[1] RFC1892 と RFC3462 の差異です。 頁付けとか字下げとかの編集上の差異は省略しています。

「which」が「that」になった箇所もありましたが、これも省略しました。

  Network Working Group                                       G. Vaudreuil
 -Request for Comments: 1892                        Octel Network Services
 -Category: Standards Track                                   January 1996
 +Request for Comments: 3462                           Lucent Technologies
 +Obsoletes: 1892                                             January 2003
 +Category: Standards Track

+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Multipart/Report Multipurpose Internet Mail Extensions (MIME)
+   content-type is a general "family" or "container" type for electronic
+   mail reports of any kind.  Although this memo defines only the use of
+   the Multipart/Report content-type with respect to delivery status
+   reports, mail processing programs will benefit if a single content-
+   type is used to for all kinds of reports.
+
+   This document is part of a four document set describing the delivery
+   status report service.  This collection includes the Simple Mail
+   Transfer Protocol (SMTP) extensions to request delivery status
+   reports, a MIME content for the reporting of delivery reports, an
+   enumeration of extended status codes, and a multipart container for
+   the delivery report, the original message, and a human-friendly
+   summary of the failure.

「Table of Contents」追加

「Document Conventions」追加

1. The Multipart/Report MIME content-type

 
@@

When 8-bit or binary data not encoded in 7 bits a 7 bit form is to be returned, and the return path is not guaranteed to be 8-bit or binary capable, two options are available. The origional message MAY be reencoded into a legal 7-bit MIME message or the Text/RFC822-Headers content-type MAY be used to return only the origional message headers.

2. The Text/RFC822-Headers MIME content-type

 
The Text/RFC822-Headers MIME content-type provides a mechanism to
label and return only the RFC 822 headers of a failed message.  These
headers are not the complete message and should not be returned as a
Message/RFC822.  The returned headers are useful for identifying the
failed message and for diagnostics based on the received: lines.

Encoding considerations

7 bit is sufficient for normal RFC822 headers, however, if the headers are broken and require encoding to make them legal 7 bit content, they may be encoded in quoted-printable.

The Text/RFC822-hHeaders body part should contain all the RFC822 header lines from the message which caused the report. The RFC822 headers include all lines prior to the blank line in the message. They include the MIME-Version and MIME Content- hHeaders.

「Security Considerations」は第4章から第3章に変更。

 
@@

 
「3. References」は「4. Normative References」に変更。

(以下変更のあるもののみ。一部新旧 RFC で順序変更あり。)

[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, University of Tennessee, Octel Network Services, January 1996 RFC 3464, January 2003.

[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 1521, Bellcore, Innosoft, June 1992 RFC 2046, November 1996.

[DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, University of Tennessee, January 1996 RFC 3461, January 2003.

「5. Author's Address」→「Author's Address」

 
Gregory M. Vaudreuil

Octel Network Services
17060 Dallas Parkway
Dallas, TX 75248-1905

Phone: +1-214-733-2722 EMail: Greg.Vaudreuil@Octel.com

Lucent Technologies 7291 Williamson Rd Dallas Tx, 75214

Phone: +1 214 823 9325 EMail: GregV@ieee.org

「Full Copyright Statement」追加 (RFCのライセンス参照)

「Acknowledgement」追加