Email Address Internationalization                        Y. YONEYA, Ed.
(EAI)                                                   K. Fujiwara, Ed.
Internet-Draft                                                      JPRS
Expires: November 27, December 28, 2006                                  May                                  Jun 26, 2006

   Downgrading mechanism for Internationalized eMail Email Address (IMA)
                       draft-ietf-eai-downgrade-00.txt Internationalization (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 handles systems handle only US-ASCII characters in SMTP
   envelope and mail headers.  The Internationalized eMail Email Address (IMA) Internationalization
   (EAI) is implemented by allowing UTF-8 characters in SMTP envelope
   and mail headers.  To deliver IMA Non-ASCII mail address through IMA EAI
   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 . . . . . . . . . . . . . . . . . . . .  4  3
     3.1.  Timing and conditions of downgrading . . . . . . . . . . .  4  3
     3.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  SMTP DATA/Header downgrading . . . . . . . . . . . . . . . . .  6  5
     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 header  8
       5.3.1.  Downgrading address headers  . . . . . . . . . . . . .  9
       5.3.2.  Header conversion example  . . . .  9 . . . . . . . . . . 10
   6.  Implementation consideration . . . . . . . . . . . . . . . . . 10 12
     6.1.  MUA  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12
     6.2.  MDA Requirements . . . . . . . . . . . . . . . . . . . . . 10 12
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 11 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 11 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 14 15

1.  Introduction

   Traditional mail system systems which is are defined by [RFC2821] and [RFC2822]
   allows
   allow US-ASCII characters in SMTP envelop envelope and mail headers.  IMA headers in body
   part.  The EAI proposal [IMA-overview],[IMA-UTF8], [IMA-SMTPext] [EAI-Overview],[EAI-UTF8], [EAI-SMTPext]
   allows UTF-8 characters in SMTP envelop envelope and mail headers. headers in body
   part.

   Carrying IMA Non-ASCII mail address from sender to recipients requires
   all components on the mail delivery route are IMA EAI compliant.
   Otherwise IMA Non-ASCII mail address can't be delivered.  To solve the
   problem, this document describes downgrading mechanism that enables
   delivering IMA Non-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 IMA EAI consists from following two parts:
   o  SMTP session downgrade downgrading
   o  header downgrade downgrading

   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 downgrade downgrading is described in
   Section 4, and mail header downgrade downgrading 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 in

   Terminology for this document depends on the abstractions
   of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA").
   However, it is 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 messages defined 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-email i-Email header exists, downgrading will be performed.
   If UTF-8 characters exist in mail headers are present without the i18n-email i-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 decoding upgrading must be automated.
   4.  Downgrading and decoding upgrading 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 decoding upgrading 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 sender sender's MUA MUST append ALT-ADDR appends ALT-
   ADDR or ATOMIC option to all IMA Non-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 IMA EAI
   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-ASCII

   Further, 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 are method 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 IMA Non-ASCII mail address with specified or generated
   alternative US-ASCII address.  Then appends replaced information with IMA-Downgraded-From
   EAI-Downgraded-From and IMA-Downgraded-To EAI-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/To EAI-Downgraded-From/To headers, MUA/MTA
   MUST perform SMTP/Header SMTP DATA/Header downgrading.  This is described in next
   section.

   Downgraded envelope to local-part is parsed only in MDA.  MDA and delivered delivers the mail
   to final mailbox.

   Case study: SPF check

   SPF checks envelope from's domainname of the envelope from and smtp connection IP
   address.  If ALT-ADDR's ALT-ADDR domainname is Punycode/IDNA form of IMA Non-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, four three 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 header

   Target and non-target of downgrading elements in mail headers (SMTP
   data) are below:

   Originator address(es): IMA Non-ASCII mail addresses in From, Reply-To,
      Sender and their Resent- headers MUST be target of downgrading.
   Destination address(es): IMA Non-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 IMA Non-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 downgrade downgrading 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.
      *  If  From header contains IMA, it is replaced generated with downgraded Envelope-from.
      *  If  To or CC headers contain IMA, they are replaced header 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 1

   Upgrading:
      *  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 decoding upgrading the downgraded message first.

   Pros:
      *  MTA does not need to decode each headers header carefully.
      *  Whole headers can be submitted AS IS.
   Cons:
      *  IMA  Non-ASCII from/to can not distinguish from encoded downgraded mail
         headers.
      *  IMA  EAI 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.

   Each each header has its own downgrading method.  Basically, MIME encoding
   of RFC 2047.  Recipient/Sender addresses and Received headers which 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 includes UTF-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 method header 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 characters 5.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 headers header 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:
      *  IMA  EAI incompliant MUA can display displays the downgraded mail body except for
         original
         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 difficult higher 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:
         All case 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 in

   This section targets From, Sender, Reply-To, To, CC, Resent-* headers.
         Received BCC, 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
         process mailbox/angle-addr described
       below.
   2.  By mailbox/angle-addr downgrading, if the field became empty, the
       field should generate From be removed.
   3.  If all header from field 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 should From header is removed, generate To new From header from the envelope
         to address with downgraded mark
       envelope-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 part address 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 and defined 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.
      *  Implementation angle-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

   IMA

   EAI compliant MUA MUST implement downgrade downgrading mechanism for sending.

   MUA MAY encode UTF-8 in Subject header with the same encoding of body
   part while downgrading.

   IMA

   EAI compliant MUA MUST decode upgrade downgraded mail and MUST show IMA Non-
   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 IMA EAI 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 IMA it 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 IMA Non-ASCII mail addresses in ACE form, it
   MUST have ACE-Prefix.  The ACE-Prefix MUST differ from IDNA ACE-Prefix ACE-
   Prefix to avoid possible confusion.  IANA will assign IMA Non-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-00 Y. 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-00 Addresses:
              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-03 Headers",
              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: yone@jprs.co.jp

   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: fujiwara@jprs.co.jp

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
   ietf-ipr@ietf.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.