Skip to main content

Overview and Framework for Internationalized Email
RFC 4952

Revision differences

Document history

Date Rev. By Action
2015-10-14
05 (System) Notify list changed from eai-chairs@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
05 (System) post-migration administrative database adjustment to the Abstain position for David Kessens
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-08-10
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-08-10
05 Amy Vezza [Note]: 'RFC 4952' added by Amy Vezza
2007-07-25
05 (System) RFC published
2007-03-27
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-03-27
05 Amy Vezza
[Note]: 'The Document Shepherd is Harald Alvestrand.  A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of …
[Note]: 'The Document Shepherd is Harald Alvestrand.  A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of -04 should be fine.' added by Amy Vezza
2007-03-19
05 (System) IANA Action state changed to No IC from In Progress
2007-03-19
05 (System) IANA Action state changed to In Progress
2007-03-18
05 Amy Vezza IESG state changed to Approved-announcement sent
2007-03-18
05 Amy Vezza IESG has approved the document
2007-03-18
05 Amy Vezza Closed "Approve" ballot
2007-03-18
05 Ted Hardie State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ted Hardie
2007-03-18
05 Ted Hardie
[Note]: 'The Document Shepherd is Harald Alvestrand.  A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of …
[Note]: 'The Document Shepherd is Harald Alvestrand.  A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of -04 should be fine.' added by Ted Hardie
2007-03-17
05 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2007-02-14
05 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2007-02-09
05 David Kessens [Ballot Position Update] Position for David Kessens has been changed to Abstain from Discuss by David Kessens
2007-02-09
05 David Kessens
[Ballot comment]
From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage …
[Ballot comment]
From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready.


In '1.  Introduction':

Without the extensions specified in this document, the mailbox name is
restricted to a subset of 7-bit ASCII [RFC2821].

And this is probably a good thing as far as me concerned (note that my
native language includes characters that cannot be represented in 7-bit
ASCII)

In section '1.2.  Problem statement':

If the names and initials used in email addresses can be
expressed in the native languages and writing systems of the users,
the Internet will be perceived as more natural, especially by those
whose native language is not written in a subset of a Roman-derived
script.

In addition, the use of internationaled email addresses will serve to fragmentize the
email name address namespace, thereby fragmenting and isolating people by
making it harder to communicate with people that use different
charactersets and thus undermining the usefulness of email.

In section '7.  Experimental Targets':

un-upgraded

I cannot wait to see what kind of word the RFC editor is going to use
instead of this one ;-).

------

Please see below for the original text of my DISCUSS:

Most people are probably aware that I am not a big fan of this effort.

However, this was unfortunately chartered as I seem to be the only AD with this position. As such I don't believe that I can
stop this work. However, I do feel that there are inaccuracies that
need to be fixed. After that has been fixed, I will change my position to an ABSTAIN.

In 'Abstract:':

Full use of electronic mail throughout the world requires that people
be able to use their own names, written correctly in their own
languages and scripts, as mailbox names in email addresses.

There is absolutely no requirement to use peoples
own name to be able to fully use email. In fact, there is and
has been a long tradition to use something else than one's own name and
there are countries who use other scripts but have had no difficulties
at all to use email.

In section '4.3.  Downgrading Mechanism for Backward Compatibility'

and the selection
of potential intermediate relays is under the control of the
administration of the final delivery server.

This seems a rather optimistic assumption.

The first of these two options, that of rejecting or returning the
message to the sender MAY always be chosen.

This is a completely unacceptable approach: emails that conform to the

spec should be delivered. emails success is based on the fact that
it is an extremely robust service and delivery is almost guaranteed.
Therefore, some form of backwards compatibility will be required,
rejecting or returning messages doesn't follow that approach.

In section '9.  Security Considerations':

It should be noted that
one of the proposed fixes for, e.g., domain names in URLs, does not
work for email local parts since they are case-sensitive.

This text is ambiguous. It is not clear what the 'they' refers to.
(and it might need more work as both domain names and local parts
are case-insensitive as far as I know - please correct me if I am wrong!)

The requirements and mechanisms documented in this set
of specifications do not, in general, raise any new security issues.

This is factually incorrect as explained in this section itself.
Internationalization has issues for domains, and it will introduce
the same issues for email while this was previously not a problem.
2007-02-09
05 (System) Removed from agenda for telechat - 2007-02-08
2007-02-08
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2007-02-08
05 Jari Arkko
[Ballot discuss]
I believe this is important work and long overdue.
I do have a question abou the server downgrade
behaviour, however:

> Since the …
[Ballot discuss]
I believe this is important work and long overdue.
I do have a question abou the server downgrade
behaviour, however:

> Since the final delivery SMTP server (or, to be more specific, its
> corresponding mail storage agent) cannot safely assume that agents
> accessing email storage will always be capable of handling the
> extensions proposed here, it MAY either downgrade internationalized
> emails or specially identify messages that utilize these extensions,
> or both.  If this done, the final delivery SMTP server SHOULD include
> a mechanism to preserve or recover the original internationalized
> forms without information loss to support access by UTF8SMTP-aware
> agents.

Does this suggest that the final server downgrades mails
without knowing that the client is uncapable of reading
them in the internationalized form? This seems surprising.
Can you elaborate why? And what is the identification mechanism,
and how does it affect POP/IMAP access to the messages?
2007-02-08
05 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2007-02-08
05 Jari Arkko [Ballot comment]
> US-ASCII character repertoire, use of punycode on the right hand

The term Punycode is used here without reference or definition.
2007-02-08
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-02-08
05 Sam Hartman
[Ballot comment]
me too on removing the anchors.  Besides that a really solid document.

Strong disagreement with most of David's discuss, especially the parts
that …
[Ballot comment]
me too on removing the anchors.  Besides that a really solid document.

Strong disagreement with most of David's discuss, especially the parts
that refer to the abstract.
2007-02-08
05 David Kessens
[Ballot comment]
From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage …
[Ballot comment]
From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready.


In '1.  Introduction':

Without the extensions specified in this document, the mailbox name is
restricted to a subset of 7-bit ASCII [RFC2821].

And this is probably a good thing as far as me concerned (note that my
native language includes characters that cannot be represented in 7-bit
ASCII)

In section '1.2.  Problem statement':

If the names and initials used in email addresses can be
expressed in the native languages and writing systems of the users,
the Internet will be perceived as more natural, especially by those
whose native language is not written in a subset of a Roman-derived
script.

In addition, the use of internationaled email addresses will serve to fragmentize the
email name address namespace, thereby fragmenting and isolating people by
making it harder to communicate with people that use different
charactersets and thus undermining the usefulness of email.

In section '7.  Experimental Targets':

un-upgraded

I cannot wait to see what kind of word the RFC editor is going to use
instead of this one ;-).
2007-02-08
05 David Kessens
[Ballot comment]
From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage …
[Ballot comment]
From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready.


In '1.  Introduction':

Without the extensions specified in this document, the mailbox name is
restricted to a subset of 7-bit ASCII [RFC2821].

And this is probably a good thing as far as me concerned (note that my
native language includes characters that cannot be represented in 7-bit
ASCII)

In section '1.2.  Problem statement':

If the names and initials used in email addresses can be
expressed in the native languages and writing systems of the users,
the Internet will be perceived as more natural, especially by those
whose native language is not written in a subset of a Roman-derived
script.

In addition, the use of internationaled email addresses will serve to fragmentize the
email name address namespace, thereby fragmenting and isolating people by
making it harder to communicate with people that use different
charactersets and thus undermining the usefulness of email.
2007-02-08
05 David Kessens
[Ballot discuss]
Most people are probably aware that I am not a big fan of this effort.

However, this was unfortunately chartered as I seem …
[Ballot discuss]
Most people are probably aware that I am not a big fan of this effort.

However, this was unfortunately chartered as I seem to be the only AD with this position. As such I don't believe that I can
stop this work. However, I do feel that there are inaccuracies that
need to be fixed. After that has been fixed, I will change my position to an ABSTAIN.

In 'Abstract:':

Full use of electronic mail throughout the world requires that people
be able to use their own names, written correctly in their own
languages and scripts, as mailbox names in email addresses. 

There is absolutely no requirement to use peoples
own name to be able to fully use email. In fact, there is and
has been a long tradition to use something else than one's own name and
there are countries who use other scripts but have had no difficulties
at all to use email.

In section '4.3.  Downgrading Mechanism for Backward Compatibility'

and the selection
of potential intermediate relays is under the control of the
administration of the final delivery server.

This seems a rather optimistic assumption.

The first of these two options, that of rejecting or returning the
message to the sender MAY always be chosen.

This is a completely unacceptable approach: emails that conform to the

spec should be delivered. emails success is based on the fact that
it is an extremely robust service and delivery is almost guaranteed.
Therefore, some form of backwards compatibility will be required,
rejecting or returning messages doesn't follow that approach.

In section '9.  Security Considerations':

It should be noted that
one of the proposed fixes for, e.g., domain names in URLs, does not
work for email local parts since they are case-sensitive. 

This text is ambiguous. It is not clear what the 'they' refers to.
(and it might need more work as both domain names and local parts
are case-insensitive as far as I know - please correct me if I am wrong!)

The requirements and mechanisms documented in this set
of specifications do not, in general, raise any new security issues.

This is factually incorrect as explained in this section itself.
Internationalization has issues for domains, and it will introduce
the same issues for email while this was previously not a problem.
2007-02-08
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-02-08
05 Cullen Jennings
[Ballot comment]
In section 9 it says that this work "must not leave the Internet less secure than it is". I worry that this is …
[Ballot comment]
In section 9 it says that this work "must not leave the Internet less secure than it is". I worry that this is too strong - I think this work inherently will make the internet slightly less secure due to the homograph issues discussed. However, I think that is a trade off worth making. I would hate to see the later protocol documents held up because of this text.
2007-02-08
05 David Kessens [Ballot Position Update] New position, Discuss, has been recorded by David Kessens
2007-02-07
05 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-02-07
05 (System) New version available: draft-ietf-eai-framework-05.txt
2007-02-07
05 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Yes from No Objection by Sam Hartman
2007-02-07
05 Sam Hartman [Ballot comment]
me too on removing the anchors.  Besides that a really solid document.
2007-02-07
05 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2007-02-07
05 Dan Romascanu [Ballot comment]
I support Lars' DISCUSS concerning the need to remove the [anchor ...] comments prior to IESG approval.
2007-02-07
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-02-06
05 Russ Housley
[Ballot comment]
I agree with Lars, the various [anchorX...] notes need to be resolved
  before IESG approval.  I'll let Lars hold the DISCUSS position …
[Ballot comment]
I agree with Lars, the various [anchorX...] notes need to be resolved
  before IESG approval.  I'll let Lars hold the DISCUSS position on this
  point.

  Section 11 should be deleted before publication as an RFC.
2007-02-06
05 Russ Housley
[Ballot discuss]
The authors have agreed to add the following text to the Security
  Considerations based on the SecDir Review by Paul Hoffman:
  …
[Ballot discuss]
The authors have agreed to add the following text to the Security
  Considerations based on the SecDir Review by Paul Hoffman:
  >
  > This work will clearly impact any systems or mechanisms that are
  > dependent on digital signatures or similar integrity protection for
  > mail headers (see also the discussion in Section 6.4).  Many
  > conventional uses of PGP and S/MIME are not affected since they are
  > used to sign body parts but not headers.  On the other hand, the
  > developing work on domain keys identified mail (DKIM [DKIM-Charter])
  > will eventually need to consider this work and vice versa: while this
  > experiment does not propose to address or solve the issues raised by
  > DKIM and other signed header mechanisms, the issues will have to be
  > coordinated and resolved eventually if the two sets of protocols are
  > to co-exist.  In addition, to the degree to which email addresses
  > appear in PKI certificates, standards addressing such certificates
  > will need to be upgraded to address these internationalized
  > addresses.  Those upgrades will need to address questions of spoofing
  > by look-alikes of the addresses themselves.
  >
  When this text appears, I'll clear this DISCUSS position.
2007-02-06
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-02-05
05 Lars Eggert [Ballot comment]
Contains a bunch of other comments ("[[anchorX...]]") that should
  probably be removed.
2007-02-05
05 Lars Eggert
[Ballot discuss]
Section 6.5., paragraph 1:
>    [[anchor16: WGLC, "Framework 7": This section tentatively added to
>    keep track of the relevant text.  …
[Ballot discuss]
Section 6.5., paragraph 1:
>    [[anchor16: WGLC, "Framework 7": This section tentatively added to
>    keep track of the relevant text.  There may not be consensus for it
>    in this form (or at all).]]

  DISCUSS: I didn't expect such a comment in a document that makes it to
  the IESG. Is there consensus and the anchor should be removed, or is
  there still no consensus?


Section 6.6., paragraph 1:
>    [[anchor18: WGLC, "Framework 3": This section tentatively added to
>    keep track of the relevant text.  There may not be consensus for it
>    in this form (or at all).]]

  DISCUSS: Same issue as above.
2007-02-05
05 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2007-02-05
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-02-02
05 Ted Hardie
[Note]: 'The Document Shepherd is Harald Alvestrand.  A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of …
[Note]: 'The Document Shepherd is Harald Alvestrand.  A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of -04 should be fine.' added by Ted Hardie
2007-02-02
05 Brian Carpenter [Ballot comment]
Some changes expected following Gen-ART review at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-eai-framework-04-sparks.txt

[anchor...] notes need to be removed
2007-02-02
05 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2007-02-01
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Paul Hoffman.
2007-01-30
05 Ted Hardie Placed on agenda for telechat - 2007-02-08 by Ted Hardie
2007-01-30
05 Ted Hardie State Changes to IESG Evaluation from Waiting for Writeup by Ted Hardie
2007-01-30
05 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2007-01-30
05 Ted Hardie Ballot has been issued by Ted Hardie
2007-01-30
05 Ted Hardie Created "Approve" ballot
2007-01-26
05 (System) State has been changed to Waiting for Writeup from In Last Call by system
2007-01-22
05 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2007-01-18
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Paul Hoffman
2007-01-18
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Paul Hoffman
2007-01-12
05 Amy Vezza Last call sent
2007-01-12
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-01-11
05 Ted Hardie Last Call was requested by Ted Hardie
2007-01-11
05 Ted Hardie State Changes to Last Call Requested from Publication Requested by Ted Hardie
2007-01-11
05 (System) Ballot writeup text was added
2007-01-11
05 (System) Last call text was added
2007-01-11
05 (System) Ballot approval text was added
2007-01-11
05 Ted Hardie [Note]: 'The Document Shepherd is Harald Alvestrand.' added by Ted Hardie
2007-01-11
05 Ted Hardie

  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
  …

  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Harald Alvestrand is Document Shepherd. He has reviewed the document.

  (1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The review in the WG has been thorough, and many people who are not WG
members are aware of the document.
We think that the IETF would benefit from having its attention called to
the document, so that people are aware that the EAI experiment is being
tried, and so that any issues with the general approach taken can be raised before the WG settles on final specifications for the technical components of the proposal; this is the reason for asking for publication of this document before the technical specifications are finished.

  (1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.
The format of email addresses is embedded in a lot of other specifications, and these need to evaluate whether their specifications will be affected by this work, but that is a review of their documents, not a review of this document.

  (1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.

There are some sections in the document that might not reflect a solid
informed consensus in the WG - notably sections 6.5 and 6.6. However, the WG has elected not to have further discussion on these in WG Last Call, so we can assume that the WG will not object to the text as given - the text mostly serves to point out areas where further work might be needed, and has limited immediate technical impact.

  (1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

As far as concern has been expressed, the WG seems satisfied with this
document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

Online id-nits checker complains that the domain name "any.thing.goes" does not end in "example"; this is a left-hand side of an email address, so does not constitute a break with the I-D checklist.

  (1.h)  Has the document split its references into normative and
        informative?  Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion?  Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes. All normative references are published.

The document lists the actual technical specifications it is a framework
for as informative references. This is believed to be factually correct -
it is not necessary to have the specifications to interpret the framework,
and since it is a framework, it cannot be implemented.

  (1.i)  Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggested a
        reasonable name for the new registry?  See
        [I-D.narten-iana-considerations-rfc2434bis].  If the document
        describes an Expert Review process has Shepherd conferred with
        the Responsible Area Director so that the IESG can appoint the

Yes.
(1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes, there are no such sections.

  (1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Writeup?  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary

  Full use of electronic mail throughout the world requires that people
  be able to use their own names, written correctly in their own
  languages and scripts, as mailbox names in email addresses.  This
  document introduces a series of specifications that define mechanisms
  and protocol extensions needed to fully support internationalized
  email addresses.  These changes include an SMTP extension and
  extension of email header syntax to accommodate UTF-8 data.  The
  document set also includes discussion of key assumptions and issues
  in deploying fully internationalized email.

      Working Group Summary

        The decision to not provide any means of "automatic
        encapsulation" of UTF-8 email addresses, but instead insist
        that the sender specify an alternate
        address for downgrading purposes, was controversial, but was
        definitely the decision of the working group.

        Document Quality

            This document has helped guide the development of the
            technical specification.
            Having the document stable will facilitate finishing the
            rest.

        Personnel
            The Document Shepherd is Harald Alvestrand.
            The responsible AD is Ted Hardie.
2007-01-11
05 Ted Hardie Draft Added by Ted Hardie in state Publication Requested
2006-12-13
04 (System) New version available: draft-ietf-eai-framework-04.txt
2006-11-10
03 (System) New version available: draft-ietf-eai-framework-03.txt
2006-10-12
02 (System) New version available: draft-ietf-eai-framework-02.txt
2006-06-26
01 (System) New version available: draft-ietf-eai-framework-01.txt
2006-05-24
00 (System) New version available: draft-ietf-eai-framework-00.txt