doc: Add RFC documents

1 files changed, 115 insertions, 0 deletions

diff --git a/doc/rfc/rfc696.txt b/doc/rfc/rfc696.txt
new file mode 100644
index 0000000..60c90dd
--- /dev/null
+++ b/doc/rfc/rfc696.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                                            V. Cerf
+Request for Comments: 696                            Stanford University
+NIC: 32962                                                     July 1975
+
+
+           Comments on IMP/HOST and HOST/IMP Protocol Changes
+
+   With reference to RFC's 687, 690, and 692 (NIC's 32564, 32699, and
+   32734, respectively) by D.C. Walden, J. Postel, and S. Wolfe
+   (respectively), I would like to offer some observations relative to
+   current international standards recommendations from working group
+   6.1 of the International Federation of Information Processing.  In a
+   meeting held last May at the NCC, this working group voted to present
+   a recommendation to CCITT (International Consultative Committee on
+   Telephony and Telegraphy of the International Telegraphics Union) for
+   a standard packet (or DATAGRAM) header.
+
+   The proposed packet header format is meant to interface hosts to
+   packet networks.  It is not a header for Host-to-Host protocol, nor
+   is it an IMP-to-IMP header.  The bulk of the header is taken up with
+   addressing space(96 bits!)  since this will be compatible with the
+   current maximum address space of the telephone system (14 digits).
+
+   LOCAL NETWORK FIELD - 4 bits
+
+      This field allows local networks to operate easily on multiple
+      formats, since the 4 bits can be used in any fashion desired by
+      the local network.
+
+   DATAGRAM FORMAT - 4 bits
+
+      This field could be used by ARPANET to contain "1001" binary, so
+      as to maintain backward compatibility with the existing message
+      leader format.
+
+   PACKET TYPE CODE - 8 bits
+
+      This could be used for the HOST/IMP and IMP/HOST code.
+
+   FACILITIES - 16 bits
+
+      These bits have not yet been specifically allocated.  Some will no
+      doubt be for international services (e.g., tracing at gateways
+      between networks, accounting, class of service).  It was the
+      feeling of WG 6.1 members that some of these bits (e.g., 8) might
+      be allocated to the originating network (or destination network)
+      for its own use.
+
+
+
+
+Cerf                                                            [Page 1]
+
+RFC 696    Comments on IMP/HOST and HOST/IMP Protocol Changes  July 1975
+
+
+   TEXT LENGTH - 16 bits
+
+      These bits count the number of octets in the text of the packet,
+      not including octets in the header (which is fixed in length for
+      any particular format).
+
+   DESTINATION ADDRESS - 48 bits [1]
+
+      These bits could be allocated in the following way: Destination
+      Network Identifier - 8 bits; Destination Host Identifier - 8 bits;
+      Destination IMP identifier - 16 bits; Reserved- 16 bits.
+
+   SOURCE ADDRESS - 48 bits
+
+      These bits would be used in a fashion similar to the destination
+      address bits.
+
+   The resulting packet is 144 bits long and adding the present 40-bit
+   Host-to-Host header results in a total of 184 bits, which is not very
+   pleasant.  A temporary fix (until we can introduce a new NCP design)
+   might be to squeeze out the reserved 16-bit fields in the source and
+   destination address fields, giving 32 bits to carry the byte size and
+   byte count information for the present Host/Host protocol.
+   Alternatively, the length field of the packet header and one of the
+   facilities flags (or a whole field) could be used to indicate byte
+   size and byte count.  Either idea would require some fairly
+   substantial modification of existing NCP programs, so is probably not
+   very palatable.
+
+   Another alternative would be to add a dummy byte after the 144th bit
+   of header, followed by 40 bits of NCP header, giving a total length
+   of message leader and NCP header of 192 bits, a number divisible by
+   12, 16, 24, 32, 48.
+
+   With respect to the proposed text length field, although bit lengths
+   are the most flexible, it seems reasonable to admit that nearly all
+   data transmission is done in 8-bit quantities, and therefore that bit
+   lengths are, in fact, an unnecessary luxury.  This is a weak argument
+   when 36-bit and 32-bit machines must interface.
+
+
+
+
+         [ This RFC was put into machine readable form for entry ]
+         [ into the online RFC archives by Alex McKenzie with    ]
+         [ support from GTE, formerly BBN Corp.            11/99 ]
+
+
+
+
+
+Cerf                                                            [Page 2]
+