Subject: [IMA] DRAFT minutes from IEE BOF

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 29 Nov 2005 15:22:48 +0100

Please send corrections, additions, spelling errors to me.

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. Fujiwarea
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 dowgrading. 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 Croker]: 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 Croker] 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, object needs to 
be labelled.
<this question was unclear in the notes>
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 
filters
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 Croker]: 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:[DaveCrocker] Want another paragraph in charter, 2nd sentence of 2nd 
paragraph is backwards. Enable UTF8 address natively, consider it the 
default. SNMTP extension decleares a new characte rset.

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.
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: yangwoo ko <[email-masked]>
Date: Wed, 30 Nov 2005 14:56:00 +0900

Harald Tveit Alvestrand wrote:
> 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.
> 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
> 
> Outline: Transmission of email headers in utf8 encoding, specifiy the 
> use of unicode encoded in utf8 on email header bodies
> Conclusion:no questions
> 
> 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?
> 
> 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
> 
> The email system is made of multiple subsystems, and each subsystem 
> needs to be upgraded.
> 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 dowgrading. POP/IMAP should 

dowgrading -> downgrading

> do some changes. WG charter may need to have POP/IMAP Experimental 
> documents.
> 
> Two questions: if someone sends a message to more than one person, and 
> some people have an user agent that supports the internationalized email 
> 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.
> 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.
> 
> Klensin: Punycode upgrading won't work. This effort is not meant to 
> solve all the problems of email at the same time.
> 
> Q5:[Dave Croker]: 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.
> 
> 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.
> Q8:[Chris Newman]: Internationalizing email local parts is different 
> from the internationalizing domain name (IDN). These are different 
> 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.
> 
> The presentation layer is worrisome, no details documented, object needs 
> to be labelled.

My understanding is that Dave want to be able to recognize a
"stored" message be of new format(i.e. IEE compliant) or old one
(i.e. RFC 822 compliant).

> 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.
> systems and email systems or applications support Unicode by 
> transforming GB coding into Unicode. Most systems can transform GB to 
> Unicode.
> 
> Answer by harald : RFC 2231 is a solution if we need it. It's not been 
> very popular.
> will be a experimental document and part of the initial document set. 
> Need POP and IMAP, volunteering to write the POP draft.
> 
> 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.
> 
> defaults can be changed. No default tagging should remain; all tags 
> should be explicit. Labelling is easy and essential.
> 
> We must first deal with the user experience - document what user 
> experience we are trying to create.
> 
> 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.
> 
> Q23:[Harald]: Massive support for going forward with the work. Are we 
> good with
> 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.
> 
> 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.
> 

default. SMTP extension declares a new character set.

> 
> Q28:[Ted Hardie]: Basically, I believe we need to make sure the mail 
> system will not be fragmented.
> 
> 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.
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 30 Nov 2005 12:21:59 -0000

On Wed, 30 Nov 2005 05:56:00 -0000, yangwoo ko <[email-masked]> wrote:

>> The presentation layer is worrisome, no details documented, object  
>> needs to be labelled.

Yes, I would like to see that. I have suggested a header which says, in  
effect "I am an I18N message". It may not be needed when messages are sent  
by SMTP, but it would be useful for all sorts of other purposes, such as  
when other transport protocols are used, or for use inside IMAP  
implementations.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Nov 2005 08:28:09 -0800

> (i.e. RFC 822 compliant).

I do not recall my words, but you the gist of my concern is approximately 
what you understood.

The general form of my concerns:

      When there are multiple choices in content form, the choice that 
applies for a given message needs to be labeled explicitly within the 
message.  Messages need to be self-contained, rather than relying on their 
context for interpretation.   This is during transit, as well as storage.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Nov 2005 12:26:07 -0500

--On Wednesday, 30 November, 2005 08:28 -0800 Dave Crocker
<[email-masked]> wrote:

> 
>>> Q10:[Dave Crocker]: Should we follow the "PR" 2282 object &
>>> pseudo push? The presentation layer is worrisome, no details
>>> documented, object  needs to be labelled.
>> "stored" message be of new format(i.e. IEE compliant) or old
>> one (i.e. RFC 822 compliant).
> 
> 
> I do not recall my words, but you the gist of my concern is
> approximately what you understood.
> 
>       When there are multiple choices in content form, the
> choice that applies for a given message needs to be labeled
> explicitly within the message.  Messages need to be
> self-contained, rather than relying on their context for
> interpretation.   This is during transit, as well as storage.

Dave,

While this clearly belongs in the minutes since it was
discussed, I want to open a bit of discussion on this topic.  I
want to stress that I don't have a strong position on it; I'm
just trying to understand the claimed requirement and what would
satisfy it a little better.

In theory, the content of messages in transit is not examined at
all, so it makes little difference what is in the headers except
at the endpoints.  

I'm also reminded of the famous "MIME-Version: 1.0" header
field, which was supposed to denote a new way of identifying
headers (particularly the presence and interpretation of
"Content-type:") as well as a formatted body.  Now, it was
arguably necessary because "Content-type:" was already in use
for slightly different information in a slightly different
format -- only if "MIME-version:" was also present could one be
reasonably assured that 
"Content-type:" could safely be interpreted according to MIME
rules.   But, for all the other good it has done us -- and, in
particular, our inability to change the version number in a
meaningful way -- we could have named the Content-type field
"MIME-Content-Type:", required it, and saved the extra header
line.

So, first, for amusement value, is this "MIME-Version: 2.0"?
My gut tells me this isn't a good idea, but at least the odds of
some intermediary filter discarding the message would be reduced.

More generally, is this a header that should be required to be
pushed into the message on final delivery or as part of a
gateway process, not unlike "Return-path:".  And, if not, what
is the value of having it in transit?

It also seems to me that the _real_ point at which this is most
important is in the message store and in the mechanisms used to
pick the message up from the store and deliver them to, e.g., a
POP server or client.   If that is the case, are we going to
start specifying message store formats now?  We have carefully
avoided it in the past and, as you know better than anyone else,
822 is specified as the format of headers on delivery, not the
format that has to be used in message stores and otherwise
within systems.

    john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Nov 2005 12:48:54 -0800

> all, so it makes little difference what is in the headers except

Parts of transit are packaging and unpackaging for posting and delivery.

These are examples of needing self-labeling.

> arguably necessary because "Content-type:" was already in use

Right.  Self-labeling.

We can quibble about the how, but the main point is that a message with a
free-text body has a different labeling than a message with a MIME body, so
that a processor can know which model to apply.

> is the value of having it in transit?

Yeah, I suppose we could quibble whether to have it only in the SMTP
commands during transit, but in the message itself otherwise, but my main
concern is robustness in the absence of context.

d/
-- 

Dave Crocker