[Standards] Re: [jdev] XEP-0115: Entity Capabilities

Mridul Muralidharan mridul at sun.com
Mon Jul 2 11:08:29 UTC 2007


Mridul Muralidharan wrote:
> Joe Hildebrand wrote:
>>
>> On Jun 27, 2007, at 2:32 AM, Jacek Konieczny wrote:
>>
>>> That is not true. Years ago I have proposed other solution: instead of
>>> announcing client name version and caps clients should announce digest
>>> (e.g. MD5 or SHA) of normalized set of supported features. The list
>>> would have to be obtained only once per feature set and it could be
>>> verified. The traffic would not be much bigger than with current
>>> solution and the 'cache taint' problem would be gone. And
>>> implementations could be simpler (no need for capability registry --
>>> namespace registry is enough) and less error-prone (when a new namespace
>>> is added the digest would change 'automatically'. Currently developers
>>> have to manually update version or capability string).
>>>
>>> I think the digest could be used with current specification too -- as
>>> the only capability string, bound with all the supported namespaces. But
>>> XEP-0115 is not optimized for such usage and says nothing about digest
>>> verification.
>>
>> The current spec could absolutely be used for this.  The hardest part 
>> is spec'ing how to generate a string that has all of the capabilities, 
>> so that you can run the hash.  Canonical XML is massive overkill, but, 
>> for example, if we just said:
>>
>> - For all sorting, use the Unicode Collation Algorithm 
>> (http://www.unicode.org/unicode/reports/tr10/)
>> - Initialize an empty string E
>> - sort the identities by category, then type
>> - for each identity, append the category, then the type (if it exists) 
>> to E (note: any information inside an identity will be ignored)
>> - sort the features by URI
>> - for each feature, append the URI to E  (note: any information inside 
>> a feature will be ignored)
>> - calculate the MD5 sum for E
>> - use this for the version number or extension name
>>
>> Example (adapted from XEP-115, example 2):
>>
>> <presence from='romeo at montague.net/home'>
>>   <c xmlns='http://jabber.org/protocol/caps'
>>      node='http://exodus.jabberstudio.org/caps'
>>      ver='730c80b442e150dd5e19a31f8edfa8b1'
>>      ext='d6224a352df544cfde1fbce177301c67 
>> d0ef9e8327acf5873d16fe083b4d3f3f'/>
>> </presence>
>>
>> The receiving client SHOULD check the hashes, after doing the IQ/gets:
>>
>> md5(clientpchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/feature-neghttp://jabber.org/protocol/muc) 
>> = 730c80b442e150dd5e19a31f8edfa8b1
>> md5(clientpchttp://jabber.org/protocol/bytestreamshttp://jabber.org/protocol/sihttp://jabber.org/protocol/si/profile/file-transfer) 
>> = d6224a352df544cfde1fbce177301c67
>> md5(clientpchttp://jabber.org/protocol/xhtml-im) = 
>> d0ef9e8327acf5873d16fe083b4d3f3f
>>
>> If the receiving client detects an inconsistency, it MUST NOT use the 
>> information it received, and SHOULD show an error of some kind.
>>
>> For backwards-compatibility, any version number that is not 32 octets 
>> long consisting only of [0-9a-f] MUST be treated as if it does not 
>> implement MD5 checking.
>>
>> Analysis:
>> - Existing entities, both sending and receiving, should work fine
>> - Over time, we can phase in entities that send md5 versions and ext's
>> - Receiving clients that care about security can start checking MD5 
> 
> +1
> This sounds good enough to prevent polluting the client side cache.
> 


Forgot to add, change name from ver & ext to verh and exth ?

Also, relationship between caps and pep :
If the server supports pep - then cant it not directly respond back to 
the requester for caps disco queries ?

Regards,
Mridul

> 
>> hashes of the features to check for poisoning.
>> - Downside: more bytes in presence than today.
> 
> With server optimization implemented, wont this not be restricted to 
> first time presence push to a contact ?
> So maybe not as bad ?
> 
>> - Assertion: anything else we do will be at least this bad if not worse.
> 
> yes
> 
>>
>> If we add these bits to -115, will everyone agree to never bring up 
>> changing caps again, and to all agree on that the next time a n00b 
>> comes around?
> 
> heh
> 
>>
>> --Joe Hildebrand
>>
>>
> 
> 
> Regards,
> Mridul




More information about the Standards mailing list