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

Ian Paterson ian.paterson at clientside.co.uk
Wed Jul 4 08:27:38 UTC 2007


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".
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.
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).

- Ian




More information about the Standards mailing list