[Standards] Re: [jdev] XEP-0115: Entity Capabilities
mridul at sun.com
Thu Jun 28 17:28:24 CDT 2007
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
> 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
> - 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'
> The receiving client SHOULD check the hashes, after doing the IQ/gets:
> = 730c80b442e150dd5e19a31f8edfa8b1
> = d6224a352df544cfde1fbce177301c67
> md5(clientpchttp://jabber.org/protocol/xhtml-im) =
> 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.
> - 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
This sounds good enough to prevent polluting the client side cache.
> 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.
> 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
> --Joe Hildebrand
More information about the Standards