[Standards] Proposed XMPP Extension: Roster Versioning

[Pedro Melo]

Hi,

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 [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."

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."

Empty?

> "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."

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  
meddle with.


> 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."

Agreed. Hence a recommendation on implementation notes to use a  
counter with those properties.

Best regtards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!