The meeting has started with short review of WG status: interim meeting in Beijing in June 2006 8 WG drafts, one new -00 (Mailing list draft)since the interim 1.1 Presentation: John quickly talked about -framework-01.txt document. Changes since the previous revision: Added comments about PGP/SMIME/DKIM. PGP and S/MIME don't sign headers, so they should not be affected by EAI, but DKIM is. John also updated terminology used in the document. 1.2 Questions or Comments: Ted: how EAI affects mailto IRI and IRI in general. Is this in scope for the WG? Tony Finch (in jabber): also vcards, ldap schemas.... John: Martin has asked to add some text to -framework. Ted suggests to use new URI schema, as this is a major syntax change. Philip Guenther: mail3 Philip: S/MIME messages containing RFC 2047 encoded word will have to continue to use RFC 2047 in the future. John: Sure. Text is welcomed. 2.1 Presentation: John quickly presented Harald's document. There were only editorial changes since the previous revision. No questions were asked about the document. 2.2 Questions or Comments: No. 3.1 Presentation: Yao Jiankang presented -smtpext-00.txt draft. Main changes since the previous revision 1). Refined the Mailbox Address Syntax definition 2). Changed the ESMTP name for the extension to be UTF8SMTP Open issues: 1). Do we recommend to use SASLPrep (RFC 4013) for local part of an EAI address? 2). EHLO keyword for the extension 3). Syntax of SMTP commands: where to put alternative address and what is the exact syntax for MAIL FROM/RCPT TO after that) 4.1 Presentation: After that Yao did live demo of sending EAI email (different cases from Harald's draft) using extended qmail. The demo implementation doesn't do mailing list related examples, but authors are working on it. The demo contained a bug: "Content-transfer-encoding: 8bit utf8", but otherwise worked well. 4.2Questions or Comments: Note that demo didn't exactly match the latest draft, but it will be updated. In particular the demo was using a single parameter to carry either alt-address or [old] atomic=yes semantics (as per rough consensus at Beijing interim). John commented that a single parameter versa 2 parameters is another open issue. Discussion about how to parse a single parameter followed in jabber Chris (in jabber): I like the fact eaipara eliminates the silly state of both ALT-ADDR and ATOMIC parameters. But it's badly named. Ted: it seems that in Beijing there was an agreement to change from 2 parameters (for alt address and atomic) to 1 parameter. Why? Yao: to avoid the silly state when both are present. John: we need to get consensus on the change today. John: disadvantage of a single parameter: the only way to distinguish keyword from alt-address is by looking at @ sign. What happens if some implementation misspells the keyword? John: there is also a possible performance implication of the change. Chris: I find the silly state to be a more serious design error than John's concern about forward parsing. Many (actually John agrees with them): Having a single parameter is a good thing. Pete: I'm still not clear on the difference between ATOMIC and the absence of the parameter? Ted: In the absence, it seems like it would mean you don't know that it is downgradable, so bounce the message. Suggestion to change "eaiparam=" to something like "downgrade=". Randy: Why have an ATOMIC parameter at all? If its purpose is to permit the RCPT TO address to be converted when ALT-ADDRESS is not supplied, why can't the sender just do the conversion and use the converted address as ALT-ADDRESS? Many: We like that. Ted: Would there be some clients that don't have code to downconvert utf8 addresses? This is the only good justification for having "atomic". John: We can have atomic flag in the submission server, so that the client doesn't need the code to downconvert the address. Tony Finch warns about importance of the user interface, specially address books, mailto: urls ... Tony Finch raises some concern of having a submission only extension: it doesn't actually create less work for people, as most MSAs are also MTAs, so the code is shared. Pete: What about the change to put alternative address inside the <> of the mail from/rcpt to? This requires changes to RFC 2821. Pete is proposing that this move outside the angle brackets Chris: Agree with Pete, I would rather reuse existing ESMTP parameter parsing code. [Poll]: the alt-address parameter outside of the <> (i.e. == separate ESMTP parameter) Consensus to move alt-address outside of the <>. [Coming back to discussion about encoding atomic =yes or alt-address in a single parameter] Eric A.: we can put @ sign before a keyword to make it distinguishable from an address Pete: if we can agree to remove atomic, we don't need to decide on how to encode keywords. Many: agree. [Poll]: eliminate atomic? John: I want to give an argument I don't like. Only the receiving server really knows its addresses. Chris: We can not impose semantics on ASCII local parts without breaking the current model. But we _could_ impose semantics on UTF-8 local parts when we introduce them. I'd say we should impose as few such semantics as possible, but having explicit downgrading rules makes sense to me. Consensus to remove the atomic from MTAs. Ted (with AD hat on): who is doing the draft for submission only atomic parameter? John/Randy: will do a draft on atomic in submission. John/Randy: but we would prefer to not have the atomic anywhere. 5.1 Presentation Nai-Wen Hsu presented "UTF8 Header" draft. Major changes: 1). i-Email header was added 2). ABNF has changed Pending changes: Update ABNF to disallow UTF-8 in Message-ID and Received header Open Issues: 1). alt-separator - currently using { } 2). name of the i-Email parameter 5.2 Qeustions or Comments: Discussion (in jabber) about alt-separator has followed. '{' and '}' are not "special" in RFC 2822, if a parser finds them in the domain part (e.g. ), it will happily treat them as a part of the domain, but domain lookup later will fail. Tony Finch suggests ':', saying that Microsoft consuses ';' and ','. Philip G.: how about nesting <>s for the downgrade? Marcos.Sanz: utf8@utf8 [ascii@punycode] ? 6.1 Presentation testing report (also by Nai-Wen Hsu). Test based on Sendmail. Different test cases: 1) downgrade envelope 2) downgrade headers (punicode in Received header, add i-Email header, etc.) 3). also tested mailing lists Linux "mail" was used as EAI-aware client. Outlook Express as non EAI-aware client A simple EAI POP3 server was written in Perl. Tested with CAPA UTF8 and without it Issues: 1) May add-spec change? Should we use ESMTP argument for alt-address? (no longer relavant due to todays discussions) 2) Recommend: alt-separator for mailing lists is the same as for 'utf8header' 3) EAI-parameter replaces Envelope from: can alt-address be from another domain; interaction with DSN ESMTP extension, etc. 4). SPF: is EAI parameter restricted to the MTA domain? If not, how to setup SPF? 5) Interaction with DKIM: downgrade/upgrade can break signatures 6.2 Questions or Comments: No 7.1 Presentation: Pete Resnick presented IMAP draft. Couple of offline comments were received. Major Issues: 1) non extended LIST returning UTF-8 stuff? Will try to address in the next revision 2) Does the server have to upgrade all messages in the mailstore? 7.2 Qeustions or Comments: Philip: there is some complexity with server not willing to do upgrade for *some* mailboxes. Can we eliminate this (all mailboxes are UTF8)? There is performance issue for servers, e.g. calculating proper RFC822.SIZE Chris: It was less effort to write the draft in a way that is UW c-client compatible than to write the simpler always-upgrade design and deal with the political fallout. Cyrus: I still think a mode switch with a '* NOUTF8' response on select for those mailboxes the server won't 'upgrade' is a simpler implementation approach. Chris: please suggest some text John: "* NOUTF8" is also consistent with the principle that one should design for the long term then work in transitions, rather than designing kludges that one has to carry around forever. Cyrus promised to write some text 8.1 Presentation: Edmon Chung presented draft on EAI Mailing lists. Draft philosophy: "mailing lists should not introduce any additional protocol requirements for EAI" Open issues: 1) Is it a requirement to obtain alt-addresses on mailing list expansion? If yes, how to obtain them? Different mailing list scenarios: a) Pure case (only UTF-8 subscribers involved) b) Mixed case (some members might not have alt-addresses) 2). "Downgrade Considerations for mailto URLs" List-* headers are mostly using URIs, so they should be using IRIs. So there is an issue of extending mailto: schema to allow for EAI. 3). Operational policy of requiring alt-address/ atomic info 8.2 Questions or Comments: Ted: we can't require all addresses to be downgradable (e.g. if there is a community of tai users exchanging email in tai - why do they need to have alt-addresses?) Legislating human behaviour is impossible task. Example problem: sender has non-downgradable address, some subscribers have ascii-only addresses - is the message to be bounced? William L.: if mail from was non downgradable, but the mailing list rewrites MAIL FROM, bounce might not be needed. Philip G.: EAI mailing list can help two groups of people to communicate (one is ascii only, ther other is utf8 only) Pete: is it realistic to expect that people are not going to have algorithmically derivable ascii addresses? John: it is difficult to prevent people from doing stupid things (referring to previous Ted's comment about legislating human behavior) John: needs to describe possible implementation options for "bounce non downgradable sender addresses" Ted: So the clear thing is that making a mailing list address with a non-downgradable address is a bad idea. Chris: Thought experiment: what if the mailing list simply replaced all UTF-8 addresses with the list submission address? Tony Finch: the problem posters might not be subscribers It seems that there are many open issues with the draft. This document is really hard. 9.1 Presentation: No presentation for POP3 draft, only to recieve comments 9.2 Questions or Comments: No comments in the room on Chris's POP3 draft. Side conversation in jabber on non-atom email addresses. One example is subaddressing . Consensus that implementations that support plus addressing must be able to decode punycode before extracting subaddress. This followed by a diffsicuin that punicode loses information, as it uses normalization. Whatever EAI will end up using for encoding UTF-8 will have to be lossless. 10.1 Presentation: Next presentation: Fujiwara report downgrade-01 Major changes: 1) Follow new header format, added i-Email header, etc. 2) Received header field is not allowed to contain UTF-8 Overview of the draft, 3 downgrade options 1) Don't downgrade headers (new?) 2) Downgrade headers 3). MIME encapsulation 10.2 Questions or Comments Pete: why "Downgraded: To:" instead of "Downgraded-To:"? Cyrus: many tools do grep on headers (include IMAP servers), so having Downgrade-to: would work better for them. Philip (rephrasing previous question): can we just check for 8-bit, instead of requiring all implementations to check for UTF-8? The former is certainly easier to do. Chris: checking for UTF-8 is not hard (pasted some code into jabber). Marcos.Sanz: First, it is a stateful check. Second the code does necessary checks, but they are not sufficient for valid UTF-8. Chris: There are three case: Message is standards compliant and has UTF-8 headers. Message is standards compliant and has 7-bit headers only. Message is not standards compliant. Treating the third case as "Garbage In Garbage Out" (GIGO) is not a problem in my book. So the UTF-8 test is necessary and sufficient, IMHO. Marcos.Sanz: If the GIGO case can be ignored, then checking for the highest bit set is sufficient and necessary, too. Chris: true, except for any potential security issues with overlong UTF-8 sequences. John: Assume I have UTF-8 headers and a body part that is, itself, CTE=foobar (a type you don't recognize). If I now encapsulate the whole thing as base64, the multiple encoding rule is broken. You can't upgrade CTE foobar to 8bit and then re-encode the whole business (as you could in principle do with Base64) because you have never heard of foobar. [Problem]: MIME-encapsulating is going to break nested encoding rules. tlr: Downgrade can replace utf8-only address with MAIL FROM address, which are not necessarily the same thing William L.: Some ESMTP parameters (e.g. ORCPT) pass addresses,how do utf8 addresses get encoded in them? Chris: ORCPT has a tagged address: ORCPT=rfc822;encoded-addr. So we could use ORCPT=eai;encoded-addr. Of course, the xtext encoding used by ORCPT explicitly forbids 8-bit, we'd have to change that to permit UTF-8. Comparison of different downgrade methods: MIME encapsulation preserves all header information, but make information unreadable in old UAs. There is also different cost associated with different methods. At the end of the meeting Xiaodong has summarized the rough consensus on outstanding issues for all docs: 1) ATOMIC parameter Answer:agreement to remove it 2) Syntax for alt-address in the envelope Answer: move it outside of bracket 3) Do we need new extended SMTP error codes for cover bouncing and downgrade cases? Answer:we don't need 4) Encapsulation Model issue: is it satisfactory? Answer:Multiple issues with existing text, need to be discussed deeply 5) Consistent terminology Answer: Every Author should update their draft within two weeks, if necessary, and should keep consistent terminology with framework draft.