< draft-ietf-eai-utf8headers-11.txt   draft-ietf-eai-utf8headers-12.txt >
Network Working Group Y. Abel, Ed. Network Working Group Y. Abel, Ed.
Internet-Draft TWNIC Internet-Draft TWNIC
Intended status: Experimental April 22, 2008 Intended status: Experimental July 09, 2008
Expires: October 24, 2008 Expires: January 10, 2009
Internationalized Email Headers Internationalized Email Headers
draft-ietf-eai-utf8headers-11.txt draft-ietf-eai-utf8headers-12.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 34 skipping to change at page 1, line 34
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 October 24, 2008. This Internet-Draft will expire on January 10, 2009.
Abstract Abstract
Full internationalization of electronic mail requires not only the Full internationalization of electronic mail requires not only the
capability to transmit non-ASCII content, to encode selected capability to transmit non-ASCII content, to encode selected
information in specific header fields, and to use non-ASCII information in specific header fields, and to use non-ASCII
characters in envelope addresses. It also requires being able to characters in envelope addresses. It also requires being able to
express those addresses and information based on them in mail header express those addresses and information based on them in mail header
fields. This document specifies an experimental variant of Internet fields. This document specifies an experimental variant of Internet
mail that permits the use of Unicode encoded in UTF-8, rather than mail that permits the use of Unicode encoded in UTF-8, rather than
ASCII, as the base form for Internet email header field bodies. This ASCII, as the base form for Internet email header field bodies. This
form is permitted in transmission only if authorized by an SMTP form is permitted in transmission only if authorized by an SMTP
extension, as specified in an associated specification. extension, as specified in an associated specification. And this
specification updates section 6.4 of [RFC2045] to conform with the
requirements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of this specification . . . . . . . . . . . . . . . . 3 1.1. Role of this specification . . . . . . . . . . . . . . . . 3
1.2. Relation to other standards . . . . . . . . . . . . . . . 3 1.2. Relation to other standards . . . . . . . . . . . . . . . 3
2. Background and History . . . . . . . . . . . . . . . . . . . . 3 2. Background and History . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5
4.1. UTF8 Syntax and Normalization . . . . . . . . . . . . . . 5 4.1. UTF8 Syntax and Normalization . . . . . . . . . . . . . . 5
4.2. Changes on MIME headers . . . . . . . . . . . . . . . . . 6 4.2. Changes on MIME headers . . . . . . . . . . . . . . . . . 6
4.3. Syntax extensions to RFC 2822 . . . . . . . . . . . . . . 6 4.3. Syntax extensions to RFC 2822 . . . . . . . . . . . . . . 6
4.4. Change on addr-spec syntax . . . . . . . . . . . . . . . . 8 4.4. Change on addr-spec syntax . . . . . . . . . . . . . . . . 8
4.5. Trace field syntax . . . . . . . . . . . . . . . . . . . . 9 4.5. Trace field syntax . . . . . . . . . . . . . . . . . . . . 9
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. draft-ietf-eai-utf8header-11 . . . . . . . . . . . . . . . 12 8.1. draft-ietf-eai-utf8header-12 . . . . . . . . . . . . . . . 12
8.2. draft-ietf-eai-utf8header-10 . . . . . . . . . . . . . . . 13 8.2. draft-ietf-eai-utf8header-11 . . . . . . . . . . . . . . . 12
8.3. draft-ietf-eai-utf8header-09 . . . . . . . . . . . . . . . 13 8.3. draft-ietf-eai-utf8header-10 . . . . . . . . . . . . . . . 12
8.4. draft-ietf-eai-utf8header-08 . . . . . . . . . . . . . . . 13 8.4. draft-ietf-eai-utf8header-09 . . . . . . . . . . . . . . . 13
8.5. draft-ietf-eai-utf8header-07 . . . . . . . . . . . . . . . 13 8.5. draft-ietf-eai-utf8header-08 . . . . . . . . . . . . . . . 13
8.6. draft-ietf-eai-utf8header-06 . . . . . . . . . . . . . . . 13 8.6. draft-ietf-eai-utf8header-07 . . . . . . . . . . . . . . . 13
8.7. draft-ietf-eai-utf8header-05 . . . . . . . . . . . . . . . 13 8.7. draft-ietf-eai-utf8header-06 . . . . . . . . . . . . . . . 13
8.8. draft-ietf-eai-utf8header-04 . . . . . . . . . . . . . . . 13 8.8. draft-ietf-eai-utf8header-05 . . . . . . . . . . . . . . . 13
8.9. draft-ietf-eai-utf8header-03 . . . . . . . . . . . . . . . 13 8.9. draft-ietf-eai-utf8header-04 . . . . . . . . . . . . . . . 13
8.10. draft-ietf-eai-utf8header-02 . . . . . . . . . . . . . . . 14 8.10. draft-ietf-eai-utf8header-03 . . . . . . . . . . . . . . . 13
8.11. draft-ietf-eai-utf8header-01 . . . . . . . . . . . . . . . 14 8.11. draft-ietf-eai-utf8header-02 . . . . . . . . . . . . . . . 14
8.12. draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 14 8.12. draft-ietf-eai-utf8header-01 . . . . . . . . . . . . . . . 14
8.13. draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 14 8.13. draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 14
8.14. draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
1.1. Role of this specification 1.1. Role of this specification
Full internationalization of electronic mail requires several Full internationalization of electronic mail requires several
capabilities: capabilities:
o The capability to transmit non-ASCII content, provided for as part o The capability to transmit non-ASCII content, provided for as part
skipping to change at page 3, line 36 skipping to change at page 3, line 36
capable of processing it. capable of processing it.
1.2. Relation to other standards 1.2. Relation to other standards
This document updates section 6.4 of RFC 2045. It removes the This document updates section 6.4 of RFC 2045. It removes the
blanket ban on applying a content-transfer-encoding to all subtypes blanket ban on applying a content-transfer-encoding to all subtypes
of message/, and instead specifies that a composite subtype MAY of message/, and instead specifies that a composite subtype MAY
specify whether or not a content-transfer-encoding can be used for specify whether or not a content-transfer-encoding can be used for
that subtype, with "cannot be used" as the default. that subtype, with "cannot be used" as the default.
This document also updates [RFC2822] and MIME, and the fact that an This document also updates [RFC2822] and MIME ([RFC2045]), and the
experimental specification updates a standards-track spec means that fact that an experimental specification updates a standards-track
people who participate in the experiment have to consider those spec means that people who participate in the experiment have to
standards updated. consider those standards updated.
Allowing of use a content-transfer-encoding on subtypes of messages Allowing of use a content-transfer-encoding on subtypes of messages
is not limited to transmissions, which are authorized by the SMTP is not limited to transmissions, which are authorized by the SMTP
extension specified in [I-D.ietf-eai-smtpext]. Message/global extension specified in [I-D.ietf-eai-smtpext]. Message/global
permits use of a content-transfer-encoding. permits use of a content-transfer-encoding.
2. Background and History 2. Background and History
Mailbox names often represent the names of human users. Many of Mailbox names often represent the names of human users. Many of
these users throughout the world have names that are not normally these users throughout the world have names that are not normally
skipping to change at page 4, line 38 skipping to change at page 4, line 38
messages into message stores that might misinterpret, improperly messages into message stores that might misinterpret, improperly
display, or mangle such messages. It should be noted that using an display, or mangle such messages. It should be noted that using an
ESMTP extension does not prevent transfering email messages with ESMTP extension does not prevent transfering email messages with
UTF-8 header fields to other systems that use the email format for UTF-8 header fields to other systems that use the email format for
messages and that may not be upgraded, such as unextended POP and messages and that may not be upgraded, such as unextended POP and
IMAP servers. Changes to these protocols to handle UTF-8 header IMAP servers. Changes to these protocols to handle UTF-8 header
fields are addressed in [I-D.ietf-eai-pop] and fields are addressed in [I-D.ietf-eai-pop] and
[I-D.ietf-eai-imap-utf8] . [I-D.ietf-eai-imap-utf8] .
The objective for this protocol is to allow UTF-8 in email header The objective for this protocol is to allow UTF-8 in email header
fields. Issues about how to handle messages that contain UTF-8 fields. Issues such as how to handle messages containing UTF-8
header fields but are proposed to be delivered to systems that have header fields that have to be delivered to systems that have not been
not been upgraded to support this capability are discussed elsewhere, upgraded to support this capability are discussed in
particularly in [I-D.ietf-eai-downgrade]. [I-D.ietf-eai-downgrade].
3. Terminology 3. Terminology
A plain ASCII string is also a valid UTF-8 string, see [RFC3629]. In A plain ASCII string is also a valid UTF-8 string, see [RFC3629]. In
this document, ordinary ASCII characters are UTF-8 characters if they this document, ordinary ASCII characters are UTF-8 characters if they
are in headers which contain <utf8-xtra-char>s. are in headers which contain <utf8-xtra-char>s.
Unless otherwise noted, all terms used here are defined in [RFC2821], Unless otherwise noted, all terms used here are defined in [RFC2821],
[RFC2822], [RFC4952], or [I-D.ietf-eai-smtpext]. [RFC2822], [RFC4952], or [I-D.ietf-eai-smtpext].
skipping to change at page 5, line 29 skipping to change at page 5, line 29
This protocol does NOT change the [RFC2822] rules for defining header This protocol does NOT change the [RFC2822] rules for defining header
field names. The bodies of header fields are allowed to contain field names. The bodies of header fields are allowed to contain
UTF-8 characters, but the header field names themselves must contain UTF-8 characters, but the header field names themselves must contain
only ASCII characters. only ASCII characters.
To permit UTF-8 characters in field values, the header definition in To permit UTF-8 characters in field values, the header definition in
[RFC2822] must be extended to support new format. The following ABNF [RFC2822] must be extended to support new format. The following ABNF
is defined to substitute those definition in [RFC2822]. is defined to substitute those definition in [RFC2822].
Those syntax rules not referred to in this section remain as the The syntax rules not covered in this section remain as defined in
original definition in [RFC2822]. [RFC2822].
4.1. UTF8 Syntax and Normalization 4.1. UTF8 Syntax and Normalization
UTF-8 characters can be defined in terms of octets using the UTF-8 characters can be defined in terms of octets using the
following ABNF, taken from [RFC3629]: following ABNF, taken from [RFC3629]:
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail UTF8-2 = %xC2-DF UTF8-tail
skipping to change at page 8, line 6 skipping to change at page 8, line 6
utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext)
qcontent = utf8-qcontent qcontent = utf8-qcontent
To allow the use of UTF-8 in a Content-Description header field To allow the use of UTF-8 in a Content-Description header field
[RFC2045], the following syntax is used: [RFC2045], the following syntax is used:
description = "Content-Description:" unstructured CRLF description = "Content-Description:" unstructured CRLF
The <utext> syntax is extended above to allow UTF-8 in all The <utext> syntax is extended above to allow UTF-8 in all
<unstructured> header fields. <unstructured> header fields.
[NOTE IN DRAFT: If any header needs to be restricted to disallow
this, please raise the issue on the mailing list.]
Note, however, this does not remove any constraint on the character Note, however, this does not remove any constraint on the character
set of protocol elements; for instance, all the allowed values for set of protocol elements; for instance, all the allowed values for
timezone in the Date: headers are still expressed in ASCII. And timezone in the Date: headers are still expressed in ASCII. And
also, none of this revised syntax changes what is allowed in a also, none of this revised syntax changes what is allowed in a
<msg-id>, which will still remain in pure ASCII. <msg-id>, which will still remain in pure ASCII.
4.4. Change on addr-spec syntax 4.4. Change on addr-spec syntax
Internationalized email addresses are represented in UTF-8. Thus, Internationalized email addresses are represented in UTF-8. Thus,
all header fields containing <mailbox>es are updated to permit UTF-8 all header fields containing <mailbox>es are updated to permit UTF-8
skipping to change at page 9, line 24 skipping to change at page 9, line 8
; UTF8SMTP but no ALT-ADDRESS parameter provided, ; UTF8SMTP but no ALT-ADDRESS parameter provided,
; message will bounce if UTF8SMTP extension is not supported ; message will bounce if UTF8SMTP extension is not supported
"DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>> "DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>>
; UTF8SMTP with ALT-ADDRESS parameter provided, ; UTF8SMTP with ALT-ADDRESS parameter provided,
; ALT-ADDRESS can be used if downgrade is necessary ; ALT-ADDRESS can be used if downgrade is necessary
4.5. Trace field syntax 4.5. Trace field syntax
"For" fields containing internationalized addresses are allowed, by "For" fields containing internationalized addresses are allowed, by
use of the new uFor syntax. UTF-8 information in needed in Received use of the new uFor syntax. UTF-8 information may be needed in
fields and such information is therefore allowed, to preserve the Received fields. Such information is therefore allowed to preserve
integrity of those fields. The uFor syntax retains the original the integrity of those fields. The uFor syntax retains the original
UTF-8 email address between EAI-aware MTAs. Note that, should UTF-8 email address between EAI-aware MTAs. Note that, should
downgrading be required, the uFor parameter is dropped per the downgrading be required, the uFor parameter is dropped per the
procedure specified in [I-D.ietf-eai-downgrade]. procedure specified in [I-D.ietf-eai-downgrade].
The "Return-Path" header provides the email return address in the The "Return-Path" header provides the email return address in the
mail delivery. Thus, it is augmented to carry UTF8 addresses (see mail delivery. Thus, it is augmented to carry UTF8 addresses (see
the revised syntax of <angle-addr> in Section 4.4 of this document). the revised syntax of <angle-addr> in Section 4.4 of this document).
This will not break the rule of trace field integrity, because it is This will not break the rule of trace field integrity, because it is
added at the last MTA. added at the last MTA.
<item-value> on "Received:" syntax is augmented to allow UTF-8 email The <item-value> on "Received:" syntax is augmented to allow UTF-8
address on "For" clause. <angle-addr> is augmented to include UTF-8 email address on "For" clause. <angle-addr> is augmented to include
email address on previous chapter. To allow UTF-8 email address also UTF-8 email address. To allow UTF-8 email address also on syntax
on syntax corresponding of <addr-spec> on original syntax, <utf8- corresponding of <addr-spec> on original syntax, <utf8-addr-spec> is
addr-spec> is added to <item-value>. added to <item-value>.
item-value =/ utf8-addr-spec item-value =/ utf8-addr-spec
4.6. message/global 4.6. message/global
Internationalized messages must only be transmitted as authorized by Internationalized messages must only be transmitted as authorized by
[I-D.ietf-eai-smtpext] or within a non-SMTP environment which [I-D.ietf-eai-smtpext] or within a non-SMTP environment which
supports these messages. A message is a "message/global message", if supports these messages. A message is a "message/global message", if
o it contains UTF-8 header values as specified in this document, or o it contains UTF-8 header values as specified in this document, or
o it contains UTF-8 values in the headers fields of body parts. o it contains UTF-8 values in the headers fields of body parts.
skipping to change at page 12, line 18 skipping to change at page 11, line 47
In this specification, a user could provide an ASCII alternative In this specification, a user could provide an ASCII alternative
address for a non-ASCII address. However, it is possible these two address for a non-ASCII address. However, it is possible these two
address go to different mailboxes, or even different persons. This address go to different mailboxes, or even different persons. This
configuration may be based on a user's personal choice, or based on configuration may be based on a user's personal choice, or based on
administration policy. We recognize that if ASCII and non-ASCII administration policy. We recognize that if ASCII and non-ASCII
email is delivered to two different destinations, based on MTA email is delivered to two different destinations, based on MTA
capability, this may violate the principle of least astonishment, but capability, this may violate the principle of least astonishment, but
this is not a "protocol problem". this is not a "protocol problem".
The security impact of UTF-8 headers on email signature systems such
as DKIM, S/MIME and OpenPGP is discussed in RFC 4952 section 9. A
subsequent document [I-D.ietf-eai-downgrade] will cover the impact of
downgrading on these systems.
6. IANA considerations 6. IANA considerations
IANA is asked to register the message/global MIME type using the IANA is asked to register the message/global MIME type using the
registration form contained in Section 4.4. registration form contained in Section 4.4.
7. Acknowledgements 7. Acknowledgements
This document incorporates many ideas first described in Internet This document incorporates many ideas first described in Internet
Draft form by Paul Hoffman, although many details have changed from Draft form by Paul Hoffman, although many details have changed from
that earlier work. that earlier work.
skipping to change at page 12, line 44 skipping to change at page 12, line 31
Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris
Newman, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team Newman, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team
and were incorporated into the document. The editor is much great and were incorporated into the document. The editor is much great
thanks to their contribution sincerely. thanks to their contribution sincerely.
8. Edit history 8. Edit history
This section is used for tracking the update of this document. Will This section is used for tracking the update of this document. Will
be removed after finalize. be removed after finalize.
8.1. draft-ietf-eai-utf8header-11 8.1. draft-ietf-eai-utf8header-12
1. Sentences modified
2. Update [RFC2045] into the Abstract
3. Update security mechanisms descriptions in Section 5
8.2. draft-ietf-eai-utf8header-11
1. Sentences modified 1. Sentences modified
8.2. draft-ietf-eai-utf8header-10 8.3. draft-ietf-eai-utf8header-10
1. Revise some paragraphs 1. Revise some paragraphs
2. Correct typos of ABNF 2. Correct typos of ABNF
3. Note <qtext> and <text> of 2822bis 3. Note <qtext> and <text> of 2822bis
4. Fixed some idnits warnning 4. Fixed some idnits warnning
8.3. draft-ietf-eai-utf8header-09 8.4. draft-ietf-eai-utf8header-09
1. Delete Section 5 (Addtional Issues) 1. Delete Section 5 (Addtional Issues)
2. Correct two typos of ABNF 2. Correct two typos of ABNF
3. Refine normalization issue to refer to [RFC5198] 3. Refine normalization issue to refer to [RFC5198]
4. Note <qtext> and <text> of 2822bis 4. Note <qtext> and <text> of 2822bis
5. Revise Section 6 5. Revise Section 6
8.4. draft-ietf-eai-utf8header-08 8.5. draft-ietf-eai-utf8header-08
1. Sentences modified 1. Sentences modified
8.5. draft-ietf-eai-utf8header-07 8.6. draft-ietf-eai-utf8header-07
1. Modify subtype message/utf8smtp to message/global 1. Modify subtype message/utf8smtp to message/global
2. Acknowledgements revise 2. Acknowledgements revise
8.6. draft-ietf-eai-utf8header-06 8.7. draft-ietf-eai-utf8header-06
1. ABNF revise. 1. ABNF revise.
2. Sentences modified 2. Sentences modified
3. Add paragraph in Section 5 3. Add paragraph in Section 5
4. Add paragraph in Section 1.2 4. Add paragraph in Section 1.2
5. Modify Section 4.6 5. Modify Section 4.6
8.7. draft-ietf-eai-utf8header-05 8.8. draft-ietf-eai-utf8header-05
1. ABNF revise. 1. ABNF revise.
2. Remove original the section 4 (Pre-requirement) 2. Remove original the section 4 (Pre-requirement)
3. Add UTF8SMTP message (Section 4.6) 3. Add UTF8SMTP message (Section 4.6)
8.8. draft-ietf-eai-utf8header-04 8.9. draft-ietf-eai-utf8header-04
1. ABNF revise. 1. ABNF revise.
2. Modify uFor description in Section 4.5 2. Modify uFor description in Section 4.5
8.9. draft-ietf-eai-utf8header-03 8.10. draft-ietf-eai-utf8header-03
1. Editrial changes on terms and english. 1. Editrial changes on terms and english.
2. ABNF revise. 2. ABNF revise.
3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with
"<" and ">". "<" and ">".
4. Remove the "Header-Type" header. 4. Remove the "Header-Type" header.
5. Add uFor description in Section 4.5 5. Add uFor description in Section 4.5
6. Remove the content in IANA considerations since "Header-Type" is 6. Remove the content in IANA considerations since "Header-Type" is
removed. removed.
8.10. draft-ietf-eai-utf8header-02 8.11. draft-ietf-eai-utf8header-02
1. Editrial changes on terms and english. 1. Editrial changes on terms and english.
2. Change the header name "UTF8SMTP" to "Header-Type", and ABNF 2. Change the header name "UTF8SMTP" to "Header-Type", and ABNF
revise. revise.
3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with
"[" and "]". "[" and "]".
4. IANA considerations section rewrite. 4. IANA considerations section rewrite.
8.11. draft-ietf-eai-utf8header-01 8.12. draft-ietf-eai-utf8header-01
1. ABNF revise. 1. ABNF revise.
2. Terminology sync with overview document. 2. Terminology sync with overview document.
3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with
"{" and "}". "{" and "}".
4. add IANA considerations to register the new 2822 header 4. add IANA considerations to register the new 2822 header
"UTF8SMTP". "UTF8SMTP".
5. add Security considerations about relation of UTF8SMTP address to 5. add Security considerations about relation of UTF8SMTP address to
ALT-ADDRESS. ALT-ADDRESS.
8.12. draft-ietf-eai-utf8header-00 8.13. draft-ietf-eai-utf8header-00
1. ABNF added. 1. ABNF added.
2. Editrial changes. 2. Editrial changes.
3. Sent it as WG document. 3. Sent it as WG document.
8.13. draft-yeh-ima-utf8header-01 8.14. draft-yeh-ima-utf8header-01
1. Section re-arranged. 1. Section re-arranged.
2. Remove content are not below to this document. 2. Remove content are not below to this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-eai-smtpext] [I-D.ietf-eai-smtpext]
Yao, J. and W. MAO, "SMTP extension for internationalized Yao, J. and W. MAO, "SMTP extension for internationalized
skipping to change at page 15, line 21 skipping to change at page 15, line 14
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
9.2. Informative References 9.2. Informative References
[I-D.ietf-eai-downgrade] [I-D.ietf-eai-downgrade]
Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for
Email Address Internationalization", Email Address Internationalization",
draft-ietf-eai-downgrade-07 (work in progress), draft-ietf-eai-downgrade-07 (work in progress),
March 2008. March 2008.
[I-D.ietf-eai-imap-utf8] [I-D.ietf-eai-imap-utf8]
Resnick, P. and C. Newman, "IMAP Support for UTF-8", Resnick, P. and C. Newman, "IMAP Support for UTF-8",
draft-ietf-eai-imap-utf8-02 (work in progress), draft-ietf-eai-imap-utf8-03 (work in progress),
November 2007. April 2008.
[I-D.ietf-eai-pop] [I-D.ietf-eai-pop]
Newman, C. and R. Gellens, "POP3 Support for UTF-8", Newman, C. and R. Gellens, "POP3 Support for UTF-8",
draft-ietf-eai-pop-03 (work in progress), February 2008. draft-ietf-eai-pop-03 (work in progress), February 2008.
[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.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. 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.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
Author's Address Author's Address
Abel Yang (editor) Abel Yang (editor)
TWNIC TWNIC
4F-2, No. 9, Sec 2, Roosvelt Rd. 4F-2, No. 9, Sec 2, Roosvelt Rd.
Taipei, 100 Taipei, 100
Taiwan Taiwan
Phone: +886 2 23411313 ext 505 Phone: +886 2 23411313 ext 505
Email: abelyang@twnic.net.tw Email: abelyang@twnic.net.tw
 End of changes. 30 change blocks. 
59 lines changed or deleted 69 lines changed or added

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