> 1. If I receives a presence that contains both a 'hash' and 'ext' > attributes like this:
If your client supports hash, and hash is present, then you have to ignore ext. I don't think it makes any sense for a client to send 'ext' and 'hash' at the same time (see below). > 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. That section is about the *processing* side: if you *receive* a 'ver' without a hash, then you should not try to discover it (since you don't support it, and you can't verify it), unless you implemented the legacy algorithm as well. Either way, you will *always* support replying to ver queries, as both legacy and new protocol use this. > 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? I don't think combining both makes sense (or will even work properly). If you support the new protocol, use the new one only, and do not send any 'ext'. cheers, Remko
