[Standards] Proposed XMPP Extension: Roster Versioning

Pedro Melo melo at simplicidade.org
Thu Mar 6 22:30:58 UTC 2008


Please ignore this message. I hadn't read the latest version of the  
XEP, and the "MAY be a unique identifer that is opaque to the client  
but understood by the server" covers most if not all of my argument  
below. :)

Best regards,

On Mar 6, 2008, at 10:23 PM, Pedro Melo wrote:
> 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!

Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Standards mailing list