On 12/3/09 12:54 PM, Robin Collier wrote: > > >> Date: Thu, 3 Dec 2009 11:56:30 -0700 >> From: [email protected] >> To: [email protected] >> Subject: [PubSub] finishing up 1.13 >> >> OK folks, it's time to push version 1.13 of XEP-0060 out the door. My >> main question is: do we have consensus on the versioning stuff? If not >> (and if we can't gain consensus soon), then I would vote to remove it so >> that we can publish 1.13. >> > > I am sure it comes as no surprise, but I believe 'ver' values need to be > ordered
In roster versioning (XEP-0237), we said only that the 'ver' needs to be unique, leaving it up to the implementation whether it will make the 'ver' a strictly-increasing sequence number (and I think that's the consensus for pubsub, as well). It's not clear to me why pubsub 'ver' needs to be ordered. Could you please recap your argument for why *all* pubsub implementations (not just your implementation) MUST enforce ordering? > and present in the request for items on a per item basis A request for items is (typically) a request for 1+ items, and that's covered by a new section in the spec. A client is free to include 'ver' on the request, but is not required to do so. Are you suggesting that the spec makes this a MUST? Do you also think that a request for a particular item MUST include the 'ver'? > to resolve > the issue with synch and async retrieval of the same item at the application > level. This would then resolve more use cases than the opaque id. So implement it that way in your system. I still don't see why this needs to be a MUST for all implementations. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
