2.1.5 Internationalized Email and Extensions (iee)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-13

Chair(s):

Harald Alvestrand <harald@alvestrand.no>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion:
To Subscribe:
Archive:

Description of Working Group:

We propose a BOF/ proto-WG session for the Vancouver IETF to discuss
internationalization of email addresses, including a supporting SMTP
Extension and the required internationalization of email headers,
expressing the latter in UTF-8. A design team based in the Joint
Engineering Team, consisting of specialists from CNNIC, JPNIC/JPRS,
KRNIC, and TWNIC plus some invited specialists have prepared and
posted key base documents for this work.

Internationalization of email addresses is the key next step in
moving the Internet from its base in ASCII-only identifiers.
People's desire to use their names, correctly spelled, in email
address local-parts is far stronger than the desire to use
internationalized domain names, already standardized by the IETF.

The goal of this work is to pursue, via a WG and IETF processes,
one possible approach to email internationalization, carrying it
through to a series of Experimental specifications. Once those
specifications exist, implementations will be created and tested.
If the results of that work are satisfactory, a reconstituted WG
will be proposed to standardize the approach.

The longer session is proposed in order to start community review
on the documents and strategy themselves, rather than just
establishing interest (which is already clear from the JET effort
and an earlier effort/mailing list that operated under the "IMAA"
label) and reviewing the proposed charter.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Minutes of the IEE BOF at IETF64, Vancouver, CA
Minutes take by: Sheldon Lee, Ed Lewis
Post-editing: Harald Alvestrand

Meeting held Thursday, November 10, 2005, in Salon A/B, Westin Bayshore Hotel

Meeting chair: Harald Alvestrand

1.Agenda Bashing
Keith Moore: Q - What is the scope of this BOF?
Harald Alvestrand: For this bof, the question of whether there are
better apporaches is out of scope. It focuses on the architeture
proposed, trying to see whether that is viable.
Conclusion: no objection for agenda.

2. Draft framework, draft-klensin-ima-framework - John Klensin
Outline:Overview and Framework for Internationalized Email
Conclusion: no discussion and no questions for this presentation now.

3. SMTP Extension, draft-yao-ima-smtpext - J. Yao
Outline:SMTP extension for internationalized email address. Describes the "IMA"
SMTP extension negotiating support for messages that use UTF-8 in
addresses and headers
Conclusion: no questions

4. UTF-8 header, draft-yeh-ima-utf8headers - J. Yeh
Outline: Transmission of email headers in utf8 encoding, specifiy the
use of unicode encoded in utf8 on email header bodies
Conclusion:no questions

5. Downgrading, draft-yoneya-ima-downgrade - K. Fujiwara
Outline:Downgrading can occur before sending, after reception or in
the middle of transmission 
Conclusion:no questions

6. Question and Answer/Discussion

Q1:[Ted Hardie] One of John's early comments was that the downgrading
issue was less important than the previous other three document, and
may be a local matter. I expect that that is a critical question? 

Answer [John Klensin]: The internationalized email address is most
important within a community, for instance Chinese, or Arabic. Those
people are interested and need to communication with each
other. Communication between groups is far less prevalent. 
The 8bitMIME experience showed that downgrade wasn't as important as
first thought - it was not a long term problem 

Q2:[Chris Newman] I'd like to address downgrading. I think the
charter need to say that we need the RFC about downgrading - at least
experimental. 
The email system is made of multiple subsystems, and each subsystem
needs to be upgraded. 
These are very large products and very complicated, so if I am going
to start supporting internationalized email address in the product, I
have to work on one subsystem at a time. Downgrading is most important
actually for software implementation, we need something common for
downgrading. POP/IMAP should do some changes. WG charter may need to
have POP/IMAP Experimental documents.

John Klensin: Need to be able to do things incrementally - Web
clients, User interfaces. Then stuff in the middle. 

Q3:[Keith Moore]: I am entirely supportive of this effort.
I am also really familar with this kind of problem.
Two questions: if someone sends a message to more than one person, and
some people have an user agent that supports the internationalized
email address, and others not, what should happen?  
The second question is about the user experience. Different users have
different experience on email uses. How to integrate these different
user experiences is an issue that should be considered. We should
consider the MUA first.
SMTP is the least hard part, and the last step we need to worry about.

John Klensin: It's time to get started on the SMTP part. Please don't
refer to the effort as "you" - we want you (Keith) to be part of it.

Q4:[Chris] Imap and POP should be discussed, I think those are
necessary drafts, and I might do one of them. I think we do want to
talk about the upgrading of punycode, that will be the normative part
of that.
Klensin: Punycode upgrading won't work. This effort is not meant to
solve all the problems of email at the same time.

Q5:[Dave Crocker]: Why do we need SMTP Extension? Why not just focus on
an ACE-type implementation? Why is utf-8 used in transportation
instead of ACE?
Klensin: Most operating systems are changing to support utf-8. Using
utf-8 is cooperating with the trend. Encodings tend to leak all over
the place - and negatively impact the user experience. Big problem is
Envelope address not equal to header address.

Q6: [Dave Crocker] Leakage happens with UTF8 as well. utf8 is nothing
but encoding.

Q7:[Pete Resnick]: I think UTF8 is better because current status of OS
is changed, if you take a block of data, it should be utf8.
[Dave]: that problem is solved, thank you

Q8:[Chris Newman]: Internationalizing email local parts is different
from the internationalizing domain name (IDN). These are different
infrastructures. IDN can not use the negotiation mechanism. IEE can
use some negotiation mechanisms.

Q9:[Pete Resnick]: The current work is a good framework with SMTP
extension. But the hard work is how to deal with the issues related to end
systems. How do we jump start the user interface/experience work?
Klensin: Violently agree. We focus on the MTA issues. End systems is
about the presentation layer issues, MUA is traditionally not
discussed much in the IETF.
There are already MUAs for this stuff; we need to get the network
protocols in place to connect them.

Q10:[Dave Crocker]: Should we follow the "PR" 2282 object & pseudo push?
The presentation layer is worrisome, no details documented.
I think the object needs to be labelled so that one can reliably tell
a "new format" object from an "old format" object.
Klensin: If necessary then next generation of email is needed.

Q10:[Philip Ganther]: utf-8 is one kind of Unicode. I am afraid that
some country such as china use local characters in GB encoding instead
of Unicode in applications.
Answer by Yao: We do not need to worry about this. In China, most Web systems and email systems or applications support Unicode by transforming GB coding into Unicode. Most systems can transform GB to Unicode.

Q11:[Philip Ganther]Is language tag needed?
Answer by harald : RFC 2231 is a solution if we need it. It's not been
very popular.
Ganther: Needs to be discussed as a work item.

Q12:[Ted Hardie]: There are islands of consenting adults using it already.
The problem is to deal with those who do not not consent yet.
One problem can be mailing lists. Another concern is whether this is a
constantly moving target. Do we cause failures for consenting or
non-consenting participants?
Klensin: We are no longer operating in the world with clean
bounce. Spam filterss throw stuff away. This is the most risky part of
the effort.

Q13:[Chris Newman]: I think the charter need to say that the
downgrading will be a experimental document and part of the initial
document set. Need POP and IMAP, volunteering to write the POP draft.

Q14:[Randall Gellens]: We cannot have SMTP without POP and IMAP.
Concerned about label for RFC2822

Q15:[Macos Sanz] It's important to address this from the beginning; we
need a syntactic definition of the new local part.
Klensin: Agree. Need to define which characters are allowed, lengths and so on.

Q16:[Dave Crocker]: This is a focus on mechanisms for walled gardens.
The default charset has been defined to ASCII. Defaults are bad
because defaults can be changed. No default tagging should remain; all
tags should be explicit. Labelling is easy and essential.

Q17:[Tony Hansen]: POP and IMAP are important. I'm willing to work on
these. Guidance from MUA authors is needed.

Q18:[Keith Moore]: I'm disturbed about where the discussion is going.
We must first deal with the user experience - document what user
experience we are trying to create.

Q19:[John Klensin]: IMAP and POP both need to be considered. The
differences between them do not make it easy to generalize.

Q20:[Chris]: What the MUA does should be defined in one draft, it need
a draft. POP will be the first doc; both POP and IMAP are needed.
We must deal with user experience - MUA, but think this new effort is
informed by that.  Need MUA draft to deal with leakage. POP and IMAP
at the same time is ok, but should not be held up by IMAP.

Q21:[Randy Glellens] Community's there. That's good. Still need IMAP
and POP. Ugly addresses vs unexpected 8bit problem.

Q22:[Cyrus Daboo, via Jabber]: Impact on LDAP, ACAP, vcard too.

Q23:[Harald]: Massive support for going forward with the work. Are we good with
charter? With updates adding documents for POP, IMAP, mailing lists
and other considerations for storing email addresses?

Q24:[Keith Moore] The first deliverable needs to be a document
describing the user interface in mixed cases - description of the
moving parts. All other work should be tabled until then.
When you send mail with UTF8 headers out, but have one or more
receipients that do not support it, what happens must be defined.

Q25:[Pete Resnick] There is existing stuff, we can't stop for that
document. But we need the model soon.

Q26:[John Klensin] An "user experience" document as a gating criterion
can block progress; this is not a normal type of document for the
IETF, so it's unclear what it should say.
Harald: Keith Moore defined it as "what happens when users send IEE
mail to non-island users".
Keith:Should be longer term and not rushed just because there are
already consenting adults doing it.

Q27:[Dave Crocker] Want another paragraph in charter, 2nd sentence of
2nd paragraph is backwards. Enable UTF8 address natively, consider it
the default. SNMTP extension declares a new character set.

Q28:[Ted Hardie]: Basically, I believe we need to make sure the mail
system will not be fragmented.

Q29:[Keith Moore]: Fragmentation is one failure. Garbage leaking is another.

Q30:[Harald] I'd like a show of hand for three question.
 1: Should we work on this charter, send to IESG, request a WG?
    almost all raise hand.
 2: Should we start working on this?
    almost all raise hand.
 3: Are you willing to help ?
    many raise hand.

Q31:[Harald] who want to implement the MUA and SMTP server?
    one (small, scared) for MUA, and CNNIC and 7 others for SMTP server

Q32:[Philip Ganther] Also need a webmail author involved.

Q33:[Harald] The acronym IMA is already used by another BOF, should we
suggest that we use IEE, or use another term?
Answer: hope to continue using IEE.

7. Others
The follow-on work is to revise the charter, and send to the area
director, ask the IESG to approve the WG, and to find a WG chair.

Slides

1 - Agenda
2 - Intro
3 - SMTP extension
4 - Header
5 - Downgrade