Le jeudi 30 août 2007, Rachel Blackman a écrit : > >>> Personally I think the client version information should be > >>> carried in the disco#info using XEP-0128 using a new special > >>> FORM_TYPE (maybe even reusing using jabber:iq:version and using > >>> its elements as the xdata field names). > > > > Or it could be split out as a separate attribute. > > > > <c xmlns='http://jabber.org/protocol/caps' > > node='http://exodus.jabberstudio.org/' > > ver='8RovUdtOmiAjzj+xI7SK5BCw3A8=' > > v='0.9.1'/> > > > > Where the v attribute SHOULD be included. > > So, we ripped the version out, reused the ver tag as a hash of the > nodeless disco query results, then have decided you can no longer > query on that (since the hash may change as features are added/ > removed, and so the hash is not necessarily a valid disco node)... > and now we are putting the version back into caps, albeit in a > different attribute. > > To me, this begs the question of why we do not simply: > > <c xmlns='http://jabber.org/protocol/caps' > node='http://exodus.jabberstudio.org/' > ver='0.9.1' > hash='8RovUdtOmiAjzj+xI7SK5BCw3A8=' algo='sha1'/> > > > In the new version, the 'ver' option would be /optional/; if present, > you do still need to present your base options to legacy clients, but > will continue to interoperate with legacy clients fine, and -- for > newer ones -- will have not only the nice hash for verification, but > the version for display purposes. :)
This is not compatible with legacy client. anyway, putting the hash in the ext='' would be ok. But should the version be included? Also, what about the operating system and his version? and the architecture?
signature.asc
Description: This is a digitally signed message part.
