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".
True. 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. Yes. 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 >
