[Standards] Re: [jdev] XEP-0115: Entity Capabilities
Ian Paterson
ian.paterson at clientside.co.uk
Wed Jul 4 03:27:38 CDT 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