draft-ietf-eai-downgrade-08.txt   draft-ietf-eai-downgrade-09.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 July 14, 2008 Intended status: Experimental Sep 17, 2008
Expires: January 15, 2009 Expires: March 21, 2009
Downgrading mechanism for Email Address Internationalization Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-08.txt draft-ietf-eai-downgrade-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 15, 2009. This Internet-Draft will expire on March 21, 2009.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New header fields definition . . . . . . . . . . . . . . . . . 5 3. New header fields definition . . . . . . . . . . . . . . . . . 4
3.1. Envelope information preservation headers . . . . . . . . 5 3.1. Envelope information preservation headers . . . . . . . . 5
3.2. Address header field preservation headers . . . . . . . . 5 3.2. Address header field preservation headers . . . . . . . . 5
3.3. Unknown header fields preservation headers . . . . . . . 6 3.3. Unknown header fields preservation headers . . . . . . . 6
4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 7 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Path element downgrading . . . . . . . . . . . . . . . . 7 4.1. Path element downgrading . . . . . . . . . . . . . . . . 7
4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 8 4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 7
5. Email header fields downgrading . . . . . . . . . . . . . . . 8 5. Email header fields downgrading . . . . . . . . . . . . . . . 8
5.1. Downgrading method for each header field . . . . . . . . 9 5.1. Downgrading method for each header field . . . . . . . . 9
6. MIME body part headers downgrading . . . . . . . . . . . . . . 11 6. MIME body part headers downgrading . . . . . . . . . . . . . . 11
7. Security considerations . . . . . . . . . . . . . . . . . . . 12 7. Security considerations . . . . . . . . . . . . . . . . . . . 12
8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 13 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 12
8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 13 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 12
8.2. 7bit transport consideration . . . . . . . . . . . . . . 13 8.2. 7bit transport consideration . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 16 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 16
11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 16 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 16
11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 16 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 16
11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 16 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 16
11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 16 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 16
11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 17 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 17
skipping to change at page 3, line 9 skipping to change at page 3, line 9
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19
A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
Traditional mail systems which are defined by [RFC2821] and [RFC2822] Traditional mail systems which are defined by [RFC2821] and [RFC2822]
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], [I-D.ietf-eai-utf8headers] and The UTF8SMTP extension [RFC4952], [RFC5335] and [RFC5336] allows
[I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and UTF-8 characters in SMTP envelope and mail header field values.
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
path supports UTF8SMTP. This document describes a downgrading path supports UTF8SMTP. This document describes a downgrading
mechanism to avoid rejection of such messages when a server which mechanism to avoid rejection of such messages when a server which
does not support the UTF8SMTP extension is encountered. Downgrading does not support the UTF8SMTP extension is encountered. Downgrading
mechanism converts envelope and header fields to an all-ASCII mechanism converts envelope and header fields to an all-ASCII
representation. representation.
[I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail [RFC5335] allows UTF-8 characters to be used in mail header fields
header fields and MIME header fields. The downgrading mechanism and MIME header fields. The downgrading mechanism specified here
specified here converts mail header fields and MIME header fields to converts mail header fields and MIME header fields to ASCII.
ASCII.
This document does not change any protocols except by defining new This document does not change any protocols except by defining new
header fields. It describes the conversion method from the header fields. It describes the conversion method from the
internationalized email envelopes/messages which are defined in internationalized email envelopes/messages which are defined in
[RFC4952] [I-D.ietf-eai-utf8headers] [I-D.ietf-eai-smtpext] to the [RFC4952] [RFC5335] [RFC5336] to the traditional email envelopes/
traditional email envelopes/messages which are defined in [RFC2821] messages which are defined in [RFC2821] [RFC2822].
[RFC2822].
[I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs. [RFC5336] section 2.2 defines when downgrading occurs. If the SMTP
If the SMTP client has an UTF8SMTP envelope or an internationalized client has an UTF8SMTP envelope or an internationalized message and
message and the SMTP server doesn't support the UTF8SMTP SMTP the SMTP server doesn't support the UTF8SMTP SMTP extension, then the
extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or SMTP client MUST NOT send a UTF8SMTP envelope or an internationalized
an internationalized message to the SMTP server. The section shows 4 message to the SMTP server. The section shows 4 choices. The fourth
choices. The fourth choice is downgrading, as described here. choice is downgrading, as described here.
Downgrading may be implemented in MUAs, MSAs, MTAs which act as the Downgrading may be implemented in MUAs, MSAs, MTAs which act as the
SMTP client, or in MDAs, POP servers, IMAP servers which store or SMTP client, or in MDAs, POP servers, IMAP servers which store or
offer UTF8SMTP envelopes or internationalized messages to non- offer UTF8SMTP envelopes or internationalized messages to non-
UTF8SMTP compliant systems which include message stores. UTF8SMTP compliant systems which include message stores.
This document tries to define the downgrading process clearly and it This document tries to define the downgrading process clearly and it
preserves the original information as much as possible. preserves the original information as much as possible.
Downgrading in UTF8SMTP consists of the following four parts: Downgrading in UTF8SMTP consists of the following four parts:
skipping to change at page 4, line 17 skipping to change at page 4, line 13
In Section 3, many header fields starting with "Downgraded-" are In Section 3, many header fields starting with "Downgraded-" are
introduced. They preserve the original envelope information and the introduced. They preserve the original envelope information and the
original header fields. original header fields.
The SMTP downgrading is described in Section 4. It generates ASCII The SMTP downgrading is described in Section 4. It generates ASCII
only envelope information from an UTF8SMTP envelope. only envelope information from an UTF8SMTP envelope.
The Email header fields downgrading is described in Section 5. It The Email header fields downgrading is described in Section 5. It
generates ASCII only header fields. generates ASCII only header fields.
The MIME header fields are expanded in [I-D.ietf-eai-utf8headers]. The MIME header fields are expanded in [RFC5335]. The MIME header
The MIME header fields downgrading is described in Section 6. It fields downgrading is described in Section 6. It generates ASCII
generates ASCII only MIME header fields. only MIME header fields.
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].
All specialized terms used in this specification are defined in the All specialized terms used in this specification are defined in the
EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents
[RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address",
"internationalized email address", "non-ASCII address", "i18mail "internationalized email address", "non-ASCII address", "i18mail
address", "UTF8SMTP", "message" and "mailing list" are used with the address", "UTF8SMTP", "message" and "mailing list" are used with the
definitions from [RFC4952] document. definitions from [RFC4952] document.
This document depends on [I-D.ietf-eai-smtpext], This document depends on [RFC5335], [RFC5336], and [RFC5337]. Key
[I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used words used in these document are used in this document, too.
in 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.
An "UTF8SMTP envelope" has Email originator/recipient addresses An "UTF8SMTP envelope" has Email originator/recipient addresses
expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. expanded by [RFC5336] and [RFC5337].
An "UTF8SMTP message" is Email messages expanded by An "UTF8SMTP message" is Email messages expanded by [RFC5335].
[I-D.ietf-eai-utf8headers].
3. New header fields definition 3. New header fields definition
New header fields starting with "Downgraded-" are defined here to New header fields starting with "Downgraded-" are defined here to
preserve those original envelope and header values which contain preserve those original envelope and header values which contain
UTF-8 characters. During downgrading, one new "Downgraded-" header UTF-8 characters. During downgrading, one new "Downgraded-" header
field is added for each original envelope or header field which field is added for each original envelope or header field which
cannot be passed as-is to a server which does not support UTF8SMTP. cannot be passed as-is to a server which does not support UTF8SMTP.
The original envelope or header field is removed or rewritten. Only The original envelope or header field is removed or rewritten. Only
those envelope and header fields which contain non-ASCII characters those envelope and header fields which contain non-ASCII characters
skipping to change at page 5, line 38 skipping to change at page 5, line 28
envelope downgraded information consists of the original non-ASCII envelope downgraded information consists of the original non-ASCII
address and the downgraded all-ASCII address. The header field address and the downgraded all-ASCII address. The header field
syntax is specified as follows: syntax is specified as follows:
fields =/ downgradedmailfrom / downgradedrcptto fields =/ downgradedmailfrom / downgradedrcptto
downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS]
"<" Mailbox ">" [FWS] CRLF "<" Mailbox ">" [FWS] CRLF
downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS]
"<" Mailbox ">" [FWS] CRLF "<" Mailbox ">" [FWS] CRLF
Original non-ASCII address <uPath> is defined in Original non-ASCII address <uPath> is defined in [RFC5336]; it is
[I-D.ietf-eai-smtpext]; it is treated as unstructured in this header treated as unstructured in this header and it is encoded according to
and it is encoded according to [RFC2047]. <Mailbox> is defined in [RFC2047]. <Mailbox> is defined in [RFC2821], section 4.1.2.
[RFC2821], section 4.1.2.
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. Any original header field value is original header field value. Any original header field value is
treated as an <unstructured> and it MUST be encoded according to treated as an <unstructured> and it MUST be encoded according to
[RFC2047] with charset='UTF-8'. The header field syntax is specified [RFC2047] with charset='UTF-8'. The header field syntax is specified
as follows: as follows:
skipping to change at page 7, line 18 skipping to change at page 7, line 10
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
Downgrading the <path> of MAIL FROM and RCPT TO commands uses ALT- Downgrading the <path> of MAIL FROM and RCPT TO commands uses ALT-
ADDRESS parameter defined in [I-D.ietf-eai-smtpext]. A SMTP command ADDRESS parameter defined in [RFC5336]. A SMTP command is
is downgradable if the <path> contains non-ASCII address and the downgradable if the <path> contains non-ASCII address and the command
command has an ALT-ADDRESS parameter which specifies an ASCII has an ALT-ADDRESS parameter which specifies an ASCII address. Since
address. Since only non-ASCII addresses are downgradable, specifying only non-ASCII addresses are downgradable, specifying an ALT-ADDRESS
an ALT-ADDRESS value for an all-ASCII address is invalid for use with value for an all-ASCII address is invalid for use with this
this specification, and no interpretation is assigned to it. This specification, and no interpretation is assigned to it. This
restriction allows for future extension of the specification even restriction allows for future extension of the specification even
though no such extensions are currently anticipated. though no such extensions are currently anticipated.
Note that even if no downgrading is performed on the envelope, Note that even if no downgrading is performed on the envelope,
message header fields and message body MIME header fields that message header fields and message body MIME header fields that
contain non-ASCII characters MUST be downgraded. This is described contain non-ASCII characters MUST be downgraded. This is described
in Section 5 and Section 6. in Section 5 and Section 6.
When downgrading, replace each <path> which contains non-ASCII mail When downgrading, replace each <path> which contains non-ASCII mail
address with its specified alternative ASCII address and preserve the address with its specified alternative ASCII address and preserve the
skipping to change at page 8, line 12 skipping to change at page 8, line 4
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" address and the address contains non-ASCII characters, the "utf-8" address and the address contains non-ASCII characters, the
ORCPT parameter MUST be converted to utf-8-addr-xtext form or utf-8- ORCPT parameter MUST be converted to utf-8-addr-xtext form or utf-8-
addr-unitext form which are described in [I-D.ietf-eai-dsn]. addr-unitext form which are described in [RFC5337].
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.
[I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822] [RFC5335] expands Received: header fields, [RFC2822] ABNF elements
ABNF elements <mailbox>, <word>, <comment>, <unstructured>, [RFC2045] <mailbox>, <word>, <comment>, <unstructured>, [RFC2045] ABNF element
ABNF element <value>. <value>.
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: If the header field name is "Received:" and RECEIVED downgrading: If the header field name is "Received:" and
the FOR clause contains a non-ASCII addresses, remove the FOR the FOR clause contains a non-ASCII addresses, remove the FOR
clause from the header field. The other part does not contain clause from the header field. The other part does not contain
non-ASCII values. non-ASCII values.
skipping to change at page 11, line 29 skipping to change at page 11, line 22
Keywords: Keywords:
Perform WORD downgrading. Perform WORD downgrading.
o Other header fields o Other header fields
All other header fields which contains non-ASCII characters are All other header fields which contains non-ASCII characters are
user-defined, missing from this draft or future defined header user-defined, missing from this draft or future defined header
fields. Perform ENCAPSULATION downgrading as a last resort. fields. Perform ENCAPSULATION downgrading as a last resort.
Any List-* header field containing non-ASCII characters will be
turned into Downgraded-List-* header fields.
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
[I-D.ietf-eai-utf8headers]. This section defines the conversion [RFC5335]. This section defines the conversion method to ASCII only
method to ASCII only header fields for each MIME header field which header fields for each MIME header field which contains non-ASCII
contains non-ASCII characters. Parse the message body's MIME characters. Parse the message body's MIME structure for all levels
structure for all levels and check each MIME header field whether it and check each MIME header field whether it contains non-ASCII
contains non-ASCII characters. If the header field contains non- characters. If the header field contains non-ASCII characters in the
ASCII characters in the header value, the header is a target of the header value, the header is a target of the MIME body part headers
MIME body part headers downgrading. Each MIME header field's downgrading. Each MIME header field's downgrading method is
downgrading method is described below. COMMENT downgrading, MIME- described below. COMMENT downgrading, MIME-VALUE downgrading,
VALUE downgrading, UNSTRUCTURED downgrading are described in UNSTRUCTURED downgrading are described in Section 5.
Section 5.
Content-ID: Content-ID:
The Content-ID: header does not contain non-ASCII characters The Content-ID: header does not contain non-ASCII characters
except in comments. If the header contains UTF-8 characters in except in comments. If the header contains UTF-8 characters in
comments, perform COMMENT downgrading. comments, perform COMMENT downgrading.
Content-Type: Content-Type:
Content-Disposition: Content-Disposition:
Perform MIME-VALUE downgrading. Perform MIME-VALUE downgrading.
skipping to change at page 18, line 16 skipping to change at page 18, line 16
o Fixed some typos o Fixed some typos
o Added a text about 7bit transport o Added a text about 7bit transport
11.11. draft-ietf-eai-downgrade: Version 08 11.11. draft-ietf-eai-downgrade: Version 08
o Comments from the working group last call (wording) o Comments from the working group last call (wording)
12. Normative References 12. Normative References
[I-D.ietf-eai-dsn]
Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications",
draft-ietf-eai-dsn-06 (work in progress), January 2008.
[I-D.ietf-eai-smtpext]
Yao, J. and W. MAO, "SMTP extension for internationalized
email address", draft-ietf-eai-smtpext-13 (work in
progress), July 2008.
[I-D.ietf-eai-utf8headers]
Yang, A., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-12 (work in progress),
July 2008.
[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)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
skipping to change at page 19, line 28 skipping to change at page 19, line 12
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
Header Fields", RFC 4021, March 2005. Header Fields", RFC 4021, March 2005.
[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.
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337,
September 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
 End of changes. 23 change blocks. 
73 lines changed or deleted 64 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/