[Standards] Proposed XMPP Extension: Roster Versioning
melo at simplicidade.org
Thu Mar 6 22:23:51 UTC 2008
On Mar 6, 2008, at 4:27 AM, Peter Saint-Andre wrote:
> 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.
If we are going to have semantic meaning the in the version then the
spec must reflect what the meaning is.
I agree that servers will use a counter or sequence per roster for
this, because its efficient and they can easily see what needs to be
sent to the client. What I don't get is why we should force that in
the spec, given that the client never uses the version semantically,
he only sends it back to the server.
I think the version should be specifiec as a opaque string, and in
the implementation notes recommend strongly the use of a counter for
the reasons Dave Cridland gave.
> 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  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."
he is right but thats a server issue, Clients don't care, they store
it and send it back later.
So at most this is relevant as implementation notes for servers.
Again: I think most of us agree that servers will use an integer
counter because its the most efficient way to implement the entire XEP.
What I don't see is the need to tell that in the spec, therefore
limiting us for the future.
> "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."
Sending a 0? what about sending an empty version attribute? Same thing.
> "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,
> are known to be broken, I'm pretty sure people will get stuff wrong
> without it being a MUST."
Others might counter-propose something meaningful but some are
proposing something opaque, without meaning for the client. And that
is the best way for clients not to mess up.
Server authors have to get it right based on their architecture of
their server, and that is something that I don't think specs should
> And previously on the list he said :
> "strictly increasing numeric sequences have proved useful in the IMAP
> world, because clients can spot when things go wrong much more
Agreed. Hence a recommendation on implementation notes to use a
counter with those properties.
XMPP ID: melo at simplicidade.org
More information about the Standards