I have a few comments from a very quick read of the spec... The discovery shows the full querying another full jid to determine if the latter's client supports the extension with an <iq/>... but the <message/> traffic examples is not addressed specifically to the full jid queried, it probably should be. That is, you shouldn't be sending this extension to the jids you didn't confirm support this extension... so the traffic, I think, should be addressed to the full jid whose support was queried.
There is no discussion of discovery in the context of MUC. Regarding stanza level encryption, if any encryption is used for any message stanza to a particular (full) jid, it should be used for all. For signing of stanzas, I would say it optional whether edits should be signed when the whole text is. It depends on what the verifier is trying to verify. However, because of bandwidth concerns, I'd say "don't sign the edits" unless the sender knows the signatures on the edits are useful. I don't mind the "MUST be based on Unicode code points", but the spec should be clear that implementations "MUST count code points as they appear in the UTF-8 on the wire". It's been noted in discussions that many XML libraries translate Unicode between the wire and presentation (and vice versa) in UTF-8. I suspect that sometimes this includes unicode normalization. That can screw with the counts. I also think some sort of sort of mechanism to say "stop (or pause) RTT use". It would be good if this mechanism could be used not only by the two clients trying to do RTT, but entities in the middle. In absence of such mechanism, you'll find servers resorting to harsh methods to deal with congestion that will be blamed (right or wrong) on this extension. Also, it might be appropriate that operators of congestion/bandwidth/latency/$$$ sensitive networks are likely disrupt this extensions, and implementations should be friendly to such disruptions (such as by honoring the discovery failures). Because if clients don't, operators will escalate as they believe necessary to protect their networks. I think the word "public" should be removed from the phrase "congestion on public XMPP networks" because it an unnecessary and inappropriate qualification. Congestion and its avoidance is of general concern. I do think the appropriate rate limits/timers should be MUSTs not SHOULDs. -- Kurt
