A few points of clarification... Joe Hildebrand wrote:
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:
However, this will be rare. I've never seen a client that had different names in different languages (though naturally that's possible). E.g., "Psi" in all languages but Greek, where the name is "Ψ". :)
<iq type='result'
from='[EMAIL PROTECTED]/balcony'
to='[EMAIL PROTECTED]/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'/>
The inclusion of xml:lang is not defined in XEP-0030 but it's inherited from XML, so it's allowed here.
... <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.
Right, again this would be rare.
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.
Yes I can work that up quickly.
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.
And we will also keep the 'v' attribute that's currently in 1.5.I'll update XEP-0115 along these lines so that we can once again run it up the flagpole. :)
Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
