[Standards] XEP-0115: version 1.5 revisited

Rachel Blackman rcb at ceruleanstudios.com
Wed Nov 21 17:37:46 UTC 2007

>> I.e., I think this method is kind of a mess, when just adding  
>> 'hash' in separately would've solved the backwards compatibility  
>> issue nicely.  However, that ship has probably sailed, so even just  
>> including 'v' will solve the 'users will ask for this' concern I  
>> had about displaying version strings. :)
> And then new clients would need to respond to both new-style queries  
> and old-style queries, as well as continuing to send ext for  
> backward-compatibility.

My backwards-compatibility concern was less about version display in  
this case and more about the use of that value.

Old style, if I had node='http://foo.com/bar' and ver='somestring',  
then I could query on http://foo.com/bar#somestring and get that value  
(and of course, same with the exts).

Now you are supposed to just do a straight out disco query against the  
user; http://foo.com/bar#somestring is not guaranteed to actually be a  
valid query you can perform, which means old-style clients that expect  
to do node#ver queries may not receive data at all.  Thus, we broke  
backwards compatibility entirely.

Hence my thought that including node/ver if you wanted to support the  
old style client queries, and including the hash differently if not,  
would have been more backwards-compatible.  My talk about version  
display is just because I know users will ask for the version string,  
not because I think it has any inherent value.  I just always think to  
myself 'will my users howl at me if I remove this,' and if the answer  
is 'yes,' I speak up. ;)

But I think breaking the version string for a 'backwards  
compatibility' which we then proceeded to break by removing the 'query  
on the hash' aspect of things was not our best decision as a standards  
body.  Because at this point, we've managed to confuse the issue AND  
ensure old implementations may not work, either.  That's my concern  
there; over the course of a few revisions, we made the protocol more  
confusing, and then we sacrificed the backwards compatibility we  
supposedly gained by that confusion.

I mean, I know how I will implement this (including generating my hash  
and then allowing it as a proper disco query to allow old-style  
clients to work with me), but the situation seems non-ideal.  Given  
that we broke with backwards compatibility by removing the ability to  
query on the hash, we should have just kept node/ver with their old  
meanings,  and added a separate hash attribute.

Anyway, what's done is done; I point this out only to show that we  
shouldn't let this happen again when changing other bits and pieces,  
down the road.

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/

More information about the Standards mailing list