From ima-bounces@ietf.org Thu Jan 03 15:14:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAWS4-0004Ol-VN; Thu, 03 Jan 2008 15:14:04 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAWS3-0004ON-3h for ima-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 15:14:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAWS2-0004OF-Mr for ima@ietf.org; Thu, 03 Jan 2008 15:14:02 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAWS0-00035W-Ja for ima@ietf.org; Thu, 03 Jan 2008 15:14:02 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 06A292596D8 for ; Thu, 3 Jan 2008 21:14:00 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09889-05 for ; Thu, 3 Jan 2008 21:13:52 +0100 (CET) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEDB92596D7 for ; Thu, 3 Jan 2008 21:13:51 +0100 (CET) Date: Thu, 03 Jan 2008 21:10:54 +0100 From: Harald Tveit Alvestrand To: EAI WG Message-ID: <843FB94CABC876CDB54ABD68@[192.168.1.119]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========BA2184FCB4900315B6BC==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 1.8 (+) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Subject: [EAI] Updated minutes from Vancouver meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --==========BA2184FCB4900315B6BC========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have done some slight updates to the minutes from the Vancouver meeting - a few spelling errors, a name spelled wrong, and some indenting to make it clearer who spoke when. These are also uploaded to the IETF meeting materials server. Harald --==========BA2184FCB4900315B6BC========== Content-Type: text/plain; charset=utf-8; name="EAI minutes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="EAI minutes.txt"; size=16611 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.=20 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)=20 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. =20 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.=20 Harald: Seems outside of charter.=20 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.=20 Eai-implementors@alvestrand.no, eai-implementors-request@alvestrand.no=20 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 --==========BA2184FCB4900315B6BC========== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --==========BA2184FCB4900315B6BC==========-- From ima-bounces@ietf.org Fri Jan 04 01:41:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAgF7-0004Nh-Av; Fri, 04 Jan 2008 01:41:21 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAgF5-0004Lc-Bk for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 01:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAgF4-0004LU-S5 for ima@ietf.org; Fri, 04 Jan 2008 01:41:18 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAgF2-0000J9-E8 for ima@ietf.org; Fri, 04 Jan 2008 01:41:18 -0500 Received: (eyou send program); Fri, 04 Jan 2008 14:41:04 +0800 Message-ID: <399428864.01848@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Fri, 04 Jan 2008 14:41:04 +0800 Message-ID: <031a01c84e9c$c9bd7300$236ff1da@yaojk> From: "YAO Jiankang" To: "Frank Ellermann" References: <395551932.22617@cnnic.cn> Subject: Re: [EAI] UTF8SMTP (was: Second Last Call - EAI protocol core documents) Date: Fri, 4 Jan 2008 14:41:08 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.3 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2082116330==" Errors-To: ima-bounces@ietf.org --===============2082116330== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkZyYW5rIEVsbGVybWFubiIg PG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogVHVl c2RheSwgTm92ZW1iZXIgMjAsIDIwMDcgNTozMyBQTQ0KU3ViamVjdDogW0VBSV0gVVRGOFNNVFAg KHdhczogU2Vjb25kIExhc3QgQ2FsbCAtIEVBSSBwcm90b2NvbCBjb3JlIGRvY3VtZW50cykNCg0K PldoYXQncyB0aGUgc3RhdGUgb2YgdGhlIGFydCB3aXRoIHRoZSByZWdpc3RyeSBJLUQocykgPw0K PlRoZSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgSUQua2xlbnNpbi1zbXRwLWNvZGUtcmVnaXN0cnkN Cj5zaG91bGQgYmUgSUQuaGFuc2VuLTQ0Njh1cGQtbWFpbGVzLXJlZ2lzdHJ5LCBzaG91bGRuJ3QN Cj5pdCA/ICAoTm8sIEhhcmFsZCwgdGhhdCdzIG5vdCBhICJuZXciIG5pdC4uLiA7LSkNCg0KDQpk byB5b3UgbWVhbiB0aGF0IHRoZSBlbmhhbmNlZCByZXNwb25zZSBjb2RlIGFzc2lnbm1lbnRzIHNo b3VsZCBiZSByZWZlciB0byAgIElELmhhbnNlbi00NDY4dXBkLW1haWxlcy1yZWdpc3RyeSBpbnN0 ZWFkIG9mIElELmtsZW5zaW4tc210cC1jb2RlLXJlZ2lzdHJ5Pw0KDQoNCllBTyBKaWFua2FuZw0K DQogPkZyYW5rDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSU1BIG1haWxpbmcgbGlzdA0KSU1BQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCg== --===============2082116330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============2082116330==-- From ima-bounces@ietf.org Fri Jan 04 02:41:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAhBR-0004vG-KS; Fri, 04 Jan 2008 02:41:37 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAhBQ-0004vA-Bm for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 02:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAhBQ-0004v2-1a for ima@ietf.org; Fri, 04 Jan 2008 02:41:36 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAhBN-00015Z-EN for ima@ietf.org; Fri, 04 Jan 2008 02:41:36 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id m047fHYT021030 for ; Fri, 4 Jan 2008 16:41:17 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0f95_6f01c912_ba98_11dc_87a4_0014221f2a2d; Fri, 04 Jan 2008 16:41:17 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:34774) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 4 Jan 2008 16:37:06 +0900 Message-Id: <6.0.0.20.2.20080104151649.0b7ae8e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Jan 2008 15:49:23 +0900 To: Harald Alvestrand , Frank Ellermann From: Martin Duerst Subject: Re: Mailto: (Re: [EAI] Re: Minutes from our Vancouver meeting) In-Reply-To: <476DEFDB.5060201@alvestrand.no> References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <476DEFDB.5060201@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 14:19 07/12/23, Harald Alvestrand wrote: >Frank Ellermann skrev: >> >> | *** Resolution: Internationalization of Mailto: is >> | within scope, because it is a requirement for the >> | List-headers work. >> >> Interesting. I kind of hoped that mailto-bis would >> be limited to fix mailto (for 3986, automagically >> also 3987). With 2822upd entering the picture that >> is not more as "impossible" as it used to be. But >> I still think that mailto-I18N should be a second >> (experimental) step after mailto-bis (PS) is ready. >> >That is also my impression; Martin hasn't indicated that he wants to >take on the EAI work at the same time as the rest of what he's doing. Except for the 'same time', I think I pretty much volunteered already, but I can do so again. If that draft will be experimental, I guess it can be very short, because it does't need to repeat what's in draft-duerst-mailto-bis. I propose that the draft be named draft-ietf-eai-mailto. I can probably submit it in a week or so. >So if mailto-bis rolls out (giving us a stable platform) without EAI >extensions, we can take it from there (I think). What do you mean by 'rolls out'? A published RFC? IETF last call? Or just another (hopefully closest to the last) I-D? I have just published another I-D. Any comments are very much appreciated. This has been lying around for quite some time, so I plan to move it forward rather soon. From the announcement: >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'mailto' URI Scheme Author(s) : M. Duerst, et al. Filename : draft-duerst-mailto-bis-04.txt Pages : 18 Date : 2008-01-04 This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It updates the syntax of 'mailto' URIs from [RFC2368] for better internationalization and compatibility with IRIs ([RFC3987]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-04.txt >>>>>>>> Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 04 02:56:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAhQ4-0003Cg-3l; Fri, 04 Jan 2008 02:56:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAhQ2-0003Cb-KP for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 02:56:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAhPu-0003CK-Au for ima@ietf.org; Fri, 04 Jan 2008 02:56:34 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAhPt-0000CJ-Lj for ima@ietf.org; Fri, 04 Jan 2008 02:56:34 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B46872596DA; Fri, 4 Jan 2008 08:56:32 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32417-04; Fri, 4 Jan 2008 08:56:26 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF1272596CB; Fri, 4 Jan 2008 08:56:25 +0100 (CET) Message-ID: <477DE69C.5070900@alvestrand.no> Date: Fri, 04 Jan 2008 08:56:12 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Martin Duerst Subject: Re: Mailto: (Re: [EAI] Re: Minutes from our Vancouver meeting) References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <476DEFDB.5060201@alvestrand.no> <6.0.0.20.2.20080104151649.0b7ae8e0@localhost> In-Reply-To: <6.0.0.20.2.20080104151649.0b7ae8e0@localhost> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst skrev: > At 14:19 07/12/23, Harald Alvestrand wrote: > >> Frank Ellermann skrev: >> >>> | *** Resolution: Internationalization of Mailto: is >>> | within scope, because it is a requirement for the >>> | List-headers work. >>> >>> Interesting. I kind of hoped that mailto-bis would >>> be limited to fix mailto (for 3986, automagically >>> also 3987). With 2822upd entering the picture that >>> is not more as "impossible" as it used to be. But >>> I still think that mailto-I18N should be a second >>> (experimental) step after mailto-bis (PS) is ready. >>> >>> >> That is also my impression; Martin hasn't indicated that he wants to >> take on the EAI work at the same time as the rest of what he's doing. >> > > Except for the 'same time', I think I pretty much volunteered > already, but I can do so again. If that draft will be experimental, > I guess it can be very short, because it does't need to repeat > what's in draft-duerst-mailto-bis. > I propose that the draft be named draft-ietf-eai-mailto. > I can probably submit it in a week or so. > That would be great. If you submit it as a WG draft, I think we as chairs can approve it quickly. > >> So if mailto-bis rolls out (giving us a stable platform) without EAI >> extensions, we can take it from there (I think). >> > > What do you mean by 'rolls out'? A published RFC? IETF last call? > Or just another (hopefully closest to the last) I-D? > Hopefully "published RFC". > I have just published another I-D. Any comments are very much > appreciated. This has been lying around for quite some time, > so I plan to move it forward rather soon. Which mailing list do you prefer for discussion of the 2368-update? > From the announcement: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : The 'mailto' URI Scheme > Author(s) : M. Duerst, et al. > Filename : draft-duerst-mailto-bis-04.txt > Pages : 18 > Date : 2008-01-04 > > This document defines the format of Uniform Resource Identifiers > (URI) to identify resources that are reached using Internet mail. It > updates the syntax of 'mailto' URIs from [RFC2368] for better > internationalization and compatibility with IRIs ([RFC3987]). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-04.txt > > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 04 04:11:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAian-0004Ox-Lb; Fri, 04 Jan 2008 04:11:53 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAiam-00044u-44 for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 04:11:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAial-0003zk-Ki for ima@ietf.org; Fri, 04 Jan 2008 04:11:51 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAiaj-0002iP-BN for ima@ietf.org; Fri, 04 Jan 2008 04:11:51 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m049Bk3t025135 for ; Fri, 4 Jan 2008 18:11:46 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 5bed_12eb7d82_baa5_11dc_98a6_0014221fa3c9; Fri, 04 Jan 2008 18:11:46 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60638) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 4 Jan 2008 18:07:36 +0900 Message-Id: <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Jan 2008 17:52:54 +0900 To: Harald Tveit Alvestrand , EAI WG From: Martin Duerst Subject: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) In-Reply-To: <843FB94CABC876CDB54ABD68@[192.168.1.119]> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I haven't been at the meeting, but here are some comments on the normalization discussion: >#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. This is a very clear and firm principle. >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. Different normalizations at different recipient domains are already in use: some recipients use case folding, some others don't. The problem with Unicode normalization is that it's much more difficult to figure out because there are no visual differences. >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. The Klensin draft is about what you send over the wire, not what recipients do. We know we shouldn't change anything in transit, so the responsible party is the (origin) MUA. Basically, what we should say is: - The (origin) MUA normalizes (see draft-klensin-net-utf8, section X) - The final MTA makes sure it understands such normalized addresses (either by just using the normalized form it its "address book", or by doing appropriate normalization when looking up a user). >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. I'd definitely want to see the tweaked text. >Poll on referencing Klensin draft: 20 in favor, 0 against. >Klensin: My document has a discussion of issues on normalized versus > non-normalized text. BTW, in Section 3, there are some wording problems: > The section above requires that, except in very usual circumstances, > all Net-Unicode strings be transmitted in normalized form. usual -> unusual? Regards, Martin. >*** #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. At 05:10 08/01/04, Harald Tveit Alvestrand wrote: >I have done some slight updates to the minutes from the Vancouver meeting - a few spelling errors, a name spelled wrong, and some indenting to make it clearer who spoke when. > >These are also uploaded to the IETF meeting materials server. > > Harald > > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 04 09:34:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAncU-0001Eu-PW; Fri, 04 Jan 2008 09:33:58 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAncT-0001Eo-50 for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 09:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAncS-0001Eg-RZ for ima@ietf.org; Fri, 04 Jan 2008 09:33:56 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAncP-0004H0-RU for ima@ietf.org; Fri, 04 Jan 2008 09:33:56 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C2BF92596FA; Fri, 4 Jan 2008 15:33:52 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09746-05; Fri, 4 Jan 2008 15:33:47 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 96FD32596F9; Fri, 4 Jan 2008 15:33:47 +0100 (CET) Message-ID: <477E43CB.5030609@alvestrand.no> Date: Fri, 04 Jan 2008 15:33:47 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: YAO Jiankang , Tony Hansen , Chris Newman Subject: ENHANCEDSTATUSCODES registry (Re: [EAI] UTF8SMTP) References: <395551932.22617@cnnic.cn> <399428864.01848@cnnic.cn> In-Reply-To: <399428864.01848@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org YAO Jiankang wrote: > ----- Original Message ----- > From: "Frank Ellermann" > To: > Sent: Tuesday, November 20, 2007 5:33 PM > Subject: [EAI] UTF8SMTP (was: Second Last Call - EAI protocol core documents) > > >> What's the state of the art with the registry I-D(s) ? >> The informative reference ID.klensin-smtp-code-registry >> should be ID.hansen-4468upd-mailes-registry, shouldn't >> it ? (No, Harald, that's not a "new" nit... ;-) >> > > > do you mean that the enhanced response code assignments should be refer to ID.hansen-4468upd-mailes-registry instead of ID.klensin-smtp-code-registry? This definitely needs to refer to an existing draft, and IANA can't perform the actions asked of it in the IANA considerations section without that draft being an approved procedure. So it's not only a needed reference, it's a normative one, by my reading. Tony, are you ready to send this to the IESG? Chris, are you ready to process it? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 04 11:29:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApQK-0005pO-HA; Fri, 04 Jan 2008 11:29:32 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JApQI-0005c5-SB for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:29:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApQI-0005aJ-Fk for ima@ietf.org; Fri, 04 Jan 2008 11:29:30 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JApQH-0002rA-7C for ima@ietf.org; Fri, 04 Jan 2008 11:29:30 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JApQB-000Mh1-99; Fri, 04 Jan 2008 11:29:23 -0500 Date: Fri, 04 Jan 2008 11:29:22 -0500 From: John C Klensin To: Martin Duerst , Harald Tveit Alvestrand , EAI WG Subject: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) Message-ID: <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 04 January, 2008 17:52 +0900 Martin Duerst wrote: >... >> 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. > > Different normalizations at different recipient domains are > already in use: some recipients use case folding, some others > don't. The problem with Unicode normalization is that it's > much more difficult to figure out because there are no > visual differences. Exactly. And, of course, some normalizations, such as NFKC, do change things for which there are visual differences and, while it is rare and UTC certainly wouldn't approve, some rendering engines compensate for perceived Unicode inadequacies by rendering a few precomposed characters differently from their character+ combining character canonical equivalents. >> 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. > > The Klensin draft is about what you send over the wire, not > what recipients do. We know we shouldn't change anything in > transit, so the responsible party is the (origin) MUA. > Basically, what we should say is: > - The (origin) MUA normalizes (see draft-klensin-net-utf8, > section X) > - The final MTA makes sure it understands such > normalized addresses (either by just using the normalized > form it its "address book", or by doing appropriate > normalization when looking up a user). The second statement effectively requires that the receiving MTA normalize and permits the sender to expect that it will do so. While it is unlikely that this would cause any problems with MUAs or MTAs that carefully observe the robustness principle, we have ample experience in the email world of people who interpret that principle as a license rather than a caution. I think that puts us on precisely the slippery slope I'm trying to avoid. Let me therefore make an alternate suggestion that takes us a small step in the direction of the document with UI and operational suggestions we've discussed but that may help with this. # Under most circumstances, the delivery MTA SHOULD be # configured so that local parts of addresses will be # accepted in NFC-normalized form and probably in # NFKC-normalized form. As with traditional ASCII # addresses and case-sensitivity [XXX], it MAY, of course, # permit alternate forms as aliases and, where the use of # such forms appears likely based on experience, usually # should do so. Note that this is completely consistent with the suggestion and style of the first full paragraph after the syntax rules of RFC 2821 Section 4.1.2 ("While the above definition for Local-part..."). The section number and text are identical in 2821bis, at least so far. My suggestion would be to incorporate the above, and reference both 2821 Section 4.1.2 and its 2821bis equivalent in "[XXX]" and let the RFC Editor sort things out. Then one might add if one wanted to (and I think there was some strong feeling for it during the Vancouver discussions) something like: # Just as message originators should be extremely careful # about oddly-quoted forms in unextended SMTP, the # possibility of Unicode normalization being applied # during in-transit processing independent of the MTA # actions specified here (see [net-utf8]) suggests that # message originators should exert extra caution about # sending unnormalized addresses. Note lower-case "should". Some formulation that used a different word entirely might be better. This sticks fairly closely to the 2821 formulation and provides no foundation at all for senders to expect that the delivery MTA will normalize whatever garbage they send (e.g., it is written in terms of accepting the normalized form, not in terms of normalizing whatever comes in -- Martin's text also accomplishes that, but I think this is more clear). I note that, while it has often not been an especially good idea, there is an SMTP history of using very strange local addresses to reduce the odds of undesired correspondence (spam included, but by no means restricted to that). If someone wants to parallel that with UTF8SMTP by permitting only an unnormalized form, we can (and probably should) warn against it as a general practice but should not, IMO, try to prohibit it. See also the "footnote" below. >> 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. > > I'd definitely want to see the tweaked text. Contrary to the discussion in Vancouver, the proposed text above would be applicable to, and should be applied in, SMTPEXT. A reference to it from the headers document would not be a bad idea. >> Poll on referencing Klensin draft: 20 in favor, 0 against. >> Klensin: My document has a discussion of issues on normalized >> versus non-normalized text. > > BTW, in Section 3, there are some wording problems: > >> The section above requires that, except in very usual >> circumstances, all Net-Unicode strings be transmitted in >> normalized form. > > usual -> unusual? Yep. Fixed in -07. Thanks. john "footnote". Most of the "should control characters be permitted in address local parts" discussion that has come up repeatedly here is bogus. I apologize to everyone for not catching it sooner. There is an explicit prohibition --in text, not in the ABNF-- in 2821 on the use of any control character in mailbox names. For details, watch for a note on the ietf-smtp list (I will find the discussion impossible to follow if it is going on in both places). However, the fact that there is such a prohibition in 2821 opens us to the possibility of needing a similar prohibition in SMTPEXT, extending the possible characters in UTF8SMTP addresses to Unicode-less-controls, rather than to Unicode generally. If we want to make that prohibition, it should probably be based on Unicode General Category values (see Unicode 5.0, table 4-7 (page 139) and elsewhere) rather than on a range of codepoints. Candidates for a prohibition include characters with values Cc (which gets the C0 and C1 controls), Cf, Cs, and Cn, with Zl and Zp being other likely candidates. Zs is problematic and should probably not be prohibited unless one wants to write a special rule with a list of characters or exceptions. It includes the traditional SPACE (U+0020) which cannot be prohibited without being more restrictive than 2821 but also includes a long series of space and space-like things, some of which are bad news (but others of which are not). _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 04 20:28:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAxqK-0003mE-7p; Fri, 04 Jan 2008 20:28:56 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAxqI-0003lj-GP for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 20:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAxqI-0003lb-6J for ima@ietf.org; Fri, 04 Jan 2008 20:28:54 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAxqF-0002Dw-KU for ima@ietf.org; Fri, 04 Jan 2008 20:28:54 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m051SpSB009514 for ; Sat, 5 Jan 2008 01:28:51 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JU500601D9L9V00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 04 Jan 2008 18:28:51 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JU500HIADG0H920@mail-amer.sun.com>; Fri, 04 Jan 2008 18:28:51 -0700 (MST) Date: Fri, 04 Jan 2008 17:28:51 -0800 From: Chris Newman Subject: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) In-reply-to: <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> To: John C Klensin , Martin Duerst , Harald Tveit Alvestrand , EAI WG Message-id: <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org When it comes to rules for human interactions, I've always felt a 3-level model is helpful: things that are illegal, things that are legal and acceptable behavior, and things that are legal and bad etiquette or bad practice. The cost of putting too much in the "illegal" category is reduced freedom. The third category works better for regional variations and allows faster evolution of rules (hopefully for the better) over time. Unicode crosses squarely into the human interaction area and needs the 3-level model. There are regional variations on Unicode normalization, our normalization knowledge needs to evolve with experience faster than RFCs are revised and there are numerous etiquette issues involved with global mail. There are things that are non-compliant in EAI addresses, things that are compliant and acceptable and things that need to be compliant but are often/always bad practice or bad etiquette. Our standards need to allow things in the third category and recognize they may not interoperate in all cases. This is uncomfortable territory for those who value precise specifications and interoperability as highly as the IETF traditionally has. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 04 20:42:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAy3A-0002Ko-6E; Fri, 04 Jan 2008 20:42:12 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JAy39-0002Ki-41 for ima-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 20:42:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAy38-0002Ka-O0 for ima@ietf.org; Fri, 04 Jan 2008 20:42:10 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAy37-0001Gz-CD for ima@ietf.org; Fri, 04 Jan 2008 20:42:10 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JAy2z-000Jtc-PK; Fri, 04 Jan 2008 20:42:02 -0500 Date: Fri, 04 Jan 2008 20:41:57 -0500 From: John C Klensin To: Chris Newman , Martin Duerst , Harald Tveit Alvestrand , EAI WG Subject: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) Message-ID: <47E569131CE12EE0EF4EE812@p3.JCK.COM> In-Reply-To: <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris, I'm not positive because we are using very different vocabularies and perhaps thinking about this differently, but I think we are in violent agreement. And I again note that we aren't proposing anything really new here: 2821 (and its predecessors, but 2821 is more explicit) effectively says "case-sensitive addresses are valid" and "if you use one of those puppies, bad things will happen and it may not interoperate". I think that is exactly your "compliant but often/always bad practice" case. So, to make this specific and be sure I understand you, we would have, e.g., * Unnormalized strings are valid, but sufficiently bad practice that they may not work reliably on a global basis. * C0 (and presumably C1) controls are prohibited, the first in 2821 and the second by an obvious extension from it. * Other kinds of punctuation, spaces, etc., are risky practice. Perhaps they will work, and we should expect SMTP receiver code to handle them, but creating dependencies on them in mailbox names that are chosen is usually a bad practice and may lead to interoperability problems. Is that reasonably close? john --On Friday, 04 January, 2008 17:28 -0800 Chris Newman wrote: > When it comes to rules for human interactions, I've always > felt a 3-level model is helpful: things that are illegal, > things that are legal and acceptable behavior, and things that > are legal and bad etiquette or bad practice. The cost of > putting too much in the "illegal" category is reduced freedom. > The third category works better for regional variations and > allows faster evolution of rules (hopefully for the better) > over time. > > Unicode crosses squarely into the human interaction area and > needs the 3-level model. There are regional variations on > Unicode normalization, our normalization knowledge needs to > evolve with experience faster than RFCs are revised and there > are numerous etiquette issues involved with global mail. There > are things that are non-compliant in EAI addresses, things > that are compliant and acceptable and things that need to be > compliant but are often/always bad practice or bad etiquette. > Our standards need to allow things in the third category and > recognize they may not interoperate in all cases. This is > uncomfortable territory for those who value precise > specifications and interoperability as highly as the IETF > traditionally has. > > - Chris > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 05 09:28:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBA0f-0007AJ-Bn; Sat, 05 Jan 2008 09:28:25 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBA0e-00079t-6u for ima-confirm+ok@megatron.ietf.org; Sat, 05 Jan 2008 09:28:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBA0d-00079Y-R1 for ima@ietf.org; Sat, 05 Jan 2008 09:28:23 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBA0d-0005bM-0k for ima@ietf.org; Sat, 05 Jan 2008 09:28:23 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D979F2596FB; Sat, 5 Jan 2008 15:28:21 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16157-05; Sat, 5 Jan 2008 15:28:16 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8770A2596F9; Sat, 5 Jan 2008 15:28:16 +0100 (CET) Message-ID: <477F93EE.7090506@alvestrand.no> Date: Sat, 05 Jan 2008 15:27:58 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: John C Klensin References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> <47E569131CE12EE0EF4EE812@p3.JCK.COM> In-Reply-To: <47E569131CE12EE0EF4EE812@p3.JCK.COM> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Chris Newman , EAI WG Subject: [EAI] Re: Normalization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin skrev: > Chris, > > I'm not positive because we are using very different > vocabularies and perhaps thinking about this differently, but I > think we are in violent agreement. And I again note that we > aren't proposing anything really new here: 2821 (and its > predecessors, but 2821 is more explicit) effectively says > "case-sensitive addresses are valid" and "if you use one of > those puppies, bad things will happen and it may not > interoperate". I think that is exactly your "compliant but > often/always bad practice" case. > > So, to make this specific and be sure I understand you, we would > have, e.g., > > * Unnormalized strings are valid, but sufficiently bad practice > that they may not work reliably on a global basis. > > * C0 (and presumably C1) controls are prohibited, the first in > 2821 and the second by an obvious extension from it. > > * Other kinds of punctuation, spaces, etc., are risky practice. > Perhaps they will work, and we should expect SMTP receiver code > to handle them, but creating dependencies on them in mailbox > names that are chosen is usually a bad practice and may lead to > interoperability problems. > > Is that reasonably close? That corresponds to what I think is reasonable. One thing that gets people (including me) worried here is that we have some choices that are analogous to case folding but less widely understood - NFD/NFC/NFKC being the most important one - where, in the absence of a recommendation, reasonable people can pick different choices (as MacOS and Windows did). Adding a recommendation of "if you don't have a good reason to do otherwise, do this - it works for most cases" would increase the chances of interoperability. But it doesn't fit very well with the "let's write down the rules only" approach we've so far taken in the EAI specs. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 06 02:23:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBPqi-0007lJ-GY; Sun, 06 Jan 2008 02:23:12 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBPqh-0007km-E9 for ima-confirm+ok@megatron.ietf.org; Sun, 06 Jan 2008 02:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBPqg-0007kN-Ud for ima@ietf.org; Sun, 06 Jan 2008 02:23:10 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBPqd-0008Ki-Eo for ima@ietf.org; Sun, 06 Jan 2008 02:23:10 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m067N4S4002975 for ; Sun, 6 Jan 2008 16:23:04 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 185d_385bc566_bc28_11dc_93f0_0014221fa3c9; Sun, 06 Jan 2008 16:23:03 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54305) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 6 Jan 2008 16:18:40 +0900 Message-Id: <6.0.0.20.2.20080105161511.0676aae0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Jan 2008 16:15:39 +0900 To: John C Klensin , Chris Newman , Harald Tveit Alvestrand , EAI WG From: Martin Duerst Subject: Re: Normalization (was: Re: [EAI] Updated minutes fromVancouver meeting) In-Reply-To: <47E569131CE12EE0EF4EE812@p3.JCK.COM> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> <47E569131CE12EE0EF4EE812@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 10:41 08/01/05, John C Klensin wrote: >So, to make this specific and be sure I understand you, we would >have, e.g., > >* Unnormalized strings are valid, but sufficiently bad practice >that they may not work reliably on a global basis. > >* C0 (and presumably C1) controls are prohibited, the first in >2821 and the second by an obvious extension from it. > >* Other kinds of punctuation, spaces, etc., are risky practice. >Perhaps they will work, and we should expect SMTP receiver code >to handle them, but creating dependencies on them in mailbox >names that are chosen is usually a bad practice and may lead to >interoperability problems. > >Is that reasonably close? That looks very good to me. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 06 03:11:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBQbq-0005ES-A5; Sun, 06 Jan 2008 03:11:54 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBQbp-0005EN-2G for ima-confirm+ok@megatron.ietf.org; Sun, 06 Jan 2008 03:11:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBQbi-0005E0-No for ima@ietf.org; Sun, 06 Jan 2008 03:11:46 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBQbg-0000Lp-7R for ima@ietf.org; Sun, 06 Jan 2008 03:11:46 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id m068Bf0c026603 for ; Sun, 6 Jan 2008 17:11:41 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 186d_02c6f9be_bc2f_11dc_833e_0014221fa3c9; Sun, 06 Jan 2008 17:11:40 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40583) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 6 Jan 2008 17:07:31 +0900 Message-Id: <6.0.0.20.2.20080106165610.08da6c70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 06 Jan 2008 17:11:12 +0900 To: John C Klensin , Harald Tveit Alvestrand , EAI WG From: Martin Duerst Subject: Re: Normalization (was: Re: [EAI] Updated minutes fromVancouver meeting) In-Reply-To: <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello John, At 01:29 08/01/05, John C Klensin wrote: > > >--On Friday, 04 January, 2008 17:52 +0900 Martin Duerst > wrote: >>> 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. >> >> The Klensin draft is about what you send over the wire, not >> what recipients do. We know we shouldn't change anything in >> transit, so the responsible party is the (origin) MUA. >> Basically, what we should say is: >> - The (origin) MUA normalizes (see draft-klensin-net-utf8, >> section X) >> - The final MTA makes sure it understands such >> normalized addresses (either by just using the normalized >> form it its "address book", or by doing appropriate >> normalization when looking up a user). > >The second statement effectively requires that the receiving MTA >normalize and permits the sender to expect that it will do so. I don't understand this. If I have a receiving MTA, and I set it up so that all usernames are in NFC, then I'll just rely on the fact that most senders will input addresses in NFC, and those who won't will die out. ># Under most circumstances, the delivery MTA SHOULD be ># configured so that local parts of addresses will be ># accepted in NFC-normalized form and probably in ># NFKC-normalized form. As with traditional ASCII ># addresses and case-sensitivity [XXX], it MAY, of course, ># permit alternate forms as aliases and, where the use of ># such forms appears likely based on experience, usually ># should do so. I'd fully stand behind this, exactly what I had in mind. >Note that this is completely consistent with the suggestion and >style of the first full paragraph after the syntax rules of RFC >2821 Section 4.1.2 ("While the above definition for >Local-part..."). The section number and text are identical in >2821bis, at least so far. My suggestion would be to incorporate >the above, and reference both 2821 Section 4.1.2 and its 2821bis >equivalent in "[XXX]" and let the RFC Editor sort things out. > >Then one might add if one wanted to (and I think there was some >strong feeling for it during the Vancouver discussions) >something like: > ># Just as message originators should be extremely careful ># about oddly-quoted forms in unextended SMTP, the ># possibility of Unicode normalization being applied ># during in-transit processing independent of the MTA ># actions specified here (see [net-utf8]) suggests that ># message originators should exert extra caution about ># sending unnormalized addresses. > >Note lower-case "should". Some formulation that used a >different word entirely might be better. I'm not sure about this. There is some possibility that normalization is applied in transit, but in that case, sending unnormalized addresses wouldn't be a problem, they'd get normalized. What would be a problem is having a receipient MTA that only accepts unnormalized, and the sender knowing that and sending unnormalized, but they not being able to communicate. So I'd reword the above to say that because transit MTAs are forbidden to normalize, and because receiving MTAs most probably have been set up to receive normalized, there should be extra caution against sending unnormalized addresses. >This sticks fairly closely to the 2821 formulation and provides >no foundation at all for senders to expect that the delivery MTA >will normalize whatever garbage they send (e.g., it is written >in terms of accepting the normalized form, not in terms of >normalizing whatever comes in -- Martin's text also accomplishes >that, but I think this is more clear). I'm very sure you're better than me to get the terms and wording right in this area. >I note that, while it >has often not been an especially good idea, there is an SMTP >history of using very strange local addresses to reduce the odds >of undesired correspondence (spam included, but by no means >restricted to that). If someone wants to parallel that with >UTF8SMTP by permitting only an unnormalized form, we can (and >probably should) warn against it as a general practice but >should not, IMO, try to prohibit it. Well, yes. But there is a tradeoff between making addresses strange to make sure you don't get reached by strangers and spammers, and not making your address too strange to make sure you still get reached by those you want to reach you. And I think with unnormalized forms, the tradeoffs would be particularly bad. But we don't have to mention that in the spec. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 06 05:39:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBSuB-0000HB-SB; Sun, 06 Jan 2008 05:38:59 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBSuA-0000H6-R4 for ima-confirm+ok@megatron.ietf.org; Sun, 06 Jan 2008 05:38:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBSuA-0000Gy-HN for ima@ietf.org; Sun, 06 Jan 2008 05:38:58 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBSu9-0007G6-Nb for ima@ietf.org; Sun, 06 Jan 2008 05:38:58 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JBSu3-000AZg-Lo; Sun, 06 Jan 2008 05:38:51 -0500 Date: Sun, 06 Jan 2008 05:38:50 -0500 From: John C Klensin To: Harald Alvestrand Message-ID: In-Reply-To: <477F93EE.7090506@alvestrand.no> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> <47E569131CE12EE0EF4EE812@p3.JCK.COM> <477F93EE.7090506@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Chris Newman , EAI WG Subject: [EAI] Re: Normalization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Saturday, 05 January, 2008 15:27 +0100 Harald Alvestrand wrote: > John C Klensin skrev: >> Chris, >> >> I'm not positive because we are using very different >> vocabularies and perhaps thinking about this differently, but >> I think we are in violent agreement. And I again note that we >> aren't proposing anything really new here: 2821 (and its >> predecessors, but 2821 is more explicit) effectively says >> "case-sensitive addresses are valid" and "if you use one of >> those puppies, bad things will happen and it may not >> interoperate". I think that is exactly your "compliant but >> often/always bad practice" case. >> >> So, to make this specific and be sure I understand you, we >> would have, e.g., >> >> * Unnormalized strings are valid, but sufficiently bad >> practice that they may not work reliably on a global basis. >> >> * C0 (and presumably C1) controls are prohibited, the first in >> 2821 and the second by an obvious extension from it. >> >> * Other kinds of punctuation, spaces, etc., are risky >> practice. Perhaps they will work, and we should expect SMTP >> receiver code to handle them, but creating dependencies on >> them in mailbox names that are chosen is usually a bad >> practice and may lead to interoperability problems. >> >> Is that reasonably close? > That corresponds to what I think is reasonable. > > One thing that gets people (including me) worried here is that > we have some choices that are analogous to case folding but > less widely understood - NFD/NFC/NFKC being the most important > one - where, in the absence of a recommendation, reasonable > people can pick different choices (as MacOS and Windows did). > > Adding a recommendation of "if you don't have a good reason to > do otherwise, do this - it works for most cases" would > increase the chances of interoperability. > > But it doesn't fit very well with the "let's write down the > rules only" approach we've so far taken in the EAI specs. Well, (i) We have considerable flexibility in Experimental documents to describe the theory on which decisions are based. If that means a fast revision of "framework"*, or that we need to move the priority of "advice on configuration" up, so be it. However I think the community would be better served right now by patching the information in somehow and then making a document reorganization the first step in a move onto standard track. (ii) "if you don't have a good reason to do otherwise, do this - it works for most cases" is precisely what a SHOULD statement should (sic) be all about. john * The minutes reflect the fact that I offered to work on a revision of "framework" to incorporate some scattered material, notably the appendix in SMTPEXT. While the text for the I-D is nearly ready for posting, pulling the text out of SMTPEXT would have created a mess or normative references to a proposed revision of an Informational document. That seemed a little too convoluted and a little too error-prone if we tried to rush it through, so the framework-bis project has gone on hold. We can change that, but it would need to be important enough to hold everything else up (by some months unless we can accelerate our current pace). Or we can copy everything to 4952bis and then remove all of the text from SMTPEXT that would not imply a normative reference. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 07 02:50:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmkO-0007Wb-1e; Mon, 07 Jan 2008 02:50:12 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBmkL-0007WC-N2 for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 02:50:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmkE-0007S9-Vt; Mon, 07 Jan 2008 02:50:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBmkE-00089p-KY; Mon, 07 Jan 2008 02:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 853C22AC64; Mon, 7 Jan 2008 07:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JBmkE-0001I3-9H; Mon, 07 Jan 2008 02:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 07 Jan 2008 02:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. MAO Filename : draft-ietf-eai-smtpext-10.txt Pages : 22 Date : 2008-01-07 This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-07024610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-07024610.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Jan 07 06:29:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBqAr-0006T7-EC; Mon, 07 Jan 2008 06:29:45 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBqAp-0006T1-UX for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 06:29:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBqAp-0006St-Ja for ima@ietf.org; Mon, 07 Jan 2008 06:29:43 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBqAo-0003oQ-Ie for ima@ietf.org; Mon, 07 Jan 2008 06:29:43 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew*man#ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.275) id 47820d22.4fe2.3a4 for ima@ietf.org; Mon, 7 Jan 2008 11:29:38 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id m07BTbJ5024393 for ; Mon, 7 Jan 2008 11:29:38 GMT Subject: Fwd: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> Message-ID: To: IMA Date: Mon, 07 Jan 2008 11:29:36 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 04 Jan 2008 08:52:54 -0000, Martin Duerst wrote: > I haven't been at the meeting, but here are some comments on the > normalization discussion: > >> #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. > > This is a very clear and firm principle. Not quite. There are two parties who might fiddle with a local-part 1. The originator of the message, who may choose from various Unicode normalizations that appear the same to the naked eye. 2. The final recipient MTA who gets to inspect the local-part in detail and thence figures out who/what to deliver it to. I agree that nobody between those two has any business changing anything as it passes through (but it will probably happen nevertheless :-( ). > The Klensin draft is about what you send over the wire, not what > recipients do. We know we shouldn't change anything in transit, > so the responsible party is the (origin) MUA. Basically, what we > should say is: > - The (origin) MUA normalizes (see draft-klensin-net-utf8, section X) > - The final MTA makes sure it understands such normalized addresses > (either by just using the normalized form it its "address book", > or by doing appropriate normalization when looking up a user). Exactly. Or, to be more precise, people who advertise their email addresses in Reply-To headers or in mailto: URLs or in any other way should do so in the most normal manner that their incoming MTA is able to understand. That way, MUAs originating mail to that address will use a well-normalized form without even realising it. Any incoming MTA that decides to treat visually identical local-parts (differing only in their normalizations) in different ways should be taken out and shot at dawn. Our drafts should make this clear. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 07 11:54:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvFS-0005Dq-Kl; Mon, 07 Jan 2008 11:54:50 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBvFQ-0005Dc-TW for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 11:54:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvFQ-0005DU-JB for ima@ietf.org; Mon, 07 Jan 2008 11:54:48 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBvFQ-00044M-A1 for ima@ietf.org; Mon, 07 Jan 2008 11:54:48 -0500 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1JBvFP-0007h3-NB for ima@ietf.org; Mon, 07 Jan 2008 11:54:47 -0500 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id 91CA33CD3BD; Mon, 7 Jan 2008 11:56:06 -0500 (EST) Date: Mon, 7 Jan 2008 11:56:06 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) Message-ID: <20080107165606.GH22237@afilias.info> References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> <47E569131CE12EE0EF4EE812@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E569131CE12EE0EF4EE812@p3.JCK.COM> User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Jan 04, 2008 at 08:41:57PM -0500, John C Klensin wrote: [3 points] > Is that reasonably close? Looks about right to me. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 07 12:20:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvds-0001py-3X; Mon, 07 Jan 2008 12:20:04 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBvdq-0001pt-Tz for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:20:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvdq-0001pl-Io for ima@ietf.org; Mon, 07 Jan 2008 12:20:02 -0500 Received: from wolverine01.qualcomm.com ([199.106.114.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBvdq-0005Gs-4W for ima@ietf.org; Mon, 07 Jan 2008 12:20:02 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:Date:To:From:Subject: Content-Type; b=PDaL9fwtpjQq78jDb2lzRBbcbkj2ToQKpCvUeX9e735NxS3NYe83E4by y54IoB82oUi2fgah0XFIfQGJFnpiUXh4uCaWcV+bxPndNYNxkhqjTFNxQ ls4nlGGyl0SAnZhc4a40Rsp1Ylg0iFEfpHjgwK9pRZ0RmxW3PjLLJ5xxE 0=; X-IronPort-AV: E=McAfee;i="5100,188,5201"; a="395528" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jan 2008 09:20:00 -0800 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.14.1/8.12.5/1.0) with ESMTP id m07HK0M4008759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Jan 2008 09:20:01 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.14.1/8.14.2/1.0) with ESMTP id m07HJxtm010602; Mon, 7 Jan 2008 09:19:59 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> Date: Mon, 7 Jan 2008 09:19:58 -0800 To: "Charles Lindsey" , IMA From: Ted Hardie Subject: Re: Fwd: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >Any incoming MTA that decides to treat visually identical local-parts >(differing only in their normalizations) in different ways should be taken >out and shot at dawn. Our drafts should make this clear. I'd like to point out a couple of flies; you can decide whether they are in our ointment or someone else's. 1) "Visually identical" local-parts can be constructed out of very different parts of the unicode code space. Cyrillic will give you a very nice PAT (u0420, u0410, u0422) that is visually equivalent to PAT (u0050, u0041, u0054). "Differing only in their normalizations" might distinguish between those two (they come from what we recognize as different contexts), but starting with "visually identical" as the test seems the wrong way round. We have to start from something else, it seems to me, and then go on to what identical means in the context of that something else. 2) This especially true where there are native readers of a local-part that might substitute a character they treat as "the same" even when the two are neither visually identical nor the same unicode code point. Many Chinese characters fall into this; they are culturally "the same" so much so that native readers may not be able to remember which version was associated with a specific string (was that "guo" fantizi or jiantizi?) The way to deal with the problem at an MTA level may well be to use the address-book mechanism you describe. If I want PAT (u0050, u0041, u0054) not to be equivalent to PAT (u0420, u0410, u0422), then the address book for the first *does not include the second*, visually identical or no. Similarly, if I want "guo" in jiantizi and fantizi (u56EF, u570B) to match, I had better put that in either a global or local address book. But visual identification is pretty much off the table, at least as it seems to me. regards, Ted _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 07 12:49:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw6A-0003gv-UW; Mon, 07 Jan 2008 12:49:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBw69-0003gq-O8 for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:49:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw69-0003gi-EL for ima@ietf.org; Mon, 07 Jan 2008 12:49:17 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBw65-00041P-BA for ima@ietf.org; Mon, 07 Jan 2008 12:49:17 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m07HnCUC012591 for ; Mon, 7 Jan 2008 17:49:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUA00E01BSAHO00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 07 Jan 2008 10:49:12 -0700 (MST) Received: from [10.1.110.5] (24-205-138-209.dhcp.psdn.ca.charter.com [24.205.138.209]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUA00JJSC5RL650@mail-amer.sun.com>; Mon, 07 Jan 2008 10:49:05 -0700 (MST) Date: Mon, 07 Jan 2008 09:49:09 -0800 From: Chris Newman Subject: Re: Normalization (was: Re: [EAI] Updated minutes from Vancouver meeting) In-reply-to: <47E569131CE12EE0EF4EE812@p3.JCK.COM> To: John C Klensin , Martin Duerst , Harald Tveit Alvestrand , EAI WG Message-id: <469697D58ECB573209BE2C50@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <843FB94CABC876CDB54ABD68@[192.168.1.119]> <6.0.0.20.2.20080104173647.0b7ad4b0@localhost> <5D532FDDE2FD5F375FF66B85@p3.JCK.COM> <108DFDBB9CE4F600434953B0@446E7922C82D299DB29D899F> <47E569131CE12EE0EF4EE812@p3.JCK.COM> X-Spam-Score: -1.0 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote on 1/4/08 20:41 -0500: > I'm not positive because we are using very different > vocabularies and perhaps thinking about this differently, but I > think we are in violent agreement. And I again note that we > aren't proposing anything really new here: 2821 (and its > predecessors, but 2821 is more explicit) effectively says > "case-sensitive addresses are valid" and "if you use one of > those puppies, bad things will happen and it may not > interoperate". I think that is exactly your "compliant but > often/always bad practice" case. > > So, to make this specific and be sure I understand you, we would > have, e.g., > > * Unnormalized strings are valid, but sufficiently bad practice > that they may not work reliably on a global basis. > > * C0 (and presumably C1) controls are prohibited, the first in > 2821 and the second by an obvious extension from it. > > * Other kinds of punctuation, spaces, etc., are risky practice. > Perhaps they will work, and we should expect SMTP receiver code > to handle them, but creating dependencies on them in mailbox > names that are chosen is usually a bad practice and may lead to > interoperability problems. > > Is that reasonably close? Yes. That's well stated. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 07 14:14:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxQr-0001W9-TP; Mon, 07 Jan 2008 14:14:45 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBxQq-0001Vz-RD for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 14:14:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxQq-0001Vm-FH for ima@ietf.org; Mon, 07 Jan 2008 14:14:44 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBxQq-00044U-4F for ima@ietf.org; Mon, 07 Jan 2008 14:14:44 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 7 Jan 2008 11:14:43 -0800 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.41]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Mon, 7 Jan 2008 11:14:38 -0800 From: Shawn Steele To: "ima@ietf.org" Date: Mon, 7 Jan 2008 11:14:37 -0800 Thread-Topic: Unicode Security Considerations Thread-Index: AchRYYuGCyWrD8Z9ScGMIWqccUFOMA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [EAI] Unicode Security Considerations X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0311429132==" Errors-To: ima-bounces@ietf.org --===============0311429132== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C9BF0238EED3634BA1866AEF14C7A9E55E1538020BNAEXMSGC116re_" --_000_C9BF0238EED3634BA1866AEF14C7A9E55E1538020BNAEXMSGC116re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some of the normalization discussion has been around the security and appro= priateness of various Unicode characters. It seems to me that instead of t= rying to describe the security of Unicode, a pointer to an appropriate doc = like UTR# 36 http://www.unicode.org/reports/tr36/ would be better, with per= haps a few points that are specific to email. Eg: "When creating email local parts, appropriate Unicode security consideratio= ns should be taken into account..." Each site may have unique requirements that would be inappropriate for a di= fferent site. - Shawn --_000_C9BF0238EED3634BA1866AEF14C7A9E55E1538020BNAEXMSGC116re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some of the normalization discussion has been aroun= d the security and appropriateness of various Unicode characters.  It seems = to me that instead of trying to describe the security of Unicode, a pointer to= an appropriate doc like UTR# 36 http://www.unicode.org/reports/tr36/ would be better, with perhaps a few points that are specific to email. = ; Eg:

 

“When creating email local parts, appropriate Unicode security considerations should be taken into account…”<= o:p>

 

Each site may have unique requirements that would b= e inappropriate for a different site.

 

-&nb= sp;   Shawn

 

 

 

 

--_000_C9BF0238EED3634BA1866AEF14C7A9E55E1538020BNAEXMSGC116re_-- --===============0311429132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============0311429132==-- From ima-bounces@ietf.org Mon Jan 07 15:41:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBymu-0007x2-Hj; Mon, 07 Jan 2008 15:41:36 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JBymt-0007wh-6C for ima-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 15:41:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByms-0007wZ-Sd for ima@ietf.org; Mon, 07 Jan 2008 15:41:34 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByms-0008Rp-Iq for ima@ietf.org; Mon, 07 Jan 2008 15:41:34 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1199735558!27929960!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 6141 invoked from network); 7 Jan 2008 19:52:38 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-12.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 7 Jan 2008 19:52:38 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id m07JqbNJ027872 for ; Mon, 7 Jan 2008 11:52:37 -0800 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id m07JqYAx027852 for ; Mon, 7 Jan 2008 11:52:35 -0800 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m07JqYiT018476 for ; Mon, 7 Jan 2008 13:52:34 -0600 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m07JqSt6018406 for ; Mon, 7 Jan 2008 13:52:28 -0600 Received: from [135.25.190.119] (unknown[135.25.190.119](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20080107195228gw10010gree> (Authid: tony); Mon, 7 Jan 2008 19:52:28 +0000 Message-ID: <478282CD.3080104@att.com> Date: Mon, 07 Jan 2008 14:51:41 -0500 From: Tony Hansen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: ENHANCEDSTATUSCODES registry (Re: [EAI] UTF8SMTP) References: <395551932.22617@cnnic.cn> <399428864.01848@cnnic.cn> <477E43CB.5030609@alvestrand.no> In-Reply-To: <477E43CB.5030609@alvestrand.no> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Frank Ellermann , Chris Newman , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Just an FYI, John and I have an update to ID.hansen-4468upd-mailesc-registry "in the works". It will be submitted soon and can be last called at that point. Tony Harald Alvestrand wrote: > YAO Jiankang wrote: >> ----- Original Message ----- From: "Frank Ellermann" >> >> To: >> Sent: Tuesday, November 20, 2007 5:33 PM >> Subject: [EAI] UTF8SMTP (was: Second Last Call - EAI protocol core >> documents) >> >> >>> What's the state of the art with the registry I-D(s) ? >>> The informative reference ID.klensin-smtp-code-registry >>> should be ID.hansen-4468upd-mailes-registry, shouldn't >>> it ? (No, Harald, that's not a "new" nit... ;-) >>> >> >> >> do you mean that the enhanced response code assignments should be >> refer to ID.hansen-4468upd-mailes-registry instead of >> ID.klensin-smtp-code-registry? > This definitely needs to refer to an existing draft, and IANA can't > perform the actions asked of it in the IANA considerations section > without that draft being an approved procedure. > > So it's not only a needed reference, it's a normative one, by my reading. > > Tony, are you ready to send this to the IESG? > Chris, are you ready to process it? > > Harald > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 08 09:24:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFMz-00062R-Cs; Tue, 08 Jan 2008 09:23:57 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JCFMy-0005vd-44 for ima-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 09:23:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFMx-0005sa-Ov for ima@ietf.org; Tue, 08 Jan 2008 09:23:55 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCFMw-0004pl-NA for ima@ietf.org; Tue, 08 Jan 2008 09:23:55 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3^clerew^man&ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.275) id 47838776.44ba.36 for ima@ietf.org; Tue, 8 Jan 2008 14:23:50 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id m08ENnx8015464 for ; Tue, 8 Jan 2008 14:23:51 GMT Date: Tue, 08 Jan 2008 14:23:49 -0000 From: "Charles Lindsey" To: IMA Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt References: Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 07 Jan 2008 07:50:02 -0000, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Email Address Internationalization > Working Group of the IETF. > > > Title : SMTP extension for internationalized email address > Author(s) : J. Yao, W. MAO > Filename : draft-ietf-eai-smtpext-10.txt > Pages : 22 > Date : 2008-01-07 I am confused. This draft states: If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP client MUST NOT transmit an internationalized address and MUST NOT transmit a mail message which contains containing internationalized mail headers as described in [EAI-utf8header] at any level within its MIME structure. Instead, if an SMTP client (SMTP sender) attempts to transfer a UTF8SMTP internationalized message and encounters a server that does not support the extension, it MUST make one of the following four choices: This seems to state, quite clearly, that a non-UTF8SMTP server, even if it supports 8BITMIME, MUST NOT transmit a message containing a message/global. IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in RFC 2045. If this is what it means then, of course, I Approve. But in that case it is inconsistent with utf8headers, which explicitly allows them and permits them to be encoded in Base64 or Q-P. And it is inconsistent with our DSN draft for the same reason. A couple of further niggles. It still uses the ABNF rule . I thought we had agreed to change this to (this change is also not yet in the utf8headers draft). And I also find the words: If a normal success response (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms: User Name ; uMailbox is defined in section 2.3 of this document ; User Name allows the can contain non-ASCII character. characters. uMailbox ; uMailbox is defined in section 2.3 of this document It uses the word "either", but I don't see two things between which I am supposed to choose. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 08 20:45:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCQ0X-0003Tz-E2; Tue, 08 Jan 2008 20:45:29 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JCQ0U-0003Tt-SR for ima-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 20:45:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCQ0U-0003Tl-HB for ima@ietf.org; Tue, 08 Jan 2008 20:45:26 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCQ0S-0004QS-OR for ima@ietf.org; Tue, 08 Jan 2008 20:45:26 -0500 Received: (eyou send program); Wed, 09 Jan 2008 09:45:18 +0800 Message-ID: <399843118.17122@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Wed, 09 Jan 2008 09:45:18 +0800 Message-ID: <00d301c85261$4a476f40$236ff1da@yaojk> From: "YAO Jiankang" To: "Charles Lindsey" , "IMA" References: <399802708.11296@cnnic.cn> Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt Date: Wed, 9 Jan 2008 09:45:18 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.3 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1834107383==" Errors-To: ima-bounces@ietf.org --===============1834107383== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86ICJJTUEiIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDA4LCAyMDA4IDEwOjIzIFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gSS1E IEFjdGlvbjpkcmFmdC1pZXRmLWVhaS1zbXRwZXh0LTEwLnR4dCANCg0KDQo+IE9uIE1vbiwgMDcg SmFuIDIwMDggMDc6NTA6MDIgLTAwMDAsIDxJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc+IHdyb3Rl Og0KPiANCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyAgDQo+PiBkaXJlY3Rvcmllcy4NCj4+IFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIEVtYWlsIEFkZHJlc3MgSW50ZXJuYXRpb25hbGl6YXRpb24gIA0K Pj4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+DQo+Pg0KPj4gVGl0bGUgICAgICAgICAg IDogU01UUCBleHRlbnNpb24gZm9yIGludGVybmF0aW9uYWxpemVkIGVtYWlsIGFkZHJlc3MNCj4+ IEF1dGhvcihzKSAgICAgICA6IEouIFlhbywgVy4gTUFPDQo+PiBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWVhaS1zbXRwZXh0LTEwLnR4dA0KPj4gUGFnZXMgICAgICAgICAgIDogMjINCj4+ IERhdGUgICAgICAgICAgICA6IDIwMDgtMDEtMDcNCj4gDQo+IEkgYW0gY29uZnVzZWQuDQo+IA0K PiBUaGlzIGRyYWZ0IHN0YXRlczoNCj4gDQo+ICAgIElmIHRoZSBVVEY4U01UUCBTTVRQIGV4dGVu c2lvbiBpcyBub3Qgb2ZmZXJlZCBieSB0aGUgU2VydmVyLCB0aGUgU01UUA0KPiAgICBjbGllbnQg TVVTVCBOT1QgdHJhbnNtaXQgYW4gaW50ZXJuYXRpb25hbGl6ZWQgYWRkcmVzcyBhbmQgTVVTVCBO T1QNCj4gICAgdHJhbnNtaXQgYSBtYWlsIG1lc3NhZ2Ugd2hpY2ggY29udGFpbnMgY29udGFpbmlu ZyBpbnRlcm5hdGlvbmFsaXplZCAgDQo+IG1haWwgaGVhZGVycyBhcw0KPiAgICBkZXNjcmliZWQg aW4gW0VBSS11dGY4aGVhZGVyXSBhdCBhbnkgbGV2ZWwgd2l0aGluIGl0cyBNSU1FIHN0cnVjdHVy ZS4NCj4gICAgSW5zdGVhZCwgaWYgYW4gU01UUCBjbGllbnQgKFNNVFAgc2VuZGVyKSBhdHRlbXB0 cyB0byB0cmFuc2ZlciBhIFVURjhTTVRQDQo+ICAgIGludGVybmF0aW9uYWxpemVkIG1lc3NhZ2Ug YW5kIGVuY291bnRlcnMgYSBzZXJ2ZXIgdGhhdCBkb2VzIG5vdA0KPiAgICBzdXBwb3J0IHRoZSBl eHRlbnNpb24sIGl0IE1VU1QgbWFrZSBvbmUgb2YgdGhlIGZvbGxvd2luZyBmb3VyDQo+ICAgIGNo b2ljZXM6DQo+IA0KPiBUaGlzIHNlZW1zIHRvIHN0YXRlLCBxdWl0ZSBjbGVhcmx5LCB0aGF0IGEg bm9uLVVURjhTTVRQIHNlcnZlciwgZXZlbiBpZiBpdCAgDQo+IHN1cHBvcnRzIDhCSVRNSU1FLCBN VVNUIE5PVCB0cmFuc21pdCBhIG1lc3NhZ2UgY29udGFpbmluZyBhICANCj4gbWVzc2FnZS9nbG9i YWwuDQo+IElPVyBpdCBNVVNUIE5PVCB2aW9sYXRlIHRoYXQgRVhQUkVTU0xZIEZPUkJJRERFTiBp biBSRkMgIA0KPiAyMDQ1Lg0KPiANCj4gSWYgdGhpcyBpcyB3aGF0IGl0IG1lYW5zIHRoZW4sIG9m IGNvdXJzZSwgSSBBcHByb3ZlLiBCdXQgaW4gdGhhdCBjYXNlIGl0ICANCj4gaXMgaW5jb25zaXN0 ZW50IHdpdGggdXRmOGhlYWRlcnMsDQoNCmFjY29yZGluZyB0byB0aGUgZGVmaW5pdGlvbiBvZiBz ZWN0aW9uIDQuNiBvZiB1dGY4aGVhZGVyIGRvY3VtZW50LCANCkEgbWVzc2FnZSBpcyBhICJtZXNz YWdlL2dsb2JhbCBtZXNzYWdlIiwgaWYNCiAgIG8gIGl0IGNvbnRhaW5zIFVURi04IGhlYWRlciB2 YWx1ZXMgYXMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIG9yDQogICBvICBpdCBjb250YWlu cyBVVEYtOCB2YWx1ZXMgaW4gdGhlIGhlYWRlcnMgZmllbGRzIG9mIGJvZHkgcGFydHMuDQoNCnNl Y3Rpb24gNC42IGFsc28gc2FpZCB0aGF0ICIgIEludGVybmF0aW9uYWxpemVkIG1lc3NhZ2VzIG11 c3Qgb25seSBiZSB0cmFuc21pdHRlZCBhcyBhdXRob3JpemVkIGJ5DQogICBbRUFJLVNNVFAtZXh0 ZW5zaW9uXSBvciB3aXRoaW4gYSBub24tU01UUCBlbnZpcm9ubWVudCB3aGljaCBzdXBwb3J0cw0K ICAgdGhlc2UgbWVzc2FnZXMuICIgU28gaXQgbWVhbnMgdGhhdCBpZiB1ZjhoZWFkZXIgZG9jdW1l bnQgYWxsb3dzIG1lc3NhZ2UvZ2xvYmFsLCBpdCB3aWxsIGZvbGxvdyB0aGUgc3BlY2lmaWNhdGlv biBpbiBFQUkgc210cHhldCBkb2N1bWVudC4NCg0KSU1PLCBpdCBpcyBzdGlsbCBjb25zaXN0ZW50 IHdpdGggdXRmOGhlYWRlciBkb2N1bWVudC4NCg0KIA0KDQo+d2hpY2ggZXhwbGljaXRseSBhbGxv d3MgdGhlbSBhbmQgcGVybWl0cyAgDQo+IHRoZW0gdG8gYmUgZW5jb2RlZCBpbiBCYXNlNjQgb3Ig US1QLiANCg0KSSBkbyBub3QgdGhpbmsgdGhhdCB1dGY4aGVhZGVyIGRvY3VtZW50IGNsZWFybHkg cGVybWl0IHRoZSBtZXNzYWdlL2dsb2JhbCB0byBiZSBlbmNvZGVkIGluIEJhc2U2NCBvciBRLVAu DQp1dGY4aGVhZGVyIGRvY3VtZW50ICB0cnkgdG8gYXV0aG9yaXplIHRoZSB1dGY4IGhlYWRlciBp bnN0ZWFkIG9mIGJhc2U2NCBvciBRLVAuDQoNCg0KPkFuZCBpdCBpcyBpbmNvbnNpc3RlbnQgd2l0 aCBvdXIgRFNOICANCj4gZHJhZnQgZm9yIHRoZSBzYW1lIHJlYXNvbi4NCg0KSSBhbSBub3Qgc3Vy ZS4NCg0KQWxleGV5IE1lbG5pa292IG9yIENocmlzIG1heSBoYXZlIG1vcmUgY29tbWVudHMgb24g aXQuDQoNCg0KDQo+IA0KPiBBIGNvdXBsZSBvZiBmdXJ0aGVyIG5pZ2dsZXMuDQo+IA0KPiBJdCBz dGlsbCB1c2VzIHRoZSBBQk5GIHJ1bGUgPFVURjgteHRyYS1jaGFyPi4gSSB0aG91Z2h0IHdlIGhh ZCBhZ3JlZWQgdG8gIA0KPiBjaGFuZ2UgdGhpcyB0byA8VVRGOC1ub24tYXNjaWk+ICh0aGlzIGNo YW5nZSBpcyBhbHNvIG5vdCB5ZXQgaW4gdGhlICANCj4gdXRmOGhlYWRlcnMgZHJhZnQpLg0KDQoN CmlmIG5vYm9keSBvYmplY3QgaXQsIEkgd2lsbCB1c2UgVVRGOC1ub24tYXNjaWkgaW4gbmV4dCB2 ZXJzaW9uLiAoVGhhbmtzIDopKQ0KDQo+IA0KPiBBbmQgSSBhbHNvIGZpbmQgdGhlIHdvcmRzOg0K PiANCj4gICAgSWYgYSBub3JtYWwgc3VjY2VzcyByZXNwb25zZSAoaS5lLiwgMjUwKSByZXNwb25z ZSBpcyByZXR1cm5lZCwgdGhlICANCj4gcmVzcG9uc2UNCj4gICAgTUFZIGluY2x1ZGUgdGhlIGZ1 bGwgbmFtZSBvZiB0aGUgdXNlciBhbmQgTVVTVCBpbmNsdWRlIHRoZSBtYWlsYm94IG9mDQo+ICAg IHRoZSB1c2VyLiAgSXQgTVVTVCBiZSBpbiBlaXRoZXIgb2YgdGhlIGZvbGxvd2luZyBmb3JtczoN Cj4gDQo+ICAgICAgICAgIFVzZXIgTmFtZSA8dU1haWxib3g+DQo+ICAgICAgICAgICAgIDsgdU1h aWxib3ggaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDIuMyBvZiB0aGlzIGRvY3VtZW50DQo+ICAgICAg ICAgICAgIDsgVXNlciBOYW1lIGFsbG93cyB0aGUgY2FuIGNvbnRhaW4gbm9uLUFTQ0lJIGNoYXJh Y3Rlci4gIA0KPiBjaGFyYWN0ZXJzLg0KPiANCj4gICAgICAgICAgdU1haWxib3gNCj4gICAgICAg ICAgICAgOyB1TWFpbGJveCBpcyBkZWZpbmVkIGluIHNlY3Rpb24gMi4zIG9mIHRoaXMgZG9jdW1l bnQNCj4gDQo+IEl0IHVzZXMgdGhlIHdvcmQgImVpdGhlciIsIGJ1dCBJIGRvbid0IHNlZSB0d28g dGhpbmdzIGJldHdlZW4gd2hpY2ggSSBhbSAgDQo+IHN1cHBvc2VkIHRvIGNob29zZS4NCg0Kb3B0 aW9uIDE6IHlvdSBjaG9vc2U6ICBVc2VyIE5hbWUgPHVNYWlsYm94Pg0KDQpvcHRpb24gMjogeW91 IGNob29zZSA6ICB1TWFpbGJveA0KDQppcyBteSB1bmRlcnN0YW5kaW5nIHJpZ2h0Pw0KDQoNClRo YW5rcyBhIGxvdCBhbmQgSGFwcCBuZXcgeWVhcg0KWUFPIEppYW5rYW5nDQpDTk5JQw0KDQo+IA0K PiAtLSANCj4gQ2hhcmxlcyBILiBMaW5kc2V5IC0tLS0tLS0tLUF0IEhvbWUsIGRvaW5nIG15IG93 biB0aGluZy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUZWw6ICs0NCAxNjEgNDM2IDYxMzEg ICAgICAgICAgICAgICAgICAgICAgIA0KPiBXZWI6IGh0dHA6Ly93d3cuY3MubWFuLmFjLnVrL35j aGwNCj4gRW1haWw6IGNobEBjbGVyZXcubWFuLmFjLnVrIFNuYWlsOiA1IENsZXJld29vZCBBdmUs IENIRUFETEUsIFNLOCAzSlUsIFUuSy4NCj4gUEdQOiAyQzE1RjFBOSBGaW5nZXJwcmludDogNzMg NkQgQzIgNTEgOTMgQTAgMDEgRTcgNjUgRTggNjQgN0UgMTQgQTQgQUIgQTUNCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFp bGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pbWENCj4= --===============1834107383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1834107383==-- From ima-bounces@ietf.org Wed Jan 09 06:05:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCYkI-0003qv-9K; Wed, 09 Jan 2008 06:05:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JCYkG-0003qP-ND for ima-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 06:05:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCYkG-0003ot-D0 for ima@ietf.org; Wed, 09 Jan 2008 06:05:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCYkE-0004OA-Gs for ima@ietf.org; Wed, 09 Jan 2008 06:05:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JCYk8-0005Nz-HU for ima@ietf.org; Wed, 09 Jan 2008 11:05:08 +0000 Received: from c-134-88-143.hh.dial.de.ignite.net ([62.134.88.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jan 2008 11:05:08 +0000 Received: from nobody by c-134-88-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jan 2008 11:05:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Wed, 9 Jan 2008 12:05:15 +0100 Organization: Lines: 53 Message-ID: References: <399802708.11296@cnnic.cn> <399843118.17122@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-143.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [EAI] Re: I-D Action:draft-ietf-eai-smtpext-10.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org YAO Jiankang wrote: >>| client MUST NOT transmit an internationalized address and MUST NOT >>| transmit a mail message which contains containing internationalized = >>| mail headers as described in [EAI-utf8header] at any level within >>| its MIME structure. >> This seems to state, quite clearly, that a non-UTF8SMTP server, even >> if it supports 8BITMIME, MUST NOT transmit a message containing a =20 >> message/global. But that would be very wrong. It's nobody's business what MIME parts an ordinary 8bit message/rfc822 contains as long as they are 8BITMIME compatible. One or more of these parts can be message/global objects with UTF-8 in their header. Only 8bit to 7bit gateways need to worry about non-ASCII octets. UTF8SMTP to 8BITMIME gateways can ignore it. > according to the definition of section 4.6 of utf8header document,=20 > A message is a "message/global message", if > o it contains UTF-8 header values as specified in this document, = or > o it contains UTF-8 values in the headers fields of body parts. The second clause is dubious. UTF-8 characters are not allowed in a MIME part header for MIME version 1.0. An "experimental MIME update" allowing it, if this survives the IETF Last Call, but I hope it won't, would force poor UTF8SMTP to 8BITMIME gateways to look into MIME part headers, where they'll find many variations of what's best described as garbage. At that point they are forced to reject the dubious mail, and this could kill the whole EAI effort only because "we" (=3D not me) tried to "improve" MIME part headers. > IMO, it is still consistent with utf8header document. Please make it also consistent with MIME. You don't want "any level within its MIME structure". The internal structure of a message/??? embedded in the top level message is opaque, no matter if a gateway happens to know a few ??? subtypes like rfc822, global, news, etc., or not. For embedded messages the point is to catch non-ASCII octets not allowed for 7bit in the case of an 8bit to 7bit gateway. IMO an UTF8SMTP to 8BITMIME gateway isn't the same as 8bit to 7bit. If the top level message is no message/global it must be a message/rfc822, embedded message objects of any subtype can't change this decision. > I do not think that utf8header document clearly permit the=20 > message/global to be encoded in Base64 or Q-P. Yes, I think that is limited to emergencies when trying to send a DSN to a message/global sender, who somehow managed to have still some 7bit-only reverse routes. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 09 07:02:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCZdu-0004dp-E9; Wed, 09 Jan 2008 07:02:46 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JCZdt-0004dB-0D for ima-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 07:02:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCZds-0004Z0-IP for ima@ietf.org; Wed, 09 Jan 2008 07:02:44 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCZdr-0007dz-Fl for ima@ietf.org; Wed, 09 Jan 2008 07:02:44 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew*man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.275) id 4784b7df.157bc.464 for ima@ietf.org; Wed, 9 Jan 2008 12:02:39 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id m09C2cZp019789 for ; Wed, 9 Jan 2008 12:02:39 GMT To: IMA Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt References: <399802708.11296@cnnic.cn> <00d301c85261$4a476f40$236ff1da@yaojk> Message-ID: Date: Wed, 09 Jan 2008 12:02:38 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <00d301c85261$4a476f40$236ff1da@yaojk> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 09 Jan 2008 01:45:18 -0000, YAO Jiankang wrote: > > ----- Original Message ----- > From: "Charles Lindsey" > To: "IMA" > according to the definition of section 4.6 of utf8header document, > A message is a "message/global message", if > o it contains UTF-8 header values as specified in this document, or > o it contains UTF-8 values in the headers fields of body parts. Yes, it is the first of those cases we should focus upon. It seems that smtpext will not allow you to transmit a message containing an attachment of that form to a non-UTF8SMTP system. > > section 4.6 also said that " Internationalized messages must only be > transmitted as authorized by > [EAI-SMTP-extension] or within a non-SMTP environment which supports > these messages. " So it means that if uf8header document allows > message/global, it will follow the specification in EAI smtpxet document. > > IMO, it is still consistent with utf8header document. But confusing, since it implies you may send such messages if [EAI-SMTP-extension] allows it, in the full knowledge that [EAI-SMTP-extension] does not. > > >> which explicitly allows them and permits >> them to be encoded in Base64 or Q-P. > > I do not think that utf8header document clearly permit the > message/global to be encoded in Base64 or Q-P. > utf8header document try to authorize the utf8 header instead of base64 > or Q-P. utf8headers says: The type message/global is similar to message/rfc822, except that it contains a message that can contain UTF-8 characters in the headers of the message or body parts. If this type is sent to a 7-bit-only system, it has to be encoded in [RFC2045]. ... That surely means encoding in Base64 or Q-P? (Note that a system compliant with MIME that doesn't recognize message/global would treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].) And of course my position has always been that that sentence is a misreading of 5.2.4 of [RFC2046], and that in any case a large number of current MTAs will not treat it that way. >> And it is inconsistent with our DSN >> draft for the same reason. > > I am not sure. > > Alexey Melnikov or Chris may have more comments on it. Indeed. >> It uses the word "either", but I don't see two things between which I am >> supposed to choose. > > option 1: you choose: User Name > > option 2: you choose : uMailbox OK, I see it now. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 10 12:44:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD1Ry-0000Yr-Au; Thu, 10 Jan 2008 12:44:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JD1Rx-0000Yi-CK for ima-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 12:44:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD1Rx-0000Y0-1J for ima@ietf.org; Thu, 10 Jan 2008 12:44:17 -0500 Received: from mail203.messagelabs.com ([216.82.254.243]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD1Rw-0000h9-5f for ima@ietf.org; Thu, 10 Jan 2008 12:44:16 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-7.tower-203.messagelabs.com!1199987054!234156!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 27518 invoked from network); 10 Jan 2008 17:44:14 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-7.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 10 Jan 2008 17:44:14 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0AHiEaZ002169 for ; Thu, 10 Jan 2008 09:44:14 -0800 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0AHiBnw002127 for ; Thu, 10 Jan 2008 09:44:11 -0800 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m0AHiBBZ004675 for ; Thu, 10 Jan 2008 11:44:11 -0600 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m0AHi7Af004622 for ; Thu, 10 Jan 2008 11:44:07 -0600 Received: from [135.25.188.13] (unknown[135.25.188.13](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20080110174406gw10010gmje> (Authid: tony); Thu, 10 Jan 2008 17:44:06 +0000 Message-ID: <47865938.80406@att.com> Date: Thu, 10 Jan 2008 12:43:20 -0500 From: Tony Hansen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ietf-smtp@imc.org References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: EAI WG , John Klensin Subject: [EAI] Re: I-D Action:draft-hansen-4468upd-mailesc-registry-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Registry for SMTP Enhanced Mail System > Status Codes > Author(s) : T. Hansen, J. Klensin > Filename : draft-hansen-4468upd-mailesc-registry-03.txt > Date : 2008-01-10 Ok, so A Registry for SMTP Enhanced Mail System Status Codes, draft-hansen-4468upd-mailesc-registry, has been updated. This one represents a proper merger with draft-klensin-smtp-code-registry, and (I think) addresses almost all of the comments that have come out since -02. As requested, it has added a typical Associated Basic Status Code entry to the registration. It also has a table showing the typical Associated Basic Status Code for many of the existing codes, seeded with those found in RFCs 4468 and 4954. There are many holes in this table, though, that need to be filled in. Please feel free to contribute to this table. This version does not define X.8.Z. I was not convinced there was enough of a consensus to add it. Discussion should occur on ietf-smtp@imc.org. Tony Hansen tony@att.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 17 15:24:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbH9-0003PL-PA; Thu, 17 Jan 2008 15:23:47 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JFbH8-0003PG-QY for ima-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 15:23:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbH8-0003P8-FG for ima@ietf.org; Thu, 17 Jan 2008 15:23:46 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFbH7-0004Mp-Rr for ima@ietf.org; Thu, 17 Jan 2008 15:23:46 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A80A32596CB; Thu, 17 Jan 2008 21:23:44 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17551-07; Thu, 17 Jan 2008 21:23:39 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 334D22596C7; Thu, 17 Jan 2008 21:23:39 +0100 (CET) Message-ID: <478FB945.9080906@alvestrand.no> Date: Thu, 17 Jan 2008 21:23:33 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey skrev: > On Mon, 07 Jan 2008 07:50:02 -0000, wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Email Address Internationalization >> Working Group of the IETF. >> >> >> Title : SMTP extension for internationalized email address >> Author(s) : J. Yao, W. MAO >> Filename : draft-ietf-eai-smtpext-10.txt >> Pages : 22 >> Date : 2008-01-07 > > I am confused. > > This draft states: > > If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP > client MUST NOT transmit an internationalized address and MUST NOT > transmit a mail message which contains containing internationalized > mail headers as > described in [EAI-utf8header] at any level within its MIME structure. > Instead, if an SMTP client (SMTP sender) attempts to transfer a > UTF8SMTP > internationalized message and encounters a server that does not > support the extension, it MUST make one of the following four > choices: > > This seems to state, quite clearly, that a non-UTF8SMTP server, even > if it supports 8BITMIME, MUST NOT transmit a message containing a > message/global. IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in > RFC 2045. > > If this is what it means then, of course, I Approve. But in that case > it is inconsistent with utf8headers, which explicitly allows them and > permits them to be encoded in Base64 or Q-P. And it is inconsistent > with our DSN draft for the same reason. It was intended to say that the structure Content-type: multipart/mixed Content-type: text/plain Content-description: is illegal to send, but that the structure Content-type: multipart/mixed Content-type: message/global Content-transfer-encoding: base64 (base64-encoding of) Subject: (end base64-encoding) is completely legal to send. One way to describe it is that the stuff that's inside a content-transfer-encoding, or where a content-transfer-encoding can be applied, has ceased being part of the message's MIME structure; the MIME processor no longer cares about its headers, only about whether or not the part conforms to the 7-bit, 8-bit or binary formats. I'm not sure what words to use to make this distinction obvious. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 17 22:29:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFhun-0003ZQ-Bj; Thu, 17 Jan 2008 22:29:09 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JFhul-0003ZK-Aa for ima-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 22:29:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFhul-0003ZC-0M for ima@ietf.org; Thu, 17 Jan 2008 22:29:07 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFhuk-0005QH-M1 for ima@ietf.org; Thu, 17 Jan 2008 22:29:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JFhuc-0004P4-TS for ima@ietf.org; Fri, 18 Jan 2008 03:28:59 +0000 Received: from c-134-88-10.hh.dial.de.ignite.net ([62.134.88.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2008 03:28:58 +0000 Received: from nobody by c-134-88-10.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2008 03:28:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Fri, 18 Jan 2008 04:29:21 +0100 Organization: Lines: 10 Message-ID: References: <478FB945.9080906@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-10.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] EXPRESSLY FORBIDDEN (was: I-D Action:draft-ietf-eai-smtpext-10.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > I'm not sure what words to use to make this distinction obvious. Should I try the "2045 erratum" approach ? The "new" (proposed) rules for errata apparently require AD verification for IETF RFCs. See http://article.gmane.org/gmane.ietf.ima/2150 (we're at 2370) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 18 12:04:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFue9-0002hW-7h; Fri, 18 Jan 2008 12:04:49 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JFue6-0002hA-Uv for ima-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:04:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFue6-0002h2-Ke for ima@ietf.org; Fri, 18 Jan 2008 12:04:46 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFue6-0001MI-Az for ima@ietf.org; Fri, 18 Jan 2008 12:04:46 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 09:04:45 -0800 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.41]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Fri, 18 Jan 2008 09:04:45 -0800 From: Shawn Steele To: "ima@ietf.org" Date: Fri, 18 Jan 2008 09:04:44 -0800 Thread-Topic: UTF8 MUST NOT transmit... Thread-Index: AchZ85zgro8oYzo/QZWgS5UDZ1PuvAAADvyw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] UTF8 MUST NOT transmit... X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP > client MUST NOT transmit an internationalized address... So I assume a Punycode encoded domain name isn't considered "internationali= zed" for this context? I'm concerned a tiny bit about "MUST NOT". Although its not reliable, it s= eems to me that some mail systems permit non-ASCII labels and are successfu= l, at least within their domain, and often in a broader context. - shawn _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 18 13:37:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFw5M-0007bb-Fw; Fri, 18 Jan 2008 13:37:00 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JFw5K-0007Sb-FV for ima-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 13:36:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFw5K-0007OM-01 for ima@ietf.org; Fri, 18 Jan 2008 13:36:58 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFw5J-0006mR-A1 for ima@ietf.org; Fri, 18 Jan 2008 13:36:57 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JFw5H-0008Tr-ET; Fri, 18 Jan 2008 13:36:55 -0500 Date: Fri, 18 Jan 2008 13:36:54 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Subject: Re: [EAI] UTF8 MUST NOT transmit... Message-ID: <3BA66DF86EA0146BA4379FB0@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 18 January, 2008 09:04 -0800 Shawn Steele wrote: >> If the UTF8SMTP SMTP extension is not offered by the >> Server, the SMTP client MUST NOT transmit an >> internationalized address... > > So I assume a Punycode encoded domain name isn't considered > "internationalized" for this context? That is correct. A punycoded domain name is an ASCII LDH name except to systems that specifically recognize IDNA. > I'm concerned a tiny bit about "MUST NOT". Although its not > reliable, it seems to me that some mail systems permit > non-ASCII labels and are successful, at least within their > domain, and often in a broader context. This turns out to be the old "just send 8" debate in another form. MUST NOT is appropriate because, if such addresses are used without the extension, interoperability cannot be guaranteed or even predicted. Some systems will reject the addresses, others will trash them (e.g., by dropping the high-order bits), others may do other things, including having them work. But note that, if the addresses are transmitted without the extension, a whole series of things need to happen in a consistent way to avoid breaking things downstream. Just for example, one needs Return-path to be mapped correctly into the headers, and then to be interpreted correctly, to prevent bad things from happening down the line. That is true even if the only non-ASCII component of the address is the domain name. Few of the systems that simply transmit and accept non-ASCII addresses have thought through and worked out all of those details in a comprehensive way. If it were completely obvious, the details associated with this extension would probably be unnecessary and a "SHOULD" might be in order. Of course, almost anything can be done by private, out of band, agreements, but such activities lie outside the standard. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 18 13:41:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFw9K-0004Di-D8; Fri, 18 Jan 2008 13:41:06 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JFw9I-0004DM-Na for ima-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 13:41:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFw9I-0004DE-Do for ima@ietf.org; Fri, 18 Jan 2008 13:41:04 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFw9G-0001En-8J for ima@ietf.org; Fri, 18 Jan 2008 13:41:04 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 10:41:01 -0800 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.41]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Fri, 18 Jan 2008 10:41:01 -0800 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Date: Fri, 18 Jan 2008 10:41:00 -0800 Subject: RE: [EAI] UTF8 MUST NOT transmit... Thread-Topic: [EAI] UTF8 MUST NOT transmit... Thread-Index: AchaASp/tDZKkseHQnGKFaa53y6sBgAADxew Message-ID: References: <3BA66DF86EA0146BA4379FB0@p3.JCK.COM> In-Reply-To: <3BA66DF86EA0146BA4379FB0@p3.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > > So I assume a Punycode encoded domain name isn't considered > > "internationalized" for this context? > That is correct. A punycoded domain name is an ASCII LDH name > except to systems that specifically recognize IDNA. Its probably worth pointing out that punycode names are permitted. I reali= ze that punycode names are technically ASCII, however IDN aware readers may= equate them with "internationalized", so it'd be good to clarify this poin= t. > I'm concerned a tiny bit about "MUST NOT" Thanks for the clarification :) - Shawn _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 18 14:09:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwaT-0003S3-TY; Fri, 18 Jan 2008 14:09:09 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JFwaS-0003Ls-Af for ima-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwaR-0003Ep-Nf for ima@ietf.org; Fri, 18 Jan 2008 14:09:07 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwaO-0001tU-BT for ima@ietf.org; Fri, 18 Jan 2008 14:09:07 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JFwaN-0009uO-W9; Fri, 18 Jan 2008 14:09:04 -0500 Date: Fri, 18 Jan 2008 14:09:03 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Subject: RE: [EAI] UTF8 MUST NOT transmit... Message-ID: <9A9261165205B2B1EE77731C@p3.JCK.COM> In-Reply-To: References: <3BA66DF86EA0146BA4379FB0@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 18 January, 2008 10:41 -0800 Shawn Steele wrote: >> > So I assume a Punycode encoded domain name isn't considered >> > "internationalized" for this context? > >> That is correct. A punycoded domain name is an ASCII LDH >> name except to systems that specifically recognize IDNA. > > Its probably worth pointing out that punycode names are > permitted. I realize that punycode names are technically > ASCII, however IDN aware readers may equate them with > "internationalized", so it'd be good to clarify this point. yes, you are probably correct. I can easily fix that in "framework", but the WG is still undecided whether to try to reissue "framework" (i.e., update RFC4952) in this round or to hold it for a standards-track round of processing. Perhaps a simple note could be added to the statement in "smtpext". >> I'm concerned a tiny bit about "MUST NOT" > > Thanks for the clarification :) :-) john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 19 10:13:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGFO0-0004je-Ha; Sat, 19 Jan 2008 10:13:32 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JGFNy-0004X5-Mz for ima-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 10:13:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGFNy-0004SR-9Q for ima@ietf.org; Sat, 19 Jan 2008 10:13:30 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGFNx-00053j-A1 for ima@ietf.org; Sat, 19 Jan 2008 10:13:29 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew#man#ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.276) id 47921397.12826.20b for ima@ietf.org; Sat, 19 Jan 2008 15:13:27 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id m0JFDQQV006799 for ; Sat, 19 Jan 2008 15:13:27 GMT Date: Sat, 19 Jan 2008 15:13:26 -0000 To: IMA Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Message-ID: User-Agent: Opera Mail/9.25 (SunOS) MIME-Version: 1.0 References: <478FB945.9080906@alvestrand.no> In-Reply-To: <478FB945.9080906@alvestrand.no> Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 17 Jan 2008 20:23:33 -0000, Harald Alvestrand wrote: > Charles Lindsey skrev: >> This draft states: >> >> If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP >> client MUST NOT transmit an internationalized address and MUST NOT >> transmit a mail message which contains containing internationalized >> mail headers as >> described in [EAI-utf8header] at any level within its MIME structure. >> Instead, if an SMTP client (SMTP sender) attempts to transfer a >> UTF8SMTP >> internationalized message and encounters a server that does not >> support the extension, it MUST make one of the following four >> choices: >> >> This seems to state, quite clearly, that a non-UTF8SMTP server, even >> if it supports 8BITMIME, MUST NOT transmit a message containing a >> message/global. IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in >> RFC 2045. > It was intended to say that the structure > > Content-type: multipart/mixed > > Content-type: text/plain > Content-description: > > is illegal to send, but that the structure But it does not say that, since it is only prohibiting "internationalized mail headers" in certain contexts (though I am sure there is text elsewhere in the drafts to prohibit your example). > > Content-type: multipart/mixed > > Content-type: message/global > Content-transfer-encoding: base64 > > (base64-encoding of) > Subject: > (end base64-encoding) > > is completely legal to send. Yes, it permits that, but it PROHIBITS Content-type: multipart/mixed Content-type: message/global Content-transfer-encoding: 8bit Subject: to be sent to a server that does not support UTF8SMTP (but presumably does support 8BITMIME). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 21 04:11:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGsgS-0005tu-1A; Mon, 21 Jan 2008 04:11:12 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JGsgQ-0005tf-3S for ima-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 04:11:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGsgP-0005tQ-Ih for ima@ietf.org; Mon, 21 Jan 2008 04:11:09 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGsgO-0007Pm-Uy for ima@ietf.org; Mon, 21 Jan 2008 04:11:09 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EDD2D2596CB; Mon, 21 Jan 2008 10:11:07 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13675-06; Mon, 21 Jan 2008 10:11:02 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD8022596C9; Mon, 21 Jan 2008 10:11:02 +0100 (CET) Message-ID: <479461A6.1070602@alvestrand.no> Date: Mon, 21 Jan 2008 10:11:02 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] I-D Action:draft-ietf-eai-smtpext-10.txt References: <478FB945.9080906@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Thu, 17 Jan 2008 20:23:33 -0000, Harald Alvestrand > wrote: > >> Charles Lindsey skrev: > >>> This draft states: >>> >>> If the UTF8SMTP SMTP extension is not offered by the Server, the >>> SMTP >>> client MUST NOT transmit an internationalized address and MUST NOT >>> transmit a mail message which contains containing internationalized >>> mail headers as >>> described in [EAI-utf8header] at any level within its MIME >>> structure. >>> Instead, if an SMTP client (SMTP sender) attempts to transfer a >>> UTF8SMTP >>> internationalized message and encounters a server that does not >>> support the extension, it MUST make one of the following four >>> choices: >>> >>> This seems to state, quite clearly, that a non-UTF8SMTP server, even >>> if it supports 8BITMIME, MUST NOT transmit a message containing a >>> message/global. IOW it MUST NOT violate that EXPRESSLY FORBIDDEN in >>> RFC 2045. > >> It was intended to say that the structure >> >> Content-type: multipart/mixed >> >> Content-type: text/plain >> Content-description: >> >> is illegal to send, but that the structure > > But it does not say that, since it is only prohibiting > "internationalized mail headers" in certain contexts (though I am sure > there is text elsewhere in the drafts to prohibit your example). in what way is "content-description: " not an internationalized mail header? >> >> Content-type: multipart/mixed >> >> Content-type: message/global >> Content-transfer-encoding: base64 >> >> (base64-encoding of) >> Subject: >> (end base64-encoding) >> >> is completely legal to send. > > Yes, it permits that, but it PROHIBITS > > Content-type: multipart/mixed > > Content-type: message/global > Content-transfer-encoding: 8bit > > Subject: > > to be sent to a server that does not support UTF8SMTP (but presumably > does support 8BITMIME). I believe that if the text can be interpreted that way, it is a problem with the text. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 21 05:35:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGu0E-0008E4-83; Mon, 21 Jan 2008 05:35:42 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JGu0D-0008Dz-Ez for ima-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 05:35:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGu0D-0008Dr-2n for ima@ietf.org; Mon, 21 Jan 2008 05:35:41 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGu0B-00016A-NC for ima@ietf.org; Mon, 21 Jan 2008 05:35:40 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E11AE2596CD; Mon, 21 Jan 2008 11:35:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16151-10; Mon, 21 Jan 2008 11:35:33 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB5512596C9; Mon, 21 Jan 2008 11:35:32 +0100 (CET) Message-ID: <47947574.5030406@alvestrand.no> Date: Mon, 21 Jan 2008 11:35:32 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: ietf-types@alvestrand.no Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: EAI WG Subject: [EAI] Request for review of EAI MIME types X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is the formal request for review for the following media types that have been defined in the Email Address Internationalization WG, and published in the drafts draft-ietf-eai-utf8headers-08 draft-ietf-eai-dsn-05 The extracted templates are given below. For full context, read the drafts. If possible, keep the EAI WG copied on any substantive comments. Harald Alvestrand, EAI WG chair === message/global, from draft-ietf-eai-utf8headers-08 ===== Type name: message Subtype name: global Required parameters: none Optional parameters: none Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted. Security considerations: See Section 6 Interoperability considerations: The media type provides functionality similar to the message/rfc822 content type for email messages with international email headers. When there is a need to embed or return such content in another message, there is generally an option to use this media type and leave the content unchanged or downconvert the content to message/rfc822. Both of these choices will interoperate with the installed base, but with different properties. Systems unaware of international headers will typically treat a message/global body part as an unknown attachment, while they will understand the structure of a message/ rfc822. However, systems which understand message/global will provide functionality superior to the result of a down-conversion to message/rfc822. The most interoperable choice depends on the deployed software. Published specification: RFC XXXX Applications that use this media type: SMTP servers and email clients that support multipart/report generation or parsing. Email clients which forward messages with international headers as attachments. Additional information: Magic number(s): none File extension(s): The extension ".u8msg" is suggested. Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message" is suggested. This conforms to "public.message" and "public.composite-content" but does not necessarily conform to "public.utf8-plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This is a structured media type which embeds other MIME media types. The 8-bit or binary content-transfer- encoding MUST be used unless this media type is sent over a 7-bit only transport. Author: See Author's Address section of this document. Change controller: IETF Standards Process === Message/global-headers, from draft-ietf-eai-dsn-05 === Type name: message Subtype name: global-headers Required parameters: none Optional parameters: none Encoding considerations: This media type contains Internationalized Email Headers [I-D.ietf-eai-utf8headers] with no message body. Whenever possible, the 8-bit content transfer encoding SHOULD be used. When this media type passes through a 7-bit-only SMTP infrastructure it MAY be encoded with the base64 or quoted- printable content transfer encoding. Security considerations: See Section 7 Interoperability considerations: It is important this media type is not converted to a charset other than UTF-8. As a result, implementations MUST NOT include a charset parameter with this media type. Although it might be possible to downconvert this media type to the text/rfc822-header media type, such conversion is discouraged as it loses information. Published specification: RFC XXXX Applications that use this media type: UTF8SMTP servers and email clients that support multipart/report generation or parsing. Additional information: Magic number(s): none File extension(s): In the event this is saved to a file, the extension ".u8hdr" is suggested. Macintosh file type code(s): The 'TEXT' type code is suggested as files of this type are typically used for diagnostic purposes and suitable for analysis in a UTF-8 aware text editor. A uniform type identifier (UTI) of "public.utf8-email-message-header" is suggested. This type conforms to "public.utf8-plain-text" and "public.plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This media type contains textual data in the UTF-8 charset. It typically contains octets with the 8th bit set. As a result a transfer encoding is required when a 7-bit transport is used. Author: See Author's Address section of this document. Change controller: IETF Standards Process === Message/global-delivery-status, from draft-ietf-eai-dsn-05 === Type name: message Subtype name: global-delivery-status Required parameters: none Optional parameters: none Encoding considerations: This media type contains delivery status notification attributes in the UTF-8 charset. The 8-bit content transfer encoding MUST be used with this content-type, unless it is sent over a 7-bit transport environment in which case quoted- printable or base64 may be necessary. Security considerations: See Section 7 Interoperability considerations: This media type provides functionality similar to the message/delivery-status content type for email message return information. Clients of the previous format will need to be upgraded to interpret the new format, however the new media type makes it simple to identify the difference. Published specification: RFC XXXX Applications that use this media type: SMTP servers and email clients that support delivery status notification generation or parsing. Additional information: Magic number(s): none File extension(s): The extension ".u8dsn" is suggested. Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message-delivery-status" is suggested. This type conforms to "public.utf8-plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This is expected to be the second part of a multipart/report. Author: See Author's Address section of this document. Change controller: IETF Standards Process === Message/global-disposition-notification, from draft-ietf-eai-dsn-05 === Type name: message Subtype name: global-disposition-notification Required parameters: none Optional parameters: none Encoding considerations: This media type contains disposition notification attributes in the UTF-8 charset. The 8-bit content transfer encoding MUST be used with this content-type, unless it is sent over a 7-bit transport environment in which case quoted- printable or base64 may be necessary. Security considerations: See Section 7 Interoperability considerations: This media type provides functionality similar to the message/disposition-notification content type for email message disposition information. Clients of the previous format will need to be upgraded to interpret the new format, however the new media type makes it simple to identify the difference. Published specification: RFC XXXX Applications that use this media type: Email clients or servers that support message disposition notification generation or parsing. Additional information: Magic number(s): none File extension(s): The extension ".u8mdn" is suggested. Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message-disposition-notification" is suggested. This type conforms to "public.utf8-plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This is expected to be the second part of a multipart/report. Author: See Author's Address section of this document. Change controller: IETF Standards Process _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 21 06:16:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGudl-0005pN-Nj; Mon, 21 Jan 2008 06:16:33 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JGudl-0005pG-3j for ima-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 06:16:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGudk-0005p3-QA for ima@ietf.org; Mon, 21 Jan 2008 06:16:32 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGudj-00021X-2P for ima@ietf.org; Mon, 21 Jan 2008 06:16:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JGudc-0006fT-NY for ima@ietf.org; Mon, 21 Jan 2008 11:16:24 +0000 Received: from c-134-88-34.hh.dial.de.ignite.net ([62.134.88.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jan 2008 11:16:24 +0000 Received: from nobody by c-134-88-34.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jan 2008 11:16:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 21 Jan 2008 12:16:33 +0100 Organization: Lines: 30 Message-ID: References: <47947574.5030406@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-34.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [EAI] Re: Request for review of EAI MIME types X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > If possible, keep the EAI WG copied on any substantive comments. I keep the "types" review list out of this for an editorial nit: =20 > Subtype name: global [...] > Applications that use this media type: SMTP servers and email > clients that support multipart/report generation or parsing. > Email clients which forward messages with international > headers as attachments. Those are important cases where a Content-Type: message/global is *explicitly* used. For an ordinary 2822upd Internet message the message doesn't explicitly say that it is a message/rfc822, because that's understood for SMTP MAIL/SAML/SOML DATA (I'm not sure about SEND, forget it, that's anyway obsolete). Likewise it's understood that an NNTP message is a message/news until USEFOR confirms that this is the same as a message/rfc822, as noted in RFC 2045 IIRC. (Or whoever deprecates message/news, it doesn't need to be USEFOR, but likely it has to be a RFC) Therefore a message with an UTF-8 header transmitted by UTF8SMTP is *implicitly* a message/global, and the applications that use this media type include anything supporting EAI - not only the explicit cases mentioned in the registration template. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 21 10:58:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGz28-0006YS-Bx; Mon, 21 Jan 2008 10:58:00 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JGz26-0006YL-MK for ima-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 10:57:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGz26-0006YD-Bo for ima@ietf.org; Mon, 21 Jan 2008 10:57:58 -0500 Received: from main1.mycybernet.net ([209.222.63.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGz26-0003ol-2F for ima@ietf.org; Mon, 21 Jan 2008 10:57:58 -0500 Received: from 227-54-222-209.mycybernet.net ([209.222.54.227] helo=crankycanuck.ca) by main1.mycybernet.net with esmtp (Exim 4.62) (envelope-from ) id 1JGz25-00085O-N6 for ima@ietf.org; Mon, 21 Jan 2008 10:57:57 -0500 Received: by crankycanuck.ca (Postfix, from userid 1000) id 94F1450020; Mon, 21 Jan 2008 10:57:52 -0500 (EST) Date: Mon, 21 Jan 2008 10:57:52 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] UTF8 MUST NOT transmit... Message-ID: <20080121155752.GB15200@crankycanuck.ca> References: <3BA66DF86EA0146BA4379FB0@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Jan 18, 2008 at 10:41:00AM -0800, Shawn Steele wrote: > > Its probably worth pointing out that punycode names are permitted. I > realize that punycode names are technically ASCII, however IDN aware > readers may equate them with "internationalized", so it'd be good to > clarify this point. I think this is a good idea. A -- Andrew Sullivan | ajs@crankycanuck.ca The plural of anecdote is not data. --Roger Brinner _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 21 15:00:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2os-0007v4-9B; Mon, 21 Jan 2008 15:00:34 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JH2oq-0007ui-OU for ima-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 15:00:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2oq-0007ua-DT; Mon, 21 Jan 2008 15:00:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH2oq-0006kh-0I; Mon, 21 Jan 2008 15:00:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D79C12AC81; Mon, 21 Jan 2008 20:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JH2oL-0006Qz-Gi; Mon, 21 Jan 2008 15:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 21 Jan 2008 15:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-dsn-06.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Delivery Status and Disposition Notifications Author(s) : C. Newman, A. Melnikov Filename : draft-ietf-eai-dsn-06.txt Pages : 19 Date : 2008-01-21 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-21145740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-21145740.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Jan 21 17:56:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH5ZJ-0000WY-0R; Mon, 21 Jan 2008 17:56:41 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JH5ZH-0000WR-OQ for ima-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 17:56:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH5ZH-0000WJ-ET for ima@ietf.org; Mon, 21 Jan 2008 17:56:39 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH5ZF-0000MU-P7 for ima@ietf.org; Mon, 21 Jan 2008 17:56:39 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBC5E2596CB; Mon, 21 Jan 2008 23:56:36 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03185-05; Mon, 21 Jan 2008 23:56:31 +0100 (CET) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D86D2596DB; Mon, 21 Jan 2008 23:56:26 +0100 (CET) Date: Mon, 21 Jan 2008 23:53:12 +0100 From: Harald Tveit Alvestrand To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: Request for review of EAI MIME types Message-ID: In-Reply-To: References: <47947574.5030406@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Thanks Frank - this was obviously not fixed after the move of the MIME type definition from the dsn to the utf8hdr spec. Harald --On 21. januar 2008 12:16 +0100 Frank Ellermann wrote: > Harald Alvestrand wrote: > >> If possible, keep the EAI WG copied on any substantive comments. > > I keep the "types" review list out of this for an editorial nit: > >> Subtype name: global > [...] >> Applications that use this media type: SMTP servers and email >> clients that support multipart/report generation or parsing. >> Email clients which forward messages with international >> headers as attachments. > > Those are important cases where a Content-Type: message/global > is *explicitly* used. For an ordinary 2822upd Internet message > the message doesn't explicitly say that it is a message/rfc822, > because that's understood for SMTP MAIL/SAML/SOML DATA (I'm not > sure about SEND, forget it, that's anyway obsolete). > > Likewise it's understood that an NNTP message is a message/news > until USEFOR confirms that this is the same as a message/rfc822, > as noted in RFC 2045 IIRC. (Or whoever deprecates message/news, > it doesn't need to be USEFOR, but likely it has to be a RFC) > > Therefore a message with an UTF-8 header transmitted by UTF8SMTP > is *implicitly* a message/global, and the applications that use > this media type include anything supporting EAI - not only the > explicit cases mentioned in the registration template. > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 24 20:00:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JICw9-0000JB-Sx; Thu, 24 Jan 2008 20:00:53 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JI7bU-0001ab-0j for ima-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 14:19:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI7bT-0001aS-KK for ima@ietf.org; Thu, 24 Jan 2008 14:19:11 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI7bT-0000Xi-8V for ima@ietf.org; Thu, 24 Jan 2008 14:19:11 -0500 Received: by wa-out-1112.google.com with SMTP id k40so774217wah.25 for ; Thu, 24 Jan 2008 11:19:10 -0800 (PST) Received: by 10.114.149.2 with SMTP id w2mr1218166wad.29.1201202350068; Thu, 24 Jan 2008 11:19:10 -0800 (PST) Received: by 10.114.150.8 with HTTP; Thu, 24 Jan 2008 11:19:10 -0800 (PST) Message-ID: Date: Thu, 24 Jan 2008 14:19:10 -0500 From: "Mark Baker" To: "Harald Alvestrand" In-Reply-To: <47947574.5030406@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47947574.5030406@alvestrand.no> X-Google-Sender-Auth: 443e1269f6f59112 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Thu, 24 Jan 2008 20:00:52 -0500 Cc: EAI WG , ietf-types@alvestrand.no Subject: [EAI] Re: Request for review of EAI MIME types X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I'm no subject matter expert in this space, but everything looks in order from a registration process POV. The security considerations sections weren't included in your message, but are found in the drafts, and they appear fine. Mark. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 25 04:03:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKSr-0006K6-0G; Fri, 25 Jan 2008 04:03:09 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JIKSp-0006K0-Fv for ima-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 04:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKSo-0006Js-VC for ima@ietf.org; Fri, 25 Jan 2008 04:03:06 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIKSn-0008PW-FU for ima@ietf.org; Fri, 25 Jan 2008 04:03:06 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B27BF259722 for ; Fri, 25 Jan 2008 10:03:04 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31538-06 for ; Fri, 25 Jan 2008 10:03:00 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B6DC259720 for ; Fri, 25 Jan 2008 10:03:00 +0100 (CET) Message-ID: <4799A5C3.8060504@alvestrand.no> Date: Fri, 25 Jan 2008 10:02:59 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] Non-updated "scenarios" posted X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org FYI: I have posted a version -03 of "scenarios", just because the old version had expired. No changes to the document were made. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 25 04:10:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKZY-0000iq-Ge; Fri, 25 Jan 2008 04:10:04 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JIKZX-0000iW-C0 for ima-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 04:10:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKZW-0000iN-Nu; Fri, 25 Jan 2008 04:10:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIKZW-0006fD-BM; Fri, 25 Jan 2008 04:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 032742AC63; Fri, 25 Jan 2008 09:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JIKZV-0003d2-OZ; Fri, 25 Jan 2008 04:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 25 Jan 2008 04:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-scenarios-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : UTF-8 Mail: Scenarios Author(s) : H. Alvestrand Filename : draft-ietf-eai-scenarios-03.txt Pages : 9 Date : 2008-01-25 This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. One possible set of extensions that can work in these scenarios is those described in the UTF8SMTP extension documents.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-scenarios-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-25040319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-scenarios-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-scenarios-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-25040319.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Jan 25 05:02:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILNx-0008F4-Dz; Fri, 25 Jan 2008 05:02:09 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JILNw-0008EJ-43 for ima-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:02:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILNv-0008Dz-PV for ima@ietf.org; Fri, 25 Jan 2008 05:02:07 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JILNv-0008Cg-E2 for ima@ietf.org; Fri, 25 Jan 2008 05:02:07 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JILNp-0004PW-Aj for ima@ietf.org; Fri, 25 Jan 2008 10:02:01 +0000 Received: from c-134-88-207.hh.dial.de.ignite.net ([62.134.88.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 10:02:01 +0000 Received: from nobody by c-134-88-207.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 10:02:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Fri, 25 Jan 2008 11:02:16 +0100 Organization: Lines: 15 Message-ID: References: <4799A5C3.8060504@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-207.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [EAI] Re: Non-updated "scenarios" posted X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: =20 > I have posted a version -03 of "scenarios", just because the > old version had expired. No changes to the document were made. Apart from the message "this is still work in progress", is it still in any way good or required to post "keep-alive" drafts ? When I let my drafts expire and later revived them there was no problem, the submission tool simply accepted it, and in the old manual procedure the secretariat only noted the fact "revived". Just curious: Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 25 11:37:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRYX-0004ky-U6; Fri, 25 Jan 2008 11:37:29 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JIRYX-0004gt-40 for ima-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 11:37:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRYW-0004Zx-Ou for ima@ietf.org; Fri, 25 Jan 2008 11:37:28 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIRYV-0003fF-Ss for ima@ietf.org; Fri, 25 Jan 2008 11:37:28 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew$man^ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.278) id 479a1046.12fb2.20 for ima@ietf.org; Fri, 25 Jan 2008 16:37:26 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id m0PGbPGW008111 for ; Fri, 25 Jan 2008 16:37:26 GMT Date: Fri, 25 Jan 2008 16:37:25 -0000 To: IMA Subject: Re: [EAI] Re: Non-updated "scenarios" posted From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <4799A5C3.8060504@alvestrand.no> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 25 Jan 2008 10:02:16 -0000, Frank Ellermann wrote: > Harald Alvestrand wrote: > >> I have posted a version -03 of "scenarios", just because the >> old version had expired. No changes to the document were made. > > Apart from the message "this is still work in progress", is it > still in any way good or required to post "keep-alive" drafts ? And is there any need for "scenarios" to proceed to RFC? I thought its purpose was just to provide this WG with a list of points to look out for. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 26 23:47:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIzQS-0005bN-3A; Sat, 26 Jan 2008 23:47:24 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JIzQQ-0005bI-SP for ima-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 23:47:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIzQQ-0005bA-H5 for ima@ietf.org; Sat, 26 Jan 2008 23:47:22 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIzQQ-0007oZ-0l for ima@ietf.org; Sat, 26 Jan 2008 23:47:22 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6844A259759 for ; Sun, 27 Jan 2008 05:47:21 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21074-09 for ; Sun, 27 Jan 2008 05:47:16 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFCF1259758 for ; Sun, 27 Jan 2008 05:47:15 +0100 (CET) Message-ID: <479C0CC4.1080708@alvestrand.no> Date: Sun, 27 Jan 2008 05:47:00 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: EAI WG X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------010201090403080107070808" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [EAI] [Fwd: eai - New Meeting Session Request for IETF 71] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------010201090403080107070808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I have sent the request below to hold an EAI meeting at IETF-71 in Philadelphia. Please notify me of any updates needed to the conflicts list. Harald --------------010201090403080107070808 Content-Type: message/rfc822; name="eai - New Meeting Session Request for IETF 71" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eai - New Meeting Session Request for IETF 71" Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Sun, 27 Jan 2008 05:44:18 +0100 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B94DC259759 for ; Sun, 27 Jan 2008 05:44:18 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20772-09 for ; Sun, 27 Jan 2008 05:44:12 +0100 (CET) X-Greylist: domain auto-whitelisted by SQLgrey-1.6.7 Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F98F259758 for ; Sun, 27 Jan 2008 05:44:12 +0100 (CET) Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id B84A026E5B; Sun, 27 Jan 2008 04:44:10 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1JIzNK-0001OL-JS; Sat, 26 Jan 2008 23:44:10 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: session-request@ietf.org Cc: chris.newman@sun.com, lisa@osafoundation.org, harald@alvestrand.no, lee@cnnic.cn From: IETF Meeting Session Request Tool Subject: eai - New Meeting Session Request for IETF 71 Message-Id: Date: Sat, 26 Jan 2008 23:44:10 -0500 X-Virus-Scanned: by amavisd-new at alvestrand.no A new meeting session request has just been submitted by Harald Alvestrand, a working group chair of eai. --------------------------------------------------------- Working Group Name: eai Area Name: Applications Area Session Requester: Harald Alvestrand Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 60 Conflicts to Avoid: First Priority: imapext lemonade apparea ipr lemonade ltru dkim sieve sasl dnsop ipr smime krb-wg enum usefor tls httpbis Second Priority: dnsext crisp BOF or IRTF Session: please avoid conflict with BOFs of APP area, Special Requests: --------------------------------------------------------- --------------010201090403080107070808 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --------------010201090403080107070808-- From ima-bounces@ietf.org Sun Jan 27 09:20:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ8Mj-00051C-J9; Sun, 27 Jan 2008 09:20:09 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JJ8Mi-0004ur-7N for ima-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 09:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ8Mh-0004ty-TD for ima@ietf.org; Sun, 27 Jan 2008 09:20:07 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ8Mg-00030q-Bi for ima@ietf.org; Sun, 27 Jan 2008 09:20:07 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92F7E25973E; Sun, 27 Jan 2008 15:20:03 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03064-01; Sun, 27 Jan 2008 15:19:57 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B5CE259739; Sun, 27 Jan 2008 15:19:57 +0100 (CET) Message-ID: <479C930D.6020208@alvestrand.no> Date: Sun, 27 Jan 2008 15:19:57 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] Re: Non-updated "scenarios" posted References: <4799A5C3.8060504@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Fri, 25 Jan 2008 10:02:16 -0000, Frank Ellermann > wrote: > >> Harald Alvestrand wrote: >> >>> I have posted a version -03 of "scenarios", just because the >>> old version had expired. No changes to the document were made. >> >> Apart from the message "this is still work in progress", is it >> still in any way good or required to post "keep-alive" drafts ? > > And is there any need for "scenarios" to proceed to RFC? I thought its > purpose was just to provide this WG with a list of points to look out > for. That decision has not yet been taken. We're still not done with "downgrade", and the discussions that led to abandoning "upgrade" in POP and IMAP were very much driven by scenarios; those scenarios are not documented in either the POP/IMAP documents or the scenarios documents. It would be nice to capture them somewhere. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 27 22:10:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJKNr-0008Tg-PA; Sun, 27 Jan 2008 22:10:07 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JJKNn-0008PD-4q for ima-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 22:10:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJKNm-0008Ns-IQ; Sun, 27 Jan 2008 22:10:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJKNm-0004De-6i; Sun, 27 Jan 2008 22:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D999F32875; Mon, 28 Jan 2008 03:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JJKNl-0003ED-NX; Sun, 27 Jan 2008 22:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 27 Jan 2008 22:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-smtpext-11.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. MAO Filename : draft-ietf-eai-smtpext-11.txt Pages : 22 Date : 2008-01-27 This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-27220847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-27220847.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Wed Jan 30 07:38:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCD4-0005rY-QZ; Wed, 30 Jan 2008 07:38:34 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1JKCD3-0005my-JF for ima-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 07:38:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCD3-0005mi-94 for ima@ietf.org; Wed, 30 Jan 2008 07:38:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKCD0-00084K-AG for ima@ietf.org; Wed, 30 Jan 2008 07:38:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JKCCt-0006hR-SN for ima@ietf.org; Wed, 30 Jan 2008 12:38:24 +0000 Received: from c-134-88-51.hh.dial.de.ignite.net ([62.134.88.51]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 12:38:23 +0000 Received: from nobody by c-134-88-51.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 12:38:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Wed, 30 Jan 2008 13:38:30 +0100 Organization: Lines: 58 Message-ID: References: <47865938.80406@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-51.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ietf-smtp@imc.org Subject: [EAI] Re: I-D Action:draft-hansen-4468upd-mailesc-registry-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Hansen wrote: =20 > A Registry for SMTP Enhanced Mail System Status Codes, > draft-hansen-4468upd-mailesc-registry, has been updated. Hi, an editorial nit, it took me some minutes to see that there is no X.5.1 in RFC 3886. The current draft says: |1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through | X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through | X.4.7, | |2. X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 through | X.7.7) section 3.3.4 of [RFC3886] (X.1.9), | |3. X.6.6 found in section 5 of [RFC4468], [...] It should say: |1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through | X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through | X.4.7, X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 | through X.7.7)=20 | |2. section 3.3.4 of [RFC3886] (X.1.9), | |3. X.6.6 found in section 5 of [RFC4468], [...] I checked Alexey's list of associated status codes with RFC 4408: | X.3.0 --> 550, 554, 451 451 (4.3.0) in http://tools.ietf.org/html/rfc4408#section-2.5.5 | X.4.3 --> 451, 550 451 (4.4.3) in http://tools.ietf.org/html/rfc4408#section-2.5.6 | X.7.1 --> 550, 551, 451 550 (5.7.1) in http://tools.ietf.org/html/rfc4408#section-2.5.4 | X.5.2 --> 500, 501, 502, 555 550 (5.5.2) missing in RFC 4408 section 2.5.7, noted as erratum=20 http://www.openspf.org/RFC_4408/Errata#permerror-smtp-reply-code =20 Alexey's table doesn't have 550 for 5.5.2, and trying to find out what's wrong (if anything) I found in RFC 3463: | X.5.2 Syntax error | A mail transaction protocol command was issued which could not | be interpreted, either because the syntax was wrong or the | command is unrecognized. This is useful only as a permanent | error. If a code (not only 5.5.2) makes only sense as permanent error the registry could indicate this as 5?? instead of ???. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima