RFC2389 日本語訳

Network Working Group                                         P. Hethmon
Request for Comments: 2389                              Hethmon Brothers
See Also: 959                                                     R. Elz
Category: Standards Track                        University of Melbourne
                                                             August 1998

Network Working Group P. Hethmon Request for Comments: 2389 Hethmon Brothers See Also: 959 R. Elz Category: Standards Track University of Melbourne August 1998

      Feature negotiation mechanism for the File Transfer Protocol

Feature negotiation mechanism for the File Transfer Protocol

Status of this Memo

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.

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

Abstract

   The File Transfer Protocol is, from time to time, extended with new
   commands, or facilities.  Implementations of the FTP protocol cannot
   be assumed to all immediately implement all newly defined mechanisms.
   This document provides a mechanism by which clients of the FTP
   protocol can discover which new features are supported by a
   particular FTP server.

The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms. This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server.

Hethmon & Elz               Standards Track                     [Page 1]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 1]  RFC 2389 Feature negotiation mechanism August 1998

Table of Contents

Table of Contents

          Abstract  ................................................   1
    1     Introduction  ............................................   2
    2     Document Conventions  ....................................   2
    2.1   Basic Tokens  ............................................   3
    2.2   Server Replies  ..........................................   3
    3     Knowledge of Extra Capabilities - the FEAT Command  ......   3
    3.1   Feature (FEAT) Command Syntax  ...........................   4
    3.2   FEAT Command Responses  ..................................   4
    3.3   Rationale for FEAT  ......................................   6
    4     The OPTS Command  ........................................   6
    5     Security Considerations  .................................   7
    6     References  ..............................................   8
          Acknowledgements  ........................................   8
          Editors' Addresses  ......................................   8
          Full Copyright Statement  ................................   9

Abstract ................................................ 1 1 Introduction ............................................ 2 2 Document Conventions .................................... 2 2.1 Basic Tokens ............................................ 3 2.2 Server Replies .......................................... 3 3 Knowledge of Extra Capabilities - the FEAT Command ...... 3 3.1 Feature (FEAT) Command Syntax ........................... 4 3.2 FEAT Command Responses .................................. 4 3.3 Rationale for FEAT ...................................... 6 4 The OPTS Command ........................................ 6 5 Security Considerations ................................. 7 6 References .............................................. 8 Acknowledgements ........................................ 8 Editors' Addresses ...................................... 8 Full Copyright Statement ................................ 9

1. Introduction

1. Introduction

   This document amends the File Transfer Protocol (FTP) [1].  Two new
   commands are added: "FEAT" and "OPTS".

This document amends the File Transfer Protocol (FTP) [1]. Two new commands are added: "FEAT" and "OPTS".

   These commands allow a client to discover which optional commands a
   server supports, and how they are supported, and to select among
   various options that any FTP command may support.

These commands allow a client to discover which optional commands a server supports, and how they are supported, and to select among various options that any FTP command may support.

2. Document Conventions

2. Document Conventions

   This document makes use of the document conventions defined in BCP14
   [2].  That provides the interpretation of some capitalized words like
   MUST, SHOULD, etc.

This document makes use of the document conventions defined in BCP14 [2]. That provides the interpretation of some capitalized words like MUST, SHOULD, etc.

   Terms defined in [1] will be used here as defined there.  These
   include ASCII, reply, server-FTP process, user-FTP process, server-
   PI, user-PI, and user.

Terms defined in [1] will be used here as defined there. These include ASCII, reply, server-FTP process, user-FTP process, server- PI, user-PI, and user.

   Syntax required is defined using the Augmented BNF defined in [3].
   Some general ABNF definitions are required throughout the document,
   those will be defined here.  At first reading, it may be wise to
   simply recall that these definitions exist here, and skip to the next
   section.

Syntax required is defined using the Augmented BNF defined in [3]. Some general ABNF definitions are required throughout the document, those will be defined here. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section.

Hethmon & Elz               Standards Track                     [Page 2]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 2]  RFC 2389 Feature negotiation mechanism August 1998

2.1. Basic Tokens

2.1. Basic Tokens

   This document imports the definitions given in Appendix A of [3].
   There definitions will be found for basic ABNF elements like ALPHA,
   DIGIT, VCHAR, SP, etc.  To that, the following terms are added for
   use in this document.

This document imports the definitions given in Appendix A of [3]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, VCHAR, SP, etc. To that, the following terms are added for use in this document.

        TCHAR          = VCHAR / SP / HTAB    ; visible plus white space

TCHAR = VCHAR / SP / HTAB ; visible plus white space

   The TCHAR type, and VCHAR from [3], give basic character types from
   varying sub-sets of the ASCII character set for use in various
   commands and responses.

The TCHAR type, and VCHAR from [3], give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses.

        error-response = error-code SP *TCHAR CRLF
        error-code     = ("4" / "5") 2DIGIT

error-response = error-code SP *TCHAR CRLF error-code = ("4" / "5") 2DIGIT

   Note that in ABNF, strings literals are case insensitive.  That
   convention is preserved in this document.  However note that ALPHA,
   in particular, is case sensitive, as are VCHAR and TCHAR.

Note that in ABNF, strings literals are case insensitive. That convention is preserved in this document. However note that ALPHA, in particular, is case sensitive, as are VCHAR and TCHAR.

2.2. Server Replies

2.2. Server Replies

   Section 4.2 of [1] defines the format and meaning of replies by the
   server-PI to FTP commands from the user-PI.  Those reply conventions
   are used here without change.  Implementors should note that the ABNF
   syntax (which was not used in [1]) in this document, and other FTP
   related documents, sometimes shows replies using the one line format.
   Unless otherwise explicitly stated, that is not intended to imply
   that multi-line responses are not permitted.  Implementors should
   assume that, unless stated to the contrary, any reply to any FTP
   command (including QUIT) may be of the multiline format described in
   [1].

Section 4.2 of [1] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change. Implementors should note that the ABNF syntax (which was not used in [1]) in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may be of the multiline format described in [1].

   Throughout this document, replies will be identified by the three
   digit code that is their first element.  Thus the term "500 Reply"
   means a reply from the server-PI using the three digit code "500".

Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 Reply" means a reply from the server-PI using the three digit code "500".

3. Knowledge of Extra Capabilities - the FEAT Command

3. Knowledge of Extra Capabilities - the FEAT Command

   It is not to be expected that all servers will necessarily support
   all of the new commands defined in all future amendments to the FTP
   protocol.  In order to permit clients to determine which new commands
   are supported by a particular server, without trying each possible
   command, one new command is added to the FTP command repertoire.
   This command requests the server to list all extension commands, or
   extended mechanisms, that it supports.  That is, all defined and
   specified commands and features not defined in [1], or this document,
   must be included in the FEAT command output in the form specified in

It is not to be expected that all servers will necessarily support all of the new commands defined in all future amendments to the FTP protocol. In order to permit clients to determine which new commands are supported by a particular server, without trying each possible command, one new command is added to the FTP command repertoire. This command requests the server to list all extension commands, or extended mechanisms, that it supports. That is, all defined and specified commands and features not defined in [1], or this document, must be included in the FEAT command output in the form specified in

Hethmon & Elz               Standards Track                     [Page 3]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 3]  RFC 2389 Feature negotiation mechanism August 1998

   the document that defines the extension.

the document that defines the extension.

   User-FTP PIs must expect to see, in FEAT command responses, unknown
   features listed.  This is not an error, and simply indicates that the
   server-FTP implementor has seen, and implemented, the specification
   of a new feature that is unknown to the user-FTP.

User-FTP PIs must expect to see, in FEAT command responses, unknown features listed. This is not an error, and simply indicates that the server-FTP implementor has seen, and implemented, the specification of a new feature that is unknown to the user-FTP.

3.1. Feature (FEAT) Command Syntax

3.1. Feature (FEAT) Command Syntax

        feat            = "Feat" CRLF

feat = "Feat" CRLF

   The FEAT command consists solely of the word "FEAT".  It has no
   parameters or arguments.

The FEAT command consists solely of the word "FEAT". It has no parameters or arguments.

3.2. FEAT Command Responses

3.2. FEAT Command Responses

   Where a server-FTP process does not support the FEAT command, it will
   respond to the FEAT command with a 500 or 502 reply.  This is simply
   the normal "unrecognized command" reply that any unknown command
   would elicit.  Errors in the command syntax, such as giving
   parameters, will result in a 501 reply.

Where a server-FTP process does not support the FEAT command, it will respond to the FEAT command with a 500 or 502 reply. This is simply the normal "unrecognized command" reply that any unknown command would elicit. Errors in the command syntax, such as giving parameters, will result in a 501 reply.

   Server-FTP processes that recognize the FEAT command, but implement
   no extended features, and therefore have nothing to report, SHOULD
   respond with the "no-features" 211 reply.  However, as this case is
   practically indistinguishable from a server-FTP that does not
   recognize the FEAT command, a 500 or 502 reply MAY also be used.  The
   "no-features" reply MUST NOT use the multi-line response format,
   exactly one response line is required and permitted.

Server-FTP processes that recognize the FEAT command, but implement no extended features, and therefore have nothing to report, SHOULD respond with the "no-features" 211 reply. However, as this case is practically indistinguishable from a server-FTP that does not recognize the FEAT command, a 500 or 502 reply MAY also be used. The "no-features" reply MUST NOT use the multi-line response format, exactly one response line is required and permitted.

   Replies to the FEAT command MUST comply with the following syntax.
   Text on the first line of the reply is free form, and not
   interpreted, and has no practical use, as this text is not expected
   to be revealed to end users.  The syntax of other reply lines is
   precisely defined, and if present, MUST be exactly as specified.

Replies to the FEAT command MUST comply with the following syntax. Text on the first line of the reply is free form, and not interpreted, and has no practical use, as this text is not expected to be revealed to end users. The syntax of other reply lines is precisely defined, and if present, MUST be exactly as specified.

        feat-response   = error-response / no-features / feature-listing
        no-features     = "211" SP *TCHAR CRLF
        feature-listing = "211-" *TCHAR CRLF
                          1*( SP feature CRLF )
                          "211 End" CRLF
        feature         = feature-label [ SP feature-parms ]
        feature-label   = 1*VCHAR
        feature-parms   = 1*TCHAR

feat-response = error-response / no-features / feature-listing no-features = "211" SP *TCHAR CRLF feature-listing = "211-" *TCHAR CRLF 1*( SP feature CRLF ) "211 End" CRLF feature = feature-label [ SP feature-parms ] feature-label = 1*VCHAR feature-parms = 1*TCHAR

   Note that each feature line in the feature-listing begins with a
   single space.  That space is not optional, nor does it indicate
   general white space.  This space guarantees that the feature line can

Note that each feature line in the feature-listing begins with a single space. That space is not optional, nor does it indicate general white space. This space guarantees that the feature line can

Hethmon & Elz               Standards Track                     [Page 4]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 4]  RFC 2389 Feature negotiation mechanism August 1998

   never be misinterpreted as the end of the feature-listing, but is
   required even where there is no possibility of ambiguity.

never be misinterpreted as the end of the feature-listing, but is required even where there is no possibility of ambiguity.

   Each extension supported must be listed on a separate line to
   facilitate the possible inclusion of parameters supported by each
   extension command.  The feature-label to be used in the response to
   the FEAT command will be specified as each new feature is added to
   the FTP command set.  Often it will be the name of a new command
   added, however this is not required.  In fact it is not required that
   a new feature actually add a new command.  Any parameters included
   are to be specified with the definition of the command concerned.
   That specification shall also specify how any parameters present are
   to be interpreted.

Each extension supported must be listed on a separate line to facilitate the possible inclusion of parameters supported by each extension command. The feature-label to be used in the response to the FEAT command will be specified as each new feature is added to the FTP command set. Often it will be the name of a new command added, however this is not required. In fact it is not required that a new feature actually add a new command. Any parameters included are to be specified with the definition of the command concerned. That specification shall also specify how any parameters present are to be interpreted.

   The feature-label and feature-parms are nominally case sensitive,
   however the definitions of specific labels and parameters specify the
   precise interpretation, and it is to be expected that those
   definitions will usually specify the label and parameters in a case
   independent manner.  Where this is done, implementations are
   recommended to use upper case letters when transmitting the feature
   response.

The feature-label and feature-parms are nominally case sensitive, however the definitions of specific labels and parameters specify the precise interpretation, and it is to be expected that those definitions will usually specify the label and parameters in a case independent manner. Where this is done, implementations are recommended to use upper case letters when transmitting the feature response.

   The FEAT command itself is not included in the list of features
   supported, support for the FEAT command is indicated by return of a
   reply other than a 500 or 502 reply.

The FEAT command itself is not included in the list of features supported, support for the FEAT command is indicated by return of a reply other than a 500 or 502 reply.

   A typical example reply to the FEAT command might be a multiline
   reply of the form:

A typical example reply to the FEAT command might be a multiline reply of the form:

        C> feat
        S> 211-Extensions supported:
        S>  MLST size*;create;modify*;perm;media-type
        S>  SIZE
        S>  COMPRESSION
        S>  MDTM
        S> 211 END

C> feat S> 211-Extensions supported: S> MLST size*;create;modify*;perm;media-type S> SIZE S> COMPRESSION S> MDTM S> 211 END

   The particular extensions shown here are simply examples of what may
   be defined in other places, no particular meaning should be
   attributed to them.  Recall also, that the feature names returned are
   not command names, as such, but simply indications that the server
   possesses some attribute or other.

The particular extensions shown here are simply examples of what may be defined in other places, no particular meaning should be attributed to them. Recall also, that the feature names returned are not command names, as such, but simply indications that the server possesses some attribute or other.

   The order in which the features are returned is of no importance,
   server-FTP processes are not required to implement any particular
   order, or even to consistently return the same order when the command
   is repeated.

The order in which the features are returned is of no importance, server-FTP processes are not required to implement any particular order, or even to consistently return the same order when the command is repeated.

Hethmon & Elz               Standards Track                     [Page 5]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 5]  RFC 2389 Feature negotiation mechanism August 1998

   FTP implementations which support FEAT MUST include in the response
   to the FEAT command all properly documented FTP extensions beyond
   those commands and mechanisms described in RFC959 [1], including any
   which existed before the existence of FEAT.  That is, when a client
   receives a FEAT response from an FTP server, it can assume that the
   only extensions the server supports are those that are listed in the
   FEAT response.

FTP implementations which support FEAT MUST include in the response to the FEAT command all properly documented FTP extensions beyond those commands and mechanisms described in RFC959 [1], including any which existed before the existence of FEAT. That is, when a client receives a FEAT response from an FTP server, it can assume that the only extensions the server supports are those that are listed in the FEAT response.

   User-FTP processes should, however, be aware that there have been
   several FTP extensions developed, and in widespread use, prior to the
   adoption of this document and the FEAT command.  The effect of this
   is that an error response to the FEAT command does not necessarily
   imply that those extensions are not supported by the server-FTP
   process.  User-PIs should test for such extensions individually if an
   error response has been received to the FEAT command.

User-FTP processes should, however, be aware that there have been several FTP extensions developed, and in widespread use, prior to the adoption of this document and the FEAT command. The effect of this is that an error response to the FEAT command does not necessarily imply that those extensions are not supported by the server-FTP process. User-PIs should test for such extensions individually if an error response has been received to the FEAT command.

3.3. Rationale for FEAT

3.3. Rationale for FEAT

   While not absolutely necessary, a standard mechanism for the server-
   PI to inform the user-PI of any features and extensions supported
   will help reduce unnecessary traffic between the user-PI and server-
   PI as more extensions may be introduced in the future.  If no
   mechanism existed for this, a user-FTP process would have to try each
   extension in turn resulting in a series of exchanges between the
   user-PI and server-PI.  Apart from being possibly wasteful, this
   procedure may not always be possible, as issuing of a command just to
   determine if it is supported or not may have some effect that is not
   desired.

While not absolutely necessary, a standard mechanism for the server- PI to inform the user-PI of any features and extensions supported will help reduce unnecessary traffic between the user-PI and server- PI as more extensions may be introduced in the future. If no mechanism existed for this, a user-FTP process would have to try each extension in turn resulting in a series of exchanges between the user-PI and server-PI. Apart from being possibly wasteful, this procedure may not always be possible, as issuing of a command just to determine if it is supported or not may have some effect that is not desired.

4. The OPTS Command

4. The OPTS Command

   The OPTS (options) command allows a user-PI to specify the desired
   behavior of a server-FTP process when another FTP command (the target
   command) is later issued.  The exact behavior, and syntax, will vary
   with the target command indicated, and will be specified with the
   definition of that command.  Where no OPTS behavior is defined for a
   particular command there are no options available for that command.

The OPTS (options) command allows a user-PI to specify the desired behavior of a server-FTP process when another FTP command (the target command) is later issued. The exact behavior, and syntax, will vary with the target command indicated, and will be specified with the definition of that command. Where no OPTS behavior is defined for a particular command there are no options available for that command.

   Request Syntax:
        opts             = opts-cmd SP command-name
                               [ SP command-options ] CRLF
        opts-cmd         = "opts"
        command-name     = <any FTP command which allows option setting>
        command-options  = <format specified by individual FTP command>

Request Syntax: opts = opts-cmd SP command-name [ SP command-options ] CRLF opts-cmd = "opts" command-name = <any FTP command which allows option setting> command-options = <format specified by individual FTP command>

Hethmon & Elz               Standards Track                     [Page 6]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 6]  RFC 2389 Feature negotiation mechanism August 1998

   Response Syntax:
        opts-response    = opts-good / opts-bad
        opts-good        = "200" SP response-message CRLF
        opts-bad         = "451" SP response-message CRLF /
                           "501" SP response-message CRLF
        response-message = *TCHAR

Response Syntax: opts-response = opts-good / opts-bad opts-good = "200" SP response-message CRLF opts-bad = "451" SP response-message CRLF / "501" SP response-message CRLF response-message = *TCHAR

   An "opts-good" response (200 reply) MUST be sent when the command-
   name specified in the OPTS command is recognized, and the command-
   options, if any, are recognized, and appropriate.  An "opts-bad"
   response is sent in other cases.  A 501 reply is appropriate for any
   permanent error.  That is, for any case where simply repeating the
   command at some later time, without other changes of state, will also
   be an error.  A 451 reply should be sent where some temporary
   condition at the server, not related to the state of communications
   between user and server, prevents the command being accepted when
   issued, but where if repeated at some later time, a changed
   environment for the server-FTP process may permit the command to
   succeed.  If the OPTS command itself is not recognized, a 500 or 502
   reply will, of course, result.

An "opts-good" response (200 reply) MUST be sent when the command- name specified in the OPTS command is recognized, and the command- options, if any, are recognized, and appropriate. An "opts-bad" response is sent in other cases. A 501 reply is appropriate for any permanent error. That is, for any case where simply repeating the command at some later time, without other changes of state, will also be an error. A 451 reply should be sent where some temporary condition at the server, not related to the state of communications between user and server, prevents the command being accepted when issued, but where if repeated at some later time, a changed environment for the server-FTP process may permit the command to succeed. If the OPTS command itself is not recognized, a 500 or 502 reply will, of course, result.

   The OPTS command MUST be implemented whenever the FEAT command is
   implemented.  Because of that, there is no indication in the list of
   features returned by FEAT to indicate that the OPTS command itself is
   supported.  Neither the FEAT command, nor the OPTS command, have any
   optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS"
   commands.

The OPTS command MUST be implemented whenever the FEAT command is implemented. Because of that, there is no indication in the list of features returned by FEAT to indicate that the OPTS command itself is supported. Neither the FEAT command, nor the OPTS command, have any optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS" commands.

5. Security Considerations

5. Security Considerations

   No significant new security issues, not already present in the FTP
   protocol, are believed to have been created by this extension.
   However, this extension does provide a mechanism by which users can
   determine the capabilities of an FTP server, and from which
   additional information may be able to be deduced.  While the same
   basic information could be obtained by probing the server for the
   various commands, if the FEAT command were not provided, that method
   may reveal an attacker by logging the attempts to access various
   extension commands.  This possibility is not considered a serious
   enough threat to be worthy of any remedial action.

No significant new security issues, not already present in the FTP protocol, are believed to have been created by this extension. However, this extension does provide a mechanism by which users can determine the capabilities of an FTP server, and from which additional information may be able to be deduced. While the same basic information could be obtained by probing the server for the various commands, if the FEAT command were not provided, that method may reveal an attacker by logging the attempts to access various extension commands. This possibility is not considered a serious enough threat to be worthy of any remedial action.

   The security of any additional features that might be reported by the
   FEAT command, and manipulated by the OPTS command, should be
   addressed where those features are defined.

The security of any additional features that might be reported by the FEAT command, and manipulated by the OPTS command, should be addressed where those features are defined.

Hethmon & Elz               Standards Track                     [Page 7]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 7]  RFC 2389 Feature negotiation mechanism August 1998

6. References

6. References

   [1]  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
        STD 9, RFC 959, October 1985.

[1] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

Acknowledgements

Acknowledgements

   This protocol extension was developed in the FTPEXT Working Group of
   the IETF, and the members of that group are all acknowledged as its
   creators.

This protocol extension was developed in the FTPEXT Working Group of the IETF, and the members of that group are all acknowledged as its creators.

Editors' Addresses

Editors' Addresses

   Paul Hethmon
   Hethmon Brothers
   2305 Chukar Road
   Knoxville, TN 37923 USA

Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville, TN 37923 USA

   Phone: +1 423 690 8990
   Email: phethmon@hethmon.com

Phone: +1 423 690 8990 Email: phethmon@hethmon.com

   Robert Elz
   University of Melbourne
   Department of Computer Science
   Parkville, Vic   3052
   Australia

Robert Elz University of Melbourne Department of Computer Science Parkville, Vic 3052 Australia

   Email: kre@munnari.OZ.AU

Email: kre@munnari.OZ.AU

Hethmon & Elz               Standards Track                     [Page 8]

RFC 2389             Feature negotiation mechanism           August 1998

Hethmon & Elz Standards Track [Page 8]  RFC 2389 Feature negotiation mechanism August 1998

Full Copyright Statement

Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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.

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.

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.

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.

Hethmon & Elz               Standards Track                     [Page 9]

Hethmon & Elz Standards Track [Page 9]