Richard Dobson wrote: >> +1. I can't see any reason for the spec to require more than a >> increasing version number. > > I would prefer if it were just an opaque string, certainly as far as the > client in concerned there is no need for it to do anything other than > store the most recent version identifier it has received and then return > that to the server when required (i.e. at login), only the server needs > to know what to do with it and this should certainly only be RECOMMENDED > or SUGGESTED/MAYBE and not MUST.
Perhaps, I'll ponder that some more... > What would happen in cases were the > version number needs to be reset to 0 because someone has such a busy > roster that over time they exhast the maximum integer value? Even my roster isn't that busy. But yes it is *possible* I suppose. > , or if > maybe in future server implementors want to compress it somehow into hex > or something similar, it would be far far better to leave this flexible > and upto the server implementor on how they format the version identifier. Sometimes flexibility comes back to bite you. I'd prefer to keep things simple if we can. What does the extra flexibility really do for us, and is it worth the cost? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
