[Standards] Comments about XEP-0115 v.1.5pre5 (SVN)
ogoffart at kde.org
Thu Aug 30 22:00:31 UTC 2007
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'
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the Standards