Email Address Internationalization Y. YONEYA, Ed. (EAI) K. Fujiwara, Ed. Internet-Draft JPRS Expires:
November 27,December 28, 2006 MayJun 26, 2006 Downgrading mechanism for Internationalized eMailEmail Address (IMA) draft-ietf-eai-downgrade-00.txtInternationalization (EAI) draft-ietf-eai-downgrade-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 27,December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Traditional mail system handlessystems handle only US-ASCII characters in SMTP envelope and mail headers. The Internationalized eMailEmail Address (IMA)Internationalization (EAI) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver IMANon-ASCII mail address through IMAEAI incompliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP session downgrading, header downgrading and implementation consideration. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 43 3.1. Timing and conditions of downgrading . . . . . . . . . . . 43 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 4 5. SMTP DATA/Header downgrading . . . . . . . . . . . . . . . . . 65 5.1. No header downgrading . . . . . . . . . . . . . . . . . . 6 5.2. Downgrading with MIME encapsulation . . . . . . . . . . . 6 5.2.1. Downgrading with MIME encapsulation example . . . . . 7 5.3. Header conversion . . . . . . . . . . . . . . . . . . . . 9 5.4. Translating each header8 5.3.1. Downgrading address headers . . . . . . . . . . . . . 9 5.3.2. Header conversion example . . . . 9. . . . . . . . . . 10 6. Implementation consideration . . . . . . . . . . . . . . . . . 1012 6.1. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012 6.2. MDA Requirements . . . . . . . . . . . . . . . . . . . . . 1012 7. Security considerations . . . . . . . . . . . . . . . . . . . 1112 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1112 10. Normative References . . . . . . . . . . . . . . . . . . . . . 1112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1314 Intellectual Property and Copyright Statements . . . . . . . . . . 1415 1. Introduction Traditional mail systemsystems which isare defined by [RFC2821] and [RFC2822] allowsallow US-ASCII characters in SMTP envelopenvelope and mail headers. IMAheaders in body part. The EAI proposal [IMA-overview],[IMA-UTF8], [IMA-SMTPext][EAI-Overview],[EAI-UTF8], [EAI-SMTPext] allows UTF-8 characters in SMTP envelopenvelope and mail headers.headers in body part. Carrying IMANon-ASCII mail address from sender to recipients requires all components on the mail delivery route are IMAEAI compliant. Otherwise IMANon-ASCII mail address can't be delivered. To solve the problem, this document describes downgrading mechanism that enables delivering IMANon-ASCII mail address by converting it to corresponding US-ASCII representation on current mail delivery system. Not only SMTP envelope, but also UTF-8 characters in mail headers MUST be converted to US-ASCII. Downgrading in IMAEAI consists from following two parts: o SMTP session downgradedowngrading o header downgradedowngrading Decoding downgraded envelope/message is called 'Upgrading' in this document. Each downgrading mechanism has corresponding upgrading mechanism. In this document, requirements for downgrading is described in section Section 3, SMTP session downgradedowngrading is described in Section 4, and mail header downgradedowngrading is described in Section 5. 2. Terminology This document assumes a reasonable understanding of the protocols and terminology of the core email standards as documented in [RFC2821] and [RFC2822]. Much of the description inTerminology for this document depends on the abstractions of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). However, itis important to understand that those terms and the underlying concepts postdate the design of the Internet's email architecture and the "protocols on the wire" principle. That email architecture, as it has evolved, and the "wire" principle have prevented any strong and standardized distinctions about how MTAs and MUAs interact on a given origin or destination host (or even whether they are separate). The final ("delivery") MTA stores Mail messagesdefined in a "message store" or resends messages where the receiver has assigned. In this document, this function is called Mail Delivery Agent(MDA).[EAI-Overview]. In this document, an address is "all-ASCII" if every character in the address"algorithmic address" is in the ASCII character repertoire [ASCII];an US-ASCII address which is "non-ASCII" if any character is not in the ASCII character repertoire. The term "all-ASCII" is also applied to other protocol elements when the distinction is important, with "non-ASCII" or "internationalized" as its opposite. The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119].generated by algorithmic method. 3. Downgrade Requirements 3.1. Timing and conditions of downgrading This section describes timing and conditions of downgrading. o Timing: SMTP client detects that SMTP server doesn't support "IEmail" option at EHLO. [IMA-SMTPext][EAI-SMTPext] o Conditions: SMTP client detects that UTF-8 is included in the SMTP envelope or mail headers.headers in the SMTP DATA. Note: If the i18n-emaili-Email header exists, downgrading will be performed. If UTF-8 characters exist in mail headers are presentwithout the i18n-emaili-Email header, this is a protocol error, and handling of this situation is outside the scope of this specification. 3.2. Requirements 1. Downgrading must be performed only once. 2. Upgrading must be performed at minimized place such as final destination like recipient MUA. 3. Downgrading and decodingupgrading must be automated. 4. Downgrading and decodingupgrading should be easy and lightweight as it is possible to do with MTA like 8BITMIME encapsulation. 5. Downgrade and upgrade method must be defined clearly. 6. Downgrading and decodingupgrading should preserve all header information. 7. Downgrading must support SPF and DKIM. 8. Downgrading occurrence must be recorded. 4. SMTP Downgrading Downgrading MUST be performed in each SMTP session. Target of downgrading elements in SMTP envelope are below: o MAIL FROM: o RCPT TO: Downgrading in SMTP envelope uses ALT-ADDR and ATOMIC option proposed in [IMA-SMTPext]. If downgrading[EAI-SMTPext]. Downgrading is expected,possible only when a mail sendersender's MUA MUST append ALT-ADDRappends ALT- ADDR or ATOMIC option to all IMANon-ASCII envelope addresses to denote their alternative US- ASCII address when sending mail.US-ASCII address. When MUA/MTA is transferring mail and finding its envelope is IMA,Non- ASCII, it MUST decide to bounce or downgrade if receiving MTA is IMAEAI incompliant. Both ALT-ADDR parameter and ATOMIC parameter is specified in one envelope from/to, use ALT-ADDR parameter and ignore ATOMIC parameter. Further, even if no downgrading is performed for envelope from/to, MUA/MTA MUST downgrade headers including UTF-8 or bounce. This is described in next section. MTA MAY downgrade messages that envelope from/to of IMA have ALT-ADDR with alternative US-ASCII address or ATOMIC is "y".MTA generates alternative US-ASCII address when ALT-ADDR option is not specified and ATOMIC is "y". Alternative US-ASCIIFurther, even if no downgrading is performed for envelope from/to, MUA/MTA MUST downgrade mail headers including UTF-8 or bounce. This is described in next section. Algorithmic address generation algorithms aremethod is below: domain-part: Punycode/IDNA [RFC3490] local-part: Punycode[RFC3492] without normalization. Prefix MUST be assigned by IANA (which is not "xn--"). MTA replaces IMANon-ASCII mail address with specified or generated alternative US-ASCII address. Then appends replaced information with IMA-Downgraded-FromEAI-Downgraded-From and IMA-Downgraded-ToEAI-Downgraded-To header in mail header (outgoing SMTP DATA). IMA-Downgraded-From: <IMA>EAI-Downgraded-From: <Non-ASCII,ATOMIC> <US-ASCII> EAI-Downgraded-From: <Non-ASCII,US-ASCII> <US-ASCII> IMA-Downgraded-To: <IMA>EAI-Downgraded-To: <Non-ASCII,ATOMIC> <US-ASCII> EAI-Downgraded-To: <Non-ASCII,US-ASCII> <US-ASCII> Note that when downgrading, not to disclose whole recipient address, MUA/MTA SHOULD make SMTP connection per each recipient address. Also note that by appending IMA-Downgraded-From/ToEAI-Downgraded-From/To headers, MUA/MTA MUST perform SMTP/HeaderSMTP DATA/Header downgrading. This is described in next section. Downgraded envelope tolocal-part is parsed only in MDA. MDA and delivereddelivers the mail to final mailbox. Case study: SPF check SPF checks envelope from'sdomainname of the envelope from and smtp connection IP address. If ALT-ADDR'sALT-ADDR domainname is Punycode/IDNA form of IMANon-ASCII domainname, it is equal to SPF/IMA (need to define).will be compatible with current SPF. In this case, SPF check will be performed correctly. Otherwise, more detailed consideration is required. 5. SMTP DATA/Header downgrading In this section, fourthree methods for SMTP DATA/Header downgrading is proposed. Working group should select one. o No header downgrading o Encapsulating whole SMTP DATA o Translating each header o Encapsulating each headerTarget and non-target of downgrading elements in mail headers (SMTP data) are below: Originator address(es): IMANon-ASCII mail addresses in From, Reply-To, Sender and their Resent- headers MUST be target of downgrading. Destination address(es): IMANon-ASCII mail addresses in To, CC, Bcc and their Resent- headers MUST be target of downgrading. IDs: IDs such as Message-ID, Date, In-Reply-To and References MUST NOT be target of downgrading. Trace headers: Received headers which contains IMANon-ASCII mail addresses MUST be target of downgrading. other headers: UTF-8 in other headers MUST be target of downgrading. Rewriting Received header is prohibited in [RFC2821] Section 4.4 Trace field. But downgrading may be considered as the 'Mail Gatewaying' which is described in [RFC2821] Section 3.8. If it is true, these downgrading methods are acceptable. 5.1. No header downgrading Most MTAs support 8bit characters in mail headers. Currently, mail systems in some countries or languages use raw 8bit header value in their local encoding. This method does not care about using UTF-8 headers in existing mail systems. Pros: * Easy to implement. Cons: * This method may break existing mail infrastructure. 5.2. Downgrading with MIME encapsulation This downgradedowngrading method requires new MIME 'Content-Type:' which express EAI(Email Address Internationalization).EAI. This document assumes 'Content-Type: Message/EAI' existence. Downgrading: * If mail header contains UTF-8 data, downgrade whole message to be MIME encoded. Whole message becomes new MIME part (Message/ EAI). * Originator Addresses (From, Sender, etc.), Destination Addresses (To, CC, etc.), IDs (Message-ID, etc.),Message-ID, Subject, Date headers are copied from original header. * IfFrom header contains IMA, itis replacedgenerated with downgraded Envelope-from. * IfTo or CC headers contain IMA, they are replacedheader is generated with single downgraded envelope-to as To header.Envelope-to. * If Subject header contains UTF-8, it is replaced to a certain message or encoded by RFC2047.MIME [RFC2047]. * Message-ID, Date headers are preserved. As a result, new body contains one new MIME part (Message/EAI). Encoding example Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(unique_string)--" Content-Transfer-Encoding: 8bit Subject: DOWNGRADED_SUBJECT From: DOWNGRADED_FROM To: DOWNGRADED_TO Date: DATE ----Next_Part(unique_string)-- Content-Type: Message/EAI Content-Transfer-Encoding: 8bit Content-Disposition: inline IMA-Downgraded-From: <IMA> <DOWNGRADED_FROM> IMA-Downgraded-To: <IMA> <DOWNGRADED_TO> Received: ... for IMA Received: ... for IMA Message-Id: MESSAGE_ID Mime-Version: 1.0 Subject: UTF-8_SUBJECT From: IMA To: IMA Date: DATE MAIL_BODY ----Next_Part(unique_string)---- Figure 1Upgrading: * If mail message contains only one MIME part and its Content- Type is 'Message/EAI', it may be a downgraded message. To check if downgraded,it is a downgraded message, compare mail body's message-id and MIME part's message-id. If message-ids are the same, it is a downgraded message. Then, treat MIME part as entire mail message. * When checking trace field, checker SHOULD check Received header both in wrapping headers and headers in encapsulated part. Case study: DKIM DKIM checker performs decodingupgrading the downgraded message first. Pros: * MTA does not need to decode each headersheader carefully. * Whole headers can be submitted AS IS. Cons: * IMANon-ASCII from/to can not distinguish from encodeddowngraded mail headers. * IMAEAI incompliant MUA can not treat encoded message.any downgraded mail. [[Reference to [EAI-Scenarios] and evaluation of each case should be described here.]] 5.2.1. Downgrading with MIME encapsulation example Downgrading example Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(unique_string)--" Content-Transfer-Encoding: 8bit Subject: DOWNGRADED_SUBJECT From: <US-ASCII_FROM> To: <US-ASCII_TO> Date: DATE ----Next_Part(unique_string)-- Content-Type: Message/EAI Content-Transfer-Encoding: 8bit Content-Disposition: inline EAI-Downgraded-From: <Non-ASCII,ATOMIC> <US-ASCII_FROM> EAI-Downgraded-To: <Non-ASCII,ATOMIC> <US-ASCII_TO> Received: ... Received: ... Message-Id: MESSAGE_ID Mime-Version: 1.0 Subject: UTF-8_SUBJECT From: <Non-ASCII,ATOMIC> To: <Non-ASCII,ATOMIC> Date: DATE MAIL_BODY ----Next_Part(unique_string)---- 5.3. Header conversion Define conversion method to US-ASCII for all headers which contains IMA. Eacheach header has its own downgrading method. Basically, MIME encoding of RFC 2047. Recipient/Sender addresses and Received headerswhich may contain IMA need special processing.Non-ASCII characters. Each header has its own downgrading method. To preserve all header information, define generic encapsulation header: "Downgraded: HeaderName: HeaderValue". The header value is encoded by [RFC2047] with UTF-8 tag. Downgrading: From, To, CC, Resent-From, Resent-To headers which* For all headers, check if the header contains Originator/Destination address(es): Extract every addr-spec [RFC2822] of mailboxes which includesUTF-8 characters. For each addr-spec, if it includes UTF-8, convert it into ACE with* Encapsulate 'i-Email' header in Downgraded header. * If the same methodheader contains UTF-8 characters, + If the header is an address header which is described in Section 4. Original IMA SHOULD remain as a comment encoded by MIME with UTF-8 tag [RFC2047]. Note that some special characters5.3.1, - Preserve the header in addr-spec MUST be escaped. If mailbox elements except for addr-spec include UTF-8, those MUST be encoded by base64 with UTF-8 tag. Downgrading'Downgraded' header. - Downgrade the header defined in Section 5.3.1. + The other header: Encode UTF-8 characters of headersheader case, encode the header by MIME[RFC2047] with UTF-8 tag [RFC2047].tag. Upgrading: * If the mail has 'Downgraded' headers, the mail is a downgraded EAI mail message. * Decode all 'Downgraded' header. + Decode header value field string which is [RFC2047] encoded. + If the header is address headers described in Section 5.3.1, - Apply address header downgrading to the decoded header. - Remove the header line which is same to the downgraded line. + Remove the 'Downgraded' header. + Add decoded header to mail header. "HeaderName: HeaderValue". * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header.header, so decode it. Pros: * IMAEAI incompliant MUA can displaydisplays the downgraded mail body except fororiginal IMA from/to.Non-ASCII mail addresses. * EAI incompliant MUA displays and handles the sender specified or algorithmic address. * EAI compliant MUA displays and handles original headers. Cons: * Implementation and processing cost is difficulthigher than 'Header Encapsulation' defined in Section 5.2 because MUA/MTA must parse each header and encode it by defined method. * Hard to preserve whole information AS IS. The address headers are preserved but the other headers which is [RFC2047] encoded with UTF-8 tag are not distinguished that it is downgraded or it is encoded by sender's MUA. Therefore, to check DKIM requires special consideration. 5.4. Translating[[Reference to [EAI-Scenarios] and evaluation of each header Define generic encapsulation header: "Downgraded: HeaderName: HeaderValue". Header value is encoded in [RFC2047] with UTF-8 tag. Downgrading: Allcase should be described here.]] 5.3.1. Downgrading address headers which contains UTF-8 characters are encapsulated to generic encapsulation header. There is no special handling for recipient/sender addresses inThis section targets From, Sender, Reply-To, To, CC, Resent-* headers. ReceivedBCC, Resent- From, Resent-To, Resent-CC, Resent-Bcc, Resent-sender headers need special consideration.which contains Originator/Destination address(es). The header value is composed of single or multiple mailbox/angle-addr fields defined in [EAI-UTF8]. If the header contains UTF-8 characters, downgrading process encapsulates From header,method is follows. 1. Extract every field and downgrade processmailbox/angle-addr described below. 2. By mailbox/angle-addr downgrading, if the field became empty, the field should generate Frombe removed. 3. If all header fromfield is removed, remove the envelope from address with downgraded mark in comment field.header. 4. If downgrading process encapsulates all To, CC headers, downgrade process shouldFrom header is removed, generate Tonew From header from the envelope to address with downgraded markenvelope-from address. EAI angle-addr defined in comment field. Upgrading: If[EAI-UTF8] consists of 4 forms. Downgrading method is defined for each form. 1. <Non-ASCII> Non-ASCII mail header has [RFC2047] encoded partaddress without ALT-ADDR and ATOMIC parameter case, remove this angle-addr. 2. <Non-ASCII,US-ASCII> Non-ASCII mail address with sender-specified US-ASCII address case, replace it as <US-ASCII>. 3. <Non-ASCII,ATOMIC> Non-ASCII mail address with ATOMIC parameter case, generate the algorithmic address from Non-ASCII mail address and which encoding is "UTF-8",replace it as <ALG-ASCII>. 4. <US-ASCII> US-ASCII mail address case, preserve it. "mailbox" is downgraded header anddefined as "DISPLAY NAME angle-addr" in [EAI-UTF8]. The "DISPLAY NAME" field should be encoded by [RFC2047] with UTF-8 tag, if necessary. If the upgrading process decode this header. Pros: * IMA incompliant MUA can display mail body except for original IMA from/to. * Implementationangle-addr is easier than Section 5.3 Cons: * This method may break [RFC2821] [RFC2821]. * Hard to preserve whole information AS IS. Therefore, to check DKIM requires special consideration.removed, remove the field including "DISPLAY NAME". 5.3.2. Header conversion example Original EAI message i-Email: 1.0 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF-8_SUBJECT From: <NON-ASCII-FROM,ASCII-FROM> To: <NON-ASCII-TO,ASCII-TO> CC: <NON-ASCII-CC,ASCII-CC> Date: DATE MAIL_BODY SMTP downgrading adds EAI-Downgraded-From, EAI-Downgraded-To headers. EAI-Downgraded-From: <Non-ASCII,DOWNGRADED_FROM> <DOWNGRADED_FROM> EAI-Downgraded-To: <Non-ASCII,DOWNGRADED_TO> <DOWNGRADED_TO> Result of the header conversion downgrading. EAI-Downgraded-From: MIME(<Non-ASCII,DOWNGRADED_FROM>) <DOWNGRADED_FROM> EAI-Downgraded-To: MIME(<Non-ASCII,DOWNGRADED_TO>) <DOWNGRADED_TO> Downgraded: i-Email: 1.0 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: MIME(UTF-8_SUBJECT) Downgraded: From: MIME(<NON-ASCII-FROM,ASCII-FROM>) From: <ASCII-FROM> Downgraded: To: MIME(<NON-ASCII-TO,ASCII-TO>) To: <ASCII-TO> Downgraded: CC: MIME(<NON-ASCII-CC,ASCII-CC>) CC: <ASCII-CC> Date: DATE MAIL_BODY MIME() stands for [RFC2047] encoding. 6. Implementation consideration 6.1. MUA IMAEAI compliant MUA MUST implement downgradedowngrading mechanism for sending. MUA MAY encode UTF-8 in Subject header with the same encoding of body part while downgrading. IMAEAI compliant MUA MUST decodeupgrade downgraded mail and MUST show IMANon- ASCII mail addresses on display. 6.2. MDA Requirements This section describes downgrading in MDA. 1. MDA MUST NOT convert downgraded header to UTF-8.upgrade. 2. Record Return-Path header in ACE form. 3.Perform downgrading for each Storage/Back-end-Process. If and only if MDA knows recipient's MUA is IMAEAI compliant, then no downgrading is performed. 4.3. If MDA detects that SMTP recipient address is downgraded IMA,an algorithmic address, then MDA MUST decode IMAit and perform the same processing as if it were IMA.Non-ASCII mail address. MDA MAY normalize or canonicalize local-part before processing it. 7. Security considerations See the extended security considerations discussion in [IMA-overview][EAI-Overview] 8. IANA Considerations To distinguish downgraded IMANon-ASCII mail addresses in ACE form, it MUST have ACE-Prefix. The ACE-Prefix MUST differ from IDNA ACE-PrefixACE- Prefix to avoid possible confusion. IANA will assign IMANon-ASCII mail address ACE-Prefix when RFC is published. 9. Acknowledgements John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, Marcos Sanz, Alexey Melnikov, and JET members. 10. Normative References [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. [Hoffman-IMAA] Hoffman, P. and A. Costello, "Internationalizing Mail Addresses in Applications (IMAA)", draft-hoffman-imaa-03 (work in progress), October 2003. [IMA-Constraints][EAI-Overview] Klensin, J., "Internationalization in Internet Applications: Issues, Tradeoffs,J. and Email Addresses", draft-klensin-ima-constraints-00Y. Ko, "Overview and Framework for Internationalized Email", draft-ietf-eai-framework-01 (work in progress), Febrary 2006. [IMA-SMTPext]progress). [EAI-SMTPext] Yao, J., Ed., "SMTP extension for internationalized email address", draft-ietf-eai-smtpext-00 (work in progress), Febrary 2006. [IMA-UTF8] Yeh, J.,[EAI-Scenarios] Alvestrand, H., "Internationalized Email Headers", draft-yeh-ima-utf8headers-01 (work in progress), February 2006. [IMA-overview] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", draft-ietf-eai-framework-00Addresses: Scenarios", draft-ietf-eai-scenarios-00 (work in progress), May 2006. [JET-IMA] Yao, J. and J.[EAI-UTF8] Yeh, "Internationalized eMail Address (IMA)", draft-lee-jet-ima-00 (work in progress), June 2005. [Klensin-emailaddr] Klensin,J., "Internationalization of"Internationalized Email Addresses", draft-klensin-emailaddr-i18n-03Headers", draft-yeh-ima-utf8headers-01 (work in progress), July 2005. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1651] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1651, July 1994.February 2006. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.Authors' Addresses Yoshiro YONEYA (editor) JPRS Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: firstname.lastname@example.org Kazunori Fujiwara (editor) JPRS Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: email@example.com Intellectual Property Statement 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 firstname.lastname@example.org. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.