[Standards] rfc3920bis: stream restarts

[Dave Cridland]

On Wed Oct  3 17:30:55 2007, Peter Saint-Andre wrote:
> 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?

I've not seen a server implementation ever send one, and I'm not sure  
what clients would actually do if presented with one. I think the  
safer option would be to say MUST NOT, given this matches current  
behaviour. (Or "Both entities MUST NOT send a closing </stream> tag.  
It is not necessary [...]").

In the case of 6.3.4, there's no way for the client to tell the TLS  
negotiation failed under some circumstances, and similarly for the  
server, so it's not really very useful anyway. (If a certificate  
fails verification, do you send a </stream> TLS encrypted or not?  
What do you do when there are no ciphers in common?)

In the case of 6.3.5, you could send a </stream>, but who sends it  
first?

Incidentally, whilst it might be nice to maintain a well-formed XML  
document, as Greg says, we don't actually need this in practise  
anyway, and moreover, that would require both ends to close the  
stream prior to reopening it. If that's a MAY, I see lots of  
confusion potentially.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade