Email Address Internationalization                        Y. YONEYA, Ed.
(EAI)                                                   K. Fujiwara, Ed.
Internet-Draft                                                      JPRS
Expires: December 28, 2006                                  Jun 26,
Intended status: Experimental                               Aug 16, 2006
Expires: February 17, 2007

   Downgrading mechanism for Email Address Internationalization (EAI)
                    draft-ietf-eai-downgrade-01.txt
                    draft-ietf-eai-downgrade-02.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 December 28, 2006. February 17, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Traditional mail systems handle only US-ASCII characters in SMTP
   envelope and mail headers.  The Email Address Internationalization
   (EAI) is implemented by allowing UTF-8 characters in SMTP envelope
   and mail headers.  To deliver Non-ASCII mail address through EAI
   incompliant environment, some sort of converting mechanism (i.e.
   downgrading) is required.  This document describes requirements for
   downgrading, SMTP session downgrading, header downgrading Downgrading, SMTP DATA/Header Downgrading and
   implementation consideration.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Downgrade Requirements . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Timing and conditions of downgrading . . . . . . . . . . .  3
     3.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  SMTP DATA/Header downgrading Downgrading . . . . . . . . . . . . . . . . .  5
     5.1.  No header downgrading  Header conversion  . . . . . . . . . . . . . . . . . . . .  6
     5.2.
       5.1.1.  Downgrading with MIME encapsulation address headers  . . . . . . . . . . .  6
       5.2.1.  Downgrading with MIME encapsulation example . .  7
   6.  Implementation consideration . . .  7
     5.3.  Header conversion . . . . . . . . . . . . . .  8
     6.1.  MUA  . . . . . .  8
       5.3.1.  Downgrading address headers . . . . . . . . . . . . .  9
       5.3.2.  Header conversion example . . . . . . . .  8
   7.  Security considerations  . . . . . . 10
   6.  Implementation consideration . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . 12
     6.1.  MUA . . . . . . . . . . . . . . . . .  8
   9.  Acknowledgements . . . . . . . . . . 12
     6.2.  MDA Requirements . . . . . . . . . . . . .  8
   10. Change History . . . . . . . . 12
   7.  Security considerations . . . . . . . . . . . . . . . .  8
     10.1. draft-yoneya-ima-downgrade: Version 00 . . . 12
   8.  IANA Considerations . . . . . . .  8
     10.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . .  9
     10.3. draft-ietf-eai-downgrade: Version 00 . . . . 12
   9.  Acknowledgements . . . . . . .  9
     10.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . .  9
     10.5. draft-ietf-eai-downgrade: Version 02 . . . . . 12
   10. . . . . . .  9
   11. Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 10
     A.1.  SMTP Downgrading Example . . . . . . . . . . . . . . . . . 10
     A.2.  Header conversion downgrading example  . . . . . . . . . . 12
     A.3.  Header conversion upgrading example  . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 15 17

1.  Introduction

   Traditional mail systems which are defined by [RFC2821] and [RFC2822]
   allow US-ASCII characters in SMTP envelope and mail headers in body
   part.  The EAI proposal [EAI-Overview],[EAI-UTF8], [EAI-SMTPext] [I-D.ietf-eai-framework],
   [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8
   characters in SMTP envelope and mail headers in body part.

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

2.  Terminology

   Terminology for this document is defined in [EAI-Overview].

   In this document, "algorithmic address" is an US-ASCII address which
   is generated by algorithmic method. [I-D.ietf-eai-framework].

3.  Downgrade Requirements

3.1.  Timing and conditions of downgrading

   This section describes

   Followings are timing and conditions of downgrading.
   o

   Timing:  SMTP client detects that SMTP server doesn't support
      "IEmail"
      "UTF8SMTP" option at EHLO.  [EAI-SMTPext]
   o  [I-D.ietf-eai-smtpext]
   Conditions:  SMTP client detects that UTF-8 is included in the SMTP
      envelope or mail headers in the SMTP DATA.

   Note: If the i-Email UTF8SMTP header exists, downgrading will be performed.
   If UTF-8 characters exist in mail headers without the i-Email UTF8SMTP
   header, this is a protocol error, and handling of this situation is
   outside the scope of this specification.

3.2.  Requirements

   Followings are requirements of downgrading.

   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 upgrading must be automated.
   4.  Downgrading and 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 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 ALT-ADDRESS parameter proposed in [EAI-SMTPext].

   Downgrading
   [I-D.ietf-eai-smtpext].  An address is possible only when a mail sender's MUA appends ALT-
   ADDR downgradable if the address is
   all-ASCII address or ATOMIC option to all Non-ASCII the address has all-ASCII address specified by
   ALT-ADDRESS parameter.

   If the return address in the envelope addresses to denote
   their alternative US-ASCII address.

   When MUA/MTA ("MAIL FROM:") is transferring mail and not
   downgradable, downgrading fails.

   One SMTP session may contain multiple recipients.  Downgrading SHOULD
   be performed for each SMTP recipient address.  First, split a
   multiple recipients session to each sessions.  If the recipient
   address is downgradable, the SMTP session to the recipient is
   downgradable.

   When MUA/MTA is transferring mail and finding its envelope is Non-
   ASCII, contains
   Non-ASCII addresses, it MUST decide to bounce or downgrade if
   receiving MTA is EAI incompliant.

   Both ALT-ADDR parameter and ATOMIC parameter is specified in one
   envelope from/to, use ALT-ADDR parameter and ignore ATOMIC parameter.

   MTA generates alternative US-ASCII address when ALT-ADDR option is
   not specified and ATOMIC is "y".

   Further, even

   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 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 Non-ASCII mail address with specified or generated alternative US-ASCII US-
   ASCII address.  Then appends replaced information with
   EAI-Downgraded-From EAI-
   Downgraded-From: and EAI-Downgraded-To EAI-Downgraded-To: header in mail header
   (outgoing SMTP DATA).

   EAI-Downgraded-From: <Non-ASCII,ATOMIC> <US-ASCII>
      EAI-Downgraded-From: <Non-ASCII,US-ASCII> <US-ASCII>
      EAI-Downgraded-To: <Non-ASCII,ATOMIC>  <Non-ASCII {US-ASCII}> <US-ASCII>
   EAI-Downgraded-To: <Non-ASCII,US-ASCII>  <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 EAI-Downgraded-From/To EAI-Downgraded-From/To: headers, MUA/MTA
   MUST perform SMTP DATA/Header downgrading. Downgrading.  This is described in next
   section.

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

   Case study: SPF check

   SPF checks domainname of the envelope from and smtp SMTP connection IP
   address.  If ALT-ADDR ALT-ADDRESS domainname is Punycode/IDNA form of Non-ASCII Non-
   ASCII domainname, it 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, three methods

   NOTE: ORCPT

   ESMTP ORCPT parameter is used for SMTP DATA/Header Delivery Status Notifications
   (DSNs) [RFC3461].  ORCPT parameters contain mail addresses.  After
   extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT
   parameter downgrading is
   proposed.  Working group should select one.

   o  No header downgrading
   o  Encapsulating whole be defined here.

5.  SMTP DATA
   o  Translating each header DATA/Header Downgrading

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

   Originator address(es):  Non-ASCII mail addresses in From, Reply-To,
      Sender From:,
      Reply-To:, Sender: and their Resent- headers MUST be target of
      downgrading.
   Destination address(es):  Non-ASCII mail addresses in To, CC, Bcc To:, CC:, Bcc:
      and their Resent- headers MUST be target of downgrading.
   IDs:  IDs such as Message-ID, Date, In-Reply-To Message-ID:, Date:, In-Reply-To: and References References:
      MUST NOT be target of downgrading.
   Trace headers: Received  Received: headers which contains Non-ASCII mail
      addresses MUST NOT be target of downgrading. downgrading
      because they do not contain Non-ASCII mail addresses.

   other headers:  UTF-8 in other headers MUST be target of downgrading.

   Rewriting Received
   UTF8SMTP header:  Identification of internationalized email header
      requires special consideration.

5.1.  Header conversion

   This section defines conversion method to US-ASCII for each header
   which may contain 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 prohibited in [RFC2821] Section 4.4
   Trace field.  But
   encoded by [RFC2047] with UTF-8 tag.

   Downgrading:
      *  Check if the mail has 'UTF8SMTP' header and its value is
         "UTF8".  Otherwise, downgrading may be considered as is not required.
      *  Check each header whether it contains UTF-8 characters or not.
         If the header contains UTF-8 characters,
         +  If the 'Mail
   Gatewaying' header is an address header which is described in [RFC2821]
            Section 3.8.  If it is
   true, these downgrading methods are acceptable.

5.1.  No 5.1.1,
            -  Preserve the header downgrading

   Most MTAs support 8bit characters in mail headers.  Currently, mail
   systems in some countries or languages use raw 8bit 'Downgraded' header.
            -  Downgrade the header value defined in
   their local encoding.  This method does not care about using Section 5.1.1.
         +  The other header case, encode the header by [RFC2047] with
            UTF-8
   headers in existing mail systems.

   Pros: tag.
      *  Easy  Change 'UTF8SMTP' header value to implement.
   Cons: "Downgraded".
   Upgrading:
      *  This method may break existing  Check if the mail infrastructure.

5.2.  Downgrading with MIME encapsulation

   This downgrading method requires new MIME 'Content-Type:' which
   express EAI.  This document assumes 'Content-Type: Message/EAI'
   existence.

   Downgrading: has 'UTF8SMTP' header and its value is
         "Downgraded".  Otherwise, upgrading is not required.
      *  If mail  Decode all 'Downgraded' headers.
         +  Decode header contains UTF-8 data, downgrade whole message to
         be MIME value field string which is [RFC2047] encoded.  Whole message becomes new MIME part (Message/
         EAI).
      *  Message-ID, Subject, Date headers are copied from original
         header.
      *  From
         +  If the header is generated with downgraded Envelope-from.
      *  To address header described in Section 5.1.1,
            -  Apply address header downgrading to the decoded header.
            -  Remove the header line which is generated the same with single the
               downgraded Envelope-to.
      *  If Subject line.
         +  Remove the 'Downgraded' header.
         +  Add decoded header contains UTF-8, it is replaced to a certain
         message or encoded by MIME [RFC2047].
      *  Message-ID, Date headers are preserved.
      As a result, new body contains one new MIME part (Message/EAI).

   Upgrading: mail header.
      *  If each mail message contains only one MIME header has [RFC2047] encoded part and its Content-
         Type which
         encoding is 'Message/EAI', it may be a downgraded message.  To
         check if "UTF-8", it is a downgraded message, compare mail body's
         message-id and MIME part's message-id.  If message-ids header, so decode it.
      *  Change 'UTF8SMTP' header value to "UTF8".

   Followings are pros and cons of this method.

   Pros:
      *  EAI incompliant MUA displays the
         same, it is a downgraded message.  Then, treat MIME part as
         entire mail message. body except
         original Non-ASCII mail addresses.

      *  When checking trace field, checker SHOULD check Received header
         both in wrapping headers  EAI incompliant MUA displays and headers in encapsulated part.

   Case study: DKIM

   DKIM checker performs upgrading handles the downgraded message first.

   Pros: sender specified
         alternative address (ALT-ADDRESS).
      *  MTA does  EAI compliant MUA displays and handles original headers.
   Cons:
      *  Implementation and processing cost is not need to decode so easy and
         lightweight because MUA/MTA must parse each header carefully. and encode
         it by defined method.
      *  Whole headers can be submitted  Hard to preserve whole information AS IS.
   Cons:
      *  Non-ASCII from/to can  The address headers
         are preserved but the other headers which is [RFC2047] encoded
         with UTF-8 tag are not distinguish from distinguished that it is downgraded mail
         headers.
      *  EAI incompliant MUA can not treat any or
         it is encoded by sender's MUA.  Also, restoration order of the
         downgraded mail. headers is not guaranteed.  Therefore, to check DKIM
         requires special consideration.

   [[Reference to [EAI-Scenarios] [I-D.ietf-eai-scenarios] and evaluation of each case
   should be described here.]]

5.2.1.

5.1.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 each header address headers

   This section targets From:, Sender:, Reply-To:, To:, CC:, Bcc:,
   Resent-From:, Resent-To:, Resent-CC:, Resent-Bcc:, Resent-sender:
   headers which may
   contain Non-ASCII characters.  Each header has its own downgrading
   method.

   To preserve all header information, define generic encapsulation
   header: "Downgraded: HeaderName: HeaderValue". contains Originator/Destination address(es).

   The header value is
   encoded by [RFC2047] with UTF-8 tag.

   Downgrading:
      *  For all headers, check if the header contains UTF-8 characters.
      *  Encapsulate 'i-Email' header composed of single or multiple mailbox/angle-addr
   fields defined in Downgraded header.

      * [I-D.ietf-eai-utf8headers].

   If the header contains UTF-8 characters,
         +  If the header is an address header which downgrading method is
   follows.
   1.  Extract every field and downgrade mailbox/angle-addr described in
            Section 5.3.1,
            -  Preserve
       below.
   2.  By mailbox/angle-addr downgrading, if the header in 'Downgraded' header.
            -  Downgrade field became empty, the
       field should be removed.
   3.  If all header defined in Section 5.3.1.
         +  The other header case, encode the header by [RFC2047] with
            UTF-8 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 removed, remove the decoded header.
            -  Remove the
   4.  If From header line which is same to the downgraded
               line.
         +  Remove the 'Downgraded' header.
         +  Add decoded removed, generate new From: header to mail header.  "HeaderName:
            HeaderValue".
      *  If from
       envelope-from address.

   EAI angle-addr defined in [I-D.ietf-eai-utf8headers] consists of 3
   forms.  Downgrading method is defined for each form.
   1.  <US-ASCII>
          US-ASCII mail header has [RFC2047] encoded part and which
         encoding is "UTF-8", it is a downgraded header, so decode address case, preserve it.

   Pros:
      *  EAI incompliant MUA displays the downgraded
   2.  <Non-ASCII>
          Non-ASCII mail body except
         original address without ALT-ADDRESS parameter case,
          remove this angle-addr.
   3.  <Non-ASCII {US-ASCII}>
          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 address with sender-specified US-ASCII address
          case, replace it as <US-ASCII>.

   "mailbox" is higher than 'Header
         Encapsulation' defined as "DISPLAY NAME angle-addr" in Section 5.2 because MUA/MTA must
         parse each header and encode it by defined method.
      *  Hard to preserve whole information AS IS.
   [I-D.ietf-eai-utf8headers].  The address headers
         are preserved but the other headers which is [RFC2047] "DISPLAY NAME" field should be
   encoded by [RFC2047] with UTF-8 tag are not distinguished that it is downgraded or
         it tag, if necessary.  If the angle-addr
   is encoded by sender's MUA.  Therefore, to check DKIM
         requires special consideration.

   [[Reference to [EAI-Scenarios] and evaluation of each case should be
   described here.]]

5.3.1.  Downgrading address headers

   This section targets From, Sender, Reply-To, To, CC, BCC, Resent-
   From, Resent-To, Resent-CC, Resent-Bcc, Resent-sender headers which
   contains Originator/Destination address(es).

   The removed, remove the field including "DISPLAY NAME".

6.  Implementation consideration

6.1.  MUA

   EAI compliant MUA MUST implement downgrading mechanism for sending.

   MUA MAY encode UTF-8 in Subject header value is composed with the same encoding of single or multiple mailbox/angle-addr
   fields defined in [EAI-UTF8].

   If body
   part while downgrading.

   EAI compliant MUA MUST upgrade downgraded mail and MUST show Non-
   ASCII mail addresses on display.

7.  Security considerations

   See the header contains UTF-8 characters, downgrading method extended security considerations discussion in
   [I-D.ietf-eai-framework]

8.  IANA Considerations

   IANA is
   follows.
   1.  Extract every field requested to add the "EAI-Downgraded-From:",
   "EAI-Downgraded-To:" and downgrade mailbox/angle-addr described
       below.
   2.  By mailbox/angle-addr downgrading, if "Downgraded:" new headers to the field became empty, registry
   with the
       field should be removed.
   3.  If all header field entries pointing to this specification for its definition.

9.  Acknowledgements

   John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey,
   Marcos Sanz, Alexey Melnikov and JET members.

10.  Change History

   This section is removed, remove used for tracking the header.
   4.  If From header is removed, generate new From header from
       envelope-from address.

   EAI angle-addr defined in [EAI-UTF8] consists update of 4 forms. this document.  Will
   be removed after finalize.

10.1.  draft-yoneya-ima-downgrade: Version 00

   o  Initial version
   o  Fllowed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00

10.2.  draft-yoneya-ima-downgrade: Version 01

   o  Document structure was changed
   o  Fllowed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02
   o  Downgrading requirements were added
   o  SMTP DATA encapsulation method is was proposed
   o  Downgrading examples was provided

10.3.  draft-ietf-eai-downgrade: Version 00

   o  Fllowed draft-yeh-ima-utf8headers-01 and draft-ietf-eai-smtpext-00
   o  No header downgrading method was proposed
   o  Header encapsulation method was proposed

10.4.  draft-ietf-eai-downgrade: Version 01

   o  Followed draft-ietf-eai-utf8headers-00
   o  Header conversion and encapsulation method was merged
   o  Header conversion method was defined for each form.
   1.  <Non-ASCII>
          Non-ASCII mail address without ALT-ADDR in detail

10.5.  draft-ietf-eai-downgrade: Version 02

   o  Followed draft-ietf-eai-utf8headers-01 and ATOMIC parameter
          case, remove this angle-addr.
   2.  <Non-ASCII,US-ASCII>
          Non-ASCII mail address with sender-specified US-ASCII
      draft-ietf-eai-smtpext-01
   o  Specification about algorithmic generated address
          case, replace it as <US-ASCII>.
   3.  <Non-ASCII,ATOMIC> is removed
   o  No header downgrading method was removed
   o  SMTP DATA encapsulation method was removed

11.  Normative References

   [I-D.ietf-eai-framework]
              Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", draft-ietf-eai-framework-01
              (work in progress), June 2006.

   [I-D.ietf-eai-scenarios]
              Alvestrand, H., "UTF-8 Mail: Scenarios",
              draft-ietf-eai-scenarios-01 (work in progress), June 2006.

   [I-D.ietf-eai-smtpext]
              Yao, J. and W. Mao, "SMTP extension for internationalized
              email address", draft-ietf-eai-smtpext-01 (work in
              progress), July 2006.

   [I-D.ietf-eai-utf8headers]
              Yeh, J., "Internationalized Email Headers",
              draft-ietf-eai-utf8headers-01 (work in progress),
              August 2006.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

Appendix A.  Examples

A.1.  SMTP Downgrading Example

   This section shows a SMTP Downgrading example.  Consider a
   downgradable mail message.
   o  The sender address with ATOMIC parameter case, generate
          the algorithmic address from is "NON-ASCII-FROM" which is Non-ASCII mail address.
      Its ASCII alternative is "ASCII-FROM".
   o  The "To" address and
          replace it as <ALG-ASCII>.
   4.  <US-ASCII>
          US-ASCII mail is "NON-ASCII-TO" which is Non-ASCII address.
      Its ASCII alternative is "ASCII-TO".
   o  The "CC" address case, preserve it.

   "mailbox" is defined as "DISPLAY NAME angle-addr" in [EAI-UTF8]. "NON-ASCII-CC" which is Non-ASCII address.  It
      has no ASCII alternative address.
   o  The
   "DISPLAY NAME" field should be encoded by [RFC2047] with UTF-8 tag,
   if necessary.  If the angle-addr Subject header is removed, remove the field
   including "DISPLAY NAME".

5.3.2.  Header conversion example "UTF8-Subject" which contains Non-ASCII
      characters.

   Original EAI message

   i-Email: 1.0 SMTP session

   MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
   RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO>
   RCPT TO: <NON-ASCII-CC>
   -------------------------------------------------------------
   UTF8SMTP: UTF8
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: UTF-8_SUBJECT UTF8-SUBJECT
   From: <NON-ASCII-FROM,ASCII-FROM> <NON-ASCII-FROM {ASCII-FROM}>
   To: <NON-ASCII-TO,ASCII-TO> <NON-ASCII-TO {ASCII-TO}>
   CC: <NON-ASCII-CC,ASCII-CC> <NON-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.

                      Figure 1: Original EAI message

   In this example, there are two sessions, one is To:, the other is
   CC:.  The CC: session does not contain ASCII alternative address, it
   is not downgradable and bounced.  The To: session can be downgraded
   to the next example Figure 2.

   After SMTP Downgrading

   MAIL From: <ASCII-FROM>
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   EAI-Downgraded-From: <NON-ASCII-FROM {ASCII-FROM}> <ASCII-FROM>
   EAI-Downgraded-To: <NON-ASCII-TO {ASCII-TO}> <ASCII-TO>
   UTF8SMTP: UTF8
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: UTF8-SUBJECT
   From: <NON-ASCII-FROM {ASCII-FROM}>
   To: <NON-ASCII-TO {ASCII-TO}>
   CC: <NON-ASCII-CC>
   Date: DATE

   MAIL_BODY

                   Figure 2: SMTP Downgraded EAI message

A.2.  Header conversion downgrading example

   Original EAI message

   UTF8SMTP: UTF8
   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>
   Date: DATE

   MAIL_BODY

                      Figure 3: Original EAI message
   SMTP Downgrading adds EAI-Downgraded-From:
       MIME(<Non-ASCII,DOWNGRADED_FROM>) and EAI-Downgraded-To:
   headers.

   EAI-Downgraded-From: <Non-ASCII {DOWNGRADED_FROM}> <DOWNGRADED_FROM>
   EAI-Downgraded-To:
       MIME(<Non-ASCII,DOWNGRADED_TO>) <Non-ASCII {DOWNGRADED_TO}> <DOWNGRADED_TO>
   Downgraded: i-Email: 1.0

                Figure 4: Headers added by SMTP Downgrading

   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>
   UTF8SMTP: Downgraded
   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>) MIME(<NON-ASCII-FROM {ASCII-FROM}>)
   From: <ASCII-FROM>
   Downgraded: To: MIME(<NON-ASCII-TO,ASCII-TO>) MIME(<NON-ASCII-TO {ASCII-TO}>)
   To: <ASCII-TO>
   Downgraded: CC: MIME(<NON-ASCII-CC,ASCII-CC>)
   CC: <ASCII-CC> MIME(<NON-ASCII-CC>)
   Date: DATE

   MAIL_BODY

              Figure 5: Header conversion downgraded message

   MIME() stands for [RFC2047] encoding.

6.  Implementation consideration

6.1.  MUA

   EAI compliant MUA MUST implement downgrading mechanism for sending.

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

   EAI compliant MUA MUST upgrade downgraded mail and MUST show Non-
   ASCII mail addresses on display.

6.2.  MDA Requirements

A.3.  Header conversion upgrading example

   This section describes downgrading in MDA.
   1.  MDA MUST NOT upgrade.
   2.  Perform downgrading for each Storage/Back-end-Process.  If and
       only if MDA knows recipient's MUA example shows upgrading process of Figure 5.

   First, check 'UTF8SMTP:' header.  Its value is "Downgraded", it is
   EAI compliant, then no
       downgrading downgraded message.

   Decode all 'Downgraded:' headers.

   Downgraded: From: MIME(<NON-ASCII-FROM {ASCII-FROM}>)
   Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>)
   Downgraded: CC: MIME(<NON-ASCII-CC>)

             Figure 6: Upgrading: selecting Downgraded headers

   Decode header value field string which is performed.
   3.  If MDA detects that SMTP recipient [RFC2047] encoded.

   From: <NON-ASCII-FROM {ASCII-FROM}>
   To: <NON-ASCII-TO {ASCII-TO}>
   CC: <NON-ASCII-CC>

             Figure 7: Upgrading: upgraded Downgraded headers

   Apply address header downgrading to the decoded header.

   From: <ASCII-FROM>
   To: <ASCII-TO>

        Figure 8: Upgrading: downgraded upgraded Downgraded headers
   Remove the header line which is an algorithmic
       address, then MDA MUST decode it and perform the same processing
       as if it were Non-ASCII mail address.  MDA MAY normalize or
       canonicalize local-part before processing it.

7.  Security considerations

   See with the extended security considerations discussion in [EAI-Overview]

8.  IANA Considerations

   To distinguish downgraded Non-ASCII mail addresses in ACE form, it
   MUST have ACE-Prefix.  The ACE-Prefix MUST differ from IDNA ACE-
   Prefix to avoid possible confusion.  IANA will assign 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

   [EAI-Overview]
              Klensin, J. and Y. Ko, "Overview line.

   EAI-Downgraded-From:
       MIME(<Non-ASCII {DOWNGRADED_FROM}) <DOWNGRADED_FROM>
   EAI-Downgraded-To:
       MIME(<Non-ASCII {DOWNGRADED_TO}) <DOWNGRADED_TO>
   UTF8SMTP: Downgraded
   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}>)
   Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>)
   Downgraded: CC: MIME(<NON-ASCII-CC>)
   Date: DATE

   MAIL_BODY

             Figure 9: Upgrading: Removing duplicated headers

   Remove the 'Downgraded' header and Framework for
              Internationalized Email", draft-ietf-eai-framework-01
              (work in progress).

   [EAI-SMTPext]
              Yao, J., Ed., "SMTP extension for internationalized email
              address", draft-ietf-eai-smtpext-00 (work in progress),
              Febrary 2006.

   [EAI-Scenarios]
              Alvestrand, H., "Internationalized Email Addresses:
              Scenarios", draft-ietf-eai-scenarios-00 (work in
              progress), May 2006.

   [EAI-UTF8]
              Yeh, J., "Internationalized Email Headers",
              draft-yeh-ima-utf8headers-01 (work in progress),
              February 2006. add decoded Downgraded headers If
   each mail header has [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [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., encoded part and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3492]  Costello, A., "Punycode: A Bootstring which encoding of Unicode
              for Internationalized Domain Names is
   "UTF-8", it is a downgraded header, so decode it.  Change 'UTF8SMTP'
   header value to "UTF8".

   EAI-Downgraded-From: <Non-ASCII {DOWNGRADED_FROM}> <DOWNGRADED_FROM>
   EAI-Downgraded-To: <Non-ASCII {DOWNGRADED_TO}> <DOWNGRADED_TO>
   UTF8SMTP: UTF8
   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: MIME(<NON-ASCII-TO {ASCII-TO}>
   CC: MIME(<NON-ASCII-CC>
   Date: DATE

   MAIL_BODY

               Figure 10: Header conversion upgraded message

   As a result, in Applications
              (IDNA)", RFC 3492, March 2003. this example, all headers are preserved.

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

Full 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.

   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.

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. IETF
   Administrative Support Activity (IASA).