On Wednesday 05 March 2008 8:27 pm, Peter Saint-Andre wrote: > Justin Karneges wrote: > > 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.
That changes things then. I saw some mention of that in the council logs, but I must have missed that on the mailing list so I didn't consider it. > > 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. Indeed. To clarify the point I was trying to make, imagine there are three categories for specifications: overly flexible, neutral, and restrictive. Opaque string: neutral. Strictly-increasing integer: restrictive. Compare this to the joke about stanzas: <message/>-only: neutral. <message/> or <thing/>: overly flexible. What counts as what is a matter of what the usual design practices and trends are for related specifications. My assessment, from what I read in the mailing list arguments, is that opaque was in the 'neutral' category. Thus it should not be Richard that needs to argue for opaque, but rather it should be Dave that needs to argue for integer. IMO, I guess. Okay, enough of that nonsense. :) > > 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: > [snip] To be honest, all of this still reads like implementation notes to me, except: > "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." Maybe these could be explained here on the list. The implication in these statements is that the revision value has meaning to the client, and that the client can even create these values. -Justin
