Last Modified: 2005-10-13
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. Fujiwara 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 downgrading. 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 Crocker]: 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 Crocker] 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. I think the object needs to be labelled so that one can reliably tell a "new format" object from an "old format" object. 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 filterss 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 Crocker]: 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:[Dave Crocker] Want another paragraph in charter, 2nd sentence of 2nd paragraph is backwards. Enable UTF8 address natively, consider it the default. SNMTP extension declares a new character set. 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.