[registrars] Fwd: WG Review: Email Address Internationalization (eai)

[Eric Brunner-Williams <brunner@xxxxxxxxxxx>]

Registrars, EPPers, ADs,

My most disapointing experience in 2001 was not getting fired by NeuStar,
it was the IETF IDN WG deciding to ignore the Joint Engineering Taskforce
(TW/CN/KR/JP + SG/HK/MO as observers) on how to fix, via intermediate maps,
the printer garbage fond to domain name phishers in Unicode, or an 8-bit
clean flagday, with ESMTP to differentiate between 7-bit and 8-bit clean
hops.

I'm pleased to see a new WG in this area, and one that will work on the
constraint that, several years ago, precluded an email flag day, or any
hetrogenaity of bit-lengths in envelope and header fields, which IMO is
the only reason IDNA (VGRS's RACE tossed slightly and lightly salted) is
controlling on what IDNs we well are.

I'll be contributing to the WG.
Eric

------- Forwarded Message

Return-Path: ietf-announce-bounces@xxxxxxxx
Delivery-Date: Tue Feb 21 13:09:22 2006
Return-Path: <ietf-announce-bounces@xxxxxxxx>
Received: from megatron.ietf.org (megatron.ietf.org [156.154.16.145])
	by nic-naa.net (8.13.4/8.13.4) with ESMTP id k1LI9LiF004525
	for <brunner@xxxxxxxxxxx>; Tue, 21 Feb 2006 13:09:21 -0500 (EST)
	(envelope-from ietf-announce-bounces@xxxxxxxx)
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBbt4-0007NY-AZ; Tue, 21 Feb 2006 13:05:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBbt2-0007Mb-0M; Tue, 21 Feb 2006 13:05:20 -0500
Received: from [156.154.16.129] (helo=cypress.neustar.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FBbt1-00071j-Ku; Tue, 21 Feb 2006 13:05:19 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1LI5J0e032191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2006 18:05:19 GMT
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1FBbt1-0006Yx-6q; Tue, 21 Feb 2006 13:05:19 -0500
Content-Type: text/plain
Mime-Version: 1.0
To: IETF Announcement list <ietf-announce@xxxxxxxx>
From: IESG Secretary <iesg-secretary@xxxxxxxx>
Message-Id: <E1FBbt1-0006Yx-6q@xxxxxxxx>
Date: Tue, 21 Feb 2006 13:05:19 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: ima@xxxxxxxx
Subject: WG Review: Email Address Internationalization (eai) 
X-BeenThere: ietf-announce@xxxxxxxx
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@xxxxxxxx
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:ietf-announce-request@xxxxxxxx?subject=unsubscribe>
List-Post: <mailto:ietf-announce@xxxxxxxx>
List-Help: <mailto:ietf-announce-request@xxxxxxxx?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:ietf-announce-request@xxxxxxxx?subject=subscribe>
Errors-To: ietf-announce-bounces@xxxxxxxx

A new IETF working group has been proposed in the Applications Area.  
The IESG has not made any determination as yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@xxxxxxxx) by March 1st.

+++

Email Address Internationalization (eai)
========================================

Current Status: Proposed Working Group

1.1. Chair(s)
TBD

1.2. Applications Area Director(s)
Ted Hardie <hardie@xxxxxxxxxxxx>
Scott Hollenbeck <shollenbeck@xxxxxxxxxxxx>

1.3. Applications Area Advisor
To be determined

1.4. Mailing Lists
General Discussion: ima@xxxxxxxx
To Subscribe: https://www1.ietf.org/mailman/listinfo/ima
Archive: http://www1.ietf.org/mail-archive/web/ima/index.html

1.5. Description of Working Group

Since early in the effort to internationalize domain names, which
resulted in the standards associated with IDNA, it has been
understood that internationalization of email address local parts is
even more important. After all, most prefer variations on their
names for those addresses. At the same time, email address
internationalization poses a series of special problems. Constraints
on the interpretation of local-parts by any system other than the
final delivery one --constraints that go back to before RFC 821 and
that have been vital to the operation of the Internet's email
environment-- make address encoding nearly impossible. The need to
use addresses in both the email envelope and in header fields, and to
do so in ways that are at least compatible, suggests that this is not
a simple and isolated problem.

This working group will address one basic approach to email
internationalization. That approach is based on the use of an SMTP
extension to enable both the use of UTF-8 in envelope address local-
parts and optionally in domain-parts and the use of UTF-8 in mail
headers -- both in address contexts and wherever encoded-words are
permitted today. Its initial target will be a set of experimental
RFCs that specify the details of this approach and provide the basis
for generating and testing interoperable implementations. Its work
will include examining whether "downgrading" -- transforming an
internationalized message to one that is compatible with unextended
SMTP clients and servers and unextended MUAs -- is feasible and
appropriate and, if it is, specifying a way to do so. If it is not,
the WG will evaluate whether the effort is worth taking forward.

Key parts of this effort include extended analyses and, if necessary,
proof of concept in three areas in addition to smooth operation when
all systems and components along a message path have been upgraded to
support the new facilities. They are

o Examination of scenarios for the appearance of these facilities to
users, including ways in which alternate addresses may be
specified if those are needed for downgrading.
o Examination of different locations at which downgrading might be
required and accomplished, differentiating between requirements
and capabilities at the point of origin (at or before the
submission server), those that exist while the message is in
transit, and those that apply after SMTP "final delivery" or in
the logical vicinity or an IMAP or POP server.
o Examination of the "mailing list question", i.e., how a mixture of
traditional and internationalized addresses on a mailing list will
impact message flows, error reports, and delivery notifications in
all plausible combinations of servers and addresses, including
internationalizated and traditional reverse paths.

Once the Experimental RFCs are completed and implemented, the
experience gathered will be evaluated. If the approach is found to
have been successful (using criteria the WG will establish as an
early work item), the WG will be rechartered to update the documents
for processing onto the standards track.

1.6. Deliverables

The following deliverables are foreseen in this charter. The WG
chairs may structure the deliverables into specific documents
or document sets as needed. Adding or removing documents
outside of these deliverables will require a charter update.

o Overview and architecture (Info)
o Interworking scenarios, including the "mailing list question"
(Info)
o SMTP extensions specification (Exp)
o Header format specification (Exp)
o Downgrading specification in SMTP (Exp)
o Downgrading specification in POP servers (Exp)
o Downgrading specification in IMAP servers (Exp)
o Results and evaluation of experiment (Info)

Going forward, it is possible that the SMTP downgrading specification
will go for Informational due to the difficulty of fully specifying
all necessary behaviours.

NOTE IN DRAFT: Additional possible documents suggested:
Advice for MUA implementors (Info)

1.7. Goals and Milestones

(Very tentative so far)

+-------------+--------------------------------------+--------------+
| DONE | Overview/architecture draft first | |
| | draft | |
| Feb 2006 | Interworking scenarios first draft | |
| DONE | SMTP Extensions first draft | |
| DONE | Header format first draft | |
| Mar 2006 | Downgrading in SMTP first draft | |
| Mar 2006 | Downgrading in POP first draft | |
| Mar 2006 | Downgrading in IMAP first draft | |
| Jun 2006 | Overview/architecture draft to IESG | |
| Jun 2006 | Interworking scenarios to IESG | |
| Sep 2006 | SMTP Extensions to IESG | |
| Sep 2006 | Header format to IESG | |
| Sep 2006 | Downgrading in SMTP to IESG | |
| Sep 2006 | Downgrading in POP to IESG | |
| Sep 2006 | Downgrading in IMAP to IESG | |
| Dec 2006 | Results and evaluation first draft | |
| Mar 2007 | Results and evaluation to IESG | |
| Mar 2007 | Group recharter for standards track | |
| | or disband | |
+-------------+--------------------------------------+--------------+

Table 1

1.8. Internet-Drafts

Drafts listed below were posted as initial discussion documents,
significantly preceeding the meeting at IETF 64 (Vancouver, 2005
Oct).

2005.06.27 draft-lee-jet-ima-00.txt
2005.07.18 draft-klensin-emailaddr-i18n-03.txt

Drafts listed below were prepared and posted to inform the discussion
at IETF 64. They replace those above.

o draft-klensin-ima-framework-00.txt
o draft-yao-ima-smtpext-00.txt
o draft-yeh-ima-utf8headers-00.txt
o draft-yoneya-ima-downgrade-00.txt

Drafts produced by the WG

None as yet

1.9. Request For Comments

None as yet


_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf-announce

------- End of Forwarded Message