[Standards] XEP-0115 redux

[Joe Hildebrand]

On Jan 21, 2008, at 1:25 AM, Ralph Meijer wrote:

> At some point we defined XEP-0128 (Service Discovery Extensions) to  
> hold
> such additional information and it seems to me that a solution to all
> this is to include such information to calculate the value of the caps
> 'ver' attribute. This would require a different method of calculating
> the hash, though. Obviously, this is only useful if this meta
> information does not change often and is not too diverse between
> instances of the same (version) of a client.


We just had a talk about this IRL, and the upshot is, I think that  
Ralph is on to something.  If we give up on trying to reuse hash  
values across different clients, which I think is of dubious value  
particularly since I don't think it will happen all that often, then I  
think we may have a way forward.

First, the disco#info response to the relevant caps node SHOULD  
include all of the languages for which the client has name information:

<iq type='result'
     from='juliet at capulet.org/balcony'
     to='romeo at montague.net/orchard'
     id='info1'>
   <query xmlns='http://jabber.org/protocol/disco#info'
          node='http://example.com/clients/foo#somehash'>
     <identity
         xml:lang='en'
         category='client'
         type='pc'
         name='A client named foo'/>
     <identity
         xml:lang='it'
         category='client'
         type='pc'
         name='Un programma chiamata foo'/>
     ...
     <x xmlns='jabber:x:data' type='result'>
       <field var='FORM_TYPE' type='hidden'>
         <value>urn:xmpp:clientinfo</value>
       </field>
       <field var='OS'>
         <value>Linux</value>
       </field>
       <field var='OSVersion'>
         <value>2.6.22</value>
       </field>
       ...
     </x>
   </query>
</iq>

Next, the thing that is hashed should begin like this:

category>type>lang>name>

where the lang is omitted if it is not specified in the disco#info  
response.  Identities should be sorted by category, then type, then  
lang (if it exists).  There MUST NOT be more than one instance of a  
given category/type/lang.

As well, at the end of the current string, we should tack on the  
XEP-128 extensions, if any.

var>value>value>var>value>

where the fields are sorted by var, and the values are sorted by the  
contents of the value if there is more than one.

Now, this will result in larger disco#info responses, but I don't  
think I care, since they won't happen often.  There will also be more  
hashes in the wild, but not *that* many.

We'll also need a clientinfo XEP, but that's probably not that hard.

Hopefully, this will allow us to send around all of the information  
that is required, without doing info or version floods, allowing for  
the existing 1.4 caching rules to continue to be used to good effect.

-- 
Joe Hildebrand