RE: #$" ...

[Roger Crew <rfc@MICROSOFT.com>]

The short story is that #$" is NOT an MCP message but rather part of the
fundamental definition of what is out-of-band and what is in-band, something
that should be common to all versions of MCP and any other protocols to be
based on this style of out-of-band-ness.  (And this BTW has to do with why
it's #$" and not #$#".)  I could go on (and have gone on) at length about
this, so I'll just refer you to the archives for the rationale:

    <http://www.research.att.com/~davek/mcp-dev/msg00220.html>
    <http://www.research.att.com/~davek/mcp-dev/msg00223.html>
    <http://www.research.att.com/~davek/mcp-dev/msg00271.html>


> I see no cause for an MCP/2.1 aware client to impose the 
> translation layer behaviour upon the connection until 
> absolutely necessary.  This should probably be explicit
> in the spec.

If you are extracting #$# lines from the data stream, attempting to
interpret them as OOB messages, and dropping them on the floor if this
fails, you are ALREADY imposing (a part of) the translation layer behaviour
on the connection.  In principal, wherever you're taking the trouble to
watch for #$# to give it special treatment --- which you'll note is the case
both before AND after version negotiation --- you should likewise do so for
#$".  End of story (as per MCP 2.1).

Unfortunately, when specifying what's supposed to happen before both sides
agree on a protocol or even the basic substrate like the translation layer
and how to recognize #$# lines as OOB messages, we're basically in
never-never land.  Nothing prevents you from talking to a peer who doesn't
even grok #$# but who spews random text that happens to include the correct
responses anyway.  At some point, "communication" will break down; one can
only hope that it will happen as quickly as possible.

That the description of the translation layer in MCP 2.1 conflicts with MCP
1.0 is inevitable.  MCP 1.0 is thus simply BROKEN; it unavoidably garbles
data and there's simply nothing one can do about it.  The specification of
OOBness a.k.a. the translation layer is an attempt to fix this.

IMHO, the best way out of the box --- and I'm not going to pretend this is a
particularly GOOD way out, but merely the best of a number of unpalatable
alternatives --- is to declare that MCP 1.0 *is* indeed supposed to follow
the translation layer rules (that nobody ever bothered to set down until MCP
2.1), but since

 (a) MCP 1.0 is quietly garbling your data anyway,
 (b) #$" lines are at least as infrequent as in-band #$# lines
and
 (c) MCP 1.0 is obsolete and will (we hope) disappear soon

the fact that existing implementations are not entirely "conformant" with
this retroactive specification is less significant.  This is probably the
easiest way to go from an implementation point of view.

Another possibility:  Since MCP 1.0 is likewise necessarily murky about what
happens prior to version negotiation, I would maintain that an
implementation of MCP 1.0 that performs unquoting of #$" lines prior to
version negotiation and disables it thereafter is an ENTIRELY correct
implementation of MCP 1.0, even by the old rules.

In the real world, since implementations of MCP 1.0 exist as they are, no
reasonable person will expect #$"-quoting to work prior to version
negotiation if there's any possibility that the peer will turn out to be
speaking MCP 1.0.  And since version negotiation will usually be nearly the
first thing to happen on a connection, this simply shouldn't come up that
often.