I have just completed a full review of rfc3920bis and will submit a new version as soon as I have found time to key in my edits (most of which are minor editorial nits).
One larger issue is stream restarts after STARTTLS negotiation and SASL negotiation. Currently, rfc3920bis says things like this (in the case of STARTTLS failure): It is not necessary to send a closing </stream> tag before terminating the TCP connection, since the receiving entity and initiating entity MUST consider the original stream to be closed upon failure of the TLS negotiation. And this (STARTTLS success): It is not necessary to send a closing </stream> tag before sending the initial stream header, since the receiving entity and initiating entity MUST consider the original stream to be closed upon success of the TLS negotiation. The phrase "not necessary" is not good spec writing (there is no requirements keyword "NOT REQUIRED" in RFC 2119). Does that text imply that the receiving entity MAY send a closing stream tag? Interestingly, in the very first attempt at defining STARTTLS negotiation (XEP-0035), the closing </stream> tag was sent by the receiving entity: http://www.xmpp.org/extensions/xep-0035.html#sect-id2251066 That approach certainly seems cleaner from an XML standpoint (the original stream is over, start a new one). Would anything break if we specified that the receiving entity SHOULD close the stream and then the initiating entity shall send a new initial stream header? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
