Hi, I have some questions about backward compatibility of XEP-0115: version 1.3: http://www.xmpp.org/extensions/attic/xep-0115-1.3.html version 1.5: http://www.xmpp.org/extensions/xep-0115.html
1. If I receives a presence that contains both a 'hash' and 'ext' attributes like this: <presence from='[EMAIL PROTECTED]/orchard'> <c xmlns='http://jabber.org/protocol/caps' hash='sha-1' ext='voice-v1 jingle-audio jingle-video' node='http://code.google.com/p/exodus' ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> </presence> Version 1.5 of XEP-0115 section "5.4 Processing method" says that since it contains a 'hash' attribute, my client should send a service discovery query on the verification string. MUST I ignore the 'ext' attribute if my client follow the version 1.5 of the XEP? Is it allowed to send a discovery query on both the verification string and each bundles? Should I? 2. I don't understand how backward-compatibility works. The XEP version 1.5 says: "If a caps-processing application does not support the legacy format, it SHOULD ignore the 'ver' value entirely". But a client compliant to the XEP version 1.3 (where is defined the legacy format) will send a discovery query on the ver attribute, whatever it contains (hash as specified in v1.5 or version as in v1.3). It seems inconsistent. 3. If a client with pluggable capabilities want to be compatible with both remote client implementing the XEP v1.3 and v1.5, is the recommended way to use both 'ext' and 'hash' attributes? Can some features be advertised both in a bundle (e.g. jingle-audio) for v1.3 clients and in the main node with the verification string for v1.5 clients? -- Alban
