Overview and Framework for Internationalized Email
RFC 6530

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Overview and Framework for Internationalized Email) to Proposed Standard


The IESG has received a request from the Email Address
Internationalization WG (eai) to consider the following document:
- 'Overview and Framework for Internationalized Email'
  as a Proposed Standard

Please note that an earlier revision of this document was already
approved by the IESG for publication as Informational. This document has
references to and from draft-ietf-eai-5335bis and
draft-ietf-eai-5336bis. As a result of IESG comments during IESG
Evaluation of those two documents, the WG felt that they needed to make
changes to this document and change its status to Standards Track from
Informational. It is now being re-considered for Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Full use of electronic mail throughout the world requires that
  (subject to other constraints) people be able to use close variations
  on 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.  This document is a replacement for RFC
  4952; it reflects additional issues identified since that document
  was published.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation from RFC Ed Queue.
This document has references to and from draft-ietf-eai-5335bis and draft-ietf-eai-5336bis. Those two documents went through IESG Evaluation. As a result of IESG comments, the WG felt that they needed to make changes to this document *and* change its status to Standards Track from Informational. RFC Editor removed it from their queue and it is back with the IESG.

[Ballot discuss]
The Gen-ART Review by David Black on 10 Sep 2010 raised several
  issues.  The authors seem to agree that changes are appropriate,
  but a revised Internet-Draft has not been posted yet.

[Ballot discuss]
There was a brief discussion amongst the IESG about the intended status before IETF Last Call, which seemed to
support Informational Status.  However, the document was Last Called for PS and is on the telechat for PS.  I
would like to discuss why the sponsor feels standards track was the correct choice.

[Ballot comment]
The phrase "this document" is used in a confusing manner in the first two bullets of section 5.  For example,
bullet 1 reads

  o  SMTP extensions.  This document [RFC5336bis-SMTP] provides an SMTP
      extension (as provided for in RFC 5321) for internationalized
      addresses.

However, "this document" refers to the referenced specification [RFC5336bis-SMTP] rather than this document
(the framework).  Perhaps the clause could be deleted in both bullets.  Then bullet 1 would read:

  o  SMTP extensions.  [RFC5336bis-SMTP] provides an SMTP
      extension (as provided for in RFC 5321) for internationalized
      addresses.

[Ballot comment]
Thank you for this clear, well-written document. Several sentences struck me as difficult to parse...

1. In Section 8.1:

  It is likely that the most common cases in which a message that
  requires these extensions is sent to a system that does not will
  involve the combination of ASCII-only forward-pointing addresses with
  a non-ASCII backward-pointing one.

I suggest:

  Sometimes a message that requires these extensions is sent to a
  system that does not support these extensions; tt is likely that the most
  common cases will involve the combination of ASCII-only forward-pointing
  addresses with a non-ASCII backward-pointing one.

2. In Section 10.1:

  While these
  are permitted by the protocols and servers are expected to support
  them and there are special cases where they can provide value, taking
  advantage of those features is almost always bad practice unless the
  intent is to create some form of security by obscurity.

I suggest:

  These formations are permitted by the protocols and servers are
  expected to support them.  Although they can provide value in special
  cases, taking advantage of them is almost always bad practice unless
  the intent is to create some form of security by obscurity.

3. In Section 10.1:

  o  In general, it is wise to support addresses in Normalized form,
      using either Normalization Form NFC and, except in unusual
      circumstances, NFKC.

Is the intent to say that it is best to use NFC and to use NKFC only in unusual circumstances?

4. In Section 11.1:

  The mailto: schema [RFC2368] and discussed in the Internationalized
  Resource Identifier (IRI) specification [RFC3987] may need to be
  modified when this work is completed and standardized.

I suggest:

  The mailto: schema, defined in RFC 2368 [RFC2368] and discussed
  in the Internationalized Resource Identifier (IRI) specification [RFC3987],
  may need to be modified when this work is completed and standardized.

5. In Section 12:

  The key architectural difference between the
  experimental specifications and this newer set is that the earlier
  specifications supported in-transit downgrading including providing
  syntax and functions to support passing alternate, all-ASCII,
  addresses with the non-ASCII ones and special headers to indicate the
  downgraded status of messages.

Yes, "downgrading including providing" is impressive, but I suggest:

  The key architectural difference between the
  experimental specifications and this newer set is that the earlier
  specifications supported in-transit downgrading, which included the
  definition of syntax and functions to support passing alternate, all-ASCII,
  addresses with the non-ASCII ones as well as special headers to
  indicate the downgraded status of messages.

6. In Section 14:

  Expecting and most or all
  such transformations prior to final delivery be done by systems that
  are presumed to be under the administrative control of the sending
  user ameliorates the potential problem somewhat as compared to what
  it would be if the relationships were changed in transit.

I suggest:

  This potential problem can be mitigated somewhat by enforcing the
  expectation that most or all such transformations will be performed
  prior to final delivery by systems that are presumed to be under the
  administrative control of the sending user (as opposed to being
  performed in transit by entities that are not under the administrative
  control of the sending user).

Finally, a reference to RFC 5280 seems appropriate in Section 14 when
mentioning PKIX.

[Ballot discuss]
> Intended status: Informational

  and

Section 5322, paragraph 3:
>    Although this document is Informational, those
>    requirements are consistent with requirements specified in the
>    Standards Track documents in this set as described in Section 5.

  DISCUSS: The datatracker has this going for PS. Which is correct?

[Ballot comment]
Thank you for this very clearly and concisely written document.  I
have only a few minor editorial comments:

Section 7.1: s/left hand part/local part/ and right hand part/domain
part/ for consistency with convention elsewhere in the document?

Also in section 7.1: is US-ASCII equivalent to ASCII and can US-ASCII
be replaced by ASCII for consistency?  It's not terribly important,
but the rest of the document is written carefully enough that when I
read "US-ASCII" I thought it might have some significance relative to
ASCII as used throughout the rest of the doc.

In section 10.1, what, exactly, are "EAI mailbox names"?

[Ballot comment]
Thank you for this very clearly and concisely written document.  I have only a few minor editorial comments:

Section 7.1: s/left hand part/local part/ and right hand part/domain part/ for consistency with convention elsewhere in the document?

Also in section 7.1: is US-ASCII equivalent to ASCII and can US-ASCII be replaced by ASCII for consistency?  It's not terribly important, but the rest of the document is written carefully enough that when I read "US-ASCII" I thought it might have some significance relative to ASCII as used throughout the rest of the doc.

In section 10.1, what, exactly, are "EAI mailbox names"?

[Ballot discuss]
The Gen-ART Review by David Black on 10 Sep 2010 raised several
  issues.  The authors seem to agree that changes are appropriate,
  but a revised Internet-Draft has not been posted yet.

[Note]: 'I set the document status to PS, but I and the WG is happy for this to proceed as Informational
' added by Alexey Melnikov