Skip to main content

Overview and Framework for Internationalized Email
RFC 4952

Yes

(Ted Hardie)

No Objection

(Magnus Westerlund)
(Ross Callon)

Abstain


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

Lars Eggert (was Discuss) No Objection

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

(Sam Hartman; former steering group member) (was No Objection) Yes

Yes (2007-02-08)
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.

(Ted Hardie; former steering group member) Yes

Yes ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2007-02-02)
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

(Cullen Jennings; former steering group member) No Objection

No Objection (2007-02-08)
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; former steering group member) No Objection

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

(Jari Arkko; former steering group member) (was Discuss) No Objection

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

The term Punycode is used here without reference or definition.

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2007-02-06)
  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.

(David Kessens; former steering group member) (was Discuss) Abstain

Abstain (2007-02-09)
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.