Network Working Group                                     Y. YONEYA, Ed.
Internet-Draft                                          K. Fujiwara, Ed.
Expires: April 20, 2006                                             JPRS
                                                        October 17, 2005


    Downgrading mechanism for Internationalized eMail Address (IMA)
                   draft-yoneya-ima-downgrade-00.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 April 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Traditional mail systems handle only US-ASCII characters in SMTP
   envelope and mail headers.  The internationalized email address (IMA)
   is implemented by allowing UTF-8 characters in the SMTP envelope and
   mail headers.  This document describes downgrading from
   internationalized addressing with the SMTP extension and UTF-8
   headers to traditional email formats and characters.





YONEYA & Fujiwara        Expires April 20, 2006                 [Page 1]


Internet-Draft                IMA Downgrade                 October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Downgrade Encoding . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Downgrading mail addresses in envelope . . . . . . . . . .  4
     3.2.  Downgrading mail addresses in mail header  . . . . . . . .  4
     3.3.  Downgrading other data . . . . . . . . . . . . . . . . . .  4
   4.  Downgrading  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Timing and conditions of downgrading . . . . . . . . . . .  4
     4.2.  SMTP Downgrading . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  Mail Header Downgrading  . . . . . . . . . . . . . . . . .  5
     4.4.  Record of downgrading  . . . . . . . . . . . . . . . . . .  5
   5.  Implementation consideration . . . . . . . . . . . . . . . . .  5
     5.1.  MUA  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  MDA Requirements . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  6
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  6
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10




























YONEYA & Fujiwara        Expires April 20, 2006                 [Page 2]


Internet-Draft                IMA Downgrade                 October 2005


1.  Introduction

   Traditional Internet email systems are defined by [RFC2821] and
   [RFC2822].  They allow US-ASCII characters in the SMTP envelope and
   mail headers.  The IMA proposal [IMA-Framework], [IMA-UTF8], [IMA-
   SMTPext] allows UTF-8 characters in SMTP envelope and mail headers.

   Carrying IMA from sender to recipients requires that all components
   on the mail delivery route be IMA compliant.  Otherwise IMA can't be
   delivered.  To solve the problem, this document describes a downgrade
   mechanism that enables delivering IMA by converting it to
   corresponding US-ASCII representation on current mail delivery
   system.  Not only SMTP envelope, but also UTF-8 in mail headers MUST
   be converted to US-ASCII.

   Converting IMA to US-ASCII SHOULD have algorithmic method and 1-to-1
   mapping.  Requiring users to specify both an IMA and an equivalent
   US-ASCII form is inconvenient and decreases usefulness of IMA.


2.  Terminology

   This document assumes a reasonable understanding of the protocols and
   terminology of the core email standards as documented in [RFC2821]
   and [RFC2822].  It also assumes familiarity with the other IMA
   documents described in [IMA-Framework].

   Much of the description in 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 in a "message store"
   or resends messages where the receiver has assigned.  In this
   document, this function is called Mail Delivery Agent(MDA).

   In this document, an address is "all-ASCII" if every character in the
   address is in the ASCII character repertoire [ASCII]; an address 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.




YONEYA & Fujiwara        Expires April 20, 2006                 [Page 3]


Internet-Draft                IMA Downgrade                 October 2005


   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
   and "MAY" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


3.  Downgrade Encoding

3.1.  Downgrading mail addresses in envelope

   This section describes how to downgrade mail addresses in SMTP
   envelope.  The encoding described in this section is also used in the
   mail header.
   1.  Extract mail addresses from IMA SMTP envelope according to [IMA-
       SMTPext].
   2.  Convert mail addresses into ACE(ASCII Compatible Encoding) if it
       is IMA.  ACE format of IMA is below.
       *  Domain part (RHS of @) is encoded to Punycode of IDNA
          [RFC3490].
       *  Local part (LHS of @) is encoded to Punycode [RFC3492] as a
          whole with ACE-Prefix described in Section 7.  If local part
          consists exclusively of US-ASCII characters, do not convert.

3.2.  Downgrading mail addresses in mail header

   This section describes how to downgrade mail addresses in mail
   headers.

   Extract every addr-spec [RFC2822] of mailboxes from mail headers
   including UTF-8.  For each addr-spec, if it includes UTF-8, convert
   it into ACE with the same method described in Section 3.1.  Original
   IMA SHOULD remain as a comment encoded by base64 of MIME with UTF-8
   tag.  Note that specials 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.

3.3.  Downgrading other data

   This section describes how to downgrade other mail headers.
   1.  Encode UTF-8 part of headers by base64 of MIME with UTF-8 tag.
   2.  encoding=UTF-8


4.  Downgrading

4.1.  Timing and conditions of downgrading

   This section describes timing and conditions of downgrading.




YONEYA & Fujiwara        Expires April 20, 2006                 [Page 4]


Internet-Draft                IMA Downgrade                 October 2005


      Timing: SMTP client detects SMTP server doesn't support IMA by its
      absence from the EHLO response.
      Conditions: SMTP client detects UTF-8 is included in SMTP envelope
      or mail headers.

4.2.  SMTP Downgrading

   Target of downgrading elements in SMTP envelope are below:
   1.  MAIL FROM:
   2.  RCPT TO:

   Downgrading MUST be performed in each SMTP session.

4.3.  Mail Header Downgrading

   Target of downgrading elements in mail headers (SMTP data) are below:
   Originator address(es): IMA in From, Reply-To and Sender and their
      Resent- headers MUST be converted into ACE form.
   Destination address(es): IMA in To and Cc and their Recent- headers
      MUST be converted into ACE form.
   IDs: IDs such as Message-ID, In-Reply-To and Reference MUST NOT be
      the target of downgrading, i.e., these headers MUST NOT be
      downgraded.
   Other headers: UTF-8 in other headers such as Subject and Received
      MUST be converted into base64 of MIME with UTF-8 tag.

   Note that the MTA which performs downgrading MUST be responsible for
   base64 encoding of preceding Received headers.

4.4.  Record of downgrading

   MTA which performs downgrading MUST add downgrading header to record
   which headers are downgraded.  Downgrading header is specified as
   "X-IMA-Downgraded", and elements of the header is list of downgraded
   header names separated by white space characters.

   SMTP envelope downgrading is recorded as Envelope-To and Envelope-
   From.

   X-IMA-Downgraded: Envelope-From Envelope-To From To CC


5.  Implementation consideration

5.1.  MUA

   An IMA compliant MUA MUST implement downgrade mechanism for sending.




YONEYA & Fujiwara        Expires April 20, 2006                 [Page 5]


Internet-Draft                IMA Downgrade                 October 2005


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

   IMA compliant MUA MUST decode downgraded mail headers and MUST show
   IMA on display.  MUA MAY use X-IMA-Downgraded header to determine
   which headers were downgraded.

5.2.  MDA Requirements

   This section describes downgrading in MDA.
   1.  MDA MUST NOT convert downgraded header to UTF-8.
   2.  Record Return-Path header in ACE form.
   3.  Perform downgrading for each Storage/Back-end-Process.  If and
       only if MDA knows MUA is IMA compliant, then no downgrading is
       performed.
   4.  If MDA detects downgraded IMA in SMTP envelope, then MDA MUST
       decode IMA and perform the same processing as if it were IMA.
       MDA MAY normalize or canonicalize local-part before processing
       it.


6.  Security considerations

   See the extended security considerations discussion in [IMA-
   Framework]


7.  IANA Considerations

   To distinguish downgraded IMA in ACE form, it MUST have ACE-Prefix.
   The ACE-Prefix MUST be differ from IDNA ACE-Prefix to avoid possible
   confusion.  IANA will assign IMA ACE-Prefix when RFC is published.

   IANA should register the new header [X-]IMA-Downgraded in the
   registry of email header types.


8.  Acknowledgements

   ...To be supplied ...

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



YONEYA & Fujiwara        Expires April 20, 2006                 [Page 6]


Internet-Draft                IMA Downgrade                 October 2005


              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-Framework]
              Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", draft-klensin-ima-framework-00
              (work in progress), September 2005.

   [IMA-SMTPext]
              Yao, J., Ed., "SMTP Extension for Internationalized Email
              Address", draft-yao-smtpext-00 (work in progress),
              September 2005.

   [IMA-UTF8]
              Yeh, J., "Transmission of Email Headers in UTF-8
              Encoding", draft-yeh-ima-utf8headers-00 (work in
              progress), October 2005.

   [JET-IMA]  Yao, J. and J. Yeh, "Internationalized eMail Address
              (IMA)", draft-lee-jet-ima-00 (work in progress),
              June 2005.

   [Klensin-emailaddr]
              Klensin, J., "Internationalization of Email Addresses",
              draft-klensin-emailaddr-i18n-03 (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.

   [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,



YONEYA & Fujiwara        Expires April 20, 2006                 [Page 7]


Internet-Draft                IMA Downgrade                 October 2005


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


Appendix A.  Examples

   ...to be supplied...





































YONEYA & Fujiwara        Expires April 20, 2006                 [Page 8]


Internet-Draft                IMA Downgrade                 October 2005


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































YONEYA & Fujiwara        Expires April 20, 2006                 [Page 9]


Internet-Draft                IMA Downgrade                 October 2005


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 (2005).  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.




YONEYA & Fujiwara        Expires April 20, 2006                [Page 10]