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

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

[PRE[
  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
]PRE]

@@ 

[PRE[
+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.
]PRE]

「Table of Contents」追加

「Document Conventions」追加

@@ 

1. The Multipart/Report [DEL[MIME]] content-type
[PRE[
 
@@
]PRE]

When [INS[8-bit or binary]] data not encoded in [DEL[7 bits]] [INS[a 7 bit form]] is to be returned, and the return
path is not guaranteed to be 8-bit [INS[or binary]] capable, two options are
available.  The origional message MAY be reencoded into a legal 7[INS[-]]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 [DEL[MIME]] content-type
[PRE[
 
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[DEL[:]] lines.
]PRE]

@@ 

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

@@ 

The Text/RFC822-[DEL[h]][INS[H]]eaders 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-[DEL[ h]][INS[H]]eaders.

@@ 

「Security Considerations」は第4章から第3章に変更。
[PRE[
 
@@
]PRE]

[INS[

A signature covering the entire multipart/report structure could be
used to prevent such forgeries; such a signature scheme is, however,
beyond the scope of this document.

そのような偽造を防ぐために [CODE[multipart.report]] 
構造全体を包む署名を使うことも出来ます。
しかし、そのような署名の方法はこの文書の適用範囲外とします。
]INS]

@@ 
[PRE[
 
「3. References」は「4. Normative References」に変更。
]PRE]

@@ 

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

[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]].

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

[INS[

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
]INS]

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

[INS[

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

@@ 

[INS[

Appendix A - Changes from RFC 1892

Changed Authors contact information

Updated required standards boilerplate

Edited the text to make it spell-checker and grammar checker
compliant
]INS]

@@ 

「5. Author's Address」→「Author's Address」
[PRE[
 
Gregory M. Vaudreuil
[DEL[]]
Octel Network Services
17060 Dallas Parkway
Dallas, TX 75248-1905
]PRE]

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

Lucent Technologies
7291 Williamson Rd
Dallas Tx, 75214

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

@@ 

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

「Acknowledgement」追加

@@ 以上
- [2] なんで [[RFC2822]] でなくて [[RFC822]] を参照しているんだろう。