Overview and Framework for Internationalized Email
RFC 4952

Note: This ballot was opened for revision 05 and is now closed.

(Ted Hardie) Yes

(Sam Hartman) (was No Objection) Yes

Comment (2007-02-08)
No email
send info
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.

(Jari Arkko) (was Discuss) No Objection

Comment (2007-02-08)
No email
send info
> US-ASCII character repertoire, use of punycode on the right hand

The term Punycode is used here without reference or definition.

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2007-02-02 for -)
No email
send info
Some changes expected following Gen-ART review at

[anchor...] notes need to be removed

Lars Eggert (was Discuss) No Objection

Comment (2007-02-05)
No email
send info
  Contains a bunch of other comments ("[[anchorX...]]") that should
  probably be removed.

(Russ Housley) (was Discuss) No Objection

Comment (2007-02-06)
No email
send info
  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

  Section 11 should be deleted before publication as an RFC.

(Cullen Jennings) No Objection

Comment (2007-02-08)
No email
send info
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.

(Dan Romascanu) No Objection

Comment (2007-02-07 for -)
No email
send info
I support Lars' DISCUSS concerning the need to remove the [anchor ...] comments prior to IESG approval.

(Magnus Westerlund) No Objection

(David Kessens) (was Discuss) Abstain

Comment (2007-02-09)
No email
send info
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 

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

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':


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.