On Tuesday 21 January 2003 04:11, Mark S. Miller wrote:
> Don't need to. Since (by assumption in the previous reply), we're
> negotiating a semantics-free choice, we can treat each direction as a
> separate decision. I imagine a protocol like the following:
>
> Both Alice and Bob just start speaking in Doc/XML. This lets message
> traffic flow prior to negotiating another format, which is good, since
> latency is more important that bandwidth or marshalling time.
>
> Alice, whenever she feels like it, tells Bob "you also may speak to me in
> Doc/doc-code or Doc/term-tree". Alice says this on the Alice->Bob link, but
> she's speaking only about the Bob->Alice link.
>
> Bob, anytime after he's gotten such permission, says in Doc/XML "I'm
> switching to Doc/doc-code". The next Bob->Alice packet must then be encoded
> in Doc/doc-code.
>
> The above sequence of events may happen to be interleaved with a
> corresponding negotiation about the other direction, or not. In any case,
> these two choices don't need to be synchronized or coordinated.

On Tuesday 21 January 2003 09:45, Tyler Close wrote:
> I'll give it some thought.

This is pretty much what I was first thinking too, but after some
more thought, I have some changes.

The above scenario makes it tricky to manage input buffers. On the
receiving side of the changeover, you're going to get an input
buffer that has some old syntax, followed by the new syntax. This
makes it tricky to send data to the correct decoder. After you
finish decoding the changeover message, you'ld have to get the
rest of the input buffer out of the old decoder and put it into
the new decoder.  This places some severe restraints on the types
of implementation models you can support. It might be better to
sacrifice a round-trip for a simpler model.

Both upstream and downstream change syntax in lockstep. Only the
initiating side of the connection can initiate a syntax change.
I'll call the initiating side of the connection the client and the
other side the server.  The procedure is:

1.  Server sends SupportedSyntaxes message.
2.  Client receives SupportedSyntaxes message.
3.  Client sends ChangeSyntax message in old syntax.
4.  Client stops sending messages.
5.  Server receives ChangeSyntax message.
6.  Server sends AckSyntax message in old syntax.
7.  Server stops sending messages.
8.  Client receives AckSyntax message. 
9.  Client starts sending messages in new syntax.
10. Server receives any message in new syntax.
11. Server starts sending messages in new syntax.

This way, both sides can cleanly terminate the input stream to the
old decoder and route future input to the new decoder.

Tyler