doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2347.txt b/doc/rfc/rfc2347.txt
new file mode 100644
index 0000000..dbc0f8c
--- /dev/null
+++ b/doc/rfc/rfc2347.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          G. Malkin
+Request for Commments: 2347                                 Bay Networks
+Updates: 1350                                                  A. Harkin
+Obsoletes: 1782                                      Hewlett Packard Co.
+Category: Standards Track                                       May 1998
+
+
+                         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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+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 TFTP's 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].
+
+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
+
+
+
+Malkin & Harkin             Standards Track                     [Page 1]
+
+RFC 2347                 TFTP Option Extension                  May 1998
+
+
+   should be terminated due to option negotiation.
+
+   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 |
+       >-------+---+---~~---+---+
+
+      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 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.
+
+   The OACK packet has the following format:
+
+
+
+
+
+
+
+Malkin & Harkin             Standards Track                     [Page 2]
+
+RFC 2347                 TFTP Option Extension                  May 1998
+
+
+      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
+      |  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 should 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             Standards Track                     [Page 3]
+
+RFC 2347                 TFTP Option Extension                  May 1998
+
+
+   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             Standards Track                     [Page 4]
+
+RFC 2347                 TFTP Option Extension                  May 1998
+
+
+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
+
+   The basic TFTP protocol has no security mechanism.  This is why it
+   has no rename, delete, or file overwrite capabilities.  This document
+   does not add any security to TFTP; however, the specified extensions
+   do not add any additional security risks.
+
+References
+
+   [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
+       October 1992.
+
+   [2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
+       May 1998.
+
+   [3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer
+       Size Options", RFC 2349, May 1998.
+
+
+
+
+
+Malkin & Harkin             Standards Track                     [Page 5]
+
+RFC 2347                 TFTP Option Extension                  May 1998
+
+
+Authors' Addresses
+
+   Gary Scott Malkin
+   Bay Networks
+   8 Federal Street
+   Billerica, MA  01821
+
+   Phone:  (978) 916-4237
+   EMail:  gmalkin@baynetworks.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             Standards Track                     [Page 6]
+
+RFC 2347                 TFTP Option Extension                  May 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Harkin             Standards Track                     [Page 7]
+