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 ima@ietf.org 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: [SP ] RCPT TO: [ SP ] 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: [SP ] RCPT TO: [ SP ] where EAI-parameter may be alt-addr or atomic according to the value of the EAI-parameter for example, if MAIL FROM: alt-addr=AsciiUser@example.com, it means that the EAI-parameter is alt-address because the value is an email address; if MAIL FROM: 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 ima@ietf.org into eai@ietf.org? Answer: Most of attendees do not agree that the change is needed, but nobody objects to let eai@ietf.org be an alias of ima@ietf.org. 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].