home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / ppp / 892 < prev    next >
Encoding:
Text File  |  1992-11-14  |  2.8 KB  |  55 lines
  1. Newsgroups: comp.protocols.ppp
  2. Path: sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!mstar!mstar!bob
  3. From: bob@MorningStar.Com (Bob Sutterfield)
  4. Subject: asyncmap rationale (was Re: PPP via intermediate links)
  5. In-Reply-To: rees@pisa.citi.umich.edu's message of 12 Nov 1992 20: 26:44 GMT
  6. Message-ID: <BOB.92Nov13105133@volitans.MorningStar.Com>
  7. Sender: news@MorningStar.Com
  8. Nntp-Posting-Host: volitans.morningstar.com
  9. Organization: Morning Star Technologies
  10. References: <1ck9arINNjro@gap.caltech.edu> <BOB.92Nov3145722@volitans.MorningStar.Com>
  11.     <5c5436cd.1bc5b@pisa.citi.umich.edu>
  12. Date: Fri, 13 Nov 1992 15:51:44 GMT
  13. Lines: 40
  14.  
  15. In article <5c5436cd.1bc5b@pisa.citi.umich.edu> rees@pisa.citi.umich.edu (Jim Rees) writes:
  16.    In article <BOB.92Nov3145722@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
  17.      Since 0xff is outside the range that can be negotiated using the
  18.      LCP Async-Control-Character-Map mechanism, some special means
  19.      must be exercised to keep it from being a part of the user data
  20.      stream.
  21.  
  22.    Surely you're not serious.  The ppp folks provided an escape
  23.    mechanism for characters that can't be sent transparently, then
  24.    limited the scope of that mechanism?  That seems seriously stupid
  25.    to me.  What could they possibly have been thinking?
  26.  
  27. The escaping mechanism isn't limited, only the negotiation mechanism.
  28.  
  29. Since the initial asyncmap is 32 "1" bits for guaranteed transparency,
  30. LCP negotiations (including negotiations regarding the eventual
  31. operational asyncmaps) progress with all the async control characters
  32. escaped into two-byte pairs, each consisting of a 0x7D flag followed
  33. by a byte that's the original byte XOR'd with 0x20.  Each byte of any
  34. resulting escaped pair is thus outside the range of the asyncmap.
  35.  
  36. If the initial asyncmap were 256 "1" bits, what byte range would you
  37. use for negotiations?  Everything would need to be escaped, but even
  38. those escaped results would need to be escaped before transmission.
  39. What would they transform into?  If you wanted to leave some
  40. "printable" characters out of the 256-bit wide all-ones initial
  41. asyncmap so that they'd be available for negotiation, how would you
  42. know which ones to leave out, without first negotiating them somehow?
  43.  
  44. Only the negotiation mechanism is so limited, but the escaping
  45. mechanism can be used on (almost) any character without in-band
  46. negotiation.  This breaks the general philosophy of "no a-priori
  47. configuration", but no good general solution has been proposed, and
  48. this workaround is at least pragmatic, though ugly.
  49.  
  50. (Actually, the escaping mechanism is also limited, but not as badly as
  51. the negotiation mechanism.  You can't escape 0x5E, 0x7D or 0x7E
  52. because their XOR-with-0x20 results would collide with PPP's HDLC
  53. framing character, the escape leadin, and with each other, resulting
  54. in unresolvable ambiguities.)
  55.