🚀 go-pugleaf

In article <5c5436cd.1bc5b@pisa.citi.umich.edu> rees@pisa.citi.umich.edu (Jim Rees) writes:
   In article <BOB.92Nov3145722@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
     Since 0xff is outside the range that can be negotiated using the
     LCP Async-Control-Character-Map mechanism, some special means
     must be exercised to keep it from being a part of the user data
     stream.

   Surely you're not serious.  The ppp folks provided an escape
   mechanism for characters that can't be sent transparently, then
   limited the scope of that mechanism?  That seems seriously stupid
   to me.  What could they possibly have been thinking?

The escaping mechanism isn't limited, only the negotiation mechanism.

Since the initial asyncmap is 32 "1" bits for guaranteed transparency,
LCP negotiations (including negotiations regarding the eventual
operational asyncmaps) progress with all the async control characters
escaped into two-byte pairs, each consisting of a 0x7D flag followed
by a byte that's the original byte XOR'd with 0x20.  Each byte of any
resulting escaped pair is thus outside the range of the asyncmap.

If the initial asyncmap were 256 "1" bits, what byte range would you
use for negotiations?  Everything would need to be escaped, but even
those escaped results would need to be escaped before transmission.
What would they transform into?  If you wanted to leave some
"printable" characters out of the 256-bit wide all-ones initial
asyncmap so that they'd be available for negotiation, how would you
know which ones to leave out, without first negotiating them somehow?

Only the negotiation mechanism is so limited, but the escaping
mechanism can be used on (almost) any character without in-band
negotiation.  This breaks the general philosophy of "no a-priori
configuration", but no good general solution has been proposed, and
this workaround is at least pragmatic, though ugly.

(Actually, the escaping mechanism is also limited, but not as badly as
the negotiation mechanism.  You can't escape 0x5E, 0x7D or 0x7E
because their XOR-with-0x20 results would collide with PPP's HDLC
framing character, the escape leadin, and with each other, resulting
in unresolvable ambiguities.)