Updates for new RFC.

Author: larsbrinkhoff

doc/rfc-new.txt

@@ -9,6 +9,9 @@ Obsoletes: 165, 6529                                           J. Postel
 
 Abstract
 
+ | The authors suggest the Internet community should switch to another
+ | protocol.
+
    This document reproduces the Host/Host Protocol developed by the ARPA
    Network Working Group during 1969, 1970, and 1971.  It describes a
    protocol used to manage communication between processes residing on
@@ -622,7 +625,8 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    that byte size, then the outer layer of protocol will not be
    implementable on that Host.
 
-   The IMP sub-network requires that the first 32 bits of each message
+ | The original protocol on the IMP sub-network requires that the first
+   32 bits of each message
    (called the leader) contain addressing information, including
    destination Host address and link number.  The second level protocol
    extends the required information at the beginning of each message to
@@ -631,9 +635,15 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    conveniently with 8-bit units of data or have word lengths of 18 or
    36 bits; 72 is the least common multiple of these lengths.  Thus, the
    length chosen for the message header should reduce bit-shifting
-   problems for many Hosts.  In addition to the leader, the message
+   problems for many Hosts.
+ | In 1976, the leader was extended to 96 bits, and the host was
+ | allowed to specify some number of 16-bit padding words between the
+ | leader and the message data portion.
+   In addition to the leader, the message
    header includes a field giving the byte size used in the message, a
    field giving the number of bytes in the message, and "filler" fields.
+ | Note that the message header applies to both control messages and
+ | regular messages containing data.
    The format of the message header is fully described in Section IV.
 
    Another major concern of the second level protocol is a method for
@@ -804,6 +814,69 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    _queueing_facility._  This is not, however, an absolute requirement
    of the protocol.
 
+ | _Initial Connection Protocol_
+
+ | RFC 165 specifies a procol that allows a server to listen to some
+ | particular well-known socket number, and then establish two
+ | connections for full-duplex communication between the server and
+ | user processes.  To do this, first a temporary simplex connection
+ | is opened for the server to transfer a new socket number to the
+ | user.  Then this socket is the basis for opening two new
+ | connections between the two processes, and the first connection is
+ | closed.
+
+ | Below, the well-known socket is called L.  The temporary connection
+ | is initiated by the user from socket U.  The new socket number is
+ | S, and the full-duplex connections are between S and U+3, and S+1
+ | and U+2.
+
+   Server                          User
+
+   S1: listening on socket L.      U1: RTS (U, L, _l1_)
+
+   S2: Wait for match.             U2: Wait for match.
+
+   S3: STR (L, U, _s1_)
+
+   S4: Wait for allocation.        U3: All (_l1_, _m1_, _b1_)
+
+   S5: Send data S in_s1_ bit      U4: Receive data S in s1 bit bytes.
+       bytes as allowed by             _s1_ bit bytes.
+       allocation m1_, _b1_).
+
+   S6: CLS (L, U)                  U5: CLS (U, L)
+
+   S7: RTS (S, U+3, _l2_)          U6: STR (U+3, S, _s2_)
+
+   S8: STR (S+1, U+2, _s3_)        U7: RTS (U+2, S+1, _l3_)
+
+   The labels here imply no ordering except that ordering required by
+   the Host-Host Protocol.  Note that steps S7 and S8 can be reversed as
+   can U6 and U7.  Also, notice that at any time after S2 the server
+   could initiate steps S7 and S8 in parallel with steps S3 through S6,
+   and that at any time after U4 the user could initiate steps U6 and U7
+   in parallel with step U5.
+
+   Following the above, exchanges ALL commands would be exchanged and
+   data transfers could begin.
+
+   At this level the parameters of the above ICP family are L, _m1_,
+   _b1_, _s1_, _s2_, _s3_, _l1_, _l2_, _l3_.
+
+   L is a well known socket number and will be specified for each type
+   of service.
+
+   m1 and b1 are allocation quantities for the transfer of a socket
+   number.
+
+      _m1_ is specified to be 1.
+      _b1_ is specified to be 32.
+      _s1_, _s2_, and _s3_ are byte sizes.  Only _s1_ is to be specified
+         as _s2_ and _s3_ are to be left to the process involved.
+      _s1_ is specified to be 32.
+
+      _l1_, _l2_, and _l3_ are links and are not specified.
+
 
    Connection Termination
    ======================
@@ -1710,6 +1783,11 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
       ERR = 11
       RST = 12
       RRP = 13
+      RAR = 14
+      RAS = 15
+      RAP = 16
+      NXR = 17
+      NXS = 18
 
 
    Control Command Summary
@@ -1803,6 +1881,31 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
         | RRP |
         +-----+
 
+           8
+        +-----+
+        | RAR |
+        +-----+
+
+           8
+        +-----+
+        | RAS |
+        +-----+
+
+           8
+        +-----+
+        | RAP |
+        +-----+
+
+           8
+        +-----+
+        | NXR |
+        +-----+
+
+           8
+        +-----+
+        | NXS |
+        +-----+
+