[Standards] Comments about XEP-0115 v.1.5pre5 (SVN)

Olivier Goffart 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'
>       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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070831/bdc7964c/attachment.sig>

More information about the Standards mailing list