doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1782.txt b/doc/rfc/rfc1782.txt
new file mode 100644
index 0000000..bef8d84
--- /dev/null
+++ b/doc/rfc/rfc1782.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          G. Malkin
+Request for Comments: 1782                                Xylogics, Inc.
+Updates: 1350                                                  A. Harkin
+Category: Standards Track                            Hewlett Packard Co.
+                                                              March 1995
+
+
+                         TFTP Option Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Trivial File Transfer Protocol [1] is a simple, lock-step, file
+   transfer protocol which allows a client to get or put a file onto a
+   remote host.  This document describes a simple extension to TFTP to
+   allow option negotiation prior to the file transfer.
+
+Introduction
+
+   The option negotiation mechanism proposed in this document is a
+   backward-compatible extension to the TFTP protocol.  It allows file
+   transfer options to be negotiated prior to the transfer using a
+   mechanism which is consistent with TFTPs Request Packet format.  The
+   mechanism is kept simple by enforcing a request-respond-acknowledge
+   sequence, similar to the lock-step approach taken by TFTP itself.
+
+   While the option negotiation mechanism is general purpose, in that
+   many types of options may be negotiated, it was created to support
+   the Blocksize option defined in [2].  Additional options are defined
+   in [3].
+
+   This document assumes reader familiarity with the TFTP specification
+   [1] and its terminology.
+
+Packet Formats
+
+   TFTP options are appended to the Read Request and Write Request
+   packets.  A new type of TFTP packet, the Option Acknowledgment
+   (OACK), is used to acknowledge a client's option negotiation request.
+   A new error code, 8, is hereby defined to indicate that a transfer
+   should be terminated due to option negotiation.
+
+
+
+Malkin & Harkin                                                 [Page 1]
+
+RFC 1782                 TFTP Option Extension                March 1995
+
+
+   Options are appended to a TFTP Read Request or Write Request packet
+   as follows:
+
+      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
+      |  opc  |filename| 0 |  mode  | 0 |  opt1  | 0 | value1 | 0 | <
+      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
+
+       >-------+---+---~~---+---+
+      <  optN  | 0 | valueN | 0 |
+       >-------+---+---~~---+---+
+
+      The "0"s shown in these illustrations and the ones below are all
+      all zero octets, i.e., NULL terminators for the preceeding
+      fields.
+
+      opc
+         The opcode field contains either a 1, for Read Requests, or 2,
+         for Write Requests, as defined in [1].
+
+      filename
+         The name of the file to be read or written, as defined in [1].
+         This is a NULL-terminated field.
+
+      mode
+         The mode of the file transfer: "netascii", "octet", or "mail",
+         as defined in [1].  This is a NULL-terminated field.
+
+      opt1
+         The first option, in case-insensitive ASCII (e.g., "blksize").
+         This is a NULL-terminated ASCII field.
+
+      value1
+         The value associated with the first option, in case-insensitive
+         ASCII.  This is a NULL-terminated field.
+
+      optN, valueN
+         The final option/value pair.  Each NULL-terminated field is
+         specified in case-insensitive ASCII.
+
+   The options and values are all NULL-terminated, in keeping with the
+   original request format.  If multiple options are to be negotiated,
+   they are appended to each other.  The order in which options are
+   specified is not significant.  The maximum size of a request packet
+   is 512 octets.
+
+
+
+
+
+
+
+Malkin & Harkin                                                 [Page 2]
+
+RFC 1782                 TFTP Option Extension                March 1995
+
+
+   The OACK packet has the following format:
+
+      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
+      |  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |
+      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
+
+      opc
+         The opcode field contains a 6, for Option Acknowledgment.
+
+      opt1
+         The first option acknowledgment, copied from the original
+         request.
+
+      value1
+         The acknowledged value associated with the first option.  If
+         and how this value may differ from the original request is
+         detailed in the specification for the option.
+
+      optN, valueN
+         The final option/value acknowledgment pair.
+
+Negotiation Protocol
+
+   The client appends options at the end of the Read Request or Write
+   request packet, as shown above.  Any number of options may be
+   specified; however, an option may only be specified once.  The order
+   of the options is not significant.
+
+   If the server supports option negotiation, and it recognizes one or
+   more of the options specified in the request packet, the server may
+   respond with an Options Acknowledgment (OACK).  Each option the
+   server recognizes, and accepts the value for, is included in the
+   OACK.  Some options may allow alternate values to be proposed, but
+   this is an option specific feature.  The server must not include in
+   the OACK any option which had not been specifically requested by the
+   client; that is, only the client may initiate option negotiation.
+   Options which the server does not support should be omitted from the
+   OACK; they must not cause an ERROR packet to be generated.  If the
+   value of a supported option is invalid, the specification for that
+   option will indicate whether the server should simply omit the option
+   from the OACK, respond with an alternate value, or send an ERROR
+   packet, with error code 8, to terminate the transfer.
+
+   An option not acknowledged by the server must be ignored by the
+   client and server as if it were never requested.  If multiple options
+   were requested, the client must use those options which were
+   acknowledged by the server and must not use those options which were
+   not acknowledged by the server.
+
+
+
+Malkin & Harkin                                                 [Page 3]
+
+RFC 1782                 TFTP Option Extension                March 1995
+
+
+   When the client appends options to the end of a Read Request packet,
+   three possible responses may be returned by the server:
+
+      OACK  - acknowledge of Read Request and the options;
+
+      DATA  - acknowledge of Read Request, but not the options;
+
+      ERROR - the request has been denied.
+
+   When the client appends options to the end of a Write Request packet,
+   three possible responses may be returned by the server:
+
+      OACK  - acknowledge of Write Request and the options;
+
+      ACK   - acknowledge of Write Request, but not the options;
+
+      ERROR - the request has been denied.
+
+   If a server implementation does not support option negotiation, it
+   will likely ignore any options appended to the client's request.  In
+   this case, the server will return a DATA packet for a Read Request
+   and an ACK packet for a Write Request establishing normal TFTP data
+   transfer.  In the event that a server returns an error for a request
+   which carries an option, the client may attempt to repeat the request
+   without appending any options.  This implementation option would
+   handle servers which consider extraneous data in the request packet
+   to be erroneous.
+
+   Depending on the original transfer request there are two ways for a
+   client to confirm acceptance of a server's OACK.  If the transfer was
+   initiated with a Read Request, then an ACK (with the data block
+   number set to 0) is sent by the client to confirm the values in the
+   server's OACK packet.  If the transfer was initiated with a Write
+   Request, then the client begins the transfer with the first DATA
+   packet, using the negotiated values.  If the client rejects the OACK,
+   then it sends an ERROR packet, with error code 8, to the server and
+   the transfer is terminated.
+
+   Once a client acknowledges an OACK, with an appropriate non-error
+   response, that client has agreed to use only the options and values
+   returned by the server.  Remember that the server cannot request an
+   option; it can only respond to them.  If the client receives an OACK
+   containing an unrequested option, it should respond with an ERROR
+   packet, with error code 8, and terminate the transfer.
+
+
+
+
+
+
+
+Malkin & Harkin                                                 [Page 4]
+
+RFC 1782                 TFTP Option Extension                March 1995
+
+
+Examples
+
+   Read Request
+
+      client                                           server
+      -------------------------------------------------------
+      |1|foofile|0|octet|0|blksize|0|1432|0|  -->               RRQ
+                                    <--  |6|blksize|0|1432|0|   OACK
+      |4|0|  -->                                                ACK
+                             <--  |3|1| 1432 octets of data |   DATA
+      |4|1|  -->                                                ACK
+                             <--  |3|2| 1432 octets of data |   DATA
+      |4|2|  -->                                                ACK
+                             <--  |3|3|<1432 octets of data |   DATA
+      |4|3|  -->                                                ACK
+
+   Write Request
+
+      client                                           server
+      -------------------------------------------------------
+      |2|barfile|0|octet|0|blksize|0|2048|0|  -->               RRQ
+                                    <--  |6|blksize|0|2048|0|   OACK
+      |3|1| 2048 octets of data |  -->                          DATA
+                                                   <--  |4|1|   ACK
+      |3|2| 2048 octets of data |  -->                          DATA
+                                                   <--  |4|2|   ACK
+      |3|3|<2048 octets of data |  -->                          DATA
+                                                   <--  |4|3|   ACK
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+References
+
+   [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
+       MIT, July 1992.
+
+   [2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783,
+       Xylogics, Inc., Hewlett Packard Co., March 1995.
+
+   [3] Malkin, G., and A. Harkin, A., "TFTP Timeout Interval and
+       Transfer Size Options", RFC 1784, Xylogics, Inc., Hewlett Packard
+       Co., March 1995.
+
+
+
+
+
+
+
+Malkin & Harkin                                                 [Page 5]
+
+RFC 1782                 TFTP Option Extension                March 1995
+
+
+Authors' Addresses
+
+       Gary Scott Malkin
+       Xylogics, Inc.
+       53 Third Avenue
+       Burlington, MA  01803
+
+       Phone:  (617) 272-8140
+       EMail:  gmalkin@xylogics.com
+
+
+       Art Harkin
+       Internet Services Project
+       Information Networks Division
+       19420 Homestead Road MS 43LN
+       Cupertino, CA  95014
+
+       Phone: (408) 447-3755
+       EMail: ash@cup.hp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Harkin                                                 [Page 6]
+