doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc5797.txt b/doc/rfc/rfc5797.txt
new file mode 100644
index 0000000..604c38f
--- /dev/null
+++ b/doc/rfc/rfc5797.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Klensin
+Request for Comments: 5797
+Updates: 959                                                   A. Hoenes
+Category: Standards Track                                         TR-Sys
+ISSN: 2070-1721                                               March 2010
+
+
+                   FTP Command and Extension Registry
+
+Abstract
+
+   Every version of the FTP specification has added a few new commands,
+   with the early ones summarized in RFC 959.  RFC 2389 established a
+   mechanism for specifying and negotiating FTP extensions.  The number
+   of extensions, both those supported by the mechanism and some that
+   are not, continues to increase.  An IANA registry of FTP Command and
+   Feature names is established to reduce the likelihood of conflict of
+   names and the consequent ambiguity.  This specification establishes
+   that registry.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5797.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 1]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Registry Definition .............................................2
+      2.1. Registry Name ..............................................2
+      2.2. Registry Format ............................................2
+      2.3. Criteria for Registration ..................................4
+      2.4. Base FTP Commands ..........................................5
+      2.5. Obsolete Commands ..........................................5
+   3. Initial Contents of Registry ....................................6
+   4. Acknowledgments .................................................8
+   5. IANA Considerations .............................................9
+   6. Security Considerations .........................................9
+   7. References ......................................................9
+      7.1. Normative References .......................................9
+      7.2. Informative References .....................................9
+
+1.  Introduction
+
+   Every version of the FTP specification has added a few new commands,
+   with the early ones summarized in RFC 959 [RFC0959].  RFC 2389
+   [RFC2389] established a mechanism for specifying and negotiating
+   extensions to the FTP protocol specified in RFC 959, by means of
+   "FEAT Strings" identifying extensions supported by the FTP server,
+   and sent in response to a "FEAT" command.  The number of extensions
+   continues to grow, not all of them supported by FEAT.  An IANA
+   registry is established to reduce the likelihood of a conflict of
+   names and the consequent ambiguity and to encourage the sharing of
+   information.  This specification establishes that registry.
+
+2.  Registry Definition
+
+2.1.  Registry Name
+
+   The name of this registry is "FTP Commands and Extensions".
+
+2.2.  Registry Format
+
+   As specified in this RFC, IANA has established a registry for FTP
+   commands and extensions.  Registration requests and registry entries
+   should include the following:
+
+   Command Name -  The FTP command, either new or modified, used in the
+      extension or with which the extension is used.
+
+      Following the long-standing practice to capitalize command names
+      in specification documents for FTP, the command names are entered
+      in all uppercase.  For extensions amending the operation of a
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 2]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+      command, a plus sign ("+") is appended to the command name.
+      However, if an extension affects the overall command parameter
+      handling and/or transaction processing, instead of being bound to
+      one command (or a small number of commands), the string "-N/A-" is
+      entered.
+
+      It is intended to have the registry entries ordered by ascending
+      ASCII collation order of this column (including the "+" suffix if
+      present).
+
+   Extension name -  The name of the extension.
+
+      FTP extensions predating RFC 2389 [RFC2389], and some extensions
+      published after it, did not specify a keyword to identify the
+      extension in a FEAT response.  Some later specifications
+      established FEAT strings with the respective command names as
+      their keywords.  In order to provide for keywords for future
+      specifications in such cases, this document establishes
+      'placeholder' keywords to reserve reasonable feature names for
+      future standardization.  Similarly, placeholder keywords are used
+      for the basic FTP commands specified in RFC 959 [RFC0959] and
+      those of its predecessors that are still in use.  These
+      placeholder keywords are placed in the registry for convenience;
+      it is not intended that they be returned in FEAT responses.
+      To compensate for this idiosyncrasy, the column in the registry is
+      entitled "FEAT Code", and to clearly distinguish between the two
+      cases, defined FEAT keywords codes are listed in all uppercase,
+      whereas placeholder keywords (henceforth called "pseudo FEAT
+      codes") are listed in lowercase.  Future specifications are
+      allowed to "upgrade" a placeholder to a true keyword unless it is
+      specifically declared 'immutable' below, but otherwise IANA
+      maintains uniqueness of feature names (FEAT codes) based on case-
+      insensitive comparison.
+
+   Description -  A brief description of the extension and, where
+      appropriate, the command.
+
+   FEAT String -  (optional in registration requests to IANA)
+
+      The string expected to be included in the response to the FEAT
+      command [RFC2389] if the extension is supported.
+
+      In many cases, the FEAT string required to identify an extension
+      only consists of the "FEAT Code", making this item redundant.
+      Therefore, this item should only be specified if it is intended to
+      register a FEAT string that contains mandatory elements other than
+      the "FEAT Code" itself.
+
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 3]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+      Due to space restrictions, and to allow registrants to provide
+      additional information, IANA should present these registration
+      items (if given) in numbered footnotes to the table, not in an
+      additional table column.
+
+   Command Type -  The type (or 'kind') of the command.
+
+      Section 4.1 of RFC 959 [RFC0959] introduced a subdivision of FTP
+      commands into three types: Access control, transfer Parameter
+      {setting}, and Service {execution}.  For clarity, and as a service
+      to the user of the registry, this subdivision is extended to all
+      registered FTP commands, using the characteristic initial of the
+      type, 'a', 'p', or 's', respectively, filed in the registry column
+      titled "type"; combinations are allowed, e.g., 'p/s'.
+
+   Conformance Requirements -  The support expectation for the command.
+
+      RFC 959 specifies mandatory-to-implement commands and optional
+      commands.  This classification is carried over to all registered
+      commands, using a column titled "conf" carrying a single character
+      -- either 'm' or 'o', for "mandatory" and "optional",
+      respectively.  Similarly, obsoleted or historic entries are left
+      in the registry to avoid conflicts with deployed implementations,
+      and these entries are marked with 'h' (for "historic").
+      Beyond the initial registrations, Standards Action [RFC5226] is
+      needed to register new "mandatory" entries or to move such entries
+      to "historic".
+
+   Reference -  A reference to an RFC or other definition of the
+      extension and/or to implementations supporting it (see the next
+      section).
+
+2.3.  Criteria for Registration
+
+   This registry is primarily intended to avoid conflicting uses of the
+   same extension names and command keywords for different purposes, not
+   to demonstrate that an extension is somehow "approved".  The "Expert
+   Review" method will be used, but the designated expert is expected to
+   check only that at least one of the two criteria that follow are met.
+
+   1.  The extension is documented in a permanent and readily available
+       public specification (this is the same as the "Specification
+       Required" registration policy defined in RFC 5226 [RFC5226]).
+
+   2.  The extension is actually implemented in FTP client and server
+       systems that are generally available (not necessarily either free
+       or unencumbered, but available).
+
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 4]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+   For an extension or command to be marked "mandatory" ('m' in the
+   "conf" column), an IETF Standards Track specification is required.
+   An IESG Standards Action is allowed to direct IANA to change the
+   Conformance Requirements listed for any entry.
+
+2.4.  Base FTP Commands
+
+   The following commands are part of the base FTP specification
+   [RFC0959] and are listed in the registry with the immutable pseudo
+   FEAT code "base".
+
+      Mandatory commands:
+
+      ABOR, ACCT, ALLO, APPE, CWD, DELE, HELP, LIST, MODE, NLST, NOOP,
+      PASS, PASV, PORT, QUIT, REIN, REST, RETR, RNFR, RNTO, SITE, STAT,
+      STOR, STRU, TYPE, USER
+
+      Optional commands:
+
+      CDUP, MKD, PWD, RMD, SMNT, STOU, SYST
+
+   Note: STD 3 [RFC1123] clarified and updated the status and
+   implementation requirements of these standard FTP commands, and it
+   contains important complementary information for the following
+   commands:
+
+      LIST, NLST, PASV, REST, SITE, STOU
+
+2.5.  Obsolete Commands
+
+   The following commands were specified as experimental in an extension
+   to an early version of the FTP specification [RFC0775] but later
+   deprecated by RFC 1123 [RFC1123], because Standard FTP [RFC0959]
+   specifies their standard successors.  They are listed in the registry
+   with the immutable pseudo FEAT code "hist".
+
+      XCUP, XCWD, XMKD, XPWD, XRMD
+
+   Implementation note:  Deployed FTP clients still make use of the
+      deprecated commands and most FTP servers support them as aliases
+      for the standard commands.
+
+   The following commands were specified as part of the "FOOBAR" IPng
+   effort in RFC 1545 [RFC1545] and, later, RFC 1639 [RFC1639] and are
+   now obsolete.  They are listed in the registry with the immutable
+   pseudo FEAT code "hist".
+
+      LPRT, LPSV
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 5]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+3.  Initial Contents of Registry
+
+   As a service to users of the registry and the authors of existing
+   specifications, all FTP commands and features published in RFCs after
+   STD 3 [RFC1123] and up to the time of this writing were included in
+   the registry upon creation.
+
+   The following pseudo FEAT codes have been assigned, according to
+   Section 2:
+
+      base - FTP standard commands [RFC0959]
+      hist - Historic experimental commands [RFC0775], [RFC1639]
+      secu - FTP Security Extensions [RFC2228]
+      feat - FTP Feature Negotiation [RFC2389]
+      nat6 - FTP Extensions for NAT/IPv6 [RFC2428]
+
+   +-------+------+-------------------+------+------+------------------+
+   | cmd   | FEAT | description       | type | conf | RFC#s/References |
+   |       | Code |                   |      |      | and Notes        |
+   +-------+------+-------------------+------+------+------------------+
+   | ABOR  | base | Abort             | s    | m    | 959              |
+   | ACCT  | base | Account           | a    | m    | 959              |
+   | ADAT  | secu | Authentication/   | a    | o    | 2228, 2773, 4217 |
+   |       |      | Security Data     |      |      |                  |
+   | ALLO  | base | Allocate          | s    | m    | 959              |
+   | APPE  | base | Append (with      | s    | m    | 959              |
+   |       |      | create)           |      |      |                  |
+   | AUTH  | secu | Authentication/   | a    | o    | 2228             |
+   |       |      | Security          |      |      |                  |
+   |       |      | Mechanism         |      |      |                  |
+   | AUTH+ | AUTH | Authentication/   | a    | o    | 2773, 4217 #2    |
+   |       |      | Security          |      |      |                  |
+   |       |      | Mechanism         |      |      |                  |
+   | CCC   | secu | Clear Command     | a    | o    | 2228             |
+   |       |      | Channel           |      |      |                  |
+   | CDUP  | base | Change to Parent  | a    | o    | 959              |
+   |       |      | Directory         |      |      |                  |
+   | CONF  | secu | Confidentiality   | a    | o    | 2228             |
+   |       |      | Protected Command |      |      |                  |
+   | CWD   | base | Change Working    | a    | m    | 959              |
+   |       |      | Directory         |      |      |                  |
+   | DELE  | base | Delete File       | s    | m    | 959              |
+   | ENC   | secu | Privacy Protected | a    | o    | 2228, 2773, 4217 |
+   |       |      | Command           |      |      |                  |
+   | EPRT  | nat6 | Extended Port     | p    | o    | 2428             |
+   | EPSV  | nat6 | Extended Passive  | p    | o    | 2428             |
+   |       |      | Mode              |      |      |                  |
+
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 6]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+   | FEAT  | feat | Feature           | a    | m #1 | 2389             |
+   |       |      | Negotiation       |      |      |                  |
+   | HELP  | base | Help              | s    | m    | 959              |
+   | LANG  | UTF8 | Language (for     | p    | o    | 2640             |
+   |       |      | Server Messages)  |      |      |                  |
+   | LIST  | base | List              | s    | m    | 959, 1123        |
+   | LPRT  | hist | Data Port         | p    | h    | 1545, 1639       |
+   |       |      | {FOOBAR}          |      |      |                  |
+   | LPSV  | hist | Passive Mode      | p    | h    | 1545, 1639       |
+   |       |      | {FOOBAR}          |      |      |                  |
+   | MDTM  | MDTM | File Modification | s    | o    | 3659             |
+   |       |      | Time              |      |      |                  |
+   | MIC   | secu | Integrity         | a    | o    | 2228, 2773, 4217 |
+   |       |      | Protected Command |      |      |                  |
+   | MKD   | base | Make Directory    | s    | o    | 959              |
+   | MLSD  | MLST | List Directory    | s    | o    | 3659             |
+   |       |      | (for machine)     |      |      |                  |
+   | MLST  | MLST | List Single       | s    | o    | 3659             |
+   |       |      | Object            |      |      |                  |
+   | MODE  | base | Transfer Mode     | p    | m    | 959              |
+   | NLST  | base | Name List         | s    | m    | 959, 1123        |
+   | NOOP  | base | No-Op             | s    | m    | 959              |
+   | OPTS  | feat | Options           | p    | m #1 | 2389             |
+   | PASS  | base | Password          | a    | m    | 959              |
+   | PASV  | base | Passive Mode      | p    | m    | 959, 1123        |
+   | PBSZ  | secu | Protection Buffer | p    | o    | 2228             |
+   |       |      | Size              |      |      |                  |
+   | PBSZ+ | PBSZ | Protection Buffer | p    | o    | 4217             |
+   |       |      | Size              |      |      |                  |
+   | PORT  | base | Data Port         | p    | m    | 959              |
+   | PROT  | secu | Data Channel      | p    | o    | 2228             |
+   |       |      | Protection Level  |      |      |                  |
+   | PROT+ | PROT | Data Channel      | p    | o    | 4217             |
+   |       |      | Protection Level  |      |      |                  |
+   | PWD   | base | Print Directory   | s    | o    | 959              |
+   | QUIT  | base | Logout            | a    | m    | 959              |
+   | REIN  | base | Reinitialize      | a    | m    | 959              |
+   | REST  | base | Restart           | s/p  | m    | 959, 1123        |
+   | REST+ | REST | Restart (for      | s/p  | m    | 3659 #3          |
+   |       |      | STREAM mode)      |      |      |                  |
+   | RETR  | base | Retrieve          | s    | m    | 959              |
+   | RMD   | base | Remove Directory  | s    | o    | 959              |
+   | RNFR  | base | Rename From       | s/p  | m    | 959              |
+   | RNTO  | base | Rename From       | s    | m    | 959              |
+   | SITE  | base | Site Parameters   | s    | m    | 959, 1123        |
+   | SIZE  | SIZE | File Size         | s    | o    | 3659             |
+   | SMNT  | base | Structure Mount   | a    | o    | 959              |
+   | STAT  | base | Status            | s    | m    | 959              |
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 7]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+   | STOR  | base | Store             | s    | m    | 959              |
+   | STOU  | base | Store Unique      | a    | o    | 959, 1123        |
+   | STRU  | base | File Structure    | p    | m    | 959              |
+   | SYST  | base | System            | s    | o    | 959              |
+   | TYPE  | base | Representation    | p    | m    | 959 #4           |
+   |       |      | Type              |      |      |                  |
+   | USER  | base | User Name         | a    | m    | 959              |
+   | XCUP  | hist | {precursor for    | s    | h    | 775, 1123        |
+   |       |      | CDUP}             |      |      |                  |
+   | XCWD  | hist | {precursor for    | s    | h    | 775, 1123        |
+   |       |      | CWD}              |      |      |                  |
+   | XMKD  | hist | {precursor for    | s    | h    | 775, 1123        |
+   |       |      | MKD}              |      |      |                  |
+   | XPWD  | hist | {precursor for    | s    | h    | 775, 1123        |
+   |       |      | PWD}              |      |      |                  |
+   | XRMD  | hist | {precursor for    | s    | h    | 775, 1123        |
+   |       |      | RMD}              |      |      |                  |
+   | -N/A- | TVFS | Trivial Virtual   | p    | o    | 3659             |
+   |       |      | File Store        |      |      |                  |
+   +-------+------+-------------------+------+------+------------------+
+
+                                  Table 1
+
+   Notes:
+   #1 While an IETF Standards Action would be required to make the FEAT
+      mechanism [RFC2389] mandatory, implementation of that extension
+      mechanism is clearly required in conjunction with any extension or
+      feature that depends on it.
+   #2 FEAT String for [RFC4217]: AUTH TLS
+      FEAT String for [RFC2773]: AUTH KEA-SKIPJACK
+   #3 FEAT String: REST STREAM
+   #4 FEAT String: TYPE {semicolon-separated list of supported types}
+
+4.  Acknowledgments
+
+   Any work to update or extend FTP depends on the base specification in
+   RFC 959.  The contributions of its editors, Jon Postel and Joyce
+   Reynolds, are gratefully acknowledged.  The option-negotiation
+   mechanism specified in RFC 2389 (and the accumulation of features
+   that followed it) made this registry relevant; the authors of those
+   documents are acknowledged as well.
+
+   Barry Leiba and Alexey Melnikov made several suggestions about
+   earlier versions of this document, most of which have been
+   incorporated.
+
+   Anthony Bryan spotted a few typographical errors.
+
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 8]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+   Scott Bradner suggested a clarification to the "Expert Review" text.
+
+   The authors appreciate the comments and support for this work
+   received from FTP implementers and many IETF participants.  Comments
+   from the IESG helped to shape this document and registry to improve
+   its utility.
+
+5.  IANA Considerations
+
+   IANA has established the registry described in Section 2 using the
+   initial content specified in Section 3 and including the body of
+   Sections 2.4 and 2.5 as explanatory text in the preface of the
+   registry.
+
+   New entries should be added to this registry when extensions to FTP
+   are approved or defined in RFCs or when extensions that are already
+   in use and well-documented are identified.  In other words, the
+   requirement for registration is a slightly relaxed version of
+   "Specification Required" [RFC5226] with Expert Review.  See
+   Section 2.3 for specifics and exceptions.
+
+6.  Security Considerations
+
+   The creation of this registry provides improved documentation and
+   protection against interoperability problems.  It introduces no new
+   security issues.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
+              STD 9, RFC 959, October 1985.
+
+   [RFC2389]  Hethmon, P. and R. Elz, "Feature negotiation mechanism for
+              the File Transfer Protocol", RFC 2389, August 1998.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+7.2.  Informative References
+
+   [RFC0775]  Mankins, D., Franklin, D., and A. Owen, "Directory
+              oriented FTP commands", RFC 775, December 1980.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+
+
+Klensin & Hoenes             Standards Track                    [Page 9]
+
+RFC 5797           FTP Command and Extension Registry         March 2010
+
+
+   [RFC1545]  Piscitello, D., "FTP Operation Over Big Address Records
+              (FOOBAR)", RFC 1545, November 1993.
+
+   [RFC1639]  Piscitello, D., "FTP Operation Over Big Address Records
+              (FOOBAR)", RFC 1639, June 1994.
+
+   [RFC2228]  Horowitz, M., "FTP Security Extensions", RFC 2228,
+              October 1997.
+
+   [RFC2428]  Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
+              for IPv6 and NATs", RFC 2428, September 1998.
+
+   [RFC2773]  Housley, R. and P. Yee, "Encryption using KEA and
+              SKIPJACK", RFC 2773, February 2000.
+
+   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
+              October 2005.
+
+Authors' Addresses
+
+   John C Klensin
+   1770 Massachusetts Ave, Ste 322
+   Cambridge, MA  02140
+   USA
+
+   Phone: +1 617 245 1457
+   EMail: john+ietf@jck.com
+
+
+   Alfred Hoenes
+   TR-Sys
+   Gerlinger Str. 12
+   Ditzingen  D-71254
+   Germany
+
+   EMail: ah@TR-Sys.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin & Hoenes             Standards Track                   [Page 10]
+