draft-ietf-eai-downgraded-display-01.txt   draft-ietf-eai-downgraded-display-02.txt 
Email Address Internationalization K. Fujiwara Email Address Internationalization K. Fujiwara
(EAI) JPRS (EAI) JPRS
Intended status: Experimental Intended status: Experimental
Expires: September 10, 2009 Expires: March 12, 2010
Displaying Downgraded Messages for Email Address Internationalization Displaying Downgraded Messages for Email Address Internationalization
draft-ietf-eai-downgraded-display-01.txt draft-ietf-eai-downgraded-display-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on March 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes how to display downgraded messages which This document describes a method for displaying downgraded messages
originally contain internationalized E-mail addresses or which originally contained internationalized E-mail addresses or
internationalized header fields. internationalized header fields.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration of displaying downgraded message . . . . . . . . 4 3. Consideration of displaying downgraded message . . . . . . . . 4
4. Displaying downgraded message . . . . . . . . . . . . . . . . 4 4. Displaying downgraded message . . . . . . . . . . . . . . . . 4
5. Security considerations . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 6 8.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7
8.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 6 8.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7
8.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 6 8.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 8.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9
A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Email Address Internationalization (UTF8SMTP) extension document The Email Address Internationalization (UTF8SMTP) extension document
set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address
structure, syntax and Email header format. To avoid bouncing structure, syntax and Email header format. To avoid rejection of
internationalized Email messages, the downgrading mechanism internationalized Email messages, the downgrading mechanism [RFC5504]
[I-D.ietf-eai-downgrade] converts an internationalized message to a converts an internationalized message to a traditional Email message
traditional Email message when a server in the delivery path does not when a server in the delivery path does not support the UTF8SMTP
support the UTF8SMTP extension. The downgraded message is a extension. The downgraded message is a traditional Email message,
traditional Email message, except the message has "Downgraded-" except the message has "Downgraded-" header fields.
header fields.
A perfect reverse-function of the downgrading does not exist because A perfect reverse-function of the downgrading does not exist because
the encoding defined in [RFC2047] is not exactly reversible and the encoding defined in [RFC2047] is not exactly reversible and
Received header field downgrading may remove FOR clause information. Received header field downgrading may remove FOR clause information.
The restoration of the downgrading should be done once at the final The restoration of the downgrading should be done once at the final
destination of the downgraded message such as MUAs or IMAP servers. destination of the downgraded message such as MUAs or IMAP servers.
This document describes the restoration methods as displaying This document describes the restoration methods as displaying
downgraded messages in MUAs. downgraded messages in MUAs.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Specialized terms used in this specification are defined in the EAI Specialized terms used in this specification are defined in the EAI
overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045] overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045]
[RFC2047] [RFC2183] [RFC2231]. [RFC2047] [RFC2183] [RFC2231].
This document depends on [RFC5335] and [I-D.ietf-eai-downgrade]. Key This document depends on [RFC5335] and [RFC5504]. Key words used in
words used in these document are used in this document, too. these document are used in this document, too.
The term "non-ASCII" is an UTF-8 string which contains at least one The term "non-ASCII" is an UTF-8 string which contains at least one
non-ASCII character. non-ASCII character.
The term "address header field" is used for a header field which The term "address header field" is used for a header field which
contains <mailbox> elements which is defined in [RFC5322]. "Address contains <mailbox> elements which is defined in [RFC5322]. "Address
header fields" contain "From", "Sender", "Reply-To", "To", "Cc", header fields" contain "From", "Sender", "Reply-To", "To", "Cc",
"Bcc", "Resent-From", "Resent-Sender", "Resent-To", "Resent-Cc", "Bcc", "Resent-From", "Resent-Sender", "Resent-To", "Resent-Cc",
"Return-Path" header fields. "Return-Path" header fields.
An "UTF8SMTP message" is an Email messages expanded by [RFC5335]. An "UTF8SMTP message" is an Email messages expanded by [RFC5335].
The term "MIME decode" is used for both "encoded-word" decoding The term "MIME decode" is used for both "encoded-word" decoding
defined by [RFC2047] and MIME parameter value decoding defined by defined by [RFC2047] and MIME parameter value decoding defined by
[RFC2231]. [RFC2231].
3. Consideration of displaying downgraded message 3. Consideration of displaying downgraded message
Displaying downgraded message is mostly performed by MIME decoding Displaying downgraded message is mostly performed by MIME decoding
according to [RFC2047] and [RFC2231]. Result of MIME decoding, the according to [RFC2047] and [RFC2231]. As a result of MIME decoding,
header of the message still contains Downgraded-*: header fields, but the header of the message still contains "Downgraded-" header fields,
the header field bodies are MIME decoded. These decoded but the header field bodies are MIME decoded. These decoded
"Downgraded-" header fields contain the original header field name "Downgraded-" header fields contain the original header field name
and the original header field values. The recipient can read them. and the original header field values. The recipient can read them.
But the recipient's MUA cannot use the original header fields But the recipient's MUA cannot use the original header fields
automatically. automatically.
Additionally, MUAs can process "Downgraded-" header fields. Additionally, A MUA can process "Downgraded-" header fields.
The easiest way to process "Downgraded-" header fields is to remove The easiest way to process "Downgraded-" header fields is to remove
"Downgraded-" from the decoded "Downgraded-" header fields' name. "Downgraded-" from the decoded "Downgraded-" header fields' names.
Then, the "address header fields" may be displayed twice, one is from Then, the "address header fields" may be displayed twice, one is from
downgraded header field and the other is from decoded "Downgraded-" downgraded header field and the other is from decoded "Downgraded-"
header field. Although it is very easy, it MUST NOT be used because header field. Although it is very easy, it MUST NOT be used because
of the following reasons. of the following reasons.
o [RFC5322] section 3.6 defines number of times each field may occur o [RFC5322] section 3.6 defines number of times each field may occur
in the header section of a message and the maximum number for in the header section of a message and the maximum number for
"From", "Sender", "To", "Cc", "Bcc" header fields is 1. It "From", "Sender", "To", "Cc", "Bcc" header fields is 1. It
violates [RFC5322]. violates [RFC5322].
o Users cannot distinguish which is the original downgraded header o Users cannot distinguish which is the original downgraded header
field and which is the generated header field. field and which is the generated header field.
o The Downgraded-* header field and corresponding header field may o The "Downgraded-" header field and corresponding header field may
not have relations. not have relations.
The following way is to remove "Downgraded-" from the decoded
"Downgraded-" header fields' name and remove the corresponding header
field at the same time.
4. Displaying downgraded message 4. Displaying downgraded message
MUAs may decode and re-generate the original header fields of the A MUA MAY decode and re-generate the original header fields of the
message. This procedure may reconstruct the original message from message. This procedure can be used to reverse the Downgrade process
the downgraded message. But it is not guaranteed. but will not construct exactly the original header fields in all
cases.
Displaying downgraded message is implemented by the following steps. Displaying downgraded message is implemented by the following steps.
Step 1: Select Address header field preservation headers described Input:
in Section 3.2 of [I-D.ietf-eai-downgrade]. Target header fields The input to this procedure is the header of the message as
are "Downgraded-From", "Downgraded-Sender", "Downgraded-To", received. Copy the entire header into an edit space.
"Downgraded-Cc", "Downgraded-Bcc", "Downgraded-Reply-To",
"Downgraded-Resent-From", "Downgraded-Resent-Sender", "Downgraded-
Resent-To", "Downgraded-Resent-Cc", "Downgraded-Resent-Bcc",
"Downgraded-Resent-Reply-To", "Downgraded-Return-Path" and
"Downgraded-Disposition-Notification-To" header fields.
Step 2: Generate new header field which field name is the original Step 1:
header field name and the field value is the MIME decoded header Select the "Address Header Fields' Preservation Header Fields"
field value from the output of Step 1. described in Section 3.2 of [RFC5504] in the edit space. These
header fields are "Downgraded-From", "Downgraded-Sender",
"Downgraded-To", "Downgraded-Cc", "Downgraded-Bcc", "Downgraded-
Reply-To", "Downgraded-Resent-From", "Downgraded-Resent-Sender",
"Downgraded-Resent-To", "Downgraded-Resent-Cc", "Downgraded-
Resent-Bcc", "Downgraded-Resent-Reply-To", "Downgraded-Return-
Path" and "Downgraded-Disposition-Notification-To" header fields.
Step 3: Apply Email header fields downgrading defined in section 5 Step 2:
of [I-D.ietf-eai-downgrade] to the output of Step 2 without re- For each header field from the output of Step 1, generate a new
generating "Downgraded-" header fields. header field where the field name is the original header field
name and the field value is the result of MIME decoding header
field value.
Step 4: Compare the output of Step 3 and the original header Step 3:
fields. If the same header fields exist for the output of Step 3 Apply "Email Header Fields Downgrading" defined in section 5 of
and the original header fields, remove the same header fields from [RFC5504] to the output of Step 2 without re-generating
the original header fields. This step outputs the original header "Downgraded-" header fields and copy the output into a new space
fields which is modified by this step 4. Before this comparison, (hereafter, call it as a "comparison space").
a canonicalization described below is useful.
Step 4:
Compare the header fields in the comparison space with the header
fields of the same name in the edit space. Before this
comparison, canonicalize each header field described below.
1. Unfold all header field continuation lines as described in 1. Unfold all header field continuation lines as described in
[RFC5322]. [RFC5322].
2. Insert a space character before and after <mailbox-list> 2. Insert a space character before and after <mailbox-list>
separator "," if there is no space character. separator "," if there is no space character.
3. Insert a space character before and after <comment> if there 3. Insert a space character before and after <comment> if there
is no space character. is no space character.
4. Decode each <encoded-word> whose charset is 'UTF-8'. 4. Decode each <encoded-word> whose charset is 'UTF-8'.
5. Convert all sequences of one or more WSP characters to a 5. Convert all sequences of one or more WSP characters to a
single space character. WSP characters here include those single space character. WSP characters here include those
before and after a line folding boundary. before and after a line folding boundary.
6. Delete all WSP characters at the end of each unfolded header 6. Delete all WSP characters at the end of each unfolded header
field value. field value.
7. Delete any WSP characters remaining before and after the colon 7. Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. separating the header field name from the header field value.
The colon separator MUST be retained. The colon separator MUST be retained.
Step 5: Decode MIME encoded header fields and MIME body part header For each header field, if the same header fields exist in the
fields according to [RFC2047] and [RFC2231]. comparison space and in the edit space, remove the original header
field in the edit space and the generated header field in the
comparison space.
Step 6: For each "Downgraded-" header field except the address Remaining header fields in the comparison space may be bogus or
header field preservation headers and the envelope information broken "Address Header Fields' Preservation Header Fields" origin.
preservation headers described in [I-D.ietf-eai-downgrade] section
3, generate new header field which field name is the original
header field name and the field value is the decoded header field
value, then replace the original "Downgraded-" header field by the
generated header field.
Don't change "Downgraded-Mail-From" and "Downgraded-Rcpt-To" Step 5:
header fields because they do not have their original header Decode all MIME encoded header fields according to [RFC2047] and
fields. Don't change the address header field preservation header [RFC2231] in the edit space.
if it doesn't have the corresponding downgraded header field.
5. Security considerations Step 6:
For each "Unknown Header Fields' Preservation Header Fields"
described in section 3.3 of [RFC5504] and "Address Header Fields'
Preservation Header Fields", generate a new header field where the
field name is the original header field name and the field value
is the result of MIME decoding header field value, then replace
the original "Downgraded-" header field by the generated header
field in the edit space. "Envelope Information Preservation
Header Fields" are not targets of this step.
While displaying downgraded message changes the header fields of the The output of this procedure is an UTF8SMTP header in the edit space.
message and it may lose the original information, MUAs should have a It will closely resemble the original header.
function to read the original received message (with/without MIME
decoding). After this procedure, the MUA may decode MIME body part header fields
according to [RFC2047] and [RFC2231].
5. Security considerations
While information in any email header should usually treated with While information in any email header should usually treated with
some suspicion, current email systems commonly employ various some suspicion, current email systems commonly employ various
mechanisms and protocols to make the information more trustworthy. mechanisms and protocols to make the information more trustworthy.
For example, an organization's boundary MTA can modify From: lines so For example, an organization's boundary MTA can modify "From:" lines
that messages arriving from outside the organization are easily so that messages arriving from outside the organization are easily
distinguishable from internal emails. As a result of rewriting, the distinguishable from internal emails. As a result of rewriting, the
Downgraded-From header field may not be decoded. "Downgraded-From" header field may not be decoded.
See "Security considerations" section in [I-D.ietf-eai-downgrade] and A MUA may emphasize bogus or broken "Downgraded-" header fields in
[RFC4952] for more discussion. step 4 of Section 4.
Hiding the information from the actual header fields when using the
"Downgraded-" header fields does not cause loss of information if the
comparison done in step 4 of Section 4 is successful. To ensure that
no information is lost, a MUA SHOULD have a function that uses the
actual message that was received (with/without MIME decoding) to
render the message.
See "Security considerations" section in [RFC5504] and [RFC4952] for
more discussion.
6. IANA Considerations 6. IANA Considerations
This document makes no requests for IANA action. This section can be
removed by the RFC Editor before publication.
7. Acknowledgements 7. Acknowledgements
This document was separated from [RFC5504]. Both documents were
developed in the EAI WG. Significant comments and suggestions were
received from John Klensin, Harald Alvestrand, Chris Newman, Randall
Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank
Ellermann, Edward Lewis, S. Moonesamy and JET members.
8. Change History 8. Change History
This section is used for tracking the update of this document. Will This section is used for tracking the update of this document. Will
be removed after finalize. be removed after finalize.
8.1. draft-fujiwara-eai-downgraded-display: Version 00 8.1. draft-fujiwara-eai-downgraded-display: Version 00
o Initial version o Initial version
o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt
8.2. draft-ietf-eai-downgraded-display: Version 00 8.2. draft-ietf-eai-downgraded-display: Version 00
o Submitted as a working group draft o Submitted as a working group draft
8.3. draft-ietf-eai-downgraded-display: Version 01 8.3. draft-ietf-eai-downgraded-display: Version 01
o Prohibited and removed Displaying Technique 1 o Prohibited and removed Displaying Technique 1
o Added new texts to Security Considerations o Added new texts to Security Considerations
9. Normative References 8.4. draft-ietf-eai-downgraded-display: Version 02
[I-D.ietf-eai-downgrade] o updated by comments from Chair's review and AD's review
Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for o Fixed references
Email Address Internationalization", o Rewrote section 4 to be more comprehensible
draft-ietf-eai-downgrade-12 (work in progress), o Added bogus or broken "Downgraded-" header fields
March 2009. o Added sentences in Security considerations
9. References
9.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 7, line 32 skipping to change at page 8, line 30
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231, Character Sets, Languages, and Continuations", RFC 2231,
November 1997. November 1997.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007. Internationalized Email", RFC 4952, July 2007.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008. September 2008.
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
Email Address Internationalization", RFC 5504, March 2009.
9.2. Informative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008. Email Addresses", RFC 5336, September 2008.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337, Status and Disposition Notifications", RFC 5337,
September 2008. September 2008.
Appendix A. Examples Appendix A. Examples
This section shows a example of displaying downgraded message. This section shows a example of displaying downgraded message.
skipping to change at page 8, line 4 skipping to change at page 9, line 8
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008. Email Addresses", RFC 5336, September 2008.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337, Status and Disposition Notifications", RFC 5337,
September 2008. September 2008.
Appendix A. Examples Appendix A. Examples
This section shows a example of displaying downgraded message. This section shows a example of displaying downgraded message.
First, an example of the original UTF8SMTP message and its downgraded First, an example of the original UTF8SMTP message and its downgraded
message are shown. They are the same as "Example 1" of message are shown. They are the same as "Example 1" of [RFC5504].
[I-D.ietf-eai-downgrade]. The example UTF8SMTP message is shown in The example UTF8SMTP message is shown in Figure 1.
Figure 1.
Message-Id: MESSAGE_ID Message-Id: MESSAGE_ID
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
skipping to change at page 11, line 7 skipping to change at page 12, line 7
NON-ASCII-remote2@example.org removed:; NON-ASCII-remote2@example.org removed:;
Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org> Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 3: MIME decoded message Figure 3: MIME decoded message
A.1. Displaying example A.1. Displaying example
This example shows displaying process of 'Displaying technique' for This example shows processes of 'Displaying downgraded message' for
Figure 2. Figure 2.
First, perform Step 1. First, perform Step 1.
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?= =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?= =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?= =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
skipping to change at page 13, line 17 skipping to change at page 14, line 17
header fields only. header fields only.
Author's Address Author's Address
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81-3-5215-8451
Email: fujiwara@jprs.co.jp Email: fujiwara@jprs.co.jp
 End of changes. 35 change blocks. 
95 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/