since I'm halfway through anyway...
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Well, I think sending a message with s/airlock/window/ would be sufficient, but i'm rather old-fashioned :-)
2. Does the specification solve the problem stated in the introduction and requirements?
Piggybacking on the id seems like a dirty hack, but for the sake of traffic it's better than adding a new xml element to each message stanza.
3. Do you plan to implement this specification in your code? If not, why not?
server-dev, N/A
4. Do you have any security concerns related to this specification?
See my other messages.
5. Is the specification accurate and clearly written?
I would reorder the business rules in section 4 so that they deal with the topics in a less random order. Proposed order would be 1+4 (dealing with the id on the sender side), 5+6 (dealing with the sender) and 3+4 last (dealing with the receiver).
The discovery examples in section 2 use a server jid which seems awkward, probably related to the text at the start of the section.
THIS PROTOXEP in the registrar considerations should have probably been replaced by XEP-0308 upon publication.
