[Standards] XEP-0115: version 1.5 revisited

Peter Saint-Andre stpeter at stpeter.im
Tue Nov 20 02:54:29 UTC 2007


OK, I'm still trying to get to closure here... :)

Rachel Blackman wrote:
>> A version is only interesting if you know the software that it goes with.
>> Unfortunately all we have is a URI, which means for any sane display I
>> need a
>> table of URI->"software name" mappings, and thus I can only display
>> versions
>> for software I know about.  That seems limiting.
> 
> Not really; you can just cache the identity part of a disco query when
> you cache the list of features.  Usually the identity contains the
> client name, and you are already generally getting that when you do your
> disco query.  In general, I see things like...
> 
> <identity category='client' name='Exodus' type='pc'/>
> 
> ...coming back.  You cache the name, and add the version.  (Optionally,
> if the name string contains the version string, a'la 'Exodus 0.9.1' and
> version '0.9.1' you just use the name unmodified.)

Hmm. What if you have this?

<presence from='romeo at montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps'
     node='http://code.google.com/p/exodus/'
     v='0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>

AND...

<identity category='client' name='Exodus 0.9.1' type='pc'/>

Then do you display the following?

Software: Exodus 0.9.1 0.9.1

[sic]

That seems bad. Let's keep the version information in one place. I think
it's safest to put it in the disco#info 'name' attribute and nowhere
else (that is, if people really want this information -- the more I
think about it, the less convinced I am that it is useful or important
to provide the version information in caps). This way we don't clog up
the caps data with version information, we don't need to add a new 'v'
attribute to caps, and we can leave the naming to disco as it (perhaps)
should have been all along.

> Granted, this becomes an issue if you have two clients with identical
> hashes but different names, so Justin's suggestion of an 'n' field in
> the caps is not without merit.  But users do like this information --
> and it can be useful to know that someone is on the Gmail web client,
> rather than Google Talk itself -- so having SOME way to convey it in a
> sensible and bandwidth-efficient manner (i.e., avoiding our old-school
> iq:version flood) is a good idea.

Well, as Justin said, a client can maintain a mapping of node -> name
(derived from disco#info results) if it really cares, right? Then if you
want to advertise different builds of the same or similar client, you
could include different nodes (http://www.google.com/talk/win vs.
http://www.google.com/talk/web or whatever).

So folks, let's keep things in perspective:

1. What really matters here is the capabilities (in 1.4+, the 'ver'
attribute).

2. The node is nice to have for certain use cases because it can give
you a mapping to a client name (via disco#info) if you want it.

3. The version information may be desirable in certain odd situations,
but I have not heard a compelling argument for it (most people want to
show the software name but are not all that interested in the exact
version). If you really really need the version, use XEP-0092 (but for
Pete's sake don't flood every person in your roster for the damn version
because no one really cares about it!).

Therefore I argue for removing version from caps (i.e., not adding it
back in version 1.5 -- we already removed it from 1.4).

An updated copy (1.5pre8) of XEP-0115 is here:

http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html

The SVN diffs are here:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=1403

Do we have consensus?

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/20071119/8e49c065/attachment.bin>


More information about the Standards mailing list