draft-ietf-eai-downgraded-display-03.txt   rfc5825.txt 
Email Address Internationalization K. Fujiwara Internet Engineering Task Force (IETF) K. Fujiwara
(EAI) JPRS Request for Comments: 5825 JPRS
Internet-Draft B. Leiba Category: Experimental B. Leiba
Intended status: Experimental Huawei Technologies ISSN: 2070-1721 Huawei Technologies
Expires: June 4, 2010 December 1, 2009 April 2010
Displaying Downgraded Messages for Email Address Internationalization Displaying Downgraded Messages for Email Address Internationalization
draft-ietf-eai-downgraded-display-03.txt
Abstract Abstract
This document describes a method for displaying downgraded messages This document describes a method for displaying downgraded messages
which originally contained internationalized E-mail addresses or that originally contained internationalized email addresses or
internationalized header fields. internationalized header fields.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 4, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5825.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................2
3. Converting downgraded message headers for display . . . . . . 3 3. Converting Downgraded Message Headers for Display ...............3
3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Considerations .............................................3
3.2. The process . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. The Process ................................................3
3.2.1. No reconstruction of the Envelope Information 3.2.1. No Reconstruction of the Envelope
Preservation Header Fields . . . . . . . . . . . . . . 4 Information Preservation ............................4
3.2.2. Reconstructing the Address Header Fields' 3.2.2. Reconstructing the Address Header Fields'
Preservation Header Fields . . . . . . . . . . . . . . 4 Preservation Header .................................4
3.2.3. The Unknown Header Fields' Preservation Header 3.2.3. The Unknown Header Fields' Preservation
Fields . . . . . . . . . . . . . . . . . . . . . . . . 5 Header Fields .......................................5
4. Security considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations .........................................6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements ................................................6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. References ......................................................6
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References .......................................6
7.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7 6.2. Informative References .....................................7
7.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7 Appendix A. Examples ..............................................8
7.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7 A.1. Displaying Example ........................................11
7.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7
7.5. draft-ietf-eai-downgraded-display: Version 03 . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 rejection of structure, syntax, and email header format. To avoid rejection of
internationalized Email messages, the downgrading mechanism [RFC5504] internationalized email messages, the downgrading mechanism [RFC5504]
converts an internationalized message to a traditional Email message converts an internationalized message to a traditional email message
when a server in the delivery path does not support the UTF8SMTP when a server in the delivery path does not support the UTF8SMTP
extension. The downgraded message is a traditional Email message, extension. The downgraded message is a traditional email message,
except the message has "Downgraded-" header fields. except the message has "Downgraded-" 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
The restoration of the downgrading should be done once at the final information. The restoration of the downgrading should be done once
destination of the downgraded message such as MUAs or IMAP servers. at the final destination of the downgraded message such as Mail User
This document describes the restoration methods for displaying Agents (MUAs) or IMAP servers. This document describes the
downgraded messages in MUAs. restoration methods for displaying 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], or the MIME documents
[RFC2047] [RFC2183] [RFC2231]. [RFC2045], [RFC2047], [RFC2183], and [RFC2231].
This document depends on [RFC5335] and [RFC5504]. Key words used in This document depends on [RFC5335] and [RFC5504]. Key words used in
these document are used in this document, too. those documents are used in this document, too.
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. Converting downgraded message headers for display 3. Converting Downgraded Message Headers for Display
3.1. Considerations 3.1. Considerations
The order of some header fields (such as "Resent-*" fields) is The order of some header fields (such as "Resent-*" fields) is
significant. The process of regenerating the original fields from significant. The process of regenerating the original fields from
the downgraded ones MUST NOT reorder the fields. the downgraded ones MUST NOT reorder the fields.
In order to regenerate a field from a specific downgraded header In order to regenerate a field from a specific downgraded header
field, it's necessary to find the corresponding replacement in the field, it's necessary to find the corresponding replacement in the
current message. If the corresponding field can not be found, the current message. If the corresponding field cannot be found, the
downgraded header field in question can not be regenerated and used. downgraded header field in question cannot be regenerated and used.
3.2. The process In any case where reconstruction of a particular downgraded header
field fails, both header fields (the "downgraded-YYY" header field
and the "YYY" header field) SHOULD be left in the message as they
are. The MUA MAY choose to communicate the situation to the user
(see the "Security Considerations" section).
A MUA MAY decode and re-generate the original header fields of the 3.2. The Process
message (MTAs and MDAs SHOULD NOT attempt to do this; it SHOULD be
left to the MUA). This procedure can be used to approximately
reverse the Downgrade process, but it will not always construct the
original header fields exactly.
Three types of Downgraded header fields are described in section 3 of A MUA MAY decode and regenerate the original header fields of the
message (Mail Transport Agents (MTAs) and Mail Delivery Agents (MDAs)
SHOULD NOT attempt to do this; it SHOULD be left to the MUA). This
procedure can be used to approximately reverse the downgrade process,
but it will not always construct the original header fields exactly.
Three types of downgraded header fields are described in Section 3 of
[RFC5504]: [RFC5504]:
1. "Envelope Information Preservation Header Fields", described in 1. "Envelope Information Preservation Header Fields", described in
RFC5504 section 3.1 and in Section 3.2.1, below. RFC5504 Section 3.1 and in Section 3.2.1, below.
2. "Address Header Fields' Preservation Header Fields", described in 2. "Address Header Fields' Preservation Header Fields", described in
RFC5504 section 3.2 and in Section 3.2.2, below. RFC5504 Section 3.2 and in Section 3.2.2, below.
3. "Unknown Header Fields' Preservation Header Fields", described in 3. "Unknown Header Fields' Preservation Header Fields", described in
RFC5504 section 3.3 and in Section 3.2.3, below. RFC5504 Section 3.3 and in Section 3.2.3, below.
After processing Downgraded header fields, decode all header fields, After processing downgraded header fields, decode all header fields,
as described in [RFC2047] and [RFC2231]. as described in [RFC2047] and [RFC2231].
3.2.1. No reconstruction of the Envelope Information Preservation 3.2.1. No Reconstruction of the Envelope Information Preservation
Header Fields Header Fields
Envelope Information Preservation Header Fields are new fields that Envelope information preservation header fields are new fields that
might have been added by the downgrade process. Because they do not might have been added by the downgrade process. Because they do not
represent fields that appeared in the original message, this process represent fields that appeared in the original message, this process
is not applicable to them. is not applicable to them.
3.2.2. Reconstructing the Address Header Fields' Preservation Header 3.2.2. Reconstructing the Address Header Fields' Preservation Header
Fields Fields
Reconstructing Address Header Fields' Preservation Header Fields is Reconstructing address header fields' preservation header fields is
OPTIONAL, and a decision MAY be made on each field, individually. In OPTIONAL, and a decision MAY be made on each field, individually. In
particular, it might be less important to process the Resent-* header particular, it might be less important to process the "Resent-*"
fields, so an implementation MAY choose to skip those. header fields, so an implementation MAY choose to skip those.
To construct a displayable copy of a header field from one of these To construct a displayable copy of a header field from one of these
downgraded header fields, follow this procedure: downgraded header fields, follow this procedure:
1. In an edit buffer, create a new header field:"
1a. For the field name, remove the "Downgraded-" prefix from the
downgraded field name. For example, "Downgraded-From" becomes
"From", and "Downgraded-Resent-To" becomes "Resent-To".
1b. For the field value, decode the MIME-encoded value of the 1. In an edit buffer, create a new header field:
downgraded field according to [RFC2047].
2. If the header field is one that can only appear once, according (a) For the field name, remove the "Downgraded-" prefix from the
to the table in [RFC5322] section 3.6 ("From", "Sender", "To", downgraded field name. For example, "Downgraded-From"
"CC", "BCC", "Reply-To"), locate the corresponding field in the becomes "From", and "Downgraded-Resent-To" becomes
message's headers, and skip to step 9. Otherwise, continue with "Resent-To".
step 3.
3. Apply "Email Header Fields Downgrading", defined in section 5 of (b) For the field value, decode the MIME-encoded value of the
[RFC5504], to the field in the edit buffer, but do not prepend the downgraded field according to [RFC2047].
"Downgraded-" prefix. Put the result into comparison buffer 1.
4. Canonicalize the header fields in the comparison buffer: 2. Apply "Email Header Fields Downgrading", defined in Section 5 of
1. Unfold all header field continuation lines as described in [RFC5504], to the field in the edit buffer. The process
[RFC5322]. generates two header fields, one is ASCII header field and the
2. Ensure that there is one space character before and one after other is the Address Header Fields' Preservation Header Field.
the <mailbox-list> separator ",". If a space character is Put the generated ASCII header field into comparison buffer 1.
missing, insert one.
3. Ensure that there is one space character before and one after 3. Canonicalize the header field in the comparison buffer 1:
each <comment>. If a space character is missing, insert one.
4. Decode each <encoded-word> whose charset is "UTF-8". 1. Unfold all header field continuation lines as described in
5. Convert all sequences of one or more WSP characters to a [RFC5322].
single space character. WSP characters here include those
before and after a line-folding boundary. 2. Ensure that there is one space character before and one after
6. Delete all WSP characters at the end of each unfolded header the <mailbox-list> separator ",". If a space character is
field value. missing, insert one.
7. Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value, 3. Ensure that there is one space character before and one after
retaining the colon separator. each <comment>. If a space character is missing, insert one.
5. Locate the first instance of the corresponding field in the
message's headers. 4. Decode each <encoded-word> whose charset is "UTF-8".
6. Canonicalize the located field as in step 4, and put the result
into comparison buffer 2. 5. Convert all sequences of one or more WSP characters to a
7. Compare the header field in comparison buffer 1 with the header single space character. WSP characters here include those
field in comparison buffer 2. If they match, go to step 9. before and after a line-folding boundary.
8. Locate the next instance of the corresponding field in the
message's headers. If one is found, go to step 6. If none is 6. Delete all WSP characters at the end of each unfolded header
found, stop: you can not use this downgraded field because you field value.
can't find its replacement in the message.
9. Replace the located header field with the one in the edit 7. Delete any WSP characters remaining before and after the
buffer. You MUST NOT reorder the header fields when you do this; colon separating the header field name from the header field
it's important to replace the field in place. value, retaining the colon separator.
4. Locate the first instance of the corresponding field in the
message's headers.
5. Canonicalize the located field as in step 3, and put the result
into comparison buffer 2.
6. Compare the header field in comparison buffer 1 with the header
field in comparison buffer 2. If they match, go to step 8.
7. Locate the next instance of the corresponding field in the
message's headers. If one is found, go to step 5. If none is
found, stop: you cannot use this downgraded field because you
can't find its replacement in the message.
8. Replace the located header field with the one in the edit buffer.
You MUST NOT reorder the header fields when you do this; it's
important to replace the field in the same place. Remove the
target downgraded header field in the message header.
3.2.3. The Unknown Header Fields' Preservation Header Fields 3.2.3. The Unknown Header Fields' Preservation Header Fields
The Unknown Header Fields' Preservation Header Fields SHOULD be left The unknown header fields' preservation header fields SHOULD be left
as they are unless the MUA has special knowledge of a particular as they are unless the MUA has special knowledge of a particular
field. An MUA with such knowledge MAY use the procedure in field. An MUA with such knowledge MAY use the procedure similar to
Section 3.2.2, above, for those fields that it knows about. the procedure in Section 3.2.2, above, for those fields about which
it knows. (Note that the whitespace canonicalization rule might not
be applicable to some header fields.)
4. Security considerations 4. Security Considerations
While information in any email header should usually be treated with While information in any email header should usually be 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 For example, an organization's boundary MTA can modify "From" lines
so 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 that rewriting, distinguishable from internal emails. As a result of that rewriting,
it might not be possible to reconstruct the "Downgraded-From" header the "From" header field might not match the "Downgraded-From" header
field. field.
A MUA MAY emphasize bogus or broken Address Header Fields' A MUA MAY emphasize bogus or broken address header fields'
Preservation Header Fields found in step 8 of Section 3.2.2. preservation header fields found in step 7 of Section 3.2.2.
Hiding the information from the actual header fields when using the Hiding the information from the actual header fields when using the
"Downgraded-" header fields does not cause loss of information if "Downgraded-" header fields does not cause loss of information if
generating MIME decoded header fields in step 1 of Section 3.2.2 and generating MIME-decoded header fields in step 1 of Section 3.2.2 and
the comparison done in step 8 are successful. To ensure that no the comparison done in step 7 are successful. To ensure that no
information is lost, a MUA SHOULD have a function that uses the information is lost, a MUA SHOULD have a function that uses the
actual message that was received (with/without MIME decoding) to actual message that was received (with/without MIME decoding) to
render the message. render the message.
See "Security considerations" section in [RFC5504] and [RFC4952] for We have focused, here, on issues with displaying downgraded messages.
more discussion. For more discussion of downgraded and internationalized messages in
general, see the "Security Considerations" section in [RFC5504] and
5. IANA Considerations [RFC4952].
This document makes no requests for IANA action. This section can be
removed by the RFC Editor before publication.
6. Acknowledgements 5. Acknowledgements
This document was separated from [RFC5504]. Both documents were This document was separated from [RFC5504]. Both documents were
developed in the EAI WG. Significant comments and suggestions were developed in the EAI WG. Significant comments and suggestions were
received from John Klensin, Harald Alvestrand, Chris Newman, Randall received from John Klensin, Harald Alvestrand, Chris Newman, Randall
Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Pasi Eronen, Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Pasi Eronen,
Frank Ellermann, Edward Lewis, S. Moonesamy and JET members. Frank Ellermann, Edward Lewis, S. Moonesamy, and JET members.
7. Change History
This section is used for tracking the update of this document. Will
be removed after finalize.
7.1. draft-fujiwara-eai-downgraded-display: Version 00
o Initial version
o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt
7.2. draft-ietf-eai-downgraded-display: Version 00
o Submitted as a working group draft
7.3. draft-ietf-eai-downgraded-display: Version 01
o Prohibited and removed Displaying Technique 1
o Added new texts to Security Considerations
7.4. draft-ietf-eai-downgraded-display: Version 02
o updated by comments from Chair's review and AD's review
o Fixed references
o Rewrote section 4 to be more comprehensible
o Added bogus or broken "Downgraded-" header fields
o Added sentences in Security considerations
7.5. draft-ietf-eai-downgraded-display: Version 03
o Section 3 (formerly 3 and 4) was rewritten by Barry Leiba.
8. References 6. References
8.1. Normative References 6.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 8, line 20 skipping to change at page 7, line 29
[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 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
Email Address Internationalization", RFC 5504, March 2009. Email Address Internationalization", RFC 5504, March 2009.
8.2. Informative References 6.2. Informative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. 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 a downgraded message. This section shows an example of displaying a 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. The example comes from "Example 1" of [RFC5504] message are shown. The example comes from "Example 1" of [RFC5504]
and three header fields, "Unknown-Field", "Resent-From", and and three header fields, "Unknown-Field", "Resent-From", and
"Resent-To", are added. The example UTF8SMTP message is shown in "Resent-To", are added. 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
skipping to change at page 9, line 26 skipping to change at page 9, line 5
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
<ASCII-reto@example.net>> <ASCII-reto@example.net>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 1: Original message Figure 1: Original message
Delivered downgraded message is shown in Figure 2. Return-Path A delivered downgraded message is shown in Figure 2. A Return-Path
header will be added by the final destination MTA. Some of Received: header will be added by the final destination MTA. Some "Received"
header fields may be added. header fields may be added.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Received: ... Received: ...
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?= =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?= Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?= =?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID Message-Id: MESSAGE_ID
Mime-Version: 1.0 Mime-Version: 1.0
skipping to change at page 10, line 39 skipping to change at page 10, line 5
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?= =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net> Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?= =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 2: Downgraded message Figure 2: Downgraded message
Figure 3 shows MIME decoded message of Figure 2. The recipient can Figure 3 shows the MIME-decoded message of Figure 2. The recipient
read the original From, To, Cc and Unknown-Field header fields as can read the original "From", "To", "Cc", "Resent-From", "Resent-To"
Downgraded-From, Downgraded-To, Downgraded-Cc and Downgraded-Unknown- and "Unknown-Field" header fields as "Downgraded-From",
Field header fields. "Downgraded-To", "Downgraded-Cc", "Downgraded-Resent-From",
"Downgraded-Resent-To", and "Downgraded-Unknown-Field" header fields.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Received: ... Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
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"
skipping to change at page 11, line 36 skipping to change at page 10, line 42
Resent-From: DISPLAY-remote1 <ASCII-remote1@example.net> Resent-From: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-Resent-From: DISPLAY-remote1 Downgraded-Resent-From: DISPLAY-remote1
<NON-ASCII-remote1@example.net <ASCII-remote1@example.net>> <NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <ASCII-reto@example.net> Resent-To: DISPLAY-reto <ASCII-reto@example.net>
Downgraded-Resent-To: DISPLAY-reto Downgraded-Resent-To: DISPLAY-reto
<NON-ASCII-reto@example.net <ASCII-reto@example.net>> <NON-ASCII-reto@example.net <ASCII-reto@example.net>>
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 how to display the message in Figure 2, above, This example shows how to display the message in Figure 2, above,
using the process defined in Section 3. For simplicity, we will show using the process defined in Section 3. For simplicity, we will show
the reconstruction of all the applicable fields at once. the reconstruction of all the applicable fields at once.
Selecting all Downgraded-* fields gives this: Selecting all Downgraded-* fields gives this:
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?= =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?= Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
skipping to change at page 12, line 31 skipping to change at page 11, line 31
=?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>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?= Downgraded-Resent-From: =?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-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?= =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Figure 4: Downgraded header fields Figure 4: Downgraded header fields
Two of the fields, Downgraded-Mail-From and Downgraded-Rcpt-To, are Two of the fields, "Downgraded-Mail-From" and "Downgraded-Rcpt-To",
Envelope Information Preservation Header Fields, and will not be are envelope information preservation header fields, and will not be
reconstructed. One field, Downgraded-Unknown-Field, is an Unknown reconstructed. One field, "Downgraded-Unknown-Field", is an unknown
Header Fields' Preservation Header Field, and will also not be header fields' preservation header field and will also not be
reconstructed. That leaves these to be reconstructed, the Address reconstructed. That leaves the address header fields' preservation
Header Fields' Preservation Header Fields: header fields to be reconstructed.
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>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?= Downgraded-Resent-From: =?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-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
skipping to change at page 13, line 4 skipping to change at page 11, line 48
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>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?= Downgraded-Resent-From: =?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-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?= =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Figure 5: Header fields for the reconstruction Figure 5: Header fields for the reconstruction
Now, perform Step 1, creating temporary fields. Now, perform step 1 to the downgraded header fields shown in Figure 5
and create an edit buffer.
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>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org> Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 Resent-From: DISPLAY-remote1
<NON-ASCII-remote1@example.net <ASCII-remote1@example.net>> <NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto Resent-To: DISPLAY-reto
<NON-ASCII-reto@example.net <ASCII-reto@example.net>> <NON-ASCII-reto@example.net <ASCII-reto@example.net>>
Figure 6: Output of Step 1 Figure 6: edit buffer: Output of step 1
In step 2, we set aside the "From", "To", and "Cc" fields, and
continue to step 3 with just "Resent-From" and "Resent-To" (the
fields that may appear more than once). The fields we set aside will
be picked up again later, in step 9.
Perform Steps 3 and 4. The edit buffer contains re-generated ASCII Apply "Email Header Fields Downgrading" to the "edit buffer". It
header fields, canonicalized. generates downgraded ASCII header fields and the address header
fields' preservation header fields. The latter fields are the same
as the downgraded header fields. Put the former fields into
"comparison buffer 1".
Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net> From:DISPLAY-local <ASCII-local@example.com>
Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net> To:DISPLAY-remote1 <ASCII-remote1@example.net>
Cc:DISPLAY-remote2 Internationalized address
NON-ASCII-remote2@example.org removed:;
Resent-From:DISPLAY-remote1 <ASCII-remote1@example.net>
Resent-To:DISPLAY-reto <ASCII-reto@example.net>
Figure 7: The edit buffer (output of Step 4) Figure 7: comparison buffer 1: Output of step 3
Perform Steps 5 to 7, comparison, for each header field. Both the Perform steps 4 to 6, comparison, for each header field. Five header
Resent-From and Resent-To fields will match, and we will proceed to fields, "From", "To", "Cc", "Resent-From" and "Resent-To" fields will
step 9. (Step 8, iteration, does not apply in this example. match, and we will proceed to step 8. (Step 7, iteration, does not
apply in this example.
Perform step 9, replacing all applicable fields, without changing the Perform step 8, replacing all applicable fields, without changing the
order. Then do MIME decoding on everything, for display. order. Then, do MIME decoding on everything, for display.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Received: ... Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net> Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net> <ASCII-remote1@example.net>
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"
skipping to change at page 14, line 44 skipping to change at page 14, line 14
Authors' Addresses Authors' Addresses
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
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
 End of changes. 60 change blocks. 
216 lines changed or deleted 201 lines changed or added

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