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/
smime.p7s
Description: S/MIME Cryptographic Signature
