[Standards] rfc3920bis: stream restarts

[Justin Karneges]

On Wednesday 03 October 2007 10:07 am, Dave Cridland wrote:
> 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.

Depending on the client, it would probably break the TLS negotiation.

Here's a typical flow:

C: <starttls/>
S: <proceed/>
C: TLS client hello
S: TLS server hello

If instead, it became:

C: <starttls/>
S: <proceed/>
C: TLS client hello
S: </stream>
S: TLS server hello

Then </stream> would get interpretted by the client as the TLS server hello, 
and the negotiation would fail.

I say "depending on the client", because:

C: <starttls/>
S: <proceed/></stream>
C: TLS client hello
S: TLS server hello

In the above scenario, some clients might eat the </stream> data and never 
process it, if it happens to arrive in the same packet as <proceed/>.

Psi operates in a pipelined fashion until the XML stream is considered open 
for routable stanza usage, and so you'd get a TLS negotiation error 
regardless of how the TCP stream was packetized.  I think this is the most 
correct behavior, but then I don't know if we've ever had a discussion about 
XMPP pipelining yet.

-Justin