[Standards] XEP-0115: version 1.5 revisited

Peter Saint-Andre stpeter at stpeter.im
Wed Nov 21 18:18:31 UTC 2007


Rachel Blackman wrote:
>>> 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.

I don't think I agree. That is, I think if you receive a disco#info
request at a node you don't know about, you should reply as if the node
attribute had not been included. But I notice that this is not specified
in XEP-0030.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20071121/73fddecc/attachment.bin>


More information about the Standards mailing list