doc: Add RFC documents

1 files changed, 115 insertions, 0 deletions

diff --git a/doc/rfc/rfc1785.txt b/doc/rfc/rfc1785.txt
new file mode 100644
index 0000000..a91c3f3
--- /dev/null
+++ b/doc/rfc/rfc1785.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                                          G. Malkin
+Request for Comments: 1785                                Xylogics, Inc.
+Updates: 1350                                                  A. Harkin
+Category: Informational                              Hewlett Packard Co.
+                                                              March 1995
+
+
+                    TFTP Option Negotiation Analysis
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   The TFTP option negotiation mechanism, proposed in [1], is a
+   backward-compatible extension to the TFTP protocol, defined in [2].
+   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.
+
+   This document was written to allay concerns that the presence of
+   options in a TFTP Request packet might cause pathological behavior on
+   servers which do not support TFTP option negotiation.
+
+Test Results
+
+   A TFTP client, modified to send TFTP options, was tested against five
+   unmodified servers:
+
+      DEC   DEC 3000/400 alpha   OSF1 V3.0
+      SGI   IP17 mips            IRIX 5.2
+      SUN   sun4c sparc          SunOS 5.1
+      IBM   RS/6000 Model 320    AIX 3.4
+      SUN   sun4m                SunOS 4.1.3
+
+   In each case, the servers ignored the option information in the
+   Request packet and the transfer proceeded as though no option
+   negotiation had been attempted.  In addition, the standard BSD4.3
+   source for TFTPD, the starting point for many implementations, was
+   examined.  The code clearly ignores any extraneous information in
+   Request packets.
+
+   From these results and examinations, it is clear that the TFTP option
+
+
+
+Malkin & Harkin                                                 [Page 1]
+
+RFC 1785            TFTP Option Negotiation Analysis          March 1995
+
+
+   negotiation mechanism is fully backward-compatible with unmodified
+   TFTP servers.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+References
+
+   [1] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782,
+       Xylogics, Inc., Hewlett Packard Co., March 1995.
+
+   [2] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
+       MIT, July 1992.
+
+Related Documents
+
+   Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783,
+       Xylogics, Inc., Hewlett Packard Co., March 1995.
+
+   Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
+       Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., 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 2]
+