Subject: [EAI] Minutes about EAI Interim Meeting in Beijing

From: Xiaodong Lee <[email-masked]>
Date: Wed, 14 Jun 2006 22:18:33 +0800

Dear All,

Please refer to the minutes, and notify question 23 specially. ( The
attachment is the TXT version of the minutes)

Every author/editor, please update your draft and submit it on time, if
you want update your draft from 00 to 01.

Regards!

*******************************
EAI WG Interim Meeting Minutes
*******************************

The interim meeting of the EAI WG was held at Meeting Room 510 of CNNIC
in Beijing, China on June 6, 2006.
11 people attended in person, 2 people attended by sip-based conference,
3 people attended by video conference, 1 people attended by video/audio IM.

The minutes record the issues that were discussed, and the conclusions
that the people present came to. These decisions need to be verified
with the mailing list.
The agenda consisted of:
*Current drafts reviews
*Implementations and testing plans
*Terminologies issues
*Open issues

Current Drafts Review
For framework document:
1.All the drafts should be checked for consistency with the WG charter.
One piece of coordination between documents is that all terminology
needs to move to the framework docment.
2.Issues related to interaction with security protocols, such as
DKIM/PGP/SMIME should be considered in the framework document.
For scenarios document
3.There are still some scenarios that we may consider in the document.
These include scenarios that involve communication between two
EAI-compliant users connected via an infrastructure with one or more
non-EAI-compatible elements. There was no consensus on whether these
scenarios are necessary to support.

For utf8headers document
4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most
attendees agreed that ALT-ADDR and ATOMIC should be exclusive.
5.Section 6.2. needs to be changed to say that protocol fields in
RFC2821 are not affected. For more information, Harald has sent a
comments to [email-masked] with the title" [EAI] Suggested additions to
-headers- section 6.2 "
6.It is better that the editor can put some utf8header examples in the
document. Because the current ASCII ID formt cannot support utf-8, the
editor may submit a PDF version of his draft in addition to the ASCII one.

For smtpext document
7.Some profiles such as SASLprep may be used in the local part of the
email address, but we should start out by being permissive, discover
what the problems are and forbid that while doing implementaion
experiences. There was considerable uncertainty on how much the EAI
specification should try to police the content of the local part.
8.Using the below form defined in rfc2821 to define the mail and rcpt
commends may not work.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
The reason is that the "mail-parameters" and "rcpt-parameters" are
formally defined to only use ASCII characters.
We may use the following definition:
MAIL FROM:<reverse-path> [SP <EAI-parameter> ] <CRLF>
RCPT TO:<forward-path> [ SP <EAI-parameter> ] <CRLF>
where EAI-parameter may be alt-addr or atomic according to the value of
the EAI-parameter
for example,
if MAIL FROM:<utf-8User@IDN> alt-addr=[email-masked], it means
that the EAI-parameter is alt-address because the value is an email
address;
if MAIL FROM:<utf-8User@IDN> EAI-parameter=y, it means that the
EAI-parameter is atomic because the value is 'y' or 'n';
9.The smtpext document will just give some outline of the usages of the
parameters of alt-addr and atomic, the detailed specification should be
pointed to the downgrade document.

For downgrade document
10.Header encapsulation has some problems with section 2.5 of scenario
doc. The only downgrade mechanism that is compatible with section 2.5 of
the scenario doc is that described in section 5.3 of the downgrade
document, and this will be the one selected for future work.
11.We have identified some problems with the approach described in
section 5.3 of the downgrade document, but it still seems like the most
promising approach.
12.The editor will update downgrade document to incorporate current
utf-8headers documents
13.The approach of the section 5.3 needs more detail information.
14.Some RFC2821 related things in the downgrade document should be moved
to the smtpext document.
For IMAP/POP documents
15.The IMAP document mentions the upgrading. Those who care about
upgrading should read that section carefully to check that it says what
you think it should say.
For the mailing list document
16.Edmon from Affilias volunteers to write the mailing list documents
Implementation and testing plan
17.CNNIC will implement the prototype of EAI based on qmail and has a
demo in the next IETF meeing
18.TWNIC will implement the prototype of EAI based on sendmail and has a
demo in the next IETF meeing
19.Fujiwara from JPRS will update some MUA software to allow utf-8 based
email address.
20.Yangwoo Ko, Fujiwara, Delphij from sina.com and Li Boda from sohu.com
will help some implementation and test.
21.In the 67th IETF meeting, we should have a workable system based on
webmail.

Terminologies issues
22.Question: Is it ok to Work Group to Change mailing list [email-masked]
into [email-masked]?
Answer: Most of attendees do not agree that the change is needed, but
nobody objects to let [email-masked] be an alias of [email-masked].
23.Terminologies Option : In the past, multiple short names have been
used for this effort: EAI, I-email , i18nemail, utf8email, emailing,
IMX, IMAE, utf8smtp, ismtp. The WG needs to decide on one; in the
absence of compelling technical arguments for one or the other, the
meeting decided to take a straw poll to get a decision to present to the
mailing list.
In the first round, the result is (the number of supporters in the bracket)
Utf8smtp(4), i18nemail(4), utf8email(1), IMX(1), IMAE(1), ismtp
In the second round voting for the two favor: Utf8smtp, i18nemail. the
result is
Utf8smtp(5), i18nemail(3)
The WG meeting recommends that "UTF8SMTP" should be used for this
technology, but the final decision should go to the mailing list.
24.Terminology for various types of Email address
ascii@ascii means the pure ascii email address
Non-ascii email address means that there is at least a non-ascii
character in the email address, including the below 3 categories:
Non-ascii@Non-ascii
ascii@Non-ascii
Non-ascii@ascii
If alt-address is specified by the sender, it should be named as the
sender-specified ascii address;
If the email address is generated from a non-ASCII address by some
algorithmic function, it should be named as the algorithmic ascii address

Open issues:
25.Things that should be considered but we still don't know the answer.
1)When and how much useful downgrading will be.
2)Range of characters permitted in addresses and whether/how normalized
26.If an alt-address is specified and must be used in downgrading, but
the host at the alt-address domain advertizes the SMTP extension, the
alt-address MUST still be used, but the UTF8 headers SHOULD NOT be
downgraded.
27.The meeting discussed which additional documents to the ones listed
in the current WG charter were needed.
The most important one was thought to be Operational guidelines --which
includes suggestions to SMTP delivery site maintainers as to how to
create names -- they become very important if we avoid most or all
canonicalization and preparation specifications in SMTP but dump that
problem on delivery system decisions about naming. That clearly
interacts with the SASLPrep (or whatever) issues

The meeting was closed at 17:35 [GMT+8:00].

-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:[email-masked]
   http://www.lixiaodong.cn

EAI WG Interim Meeting Minutes

The interim meeting of the EAI WG was held at Meeting Room 510 of CNNIC in Beijing, China on June 6, 2006.
11 people attended in person, 2 people attended by sip-based conference, 3 people attended by video conference, 1 people attended by video/audio IM.

The minutes record the issues that were discussed, and the conclusions that the people present came to. These decisions need to be verified with the mailing list.
The agenda consisted of: 
*Current drafts reviews
*Implementations and testing plans
*Terminologies issues
*Open issues

Current Drafts Review
For framework document:
1.All the drafts should be checked for consistency with the WG charter. One piece of coordination between documents is that all terminology needs to move to the framework docment.
2.Issues related to interaction with security protocols, such as DKIM/PGP/SMIME should be considered in the framework document.
For scenarios document
3.There are still some scenarios that we may consider in the document. These include scenarios that involve communication between two EAI-compliant users connected via an infrastructure with one or more non-EAI-compatible elements. There was no consensus on whether these scenarios are necessary to support.

For utf8headers document
4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most attendees agreed that ALT-ADDR and ATOMIC should be exclusive.
5.Section 6.2. needs to be changed to say that protocol fields in RFC2821 are not affected. For more information, Harald has sent a comments to [email-masked] with the title" [EAI] Suggested additions to -headers- section 6.2 "
6.It is better that the editor can put some utf8header examples in the document. Because the  current ASCII ID formt cannot support utf-8, the editor may submit a PDF version of his draft in addition to the ASCII one.

For smtpext document
7.Some profiles such as SASLprep may be used in the local part of the email address, but we should start out by being permissive, discover what the problems are and forbid that while doing implementaion experiences. There was considerable uncertainty on how much the EAI specification should try to police the content of the local part.
8.Using the below form defined in rfc2821 to define the mail and rcpt commends may not work.
     MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>    
     RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
The reason is that the "mail-parameters" and "rcpt-parameters" are formally defined to only use ASCII characters.
We may use the following definition:
MAIL FROM:<reverse-path> [SP <EAI-parameter> ] <CRLF>   
       RCPT TO:<forward-path> [ SP <EAI-parameter> ] <CRLF>
where EAI-parameter may be alt-addr or atomic according to the value of the EAI-parameter
for example, 
if MAIL FROM:<utf-8User@IDN> alt-addr=[email-masked], it means that the EAI-parameter is alt-address because the value is an email address; 
if MAIL FROM:<utf-8User@IDN> EAI-parameter=y, it means that the EAI-parameter is atomic because the value is 'y' or 'n';
9.The smtpext document will just give some outline of the usages of the parameters of alt-addr and atomic, the detailed specification should be pointed to the downgrade document. 

For downgrade document
10.Header encapsulation has some problems with section 2.5 of scenario doc. The only downgrade mechanism that is compatible with section 2.5 of the scenario doc is that described in section 5.3 of the downgrade document, and this will be the one selected for future work.
11.We have identified some problems with the approach described in section 5.3 of the downgrade document, but it still seems like the most promising approach.
12.The editor will update downgrade document to incorporate current utf-8headers documents
13.The approach of the section 5.3 needs more detail information.
14.Some RFC2821 related things in the downgrade document should be moved to the smtpext document.
For IMAP/POP documents
15.The IMAP document mentions the upgrading. Those who care about upgrading should read that section carefully to check that it says what you think it should say.
For the mailing list document
16.Edmon from Affilias volunteers to write the mailing list documents
Implementation and testing plan
17.CNNIC will implement the prototype of EAI based on qmail and has a demo in the next IETF meeing
18.TWNIC will implement the prototype of EAI based on sendmail and has a demo in the next IETF meeing
19.Fujiwara from JPRS will update some MUA software to allow utf-8 based email address.
20.Yangwoo Ko, Fujiwara, Delphij from sina.com and Li Boda from sohu.com will help some implementation and test. 
21.In the 67th IETF meeting, we should have a workable system based on webmail.

Terminologies issues
22.Question: Is it ok to Work Group to Change mailing list [email-masked] into [email-masked]? 
Answer: Most of attendees do not agree that the change is needed, but nobody objects to let [email-masked] be an alias of [email-masked].
23.Terminologies Option : In the past, multiple short names have been used for this effort: EAI, I-email , i18nemail, utf8email, emailing, IMX, IMAE, utf8smtp, ismtp. The WG needs to decide on one; in the absence of compelling technical arguments for one or the other, the meeting decided to take a straw poll to get a decision to present to the mailing list.
In the first round, the result is (the number of supporters in the bracket)
Utf8smtp(4), i18nemail(4), utf8email(1),  IMX(1), IMAE(1), ismtp
In the second round voting for the two favor: Utf8smtp, i18nemail. the result is 
Utf8smtp(5), i18nemail(3)
    The WG meeting recommends that "UTF8SMTP" should be used for this technology, but the final decision should go to the mailing list.
24.Terminology for various types of Email address
ascii@ascii means the pure ascii email address
Non-ascii email address means that there is at least a non-ascii character in the email address, including the below 3 categories:
Non-ascii@Non-ascii
ascii@Non-ascii
Non-ascii@ascii 
If alt-address is specified by the sender, it should be named as the sender-specified ascii address;
If the email address is generated from a non-ASCII address by some algorithmic function, it should be named as the algorithmic ascii address

Open issues:
25.Things that should be considered but we still don't know the answer. 
1)When and how much useful downgrading will be.
2)Range of characters permitted in addresses and whether/how normalized
26.If an alt-address is specified and must be used in downgrading, but the host at the alt-address domain advertizes the SMTP extension, the alt-address MUST still be used, but the UTF8 headers SHOULD NOT be downgraded.
27.The meeting discussed which additional documents to the ones listed in the current WG charter were needed.
The most important one was thought to be Operational guidelines --which includes suggestions to SMTP delivery site maintainers as to how to create names -- they become very important if we avoid most or all canonicalization and preparation specifications in SMTP but dump that problem on delivery system decisions about naming. That clearly interacts with the SASLPrep (or whatever) issues 

The meeting was closed at 17:35 [GMT+8:00].

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Jun 2006 17:06:24 +0100

> EAI WG Interim Meeting Minutes

If this is *not* required, then the alt-address and atomic parameters are
not needed on RCPT commands. There are three scenarios:

(1) All recipients are i14ed. No downgrading required.

(2) The message is only sent to ascii recipient(s). Only the return path
needs to be downgraded.

(3) The message is sent to a mixture of recipients. When the message gets
to a point where downgrading is required (for transmission to one or more
ascii recipients), the i14ed recipients do not need to be downgraded
because they will not appear in the next hop's envelope, so again only
the return path needs to be upgraded.

In (2) and (3), addresses in the message header will need to be
downgraded, but that can only be done using information in the header
because the envelope will not in general have all the information
required.

> attendees agreed that ALT-ADDR and ATOMIC should be exclusive.

Why not pass the "atomic" flag around in the form of a pre-downgraded
alt-address? This reduces the number of options that are required and
eliminates the need for a global local-part downgrading algorithm -
i.e. it would preserve the localness of local parts.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT: NORTHEAST 4 OR 5, OCCASIONALLY 6 AT FIRST. THUNDERY
SHOWERS. MODERATE OR GOOD, BECOMING POOR AT TIMES.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Jun 2006 11:56:30 +0200

> (1) All recipients are i14ed. No downgrading required.
Scenarios document, section 2.1 and 2.2
> (2) The message is only sent to ascii recipient(s). Only the return path
Scenarios document, section 2.4
> the return path needs to be upgraded.
Scenarios document, section 2.5.
The sender's address may need to be downgraded.
> because the envelope will not in general have all the information
Agreed.
> i.e. it would preserve the localness of local parts.
isn't that the same as requiring that the alt-address be present always?

---

From: Tony Finch <[email-masked]>
Date: Thu, 15 Jun 2006 11:19:59 +0100

On Thu, 15 Jun 2006, Harald Alvestrand wrote:
> > not needed on RCPT commands. There are three scenarios: [snip]
>
> Scenarios document, [...]

Indeed. I was attempting to make points that aren't already covered there.

> The sender's address may need to be downgraded.

Er yes, that's what I meant - typo!

> isn't that the same as requiring that the alt-address be present always?

A missing sender alt-address would indicate an un-downgradable message.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: FAEROES SOUTHEAST ICELAND SOUTH VEERING SOUTHWEST 5 OR 6, INCREASING
7 FOR A TIME. OCCASIONAL RAIN OR DRIZZLE. MODERATE OR GOOD, BECOMING POOR AT
TIMES.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Jun 2006 10:30:00 +0100

> i.e. it would preserve the localness of local parts.
Yes, that's the obvious way to do it when you think about it, especially  
as it avoids the yet-unsolved problem of how to indicate ATOMICITY in the  
syntax of a mailbox.

Even if we manage to incorporate the ALT_ADDRESS in that syntax (and means  
to do that using a ",", "|" or somesuch as a separator have beed  
discussed), there will still remain the problem of revising the mailto URL  
so that it can specify both the UTF8 and ALT addresses. And hacking the  
mailto URL to indicate ATOMICITY would be even uglier.

-- 
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: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Jun 2006 07:18:37 -0700

Charles Lindsey wrote:
> Yes, that's the obvious way to do it when you think about it, 
> especially as it avoids the yet-unsolved problem of how to indicate 
> ATOMICITY in the syntax of a mailbox.
>
> Even if we manage to incorporate the ALT_ADDRESS in that syntax (and 
> means to do that using a ",", "|" or somesuch as a separator have beed 
> discussed), there will still remain the problem of revising the mailto 
> URL so that it can specify both the UTF8 and ALT addresses. And 
> hacking the mailto URL to indicate ATOMICITY would be even uglier. 
I saw one proposal that went <utf8@utf8|ascii@ascii> or 
<utf8@utf8|atomic> - not much uglier; you can tell the 2 apart by the 
absence of the @-sign.

I don't like the term "atomic" all that much, but that's another issue, 
and not that important.

---

From: Tony Finch <[email-masked]>
Date: Thu, 15 Jun 2006 16:58:16 +0100

On Thu, 15 Jun 2006, Harald Alvestrand wrote:

> I saw one proposal that went <utf8@utf8|ascii@ascii> or <utf8@utf8|atomic> -
> not much uglier; you can tell the 2 apart by the absence of the @-sign.

draft-ietf-eai-utf8headers-00 currently specifies "," as the separator
within the angle-addr. I'm not sure this is an entirely wise choice given
the existing meaning of "," and the way broken software mangles message
headers.

> I don't like the term "atomic" all that much, but that's another issue, and
> not that important.

"ACE-downgrade" would be a better term.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: SOUTH OR
SOUTHWEST 3 OR 4, OCCASIONALLY 5 IN THE NORTH. RAIN AT TIMES. MODERATE OR
GOOD, OCCASIONALLY POOR, MAINLY IN THE NORTH. SLIGHT OR MODERATE, OCCASIONALLY
ROUGH WEST OF THE OUTER HEBRIDES.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Jun 2006 17:44:11 +0100

On Thu, 15 Jun 2006 16:58:16 +0100, Tony Finch <[email-masked]> wrote:

>> <utf8@utf8|atomic> -

Yes, that would be a reasonable notation. One could put either "atomic" in  
there, or the actual ACE-ed address, with the same meaning.
> the existing meaning of "," and the way broken software mangles message

Yes, I would much prefer "|". I have already pointed out that it is  
unambiguous and parsable provided the syntax of the ALT-ADDRESS is  
restricted to the RFC 2821 address syntrax, rather than the full  
<addr-spec> from RFC 2822.
>> and

"downgradable"?

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Jun 2006 17:44:11 +0100

"downgradable"?

---

From: Tony Finch <[email-masked]>
Date: Fri, 16 Jun 2006 22:46:46 +0100

On Thu, 15 Jun 2006, Charles Lindsey wrote:
> unambiguous and parsable provided the syntax of the ALT-ADDRESS is restricted
> to the RFC 2821 address syntrax, rather than the full <addr-spec> from RFC
> 2822.

That would be a departure from past practice because syntactically
significant characters in email addresses are currently not members of the
atext set, whereas "|" is. I think ":" is a plausible choice. The
difference between a source path and an IMA is then indicated by the
presence of the local part before the "@" before the ":". (I'm avoiding
";" because Outlook's non-822 message format uses it instead of ",".)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FITZROY: NORTH OR NORTHEAST 4 OR 5, BUT VARIABLE 3 OR 4 IN NORTH. MAINLY FAIR.
MODERATE WITH FOG PATCHES.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 17 Jun 2006 20:53:31 +0100

>> restricted
> atext set, whereas "|" is.

Indeed, but in the real world "|" is never used within a domain name, i.e.  
after the "@" (at least, not if the message is sent by SMTP, because  
RFC2821 does not allow it).

So if you see
    <[email-masked] | [email-masked]>
then it is clear that the "|" cannot be a part of the domain (even though  
it is an atext). Hence it can only be the separator after which you expect  
to find an ALT-ADDRESS.

So all we need to do is to specify that utf-8 addresses use something more  
restrictive than <dot-atom> after the "@", and I suggested using the RFC  
2821 definition, or something based on it.

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Jun 2006 12:52:40 +0100

On Sat, 17 Jun 2006, Charles Lindsey wrote:
> after the "@" (at least, not if the message is sent by SMTP, because RFC2821
> does not allow it).

I understand that. But the email standards have a history of making
metacharacters reserved everywhere, rather than only being reserved where
the context allows them to act as a metacharacter. For example, square
brackets are only used for domain literals, but they are still not
permitted in local parts and display names.

On the other hand, perhaps this is an opportunity to relax the syntax so
that there are fewer restrictions on which ascii characters are allowed in
display names and local parts.

If we are going to break the design principles of the current standards,
we should at least try to reconstruct them with a coherent design.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: SOUTH 4 BACKING SOUTHEAST 5 TO 7, PERHAPS GALE 8 LATER. RAIN AT TIMES.
MODERATE OR GOOD.