Email Address Internationalization WG Meeting : IETF 70, Wednesday, December 5, 2007, 0900-1130 Location: Westin Bayshore, Vancouver, Canada Chairs : Harald Alvestrand , Xiaodong Lee Minutes : Donald Eastlake III Version : 1.2 ======================================================================== Where appropriate, resolutions are marked with *** in the text. Call to Order: 9:02am Appointed Scribe: Donald Eastlake. Blue Sheet, Agenda Bashing (no changes) Status of core documents -------------------------- Draft-ietf-eai-utf8headers-08.txt Draft-ietfi-eai-dsn-05.txt Smtpext-09.txt Have completed 2nd WG LC on these documents Issues have been recorded in tracker and mostly resolved except a few minor items. Chair has two issues on core documents where consensus does not seem solid: #1507 weird characters in UTF8HDR/DSN: Remove NO-WS_CTL from spec? #1518 normalization Pete Resnick: go with 2822bis which is tossing no white space controls Harald: Import text from 2822bis? Pete: No, just reference. Harald: creates a normative dependence on 2822bis... Pete: Yes but 2822bis should go to IETF LC as soon as no white space controls are resolved Harald: Going to Draft? Pete: Yes. Audience: Ooooh Tony Hansen: Does implementation report have to be done before LC if its for Draft? Harald: Yes. Harald: We can probably get away with a bit because we are aiming for Experimental. Philip Guenther: Could 2822bis go for Proposed and the upgrade to Draft later without change? Harald: Note that there is a minimum of six months at Proposed before can go to Draft. Can we reference 2822 and informatively say we'd prefer 2822bis...? Chris Newman (AD): Well, I have no problem with a down reference or stating intentions for future references. *** #1507: suggestion: normative reference to 2822 for "text", state in text that 2822bis is preferable. #1518: There are two statements in EAI draft. In 4.1 says normalization will be discussed; in 5 says will not specify normalization. Prudent use of normalization will involve restriction. John Klensin: I'm afraid of starting down a slippery slope. There are many normalizations with different purposes and effects. We are probably better off saying that local parts of addresses are for the receiving server and no one else should dare touch them. Harald: Some sections of the draft just talk about text all over, not just addresses. Possibilities are 1. delete the section 4.1 note. 2. remove the note at section 5. 3. move provisions to UTF8 header section. Klensin: We should just drop these provisions. Chris Newman: I'm concerned about interoperability. Different normalizations at different recipient domains would be a problem. We need to provide enough pointers that this is unlikely. Klensin: The problem is that pointing at Unicode without being specific can lead to choices of normalization that lose data, are inconsistent, etc. I've been pushing a document going a bit further by defining a Net UTF8 stream more generally for the IETF. But it fails due to controversy. Chris: Should we insert an informative reference to Klensin's Net UTF8? Klensin: Sure. Harald: At least two people want this. Chris: We should clarify that this is to be used by recipient domains in interpreting their local part. Harald: Then it sounds like it concerns headers, not general text. Klensin: It's more general but the provisions needs a bit of tweaking for which I volunteer to help. Poll on referencing Klensin draft: 20 in favor, 0 against. Klensin: My document has a discussion of issues on normalized versus non-normalized text. *** #1518 resolution: Refer to draft-klensin-net-utf8. Placement with the document at the editor's discretion. If removed from Section 5, section 5 can be removed. Pete Coats: Local addresses are usually case mapped. What about things like Turkish? Klensin: This sort of question is why no one but the target server manipulates this. Your example is an excellent example of why this should not be discussed in the EAI documents. Harald: We will confirm these resolutions on the mailing list, update the drafts, and send them to the IESG. Downgrade: Document: draft-ietf-eai-downgrade-05.txt ----------------------------------------------------- Issue #1496: Simple downgrade procedure? Could we close this issue by saying the description in Section 8.1 is adequate? John Klensin supports this. Appendix A: IMAP and POP have some upgrading text. Do we want to move such text to this document? Call for comments: none at microphone. Harald: Is this document ready for WG LC? Chris Newman: We should have some input from someone who has implemented downgrading. Suggest Ned Freed. I'll help get comments from him if needed. Klensin: If Ned has implemented this, that makes three implementations I know about. Randy Gellens: I think the document is in good shape but discussion of reconstructing information from documents could be added. Or this could be in a separate document or an Appendix. Harald: Are you suggesting to make Appendix A a separate document? Randy: Yes. Harald: Any objections. (none) I like it. Harald: Who has read this? (a few hands raised) Harald: Should Appendix A be a separate document? 2 in favor, 0 against. Klensin: Maybe the small response is because some people may need to consider this question for a while before answering. Harald: Will punt the question to the mailing list. With luck may we may get to WG LC before Christmas. If so, it will be a long WG LC due to the holidays. *** Resolution: Punt removal of Appendix A to a separate document to the list. *** Resolution: Otherwise, document is ready for WG Last Call. IMAP and POP ------------ Draft-ietf-eai-imap-utf8-02.txt Draft-ietf-eai-pop-02.txt Pete Resnick (imap author): We should talk about upgrading first. i.e., let Randy talk first. Randy Gellens: Up-conversion in IMAP and POP: Mail stores can be in either ASCII or UTF8. Clients can ask for either. Currently the server is specified to do the up-conversion from ASCII to UTF8. But servers will probably not do a good job either, as clients have not been doing a good job. It is unreasonable to expect a server to support all possible RFC 2047 encodings. A client is in better shape because it knows what encoding it could be interest in and it will have to do conversions for old servers anyway. * My proposal is to change the documents so that if a client requests UTF8, it will get it if the message is in UTF8, but if message is in ASCII, it gets ASCII. The hope is that as EAI is deployed, RFC 2047 encoding and downgraded messages stops being used. Chris Newman: (speaking as an author of the document, will not be the sponsoring AD) The counter argument is as follows: Language was put in to try for the brightest possible future. Implementations of RFC 2047 on clients have been poor. Server implementations on servers are better. Expecting your mobile client to have lots of character tables is a big burden. The goal was to support simpler UTF8 clients sooner, although there is a transition period where clients do have to support RFC 2047. We want to get to a brighter future sooner. Marc Crispin: I don't think there is any harm if the server does the conversion. We can't practically prohibit it. There are clients who want to see the RFC 2047 encoding to help the client guess what character set the other guy wants. No matter what level of services we provide in the server, there is no guarantee that clients will use it. It is discouraging to me that the most common client IMAP operations are basic raw message operations. Pete Resnick: Mostly agree with Marc. Sure, servers can always do this. We could have an extension for clients to ask for up-conversion. That's what the lemonade extension was about. Let's just leave it out of documents. John Klensin: Agree with Marc, but: we get in a trap because if you send stuff around in "funny" character sets and make a requirement for conversion than you impose a requirement to know all possible character sets, including those not standardized. We have learned that it is best to use one format in messages and leave the end points to do conversion to avoid the n x n problem. We should keep things as close to UTF8 as possible. Otherwise, MIME may just tell us why we can't interoperate. X: Only mail sender and re(cipient?) ... Kazunoi Fujiwara: A downgraded message is a traditional RFC 2822 message except for downgrade header. Andrew Daviel: If RFC 2047 is so complex and you want the end stations to do the conversion why not use Hex. Harald: It is no simpler to use Hex: Randy: The idea that if the document says noting then servers could do what they want is wrong because it leads to non-interoperability such as with signatures. If servers can do up-conversion then they need to indicate if they have done so, etc. Wink-wink won't cut it. Harald: Cases ... Randy: Up-converting a signed message will break the signature. If a message is EAI and you have to down convert, that will also break signatures but we have decided we have to live with that and it should go away as EAI is deployed. The recipient can see the down converted headers and complain to sysadmin/sender. Harald: Questions: Do people have enough information to decide on the server upgrade question? 10 have enough info, 3 don't Do people want to remove up convert form IMAP/POP? 15 do, 0 don't: Strong consensus. *** Resolution: Upconvert is removed. Pete: IMAP, if we go forward, we can eliminate section 9. Who has read -02 draft? (few) -02 makes use of ENABLE. ... You throw the big UTF8 switch at the beginning of the session. This is much better than switching just because you receive UTF8. The document needs various minor cleanups. It should be ready for wider review with next the version. Philip Guenther: Unbaked idea: UTF8 message flags are atoms. They can have any character in them. Use case is gmail labels. Harald: Seems outside of charter. Alexey: In IMAP WG ... Maybe some things like UTF8 login name should be removed from Experimental EAI document and made standards track. Chris Newman (AD): Get EAI documents out. I'm not concerned about things going from Experimental to Standards track quickly. Alexey: Do you have concerns about moving to a separate document in the future? Chris: No. Some things were put into EAI just because there was no place elsewhere. It's no problem splitting the IMAP doc if we want. * Harald: What about POP document? Randy: Current version was published in July. There has not been much discussion. I will revise it to remove up-conversion. Differs from IMAP in that IMAP has a big switch you throw and after you throw it everything is in the new bright UTF8 world. The POP document, on the other hand, has UTF8 versions of most separate commands. Clients are required to always use the UTF8 version if UTF8 capable and not switch back and forth but obviously a perverse client could. That structure means that a POP server might have to do down conversion on a per command basis. We could change POP to also be on a big switch basis. The down side is that POP does not have the same state situation as IMAP. Peter Coat: Why not have variants of the PASS command instead of all commands? Randy: Well, you would want a USER8 command... Chris: All POP commands are 4 characters. Pete: USR8? Randy: 8888? Pete: Say you don't know what the server supports? Randy: You get a capabilities list before you send even your user name. Harald: Choices for POP: Big switch, separate commands, no change, take to mailing list? Klensin: I favor a mode switch for two reasons. (1) Duplicate commands are just plain ugly and client changes per command is scary. (2) There are two ways to implement such things. One is to convert the entire message or message group and other in incrementally. An advantage of a mode switch is that it leaves the strategy up to the server. Per command changes pretty much requires the server to do it incrementally. Harald: 20 in favor of a big switch, 0 against. Strong consensus. *** Resolution: POP will use a "big switch" rather than separate commands. Peter Coat: On IMAP changes, I would like to see a reference to the lemonade convert document internet-draft. Klensin: The more we send people off to documents they may not be able to find, like IDs, the more we are asking for trouble... We should encourage lemonade to publish anything important as an RFC. Other Business -------------- 1. Should the "Mailto:" URL be a work item? Draft-duerst-mailto-bis-04.txt (expired) talks about this but not in the local part. This draft has no other home. 2. Implementation experience. Interop at next IETF? Klensin: Rant preview: some of us have observed at international meetings things that have led me to conclude that IRIs are seriously and terminally broken. Or at least IRIs are irrelevant to the problem that people expect IRIs to solve. On question is is "@" appropriate in some other character set that may by RtoL? Things are not so bad in URI form. IRI is a different matter. Other meta-issue: "Mailto:" URI is designed to take an address and some things that can be dropped into headers. Will be hard to change to take an address and an alternate address... Pete: Seems like the Martin Duerst effort is different. He is trying to internationalize current "Mailto:". We need to add info... Suggest postponing this. Randy: Brief comment on alternate address... Can also put a "body" parameter in a "Mailto:" URI. Klensin: I'm not saying it is insurmountable but it is non-trivial... Randy: Unfortunately, UTF8 in "Mailto:" is critical. Consider list headers. Harald: That's compelling. If we can't complete the mailing lists document without doing this, then we have to do it. People are invited to write text. *** Resolution: Internationalization of Mailto: is within scope, because it is a requirement for the List-headers work. Harald: Implementation experience. Rumors of three implementations. I just noticed that I had set up an eai-implementors mailing list. Eai-implementors@alvestrand.no, eai-implementors-request@alvestrand.no Some implementers are sensitive about revealing that they are implementing but, for those who wish to announce, it would be good if they do so. Chris? Chris (as AD): The current APPs area plan is to set aside a room Wednesday at the next IETF meeting where people can gather and do interoperability tests. APPs area is getting a bit small. Want to draw in people. We will try this. I don't have details yet but suggest people plan to bring laptops set up for informal interoperability tests. Future Plans: ------------- Harald: Action items. Core documents: new revisions addressing issues and editors fixes. Then, about a week for informal review. (Documents have been WGLCed twice already.) Then ship to IESG. Could do soon if editors are energetic. Other documents: WGLC on next version of downgrade document. Plan to send to IESG in January. By February should have total focus on remaining issues: IMAP, POP, Mailing Lists, ... We also have scenarios document. It might be a useful place to put information on various cases of clients understanding or not understanding talking to messages stores that understand or don't understand messages that are or are not EAI. John Klensin said he will work on framework document. Can maybe add the things that we didn't know should have been in it at first. Next meeting, final discussions on POP and IMAP and whatever else we can manage. Soon after that, currently chartered documents will be finished: a complete set of Experimental documents people can experiment with. Perhaps near the end of 2008, we can look at whether we want to push this onto the Standards Track. We may choose not to meet at the summer 2008 IETF meeting. Will probably meet again with a new charter in the Fall. Adjourn. 10:36