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

Mridul Mridul.Muralidharan at Sun.COM
Wed Jul 4 18:36:42 UTC 2007

Ian Paterson wrote:
> Mridul Muralidharan wrote:
>> Joe Hildebrand wrote:
>>> Changing the meaning of node breaks backwards compatibility, whereas
>>> nothing else in the current proposal does.  If there's no good reason
>>> to break backward compatibility, I suggest that we avoid it.
>> I am not sure what was decided as the final design for the spec
>> regarding hashing, but moving from existing scheme of ver & ext also
>> breaks backward compatibility.
> I don't think it does.
> 1. The 'ver' attribute used to be opaque, so existing implementations
> should cope perfectly if they receive one containing a base64-encoded
> hash value instead of something like "2.3".

So queries for both bare jid and ns#ver will be supported (and return
the same value) ? And all clients using newer spec would use bare jid I
suppose ? (so that we can deprecate ns#ver and remove this in the future)

> 2. The 'ext' attribute used to optional, so legacy applications won't
> mind if it is never specified by implementations of the latest protocol
> versions.

But we do lose ability to enable/disable plugins without invalidating
user's caps data  ... might be an acceptable tradeoff.
It should be interesting to see the effect of this on server side cache
of caps' data.

> 3. The new 'hash' attribute (containing the name of the hash) will be
> ignored by existing implementations.
> New implementations will need to be aware that if no 'hash' value is
> specified they should ignore the caps element (they should not attempt
> to be compatible with legacy caps since that would make them vulnerable
> to cache poisoning).

Makes sense.
Thanks for clarifying.

- Mridul

> - Ian

More information about the Standards mailing list