[dns-dir] FW: WG Review: Recharter of Email Address Internationalization (eai)

["Romascanu, Dan (Dan)" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
IESG Secretary
Sent: Tuesday, May 25, 2010 8:00 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: WG Review: Recharter of Email Address Internationalization
(eai) 

A modified charter has been submitted for the Email Address
Internationalization (eai) working group in the Applications Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list ([e-mail]) by Tuesday, June
1, 2010.

Email Address Internationalization (eai)
-------------------------------------
Last updated: 2010-05-21

Current Status: Active

Chairs:
   John Klensin <[e-mail]>
   Joseph Yee <[e-mail]>

Secretary:
   Jiankang Yao <[e-mail]>

Applications Area Directors:
   Alexey Melnikov <[e-mail]>
   Peter Saint-Andre <[e-mail]>

Applications Area Advisor:
   Alexey Melnikov <[e-mail]>

Mailing Lists:
   General Discussion: [e-mail]
   To Subscribe:       https://www.ietf.org/mailman/listinfo/ima
   Archive:            http://www.ietf.org/mail-archive/web/ima

Description of Working Group:

The email address has two parts, local part and domain part.
Email address internationalization must deal with both. This working
group's previous experimental efforts investigated the use of UTF-8 as a
general approach to email internationalization.  That approach is based
on the use of an SMTP extension to enable the use of UTF-8 in envelope
address local-parts, optionally in address domain-parts, and in mail
headers.  The mail header contexts can include both addresses and
wherever existing protocols (e.g., RFC 2231) permit the use of
encoded-words.

All WG deliverables specified under the original charter, particularly
the experimental protocol specifications, have been completed.  The core
specifications have been implemented and interoperability tests
performed.  The WG is now being rechartered to permit advancing revised
versions of those specifications and supporting documents into the
standards track.

As a result of implementation and testing experience, the WG has
concluded to drop the model of in-transit downgrading that was a key
part of the original effort.
In-transit downgrading approaches simply do not work well enough and
predictably enough to be worth the considerable additional complexity
that accompanies them.  In particular, dropping in-transit downgrading
eliminates the need for the first significant change to the syntax of an
email address since RFC 821 and 822 were published in 1982.

Work will therefore reflect a "no fallback" approach.  That approach
provides a very minimal transition mechanism, but is consistent with the
long-term view that email with invalid addresses or syntax should be
rejected, rather than fixed up in transit between submission servers and
delivery servers.
Discoverable fallback addresses that could be applied before or during
message submission or after SMTP "final delivery" may be investigated.
The WG may also develop other materials to give advice to implementers
or operators.  Those efforts may lead to informational documents or best
practices recommendations, but are considered independent of the core
documents.  Work on them will progress only under the condition that it
not delay the primary standards track specifications.

The WG believes that the lessons learned from implementation and testing
and removal of in-transit downgrading as a goal eliminates all major
areas of controversy about the core specifications and should permit
very rapid progress.  Such rapid progress is an explicit goal for the
WG; issues resolved in the past will not be revisited unless those who
wish to do so can demonstrate data, reasoning, or consequences that were
not considered earlier.  At the same time, any attempt to significantly
extend an established and widely deployed set of protocols may uncover
new consequences or side effects that need consideration and evaluation.
If faced with a choice between spending time on such new considerations,
the WG will favor getting things right over accelerating the schedule.


Deliverables

The following deliverables are foreseen in this charter. The WG chairs
may (re)structure the deliverables into specific documents or document
sets as needed. Adding or removing documents other than those listed
below as "Required" or "Additional" will require a charter update.


Required Documents (these are the "core specifications"
referred to elsewhere)

* Overview and Framework for Internationalized
  Email, replacing RFC 4952 (Informational or Proposed
  Standard at IESG discretion once complete)

* UTF-8 SMTP extension specification, replacing RFC 5336  (Proposed
Standard)

* Header format specification, replacing RFC 5335 (Proposed
 Standard)

* Internationalized DSN specification, replacing RFC 5337  (Proposed
Standard)

* UTF-8 POP specification, replacing RFC 5721 (Proposed
 Standard)

* UTF-8 IMAP specification, replacing RFC 5738 (Proposed
 Standard)


Additional possible documents suggested.  While milestones are listed
for most of these documents, they may be dropped by the WG with the
consent of the Responsible AD.

* Advice for MUA implementors (Informational or BCP)

* Advice for EAI deployment (Informational or BCP)

* Advice for non-ASCII and ASCII addresses for the same mailbox
(Informational or BCP)

* Mailinglist (Informational or Standards Track, replacing
 draft-eai-mailinglist)

* Mailto (Proposed Standard, updating draft-duerst-mailto-bis  to
reflect internationalized addresses)

* Protocol extensions for RFC 4409 Submission Servers or  configuration
advice for the MUA->Submission server interface.

Goals and Milestones:

Mar 2010    Discussion of Recharter for standards track at
            IETF 77 (completed)
May 2010    New charter approval from IESG
Jul 2010    EAI Framework to IESG
Sep 2010    Headers  to IESG
Sep 2010    SMTP to IESG
Sep 2010    DSN to IESG
Nov 2010    IMAP & POP3 to IESG
Dec 2010    Decision about possible changes or comments about
            Submission Servers.  If the decision is to generate
            a document, the decision will include a schedule.
Jan 2011    Advice for non-ASCII & ASCII addresses to IESG
Jan 2011    Advice for MUA implementors to IESG
Jan 2011    Advice for EAI deployment to IESG
Apr 2011    Mailinglist to IESG
Apr 2011    Mailto (Proposed Standard) to IESG