summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3463.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3463.txt')
-rw-r--r--doc/rfc/rfc3463.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3463.txt b/doc/rfc/rfc3463.txt
new file mode 100644
index 0000000..5544b2c
--- /dev/null
+++ b/doc/rfc/rfc3463.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 3463 Lucent Technologies
+Obsoletes: 1893 January 2003
+Category: Standards Track
+
+
+ Enhanced Mail System Status Codes
+
+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 (2003). All Rights Reserved.
+
+Abstract
+
+ This document defines a set of extended status codes for use within
+ the mail system for delivery status reports, tracking, and improved
+ diagnostics. In combination with other information provided in the
+ Delivery Status Notification (DSN) delivery report, these codes
+ facilitate media and language independent rendering of message
+ delivery status.
+
+Table of Contents
+
+ 1. Overview ......................................................2
+ 2. Status Code Structure .........................................3
+ 3. Enumerated Status Codes .......................................5
+ 3.1 Other or Undefined Status ...................................6
+ 3.2 Address Status ..............................................6
+ 3.3 Mailbox Status ..............................................7
+ 3.4 Mail system status ..........................................8
+ 3.5 Network and Routing Status ..................................9
+ 3.6 Mail Delivery Protocol Status ..............................10
+ 3.7 Message Content or Message Media Status ....................11
+ 3.8 Security or Policy Status ..................................12
+ 4. References ...................................................13
+ 5. Security Considerations ......................................13
+ Appendix A - Collected Status Codes ..........................14
+ Appendix B - Changes from RFC1893 ............................15
+ Author's Address .............................................15
+ Full Copyright Statement .....................................16
+
+
+
+Vaudreuil Standards Track [Page 1]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+1. Overview
+
+ There is a need for a standard mechanism for the reporting of mail
+ system errors richer than the limited set offered by SMTP and the
+ system specific text descriptions sent in mail messages. There is a
+ pressing need for a rich machine-readable, human language independent
+ status code for use in delivery status notifications [DSN]. This
+ document proposes a new set of status codes for this purpose.
+
+ SMTP [SMTP] error codes have historically been used for reporting
+ mail system errors. Because of limitations in the SMTP code design,
+ these are not suitable for use in delivery status notifications.
+ SMTP provides about 12 useful codes for delivery reports. The
+ majority of the codes are protocol specific response codes such as
+ the 354 response to the SMTP data command. Each of the 12 useful
+ codes are overloaded to indicate several error conditions. SMTP
+ suffers some scars from history, most notably the unfortunate damage
+ to the reply code extension mechanism by uncontrolled use. This
+ proposal facilitates future extensibility by requiring the client to
+ interpret unknown error codes according to the theory of codes while
+ requiring servers to register new response codes.
+
+ The SMTP theory of reply codes are partitioned in the number space in
+ such a manner that the remaining available codes will not provide the
+ space needed. The most critical example is the existence of only 5
+ remaining codes for mail system errors. The mail system
+ classification includes both host and mailbox error conditions. The
+ remaining third digit space would be completely consumed as needed to
+ indicate MIME and media conversion errors and security system errors.
+
+ A revision to the SMTP theory of reply codes to better distribute the
+ error conditions in the number space will necessarily be incompatible
+ with SMTP. Further, consumption of the remaining reply-code number
+ space for delivery notification reporting will reduce the available
+ codes for new ESMTP extensions.
+
+ The following status code set is based on the SMTP theory of reply
+ codes. It adopts the success, permanent error, and transient error
+ semantics of the first value, with a further description and
+ classification in the second. This proposal re-distributes the
+ classifications to better distribute the error conditions, such as
+ separating mailbox from host errors.
+
+ Document Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+
+Vaudreuil Standards Track [Page 2]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+2. Status Code Structure
+
+ This document defines a new set of status codes to report mail system
+ conditions. These status codes are used for media and language
+ independent status reporting. They are not intended for system
+ specific diagnostics.
+
+ The syntax of the new status codes is defined as:
+
+ status-code = class "." subject "." detail
+
+ class = "2"/"4"/"5"
+
+ subject = 1*3digit
+
+ detail = 1*3digit
+
+ White-space characters and comments are NOT allowed within a status-
+ code. Each numeric sub-code within the status-code MUST be expressed
+ without leading zero digits.
+
+ Status codes consist of three numerical fields separated by ".". The
+ first sub-code indicates whether the delivery attempt was successful.
+ The second sub-code indicates the probable source of any delivery
+ anomalies, and the third sub-code indicates a precise error
+ condition.
+
+ Example: 2.1.23
+
+ The code space defined is intended to be extensible only by standards
+ track documents. Mail system specific status codes should be mapped
+ as close as possible to the standard status codes. Servers should
+ send only defined, registered status codes. System specific errors
+ and diagnostics should be carried by means other than status codes.
+
+ New subject and detail codes will be added over time. Because the
+ number space is large, it is not intended that published status codes
+ will ever be redefined or eliminated. Clients should preserve the
+ extensibility of the code space by reporting the general error
+ described in the subject sub-code when the specific detail is
+ unrecognized.
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 3]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ The class sub-code provides a broad classification of the status.
+ The enumerated values for each class are defined as:
+
+ 2.XXX.XXX Success
+
+ Success specifies that the DSN is reporting a positive delivery
+ action. Detail sub-codes may provide notification of
+ transformations required for delivery.
+
+ 4.XXX.XXX Persistent Transient Failure
+
+ A persistent transient failure is one in which the message as
+ sent is valid, but persistence of some temporary condition has
+ caused abandonment or delay of attempts to send the message.
+ If this code accompanies a delivery failure report, sending in
+ the future may be successful.
+
+ 5.XXX.XXX Permanent Failure
+
+ A permanent failure is one which is not likely to be resolved
+ by resending the message in the current form. Some change to
+ the message or the destination must be made for successful
+ delivery.
+
+ A client must recognize and report class sub-code even where
+ subsequent subject sub-codes are unrecognized.
+
+ The subject sub-code classifies the status. This value applies to
+ each of the three classifications. The subject sub-code, if
+ recognized, must be reported even if the additional detail provided
+ by the detail sub-code is not recognized. The enumerated values for
+ the subject sub-code are:
+
+ X.0.XXX Other or Undefined Status
+
+ There is no additional subject information available.
+
+ X.1.XXX Addressing Status
+
+ The address status reports on the originator or destination
+ address. It may include address syntax or validity. These
+ errors can generally be corrected by the sender and retried.
+
+ X.2.XXX Mailbox Status
+
+ Mailbox status indicates that something having to do with the
+ mailbox has caused this DSN. Mailbox issues are assumed to be
+ under the general control of the recipient.
+
+
+
+Vaudreuil Standards Track [Page 4]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.3.XXX Mail System Status
+
+ Mail system status indicates that something having to do with
+ the destination system has caused this DSN. System issues are
+ assumed to be under the general control of the destination
+ system administrator.
+
+ X.4.XXX Network and Routing Status
+
+ The networking or routing codes report status about the
+ delivery system itself. These system components include any
+ necessary infrastructure such as directory and routing
+ services. Network issues are assumed to be under the control
+ of the destination or intermediate system administrator.
+
+ X.5.XXX Mail Delivery Protocol Status
+
+ The mail delivery protocol status codes report failures
+ involving the message delivery protocol. These failures
+ include the full range of problems resulting from
+ implementation errors or an unreliable connection.
+
+ X.6.XXX Message Content or Media Status
+
+ The message content or media status codes report failures
+ involving the content of the message. These codes report
+ failures due to translation, transcoding, or otherwise
+ unsupported message media. Message content or media issues are
+ under the control of both the sender and the receiver, both of
+ which must support a common set of supported content-types.
+
+ X.7.XXX Security or Policy Status
+
+ The security or policy status codes report failures involving
+ policies such as per-recipient or per-host filtering and
+ cryptographic operations. Security and policy status issues
+ are assumed to be under the control of either or both the
+ sender and recipient. Both the sender and recipient must
+ permit the exchange of messages and arrange the exchange of
+ necessary keys and certificates for cryptographic operations.
+
+3. Enumerated Status Codes
+
+ The following section defines and describes the detail sub-code. The
+ detail value provides more information about the status and is
+ defined relative to the subject of the status.
+
+
+
+
+
+Vaudreuil Standards Track [Page 5]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+3.1 Other or Undefined Status
+
+ X.0.0 Other undefined Status
+
+ Other undefined status is the only undefined error code. It
+ should be used for all errors for which only the class of the
+ error is known.
+
+3.2 Address Status
+
+ X.1.0 Other address status
+
+ Something about the address specified in the message caused
+ this DSN.
+
+ X.1.1 Bad destination mailbox address
+
+ The mailbox specified in the address does not exist. For
+ Internet mail names, this means the address portion to the left
+ of the "@" sign is invalid. This code is only useful for
+ permanent failures.
+
+ X.1.2 Bad destination system address
+
+ The destination system specified in the address does not exist
+ or is incapable of accepting mail. For Internet mail names,
+ this means the address portion to the right of the "@" is
+ invalid for mail. This code is only useful for permanent
+ failures.
+
+ X.1.3 Bad destination mailbox address syntax
+
+ The destination address was syntactically invalid. This can
+ apply to any field in the address. This code is only useful
+ for permanent failures.
+
+ X.1.4 Destination mailbox address ambiguous
+
+ The mailbox address as specified matches one or more recipients
+ on the destination system. This may result if a heuristic
+ address mapping algorithm is used to map the specified address
+ to a local mailbox name.
+
+ X.1.5 Destination address valid
+
+ This mailbox address as specified was valid. This status code
+ should be used for positive delivery reports.
+
+
+
+
+Vaudreuil Standards Track [Page 6]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.1.6 Destination mailbox has moved, No forwarding address
+
+ The mailbox address provided was at one time valid, but mail is
+ no longer being accepted for that address. This code is only
+ useful for permanent failures.
+
+ X.1.7 Bad sender's mailbox address syntax
+
+ The sender's address was syntactically invalid. This can apply
+ to any field in the address.
+
+ X.1.8 Bad sender's system address
+
+ The sender's system specified in the address does not exist or
+ is incapable of accepting return mail. For domain names, this
+ means the address portion to the right of the "@" is invalid
+ for mail.
+
+3.3 Mailbox Status
+
+ X.2.0 Other or undefined mailbox status
+
+ The mailbox exists, but something about the destination mailbox
+ has caused the sending of this DSN.
+
+ X.2.1 Mailbox disabled, not accepting messages
+
+ The mailbox exists, but is not accepting messages. This may be
+ a permanent error if the mailbox will never be re-enabled or a
+ transient error if the mailbox is only temporarily disabled.
+
+ X.2.2 Mailbox full
+
+ The mailbox is full because the user has exceeded a per-mailbox
+ administrative quota or physical capacity. The general
+ semantics implies that the recipient can delete messages to
+ make more space available. This code should be used as a
+ persistent transient failure.
+
+ X.2.3 Message length exceeds administrative limit
+
+ A per-mailbox administrative message length limit has been
+ exceeded. This status code should be used when the per-mailbox
+ message length limit is less than the general system limit.
+ This code should be used as a permanent failure.
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 7]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.2.4 Mailing list expansion problem
+
+ The mailbox is a mailing list address and the mailing list was
+ unable to be expanded. This code may represent a permanent
+ failure or a persistent transient failure.
+
+3.4 Mail system status
+
+ X.3.0 Other or undefined mail system status
+
+ The destination system exists and normally accepts mail, but
+ something about the system has caused the generation of this
+ DSN.
+
+ X.3.1 Mail system full
+
+ Mail system storage has been exceeded. The general semantics
+ imply that the individual recipient may not be able to delete
+ material to make room for additional messages. This is useful
+ only as a persistent transient error.
+
+ X.3.2 System not accepting network messages
+
+ The host on which the mailbox is resident is not accepting
+ messages. Examples of such conditions include an immanent
+ shutdown, excessive load, or system maintenance. This is
+ useful for both permanent and persistent transient errors.
+
+ X.3.3 System not capable of selected features
+
+ Selected features specified for the message are not supported
+ by the destination system. This can occur in gateways when
+ features from one domain cannot be mapped onto the supported
+ feature in another.
+
+ X.3.4 Message too big for system
+
+ The message is larger than per-message size limit. This limit
+ may either be for physical or administrative reasons. This is
+ useful only as a permanent error.
+
+ X.3.5 System incorrectly configured
+
+ The system is not configured in a manner that will permit it to
+ accept this message.
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 8]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+3.5 Network and Routing Status
+
+ X.4.0 Other or undefined network or routing status
+
+ Something went wrong with the networking, but it is not clear
+ what the problem is, or the problem cannot be well expressed
+ with any of the other provided detail codes.
+
+ X.4.1 No answer from host
+
+ The outbound connection attempt was not answered, because
+ either the remote system was busy, or was unable to take a
+ call. This is useful only as a persistent transient error.
+
+ X.4.2 Bad connection
+
+ The outbound connection was established, but was unable to
+ complete the message transaction, either because of time-out,
+ or inadequate connection quality. This is useful only as a
+ persistent transient error.
+
+ X.4.3 Directory server failure
+
+ The network system was unable to forward the message, because a
+ directory server was unavailable. This is useful only as a
+ persistent transient error.
+
+ The inability to connect to an Internet DNS server is one
+ example of the directory server failure error.
+
+ X.4.4 Unable to route
+
+ The mail system was unable to determine the next hop for the
+ message because the necessary routing information was
+ unavailable from the directory server. This is useful for both
+ permanent and persistent transient errors.
+
+ A DNS lookup returning only an SOA (Start of Administration)
+ record for a domain name is one example of the unable to route
+ error.
+
+ X.4.5 Mail system congestion
+
+ The mail system was unable to deliver the message because the
+ mail system was congested. This is useful only as a persistent
+ transient error.
+
+
+
+
+
+Vaudreuil Standards Track [Page 9]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.4.6 Routing loop detected
+
+ A routing loop caused the message to be forwarded too many
+ times, either because of incorrect routing tables or a user-
+ forwarding loop. This is useful only as a persistent transient
+ error.
+
+ X.4.7 Delivery time expired
+
+ The message was considered too old by the rejecting system,
+ either because it remained on that host too long or because the
+ time-to-live value specified by the sender of the message was
+ exceeded. If possible, the code for the actual problem found
+ when delivery was attempted should be returned rather than this
+ code.
+
+3.6 Mail Delivery Protocol Status
+
+ X.5.0 Other or undefined protocol status
+
+ Something was wrong with the protocol necessary to deliver the
+ message to the next hop and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.5.1 Invalid command
+
+ A mail transaction protocol command was issued which was either
+ out of sequence or unsupported. This is useful only as a
+ permanent error.
+
+ X.5.2 Syntax error
+
+ A mail transaction protocol command was issued which could not
+ be interpreted, either because the syntax was wrong or the
+ command is unrecognized. This is useful only as a permanent
+ error.
+
+ X.5.3 Too many recipients
+
+ More recipients were specified for the message than could have
+ been delivered by the protocol. This error should normally
+ result in the segmentation of the message into two, the
+ remainder of the recipients to be delivered on a subsequent
+ delivery attempt. It is included in this list in the event
+ that such segmentation is not possible.
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 10]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.5.4 Invalid command arguments
+
+ A valid mail transaction protocol command was issued with
+ invalid arguments, either because the arguments were out of
+ range or represented unrecognized features. This is useful
+ only as a permanent error.
+
+ X.5.5 Wrong protocol version
+
+ A protocol version mis-match existed which could not be
+ automatically resolved by the communicating parties.
+
+3.7 Message Content or Message Media Status
+
+ X.6.0 Other or undefined media error
+
+ Something about the content of a message caused it to be
+ considered undeliverable and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.6.1 Media not supported
+
+ The media of the message is not supported by either the
+ delivery protocol or the next system in the forwarding path.
+ This is useful only as a permanent error.
+
+ X.6.2 Conversion required and prohibited
+
+ The content of the message must be converted before it can be
+ delivered and such conversion is not permitted. Such
+ prohibitions may be the expression of the sender in the message
+ itself or the policy of the sending host.
+
+ X.6.3 Conversion required but not supported
+
+ The message content must be converted in order to be forwarded
+ but such conversion is not possible or is not practical by a
+ host in the forwarding path. This condition may result when an
+ ESMTP gateway supports 8bit transport but is not able to
+ downgrade the message to 7 bit as required for the next hop.
+
+ X.6.4 Conversion with loss performed
+
+ This is a warning sent to the sender when message delivery was
+ successfully but when the delivery required a conversion in
+ which some data was lost. This may also be a permanent error
+ if the sender has indicated that conversion with loss is
+ prohibited for the message.
+
+
+
+Vaudreuil Standards Track [Page 11]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.6.5 Conversion Failed
+
+ A conversion was required but was unsuccessful. This may be
+ useful as a permanent or persistent temporary notification.
+
+3.8 Security or Policy Status
+
+ X.7.0 Other or undefined security status
+
+ Something related to security caused the message to be
+ returned, and the problem cannot be well expressed with any of
+ the other provided detail codes. This status code may also be
+ used when the condition cannot be further described because of
+ security policies in force.
+
+ X.7.1 Delivery not authorized, message refused
+
+ The sender is not authorized to send to the destination. This
+ can be the result of per-host or per-recipient filtering. This
+ memo does not discuss the merits of any such filtering, but
+ provides a mechanism to report such. This is useful only as a
+ permanent error.
+
+ X.7.2 Mailing list expansion prohibited
+
+ The sender is not authorized to send a message to the intended
+ mailing list. This is useful only as a permanent error.
+
+ X.7.3 Security conversion required but not possible
+
+ A conversion from one secure messaging protocol to another was
+ required for delivery and such conversion was not possible.
+ This is useful only as a permanent error.
+
+ X.7.4 Security features not supported
+
+ A message contained security features such as secure
+ authentication that could not be supported on the delivery
+ protocol. This is useful only as a permanent error.
+
+ X.7.5 Cryptographic failure
+
+ A transport system otherwise authorized to validate or decrypt
+ a message in transport was unable to do so because necessary
+ information such as key was not available or such information
+ was invalid.
+
+
+
+
+
+Vaudreuil Standards Track [Page 12]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.7.6 Cryptographic algorithm not supported
+
+ A transport system otherwise authorized to validate or decrypt
+ a message was unable to do so because the necessary algorithm
+ was not supported.
+
+ X.7.7 Message integrity failure
+
+ A transport system otherwise authorized to validate a message
+ was unable to do so because the message was corrupted or
+ altered. This may be useful as a permanent, transient
+ persistent, or successful delivery code.
+
+4. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
+ for Delivery Status Notifications", RFC 3464, January 2003.
+
+5. Security Considerations
+
+ This document describes a status code system with increased
+ precision. Use of these status codes may disclose additional
+ information about how an internal mail system is implemented beyond
+ that currently available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 13]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+Appendix A - Collected Status Codes
+
+ X.1.0 Other address status
+ X.1.1 Bad destination mailbox address
+ X.1.2 Bad destination system address
+ X.1.3 Bad destination mailbox address syntax
+ X.1.4 Destination mailbox address ambiguous
+ X.1.5 Destination mailbox address valid
+ X.1.6 Mailbox has moved
+ X.1.7 Bad sender's mailbox address syntax
+ X.1.8 Bad sender's system address
+
+ X.2.0 Other or undefined mailbox status
+ X.2.1 Mailbox disabled, not accepting messages
+ X.2.2 Mailbox full
+ X.2.3 Message length exceeds administrative limit.
+ X.2.4 Mailing list expansion problem
+
+ X.3.0 Other or undefined mail system status
+ X.3.1 Mail system full
+ X.3.2 System not accepting network messages
+ X.3.3 System not capable of selected features
+ X.3.4 Message too big for system
+
+ X.4.0 Other or undefined network or routing status
+ X.4.1 No answer from host
+ X.4.2 Bad connection
+ X.4.3 Routing server failure
+ X.4.4 Unable to route
+ X.4.5 Network congestion
+ X.4.6 Routing loop detected
+ X.4.7 Delivery time expired
+
+ X.5.0 Other or undefined protocol status
+ X.5.1 Invalid command
+ X.5.2 Syntax error
+ X.5.3 Too many recipients
+ X.5.4 Invalid command arguments
+ X.5.5 Wrong protocol version
+
+ X.6.0 Other or undefined media error
+ X.6.1 Media not supported
+ X.6.2 Conversion required and prohibited
+ X.6.3 Conversion required but not supported
+ X.6.4 Conversion with loss performed
+ X.6.5 Conversion failed
+
+
+
+
+
+Vaudreuil Standards Track [Page 14]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+ X.7.0 Other or undefined security status
+ X.7.1 Delivery not authorized, message refused
+ X.7.2 Mailing list expansion prohibited
+ X.7.3 Security conversion required but not possible
+ X.7.4 Security features not supported
+ X.7.5 Cryptographic failure
+ X.7.6 Cryptographic algorithm not supported
+ X.7.7 Message integrity failure
+
+Appendix B - Changes from RFC1893
+
+ Changed Authors contact information.
+
+ Updated required standards boilerplate.
+
+ Edited the text to make it spell-checker and grammar checker
+ compliant.
+
+ Modified the text describing the persistent transient failure to more
+ closely reflect current practice and understanding.
+
+ Eliminated the restriction on the X.4.7 codes limiting them to
+ persistent transient errors.
+
+Author's Address
+
+ Gregory M. Vaudreuil
+ Lucent Technologies
+ 7291 Williamson Rd
+ Dallas, Tx. 75214
+
+ Phone: +1 214 823 9325
+ EMail: GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 15]
+
+RFC 3463 Enhanced Mail System Status Codes January 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 16]
+