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

[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

[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

[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.

[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?

[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.

[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 ;-).

[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.

[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.

[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.

[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.

[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.

[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.

[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

  (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.