doc: Add RFC documents

1 files changed, 228 insertions, 0 deletions

diff --git a/doc/rfc/rfc749.txt b/doc/rfc/rfc749.txt
new file mode 100644
index 0000000..0e37300
--- /dev/null
+++ b/doc/rfc/rfc749.txt
@@ -0,0 +1,228 @@
+
+NWG/RFC  749                                  BSG 26-Sep-78 13:13  45499
+Network Working Group                                  Bernard Greenberg
+Request for Comments 749                                     MIT-Multics
+NIC 45499                                              18 September 1978
+
+                      Telnet SUPDUP-OUTPUT Option
+
+1.  Command name and code.
+
+   SUPDUP-OUTPUT   22
+
+2.  Command meanings.
+
+   IAC WILL SUPDUP-OUTPUT
+
+   The  sender   of  this  command   REQUESTS   permission  to  transmit
+   SUPDUP-OUTPUT format messages over the TELNET connection.
+
+   IAC WON'T SUPDUP-OUTPUT
+
+   The sender  of this command  STATES  that  he  will  no  longer  send
+   SUPDUP-OUTPUT format messages over the TELNET connection.
+
+   IAC DO SUPDUP-OUTPUT
+
+   The sender  of this command  grants  the receiver  permission to send
+   SUPDUP-OUTPUT format messages over the TELNET connection.
+
+   IAC DON'T SUPDUP-OUTPUT
+
+   The sender  of this  command  DEMANDS  that  the  receiver  not  send
+   SUPDUP-OUTPUT format messages over the TELNET connection.
+
+   IAC SB SUPDUP-OUTPUT 1 <terminal-parameters> IAC SE
+
+   The sender of this command (which must be the TELNET user process) is
+   supplying   information  describing  the  capabilities  of  the  user
+   process' terminal.
+
+   IAC SB SUPDUP-OUTPUT 2 n TD1 TD2 ..  TDn SCx SCy IAC SE
+
+   The sender  of this command, which must be the TELNET server process,
+   is sending  explicit  screen control information to be carried out by
+   the user TELNET process.
+
+3.  Default.
+
+   WON'T SUPDUP-OUTPUT
+
+   DON'T SUPDUP-OUTPUT
+
+   i.e., the SUPDUP-OUTPUT format messages may not be transmitted.
+
+
+
+Greenberg                                                       [page 1]
+
+NWG/RFC  749                                  BSG 26-Sep-78 13:13  45499
+Telnet SUPDUP-OUTPUT Option
+
+
+
+4.  Motivation for the option.
+
+   The SUPDUP-OUTPUT  protocol  provides  a means to access  the virtual
+   display  support provided by the SUPDUP protocol (see RFC 734) within
+   the context  of a standard  TELNET connection. This allows occasional
+   display-oriented  programs  at non-display-oriented  servers  to take
+   advantage  of the standardized  display  support  provided by SUPDUP.
+   This cannot  be done with the standard  SUPDUP protocol or the TELNET
+   SUPDUP option (RFC 736), for they both require that all communication
+   after the negotiation  to  use  SUPDUP  has  been  completed  proceed
+   according  to the protocol  of RFC 734.   This places upon the server
+   total responsibility  for screen  management  for the duration of the
+   connection,  which, by hypothesis, the non-display oriented server is
+   not willing to accept.
+
+   User TELNET  programs  at display-oriented  user hosts provide  local
+   screen  management  by mapping  the NVT commands of TELNET into local
+   screen   management   commands;   often,   this  involves  scrolling,
+   end-of-page  processing, line clearing etc.  The SUPDUP-OUTPUT option
+   allows  a display-oriented  application program at the server side to
+   take over  screen  management  explicitly,  via  the  SUPDUP  display
+   control repertoire.  TELNET remains in effect throughout.  The IAC IP
+   and other TELNET commands are still valid.
+
+   By means of the SUPDUP-OUTPUT  option,  display-oriented programs can
+   run  on  the  server   host,  and  control  the  user  host's  screen
+   explicitly.   The user TELNET process sends a description of the user
+   terminal  (as specified in RFC 734) to the server TELNET process as a
+   subnegiotiation  block when the SUPDUP-OUTPUT  negotiation  has  been
+   successfully  completed.   The server  TELNET  process sends explicit
+   screen  control commands via subnegotiation blocks to the user TELNET
+   process.
+
+5.  Description of the option.
+
+   The SUPDUP-OUTPUT protocol may only be initiated by the server TELNET
+   process.   A server  TELNET  process wishing to take advantage of the
+   SUPDUP-OUTPUT  protocol will initiate a negotiation for it by sending
+   IAC WILL SUPDUP-OUTPUT.   The user  TELNET  process  must  accept  or
+   refuse  the offer by  sending  IAC  DO  SUPDUP-OUTPUT  or  IAC  DON'T
+   SUPDUP-OUTPUT.
+
+   If the user  TELNET  process  agrees  to  support  the  SUPDUP-OUTPUT
+   option,   it  must  follow   the  sending  of  IAC  DO  SUPDUP-OUTPUT
+   immediately   with  a  description  of  the  user's  terminal.   This
+   information  is described in RFC 734 as the "terminal parameters." It
+   is to be sent as a series  of six-bit  bytes,  one byte per eight-bit
+
+
+
+Greenberg                                                       [page 2]
+
+NWG/RFC  749                                  BSG 26-Sep-78 13:13  45499
+Telnet SUPDUP-OUTPUT Option
+
+
+
+   TELNET  data byte.   These  words may or may not contain the optional
+   line speed and graphics capabilities parameters described by RFC 747;
+   the first  six bytes  specify  the count of 36-bit words to follow as
+   described by RFC 734.
+
+   The terminal  parameter block will be sent as a subnegotiation of the
+   SUPDUP-OUTPUT option:
+
+   IAC SB SUPDUP-OUTPUT 1 byte1 byte2 ... byten IAC SE
+
+   The byte of "1"  is a command  code,  for compatibility  with  future
+   extensions.   Upon receipt  of the terminal  parameter block from the
+   user TELNET process, the server TELNET process may send SUPDUP-OUTPUT
+   blocks as described below.
+
+   The server  TELNET  process  can specify explicit control of the user
+   host's  screen  by  the  sending  of  subnegotiation  blocks  of  the
+   SUPDUP-OUTPUT  option.   The format  of such  a  block,  as  seen  in
+   eight-bit TELNET data bytes, is:
+
+   IAC SB SUPDUP-OUTPUT 2 N TD1 TD2 TD3 ... TDn SCx SCy IAC SE
+
+   The byte of "2"  is a command  code,  for compatibility  with  future
+   extensions.  The TDm bytes are the "%TDCODEs" and printing characters
+   of SUPDUP  output  of RFC 734.  N is a byte containing a count of the
+   number  of TDm's in this transmission.  N may be zero, and may not be
+   greater than 254 (decimal).  SCx and SCy are two bytes specifying the
+   anticipated horizontal and vertical (respectively) coordinates of the
+   cursor of the user host's screen after the latter has interpreted all
+   the %TDCODEs in this transmission.
+
+   The motivation  for the SCx SCy screen  position  specification is to
+   allow hosts running the ITS operating system, which will transmit the
+   TDCODEs  directly  into the local output  system, to assert the "main
+   program  level"  screen  position  without  any interpretation of the
+   transmitted TDCODE sequence by the user TELNET program.
+
+   The user TELNET  process must manage the position of the local cursor
+   with respect  to standard  TELNET NVT commands and output, and SUPDUP
+   OUTPUT  transmissions.   The user TELNET  process may assume that the
+   server  TELNET  process is managing both NVT and SUPDUP-OUTPUT output
+   in an integrated way.
+
+   The SUPDUP-OUTPUT  option makes no statement about how input is sent;
+   this may be negotiated via other options.  By default, NVT input will
+   be used.   The user-to-server  screen  management commands of RFC 734
+   are NOT implicitly handled by IAC WILL SUPDUP-OUTPUT.
+
+
+
+Greenberg                                                       [page 3]
+
+NWG/RFC  749                                  BSG 26-Sep-78 13:13  45499
+Telnet SUPDUP-OUTPUT Option
+
+
+
+   In the absence  of the transmission  of SUPDUP-OUTPUT  subnegotiation
+   blocks,  a TELNET  connection operating with the SUPDUP-OUTPUT option
+   in effect is indistinguishable from a normal TELNET connection.  Thus
+   IAC WON'T SUPDUP-OUTPUT  is highly  optional,  and if received by the
+   user TELNET  process,  should  only be used to cause  a diagnostic if
+   SUPDUP-OUTPUT  subnegotiation  blocks  are subsequently received.  If
+   received,  the user TELNET  process  should  respond  with IAC  DON'T
+   SUPDUP OUTPUT.
+
+   Because  of the optional  nature of IAC WON'T SUPDUP-OUTPUT, the user
+   TELNET  process  should  be prepared  to send the terminal  parameter
+   subnegotiation  block each time IAC WILL SUPDUP-OUTPUT  is  received,
+   i.e., even if the user TELNET process believes SUPDUP-OUTPUT to be in
+   effect.
+
+   The %TDORS  (output  reset)  code may not be sent in a  SUPDUP-OUTPUT
+   transmission.   The user TELNET  program may assume that no byte in a
+   subnegotiation block will be 255 (decimal).
+
+   No multi-byte  TDCODE  sequence  (e.g.,  %TDMOV, %TDILP) may be split
+   across SUPDUP-OUTPUT subnegotiation blocks.
+
+References:
+
+   Crispin, Mark:
+
+      "SUPDUP Display Protocol", RFC 734, 7 October 1977, NIC 44213.
+
+   Crispin, Mark:
+
+      "TELNET SUPDUP Option", RFC 736, 31 October 1977, NIC 44213.
+
+   Crispin, Mark:
+
+      "Recent  Extensions  to the SUPDUP  Protocol",  RFC 747,  21 March
+      1978, NIC 44015.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Greenberg                                                       [page 4]
\ No newline at end of file