(formerly known as "IMA")
Name: Internationalized Email and Extensions (IEE)
Area: Applications
Chair(s): To be determined
Applications Area Director(s):
Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>
Applications Area Advisor: To be determined
Mailing Lists
General Discussion: ima@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/ima
Archive: http://www1.ietf.org/mail-archive/web/ima/index.html
Since early in the effort to internationalize domain names, which cumulated in the standards associated with IDNA, it has been understood that internationalization of email address local parts is even more important. After all, most prefer variations on their names for those addresses. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts except on the final delivery system --constraints that go back to before RFC 821 and that have been vital to the operation of the Internet's email environment -- make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in waysthat are at least compatible suggests that this is not a simple and isolated problem.
This working group will address one basic approach to emai internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so.
Once the Experimental RFCs are completed and implemented, they will be evaluated. If the approach is found to have been successful using criteria the WG will establish as an early work item, the WG will be reactivated to update the documents for processing onto the standards track.
Very tentative
+-------------+--------------------------------------+--------------+
| 27 Sept: | First draft charter circulated to | Done |
| | ADs and key onlookers | |
| 30 Sept | First draft SMTP extension | Done |
| | specification | |
| Oct 3: | Consolidated overview and framework | Done |
| | draft submitted for I-D posting | |
| Oct 3: | Draft WG charter, formal time-slot | John |
| | request for IETF 64, and fallback | |
| | BOF request submitted to | |
| | Applications Area Directors | |
| Oct 3: | Circulate draft charter to IMA | John |
| | mailing list for comment. | |
| Oct 17: | First draft of downgrade | JPRS |
| | specification | |
| Oct 17: | First draft of key open questions | JPRS |
| | list | |
| Oct 17: | First draft of "UTF-8 headers" | Jeff |
| Oct 24: | Second draft of overview and | Yangwoo/John |
| | framework document if needed. | |
| Oct 24: | New draft of SMTP extension | Jiankang |
| | specification. | |
| Nov 2 | Consolidated/updated list of | JPRS |
| | questions for IETF meeting review to | |
| | mailing list | |
| Week of Nov | Meet at IETF 64, review and identify | |
| 6: | outstanding issues with drafts. | |
| Nov 28: | Third draft of framework document | |
| | (last one?) | |
| Nov 28: | Second draft of base technical | |
| | specification. | |
+-------------+--------------------------------------+--------------+
Table 1
[[Note in draft: additional documents? For example, do we need an informational "considerations for MUA authors" one?]]
+--------------+----------------------------------------------------+
| ??? | Framework document complete, submit to IESG for |
| | publication as Experimental or Informational RFC |
| | [[note in draft: I have no idea whether the IESG |
| | will approve this document without enough of the |
| | package to be implementable, but, for now...]] |
| ??? | Base technical and UTF-8 header documents |
| | complete, submit for approval and publication as |
| | Experimental RFCs |
| ??? | Additional documents complete and submitted for |
| | approval and publication as experimental RFCs. |
| ??? - ??? | Period of implementation and evaluation |
| ??? | Implementation and operational experience |
| | evaluation draft posted |
| ??? | Revised versions of all required documents posted |
| ??? | Second version of all required documents |
| ??? | Request to IESG to Last Call required documents |
| | for Proposed Standard and to public the experience |
| | and evaluation draft as an Informational RFC. |
+--------------+----------------------------------------------------+
2.7. Internet-Drafts
Drafts listed below were posted as initial discussion documents, preceeding the meeting at IETF 64
2005.06.27 draft-lee-jet-ima-00.txt
2005.07.18 draft-klensin-emailaddr-i18n-03.txt
Drafts produced by the WG
None as yet