Overview and Framework for Internationalized Email
draft-ietf-eai-framework-05

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.