============== The EAI meeting has started with Harald Alvestrand (the WG chair) setting out the rules for the meeting: no arguments about whether the proposed approach (use UTF-8 email addresses) is Ok or not. Harald also added that the goal of the meeting is to try to resolve as many issues as possible. Ted Hardie, the responsible AD for the EAI mentioned that IESG will consider very seriously transition from the experimental phase of the EAI WG to the standard track phase (see the charter). 1) "EAI constraints" document. John Klensin has talked about his "EAI constraints" document, which talks about potential fragmentation issues among other things. The draft is describing John's personal opinion and thus doesn't have to become a WG document. John mentioned that the document is a set of tradeoffs and that it is not possible to satisfy all of them. John didn't talk in details his draft, assuming that everybody has read it and jumped to the Q&A right away. Q: Paul Hoffman has asked why this draft can't be an individual submission. A: John: processing for individual submissions takes long time, can be much slower than a WG document. 2). "EAI scenarios" document. Harald has presented his "EAI scenarios" draft next. He explained that he has tried to describe use cases in generic terms in order not to constraint the solution. All requirements which weren't 100% needed were removed. Paul Hoffman has suggested to fold this document into the framework document. John has replied that having too many informational documents is bad. Consensus of the room to make the draft a WG document, but keep it a separate draft. Consolidation can be done later on. 3). "EAI framework" document. John talked about the framework draft next. Q: Ted Hardie: the "problem statement" section says that major rework is needed on the document, what is planned? A: John: take out the text about major rework :-) . Q: Lisa has asked if the WG is considering multiple solution or just one. A: John has replied that there is a single solution, multiple documents are needed mostly in order to spread the workload between multiple people. Q: Paul Hoffman: the document doesn't say which documents are mandatory to implement and which are optional. A: John: everything is mandatory, but we are not sure when to downgrade and under what conditions. Q: Ted: the document only allows downgrade or bounce? A: John: yes Q: Dave Crocker: DSN has very strict rules when to bounce a message, why this draft is not as strict? A: John: the intent was to make EAI it as strict as DSN rules. 4). "Internationalized Email Headers" document Jeff Yeh has presented "Internationalized Email Headers" draft (draft-yeh-ima-utf8headers-01.txt). He described changes since -00 first: - added new header field to signal that header fields are in UTF-8 - clarified that new format requires the IEmail SMTP extension ... Rules in RFC 2822 were not changed, in particular header names are still in ASCII. Message-ID were not changed, date-time were not changed except for the "comment" part. RFC 2822 "phrase" and "comment" non-terminals can contain UTF-8 now. Jeff has also talked about updated ABNF for RFC 2822 "mailbox". Q: Ted: what issues are anticipate for mailing lists? A: Jeff: mixture of i18n and ASCII addresses in a single message Q: Dave Crocker: References include text, why not I18N them? A: Pete Resnick has jumped to the microphone: References only allows for comments, which are addressed by general rule about comments. Dave Crocker noted that RFC 733? provided a syntax form multiple addresses for an entity and it might be nice to reuse it. Chris Newman noted that it was important to give an example of internationalized timezone in the date-time, i.e. Internationalized comment after the timezone offset. John Klensin replied to this that I18N time zone might be an issue with deployed mail clients. Pete Resnick suggested to restrict where UTF-8 can be used, not just say "everywhere where 'comment' is used". Paul Hoffman suggested that the document should give detailed instructions "do this, don't do that", so that other WG like DKIM and PKIX can see any interactions with EAI. Pete Resnick noted that there were some shared syntax between 2821 and 2822, so it would be better to abstract it out. But need to be explicit about which rules affect email message format and which affect SMTP. Q: Philip Guenther (remotely through jabber): do the changes to these rules also effectively change the rules for MIME part headers inside the body, e.g. Content-*: headers at the starts of a MIME part? A: John Klensin: Philip's issues is not addressed, will be added to todo list Chris Newman suggested to use SASLPrep for email address canonicalization. Philip Guenther noted that S/MIME at least had no canonicalization levels. 5). "EAI SMTP extension" document Jiankang Yao talked about EAI SMTP extension (draft-yao-ima-smtpext-02.txt). Changes since the last revision: - added mailbox address syntax - added the ATOMIC and ALT-ADDRESS optional parameters to MAIL FROM and RCPT TO commands. ALT-ADDRESS takes precedence. If not specified and ATOMIC=yes, the I18N address can automatically be converted to ASCII (using yet to be decided ASCII Compatible Encoding) Q: Is there any reason to permit both ATOMIC and ALT-ADDRESS on a single address? As written, ATOMIC is ignored if ALT-ADDRESS is present Q: Pete Resnick: why change the "atom" ABNF? Why not use ABNF for the quoted string? A: John: Quoted strings are nothing but troubles operationally (based on 20 years of experience), so the draft is trying to address this issue on purpose. Q: Philip: are spaces allowed in local part (they need to be quoted)? This is frequently used with user+mailbox addressing. Q: Paul Hoffman: we can't have UTF-8 examples in the document, as RFC format doesn't allow for UTF-8 :-( . Q: Ted: email address can be in either UTF-8 or punycode? A: Yes. Q: Pete Resnick: Why ATOMIC is needed, my guess is for subaddressing. Harald request to defer the question till downgrade draft 6). "Downgrade" document Yoshiro Yoneya talked about the downgrade draft (draft-yoneya-ima-downgrade-01.txt). Changes from -00: - added downgrade requirements section - separate description of SMTP and message format downgrading Downgrade requirements: - downgrade once, don't upgrade until delivered - downgrading must be easy - MUST preserve header information - should work with DKIM/SPF - an attempt to downgrade MUST be recorded ... Chris Newman noted that MUST is too strong for preserving all header information. Chris Newman commented that some requirements can't be met (e.g. charset info is lost on conversion). He suggested to use "best effort" Yoshiro talked about downgrade procedure in details (see the draft). The draft describes two ways to downgrade: MIME encapsulation and header-by-header conversion. Harald (as a participant) suggested to remove the text about upgrading and MIME encapsulation case, as there is no use case for them. The removal will make the whole model simpler (and thus will simplify the document). Chris Newman wanted to have upgrade in a different spec (or not at all). But he doesn't think upgrade can be avoided, as lack of upgrade makes writing IMAP client very difficult (2 different cases to handle in IMAP code). Lisa commented that encapsulation can be useful, as MUAs can be upgraded to support UTF-8 easier. Pete Resnick recommended to split upgrade (or downgrade) of SMTP and message format. John has commented that encapsulation preserved all information. Chris Newman commented that protocol level upgrade can only happen inside an Autonomous System (e.g. enterprise), no need to talk about this in the draft. Ted Hardie commented that header-by-header approach has advantage that only MUA needed to be updated, no changes to POP/IMAP servers. John raised an issue about downgrading headers that the MTA doesn't know about. He also commented that encapsulation and header-by-header are not necessarily mutually exclusive. Harald pointed out that encapsulation can produce a message that the recipient can't use (i.e. MUA doesn't recognize the format). No consensus in the room about encapsulation versa header-by-header, the discussion should continue on the mailing list. 7). "POP3 I18N extension" document Chris has talked about POP UTF8 extension draft. The basic approach was to add parallel command for each affected command, as there are not that many of them. I.e. the draft added RET8,LST8 in addition to RETR, LIST. It also added an optional parameter to the USER command and requires use of SASLPrep for USER/PASS/APOP use SASLPrep. The NO-RETR capability was added to say that the server can't support "old" 7bit mode. Chris has considered an alternative approach (a new command to do a "switch to UTF-8 mode", but decided against it). In particular Chris thought that the TOP command was evil and thus there is no TOP8 command. Up-conversion is required to make clients easier to implement. Q: Randy Gellens: TOP8 is useful in mail clients (to check if a message is to be downloaded). John Klensin wished that TOP has never existed. He commented that for libraries that support both IMAP and POP, TOP adds extra effort and requires specific mode of parsing message. No consensus for "not having TOP8" and Chris gave up on not adding TOP8. Q: Tony Hansen: how RETR works on UTF-8 mailstores? A: Chris Newman: downgrade. The behavior of RETR is not changed in any way. Pete Resnick commented that clients who wanted to download just headers would use RETR and drop the connection. So it is better to have TOP8. Q: why clients are using TOP? Because they have limited memory/bandwidth? They should be using LIST. Randy Gellens commented that clients use TOP both to look at headers and to peek at body. Chris asked the WG if a global switch is better than a parallel set of commands? Harald (as the WG chair) replied that this should be taken to the mailing list. 8). John talked about fragmentation of group of users due to EAI (see John Klensin's message on the mailing list). Barry Leiba commented that if there were partitioning, EAI would help to limit it by preventing deployment of multiple incompatible methods. Paul Hoffman added that there might be partitioning of people based on left-to-right versa right-to-left scripts. Cyrus Daboo added that there are other issues to be addressed like vCard, mailto URLs, etc. 9). The meeting has concluded. Authors of the documents need to republish their documents with WG names.