Justin Karneges wrote: > On Wednesday 05 March 2008 5:33 pm, Richard Dobson wrote: >> Peter Saint-Andre wrote: >>> Alexander Gnauck wrote: >>>> Peter Saint-Andre schrieb: >>>>> Here is revised text: >>>>> >>>>> The value of the 'version' attribute SHOULD be a non-negative >>>>> integer representing a strictly increasing sequence number that >>>>> is increased with any change to the roster (whether or not the >>>>> client supports this extension) but MAY be a unique identifer that >>>>> is opaque to the client but understood by the server. In any case, >>>>> the 'version' attribute contained in roster pushes MUST be unique. >>>> great, +1 >>> The Council didn't like the change from MUST to SHOULD as discussed here: >>> >>> http://logs.jabber.org/[EMAIL PROTECTED]/2008-03-05.html#13:4 >>> 0:54 >>> >>> Discussion can continue, naturally. :) >> Oh well thats a shame, just have leave it as my own extension. >> Implemented timestamps this evening to try it out and its working fine >> thus far.
A few hours of testing does not a reliable protocol make. Under what conditions? Is this a public server that people can test against? > I, too, don't understand why this value needs to be specified as being a > strictly-increasing integer, if the intent is that clients should treat it as > an opaque cookie thing anyway. I'm not convinced that that's the intent. It seems that it might be useful in some situations for the client to know where it stands. > The argument is that allowing the value to be some free form string is > unnecessarily flexible. Sure. However, I'd argue that requiring it to be a > strictly-increasing integer amounts to overspecification, especially when we > have an established trend of using free form strings all over XMPP. I'd feel > the same way if Dialback mandated a particular key format. We don't > need "nanny specs". We do need technologies that won't break. > There's a big difference between avoiding overspecification (this) I'll let Dave Cridland explain why he thinks this is not overspecification. I think his experience with IETF email and data storage protocols is relevant here. In particular, during the Council meeting [1] he said: "It's a lot more efficient with an int, and everything else is either worse performance, fails entirely, or else is equivalent difficulty to an int." "One interesting point is that with an int, there's always something a client can use to get the entire roster, with versioning turned on." "I'm not quite sure what the client ought to send if everything's completely opaque - it'd need more syntax." "Put it this way, since the counter-proposal involved timestamps, which are known to be broken, I'm pretty sure people will get stuff wrong without it being a MUST." And previously on the list he said [2]: "strictly increasing numeric sequences have proved useful in the IMAP world, because clients can spot when things go wrong much more easily." And [3]: "You can't use timestamps - they're not strictly increasing, for various reasons. Firstly, two roster changes could happen at precisely the same moment. To be fair, by introducing cluster node identifiers, and having a strict strong ordering of them, you could avoid this. Secondly, the clock on a computer can, and surprisingly often does, go backwards. That's a much harder problem to solve. Thirdly, in a clustering situation, you'd have to ensure that the time on each cluster node was perfectly synchronized. So the closest you can do would be a modified timestamp that had additional logic during generation to ensure it never went backwards, in which case you don't need the cluster identifier anymore, and that's effectively the same as having a strictly increasing integer sequence anyway, so it's easier to just do that. But even if you did want to use timestamps, just representing them as an integer is pretty trivial. Look at the definition of "modtime" in ACAP (RFC 2244), which defines a strictly increasing modified timestamp represented using digits." I don't see that these concerns were addressed on the list. And I don't see this as an appeal to authority or nannyism, just heeding the voice of experience. > and being > stupidly flexible (the joke in the council logs: "a stanza of type > <message /> SHOULD be used, but another arbitrary string MAY be used, such as > <thing />"). That was a reference to the backchannel discussions at the devcon, I think. But I wouldn't know since I wasn't privy to the backchannel. :P Peter [1] http://logs.jabber.org/[EMAIL PROTECTED]/2008-03-05.html [2] http://mail.jabber.org/pipermail/standards/2008-March/018116.html [3] http://mail.jabber.org/pipermail/standards/2008-March/018119.html
smime.p7s
Description: S/MIME Cryptographic Signature
