draft-ietf-eai-downgrade-10.txt   draft-ietf-eai-downgrade-11.txt 
Email Address Internationalization K. Fujiwara, Ed. Email Address Internationalization K. Fujiwara, Ed.
(EAI) Y. YONEYA, Ed. (EAI) Y. YONEYA, Ed.
Internet-Draft JPRS Internet-Draft JPRS
Intended status: Experimental Dec 11, 2008 Intended status: Experimental Jan 20, 2009
Expires: June 14, 2009 Expires: July 24, 2009
Downgrading mechanism for Email Address Internationalization Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-10.txt draft-ietf-eai-downgrade-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 14, 2009. This Internet-Draft will expire on July 24, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Traditional mail systems handle only ASCII characters in SMTP Traditional mail systems handle only ASCII characters in SMTP
envelope and mail header fields. The Email Address envelope and mail header fields. The Email Address
Internationalization (UTF8SMTP) extension allows UTF-8 characters in Internationalization (UTF8SMTP) extension allows UTF-8 characters in
SMTP envelope and mail header fields. To avoid rejecting SMTP envelope and mail header fields. To avoid rejecting
internationalized Email messages when a server in the delivery path internationalized Email messages when a server in the delivery path
does not support the UTF8SMTP extension, some sort of converting does not support the UTF8SMTP extension, some sort of converting
mechanism is required. This document describes a downgrading mechanism is required. This document describes a downgrading
mechanism for Email Address Internationalization. Note that this is mechanism for Email Address Internationalization. Note that this is
a way to downgrade, not tunnel. There is no associated up-conversion a way to downgrade, not tunnel. There is no associated up-conversion
mechanism, although internationalized email clients might use mechanism, although internationalized email clients might use
original internationalized addresses or other data when displaying or original internationalized addresses or other data when displaying or
replying to downgraded messages. replying to downgraded messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. New header fields definition . . . . . . . . . . . . . . . . . 4 3. New header fields definition . . . . . . . . . . . . . . . . . 5
3.1. Envelope information preservation headers . . . . . . . . 5 3.1. Envelope information preservation headers . . . . . . . . 6
3.2. Address header field preservation headers . . . . . . . . 5 3.2. Address header field preservation headers . . . . . . . . 6
3.3. Unknown header fields preservation headers . . . . . . . 6 3.3. Unknown header fields preservation headers . . . . . . . 7
4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 6 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Path element downgrading . . . . . . . . . . . . . . . . 7 4.1. Path element downgrading . . . . . . . . . . . . . . . . 8
4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 7 4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 9
5. Email header fields downgrading . . . . . . . . . . . . . . . 8 5. Email header fields downgrading . . . . . . . . . . . . . . . 9
5.1. Downgrading method for each header field . . . . . . . . 10 5.1. Downgrading method for each ABNF element . . . . . . . . 9
6. MIME body part headers downgrading . . . . . . . . . . . . . . 12 5.1.1. RECEIVED downgrading . . . . . . . . . . . . . . . . . 9
7. Security considerations . . . . . . . . . . . . . . . . . . . 13 5.1.2. UNSTRUCTURED downgrading . . . . . . . . . . . . . . . 9
8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 14 5.1.3. WORD downgrading . . . . . . . . . . . . . . . . . . . 10
8.1. RFC 2047 encoding . . . . . . . . . . . . . . . . . . . . 14 5.1.4. COMMENT downgrading . . . . . . . . . . . . . . . . . 10
8.2. Trivial downgrading . . . . . . . . . . . . . . . . . . . 14 5.1.5. MIME-VALUE downgrading . . . . . . . . . . . . . . . . 10
8.3. 7bit transport consideration . . . . . . . . . . . . . . 15 5.1.6. DISPLAY-NAME downgrading . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.1.7. MAILBOX downgrading . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.8. ENCAPSULATION downgrading . . . . . . . . . . . . . . 11
11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.9. TYPED-ADDRESS downgrading . . . . . . . . . . . . . . 11
11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 17 5.2. Downgrading method for each header field . . . . . . . . 11
11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 17 5.2.1. Address header fields which contain <address>s . . . . 11
11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 17 5.2.2. Address header fields with typed addresses . . . . . . 12
11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 18 5.2.3. Downgrading Non-ASCII in comments . . . . . . . . . . 12
11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 18 5.2.4. Received header field . . . . . . . . . . . . . . . . 12
11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 18 5.2.5. MIME Content header fields . . . . . . . . . . . . . . 12
11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 18 5.2.6. Non-ASCII in <unstructured> . . . . . . . . . . . . . 13
11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 18 5.2.7. Non-ASCII in <phrase> . . . . . . . . . . . . . . . . 13
11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 19 5.2.8. Other header fields . . . . . . . . . . . . . . . . . 13
11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 19 6. MIME body part headers downgrading . . . . . . . . . . . . . . 13
11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 19 7. Security considerations . . . . . . . . . . . . . . . . . . . 14
11.12. draft-ietf-eai-downgrade: Version 09 . . . . . . . . . . 19 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 15
11.13. draft-ietf-eai-downgrade: Version 10 . . . . . . . . . . 19 8.1. RFC 2047 encoding . . . . . . . . . . . . . . . . . . . . 15
12. Normative References . . . . . . . . . . . . . . . . . . . . . 19 8.2. Trivial downgrading . . . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 8.3. 7bit transport consideration . . . . . . . . . . . . . . 16
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 26 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 19
11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 19
11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 19
11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 19
11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 19
11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 19
11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 20
11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . 20
11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 20
11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 20
11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 20
11.12. draft-ietf-eai-downgrade: Version 09 . . . . . . . . . . 20
11.13. draft-ietf-eai-downgrade: Version 10 . . . . . . . . . . 21
11.14. draft-ietf-eai-downgrade: Version 11 . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 22
A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Traditional mail systems which are defined by [RFC5321] and [RFC5322] Traditional mail systems which are defined by [RFC5321] and [RFC5322]
allow ASCII characters in SMTP envelope and mail header field values. allow ASCII characters in SMTP envelope and mail header field values.
The UTF8SMTP extension [RFC4952], [RFC5335] and [RFC5336] allows The UTF8SMTP extension [RFC4952], [RFC5335] and [RFC5336] allows
UTF-8 characters in SMTP envelope and mail header field values. UTF-8 characters in SMTP envelope and mail header field values.
If an envelope address or header field contains non-ASCII characters, If an envelope address or header field contains non-ASCII characters,
the message cannot be delivered unless every system in the delivery the message cannot be delivered unless every system in the delivery
skipping to change at page 5, line 47 skipping to change at page 7, line 7
3.2. Address header field preservation headers 3.2. Address header field preservation headers
The address header fields preservation headers are defined to The address header fields preservation headers are defined to
preserve the original header field. Their value field holds the preserve the original header field. Their value field holds the
original header field value. The header field syntax is specified as original header field value. The header field syntax is specified as
follows: follows:
fields =/ known-downgraded-headers ":" unstructured CRLF fields =/ known-downgraded-headers ":" unstructured CRLF
known-downgraded-headers = "Downgraded-" original-headers known-downgraded-headers = "Downgraded-" original-headers
original-headers = "From" / "To" / "Cc" / "Bcc" / original-headers = "From" / "Sender" /
"Sender" / "Reply-To" / "To" / "Cc" / "Bcc" /
"Reply-To" /
"Resent-From" / "Resent-Sender" / "Resent-From" / "Resent-Sender" /
"Resent-To" / "Resent-Cc" / "Return-Path" "Resent-To" / "Resent-Cc" / "Resent-Bcc" /
"Resent-Reply-To" /
"Return-Path" /
"Disposition-Notification-To"
Preserving a header field in a downgraded header field is defined as: Preserving a header field in a downgraded header field is defined as:
1. Generate new downgraded header field whose value is the original 1. Generate new downgraded header field whose value is the original
header field value. header field value.
2. Treat the generated header field content as if it were 2. Treat the generated header field content as if it were
unstructured, and then apply [RFC2047] encoding with charset unstructured, and then apply [RFC2047] encoding with charset
UTF-8 as necessary so the result is ASCII. UTF-8 as necessary so the result is ASCII.
3.3. Unknown header fields preservation headers 3.3. Unknown header fields preservation headers
The unknown header fields preservation headers are defined to The unknown header fields preservation headers are defined to
skipping to change at page 6, line 36 skipping to change at page 8, line 4
field-name = 1*ftext field-name = 1*ftext
ftext = %d33-57 / ; Any character except ftext = %d33-57 / ; Any character except
%d59-126 ; controls, SP, and %d59-126 ; controls, SP, and
; ":". ; ":".
Encapsulating a header field in a "Downgraded-" header field is Encapsulating a header field in a "Downgraded-" header field is
defined as: defined as:
1. Generate new "Downgraded-" header field whose value is the 1. Generate new "Downgraded-" header field whose value is the
original header field value. original header field value.
2. Treat the generated header field content as if it were 2. Treat the generated header field content as if it were
unstructured, and then apply [RFC2047] encoding with charset unstructured, and then apply [RFC2047] encoding with charset
UTF-8 as necessary so the result is ASCII. UTF-8 as necessary so the result is ASCII.
3. Remove the original header field. 3. Remove the original header field.
Applying this procedure to "Received" header field is prohibited.
4. SMTP Downgrading 4. SMTP Downgrading
Target of downgrading elements in SMTP envelope are below: Target of downgrading elements in SMTP envelope are below:
o <reverse-path> of MAIL FROM command o <reverse-path> of MAIL FROM command
o <forward-path> of RCPT TO command o <forward-path> of RCPT TO command
o ORCPT parameter of RCPT TO command o ORCPT parameter of RCPT TO command
4.1. Path element downgrading 4.1. Path element downgrading
skipping to change at page 8, line 4 skipping to change at page 9, line 14
is valid for the new recipient address. Otherwise, the downgrading is valid for the new recipient address. Otherwise, the downgrading
process MUST NOT send the downgraded message to the new recipient process MUST NOT send the downgraded message to the new recipient
address via the connection and MUST try to send the downgraded address via the connection and MUST try to send the downgraded
message to the new recipient address. message to the new recipient address.
4.2. ORCPT downgrading 4.2. ORCPT downgrading
The "RCPT TO" command can have an ORCPT parameter if the DSN The "RCPT TO" command can have an ORCPT parameter if the DSN
extension [RFC3461] is supported. If the ORCPT parameter contains an extension [RFC3461] is supported. If the ORCPT parameter contains an
"utf-8" type address and the address contains raw non-ASCII "utf-8" type address and the address contains raw non-ASCII
characters, the address MUST be converted to utf-8-addr-unitext form characters, the address MUST be converted to utf-8-addr-xtext form.
or utf-8-addr-xtext form which are described in [RFC5337]. Those forms are described in [RFC5337] and clarified by successor
documents such as [I-D.ietf-eai-dsnbis].
The utf-8-addr-unitext transformation that needs to occur on the Before converting to utf-8-addr-xtext form, remove xtext encoding.
content of ORCPT is to
1. remove xtext encoding.
2. convert the result of step 1 to utf-8-addr-unitext form where all
non-ASCII characters and '\' are represented as
EmbeddedUnicodeChar.
3. re-apply xtext encoding to the result of step 2.
5. Email header fields downgrading 5. Email header fields downgrading
This section defines the conversion method to ASCII for each header This section defines the conversion method to ASCII for each header
field which may contain non-ASCII characters. field which may contain non-ASCII characters.
[RFC5335] expands Received: header fields, [RFC5322] ABNF elements [RFC5335] expands Received: header fields, [RFC5322] ABNF elements
<mailbox>, <word>, <comment>, <unstructured>, [RFC2045] ABNF element <mailbox>, <word>, <comment>, <unstructured>, [RFC2045] ABNF element
<value>. <value>.
5.1. Downgrading method for each ABNF element
Header field downgrading is defined below for each ABNF element. Header field downgrading is defined below for each ABNF element.
Downgrading an unknown header field is also defined as ENCAPSULATION Downgrading an unknown header field is also defined as ENCAPSULATION
downgrading. Converting the header field terminates when no non- downgrading. Converting the header field terminates when no non-
ASCII characters remain in the header field. ASCII characters remain in the header field.
RECEIVED downgrading: 5.1.1. RECEIVED downgrading
If the header field name is "Received:" and the FOR clause
contains a non-ASCII addresses, remove the FOR clause from the
header field. Other parts (not counting <comment>s) don't contain
non-ASCII values.
UNSTRUCTURED downgrading: If the header field name is "Received:" and the FOR clause contains a
If the header field has an <unstructured> field which contains non-ASCII addresses, remove the FOR clause from the header field.
non-ASCII characters, apply [RFC2047] encoding with charset UTF-8. Other parts (not counting <comment>s) should not contain non-ASCII
values.
5.1.2. UNSTRUCTURED downgrading
If the header field has an <unstructured> field which contains non-
ASCII characters, apply [RFC2047] encoding with charset UTF-8.
5.1.3. WORD downgrading
WORD downgrading:
If the header field has any <word> fields which contains non-ASCII If the header field has any <word> fields which contains non-ASCII
characters, apply [RFC2047] encoding with charset UTF-8. characters, apply [RFC2047] encoding with charset UTF-8.
COMMENT downgrading: 5.1.4. COMMENT downgrading
If the header field has any <comment> fields which contains non-
ASCII characters, apply [RFC2047] encoding with charset UTF-8.
MIME-VALUE downgrading: If the header field has any <comment> fields which contains non-ASCII
If the header field has any <value> elements defined by [RFC2045] characters, apply [RFC2047] encoding with charset UTF-8.
and the elements contain non-ASCII characters, encode the <value>
elements by [RFC2231] with charset UTF-8 and the Language 5.1.5. MIME-VALUE downgrading
information empty. If the <value> element is <quoted-string> and
it contains <CFWS> outside the DQUOTE, remove the <CFWS> before If the header field has any <value> elements defined by [RFC2045] and
this conversion. the elements contain non-ASCII characters, encode the <value>
elements by [RFC2231] with charset UTF-8 and the Language information
empty. If the <value> element is <quoted-string> and it contains
<CFWS> outside the DQUOTE, remove the <CFWS> before this conversion.
5.1.6. DISPLAY-NAME downgrading
DISPLAY-NAME downgrading:
If the header field has any <address> (<mailbox> and <group>) If the header field has any <address> (<mailbox> and <group>)
elements and they have <display-name> elements which contain non- elements and they have <display-name> elements which contain non-
ASCII characters, encode the <display-name> elements according to ASCII characters, encode the <display-name> elements according to
[RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the [RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the same
same algorithm as WORD downgrading. algorithm as WORD downgrading.
5.1.7. MAILBOX downgrading
MAILBOX downgrading:
The <mailbox> elements have no equivalent format for non-ASCII The <mailbox> elements have no equivalent format for non-ASCII
addresses. If the header field has any <mailbox> elements which addresses. If the header field has any <mailbox> elements which
contain non-ASCII characters, preserve the header field in each contain non-ASCII characters, preserve the header field in each
Address header field preservation header defined in Section 3.2, Address header field preservation header defined in Section 3.2, and
and rewrite each <mailbox> element to ASCII only format. The rewrite each <mailbox> element to ASCII only format. The <mailbox>
<mailbox> element which contains non-ASCII characters is one of element which contains non-ASCII characters is one of three formats.
three formats.
* [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>"
Rewrite it as Rewrite it as
[ Display-name ] "<" Addr-spec ">" [ Display-name ] "<" Addr-spec ">"
* [ Display-name ] "<" Utf8-addr-spec ">" o [ Display-name ] "<" Utf8-addr-spec ">"
* Utf8-addr-spec o Utf8-addr-spec
Rewrite both as Rewrite both as
[ Display-name ] "Internationalized Address " Encoded-word [ Display-name ] "Internationalized Address " Encoded-word
" Removed:;" " Removed:;"
where the <Encoded-word> is the original <Utf8-addr-spec> encoded
according to [RFC2047].
where the <Encoded-word> is the original <Utf8-addr-spec> 5.1.8. ENCAPSULATION downgrading
encoded according to [RFC2047].
ENCAPSULATION downgrading:
if the header field contains non-ASCII characters and for which no if the header field contains non-ASCII characters and for which no
rule is given above, encapsulate it in a Downgraded header field rule is given above, encapsulate it in a Downgraded header field
described in Section 3.3 as a last resort. described in Section 3.3 as a last resort.
TYPED-ADDRESS downgrading: Applying this procedure to "Received" header field is prohibited.
If the header field contains <utf-8-type-addr> defined in
[RFC5337] and the <utf-8-type-addr> contains raw non-ASCII
characters, it is utf-8-address form and convert it to utf-8-addr-
xtext form or utf-8-addr-unitext form. COMMENT downgrading is
also performed in this case. If the address type is unrecognized
and the header contains non-ASCII characters, then fall back to
using ENCAPSULATION downgrading on the entire header.
5.1. Downgrading method for each header field 5.1.9. TYPED-ADDRESS downgrading
If the header field contains <utf-8-type-addr> and the <utf-8-type-
addr> contains raw non-ASCII characters, it is utf-8-address form and
convert it to utf-8-addr-xtext form as described in Section 4.2.
COMMENT downgrading is also performed in this case. If the address
type is unrecognized and the header contains non-ASCII characters,
then fall back to using ENCAPSULATION downgrading on the entire
header.
5.2. Downgrading method for each header field
Header fields are listed in [RFC4021]. This section describes the Header fields are listed in [RFC4021]. This section describes the
downgrading method for each header field. downgrading method for each header field.
If the whole mail header field does not contain non-ASCII characters, If the whole mail header field does not contain non-ASCII characters,
email header field downgrading is not required. Each header field's email header field downgrading is not required. Each header field's
downgrading method is described below. downgrading method is described below.
o Address header fields which contain <address>s 5.2.1. Address header fields which contain <address>s
From: From:
Sender: Sender:
Reply-To:
To: To:
Cc: Cc:
Bcc: Bcc:
Reply-To:
Resent-From: Resent-From:
Resent-Sender: Resent-Sender:
Resent-To: Resent-To:
Resent-Cc: Resent-Cc:
Resent-Bcc: Resent-Bcc:
Resent-Reply-To: Resent-Reply-To:
Return-Path: Return-Path:
Disposition-Notification-To: Disposition-Notification-To:
If the header field contains <mailbox> elements which contains If the header field contains <mailbox> elements which contains non-
non-ASCII addresses, preserve the header field in a downgraded ASCII addresses, preserve the header field in a downgraded header
header before the conversion. Then perform COMMENT downgrading, before the conversion. Then perform COMMENT downgrading, DISPLAY-
DISPLAY-NAME downgrading and MAILBOX downgrading. NAME downgrading and MAILBOX downgrading.
o Address header fields with typed addresses 5.2.2. Address header fields with typed addresses
Original-Recipient: Original-Recipient:
Final-Recipient: Final-Recipient:
If the header field contains non-ASCII characters, perform TYPED- If the header field contains non-ASCII characters, perform TYPED-
ADDRESS downgrading. ADDRESS downgrading.
o Downgrading Non-ASCII in comments 5.2.3. Downgrading Non-ASCII in comments
Date: Date:
Message-ID: Message-ID:
Resent-Message-ID: Resent-Message-ID:
In-Reply-To: In-Reply-To:
References: References:
Resent-Date: Resent-Date:
Resent-Message-ID: Resent-Message-ID:
MIME-Version: MIME-Version:
Content-ID: Content-ID:
Content-Transfer-Encoding: Content-Transfer-Encoding:
Content-Language: Content-Language:
Accept-Language: Accept-Language:
Auto-Submitted: Auto-Submitted:
These header fields do not contain non-ASCII characters except in These header fields do not contain non-ASCII characters except in
comments. If the header contains UTF-8 characters in comments, comments. If the header contains UTF-8 characters in comments,
perform COMMENT downgrading. perform COMMENT downgrading.
o Received header field 5.2.4. Received header field
Received: Received:
perform COMMENT downgrading and RECEIVED downgrading. perform COMMENT downgrading and RECEIVED downgrading.
o MIME Content header fields 5.2.5. MIME Content header fields
Content-Type: Content-Type:
Content-Disposition: Content-Disposition:
Perform MIME-VALUE downgrading and COMMENT downgrading. Perform MIME-VALUE downgrading and COMMENT downgrading.
o Non-ASCII in <unstructured> 5.2.6. Non-ASCII in <unstructured>
Subject: Subject:
Comments: Comments:
Content-Description: Content-Description:
Perform UNSTRUCTURED downgrading. Perform UNSTRUCTURED downgrading.
o Non-ASCII in <phrase> 5.2.7. Non-ASCII in <phrase>
Keywords: Keywords:
Perform WORD downgrading. Perform WORD downgrading.
o Other header fields 5.2.8. Other header fields
All other header fields which contains non-ASCII characters are All other header fields which contains non-ASCII characters are user-
user-defined, missing from this draft or future defined header defined, missing from this draft or future defined header fields.
fields. Perform ENCAPSULATION downgrading. Perform ENCAPSULATION downgrading.
If the software understands the header's structure and a If the software understands the header's structure and a downgrading
downgrading algorithm other than ENCAPSULATION is applicable, that algorithm other than ENCAPSULATION is applicable, that software
software SHOULD use that algorithm; ENCAPSULATION downgrading is SHOULD use that algorithm; ENCAPSULATION downgrading is used as a
used as a last resort. last resort.
Any List-* header field containing non-ASCII characters will be Mailing list header fields (those that start in "List-") are part of
turned into Downgraded-List-* header fields. this category.
6. MIME body part headers downgrading 6. MIME body part headers downgrading
MIME body part header fields may contain non-ASCII characters MIME body part header fields may contain non-ASCII characters
[RFC5335]. This section defines the conversion method to ASCII only [RFC5335]. This section defines the conversion method to ASCII only
header fields for each MIME header field which contains non-ASCII header fields for each MIME header field which contains non-ASCII
characters. Parse the message body's MIME structure for all levels characters. Parse the message body's MIME structure for all levels
and check each MIME header field whether it contains non-ASCII and check each MIME header field whether it contains non-ASCII
characters. If the header field contains non-ASCII characters in the characters. If the header field contains non-ASCII characters in the
header value, the header is a target of the MIME body part headers header value, the header is a target of the MIME body part headers
skipping to change at page 16, line 13 skipping to change at page 17, line 22
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Cc Header field name: Downgraded-Cc
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Reply-To Header field name: Downgraded-Bcc
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Bcc Header field name: Downgraded-Reply-To
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-From Header field name: Downgraded-Resent-From
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Sender
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-To Header field name: Downgraded-Resent-To
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Cc Header field name: Downgraded-Resent-Cc
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Sender Header field name: Downgraded-Resent-Bcc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Reply-To
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Return-Path Header field name: Downgraded-Return-Path
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Disposition-Notification-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Furthermore, IANA is requested to refuse registration of all the Furthermore, IANA is requested to refuse registration of all the
field names that start with "Downgraded-" for unknown header fields field names that start with "Downgraded-" for unknown header fields
downgrading described in Section 3.3 to avoid conflicts with existing downgrading described in Section 3.3 to avoid conflicts with existing
IETF activity (Email Address Internationalization). IETF activity (Email Address Internationalization).
10. Acknowledgements 10. Acknowledgements
Significant comments and suggestions were received from John Klensin, Significant comments and suggestions were received from John Klensin,
Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey,
Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S.
skipping to change at page 19, line 30 skipping to change at page 21, line 9
o Comments from the working group last call (wording) o Comments from the working group last call (wording)
11.12. draft-ietf-eai-downgrade: Version 09 11.12. draft-ietf-eai-downgrade: Version 09
o References o References
11.13. draft-ietf-eai-downgrade: Version 10 11.13. draft-ietf-eai-downgrade: Version 10
o Comments from AD Review o Comments from AD Review
12. Normative References 11.14. draft-ietf-eai-downgrade: Version 11
o IETF Last call: Comments from Gen-ART and IANA
o Added new downgraded header field definitions for Resent-Reply-To,
Recent-Bcc and Disposition-Notification-To
o Separated "Email header fields downgrading" section into
subsections
o Updated ORCPT and TYPED-ADDRESS downgrading
12. References
12.1. Normative References
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994. RFC 1652, July 1994.
[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)
skipping to change at page 20, line 44 skipping to change at page 22, line 34
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008. September 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.
12.2. Informative References
[I-D.ietf-eai-dsnbis]
Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications",
draft-ietf-eai-dsnbis-00 (work in progress),
December 2008.
Appendix A. Examples Appendix A. Examples
A.1. Downgrading example 1 A.1. Downgrading example 1
This section shows an SMTP Downgrading example. Consider a mail This section shows an SMTP Downgrading example. Consider a mail
message where: message where:
o The sender address is "NON-ASCII-local@example.com" which is a o The sender address is "NON-ASCII-local@example.com" which is a
non-ASCII address. Its ASCII alternative is non-ASCII address. Its ASCII alternative is
"ASCII-local@example.com" and its display-name is "DISPLAY-local". "ASCII-local@example.com" and its display-name is "DISPLAY-local".
o The "To:" address is "NON-ASCII-remote1@example.net" which is a o The "To:" address is "NON-ASCII-remote1@example.net" which is a
non-ASCII address. Its ASCII alternative is non-ASCII address. Its ASCII alternative is
"ASCII-remote1@example.net" and its display-name is "DISPLAY- "ASCII-remote1@example.net" and its display-name is "DISPLAY-
remote1". remote1".
o The "Cc:" address is a non-ASCII address o The "Cc:" address is a non-ASCII address
"NON-ASCII-remote2@example.org" without alternative ASCII address. "NON-ASCII-remote2@example.org" without alternative ASCII address.
Its display-name is "DISPLAY-remote2". Its display-name is "DISPLAY-remote2".
o Three display-names contain non-ASCII characters. o Three display-names contain non-ASCII characters.
o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
characters. characters.
skipping to change at page 26, line 4 skipping to change at line 1179
Email: fujiwara@jprs.co.jp Email: fujiwara@jprs.co.jp
Yoshiro YONEYA (editor) Yoshiro YONEYA (editor)
JPRS JPRS
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: yone@jprs.co.jp Email: yone@jprs.co.jp
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 55 change blocks. 
132 lines changed or deleted 208 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/