#?SuikaWiki/0.9 [1] 編集上の差異を除いた [[RFC1893]] と [[RFC3463]] の差分です。 整形が行われているため、単純に [[diff]] しただけでは大量に意味の無い差分が出てきます。 @@ -Network Working Group G. Vaudreuil -Request for Comments: 1893 Octel Network Services -Category: Standards Track January 1996 +Network Working Group G. Vaudreuil +Request for Comments: 3463 Lucent Technologies +Obsoletes: 1893 January 2003 +Category: Standards Track @@ 「Copyright Notice」, 「Abstract」, 「Table of Contents」追加 @@ There [DEL[currently is not]] [INS[is a need for]] a standard mechanism for the reporting of mail system errors [DEL[except for]] [INS[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[INS[-]]readable[INS[,]] [INS[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 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 [DEL[each]] overloaded to indicate several error conditions [DEL[each]]. 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 [INS[are] partitioned in the number space [INS[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 following [DEL[proposal]] [INS[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. [INS[ 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]. ]INS] 2. Status Code[DEL[s]] [INS[Structure]] This document defines a new set of status codes to report mail system conditions. These status codes are [DEL[intended to be used]] [INS[used]] for media and language independent status reporting. They are not intended for system specific diagnostics. @@ [INS[ Example: 2.1.23 ]INS] @@ The class sub-code provides a broad classification of the status. The enumerated values [DEL[the]] [INS[for each]] class are defined as: 2.[INS[XX]]X.[INS[XX]]X Success @@ 4.[INS[XX]]X.[INS[XX]]X Persistent Transient Failure A persistent transient failure is one in which the message as sent is valid, but [INS[persistence of]] some temporary [DEL[event prevents the successful sending of]] [INS[condition has caused abandonment or delay of attempts to send]] the message. [INS[If this code accompanies a delivery failure report,]] Sending in the future may be successful. 5.[INS[XX]]X.[INS[XX]]X Permanent Failure @@ X.0.[INS[XX]X Other or Undefined Status @@ X.1.[INS[XX]]X Addressing Status @@ X.2.[INS[XX]]X Mailbox Status @@ X.3.[INS[XX]]X Mail System Status @@ X.4.[INS[XX]]X Network and Routing Status @@ X.5.[INS[XX]]X 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. [DEL[Mail delivery protocol issues may be controlled by many parties including the originating system, destination system, or intermediate system administrators.]] X.6.[INS[XX]]X 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 [DEL[whom]] [INS[which]] must support a common set of supported content-types. X.7.[INS[XX]]X Security or Policy Status @@ The outbound connection was established, but was [DEL[otherwise]] unable to complete the message transaction, either because of time-out, or inadequate connection quality. This is useful only as a persistent transient error. @@ A routing loop caused the message to be forwarded too many times, either because of incorrect routing tables or a user[INS[-]]forwarding loop. This is useful only as a persistent transient error. @@ 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. [DEL[This is useful only as a persistent transient error.]] @@ The message content must be converted [INS[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. @@ 4. [INS[Normative]] References [INS[ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ]INS] [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, [DEL[USC/Information Sciences Institute,]] August 1982. [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", [DEL[RFC 1894, University of Tennessee, Octel Network Services, January 1996]] [INS[RFC 3464, January 2003]]. @@ [DEL[ 6. Acknowledgments The author wishes to offer special thanks to Harald Alvestrand, Marko Kaittola, and Keith Moore for their extensive review and constructive suggestions. ]DEL] @@ [DEL[8. ]] Appendix [INS[A]] - Collected Status Codes @@ [INS[ 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. @@ [DEL[7. ]] Author's Address (附属書の前から後に移動) Gregory M. Vaudreuil [DEL[ Octel Network Services 17060 Dallas Parkway Suite 214 Dallas, TX 75248-1905 Voice/Fax: +1-214-733-2722 EMail: Greg.Vaudreuil@Octel.com ]DEL] [INS[ Lucent Technologies 7291 Williamson Rd Dallas, Tx. 75214 Phone: +1 214 823 9325 EMail: GregV@ieee.org ]INS] @@ 「Full Copyright Statement」 ([[RFCのライセンス]]参照) 追加, 「Acknowledgement」追加