[Standards] rfc3920bis: stream restarts

[Peter Saint-Andre]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20071003/d9c9d7ca/attachment.bin