From ima-bounces@ietf.org Wed Mar 01 01:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEKzu-0003kv-7b; Wed, 01 Mar 2006 01:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEKzt-0003kq-B1 for ima@ietf.org; Wed, 01 Mar 2006 01:39:41 -0500 Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEKzq-0007VV-Vb for ima@ietf.org; Wed, 01 Mar 2006 01:39:41 -0500 Received: (eyou send program); Wed, 01 Mar 2006 14:39:24 +0800 Message-ID: <341195164.25095@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Wed, 01 Mar 2006 14:39:24 +0800 Message-ID: <051a01c63cfb$2a9455a0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: Date: Wed, 1 Mar 2006 14:41:27 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [IEE] recent submitted draft related to IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2003845567==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============2003845567== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0517_01C63D3E.389B0CF0" This is a multi-part message in MIME format. ------=_NextPart_000_0517_01C63D3E.389B0CF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpyZWNlbnQgc3VibWl0dGVkIGRyYWZ0cyByZWxhdGVkIHRvIElNQQ0KDQpodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW8taW1hLXNtdHBleHQtMDIudHh0Lg0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2xlbnNpbi1pbWEtZnJhbWV3 b3JrLTAxLnR4dA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteWVo LWltYS11dGY4aGVhZGVycy0wMS50eHQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LW5ld21hbi1pbWEtcG9wLTAwLnR4dA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQta2xlbnNpbi1pbWEtY29uc3RyYWludHMtMDAudHh0DQoNCg0KWUFP IEppYW5rYW5nDQpCZXN0IFJlZ2FyZHMNClRlbDo4Ni0xMC01ODgxMzAwNw0KRmF4Ojg2LTEwLTYy NTU5ODkyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KQ2hpbmEgSW50ZXJuZXQgTmV0d29yayBJbmZvcm1hdGlvbiBDZW50ZXIgKENOTklDKQ0KNCwg U291dGggNHRoIFN0cmVldCwgWmhvbmdndWFuY3VuLA0KSGFpZGlhbiBkaXN0cmljdCwNCkJlaWpp bmcgMTAwMDgwLCBDaGluYQ0KUE9COiBCZWlqaW5nIDM0OSwgQnJhbmNoIDYNCmh0dHA6Ly93d3cu Y25uaWMuY24NCkVtYWlsOiB5YW9qa0Bjbm5pYy5jbg0KaGVhbHRoeWFvQDE2My5jb20NCg== ------=_NextPart_000_0517_01C63D3E.389B0CF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE1MjgiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPnJlY2VudCBzdWJtaXR0 ZWQgZHJhZnRzIHJlbGF0ZWQgdG8gSU1BPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvO zOUgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEEgDQpocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW8taW1hLXNtdHBleHQtMDIudHh0Ij5o dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW8taW1hLXNtdHBleHQt MDIudHh0PC9BPi48QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1rbGVuc2luLWltYS1mcmFtZXdvcmstMDEudHh0Ij5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rbGVuc2luLWltYS1mcmFtZXdvcmstMDEudHh0PC9B PjxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXllaC1pbWEtdXRmOGhlYWRlcnMtMDEudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC15ZWgtaW1hLXV0ZjhoZWFkZXJzLTAxLnR4dDwvQT48QlI+PEEgDQpocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uZXdtYW4taW1hLXBv cC0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5ld21h bi1pbWEtcG9wLTAwLnR4dDwvQT48QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1rbGVuc2luLWltYS1jb25zdHJhaW50cy0wMC50eHQiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtsZW5zaW4taW1hLWNvbnN0cmFp bnRzLTAwLnR4dDwvQT48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPllBTyBKaWFua2FuZzxCUj5CZXN0IA0K UmVnYXJkczxCUj5UZWw6ODYtMTAtNTg4MTMwMDc8QlI+RmF4Ojg2LTEwLTYyNTU5ODkyPEJSPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPkNoaW5h IA0KSW50ZXJuZXQgTmV0d29yayBJbmZvcm1hdGlvbiBDZW50ZXIgKENOTklDKTxCUj40LCBTb3V0 aCA0dGggU3RyZWV0LCANClpob25nZ3VhbmN1biw8QlI+SGFpZGlhbiBkaXN0cmljdCw8QlI+QmVp amluZyAxMDAwODAsIENoaW5hPEJSPlBPQjogQmVpamluZyAzNDksIA0KQnJhbmNoIDY8QlI+PEEg aHJlZj0iaHR0cDovL3d3dy5jbm5pYy5jbiI+aHR0cDovL3d3dy5jbm5pYy5jbjwvQT48QlI+RW1h aWw6IDxBIA0KaHJlZj0ibWFpbHRvOnlhb2prQGNubmljLmNuIj55YW9qa0Bjbm5pYy5jbjwvQT48 QlI+PEEgDQpocmVmPSJtYWlsdG86aGVhbHRoeWFvQDE2My5jb20iPmhlYWx0aHlhb0AxNjMuY29t PC9BPjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0517_01C63D3E.389B0CF0-- --===============2003845567== 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 --===============2003845567==-- From ima-bounces@ietf.org Wed Mar 01 03:44:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMwn-0001Xh-7F; Wed, 01 Mar 2006 03:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMwl-0001XZ-Ct; Wed, 01 Mar 2006 03:44:35 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMwj-0003ZV-PX; Wed, 01 Mar 2006 03:44:35 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k218hnd09307; Wed, 1 Mar 2006 17:43:49 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 6186_812bb51e_a8ff_11da_97b2_0014221f2a2d; Wed, 01 Mar 2006 17:43:48 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k218gkwj023374; Wed, 1 Mar 2006 17:43:12 +0900 Message-Id: <6.0.0.20.2.20060228113631.04a10d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 01 Mar 2006 16:39:57 +0900 To: Dave Crocker From: Martin Duerst Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) In-Reply-To: <4402BC94.7040709@bbiw.net> References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF6DA8.4000206@dcrocker.net> <6.0.0.20.2.20060227132450.08b94e80@lo <4402BC94.7040709@bbiw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello Dave, At 17:47 06/02/27, you wrote: >> It may be the first time somebody is saying that using all 8 bits >> that TCP/IP provides needs a research effort. > >Since it is not what I said, it probably does not help dialogue to represent my concern this way. Sorry to start my comments with this somewhat provocative and simplifying statement. You still may want to answer the rest of my mail. I also agree with what Yangwoo Ko has said, and you seem to agree to a large extent, too. My understanding is that we are all not sure how well deployment will work, and we are very well aware of the fact that deployment will be critical, and we need to work hard to try to come up with finetuned proposals that do the best in this respect. Taking that back to the IRTF vs. Experimental discussion, it seems to me that the only way to do research (if you want to call it that) about deployment issues is to actually try to, at least experimentally, deploy the technology. Testing out different alternatives/configurations/ settings as one would usually do in research doesn't seem like an option. In my view even the Experimental stamp will hold back some real-world deployment that might happen with Proposed. That's why I said that I personally preferred Standards track: It's better to go to Proposed and if necessary later to historical/obsolete than to do IRTF or Experimental and miss a deployment opportunity because we never actually really tried. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 02 11:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqsU-0004xx-Tk; Thu, 02 Mar 2006 11:42:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqsT-0004xs-Uu for ima@ietf.org; Thu, 02 Mar 2006 11:42:09 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqsS-0006As-KP for ima@ietf.org; Thu, 02 Mar 2006 11:42:09 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 690FB259768 for ; Thu, 2 Mar 2006 17:40:35 +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 31679-05 for ; Thu, 2 Mar 2006 17:40:31 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 105D7259762 for ; Thu, 2 Mar 2006 17:40:31 +0100 (CET) Message-ID: <4407205B.5080206@alvestrand.no> Date: Thu, 02 Mar 2006 17:42:03 +0100 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org 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: 2409bba43e9c8d580670fda8b695204a Subject: [IEE] Current list of EAI related drafts X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The following list of drafts are related to EAI (the proto-WG formerly known as IEE and IMA): Problem/framing: draft-alvestrand-i18mail-scenarios draft-klensin-ima-constraints Solution: draft-klensin-ima-framework draft-yeh-ima-utf8headers draft-yao-ima-smtpext draft-yoneya-ima-downgrade (if -01 comes through) draft-newman-ima-pop I wrote the first one on the list to attempt to answer Keith Moore's question that I interpreted as "what do you mean when you say 'email works'". If the IESG chooses to ask me to function as chair for this WG, it needs another editor. The second one is intended as an input piece, not as WG output. Please send a note if I've overlooked one! Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 03 04:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6RB-0001gg-N4; Fri, 03 Mar 2006 04:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6R9-0001Tn-Po for ima@ietf.org; Fri, 03 Mar 2006 04:18:59 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FF6R8-00045l-To for ima@ietf.org; Fri, 03 Mar 2006 04:18:59 -0500 Received: (snipe 20740 invoked by uid 0); 3 Mar 2006 18:18:57 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 1.187805 secs); Received: from unknown (HELO ?210.107.249.21?) (ZXY?own@210.107.249.21) by unknown with SMTP; 3 Mar 2006 18:18:56 +0900 X-RCPTTO: dcrocker@bbiw.net, falk@ISI.EDU, iesg@ietf.org, ima@ietf.org Message-ID: <440809FD.4000506@icu.ac.kr> Date: Fri, 03 Mar 2006 18:18:53 +0900 From: Yangwoo Ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> <440221B8.1090101@dcrocker.net> <4402B595.8050407@icu.ac.kr> <440492F7.6030504@dcrocker.net> In-Reply-To: <440492F7.6030504@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear Dave Crocker, Thanks for good points. Please find my replies embedded below. Regards Dave Crocker wrote: > > > Dicussion between Dave and John, quoted above, can be understood as how > >> significant it will be? I'd rather interpret the "significance" in >> somewhat different aspect. > > > I think you have describe the question correctly. > > I think that a change in the form of email addresses that can cause > delivery to fail should be considered significant. (Off-topic) Are we "changing the form" of email addresses? As a non-native English speaker, it is always very hard to grasp various meanings and usages of English words. I think we are just "adding more forms" thanks to the nice property of UTF-8. (On) Delivery failure is not always bad. Through a failure notice, a user is able to see that he/she should use alternative addresses if available. Though I don't think this type of human assisted address alternation is the best engineering solution, it is still one of valuable options we can take. > > It can/will partition the functional infrastructure. > > >> As we assume, it seems to be relatively easy to do IMA only between >> agreed parties. The real devil lies at the boundary. > > > Yes. Exactly correct. > > >> However good news is that, as a design team of this extention, we >> have a knob that controls how significantly we want to change the >> infrastructure. For example, in one extreme, we can just drop any >> mail that tries to cross the boundary. On the other extreme, every >> part of the Internet infrastructure is required to be upgraded >> somehow to support IMA so perfectly that users cannot even recognize >> that there is such boundary. In order to make IMA more usable, we >> want to deviate from the former extreme as much as possible. In order >> to make IMA be more practical, we cannot but deviate from the other >> extreme. > > > How does a design team control the operational behavior of boundary > MTAs? The experience with gatewaying between independent mail > services is that it is a challenge, at best. I don't see your point. If a standard cannot define the behavior of "compliant" components, then what is that standard for? Or, are you saying that it is impossible to standardize the behavior of gateways because the complexity of gatewaying is simply beyond the human-being's brain power? > Further, the experience with the use of "private" IP Addresses within > networks is they leak out into the public Internet. Yes. They will leak regardless of how hard we try to design the right thing. However, we have defined private IP address range and users are using it everyday. Because it is very useful to solve many real issues. No one can say that I18N addresses will not leak at all. Users who are not using EAI-enabled components will get hurt from time to time. It seems impossible (or at least impractically hard) to avoid this type of uncomfort completely. If IETF as a community has a rough consensus that any form of leak with any frequency is significant and any new idea leading to that significant change should be dealt by IRTF, then let EAI be discussed at IRTF. > > In the last 25 years, there have been somewhere between 0 and few > efforts to affect basic deliverability. (DSN is the possible > exception and it's adoption history provides quite an education.) > > d/ > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 09 10:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNQG-0005ql-H3; Thu, 09 Mar 2006 10:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNQF-0005oP-3a for ima@ietf.org; Thu, 09 Mar 2006 10:51:27 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHNQD-00067i-RZ for ima@ietf.org; Thu, 09 Mar 2006 10:51:27 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1141919485!7315368!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19497 invoked from network); 9 Mar 2006 15:51:25 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 9 Mar 2006 15:51:25 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060309155124gw100100o6e> (Authid: tony); Thu, 9 Mar 2006 15:51:24 +0000 Message-ID: <44104EFB.10408@att.com> Date: Thu, 09 Mar 2006 10:51:23 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [IEE] schedule conflict X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I wish there were something that could be done about the conflict between eai Email Address Internationalization BOF and dkim Domain Keys Identified Mail WG, both Monday 1:00 - 3:00. Tony Hansen tony@att.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 09 16:23:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSbu-0001lp-1M; Thu, 09 Mar 2006 16:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSbt-0001lk-Jh for ima@ietf.org; Thu, 09 Mar 2006 16:23:49 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSbs-00058h-VU for ima@ietf.org; Thu, 09 Mar 2006 16:23:49 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k29LNlR9005854 for ; Fri, 10 Mar 2006 06:23:47 +0900 (JST) Received: (from unknown [202.11.16.62]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006031006234619165 for ; Fri, 10 Mar 2006 06:23:46 +0900 Date: Fri, 10 Mar 2006 06:23:47 +0900 From: Yoshiro YONEYA To: ima@ietf.org Message-Id: <20060310062347.c8d693a0.yone@jprs.co.jp> In-Reply-To: <4407205B.5080206@alvestrand.no> References: <4407205B.5080206@alvestrand.no> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.6.10; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__10_Mar_2006_06_23_47_+0900_TEta_agCWLPw9erL" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Subject: [IEE] Re: Current list of EAI related drafts X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" 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. --Multipart=_Fri__10_Mar_2006_06_23_47_+0900_TEta_agCWLPw9erL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear Folks, draft-yoneya-ima-downgrade-01 has published. -- Yoshiro YONEYA On Thu, 02 Mar 2006 17:42:03 +0100 Harald Alvestrand wrote: > The following list of drafts are related to EAI (the proto-WG formerly > known as IEE and IMA): > > Problem/framing: > > draft-alvestrand-i18mail-scenarios > draft-klensin-ima-constraints > > Solution: > > draft-klensin-ima-framework > draft-yeh-ima-utf8headers > draft-yao-ima-smtpext > draft-yoneya-ima-downgrade (if -01 comes through) > draft-newman-ima-pop > > I wrote the first one on the list to attempt to answer Keith Moore's > question that I interpreted as "what do you mean when you say 'email > works'". If the IESG chooses to ask me to function as chair for this WG, > it needs another editor. > > The second one is intended as an input piece, not as WG output. > > Please send a note if I've overlooked one! > > Harald > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > --Multipart=_Fri__10_Mar_2006_06_23_47_+0900_TEta_agCWLPw9erL Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: Received: from msgmgr01.jprs.co.jp (msgmgr01.jprs.co.jp [172.18.8.17]) by spool01.jprs.co.jp (8.12.10+Sun/8.12.11) with ESMTP id k29LBUMZ012087; Fri, 10 Mar 2006 06:11:30 +0900 (JST) Received: from mx01.jprs.co.jp (mx01.jprs.co.jp [202.11.17.111]) by msgmgr01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k29LBUec014180; Fri, 10 Mar 2006 06:11:30 +0900 (JST) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Received: from mx0.jprs.co.jp ([127.0.0.1]) by mx01.jprs.co.jp (SMSSMTP 4.1.9.35) with SMTP id M2006031006112909015 ; Fri, 10 Mar 2006 06:11:29 +0900 Received: from megatron.ietf.org (odin.ietf.org [156.154.16.145]) by mx0.jprs.co.jp (8.13.4/8.13.4) with ESMTP id k29LBTTA025083; Fri, 10 Mar 2006 06:11:29 +0900 (JST) Authentication-Results: mx0.jprs.co.jp from=Internet-Drafts@ietf.org; sender-id=neutral; spf=neutral Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSP1-0004KS-EV; Thu, 09 Mar 2006 16:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5H-00010W-IX for i-d-announce@ietf.org; Thu, 09 Mar 2006 15:50:07 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS5H-0007Et-GQ for i-d-announce@ietf.org; Thu, 09 Mar 2006 15:50:07 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHS5C-0005Qy-W2 for i-d-announce@ietf.org; Thu, 09 Mar 2006 15:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2vP024961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00007X-Gg for i-d-announce@ietf.org; Thu, 09 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: I-D ACTION:draft-yoneya-ima-downgrade-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-UIDL: :=D!!%X)"!2NF!!ied"! --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Downgrading mechanism for Internationalized eMail Address (IMA) Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-yoneya-ima-downgrade-01.txt Pages : 13 Date : 2006-3-9 Traditional mail system handles only US-ASCII characters in SMTP envelope and mail headers. The Internationalized eMail Address (IMA) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver IMA through IMA incompliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP session downgrade, header downgrade and implementation consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yoneya-ima-downgrade-01.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-yoneya-ima-downgrade-01.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-yoneya-ima-downgrade-01.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: <2006-3-9123359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yoneya-ima-downgrade-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-yoneya-ima-downgrade-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9123359.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --Multipart=_Fri__10_Mar_2006_06_23_47_+0900_TEta_agCWLPw9erL 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 --Multipart=_Fri__10_Mar_2006_06_23_47_+0900_TEta_agCWLPw9erL-- From ima-bounces@ietf.org Sun Mar 12 14:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIWF1-0006FV-6k; Sun, 12 Mar 2006 14:28:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIWEz-0006F8-F7 for ima@ietf.org; Sun, 12 Mar 2006 14:28:33 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIWEy-0007Xe-4w for ima@ietf.org; Sun, 12 Mar 2006 14:28:33 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 884BC2596FC; Sun, 12 Mar 2006 20:26:51 +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 27018-08; Sun, 12 Mar 2006 20:26:47 +0100 (CET) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8A3E2596F5; Sun, 12 Mar 2006 20:26:46 +0100 (CET) Message-ID: <44147658.1040005@alvestrand.no> Date: Sun, 12 Mar 2006 20:28:24 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tony Hansen Subject: Re: [IEE] schedule conflict References: <44104EFB.10408@att.com> In-Reply-To: <44104EFB.10408@att.com> 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: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This has now been resolved - EAI is meeting on Monday from 1740 to 1840, in the Chantilly W room (opposite PANA, SHIM6, XCON, RTGAREA, SMIME and PMTUD). Some people may have a problem with SMIME... Harald Tony Hansen wrote: > I wish there were something that could be done about the conflict > between eai Email Address Internationalization BOF and dkim Domain Keys > Identified Mail WG, both Monday 1:00 - 3:00. > > Tony Hansen > tony@att.com > > > _______________________________________________ > 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 Sun Mar 12 15:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIWwG-0004xE-Lb; Sun, 12 Mar 2006 15:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIWwF-0004vX-Kh for ima@ietf.org; Sun, 12 Mar 2006 15:13:15 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIWwE-0000sL-86 for ima@ietf.org; Sun, 12 Mar 2006 15:13:15 -0500 Received: from [192.168.0.2] (adsl-71-131-40-72.dsl.sntc01.pacbell.net [71.131.40.72]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2CKDjgG029059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Mar 2006 12:13:46 -0800 Message-ID: <441480D3.9050106@dcrocker.net> Date: Sun, 12 Mar 2006 12:13:07 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [IEE] schedule conflict References: <44104EFB.10408@att.com> <44147658.1040005@alvestrand.no> In-Reply-To: <44147658.1040005@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > This has now been resolved - EAI is meeting on Monday from 1740 to 1840, > in the Chantilly W room (opposite PANA, SHIM6, XCON, RTGAREA, SMIME and > PMTUD). > > Some people may have a problem with SMIME... Dandy news. Thanks! It appears EAI extends to the following session, 1850-1950. ASRG is during that session, though its IRTF, not IETF. d/ ps. The comment about SMIME was meant to refer to the meeting schedule, or was it perhaps a more global assessment...? -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 12 15:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXOZ-0005Bt-4j; Sun, 12 Mar 2006 15:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXOX-00058A-HF for ima@ietf.org; Sun, 12 Mar 2006 15:42:29 -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 1FIXOW-0001cU-7V for ima@ietf.org; Sun, 12 Mar 2006 15:42:29 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FIXOT-000Kch-Gg; Sun, 12 Mar 2006 15:42:25 -0500 Date: Sun, 12 Mar 2006 15:42:24 -0500 From: John C Klensin To: Harald Alvestrand , Tony Hansen Subject: Re: [IEE] schedule conflict Message-ID: <0297C59C64BEF9A75CF7765F@p3.JCK.COM> In-Reply-To: <44147658.1040005@alvestrand.no> References: <44104EFB.10408@att.com> <44147658.1040005@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, 12 March, 2006 20:28 +0100 Harald Alvestrand wrote: > This has now been resolved - EAI is meeting on Monday from > 1740 to 1840, in the Chantilly W room (opposite PANA, SHIM6, > XCON, RTGAREA, SMIME and PMTUD). >From the agenda, this looks like 1740-1950 (two consecutive one hour slots). > Some people may have a problem with SMIME... And some people may have a problem with one or more of XCOM, ASRG, and/or PKIX, but I think this is a better compromise than conflicting with DKIM. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 12 15:58:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXe7-0003VY-Nm; Sun, 12 Mar 2006 15:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXe6-0003VJ-Na; Sun, 12 Mar 2006 15:58:34 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIXe5-00027a-5k; Sun, 12 Mar 2006 15:58:34 -0500 Received: from [192.168.0.2] (adsl-71-131-40-72.dsl.sntc01.pacbell.net [71.131.40.72]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2CKwmw4001622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Mar 2006 12:58:49 -0800 Message-ID: <44148B62.2060804@dcrocker.net> Date: Sun, 12 Mar 2006 12:58:10 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> <440221B8.1090101@dcrocker.net> <4402B595.8050407@icu.ac.kr> <440492F7.6030504@dcrocker.net> <440809FD.4000506@icu.ac.kr> In-Reply-To: <440809FD.4000506@icu.ac.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ima@ietf.org, Aaron Falk , dcrocker@bbiw.net, iesg@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko, >> I think that a change in the form of email addresses that can cause >> delivery to fail should be considered significant. > > (Off-topic) Are we "changing the form" of email addresses? As a > non-native English > speaker, it is always very hard to grasp various meanings and usages of > English words. > I think we are just "adding more forms" thanks to the nice property of > UTF-8. (I think your English is excellent, and that asking about my use of "form", here, is entirely reasonable, even among native English speakers.) A basic justification for using 'native' UTF-8 is that it is now very widely available on end-user systems. Indeed, this is a powerful argument for doing things differently today than has been done in the past. That is, this is the reason to use UTF-8, for the larger set of characters -- rather than to perform a special encoding on top of existing net ASCII. So I hope it is clear that the concern I am expressing is not with the choice to use 'native' UTF-8. Originally I questioned this choice, but I now think that the justification for doing UTF-8 is quite solid. (Forgive my quoting the word native, but I like to keep in mind that UTF-8, itself, is merely an encoding of the native data form. As was pointed out, we tend to not even use the correct name for that form.) However, I think that the change being described is quite basic, because it means that legacy email implementations will not be able to process addresses that are in the new form. This means that the new email address rules will create a separate, parallel name space. (I suppose that, strictly speaking, the new space is a superset -- I think this is what you mean by "adding more forms" and I believe your are correct. However, this upgrade means that old email systems cannot directly exchange mail with new environments. This is, of course, a very basic disruption to Internet mail service.) In order to exchange mail between the new and the old environments there MUST be a gateway -- and I mean gateway in the true sense: a relay that modifies the message, in order to overcome incompatibilities between the two environments. Most significant is that this incompatibility is with addressing. An impact does not get any more basic, for email. (By the way, folks are using the term "downgrading" and I believe that that is technically incorrect. Downgrading usually means that information is lost. I believe that a gateway between legacy email and EAI email will merely encode the address differently,rather than lose any addressing information detail. If this understanding is incorrect, it needs to be clarified.) > (On) Delivery failure is not always bad. Through a failure notice, a > user is able to see that > he/she should use alternative addresses if available. Please forgive me for disagreeing. First of all this creates an enormous burden on end-users, and the average end-user will not have any idea how to fix the problem -- or, at least, I think that it is unreasonable to expect them to. Second, the fact that email is store-and-forward can mean that there is indirection, such as with mailing lists. So it is not at all clear that the correct entity will receive the notification, or that they will be given enough information. Though I don't > think this type of human > assisted address alternation is the best engineering solution, it is > still one of valuable > options we can take. I think the impact of suddenly finding that email addressing does not always work is a rather serious impact on the perceived reliability and easy-of-use, Internet mail. >> How does a design team control the operational behavior of boundary >> MTAs? The experience with gatewaying between independent mail >> services is that it is a challenge, at best. > > I don't see your point. If a standard cannot define the behavior > of "compliant" components, then what is that standard for? My point is that the EAI effort needs to specify the gateway standard as an integral part of the work. Otherwise we are certain to partition Internet mail. > Or, are you saying that it is impossible to standardize the > behavior of gateways because the complexity of gatewaying > is simply beyond the human-being's brain power? I believe it is possible to specify the necessary gateway. In fact I suspect that this could be one of the more easy gateway specification tasks. My point is that I believe it cannot be treated as a secondary or optional function. I believe it is in the critical path and must be published at the same time as the basic EAI specification. (Just to make something clear, I am extremely unhappy to hold this view. I very much try to make the critical path as small as possible and I very much try to defer work on gateways.) >> Further, the experience with the use of "private" IP Addresses within >> networks is they leak out into the public Internet. > > Yes. They will leak regardless of how hard we try to > design the right thing. However, we have defined private IP address > range and users are using it everyday. Because it is very useful to > solve many real issues. The difference is that all of the private addresses were specially reserved. Hence, it is often possible to detect their inappropriate occurrence, when they do leak. Will that be true for EAI? > If IETF as a community > has a rough consensus that any form of leak with any frequency is > significant and any new idea leading to that significant change should > be dealt by IRTF, then let EAI be discussed at IRTF. Indeed, it is not reasonable to demand perfection. However I think it is equally unreasonable to treat the impact of this type of imperfection as secondary. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 12 16:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIY7H-0004Yl-61; Sun, 12 Mar 2006 16:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIY7G-0004Yg-48 for ima@ietf.org; Sun, 12 Mar 2006 16:28:42 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIY7E-0003Fn-OK for ima@ietf.org; Sun, 12 Mar 2006 16:28:42 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1142198919!9788681!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 13797 invoked from network); 12 Mar 2006 21:28:39 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 12 Mar 2006 21:28:39 -0000 Received: from [135.70.106.162] (unknown[135.70.106.162](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060312212838gw100100dke> (Authid: tony); Sun, 12 Mar 2006 21:28:38 +0000 Message-ID: <44149285.8000803@att.com> Date: Sun, 12 Mar 2006 16:28:37 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [IEE] schedule conflict References: <44104EFB.10408@att.com> <44147658.1040005@alvestrand.no> <0297C59C64BEF9A75CF7765F@p3.JCK.COM> In-Reply-To: <0297C59C64BEF9A75CF7765F@p3.JCK.COM> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Agreed. Of the conflicts, this is probably the best compromise. Thanks! Tony John C Klensin wrote: > > --On Sunday, 12 March, 2006 20:28 +0100 Harald Alvestrand > wrote: > >> This has now been resolved - EAI is meeting on Monday from >> 1740 to 1840, in the Chantilly W room (opposite PANA, SHIM6, >> XCON, RTGAREA, SMIME and PMTUD). > >>From the agenda, this looks like 1740-1950 (two consecutive one > hour slots). > >> Some people may have a problem with SMIME... > > And some people may have a problem with one or more of XCOM, > ASRG, and/or PKIX, but I think this is a better compromise than > conflicting with DKIM. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 12 17:27:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZ1m-0001wN-RL; Sun, 12 Mar 2006 17:27:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZ1m-0001wI-2p for ima@ietf.org; Sun, 12 Mar 2006 17:27:06 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIZ1m-0004Xt-1N for ima@ietf.org; Sun, 12 Mar 2006 17:27:06 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FIZ1l-00058K-EH for ima@ietf.org; Sun, 12 Mar 2006 17:27:05 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64BB52596F8 for ; Sun, 12 Mar 2006 23:25:24 +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 31556-06 for ; Sun, 12 Mar 2006 23:25:20 +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 3E8BB2596F7 for ; Sun, 12 Mar 2006 23:25:20 +0100 (CET) Date: Sun, 12 Mar 2006 23:27:05 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: -1.5 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [IEE] Proposed Agenda for IMA BOF, Monday X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Agenda for EAI BOF, Dallas IETF Monday afternoon session I - 1740--1950 (opposite PANA SHIM6 XCON RTGAREA SMIME PMTUD ASRG PKIX). 17:40 Welcome, blue sheet, scribe, agenda bashing 17:50 Review of WG proposal status say whether we're a WG or not, review charter changes 17:55 Problem/framing: What are the constraints on the problem we're trying to solve? Input documents: draft-alvestrand-i18mail-scenarios draft-klensin-ima-constraints 18:15 Solution: What are the properties of our proposed solution? Authors get 2 minutes each to introduce their doc, then we'd like to give 13 minutes for people to raise issues. Input documents: 18:15 draft-klensin-ima-framework 18:30 draft-yeh-ima-utf8headers 18:45 draft-yao-ima-smtpext 19:00 draft-yoneya-ima-downgrade 19:15 draft-newman-ima-pop 19:30 The partition issue: The claim has been made on the mailing list that changing the form of Internet mail addresses will partition email space unless gateways are part of the core standard. We should discuss this issue explicitly. 19:45 Conclusions, further work and wrap-up 19:50 End _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 17 10:17:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGhF-00077B-Oe; Fri, 17 Mar 2006 10:16:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGhF-000773-Cz; Fri, 17 Mar 2006 10:16:57 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGhF-0001nw-40; Fri, 17 Mar 2006 10:16:57 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2HFGs9W025026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 15:16:54 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FKGhC-00028o-RV; Fri, 17 Mar 2006 10:16:54 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Fri, 17 Mar 2006 10:16:54 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ima@ietf.org Subject: [IEE] WG Action: Email Address Internationalization (eai) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Email Address Internationalization (eai) ========================================== Current Status: Active Working Group Chair(s): Harald Alvestrand Applications Area Director(s): Ted Hardie Scott Hollenbeck Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ima@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ima Archive: http://www1.ietf.org/mail-archive/web/ima/index.html Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Goals and Milestones: Done Overview/architecture draft first Done Interworking scenarios first draft Done SMTP Extensions first draft Done Header format first draft Mar 2006 Downgrading in SMTP first draft Mar 2006 Downgrading in POP first draft Mar 2006 Downgrading in IMAP first draft Jun 2006 Overview/architecture draft to IESG Jun 2006 Interworking scenarios to IESG Sep 2006 SMTP Extensions to IESG Sep 2006 Header format to IESG Sep 2006 Downgrading in SMTP to IESG Sep 2006 Downgrading in POP to IESG Sep 2006 Downgrading in IMAP to IESG Dec 2006 Results and evaluation first draft Mar 2007 Results and evaluation to IESG Mar 2007 Group recharter for standards track _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 17 10:24:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGoG-0004Em-QR; Fri, 17 Mar 2006 10:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGoF-0004BM-OX for ima@ietf.org; Fri, 17 Mar 2006 10:24:11 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGoE-0002GB-FF for ima@ietf.org; Fri, 17 Mar 2006 10:24:11 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57D3F259719 for ; Fri, 17 Mar 2006 16:22:26 +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 14070-03 for ; Fri, 17 Mar 2006 16:22:23 +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 F392125970F for ; Fri, 17 Mar 2006 16:22:22 +0100 (CET) Date: Fri, 17 Mar 2006 16:24:13 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) 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: 7bac9cb154eb5790ae3b2913587a40de Subject: [IEE] We're now a working group.... X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As you saw from today's announcement, we are now officially a working group. This doesn't make much of a practical difference - but it DOES mean that we don't have to discuss what the WG should do any more; we can concentrate on doing it. See a lot of you in Dallas! Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 19 02:58:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKsna-0005Xr-4p; Sun, 19 Mar 2006 02:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKsnZ-0005VG-D9 for ima@ietf.org; Sun, 19 Mar 2006 02:58:01 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKsnF-0003KY-JK for ima@ietf.org; Sun, 19 Mar 2006 02:57:43 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2J7vHd23089; Sun, 19 Mar 2006 16:57:17 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 55f9_fc27b75a_b71d_11da_93d0_0014221f2a2d; Sun, 19 Mar 2006 16:57:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k2J7tCK1008249; Sun, 19 Mar 2006 16:56:41 +0900 Message-Id: <6.0.0.20.2.20060319163739.09c90440@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 19 Mar 2006 16:38:35 +0900 To: Harald Tveit Alvestrand , ima@ietf.org From: Martin Duerst Subject: Re: [IEE] We're now a working group.... In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello Harald, Great! Thanks for all your work. Any chance that we can reduce the number of acronyms from three (ima, iee, eai) to two (ima, eai)? Regards, Martin. At 00:24 06/03/18, Harald Tveit Alvestrand wrote: >As you saw from today's announcement, we are now officially a working group. > >This doesn't make much of a practical difference - but it DOES mean that we don't have to discuss what the WG should do any more; we can concentrate on doing it. > >See a lot of you in Dallas! > > Harald > > >_______________________________________________ >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 Sun Mar 19 08:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKxWG-0003XT-Jt; Sun, 19 Mar 2006 08:00:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKxWD-0003VA-Or for ima@ietf.org; Sun, 19 Mar 2006 08:00:25 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKxWD-0001T9-Fi for ima@ietf.org; Sun, 19 Mar 2006 08:00:25 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A711259706; Sun, 19 Mar 2006 13:58:40 +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 30726-04; Sun, 19 Mar 2006 13:58:36 +0100 (CET) Received: from [130.129.129.255] (unknown [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45900259705; Sun, 19 Mar 2006 13:58:36 +0100 (CET) Message-ID: <441D55E5.9030901@alvestrand.no> Date: Sun, 19 Mar 2006 14:00:21 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst References: <6.0.0.20.2.20060319163739.09c90440@localhost> In-Reply-To: <6.0.0.20.2.20060319163739.09c90440@localhost> 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: cf4fa59384e76e63313391b70cd0dd25 Cc: ima@ietf.org Subject: [EAI] Re: [IEE] We're now a working group.... 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 wrote: > Hello Harald, > > Great! Thanks for all your work. > > Any chance that we can reduce the number of acronyms from three > (ima, iee, eai) to two (ima, eai)? don't forget i18mail, imaa and a lot of other acronyms that have been used..... I think we could rename the mailing list in addition to changing the subject tag, leaving us with eai as the name for the effort. I have a linking for i18mail as a name for the technology, since that's easier to remember - EAI has zero mnemonic value.... Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 19 08:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKy39-000815-NA; Sun, 19 Mar 2006 08:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKy38-000810-7q for ima@ietf.org; Sun, 19 Mar 2006 08:34:26 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKy36-0002hu-FR for ima@ietf.org; Sun, 19 Mar 2006 08:34:26 -0500 Received: (snipe 24280 invoked by uid 0); 19 Mar 2006 22:34:24 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 2.147528 secs); Received: from unknown (HELO ?172.16.69.180?) (Z???own@60.253.64.1) by unknown with SMTP; 19 Mar 2006 22:34:22 +0900 X-RCPTTO: ima@ietf.org Message-ID: <441D5DD4.1080507@icu.ac.kr> Date: Sun, 19 Mar 2006 22:34:12 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Re: [IEE] We're now a working group.... References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> In-Reply-To: <441D55E5.9030901@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Harald Alvestrand wrote: > > Martin Duerst wrote: >> Hello Harald, >> >> Great! Thanks for all your work. >> >> Any chance that we can reduce the number of acronyms from three >> (ima, iee, eai) to two (ima, eai)? > don't forget i18mail, imaa and a lot of other acronyms that have been > used..... I think we could rename the mailing list in addition to > changing the subject tag, leaving us with eai as the name for the effort. > > I have a linking for i18mail as a name for the technology, since > that's easier to remember - EAI has zero mnemonic value.... To make the matters worse, EAI is fairly commonly used as an acronym of Enterprise Application Integration. > > Harald > > > _______________________________________________ > 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 Sun Mar 19 11:12:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0WG-0001ld-Kb; Sun, 19 Mar 2006 11:12:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0WF-0001lY-Fo for ima@ietf.org; Sun, 19 Mar 2006 11:12:39 -0500 Received: from nic-naa.net ([65.99.1.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0WE-0007pN-7t for ima@ietf.org; Sun, 19 Mar 2006 11:12:39 -0500 Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.13.4/8.13.4) with ESMTP id k2JGAd8D042645; Sun, 19 Mar 2006 11:10:39 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200603191610.k2JGAd8D042645@nic-naa.net> To: Yangwoo Ko Subject: Re: [EAI] Re: [IEE] We're now a working group.... In-reply-to: <441D5DD4.1080507@icu.ac.kr> References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> <441D5DD4.1080507@icu.ac.kr> Comments: In-reply-to Yangwoo Ko message dated "Sun, 19 Mar 2006 22:34:12 +0900." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42643.1142784639.1@nic-naa.net> Date: Sun, 19 Mar 2006 11:10:39 -0500 From: Eric Brunner-Williams X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 unfortunately, "i18" as in "i18n" isn't technology specific. as this w.g. is, of necessity, being an ietf chartered w.g., it is technology specific. a meaningless name is better than one that means something that isn't what is actually ment. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 19 11:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0YD-0001zj-ED; Sun, 19 Mar 2006 11:14:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0YC-0001zZ-11 for ima@ietf.org; Sun, 19 Mar 2006 11:14:40 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0YA-0007rO-K4 for ima@ietf.org; Sun, 19 Mar 2006 11:14:40 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE084259705; Sun, 19 Mar 2006 17:12: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 02932-10; Sun, 19 Mar 2006 17:12:49 +0100 (CET) Received: from [130.129.129.255] (unknown [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3A3C259703; Sun, 19 Mar 2006 17:12:48 +0100 (CET) Message-ID: <441D836A.6040104@alvestrand.no> Date: Sun, 19 Mar 2006 10:14:34 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Eric Brunner-Williams Subject: Re: [EAI] Re: [IEE] We're now a working group.... References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> <441D5DD4.1080507@icu.ac.kr> <200603191610.k2JGAd8D042645@nic-naa.net> In-Reply-To: <200603191610.k2JGAd8D042645@nic-naa.net> 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: d17f825e43c9aed4fd65b7edddddec89 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 Eric Brunner-Williams wrote: > unfortunately, "i18" as in "i18n" isn't technology specific. > > as this w.g. is, of necessity, being an ietf chartered w.g., it is technology > specific. > > a meaningless name is better than one that means something that isn't what > is actually ment. i18mail is somewhat technology specific... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 19 11:46:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL13G-0004b3-8y; Sun, 19 Mar 2006 11:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL13F-0004ay-7q for ima@ietf.org; Sun, 19 Mar 2006 11:46:45 -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 1FL13C-0000Wi-DS for ima@ietf.org; Sun, 19 Mar 2006 11:46:45 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FL137-000C9L-Dk; Sun, 19 Mar 2006 11:46:38 -0500 Date: Sun, 19 Mar 2006 09:15:51 -0500 From: John C Klensin To: dcrocker@bbiw.net Message-ID: <90379ED3D35FCA893C6A8DDF@7AD4D3FB4841A5E367CCF211> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ima@ietf.org Subject: [EAI] i18n Addressing and Fragmentation of the email infrastructure 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 Dave, I've been trying to figure out how to address your concern, voiced several times and in different ways, that the approach being contemplated in this WG inherently breaks the infrastructure, that it fragments the email network, and that I, and others, are insensitive or indifferent to those issues. If that is not a correct summary of your position and concern, I apologize -- it is, at least, the impression I'm left with after several readings of a number of your notes. To get the other issue on the table in the hope that, once exposed, we and the community generally can move beyond it, I personally take the issue seriously enough that I've been trying for some years to engage the question of ways to get full internationalization without giving non-ASCII users less functionality than those who operate entirely within an ASCII environment. I've been involved in innumerable discussions on the subject and large numbers of explorations of how it might be done. I haven't avoided any discussion on that topic that has been able to be conducted among parties who appear to be willing to work together to find solutions. I wish there were a magic solution that would install seamlessly without changes in the existing mail system, but such a solution appears to require a quantity of pixie dust that just is not available. This leaves us with a classic engineering problem in which, rather than find a perfect solution, we need to look at the intersection of possible constraint spaces and solutions spaces, analyze and balance the tradeoffs, and then try to find something that works. If, for example, we apply the constraints that (i) no i18n email approach is acceptable if it could result in a situation in which someone who has only an address in one script will be unable to communicate with someone who has an address only in a different non-ASCII script and (ii) users of non-ASCII addresses must have all of the functionality available to them that is traditional for users of all-ASCII addresses, then it is basically over: the only "solution" is to retain ASCII-only addressing forever, relying on encoded words or the equivalent to express names or terms that cannot be accurately rendered in ASCII characters. While it has gotten more refined over time, the reasoning behind that startling conclusion appears in my early internationalized addressing I-Ds, now well over two years old. An overview of it appears in draft-klensin-ima-framework and a different perspective on it, in far more depth than I intend to repeat in this note, appears in the more recent draft-klensin-ima-constraints. As I indicated above, we've certainly been looking at the issues and doing so carefully and for a fairly extended time. Viewed on way, that conclusion gives us a choice of options that could create islands within the email environment that can't communicate. Clearly, that is not a desirable state of affairs, but, again, it appears that the choice is among types and sources of islands, not whether islands will exist. One sort of island-development occurs if we simply do nothing. There is considerable demand for internationalized email addresses. The level of that demand is likely to become much higher than the demand was for IDNs and is, IMO, far more legitimate (see the drafts cited above for more details on that claim). With the right selection of MTAs, MUAs, and mail-accessing protocol implementations --ones that depart "only a little bit" from the standards and that are trivially modified to do so-- approaches analogous to the "just send 8" approaches we needed to overcome with MIME are quite plausible. In some ways, those approaches are more plausible now then they were a decade ago because one can say "just send UTF-8" and hope for universal acceptance, rather than having a nasty problem with choices of character sets and labels. If we do nothing, we will almost certainly see deployment of solutions along those lines. And, as with "just send 8", they will certainly cause serious interoperability problems as subtly different i18n address and header forms hit MTAs and MUAs that are not prepared to deal with them and do so without agreement or even warning. "Just say no" is not a realistic option here, any more than it was a realistic option with IDNs or, for that matter, the basic multiple-script and multimedia functionality that MIME enabled. Our advantage over IDN is that a larger fraction of the community has come to understand that "any solution, as long as it is quick" is not a good way to do protocol design: we actually have the option of examining and balancing tradeoffs here... and I suggest we are obligated to do just that. A second type of island-building involves, from at least one perspective, exactly what we did with MIME, only moved out to the transport level (of necessity). From that perspective, MIME doesn't provide global interoperability. Instead, it provides a safe and controlled form of non-interoperability. None of us who advocate and support MIME like to think about it that way but, if I send you a body part that is identified with a content type that you, and the tools you have available, have never heard of, then we just are not going to interoperate. MIME gives us the considerable advantage of knowing that a particular body part cannot be processed but it doesn't intrinsically provide any mechanisms for ensuring that it can be processed. In practice, if one looks at both the MIME-aware and non-MIME-aware implementations out there, there is only one content-type that is substantially guaranteed to be implemented and supported globally and that is plain, ordinary, legacy, ASCII text with relatively short lines. For everything else, maybe it is supported and maybe it is not supported, but what MIME provides is only a clear indication of the type so that an unambiguous decision can be made about whether support is available (I note that we have compromised even that principle in recent years, but that is a different discussion). If we take that logic and the constraint set it implies, back to the i18n email solution space, the conclusion we (the design team that put the framework for this WG together) have reached is that, absent a desire on the part of all users of i18n email to interoperate with traditional, all-ASCII, email users --a desire that extends to accepting a certain amount of inconvenience-- there will be islands. Our task then becomes to make the islands acceptable: to be sure that having i18n addresses or headers on the Internet doesn't blow up unsuspecting older systems and to be sure that "downgrading" mechanisms or arrangements are available at appropriate points in the infrastructure for those who are willing to go to the trouble. Note here that, as far as we have been able to tell, even encapsulation doesn't give us clean, easy, and universal in-flight downgrades: the message/rfc822 is limited to ASCII and the double-encoding rule prevents encapsulating something that might already be encapsulated, so we will almost certainly need a new content-type and body part to accomplish the encapsulation. Because non-upgraded receiving programs will presumably not understand that new type, it will provide, in essence, a tunnel to nowhere for those cases ... a different way to have two systems on the Internet not communicate with each other, but a way nonetheless. This isn't easy. All of us who have been trying to find an approach that works with minimal risk of damage or unanticipated side effects know it isn't easy. I hope, I think we all hope, that the IETF community, especially the community of experts on email, will work with us to identify the tradeoffs and risks and to find a good balance among them rather than getting diverted into arguments about which approaches can be labeled as "fragmenting" or "creating a new infrastructure". john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 19 12:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL1Uz-0008Eh-H3; Sun, 19 Mar 2006 12:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL1Uy-0008Ec-9m for ima@ietf.org; Sun, 19 Mar 2006 12:15:24 -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 1FL1Uw-0001sr-VL for ima@ietf.org; Sun, 19 Mar 2006 12:15:24 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FL1Uv-000CCo-Os; Sun, 19 Mar 2006 12:15:22 -0500 Date: Sun, 19 Mar 2006 12:15:20 -0500 From: John C Klensin To: Harald Alvestrand , Eric Brunner-Williams Subject: Re: [EAI] Re: [IEE] We're now a working group.... Message-ID: In-Reply-To: <441D836A.6040104@alvestrand.no> References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> <441D5DD4.1080507@icu.ac.kr> <200603191610.k2JGAd8D042645@nic-naa.net> <441D836A.6040104@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 --On Sunday, March 19, 2006 10:14 -0600 Harald Alvestrand wrote: > Eric Brunner-Williams wrote: >> unfortunately, "i18" as in "i18n" isn't technology specific. >> >> as this w.g. is, of necessity, being an ietf chartered w.g., >> it is technology specific. >> >> a meaningless name is better than one that means something >> that isn't what is actually ment. > i18mail is somewhat technology specific... and, if it doesn't violate some Secretariat length-of-name rule, "i18nemail" is even more so. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 19 15:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4VP-0007CY-NA; Sun, 19 Mar 2006 15:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4VO-0007CT-SB for ima@ietf.org; Sun, 19 Mar 2006 15:28:02 -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 1FL4VN-0000uX-Ib for ima@ietf.org; Sun, 19 Mar 2006 15:28:02 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FL4VK-000Cax-8S; Sun, 19 Mar 2006 15:27:58 -0500 Date: Sun, 19 Mar 2006 15:27:57 -0500 From: John C Klensin To: Harald Alvestrand , Martin Duerst Subject: Re: [EAI] Re: [IEE] We're now a working group.... Message-ID: In-Reply-To: <441D55E5.9030901@alvestrand.no> References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 --On Sunday, March 19, 2006 14:00 +0100 Harald Alvestrand wrote: > Martin Duerst wrote: >> Hello Harald, >> >> Great! Thanks for all your work. >> >> Any chance that we can reduce the number of acronyms from >> three (ima, iee, eai) to two (ima, eai)? > don't forget i18mail, imaa and a lot of other acronyms that > have been used..... I think we could rename the mailing list > in addition to changing the subject tag, leaving us with eai > as the name for the effort. > > I have a linking for i18mail as a name for the technology, > since that's easier to remember - EAI has zero mnemonic > value.... And some name-conflict issues as well. Entering "EAI" into Google is enlightening and a fairly good argument for something else. And my candidate at this point is i18nmail or i18nemail (no preference between them). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 02:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEaJ-00088Z-GC; Mon, 20 Mar 2006 02:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEaI-00088U-F5 for ima@ietf.org; Mon, 20 Mar 2006 02:13:46 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLEaH-00062A-GC for ima@ietf.org; Mon, 20 Mar 2006 02:13:46 -0500 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2K7Di8u014652 for ; Mon, 20 Mar 2006 00:13:44 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWE00G01X89BO00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 20 Mar 2006 00:13:44 -0700 (MST) Received: from 186.114.96.204.in-addr.arpa ([204.96.114.186]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWF004KI02TE100@mail-amer.sun.com> for ima@ietf.org; Mon, 20 Mar 2006 00:13:44 -0700 (MST) Date: Mon, 20 Mar 2006 01:15:41 -0600 From: Chris Newman To: ima@ietf.org Message-id: <2AB9B5F3FEE050F85AC9BEDC@186.114.96.204.in-addr.arpa> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 1.5 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [EAI] silly states and header label 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 One thing I dislike more and more as time goes on is silly states: when two elements in a protocol provide contradictory information. Whenever possible I prefer to design silly states out of the protocol. Suppose we have no way to label a UTF-8 header message. We now have three cases the code has to deal with: 1. The header is pure 7-bit. 2. The header is 8-bit and complies with UTF-8 syntax. 3. The header is 8-bit and does not comply with UTF-8 syntax. We don't need to talk much about 3, but it does permit software to bounce certain non-standard behaviors or gateway them into something more reasonable. I assert the code to validate 2 need not be particularly expensive. Indeed, I'll include a high-performance version of the code at the end of this message to prove my point. The problem I have with a header to declare message type is that changes from three cases to six cases, at least two of which are silly states. And since headers can be re-ordered it's still necessary to scan all the headers to find the label, so I don't see how the benefits (detection) can outweigh the costs (doubling the number of cases to deal with). Were I writing code, I'd ignore the label, just as I ignore the MIME-Version header (which is only helpful as a hint if one supports RFC 1049). If we must use a labeling mechanism, I suggest using a zero-width non-joiner UTF-8 character at the beginning of the message. UTF-8 aware SMTP servers are required to insert Received and Return-Path after the zero-width non-joiner character. That has some other nice features -- it permits instant detection of the encoding for certain out-of-band mechanisms (e.g. UTF-8 editors), it has no impact on display, and if the message gets to a non-8-bit system the failure is likely to be immediate and more obvious rather than later and more obscure (indeed it's so obvious that legacy systems can be patched to check for it easily). I'm still not sure those benefits outweigh the cost of silly states, but it's closer to making the cut. - Chris ----- UTF-8 detection: /* a UTF8 lookup table */ #define EXT 0x20 #define BAD 0x40 #define SP 0x10 static unsigned char utf8_table[256] = { /* 0x00 */ BAD, 1, 1, 1, 1, 1, 1, 1, /* 0x08 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x10 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x18 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x20 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x28 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x30 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x38 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x40 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x48 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x50 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x58 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x60 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x68 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x70 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x78 */ 1, 1, 1, 1, 1, 1, 1, 1, /* 0x80 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0x88 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0x90 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0x98 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0xA0 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0xA8 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0xB0 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0xB8 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT, /* 0xC0 */ BAD, BAD, 2, 2, 2, 2, 2, 2, /* 0xC8 */ 2, 2, 2, 2, 2, 2, 2, 2, /* 0xD0 */ 2, 2, 2, 2, 2, 2, 2, 2, /* 0xD8 */ 2, 2, 2, 2, 2, 2, 2, 2, /* 0xE0 */ SP|3, 3, 3, 3, 3, 3, 3, 3, /* 0xE8 */ 3, 3, 3, 3, 3, SP|3, 3, 3, /* 0xF0 */ SP|4, 4, 4, 4, SP|4, BAD, BAD, BAD, /* 0xF8 */ BAD, BAD, BAD, BAD, BAD, BAD, BAD, BAD }; /* verify a string is valid UTF-8 and doesn't contain NUL * if len < 0, strlen(str) will be used. * returns -1 if not valid, 0 if valid */ int utf8verify(const char *str, int len) { int state = 0, code; const char *end; unsigned char u1, u2; if (len < 0) len = strlen(str); end = str + len; while (str < end && (code = utf8_table[(unsigned char)*str]) != BAD) { if ((state == 0 && code == EXT) || (state > 0 && code != EXT)) { return (-1); } if ((state & SP) != 0) { state &= ~SP; u1 = (unsigned char) str[-1]; u2 = (unsigned char) str[0]; if ((u1 == 0xE0U && u2 < 0xA0U) || (u1 == 0xEDU && u2 > 0x9FU) || (u1 == 0xF0U && u2 < 0x90U) || (u1 == 0xF4U && u2 > 0x8FU)) { return (-1); } } if (code != EXT) { state = code; } --state; ++str; } return (str == end && state == 0 ? 0 : -1); } #undef SP _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 03:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFcW-0004kL-QG; Mon, 20 Mar 2006 03:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFcV-0004jR-Qx for ima@ietf.org; Mon, 20 Mar 2006 03:20:07 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFcU-00083L-EX for ima@ietf.org; Mon, 20 Mar 2006 03:20:07 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2K8K5Qj028437 for ; Mon, 20 Mar 2006 01:20:05 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWF00E0135G6800@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 20 Mar 2006 01:20:04 -0700 (MST) Received: from 186.114.96.204.in-addr.arpa ([204.96.114.186]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWF002IE35C1L00@mail-amer.sun.com> for ima@ietf.org; Mon, 20 Mar 2006 01:20:04 -0700 (MST) Date: Mon, 20 Mar 2006 02:22:01 -0600 From: Chris Newman To: ima@ietf.org Message-id: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 1.5 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [EAI] ATOMIC parameter 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 Although I'm sympathetic to the motivations behind the ATOMIC parameter, I believe it is an incorrect bias of protocol purity over operational robustness. As a matter of operational robustness it is almost always better to move questionable email material forward than to bounce it. If the recipient gets something that appears to be corrupt, they will contact the sender to resend the material. If the message is important, the recipient will probably have out-of-band mechanisms to contact the sender that are more likely to work than the MAIL FROM address (e.g. a cell phone number, etc). On the flip side, it is quite easy to mis-configure the MAIL FROM address and the problem probably won't be noticed unless the person who did so gets a complaint from a colleague which will only happen if the message moves forward and the colleague's attempt to reply fails. We also have widely deployed systems that do inappropriate things with MAIL FROM that can cause loops or other badness when a bounce happens. And in the new world of Spam blowback, many people simply ignore almost all bounces (myself included, unfortunately). This is very unfortunate for those of us who care a great deal about protocol purity. It's really painful to pass non-interoperable junk forward but the outcome for the users involved is more likely to be better, so it's usually the right thing to do. Which brings us to the ATOMIC parameter. We all like the rule which forbids local part interpretation by remote systems and I respect the ATOMIC parameter approach as a clever way to preserve that rule. Unfortunately, ATOMIC=no leaves MTAs in an untenable situation: either ignore the standard, downconvert and pass forward or bounce. Unfortunately, robustness suggests the right answer is to ignore the standard. Were I implementing a system, I'd probably ignore the standard for this case by default and include an option to follow the standard. But having "do the right thing for users" and "comply with the standard" as two separate settings is not something I like (how often do people use the "strict ANSI" option on their C compiler?). Use of a UTF-8 local part should implicitly grant permission to use the 7-bit-encoded alias of that local part. This is not significantly different from the rule that list-addr@example.com implies the existence of list-addr-request@example.com and the converse is true. Furthermore, if someone wants to use structured UTF-8 addresses for special processing and do so while interacting with a 7-bit-only system, I believe it's reasonable to insist they upgrade their special processing system to remove the 7-bit encoding prior to processing. And as much as I like sub-addresses, their use is simply not widespread enough to merit additional design complexity simply to avoid requiring up-conversion at that point in the system. Finally, down-conversion is a non-negotiable feature for some implementers (myself included). I have to be able to down-convert the UTF-8 local parts in the headers, even if an alternate address is unavailable (and it doesn't change things if the spec requires an alternate address be available, as we still have to deal with the non-compliant case in quality software). So I suggest ATOMIC=yes should be implicit from the use of UTF-8 and thus not necessary to include in the protocol specification. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 11:01:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMop-0002F5-SS; Mon, 20 Mar 2006 11:01:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMoo-0002Ex-Tj; Mon, 20 Mar 2006 11:01:18 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMok-0007b3-C1; Mon, 20 Mar 2006 11:01:18 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17C0B2596E4; Mon, 20 Mar 2006 16:59:28 +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 12481-07; Mon, 20 Mar 2006 16:59:19 +0100 (CET) Received: from [130.129.129.255] (DHCP-Wireless-129-255.ietf65.org [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id 576EC2596F1; Mon, 20 Mar 2006 16:59:18 +0100 (CET) Message-ID: <441ED1C0.9020400@alvestrand.no> Date: Mon, 20 Mar 2006 10:01:04 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org, ipr-wg@ietf.org Content-Type: multipart/mixed; boundary="------------010506020809010700020707" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [EAI] [Fwd: Audio Info] 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. --------------010506020809010700020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Making sure my WGs have seen this..... --------------010506020809010700020707 Content-Type: message/rfc822; name="Audio Info" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Audio Info" 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; Mon, 20 Mar 2006 14:54:31 +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 28C432596F4 for ; Mon, 20 Mar 2006 14:54:31 +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 08782-08 for ; Mon, 20 Mar 2006 14:54:24 +0100 (CET) X-Greylist: domain auto-whitelisted by SQLgrey-1.6.7 Received: from megatron.ietf.org (megatron.ietf.org [156.154.16.145]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A2E22596EE for ; Mon, 20 Mar 2006 14:54:24 +0100 (CET) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKr6-0005AT-Tc; Mon, 20 Mar 2006 08:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKr4-0005AL-UF for ietf@ietf.org; Mon, 20 Mar 2006 08:55:30 -0500 Received: from mserv2.uoregon.edu ([128.223.142.41] helo=smtp.uoregon.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKr3-0002lt-IF for ietf@ietf.org; Mon, 20 Mar 2006 08:55:30 -0500 Received: from uoregon.edu (geoduck.uoregon.edu [128.223.142.113]) by smtp.uoregon.edu (8.13.5/8.13.5) with ESMTP id k2KDtSnH029284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Mar 2006 05:55:28 -0800 Received: from localhost (llynch@localhost) by uoregon.edu (8.13.1/8.13.1/Submit) with ESMTP id k2KDtSmO030311 for ; Mon, 20 Mar 2006 05:55:28 -0800 X-Authentication-Warning: geoduck.uoregon.edu: llynch owned process doing -bs Date: Mon, 20 Mar 2006 05:55:28 -0800 (PST) From: "Lucy E. Lynch" X-X-Sender: llynch@geoduck.uoregon.edu To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1345/Mon Mar 20 04:03:16 2006 on mserv2 X-Virus-Status: Clean X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: Audio Info X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no All - Information on the audio from the rooms can be found at: http://videolab.uoregon.edu/events/ietf/ or you can go th http://www.ietf65.org and find a link to the audio services on the top level page. -- Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --------------010506020809010700020707 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 --------------010506020809010700020707-- From ima-bounces@ietf.org Mon Mar 20 11:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN5y-0007xX-4y; Mon, 20 Mar 2006 11:19:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN5w-0007xS-SN for ima@ietf.org; Mon, 20 Mar 2006 11:19:00 -0500 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLN5u-000051-Ck for ima@ietf.org; Mon, 20 Mar 2006 11:19:00 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-124.messagelabs.com!1142871530!8194964!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2000 invoked from network); 20 Mar 2006 16:18:52 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-124.messagelabs.com with SMTP; 20 Mar 2006 16:18:52 -0000 Received: from [135.70.80.181] (unknown[135.70.80.181](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060320161849gw1001008de> (Authid: tony); Mon, 20 Mar 2006 16:18:49 +0000 Message-ID: <441ED5E6.7070208@att.com> Date: Mon, 20 Mar 2006 11:18:46 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] ATOMIC parameter References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> In-Reply-To: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 +1 Chris Newman wrote: > Although I'm sympathetic to the motivations behind the ATOMIC parameter, > I believe it is an incorrect bias of protocol purity over operational > robustness. > ... > > Use of a UTF-8 local part should implicitly grant permission to use the > 7-bit-encoded alias of that local part. ... > > Finally, down-conversion is a non-negotiable feature for some > implementers (myself included). I have to be able to down-convert the > UTF-8 local parts in the headers, even if an alternate address is > unavailable (and it doesn't change things if the spec requires an > alternate address be available, as we still have to deal with the > non-compliant case in quality software). So I suggest ATOMIC=yes should > be implicit from the use of UTF-8 and thus not necessary to include in > the protocol specification. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 11:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN6z-00089D-Il; Mon, 20 Mar 2006 11:20:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN6y-000898-B2 for ima@ietf.org; Mon, 20 Mar 2006 11:20:04 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLN6w-00006c-Js for ima@ietf.org; Mon, 20 Mar 2006 11:20:04 -0500 Received: (snipe 20021 invoked by uid 0); 21 Mar 2006 01:19:58 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.928716 secs); Received: from unknown (HELO ?130.129.131.189?) (Z?h?own@130.129.131.189) by unknown with SMTP; 21 Mar 2006 01:19:57 +0900 X-RCPTTO: Chris.Newman@Sun.COM, ima@ietf.org Message-ID: <441ED62B.3040406@icu.ac.kr> Date: Tue, 21 Mar 2006 01:19:55 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chris Newman Subject: Re: [EAI] ATOMIC parameter References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> In-Reply-To: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Dear Chris Newman, We should consider how much standards can constraint real implementations. If we can safely assume that all implementations will execute some procedures in the exactly same order that authors of a specification had in their minds, it might be quite wonderful. However, as you pointed out, developers of quality software will intentionally deviate from standard. (I would like to call it deviation rather than ignorance.) And that will invalidate the previous assumption. In that sense, it is painful to accept this though, standard is just a median point from which implementations can deviate from and provides the least common ground when two different deviations want to communication with each other. Chris Newman wrote: > Which brings us to the ATOMIC parameter. We all like the rule which > forbids local part interpretation by remote systems and I respect the > ATOMIC parameter approach as a clever way to preserve that rule. > Unfortunately, ATOMIC=no leaves MTAs in an untenable situation: either > ignore the standard, downconvert and pass forward or bounce. > Unfortunately, robustness suggests the right answer is to ignore the > standard. Were I implementing a system, I'd probably ignore the > standard for this case by default and include an option to follow the > standard. But having "do the right thing for users" and "comply with > the standard" as two separate settings is not something I like (how > often do people use the "strict ANSI" option on their C compiler?). > > Use of a UTF-8 local part should implicitly grant permission to use > the 7-bit-encoded alias of that local part. This is not significantly > different from the rule that list-addr@example.com implies the > existence of list-addr-request@example.com and the converse is true. > Furthermore, if someone wants to use structured UTF-8 addresses for > special processing and do so while interacting with a 7-bit-only > system, I believe it's reasonable to insist they upgrade their special > processing system to remove the 7-bit encoding prior to processing. > And as much as I like sub-addresses, their use is simply not > widespread enough to merit additional design complexity simply to > avoid requiring up-conversion at that point in the system. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 11:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLND7-0004km-FI; Mon, 20 Mar 2006 11:26:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLND5-0004jS-RL for ima@ietf.org; Mon, 20 Mar 2006 11:26:23 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLND4-0000Kg-CT for ima@ietf.org; Mon, 20 Mar 2006 11:26:23 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 244052596F4; Mon, 20 Mar 2006 17:24: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 13289-03; Mon, 20 Mar 2006 17:24:32 +0100 (CET) Received: from [130.129.129.255] (DHCP-Wireless-129-255.ietf65.org [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DCA32596EE; Mon, 20 Mar 2006 17:24:31 +0100 (CET) Message-ID: <441ED7A9.1080706@alvestrand.no> Date: Mon, 20 Mar 2006 10:26:17 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [EAI] ATOMIC parameter References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> <441ED62B.3040406@icu.ac.kr> In-Reply-To: <441ED62B.3040406@icu.ac.kr> 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: 97adf591118a232206bdb5a27b217034 Cc: 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 Yangwoo Ko wrote: > > Dear Chris Newman, > > We should consider how much standards can constraint real > implementations. If we can safely assume that all implementations will > execute some procedures in the exactly same order that authors of a > specification had in their minds, it might be quite wonderful. > However, as you pointed out, developers of quality software will > intentionally deviate from standard. (I would like to call it > deviation rather than ignorance.) And that will invalidate the > previous assumption. In that sense, it is painful to accept this > though, standard is just a median point from which implementations can > deviate from and provides the least common ground when two different > deviations want communication with each other. actually the standard does slightly more than this; if the standard "works", it gives assurance that all parties following the standard are able to communicate in providing the given function. thus, when someone deviates from the standard, they take on the responsibility of proving that their deviation does not harm interoperability; if interoperability is harmed, it is the responsibility of the implementation deviating from the standard. People remember this, and may consider it when doing buying decisions later - the hope is that people's buying decisions will eventually cause the "deviants" to converge towards standard adherence. But of course, having that hope requires that one is an optimist :-) Our job as standards writers is to get to the first base: Specifying a standard that allows useful communication between conformant entities. Unless we have that, it's useless to ask people to conform to it. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 11:29:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNFx-0005ar-Gl; Mon, 20 Mar 2006 11:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNFv-0005am-Ui for ima@ietf.org; Mon, 20 Mar 2006 11:29:19 -0500 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLNFt-0000Ra-He for ima@ietf.org; Mon, 20 Mar 2006 11:29:19 -0500 Received: (eyou send program); Tue, 21 Mar 2006 00:29:05 +0800 Message-ID: <342872145.32306@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (159.226.7.246) by 159.226.7.145 with SMTP; Tue, 21 Mar 2006 00:29:05 +0800 Message-ID: <00ba01c64c3b$65027880$6b6412c6@YaoJK> From: "Yao Jiankang" To: "Chris Newman" , References: <342842820.25777@cnnic.cn> Subject: Re: [EAI] ATOMIC parameter Date: Tue, 21 Mar 2006 00:28:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 what you suggest is that "atmonic=no" is kept for use and "atmonic=yes" is removed. you mean that although atmonic value is not set, the default is "atmonic=y". only in the situation where the utf-8 email address can not be safely transformed to ACE, the atmonic value is set. is my understanding right? Yao Jiankang CNNIC ----- Original Message ----- From: "Chris Newman" To: Sent: Monday, March 20, 2006 4:22 PM Subject: [EAI] ATOMIC parameter > Although I'm sympathetic to the motivations behind the ATOMIC parameter, I > believe it is an incorrect bias of protocol purity over operational robustness. > > As a matter of operational robustness it is almost always better to move > questionable email material forward than to bounce it. If the recipient gets > something that appears to be corrupt, they will contact the sender to resend > the material. If the message is important, the recipient will probably have > out-of-band mechanisms to contact the sender that are more likely to work than > the MAIL FROM address (e.g. a cell phone number, etc). > > On the flip side, it is quite easy to mis-configure the MAIL FROM address and > the problem probably won't be noticed unless the person who did so gets a > complaint from a colleague which will only happen if the message moves forward > and the colleague's attempt to reply fails. We also have widely deployed > systems that do inappropriate things with MAIL FROM that can cause loops or > other badness when a bounce happens. And in the new world of Spam blowback, > many people simply ignore almost all bounces (myself included, unfortunately). > > This is very unfortunate for those of us who care a great deal about protocol > purity. It's really painful to pass non-interoperable junk forward but the > outcome for the users involved is more likely to be better, so it's usually the > right thing to do. > > Which brings us to the ATOMIC parameter. We all like the rule which forbids > local part interpretation by remote systems and I respect the ATOMIC parameter > approach as a clever way to preserve that rule. Unfortunately, ATOMIC=no > leaves MTAs in an untenable situation: either ignore the standard, downconvert > and pass forward or bounce. Unfortunately, robustness suggests the right > answer is to ignore the standard. Were I implementing a system, I'd probably > ignore the standard for this case by default and include an option to follow > the standard. But having "do the right thing for users" and "comply with the > standard" as two separate settings is not something I like (how often do people > use the "strict ANSI" option on their C compiler?). > > Use of a UTF-8 local part should implicitly grant permission to use the > 7-bit-encoded alias of that local part. This is not significantly different > from the rule that list-addr@example.com implies the existence of > list-addr-request@example.com and the converse is true. Furthermore, if > someone wants to use structured UTF-8 addresses for special processing and do > so while interacting with a 7-bit-only system, I believe it's reasonable to > insist they upgrade their special processing system to remove the 7-bit > encoding prior to processing. And as much as I like sub-addresses, their use > is simply not widespread enough to merit additional design complexity simply to > avoid requiring up-conversion at that point in the system. > > Finally, down-conversion is a non-negotiable feature for some implementers > (myself included). I have to be able to down-convert the UTF-8 local parts in > the headers, even if an alternate address is unavailable (and it doesn't change > things if the spec requires an alternate address be available, as we still have > to deal with the non-compliant case in quality software). So I suggest > ATOMIC=yes should be implicit from the use of UTF-8 and thus not necessary to > include in the protocol specification. > > - Chris > > > _______________________________________________ > 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 Mon Mar 20 15:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRIa-0000JW-2f; Mon, 20 Mar 2006 15:48:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRIY-0000Ip-VY for ima@ietf.org; Mon, 20 Mar 2006 15:48:18 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRIX-0002QI-51 for ima@ietf.org; Mon, 20 Mar 2006 15:48:18 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2KKmG8u029835 for ; Mon, 20 Mar 2006 13:48:16 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWG00G011JFQS00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 20 Mar 2006 13:48:16 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org (DHCP-Wireless-128-202.ietf65.org [130.129.128.202]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWG00E4T1SCLT00@mail-amer.sun.com>; Mon, 20 Mar 2006 13:48:16 -0700 (MST) Date: Mon, 20 Mar 2006 14:50:14 -0600 From: Chris Newman Subject: Re: [EAI] ATOMIC parameter In-reply-to: <441ED62B.3040406@icu.ac.kr> To: Yangwoo Ko Message-id: <0F991F721DB2F56CBFA169F1@dhcp-wireless-128-202.ietf65.org> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> <441ED62B.3040406@icu.ac.kr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Yangwoo Ko wrote on 3/21/06 1:19 +0900: > We should consider how much standards can constraint real implementations. If > we can safely assume that all implementations will execute some procedures in > the exactly same order that authors of a specification had in their minds, it > might be quite wonderful. However, as you pointed out, developers of quality > software will intentionally deviate from standard. (I would like to call it > deviation rather than ignorance.) And that will invalidate the previous > assumption. In that sense, it is painful to accept this though, standard is > just a median point from which implementations can deviate from and provides > the least common ground when two different deviations want to communication > with each other. My argument was worded a bit more subtle than it should have been. If a responsible implementer feels it is necessary to willfully violate the standard to provide better service to end users, that suggests there is a technical flaw in the standard. As Harald said, the only mandatory feature of a standard is that compliant implementations will interoperate to provide a useful service. But a standard is more successful if it is designed in such a way that more implementers will choose to comply by default. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 16:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRnX-0003Kt-UN; Mon, 20 Mar 2006 16:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRnX-0003Ko-3Y for ima@ietf.org; Mon, 20 Mar 2006 16:20:19 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLRnV-0004JT-Ce for ima@ietf.org; Mon, 20 Mar 2006 16:20:19 -0500 Received: (snipe 26215 invoked by uid 0); 21 Mar 2006 06:20:13 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.897543 secs); Received: from unknown (HELO ?130.129.131.189?) (Z???own@130.129.131.189) by unknown with SMTP; 21 Mar 2006 06:20:12 +0900 X-RCPTTO: Chris.Newman@Sun.COM, ima@ietf.org Message-ID: <441F1C81.7090209@icu.ac.kr> Date: Tue, 21 Mar 2006 06:20:01 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chris Newman Subject: Re: [EAI] ATOMIC parameter References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> <441ED62B.3040406@icu.ac.kr> <0F991F721DB2F56CBFA169F1@dhcp-wireless-128-202.ietf65.org> In-Reply-To: <0F991F721DB2F56CBFA169F1@dhcp-wireless-128-202.ietf65.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 The first impression when I heard the atomic idea is that most implementations and their users will tag email addresses as atomic=yes by default. If this is the case, atomic=no is very clear indication that local part should not processed at intermediate servers. Unless alternative address is specified, not trying to down-convert seems far more robust than trying to down-convert while expecting that final delivery MTA will up-convert before doing anything. Chris Newman wrote: > > Yangwoo Ko wrote on 3/21/06 1:19 +0900: >> We should consider how much standards can constraint real >> implementations. If >> we can safely assume that all implementations will execute some >> procedures in >> the exactly same order that authors of a specification had in their >> minds, it >> might be quite wonderful. However, as you pointed out, developers of >> quality >> software will intentionally deviate from standard. (I would like to >> call it >> deviation rather than ignorance.) And that will invalidate the previous >> assumption. In that sense, it is painful to accept this though, >> standard is >> just a median point from which implementations can deviate from and >> provides >> the least common ground when two different deviations want to >> communication >> with each other. > > My argument was worded a bit more subtle than it should have been. If > a responsible implementer feels it is necessary to willfully violate > the standard to provide better service to end users, that suggests > there is a technical flaw in the standard. > > As Harald said, the only mandatory feature of a standard is that > compliant implementations will interoperate to provide a useful > service. But a standard is more successful if it is designed in such > a way that more implementers will choose to comply by default. > > - Chris > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 17:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSnw-00089i-8d; Mon, 20 Mar 2006 17:24:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSnw-00089d-0Z for ima@ietf.org; Mon, 20 Mar 2006 17:24:48 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLSns-0006q9-9L for ima@ietf.org; Mon, 20 Mar 2006 17:24:47 -0500 Received: (snipe 7951 invoked by uid 0); 21 Mar 2006 07:24:42 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.575280 secs); Received: from unknown (HELO ?130.129.131.189?) (Z???own@130.129.131.189) by unknown with SMTP; 21 Mar 2006 07:24:42 +0900 X-RCPTTO: ima@ietf.org Message-ID: <441F2BA7.2010005@icu.ac.kr> Date: Tue, 21 Mar 2006 07:24:39 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org Subject: [EAI] Terminology issue References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> <441D5DD4.1080507@icu.ac.kr> <200603191610.k2JGAd8D042645@nic-naa.net> <441D836A.6040104@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 As pointed out in our framework document, we need to cleanup terminologies quite soon. Let me start to roll the ball. 1. Name for working scope -- (E)mail i18n vs. (e)mail address i18n vs. EAI The scope of work we are doing is (e)mail address i18n. However, current approach requires more than that (e.g. utf-8 encoding support at headers). Thus we may call it (e)mail i18n. However, this seems to be broader than what we are actually doing. I will choose (without any preference) to use EAI in the following paragraphs. 2. Name for resulting addresses -- IMA vs. i18(n)(e)mail address These are names for (e)mail addresses that are EAI-compliant. These addresses include old ASCII only addresses as well. At least for me (non English native), internationalized email address sound more natural than internationalization email address. Since I don't have any idea how to make "internationalized email address" shorter, I prefer to use IMA. (IEA?) 3. Name for resulting things (except addresses) For example, what will be the name for EAI-compliant mail contents? We may call them as internationalized mail contents though it is still broader than wanted. 4. Others There are several other terminologies (e.g. all-ASCII address) used in the documents discussed in this WG. I hope that if there were consensus on above terms, it could be easier to generate other terms based on them. Regards John C Klensin wrote: > > > > --On Sunday, March 19, 2006 10:14 -0600 Harald Alvestrand > wrote: > >> Eric Brunner-Williams wrote: >>> unfortunately, "i18" as in "i18n" isn't technology specific. >>> >>> as this w.g. is, of necessity, being an ietf chartered w.g., >>> it is technology specific. >>> >>> a meaningless name is better than one that means something >>> that isn't what is actually ment. >> i18mail is somewhat technology specific... > > and, if it doesn't violate some Secretariat length-of-name rule, > "i18nemail" is even more so. > > john > > > > _______________________________________________ > 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 Mon Mar 20 17:37:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLT0J-00007E-Hw; Mon, 20 Mar 2006 17:37:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLT0I-000079-7R for ima@ietf.org; Mon, 20 Mar 2006 17:37:34 -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 1FLT0E-00079X-Qm for ima@ietf.org; Mon, 20 Mar 2006 17:37:34 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLT0D-000Fpt-JF; Mon, 20 Mar 2006 17:37:29 -0500 Date: Mon, 20 Mar 2006 17:37:28 -0500 From: John C Klensin To: Yangwoo Ko Subject: Re: [EAI] Terminology issue Message-ID: <236696F751EF67939D90ADEB@as-s2n> In-Reply-To: <441F2BA7.2010005@icu.ac.kr> References: <6.0.0.20.2.20060319163739.09c90440@localhost> <441D55E5.9030901@alvestrand.no> <441D5DD4.1080507@icu.ac.kr> <200603191610.k2JGAd8D042645@nic-naa.net> <441D836A.6040104@alvestrand.no> <441F2BA7.2010005@icu.ac.kr> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) 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 --On Tuesday, March 21, 2006 07:24 +0900 Yangwoo Ko wrote: > > As pointed out in our framework document, we need to cleanup > terminologies quite soon. Let me start to roll the ball. > > 1. Name for working scope -- (E)mail i18n vs. (e)mail address > i18n vs. EAI > > The scope of work we are doing is (e)mail address i18n. > However, current approach requires more than that (e.g. utf-8 > encoding support at headers). Thus we may call it (e)mail > i18n. However, this seems to be broader than what we are > actually doing. I will choose (without any preference) to use > EAI in the following paragraphs. Hmm. One of the points you make below suggests i15demail :-) > 2. Name for resulting addresses -- IMA vs. i18(n)(e)mail > address > > These are names for (e)mail addresses that are EAI-compliant. > These addresses include old ASCII only addresses as well. At > least for me (non English native), internationalized email > address sound more natural than internationalization email > address. Since I don't have any idea how to make > "internationalized email address" shorter, I prefer to use > IMA. (IEA?) i15dEA? > 3. Name for resulting things (except addresses) > > For example, what will be the name for EAI-compliant mail > contents? We may call them as internationalized mail contents > though it is still broader than wanted. MIME non-ASCII body parts? And note, following a piece of the apps area discussion this morning, that content internationalization applies only to text/ body parts. > 4. Others > > There are several other terminologies (e.g. all-ASCII address) > used in the documents discussed in this WG. I hope that if > there were consensus on above terms, it could be easier to > generate other terms based on them. Clearly, I am sympathetic to the problem, I just don't know quite what to do about it. I am, however, resistant to using abbreviations or acronyms that have specific and widely-used meanings elsewhere. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 18:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTOX-0005k9-6R; Mon, 20 Mar 2006 18:02:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTOV-0005j0-Ci for ima@ietf.org; Mon, 20 Mar 2006 18:02:35 -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 1FLTOV-000070-29 for ima@ietf.org; Mon, 20 Mar 2006 18:02:35 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLTOS-000Ft2-S8; Mon, 20 Mar 2006 18:02:33 -0500 Date: Mon, 20 Mar 2006 18:02:30 -0500 From: John C Klensin To: Chris Newman , Yangwoo Ko Message-ID: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ima@ietf.org Subject: [EAI] UTF8 POP and character sets 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, It seems to me that the list of character sets that SHOULD be supported potentially adds considerable complexity to the protocol and doesn't accomplish much. So, two questions for people to think about... (1) Any POP client today that receives non-ASCII material is going to do so in encoded word form for the headers and Base64 or Q-P form, with a character set label, for textual body parts. Q-P works fairly badly outside the "Latin" ISO8859 sets and some would claim that it never works well. Those clients already have the machinery for decoding (or don't and have unhappy users), although future ones --the client side of the NO_RETR problem-- may not. Now, getting from Base64 (or Q-P) or encoded words to a character coding that matches the charset label or encode word charset code is straightforward and mechanical. But I wonder if we need to support --or if you document actually intends-- any encoding other than UTF-8 for addresses. Perhaps now is the time to start saying "our on-the-wire data format for text is going to be UTF-8 and non-UTF-8 environments need to support that conversion, and only that conversion, going forward". (2) That question is clearly more general that this WG's mission. Is it time to formally ask the IAB to convene a process for advising the applications community whether we are ready to take such a step? Any resemblance between the above concerns and this morning's AppArea conversation about an NVT-i18n is obviously no coincidence. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 18:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTj4-0000cQ-Kw; Mon, 20 Mar 2006 18:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTj2-0000Z3-U8 for ima@ietf.org; Mon, 20 Mar 2006 18:23:48 -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 1FLTj2-0001EN-4x for ima@ietf.org; Mon, 20 Mar 2006 18:23:48 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLTj1-000Fv2-BZ; Mon, 20 Mar 2006 18:23:47 -0500 Date: Mon, 20 Mar 2006 18:23:45 -0500 From: John C Klensin To: Chris Newman , ima@ietf.org Subject: Re: [EAI] ATOMIC parameter Message-ID: In-Reply-To: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa > X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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've read your note several times to see if I can figure out where we disagree. I think it is the nature of the things that are encoded in local parts and, ultimately, the reason why that "no local-part interpretation by senders or relays" rule is there. Given that rule, if one is sending UTF-8 address material to a current, RFC821-compliant-only final receiver (the worst case as far as I know), I think that one needs to know exactly how that receiver interprets and decodes addresses, and the order in which it does so, in order to downgrade the addresses. Certainly downgrading other header, or even body, material is not problematic. This many not be problematic for POP3 or IMAP because any mailbox routing or other transformations that will be applied by the delivery SMTP server will presumably be applied before anything gets to the mail store. But, for in-transit downgrading in the general case, I think that any downgrade/recoding mechanism we can devise is a shot in the dark, one that risks a sender eventually getting a bounce message about an address he or she has never seen before. Personally, I think _that_ is the worst possible case: the message gets bounced rather than delivered, and the error message is unintelligible. If the message is going to bounce, better to have it bounce from a point at which a plausible error report can be generated. Now, a way to read my analysis and yours together is that we need to drastically narrow the cases for which ATOMIC is relevant. If, for example, we have a message with UTF-8 header material but all-ASCII addresses, then one clearly can, and should, downgrade the headers (using encoded words or the equivalent). (I think this makes the case for no UTF-8 in header _names_ even stronger.) It is only when the addresses (actually the address local-parts because we can "downgrade" domain names to punycode) themselves are in UTF-8 and there is no next-hop support are we in serious trouble. And it was that case for which ATOMIC was designed. That still leaves an interesting case in which the message can be accurately delivered because the local parts in all of the forward-pointing addresses are ASCII but the backward-pointing address(es) are not. And that is the old argument about whether a message should be delivered even if it is known that it cannot be replied to. You would, I think, say "yes", as would I. The antispam community generally says "no". And I hope that we can avoid having to resolve it here. john --On Monday, March 20, 2006 02:22 -0600 Chris Newman wrote: > Although I'm sympathetic to the motivations behind the ATOMIC > parameter, I believe it is an incorrect bias of protocol > purity over operational robustness. > > As a matter of operational robustness it is almost always > better to move questionable email material forward than to > bounce it. If the recipient gets something that appears to be > corrupt, they will contact the sender to resend the material. > If the message is important, the recipient will probably have > out-of-band mechanisms to contact the sender that are more > likely to work than the MAIL FROM address (e.g. a cell phone > number, etc). > > On the flip side, it is quite easy to mis-configure the MAIL > FROM address and the problem probably won't be noticed unless > the person who did so gets a complaint from a colleague which > will only happen if the message moves forward and the > colleague's attempt to reply fails. We also have widely > deployed systems that do inappropriate things with MAIL FROM > that can cause loops or other badness when a bounce happens. > And in the new world of Spam blowback, many people simply > ignore almost all bounces (myself included, unfortunately). > > This is very unfortunate for those of us who care a great deal > about protocol purity. It's really painful to pass > non-interoperable junk forward but the outcome for the users > involved is more likely to be better, so it's usually the > right thing to do. > > Which brings us to the ATOMIC parameter. We all like the rule > which forbids local part interpretation by remote systems and > I respect the ATOMIC parameter approach as a clever way to > preserve that rule. Unfortunately, ATOMIC=no leaves MTAs in > an untenable situation: either ignore the standard, > downconvert and pass forward or bounce. Unfortunately, > robustness suggests the right answer is to ignore the > standard. Were I implementing a system, I'd probably ignore > the standard for this case by default and include an option to > follow the standard. But having "do the right thing for > users" and "comply with the standard" as two separate settings > is not something I like (how often do people use the "strict > ANSI" option on their C compiler?). > > Use of a UTF-8 local part should implicitly grant permission > to use the 7-bit-encoded alias of that local part. This is > not significantly different from the rule that > list-addr@example.com implies the existence of > list-addr-request@example.com and the converse is true. > Furthermore, if someone wants to use structured UTF-8 > addresses for special processing and do so while interacting > with a 7-bit-only system, I believe it's reasonable to insist > they upgrade their special processing system to remove the > 7-bit encoding prior to processing. And as much as I like > sub-addresses, their use is simply not widespread enough to > merit additional design complexity simply to avoid requiring > up-conversion at that point in the system. > > Finally, down-conversion is a non-negotiable feature for some > implementers (myself included). I have to be able to > down-convert the UTF-8 local parts in the headers, even if an > alternate address is unavailable (and it doesn't change things > if the spec requires an alternate address be available, as we > still have to deal with the non-compliant case in quality > software). So I suggest ATOMIC=yes should be implicit from > the use of UTF-8 and thus not necessary to include in the > protocol specification. > > - Chris > > > _______________________________________________ > 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 Mon Mar 20 19:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUj4-0006iR-H2; Mon, 20 Mar 2006 19:27:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUj3-0006iM-Ce for ima@ietf.org; Mon, 20 Mar 2006 19:27:53 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUj2-0004DT-0r for ima@ietf.org; Mon, 20 Mar 2006 19:27:53 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2L0S2i9004340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Mar 2006 16:28:03 -0800 Message-ID: <441F486B.60506@dcrocker.net> Date: Mon, 20 Mar 2006 18:27:23 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [EAI] Specify a "use only one of these" address list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Per the comment I made at the microphone, the feature I was referring to was in RFC 733, but was deprecated by the time of RFC 822: > address = host-phrase ; Machine mailbox > / ( [phrase] "<" #address ">") ; Individual / List > / ( [phrase] ":" #address ";") ; Group > / quoted-string ; Arbitrary text > / (":" ( "Include" ; File, w/ addr list > / "Postal" ; (U.S.) Postal addr > / atom ) ; Extended data type > ":" address) > The second line is what I was referring to. The text describing defining the semantics of this is: > An individual may have several mailboxes and a group of > individuals may wish to receive mail as a single unit (i.e., > a distribution list). The second and third alternatives of > an address list (#address) allow naming a collection of > subordinate addresses list(s). Recipient mailboxes are > specified within the bracketed part ("<" - ">" or ":" - ";") > of such named lists. The use of angle-brackets ("<", ">") is > intended for the cases of individuals with multiple mailboxes > and of special mailbox lists; it is not expected to be nested > more than one level, although the specification allows such > nesting. The use of colon/semi-colon (":", ";") is intended > for the case of groups. Groups can be expected to nest > (i.e., to contain subgroups). For both individuals and > groups, a copy of the transmitted message is to be sent to > EACH mailbox listed. For the case of a special list, > treatment of addresses is defined in the relevant subsections > of this section. Note that the semantics, here, say to send to ALL of the addresses in the list. I believe that the goal for the current should be to direct the use of only ONE OF the addresseses. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 20 20:12:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLVQG-00081b-6U; Mon, 20 Mar 2006 20:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUhQ-00060u-M9 for ima@ietf.org; Mon, 20 Mar 2006 19:26:12 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUhP-0004AP-Ad for ima@ietf.org; Mon, 20 Mar 2006 19:26:12 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2L0QZ7m004171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Mar 2006 16:26:37 -0800 Message-ID: <441F4814.1000101@dcrocker.net> Date: Mon, 20 Mar 2006 18:25:56 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Mon, 20 Mar 2006 20:12:31 -0500 Subject: [EAI] Specify a "use only one of these" address list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Per the comment I made at the microphone, the feature I was referring to was in RFC 733, but was deprecated by the time of RFC 822: > address = host-phrase ; Machine mailbox > / ( [phrase] "<" #address ">") ; Individual / List > / ( [phrase] ":" #address ";") ; Group > / quoted-string ; Arbitrary text > / (":" ( "Include" ; File, w/ addr list > / "Postal" ; (U.S.) Postal addr > / atom ) ; Extended data type > ":" address) > The second line is what I was referring to. The text describing defining the semantics of this is: > An individual may have several mailboxes and a group of > individuals may wish to receive mail as a single unit (i.e., > a distribution list). The second and third alternatives of > an address list (#address) allow naming a collection of > subordinate addresses list(s). Recipient mailboxes are > specified within the bracketed part ("<" - ">" or ":" - ";") > of such named lists. The use of angle-brackets ("<", ">") is > intended for the cases of individuals with multiple mailboxes > and of special mailbox lists; it is not expected to be nested > more than one level, although the specification allows such > nesting. The use of colon/semi-colon (":", ";") is intended > for the case of groups. Groups can be expected to nest > (i.e., to contain subgroups). For both individuals and > groups, a copy of the transmitted message is to be sent to > EACH mailbox listed. For the case of a special list, > treatment of addresses is defined in the relevant subsections > of this section. Note that the semantics, here, say to send to ALL of the addresses in the list. I believe that the goal for the current should be to direct the use of only ONE OF the addresseses. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 01:36:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLaU2-0007zV-UK; Tue, 21 Mar 2006 01:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLaU1-0007zQ-L0 for ima@ietf.org; Tue, 21 Mar 2006 01:36:45 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLaTz-00008t-9b for ima@ietf.org; Tue, 21 Mar 2006 01:36:45 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k2L6aguf025787 for ; Mon, 20 Mar 2006 23:36:42 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWG00501PYMYR00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 20 Mar 2006 23:36:42 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([204.96.114.218]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWG00F22T127B20@mail-amer.sun.com> for ima@ietf.org; Mon, 20 Mar 2006 23:36:42 -0700 (MST) Date: Tue, 21 Mar 2006 00:38:41 -0600 From: Chris Newman Subject: Re: [EAI] Specify a "use only one of these" address list In-reply-to: <441F4814.1000101@dcrocker.net> To: ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <441F4814.1000101@dcrocker.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 we're using: phrase in RFC 2822 + UTF 8 headers, why don't we use: MAIL FROM: in SMTP instead of the ALT-ADDRESS parameter? The similar looking protocol is an obvious, but minor advantage of this approach. However, the major advantage of this stems from a limitation of ESMTP parameters. RFC 2821 forbids the use of "=" in an ESMTP parameter value and "=" is a common character in ASCII email addresses. Furthermore, it forbids use of space which is legal (albeit never used). We could work around this using xtext encoding (as ORCPT does), by ignoring the rules or by forbidding those characters. But I don't find any of those as satisfactory as simply putting both addresses in the angle-brackets. So I propose we remove ALT-ADDRESS and replace it with optional dual-address in the angle-brackets so we can sidestep the parameter encoding/illegal-character issue. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 04:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdZ9-0007AY-5m; Tue, 21 Mar 2006 04:54:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdZ7-0007AF-Vy for ima@ietf.org; Tue, 21 Mar 2006 04:54:13 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdKb-00079s-PA for ima@ietf.org; Tue, 21 Mar 2006 04:39:15 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2L9cld12865; Tue, 21 Mar 2006 18:38:47 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 2370_7ecb9dd8_b8be_11da_8fa8_0014221f2a2d; Tue, 21 Mar 2006 18:38:46 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k2L9aTdL006553; Tue, 21 Mar 2006 18:37:51 +0900 Message-Id: <6.0.0.20.2.20060321181843.09e153b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 21 Mar 2006 18:26:42 +0900 To: John C Klensin , Chris Newman , Yangwoo Ko From: Martin Duerst Subject: Re: [EAI] UTF8 POP and character sets In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 08:02 06/03/21, John C Klensin wrote: >Chris, > >It seems to me that the list of character sets that SHOULD be supported potentially adds considerable complexity to the protocol and doesn't accomplish much. > >So, two questions for people to think about... > >(1) Any POP client today that receives non-ASCII material is going to do so in encoded word form for the headers and Base64 or Q-P form, Or 8bit, unless that's forbidden in the case of POP. >with a character set label, for textual body parts. Q-P works fairly badly outside the "Latin" ISO8859 sets and some would claim that it never works well. It's not that it doesn't work well, it's just really inefficient. >Those clients already have the machinery for decoding (or don't and have unhappy users), although future ones --the client side of the NO_RETR problem-- may not. Now, getting from Base64 (or Q-P) or encoded words to a character coding that matches the charset label or encode word charset code is straightforward and mechanical. But I wonder if we need to support --or if you document actually intends-- any encoding other than UTF-8 for addresses. I think that would be a highly unnecessary complication. >Perhaps now is the time to start saying "our on-the-wire data format for text is going to be UTF-8 and non-UTF-8 environments need to support that conversion, and only that conversion, going forward". As for 'text', as far as this refers to body text, I think it's okay to leave things as they are currently, i.e. that various encodings are allowed as long as they are documented with a charset parameter in the Content-Type header. Of course, my hope is that most of the messages that use internationalized addresses will have their body in UTF-8, but I don't think there is any reason to force that, it will happen naturally. >(2) That question is clearly more general that this WG's mission. Is it time to formally ask the IAB to convene a process for advising the applications community whether we are ready to take such a step? Which step exactly? >Any resemblance between the above concerns and this morning's AppArea conversation about an NVT-i18n is obviously no coincidence. For the benefit of those not in Dallas, could you explain. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 05:20:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdyh-0003bh-7m; Tue, 21 Mar 2006 05:20:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdyg-0003bc-0t for ima@ietf.org; Tue, 21 Mar 2006 05:20:38 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdTM-0007LD-9R for ima@ietf.org; Tue, 21 Mar 2006 04:48:16 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLdJN-0007xL-03 for ima@ietf.org; Tue, 21 Mar 2006 04:37:57 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2L9bfd12736; Tue, 21 Mar 2006 18:37:41 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 232f_57d890d2_b8be_11da_8d3f_0014221f2a2d; Tue, 21 Mar 2006 18:37:41 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k2L9aeAP006554; Tue, 21 Mar 2006 18:37:05 +0900 Message-Id: <6.0.0.20.2.20060321174546.0a278d60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 21 Mar 2006 18:16:52 +0900 To: Chris Newman , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] silly states and header label In-Reply-To: <2AB9B5F3FEE050F85AC9BEDC@186.114.96.204.in-addr.arpa> References: <2AB9B5F3FEE050F85AC9BEDC@186.114.96.204.in-addr.arpa> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 16:15 06/03/20, Chris Newman wrote: >The problem I have with a header to declare message type is that changes from three cases to six cases, at least two of which are silly states. And since headers can be re-ordered it's still necessary to scan all the headers to find the label, so I don't see how the benefits (detection) can outweigh the costs (doubling the number of cases to deal with). Were I writing code, I'd ignore the label, just as I ignore the MIME-Version header (which is only helpful as a hint if one supports RFC 1049). I very much agree with the above. >If we must use a labeling mechanism, I suggest using a zero-width non-joiner UTF-8 character at the beginning of the message. UTF-8 aware SMTP servers are required to insert Received and Return-Path after the zero-width non-joiner character. That has some other nice features -- it permits instant detection of the encoding for certain out-of-band mechanisms (e.g. UTF-8 editors), it has no impact on display, and if the message gets to a non-8-bit system the failure is likely to be immediate and more obvious rather than later and more obscure (indeed it's so obvious that legacy systems can be patched to check for it easily). I'm still not sure those benefits outweigh the cost of silly states, but it's closer to making the cut. I'm not at all sure this is a good idea. It changes the overall message format. Besides header fields and message body, separated by CRLFCRLF, we now have something additional. Some tools that just pass through the eigth bit (I'm more thinking about all kinds of secondary tools rather than the main MUAs and MTAs,...) may choke. Also, it's difficult to see, which makes debugging more difficult. This also (together with what you wrote above) makes it difficult to drop. And it would introduce a bad precedent of using Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 08:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLh6M-0001Qv-Ml; Tue, 21 Mar 2006 08:40:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLh6L-0001Qq-Ha for ima@ietf.org; Tue, 21 Mar 2006 08:40:45 -0500 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLh6J-0008AB-VW for ima@ietf.org; Tue, 21 Mar 2006 08:40:45 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-6.tower-124.messagelabs.com!1142948442!7942006!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 32745 invoked from network); 21 Mar 2006 13:40:42 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-124.messagelabs.com with SMTP; 21 Mar 2006 13:40:42 -0000 Received: from [135.70.144.233] (unknown[135.70.144.233](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060321134041gw100100gme> (Authid: tony); Tue, 21 Mar 2006 13:40:41 +0000 Message-ID: <44200254.1010000@att.com> Date: Tue, 21 Mar 2006 08:40:36 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 sounds reasonable. Tony Hansen tony@att.com Chris Newman wrote: > If we're using: > > phrase > > in RFC 2822 + UTF 8 headers, why don't we use: > > MAIL FROM: > > in SMTP instead of the ALT-ADDRESS parameter? > > The similar looking protocol is an obvious, but minor advantage of this > approach. > > However, the major advantage of this stems from a limitation of ESMTP > parameters. RFC 2821 forbids the use of "=" in an ESMTP parameter value > and "=" is a common character in ASCII email addresses. Furthermore, it > forbids use of space which is legal (albeit never used). We could work > around this using xtext encoding (as ORCPT does), by ignoring the rules > or by forbidding those characters. But I don't find any of those as > satisfactory as simply putting both addresses in the angle-brackets. > > So I propose we remove ALT-ADDRESS and replace it with optional > dual-address in the angle-brackets so we can sidestep the parameter > encoding/illegal-character issue. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 09:04:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhTO-0005Jr-Vb; Tue, 21 Mar 2006 09:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhTN-0005Jl-Rv for ima@ietf.org; Tue, 21 Mar 2006 09:04:33 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhTM-0000Wg-CI for ima@ietf.org; Tue, 21 Mar 2006 09:04:33 -0500 Received: from [198.18.101.77] ([12.5.73.162]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LE4prl025822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 06:04:52 -0800 Message-ID: <442007E1.7010203@dcrocker.net> Date: Tue, 21 Mar 2006 08:04:17 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Chris Newman Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > So I propose we remove ALT-ADDRESS and replace it with optional > dual-address in the angle-brackets so we can sidestep the parameter > encoding/illegal-character issue. So: If there is one address and the ATOMIC parameter is present and the UTF-8 address must be converted then the converted address is added to the rcpt-to list. If there are two addresses then the conversion has already been performed. It is tempting to suggest that a posting agent simply include both addresses all the time. Therefore it would not be necessary to do the conversion later. It would merely be a case of choosing one. I do not recall whether ALT-ADDRESS is restricted to be a conversion of the UTF-8 address, but it might be useful to allow it to be any legacy-encoded address. Having the posting agent specify the rcpt-to address as a list obviously permits this freedom; addresses may be entirely independent of each other. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 09:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhru-0000sf-IR; Tue, 21 Mar 2006 09:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhru-0000sa-Aa for ima@ietf.org; Tue, 21 Mar 2006 09:29:54 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhrs-0001gj-Tr for ima@ietf.org; Tue, 21 Mar 2006 09:29:54 -0500 Received: from edmontr3 ([204.96.115.94]) by server (8.12.8/8.12.8) with SMTP id k2LD2o30003935 for ; Tue, 21 Mar 2006 08:02:52 -0500 Message-ID: <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> From: "Edmon Chung" To: References: <441F4814.1000101@dcrocker.net> Subject: Re: [EAI] Specify a "use only one of these" address list Date: Tue, 21 Mar 2006 09:27:53 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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="===============0118673140==" Errors-To: ima-bounces@ietf.org --===============0118673140== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 QSBzbWFsbCBzdWdnZXN0aW9uLi4uDQpXZSB0YWxrZWQgYWJvdXQgdXNpbmcgYSBzZXBhcmF0b3Ig Zm9yIHRoZSBVVEY4IGFuZCBBU0NJSSBhZGRyZXNzZXMgd2l0aGluIHRoZSBhbmdsZSBicmFja2V0 cyBhbmQgc3RhcnRlZCB1c2luZyB0aGUgY29tbWEuICBUaGlzIHNlZW1zIHRvIGJlIGEgYml0IGNv bmZ1c2luZyBlc3BlY2lhbGx5IGNvbnNpZGVyaW5nIHdoYXQgRGF2ZSBwb2ludGVkIG91dCBpbiBS RkM3MzMsIHNpbmNlIGNvbW1hcyBhcmUgdXN1YWxseSB1c2VkIGZvciBsaXN0cywgaS5lLiAiQUxM IiByYXRoZXIgdGhhbiAiT1IiLg0KV291bGQgc3VnZ2VzdCB1c2luZyBhIGRpZmZlcmVudCBzZXBh cmF0b3IsIGUuZy4gYSBzbGFzaCAiLyIgb3IgYSB2ZXJ0aWNhbCBiYXIgInwiOg0KPHV0ZjhAdXRm OCAvIGFzY2lpQGFzY2lpPg0KPHV0ZjhAdXRmOCB8IGFzY2lpQGFzY2lpPg0KDQpFZG1vbg0KDQog DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPENo cmlzLk5ld21hbkBTdW4uQ09NPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBN YXJjaCAyMSwgMjAwNiAxOjM4IEFNDQpTdWJqZWN0OiBSZTogW0VBSV0gU3BlY2lmeSBhICJ1c2Ug b25seSBvbmUgb2YgdGhlc2UiIGFkZHJlc3MgbGlzdA0KDQoNCj4gSWYgd2UncmUgdXNpbmc6DQo+ IA0KPiAgcGhyYXNlIDx1dGY4QHV0ZjgtZG9tYWluLCBhc2NpaUBkb21haW4+DQo+IA0KPiBpbiBS RkMgMjgyMiArIFVURiA4IGhlYWRlcnMsIHdoeSBkb24ndCB3ZSB1c2U6DQo+IA0KPiBNQUlMIEZS T006PHV0ZjhAdXRmOC1kb21haW4sIGFzY2lpQGRvbWFpbj4NCj4gDQo+IGluIFNNVFAgaW5zdGVh ZCBvZiB0aGUgQUxULUFERFJFU1MgcGFyYW1ldGVyPw0KPiANCj4gVGhlIHNpbWlsYXIgbG9va2lu ZyBwcm90b2NvbCBpcyBhbiBvYnZpb3VzLCBidXQgbWlub3IgYWR2YW50YWdlIG9mIHRoaXMgDQo+ IGFwcHJvYWNoLg0KPiANCj4gSG93ZXZlciwgdGhlIG1ham9yIGFkdmFudGFnZSBvZiB0aGlzIHN0 ZW1zIGZyb20gYSBsaW1pdGF0aW9uIG9mIEVTTVRQIA0KPiBwYXJhbWV0ZXJzLiAgUkZDIDI4MjEg Zm9yYmlkcyB0aGUgdXNlIG9mICI9IiBpbiBhbiBFU01UUCBwYXJhbWV0ZXIgdmFsdWUgYW5kIA0K PiAiPSIgaXMgYSBjb21tb24gY2hhcmFjdGVyIGluIEFTQ0lJIGVtYWlsIGFkZHJlc3Nlcy4gIEZ1 cnRoZXJtb3JlLCBpdCBmb3JiaWRzIA0KPiB1c2Ugb2Ygc3BhY2Ugd2hpY2ggaXMgbGVnYWwgKGFs YmVpdCBuZXZlciB1c2VkKS4gIFdlIGNvdWxkIHdvcmsgYXJvdW5kIHRoaXMgDQo+IHVzaW5nIHh0 ZXh0IGVuY29kaW5nIChhcyBPUkNQVCBkb2VzKSwgYnkgaWdub3JpbmcgdGhlIHJ1bGVzIG9yIGJ5 IGZvcmJpZGRpbmcgDQo+IHRob3NlIGNoYXJhY3RlcnMuICBCdXQgSSBkb24ndCBmaW5kIGFueSBv ZiB0aG9zZSBhcyBzYXRpc2ZhY3RvcnkgYXMgc2ltcGx5IA0KPiBwdXR0aW5nIGJvdGggYWRkcmVz c2VzIGluIHRoZSBhbmdsZS1icmFja2V0cy4NCj4gDQo+IFNvIEkgcHJvcG9zZSB3ZSByZW1vdmUg QUxULUFERFJFU1MgYW5kIHJlcGxhY2UgaXQgd2l0aCBvcHRpb25hbCBkdWFsLWFkZHJlc3MgaW4g DQo+IHRoZSBhbmdsZS1icmFja2V0cyBzbyB3ZSBjYW4gc2lkZXN0ZXAgdGhlIHBhcmFtZXRlciBl bmNvZGluZy9pbGxlZ2FsLWNoYXJhY3RlciANCj4gaXNzdWUuDQo+IA0KPiAgICAgICAgICAgICAg ICAtIENocmlzDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+IA0KPg== --===============0118673140== 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 --===============0118673140==-- From ima-bounces@ietf.org Tue Mar 21 10:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj57-0007xs-BR; Tue, 21 Mar 2006 10:47:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj55-0007wV-Nb for ima@ietf.org; Tue, 21 Mar 2006 10:47:35 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLj54-0004dc-As for ima@ietf.org; Tue, 21 Mar 2006 10:47:35 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LFllU0006339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 07:47:49 -0800 Message-ID: <44202002.5070602@dcrocker.net> Date: Tue, 21 Mar 2006 09:47:14 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Edmon Chung Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> In-Reply-To: <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Edmon, What is being proposed *is* a list. That the list is a USE-ONE-OF, rather than a USE-ALL, form of list. However this strikes me as a minor point of distinction. I suspect the only important issue about making the syntactic choice is that the delimiter be taken from the existing set of special characters. Slash and vertical bar are not members of that set. d/ Edmon Chung wrote: > A small suggestion... > We talked about using a separator for the UTF8 and ASCII addresses within the angle brackets and started using the comma. This seems to be a bit confusing especially considering what Dave pointed out in RFC733, since commas are usually used for lists, i.e. "ALL" rather than "OR". > Would suggest using a different separator, e.g. a slash "/" or a vertical bar "|": > > > > Edmon > > > ----- Original Message ----- >> If we're using: >> >> phrase >> >> in RFC 2822 + UTF 8 headers, why don't we use: >> >> MAIL FROM: >> >> in SMTP instead of the ALT-ADDRESS parameter? -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjHG-0000Kx-8F; Tue, 21 Mar 2006 11:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjHE-0000Kl-Bx for ima@ietf.org; Tue, 21 Mar 2006 11:00:08 -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 1FLjHD-0005O4-3D for ima@ietf.org; Tue, 21 Mar 2006 11:00:08 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLjH8-000Hbo-96; Tue, 21 Mar 2006 11:00:02 -0500 Date: Tue, 21 Mar 2006 11:00:00 -0500 From: John C Klensin To: dcrocker@bbiw.net, Edmon Chung Subject: Re: [EAI] Specify a "use only one of these" address list Message-ID: <54F16593913DA2355862804F@as-s2n> In-Reply-To: <44202002.5070602@dcrocker.net> References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 --On Tuesday, March 21, 2006 09:47 -0600 Dave Crocker wrote: > Edmon, > > What is being proposed *is* a list. That the list is a > USE-ONE-OF, rather than a USE-ALL, form of list. However this > strikes me as a minor point of distinction. > > I suspect the only important issue about making the syntactic > choice is that the delimiter be taken from the existing set of > special characters. Slash and vertical bar are not members of > that set. Worse yet, slash is a key syntax character in a local-form address from a particular class of gateway that, while better best forgotten, can't be. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:06:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjNO-0002hL-58; Tue, 21 Mar 2006 11:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjNN-0002gl-3h for ima@ietf.org; Tue, 21 Mar 2006 11:06:29 -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 1FLjNM-0005aV-I0 for ima@ietf.org; Tue, 21 Mar 2006 11:06:29 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLjNH-000HcS-Mk; Tue, 21 Mar 2006 11:06:24 -0500 Date: Tue, 21 Mar 2006 11:06:21 -0500 From: John C Klensin To: Martin Duerst , Chris Newman , Yangwoo Ko Subject: Re: [EAI] UTF8 POP and character sets Message-ID: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 --On Tuesday, March 21, 2006 18:26 +0900 Martin Duerst wrote: > At 08:02 06/03/21, John C Klensin wrote: > >Chris, > > > >It seems to me that the list of character sets that SHOULD > be supported potentially adds considerable complexity to the > protocol and doesn't accomplish much. > > > >So, two questions for people to think about... > > > >(1) Any POP client today that receives non-ASCII material is > going to do so in encoded word form for the headers and Base64 > or Q-P form, > > Or 8bit, unless that's forbidden in the case of POP. Forbidden in POP (see forthcoming note) > >with a character set label, for textual body parts. Q-P > works fairly badly outside the "Latin" ISO8859 sets and some > would claim that it never works well. > > It's not that it doesn't work well, it's just really > inefficient. >From a user perspective, the "feature" of Q-P is that it is almost readable even without conversion back to the original form. That works ok -- although preferences differ-- for text bodies that are mostly ASCII with a sprinkling of Latin-N characters. For other text bodies, it just don't communicate any useful information if read without back-conversion. If one can guarantee conversion (decoding) at the receiving end, then it is all about efficiency, as you point out. > >Those clients already have the machinery for decoding (or > don't and have unhappy users), although future ones --the > client side of the NO_RETR problem-- may not. Now, getting > from Base64 (or Q-P) or encoded words to a character coding > that matches the charset label or encode word charset code is > straightforward and mechanical. But I wonder if we need to > support --or if you document actually intends-- any encoding > other than UTF-8 for addresses. > > I think that would be a highly unnecessary complication. I think that is right, but we need to look carefully at existing standards and actual use patterns. > >Perhaps now is the time to start saying "our on-the-wire > data format for text is going to be UTF-8 and non-UTF-8 > environments need to support that conversion, and only that > conversion, going forward". > > As for 'text', as far as this refers to body text, I think > it's okay to > leave things as they are currently, i.e. that various > encodings are > allowed as long as they are documented with a charset > parameter in > the Content-Type header. Of course, my hope is that most of the > messages that use internationalized addresses will have their > body in UTF-8, but I don't think there is any reason to force > that, it will happen naturally. I think we agree > >(2) That question is clearly more general that this WG's > mission. Is it time to formally ask the IAB to convene a > process for advising the applications community whether we are > ready to take such a step? > > Which step exactly? See below > >Any resemblance between the above concerns and this > morning's AppArea conversation about an NVT-i18n is obviously > no coincidence. > > For the benefit of those not in Dallas, could you explain. One of the key design decisions in getting the ARPANET to function at a user/ applications level was the establishment of a standard for the form in which text would pass over the net. It is known as "net-ASCII" or "the NVT (network virtual terminal) character set" (the two are slightly different, but the difference is not important here). The model was that systems sending text over the network --especially as part of protocol exchanges-- were required to convert to that form and systems receiving such text were required to convert from it -- both to the extent needed locally -- this avoiding all sorts of n-squared problems. For non-ASCII text, we have tended (for good reasons at the time) to go the other way, more or less permitting any CCS to be used and focusing on making sure that the receiving system knows what has been sent to that it can take responsibility for remapping it locally if needed. For some purposes that is fine, but it leads to lousy protocol design. So the question that started yesterday morning was whether it is time to define an NVT-i18n (net-Unicode?). Given how we have gotten here, that form would presumably be UTF-8 with CRLF line termination, but the question is whether, even if we assume a Unicode world, we are ready to make an NVT-like rule rather than having UCS-2 or UCS-4, sundry bit orders, etc., floating around the network as "Unicode". And, of course, for other character codings, the need becomes even more urgent. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:15:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjVc-00085T-Ga; Tue, 21 Mar 2006 11:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjVb-00081E-Gq for ima@ietf.org; Tue, 21 Mar 2006 11:14:59 -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 1FLjVb-0005qk-5J for ima@ietf.org; Tue, 21 Mar 2006 11:14:59 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLjVa-000HdP-LA for ima@ietf.org; Tue, 21 Mar 2006 11:14:59 -0500 Date: Tue, 21 Mar 2006 11:14:57 -0500 From: John C Klensin To: ima@ietf.org Message-ID: <053233FEFF4BB10CFB1F52B4@as-s2n> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [EAI] An appeal ab out protocol-readng..b 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'd like to make a request of participants in this WG effort, especially those who come to the work from the perspective of internationalization efforts rather than email ones. It is sort of an extension of expecting people who haven't read the documents to sit in back and be quiet in meetings. This effort is very different from the IDN/IDNA one in at least one very important way. With IDNA, as soon as the decision was made that the characters that actually went into the DNS would conform to the hostname/LDH rule, it because possible to essentially ignore how the DNS worked internally. Whether doing so was wise or not is something we will continue to debate for years, but it was possible. This effort, at least in the model contemplated in the WG charter and preliminary documents, actually does need to interwork with the existing email environment and do so in very fundamental ways. If we are going to make progress, everyone is going to need to be familiar with the relevant email specifications -- RFC 2821 and 2822 for everyone; the MIME specs, especially those pieces that deal with internal body part headers, encoded words, registrations, constraints on multipart types and encodings for people thinking about downgrades; the POP and IMAP specs for people thinking about extensions to those protocols, etc. Discussions without that familiarity will, at best, cost us a huge amount of time. And on-list tutorials on mail fundamentals are just not a way to move the WG forward on the many issues we need to resolve. This stuff is complex and subtle. We got a dramatic demonstration of just how subtle it is yesterday when we discovered that the authors or RFC 822 and 2822 could remember just what went into a particular header field (I assure them that I would do much worse with 2822 -- I have learned to never answer a question without checking the text and I get myself into trouble almost every time I violate that principle). So, please, try to read and understand the documents -- not only the WG documents but the relevant basic email specifications -- before posting comments that good lead us on what are often called in English "wild goose chases". thanks, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:24:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjek-0005KI-5q; Tue, 21 Mar 2006 11:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjei-0005Ga-HX for ima@ietf.org; Tue, 21 Mar 2006 11:24:24 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjef-00064r-4d for ima@ietf.org; Tue, 21 Mar 2006 11:24:24 -0500 Received: from edmontr3 ([204.96.115.94]) by server (8.12.8/8.12.8) with SMTP id k2LEvD30004364; Tue, 21 Mar 2006 09:57:17 -0500 Message-ID: <014001c64d03$e59f97c0$5e7360cc@edmontr3> From: "Edmon Chung" To: "John C Klensin" , References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> Subject: Re: [EAI] Specify a "use only one of these" address list Date: Tue, 21 Mar 2006 11:21:59 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.4 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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="===============1664904717==" Errors-To: ima-bounces@ietf.org --===============1664904717== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSBndWVzcyB0aGUgcG9pbnQgaXMsIHRoZXJlIHNob3VsZCBwcm9iYWJseSBiZSBzb21lIGRpZmZl cmVudGlhdGlvbiB0aGFuIHVzaW5nIGEgY29tbWEuDQpFZG1vbg0KDQoNCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9obiBDIEtsZW5zaW4iIDxrbGVuc2luQGpjay5jb20+ DQpUbzogPGRjcm9ja2VyQGJiaXcubmV0PjsgIkVkbW9uIENodW5nIiA8ZWRtb25AYWZpbGlhcy5p bmZvPg0KQ2M6IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMSwgMjAwNiAx MTowMCBBTQ0KU3ViamVjdDogUmU6IFtFQUldIFNwZWNpZnkgYSAidXNlIG9ubHkgb25lIG9mIHRo ZXNlIiBhZGRyZXNzIGxpc3QNCg0KDQo+IA0KPiANCj4gLS1PbiBUdWVzZGF5LCBNYXJjaCAyMSwg MjAwNiAwOTo0NyAtMDYwMCBEYXZlIENyb2NrZXIgDQo+IDxkaGMyQGRjcm9ja2VyLm5ldD4gd3Jv dGU6DQo+IA0KPj4gRWRtb24sDQo+Pg0KPj4gV2hhdCBpcyBiZWluZyBwcm9wb3NlZCAqaXMqIGEg bGlzdC4gIFRoYXQgdGhlIGxpc3QgaXMgYQ0KPj4gVVNFLU9ORS1PRiwgcmF0aGVyIHRoYW4gYSBV U0UtQUxMLCBmb3JtIG9mIGxpc3QuIEhvd2V2ZXIgdGhpcw0KPj4gc3RyaWtlcyBtZSBhcyBhIG1p bm9yIHBvaW50IG9mIGRpc3RpbmN0aW9uLg0KPj4NCj4+IEkgc3VzcGVjdCB0aGUgb25seSBpbXBv cnRhbnQgaXNzdWUgYWJvdXQgbWFraW5nIHRoZSBzeW50YWN0aWMNCj4+IGNob2ljZSBpcyB0aGF0 IHRoZSBkZWxpbWl0ZXIgYmUgdGFrZW4gZnJvbSB0aGUgZXhpc3Rpbmcgc2V0IG9mDQo+PiBzcGVj aWFsIGNoYXJhY3RlcnMuICBTbGFzaCBhbmQgdmVydGljYWwgYmFyIGFyZSBub3QgbWVtYmVycyBv Zg0KPj4gdGhhdCBzZXQuDQo+IA0KPiBXb3JzZSB5ZXQsIHNsYXNoIGlzIGEga2V5IHN5bnRheCBj aGFyYWN0ZXIgaW4gYSBsb2NhbC1mb3JtIA0KPiBhZGRyZXNzIGZyb20gYSBwYXJ0aWN1bGFyIGNs YXNzIG9mIGdhdGV3YXkgdGhhdCwgd2hpbGUgYmV0dGVyIA0KPiBiZXN0IGZvcmdvdHRlbiwgY2Fu J3QgYmUuDQo+ICAgIGpvaG4NCj4gDQo+IA0KPg== --===============1664904717== 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 --===============1664904717==-- From ima-bounces@ietf.org Tue Mar 21 11:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjoB-000231-Qw; Tue, 21 Mar 2006 11:34:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjoA-00020l-Fa for ima@ietf.org; Tue, 21 Mar 2006 11:34:10 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjo9-0006Sk-3P for ima@ietf.org; Tue, 21 Mar 2006 11:34:10 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LGYcA0012624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 08:34:39 -0800 Message-ID: <44202AFD.5070703@dcrocker.net> Date: Tue, 21 Mar 2006 10:34:05 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> In-Reply-To: <54F16593913DA2355862804F@as-s2n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > Worse yet, slash is a key syntax character in a local-form address from > a particular class of gateway that, while better best forgotten, can't be. > john oh. right. how interesting i forgot that... to that end, i should note that two other characters that are , but are not defined as such in the 2822 or 2821 list of specials are plus (+) and equal (=). My suggestion is that the delimiter for the representation of this address set a) be the same for rfc2822 header fields and rfc2821 the rcptto command, and b) be taken from the common set of lexical specials in rfc2821 and rfc2822. I think that comma falls in that category. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjoe-00028n-Q7; Tue, 21 Mar 2006 11:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjoe-00028i-AJ for ima@ietf.org; Tue, 21 Mar 2006 11:34:40 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjoc-0006TZ-US for ima@ietf.org; Tue, 21 Mar 2006 11:34:40 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LGYrkP012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 08:34:55 -0800 Message-ID: <44202B0C.9030102@dcrocker.net> Date: Tue, 21 Mar 2006 10:34:20 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Edmon Chung Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> <014001c64d03$e59f97c0$5e7360cc@edmontr3> In-Reply-To: <014001c64d03$e59f97c0$5e7360cc@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Edmon Chung wrote: > I guess the point is, there should probably be some differentiation than using a comma. > Edmon That is a concise statement. Thanks. What I am not understanding is why a syntactic distinction is needed, here. How will it improve usability, reliability, or the like? d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:37:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjr5-0004Ij-RT; Tue, 21 Mar 2006 11:37:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjr5-0004Fa-6O for ima@ietf.org; Tue, 21 Mar 2006 11:37:11 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjr3-0006iz-Sj for ima@ietf.org; Tue, 21 Mar 2006 11:37:11 -0500 Received: from edmontr3 ([204.96.115.94]) by server (8.12.8/8.12.8) with SMTP id k2LFA530004444; Tue, 21 Mar 2006 10:10:07 -0500 Message-ID: <015d01c64d05$b0a95360$5e7360cc@edmontr3> From: "Edmon Chung" To: References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> <014001c64d03$e59f97c0$5e7360cc@edmontr3> <44202A68.4090304@dcrocker.net> Subject: Re: [EAI] Specify a "use only one of these" address list Date: Tue, 21 Mar 2006 11:36:40 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.4 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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="===============1674872892==" Errors-To: ima-bounces@ietf.org --===============1674872892== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 V2VsbCwgaWYgdGhlcmUgYXJlIGNlcnRhaW4gd2F5cyB0aGF0IGFwcGxpY2F0aW9uIHRyZWF0cyBj b21tYSBzZXBhcmF0ZWQgbGlzdHMgb2YgZW1haWwgYWRkcmVzc2VzIGluIHRoZSBnaXZlbiBjb250 ZXh0IGN1cnJlbnRseSwgdGhlbiBhIGRpZmZlcmVudCBub3RhdGlvbiB3b3VsZCBtb3JlIGNsZWFy bHkgc2lnbmFsIGEgbmVlZCBmb3IgaGFuZGxpbmcgdGhlbSBkaWZmZXJlbnRseS4NCkVkbW9uDQoN Cg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ3JvY2tlciIg PGRoY0BkY3JvY2tlci5uZXQ+DQpUbzogIkVkbW9uIENodW5nIiA8ZWRtb25AYWZpbGlhcy5pbmZv Pg0KQ2M6IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMSwgMjAwNiAxMToz MSBBTQ0KU3ViamVjdDogUmU6IFtFQUldIFNwZWNpZnkgYSAidXNlIG9ubHkgb25lIG9mIHRoZXNl IiBhZGRyZXNzIGxpc3QNCg0KDQo+IA0KPiANCj4gRWRtb24gQ2h1bmcgd3JvdGU6DQo+PiBJIGd1 ZXNzIHRoZSBwb2ludCBpcywgdGhlcmUgc2hvdWxkIHByb2JhYmx5IGJlIHNvbWUgZGlmZmVyZW50 aWF0aW9uIHRoYW4gdXNpbmcgYSBjb21tYS4NCj4+IEVkbW9uDQo+IA0KPiBUaGF0IGlzIGEgY29u Y2lzZSBzdGF0ZW1lbnQuICBUaGFua3MuDQo+IA0KPiBXaGF0IEkgYW0gbm90IHVuZGVyc3RhbmRp bmcgaXMgd2h5IGEgc3ludGFjdGljIGRpc3RpbmN0aW9uIGlzIG5lZWRlZCwgaGVyZS4gIEhvdyAN Cj4gd2lsbCBpdCBpbXByb3ZlIHVzYWJpbGl0eSwgcmVsaWFiaWxpdHksIG9yIHRoZSBsaWtlPw0K PiANCj4gZC8NCj4gLS0gDQo+IA0KPiBEYXZlIENyb2NrZXINCj4gQnJhbmRlbmJ1cmcgSW50ZXJu ZXRXb3JraW5nDQo+IDxodHRwOi8vYmJpdy5uZXQ+DQo+IA0KPg== --===============1674872892== 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 --===============1674872892==-- From ima-bounces@ietf.org Tue Mar 21 11:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjry-00056Y-9O; Tue, 21 Mar 2006 11:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjP0-0003z5-Ie for ima@ietf.org; Tue, 21 Mar 2006 11:08:10 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjOz-0005dw-7Y for ima@ietf.org; Tue, 21 Mar 2006 11:08:10 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LG8Rr5009141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 08:08:28 -0800 Message-ID: <442024D9.50807@bbiw.net> Date: Tue, 21 Mar 2006 10:07:53 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> In-Reply-To: <54F16593913DA2355862804F@as-s2n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Tue, 21 Mar 2006 11:38:05 -0500 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 > Worse yet, slash is a key syntax character in a local-form address from > a particular class of gateway that, while better best forgotten, can't be. > john oh. right. how interesting i forgot that... to that end, i should note that two other characters that are , but are not defined as such in the 2822 or 2821 list of specials are plus (+) and equal (=). My suggestion is that the delimiter for the representation of this address set a) be the same for rfc2822 header fields and rfc2821 the rcptto command, and b) be taken from the common set of lexical specials in rfc2821 and rfc2822. I think that comma falls in that category. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjry-00057F-D1; Tue, 21 Mar 2006 11:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjiu-00075C-EU for ima@ietf.org; Tue, 21 Mar 2006 11:28:44 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjit-0006F2-2O for ima@ietf.org; Tue, 21 Mar 2006 11:28:44 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LGTHG0011671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 08:29:18 -0800 Message-ID: <442029BC.3040307@dcrocker.net> Date: Tue, 21 Mar 2006 10:28:44 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> In-Reply-To: <54F16593913DA2355862804F@as-s2n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Tue, 21 Mar 2006 11:38:05 -0500 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > Worse yet, slash is a key syntax character in a local-form address from > a particular class of gateway that, while better best forgotten, can't be. > john oh. right. how interesting i forgot that... to that end, i should note that two other characters that are , but are not defined as such in the 2822 or 2821 list of specials are plus (+) and equal (=). My suggestion is that the delimiter for the representation of this address set a) be the same for rfc2822 header fields and rfc2821 the rcptto command, and b) be taken from the common set of lexical specials in rfc2821 and rfc2822. I think that comma falls in that category. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjry-00058J-H1; Tue, 21 Mar 2006 11:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjly-0000iT-B7 for ima@ietf.org; Tue, 21 Mar 2006 11:31:54 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjlw-0006Pc-Ux for ima@ietf.org; Tue, 21 Mar 2006 11:31:54 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LGW9fr012275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 08:32:11 -0800 Message-ID: <44202A68.4090304@dcrocker.net> Date: Tue, 21 Mar 2006 10:31:36 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Edmon Chung Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> <014001c64d03$e59f97c0$5e7360cc@edmontr3> In-Reply-To: <014001c64d03$e59f97c0$5e7360cc@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Tue, 21 Mar 2006 11:38:05 -0500 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Edmon Chung wrote: > I guess the point is, there should probably be some differentiation than using a comma. > Edmon That is a concise statement. Thanks. What I am not understanding is why a syntactic distinction is needed, here. How will it improve usability, reliability, or the like? d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 11:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk4b-00052M-6F; Tue, 21 Mar 2006 11:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk4a-00052C-T9 for ima@ietf.org; Tue, 21 Mar 2006 11:51:08 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLk4Z-0007NV-Gv for ima@ietf.org; Tue, 21 Mar 2006 11:51:08 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LGpHW1015298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 08:51:18 -0800 Message-ID: <44202EE3.4070704@dcrocker.net> Date: Tue, 21 Mar 2006 10:50:43 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Edmon Chung Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> <014001c64d03$e59f97c0$5e7360cc@edmontr3> <44202A68.4090304@dcrocker.net> <015d01c64d05$b0a95360$5e7360cc@edmontr3> In-Reply-To: <015d01c64d05$b0a95360$5e7360cc@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Edmon Chung wrote: > Well, if there are certain ways that application treats comma separated lists of email addresses in the given context currently, then a different notation would more clearly signal a need for handling them differently. OK. Fair concern. I believe the answer is: Nothing currently handles commas inside angle-brackets. So we are talking about brand new code and a brand new capability. (I feel safe is asserting that there is no deployed code that supports the original RFC733 construct...) d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 12:01:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkEf-00047Y-S0; Tue, 21 Mar 2006 12:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkEd-00046m-Nm for ima@ietf.org; Tue, 21 Mar 2006 12:01:31 -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 1FLkEd-00084K-3i for ima@ietf.org; Tue, 21 Mar 2006 12:01:31 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLkEZ-000HiE-Pm; Tue, 21 Mar 2006 12:01:28 -0500 Date: Tue, 21 Mar 2006 12:01:25 -0500 From: John C Klensin To: dcrocker@bbiw.net, Chris Newman Subject: Re: [EAI] Specify a "use only one of these" address list Message-ID: <6C6B32061125E2BDCBEA568B@as-s2n> In-Reply-To: <442007E1.7010203@dcrocker.net> References: <441F4814.1000101@dcrocker.net> <442007E1.7010203@dcrocker.net> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.0 (+) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 --On Tuesday, March 21, 2006 08:04 -0600 Dave Crocker wrote: >> So I propose we remove ALT-ADDRESS and replace it with >> optional dual-address in the angle-brackets so we can >> sidestep the parameter encoding/illegal-character issue. > > So: > > If there is one address > and the ATOMIC parameter is present > and the UTF-8 address must be converted > then the converted address is added to the rcpt-to list. > > If there are two addresses > then the conversion has already been performed. > > It is tempting to suggest that a posting agent simply include > both addresses all the time. Therefore it would not be > necessary to do the conversion later. It would merely be a > case of choosing one. Both addresses may not exist. We've been told by system administrators and users all over the world (but some parts of the world in particular -- this is layer 9 stuff and I'm happy to discuss specifics privately) that a requirement that they have and manage ASCII addresses when they are communicating only locally is unacceptable and insulting. As we all know, protocol requirements that are considered unreasonable are generally ignored. I think that, in practical terms, we need to allow for the case that neither ATOMIC nor an alternate address will be present and that probably ought to specify what should be done in that case. My personal view is that, if one is reduced to guessing about the address to which a message should be delivered, it is better to bounce it, but others may disagree. > I do not recall whether ALT-ADDRESS is restricted to be a > conversion of the UTF-8 address, but it might be useful to > allow it to be any legacy-encoded address. Having the posting > agent specify the rcpt-to address as a list obviously permits > this freedom; addresses may be entirely independent of each > other. It is not restricted to such a conversion. It is not even restricted to be in the same domain. I think that Yangwoo and I explained why in the framework document but, if not, or if it isn't clear there, we will be happy to do so at length. But the short answer is that, in many countries, some people use transliterations of their actual names while others use translations (sometimes fanciful ones). There are no standard rules. The reason for the different domain? There are several but consider real-mailbox-in-local-script@mail.example.com and translated-or-mapped-name@automatic-content-language-translator.example.com Two other observations about the comma story. These aren't showstoppers, just things to think about before we decide. As many of us are unlucky enough to know, we've got a legacy piece of SMTP syntax that looks like <@a,@b,@c:d@e> Quite independent of the more substantive reasons for abandoning and it and deprecating its use, many implementations of it were astonishingly bad, resulting in other implementations that perhaps got unreasonably permissive. I vaguely remember at least one that would accept as a form of the above. If such code is around, it could get really confused. As we discussed yesterday, this may be the point at which we invoke the "if you implement this extension, you need to clean up your act" rule. But that rule has costs and should be applied carefully. The reason I initially chose a parameter was just to dodge any possible concerns about strange legacy code in this area. I'm not particularly committed to it, but that is why it started the way it did. Dave wrote a bit later... > My suggestion is that the delimiter for the representation of > this address set a) be the same for rfc2822 header fields and > rfc2821 the rcptto command, and > > b) be taken from the common set of lexical specials in rfc2821 > and rfc2822. I think that comma falls in that category. I certainly agree with (b) if we are going down this path. For (a), I suggest it is a desirable target, but that we need to examine and balance other considerations. Those addresses are already a bit different (no name phrase in RCPT, I think no @a:b@c forms in 2822 addresses). And I think the case analysis of what a downgraded form would look like to a legacy POP or IMAP client needs to be done _very_ carefully. Edmon wrote: > Well, if there are certain ways that application treats comma > separated lists of email addresses in the given context > currently, then a different notation would more clearly signal > a need for handling them differently. It feels as if Edmon and Dave aren't communicating, so let me try to explain what I think Edmon is saying. In the most common case, ... RCPT TO: RCPT TO: shows up in the headers as To: foo@bar.baz, bong@bar.baz Now, we can also have To: Melvin , Dick but the no-phrase forms To: , are aesthetically unattractive (and were prohibited entirely prior to, I think, RFC 1123) So, if one is going to have RCPT TO: RCPT TO: That "To:" header is going to look like... To: , bong@bar.baz ???? Well, it is ugly. Users who have been taught to ignore the brackets when name phrases are not present will be confused. And my confidence that MUA implementers will get it right is not what you'd call high. And I think that was, more or less, Edmon's point. john john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 12:11:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkOL-0001rj-BZ; Tue, 21 Mar 2006 12:11:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkOK-0001re-P4 for ima@ietf.org; Tue, 21 Mar 2006 12:11:32 -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 1FLkOK-0008Sx-DT for ima@ietf.org; Tue, 21 Mar 2006 12:11:32 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLkOH-000Hj7-L7; Tue, 21 Mar 2006 12:11:30 -0500 Date: Tue, 21 Mar 2006 12:11:27 -0500 From: John C Klensin To: dcrocker@bbiw.net, Edmon Chung Subject: Re: [EAI] Specify a "use only one of these" address list Message-ID: <69C192CF74DAC3AD5A7B7C42@as-s2n> In-Reply-To: <44202EE3.4070704@dcrocker.net> References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> <44202002.5070602@dcrocker.net> <54F16593913DA2355862804F@as-s2n> <014001c64d03$e59f97c0$5e7360cc@edmontr3> <44202A68.4090304@dcrocker.net> <015d01c64d05$b0a95360$5e7360cc@edmontr3> <44202EE3.4070704@dcrocker.net> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) 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 Sorry, this note crossed my earlier reply in the aether. Comment below. --On Tuesday, March 21, 2006 10:50 -0600 Dave Crocker wrote: > Edmon Chung wrote: >> Well, if there are certain ways that application treats comma >> separated lists of email addresses in the given context >> currently, then a different notation would more clearly >> signal a need for handling them differently. > > OK. Fair concern. > > I believe the answer is: > > Nothing currently handles commas inside angle-brackets. > > So we are talking about brand new code and a brand new > capability. To be strictly correct "nothing currently handles unquoted commas inside angle-brackets". The distinction is important because of the issues we had a brief discussion about yesterday: the quoting conventions are routinely screwed up as addresses are quoted and dequoted as mail passes through various systems. Ned has more experience in this particular area than I do, but I would not be at all surprised if there were systems out there that would take a,b as a syntax variation on "a\,b" or "a,b" and hence as a syntax variation on <"a\,b"> or <"a,b"> And, at that point, code written under an expansive view of the robustness principle to compensate for bad/buggy code could get into trouble with this. See the earlier note about the "clean up your act..." principle, but I fear that, with some implementations, this could cause something that users have expected to work in a particular way to suddenly stop working. And that makes the subset of users who identify themselves as "customers" very unhappy in painful ways. Ned, what do you think? > (I feel safe is asserting that there is no deployed code that > supports the original RFC733 construct...) Yeah. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 12:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkP8-0002Gs-Jt; Tue, 21 Mar 2006 12:12:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkP7-0002Ge-WB for ima@ietf.org; Tue, 21 Mar 2006 12:12:22 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkP6-0008Ub-Ks for ima@ietf.org; Tue, 21 Mar 2006 12:12:21 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LHCsp9019356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 09:12:55 -0800 Message-ID: <442033F5.1000903@bbiw.net> Date: Tue, 21 Mar 2006 11:12:21 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Specify a "use only one of these" address list References: <441F4814.1000101@dcrocker.net> <442007E1.7010203@dcrocker.net> <6C6B32061125E2BDCBEA568B@as-s2n> In-Reply-To: <6C6B32061125E2BDCBEA568B@as-s2n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 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 > My personal view is that, if one is reduced to guessing about the > address to which a message should be delivered, it is better to bounce > it, but others may disagree. I believe that an agent associated with an author or an agent associated with a recipient can reasonably be authorized to make some kinds of guesses. I believe it would be disastrous to have a standard that authorizes any sort of intermediary between them to make guesses. d/ > It feels as if Edmon and Dave aren't communicating, so let me try to > explain what I think Edmon is saying. > > In the most common case, > ... > RCPT TO: > RCPT TO: > shows up in the headers as > To: foo@bar.baz, bong@bar.baz > Now, we can also have > To: Melvin , Dick > but the no-phrase forms > To: , > are aesthetically unattractive (and were prohibited entirely prior to, I > think, RFC 1123) > > So, if one is going to have > RCPT TO: > RCPT TO: > That "To:" header is going to look like... > To: , bong@bar.baz yes. i believe the reality is that there is no "pretty" way to provide the alterntive addresses for the same recipient. so we merely get to debate among ugly choices. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 12:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkYA-0007US-1n; Tue, 21 Mar 2006 12:21:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkY8-0007UI-Jx for ima@ietf.org; Tue, 21 Mar 2006 12:21:40 -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 1FLkY8-0000MR-8u for ima@ietf.org; Tue, 21 Mar 2006 12:21:40 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLkY5-000HkO-Rn; Tue, 21 Mar 2006 12:21:38 -0500 Date: Tue, 21 Mar 2006 12:21:36 -0500 From: John C Klensin To: Dave Crocker Subject: Re: [EAI] Specify a "use only one of these" address list Message-ID: <5A7B17519A01D58578650978@as-s2n> In-Reply-To: <442033F5.1000903@bbiw.net> References: <441F4814.1000101@dcrocker.net> <442007E1.7010203@dcrocker.net> <6C6B32061125E2BDCBEA568B@as-s2n> <442033F5.1000903@bbiw.net> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 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 --On Tuesday, March 21, 2006 11:12 -0600 Dave Crocker wrote: >> My personal view is that, if one is reduced to guessing about >> the address to which a message should be delivered, it is >> better to bounce it, but others may disagree. > > I believe that an agent associated with an author or an agent > associated with a recipient can reasonably be authorized to > make some kinds of guesses. I certainly agree with that principle. I get a little more anxious about an agent associated with a class of users, but not knowing which user is the recipient, making guesses but can tolerate it. In particular, you know the mixed history of nearest-match address guessing systems. The most difficult of those problems is having an address that works well and without comment for an extended period suddenly stop (or end up somewhere unexpected) because a conflicting address or nearer match is added to the receiving system. Of course, if one carries that concern far enough, the logical conclusion is that all of this address substitution is a bad idea, a bad idea vaguely related to the "your address isn't deliverable, the message has been sent to ...." reply status from 821. And that brings us to the conclusion that the right way to deal with an i18n address that cannot be transferred and delivered without transformation is to bounce it with an explanation that ASCII addresses and headers are needed in the path to the destination. I'm not ready to go there, and I suspect I'm a lot more ready than many others, but... > I believe it would be disastrous to have a standard that > authorizes any sort of intermediary between them to make > guesses. Again agreed. Beyond that, isolating the cases may require a whiteboard. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 12:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkk1-00009p-TX; Tue, 21 Mar 2006 12:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkk0-00009k-M6 for ima@ietf.org; Tue, 21 Mar 2006 12:33:56 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkjz-0000jr-Bf for ima@ietf.org; Tue, 21 Mar 2006 12:33:56 -0500 Received: from edmontr3 ([204.96.115.94]) by server (8.12.8/8.12.8) with SMTP id k2LG6m30004678 for ; Tue, 21 Mar 2006 11:06:54 -0500 Message-ID: <01a601c64d0d$9f2259e0$5e7360cc@edmontr3> From: "Edmon Chung" To: References: <441F4814.1000101@dcrocker.net><442007E1.7010203@dcrocker.net> <6C6B32061125E2BDCBEA568B@as-s2n> <442033F5.1000903@bbiw.net> Subject: Re: [EAI] Specify a "use only one of these" address list Date: Tue, 21 Mar 2006 12:32:52 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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="===============0108362326==" Errors-To: ima-bounces@ietf.org --===============0108362326== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ3JvY2tlciIgPGRj cm9ja2VyQGJiaXcubmV0Pg0KPiB5ZXMuICBpIGJlbGlldmUgdGhlIHJlYWxpdHkgaXMgdGhhdCB0 aGVyZSBpcyBubyAicHJldHR5IiB3YXkgdG8gcHJvdmlkZSB0aGUgDQo+IGFsdGVybnRpdmUgYWRk cmVzc2VzIGZvciB0aGUgc2FtZSByZWNpcGllbnQuICBzbyB3ZSBtZXJlbHkgZ2V0IHRvIGRlYmF0 ZSBhbW9uZyANCj4gdWdseSBjaG9pY2VzLg0KDQpJbiB0aGF0IGNhc2UsIEkgc3VwcG9zZSBpdCBp cyBzdGlsbCBiZXR0ZXIgdG8gYXZvaWQgdGhlIHVzZSBvZiB0aGUgY29tbWEgYXMgaXQgY3JlYXRl cyBhZGRpdGlvbmFsICJ1Z2xpbmVzcyIgb3IgY29uZnVzaW9uIGluIG15IHBlcnNwZWN0aXZlLiAg RXZlbiB0aG91Z2ggd2l0aGluIHRoZSBzdHJpY3QgY29udGV4dCB0aGUgY29tbWEgZG9lcyBub3Qg YWxyZWFkeSBjYXJyeSBtZWFuaW5nLCBpbiB0aGUgY29udGV4dCBvZiBlbWFpbHMsIGVtYWlsIGFk ZHJlc3NlcywgZW1haWwgaGVhZGVycywgZXRjLCBhIGNvbW1hIHNlcGFyYXRlZCBsaXN0IG9mIGFk ZHJlc3NlcyBkb2VzIGNhcnJ5IGNlcnRhaW4gY29udmVudGlvbmFsIG1lYW5pbmcsIHRoYXQgaXMg bm90IGVudGlyZWx5IGNvbmdydWVudCB3aXRoIHRoZSBpbnRlbmRlZCB1c2FnZSBoZXJlLi4uDQpF ZG1vbg== --===============0108362326== 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 --===============0108362326==-- From ima-bounces@ietf.org Tue Mar 21 13:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlQ2-0002WX-Kw; Tue, 21 Mar 2006 13:17:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlQ0-0002VA-L2 for ima@ietf.org; Tue, 21 Mar 2006 13:17:20 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlPz-0002mR-BF for ima@ietf.org; Tue, 21 Mar 2006 13:17:20 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 495B52596E6; Tue, 21 Mar 2006 19:15: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 26948-10; Tue, 21 Mar 2006 19:15:28 +0100 (CET) Received: from [130.129.129.255] (DHCP-Wireless-129-255.ietf65.org [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A03A2596E3; Tue, 21 Mar 2006 19:15:26 +0100 (CET) Message-ID: <44204327.6050707@alvestrand.no> Date: Tue, 21 Mar 2006 12:17:11 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] UTF8 POP and character sets References: 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: 08170828343bcf1325e4a0fb4584481c Cc: 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 John C Klensin wrote: > So the question that started yesterday morning was whether it is time > to define an NVT-i18n (net-Unicode?). Given how we have gotten here, > that form would presumably be UTF-8 with CRLF line termination, but > the question is whether, even if we assume a Unicode world, we are > ready to make an NVT-like rule rather than having UCS-2 or UCS-4, > sundry bit orders, etc., floating around the network as "Unicode". > And, of course, for other character codings, the need becomes even > more urgent. One reading of RFC 2277 (IETF Policy on Character Sets and Languages) is that it allows a protocol to do exactly that, while also permitting a protocol to permit other choices. It may be time to consider removing or restricting the leeway. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 20:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsWx-00019m-85; Tue, 21 Mar 2006 20:52:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsWw-00019h-Su for ima@ietf.org; Tue, 21 Mar 2006 20:52: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 1FLsWv-0006hf-JW for ima@ietf.org; Tue, 21 Mar 2006 20:52:58 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FLsWu-000IW4-I3; Tue, 21 Mar 2006 20:52:56 -0500 Date: Tue, 21 Mar 2006 20:52:55 -0500 From: John C Klensin To: Chris Newman , ima@ietf.org Subject: Re: [EAI] Specify a "use only one of these" address list Message-ID: <81D1364726E8CEFB50663145@as-s2n.ietf65.org> In-Reply-To: References: <441F4814.1000101@dcrocker.net> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.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 Just for the record, I think this is a great idea. Where I'm confused about what to do (and worried) is about how to map the syntax into the headers (see earlier note). If we need to do in the headers, then we need to look at the tradeoffs and priorities between: * doing one thing that seems right for envelope and another thing that seems right for headers and * doing something that can be done consistently in both places. john --On Tuesday, March 21, 2006 00:38 -0600 Chris Newman wrote: > If we're using: > > phrase > > in RFC 2822 + UTF 8 headers, why don't we use: > > MAIL FROM: > > in SMTP instead of the ALT-ADDRESS parameter? > > The similar looking protocol is an obvious, but minor > advantage of this approach. >... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 21 23:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvBb-0004kr-9G; Tue, 21 Mar 2006 23:43:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvBa-0004kW-3E for ima@ietf.org; Tue, 21 Mar 2006 23:43:06 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLvBY-0004HD-AA for ima@ietf.org; Tue, 21 Mar 2006 23:43:06 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k2M4h2uf009493 for ; Tue, 21 Mar 2006 21:43:03 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWI00C01HSV4M00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 21 Mar 2006 21:43:02 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([204.96.114.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWI00EJOIFMKL10@mail-amer.sun.com>; Tue, 21 Mar 2006 21:43:02 -0700 (MST) Date: Tue, 21 Mar 2006 22:45:02 -0600 From: Chris Newman Subject: Re: [EAI] UTF8 POP and character sets In-reply-to: To: John C Klensin Message-id: <09EEB8A4933E7BA57E229730@100.114.96.204.in-addr.arpa> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 John C Klensin wrote on 3/20/06 18:02 -0500: > It seems to me that the list of character sets that SHOULD be supported > potentially adds considerable complexity to the protocol and doesn't > accomplish much. The charset requirements are specifically for the purpose of up-conversion from RFC 2047/2231 to native UTF-8. I do not require or recommend any changes to bodies, body charsets or body transfer encodings. RFC 2047 interoperability is mediocre in the field (particularly when it comes to whitespace handling between encoded words) and 2231 support is uncommon. So the implicit intention behind the POP document (and upcoming IMAP document) up-conversion requirements is to obsolete the encoding mechanisms that don't work well as quickly as possible. Indeed, these encoding mechanisms have caused my product team a truly incredible amount of pain. The goal of deprecating 2047 and 2231 as quickly as possible is the primary reason why I'm interested in this effort. UTF-8 local parts just happen to be a nice side-effect of the UTF-8 header proposal from my perspective. The charset requirements are written so an implementer can simply use an open-source library such as ICU to make a POP server fully compliant, so the implementation burden is minor. And it's only a "SHOULD" for the rare cases where a POP server can't deal with 1.5MB shared library for charset conversions. The primary value of POP is how simple it is to write a client. Deprecating the requirement to support 2047/2231 will improve the situation so it's worth some server effort. Indeed, POP clients have the worst track-record on 2047 compliance. > (2) That question is clearly more general that this WG's mission. Is it > time to formally ask the IAB to convene a process for advising the > applications community whether we are ready to take such a step? While I like the move in the direction of UTF-8, I see no reason to push it more than RFC 2277 does today. MIME body charset labels and encodings work just fine and don't seem to cause any significant problems. There are many charset conversion libraries which are competent. I do see a reason to deprecate 2047/2231 as quickly as possible, but that's for interoperability reasons; the mandated charset conversions for header charsets are simply a necessary side effect of replacing the problematic encodings with UTF-8 headers. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 22 00:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwLl-0001qc-NB; Wed, 22 Mar 2006 00:57:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwLl-0001qX-6q for ima@ietf.org; Wed, 22 Mar 2006 00:57:41 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLwLe-0007Gv-Qt for ima@ietf.org; Wed, 22 Mar 2006 00:57:41 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2M5vY8u018846 for ; Tue, 21 Mar 2006 22:57:34 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWI00F01LP1JP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 21 Mar 2006 22:57:34 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([204.96.114.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWI00EQJLVTKL10@mail-amer.sun.com>; Tue, 21 Mar 2006 22:57:34 -0700 (MST) Date: Tue, 21 Mar 2006 23:59:32 -0600 From: Chris Newman Subject: Re: [EAI] Specify a "use only one of these" address list In-reply-to: <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> To: Edmon Chung , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <441F4814.1000101@dcrocker.net> <012d01c64cf3$e99d6c90$5e7360cc@edmontr3> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Ned Freed 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 Edmon Chung wrote on 3/21/06 9:27 -0500: > A small suggestion... > We talked about using a separator for the UTF8 and ASCII addresses within the > angle brackets and started using the comma. This seems to be a bit confusing > especially considering what Dave pointed out in RFC733, since commas are > usually used for lists, i.e. "ALL" rather than "OR". Would suggest using a > different separator, e.g. a slash "/" or a vertical bar "|": > > This is a great suggestion from a usability standpoint as it makes the "OR" property clearer to end-users in the event the mail client displays the headers unprocessed. Unfortunately, both "/" and "|" are problematic because they are not specials and thus cause lexical problems (the serious one is that the space after a non-special delimiter would be lexically critical and that's non-intuitive so it will cause problems). If we want a more user-friendly syntax than "," and we're limited to the specials, the option that comes to mind is: I really like this syntax as it makes the subordinate nature of the ascii address clear. Unfortunately, the following case: would force a change to the lexical model for addresses as nested [] are not permitted today. I don't have a good sense of how many implementations have a lexical processing step and how disruptive this would be to those implementations. I'm not sure if that disruption would outweigh the usability benefit. Thoughts? - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 22 01:14:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwbr-0004aG-G7; Wed, 22 Mar 2006 01:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwbp-0004a6-Na for ima@ietf.org; Wed, 22 Mar 2006 01:14:17 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLwbm-0007wG-W0 for ima@ietf.org; Wed, 22 Mar 2006 01:14:17 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2M6ED8u005899 for ; Tue, 21 Mar 2006 23:14:14 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWI00301KGDF200@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 21 Mar 2006 23:14:13 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([204.96.114.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWI002YQMNM7C20@mail-amer.sun.com> for ima@ietf.org; Tue, 21 Mar 2006 23:14:13 -0700 (MST) Date: Wed, 22 Mar 2006 00:16:13 -0600 From: Chris Newman To: ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] Input from Sieve WG 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 Additional items for the EAI issues list: * Sieve extension for EAI. * A few years ago, Alexey had an SMTP language command to localize SMTP error responses. While we're working on i18n, should we revive that draft from the dustbin? * Should the POP EAI draft add a LANG command to negotiate UTF-8 error text responses? (IMAP already has an i18n draft for this purpose) - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 22 02:12:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxVc-0000kB-RX; Wed, 22 Mar 2006 02:11:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxVb-0000k6-Rr for ima@ietf.org; Wed, 22 Mar 2006 02:11:55 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLxVX-0001a3-7Y for ima@ietf.org; Wed, 22 Mar 2006 02:11:55 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2M7BhSD025291 for ; Wed, 22 Mar 2006 00:11:48 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWI00I01PAR1D00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 22 Mar 2006 00:11:43 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([204.96.114.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWI00EV0PBFKL10@mail-amer.sun.com>; Wed, 22 Mar 2006 00:11:43 -0700 (MST) Date: Wed, 22 Mar 2006 01:13:42 -0600 From: Chris Newman Subject: Re: [EAI] ATOMIC parameter In-reply-to: To: John C Klensin , ima@ietf.org Message-id: <809176333326EF4929F59B0E@100.114.96.204.in-addr.arpa> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <03BC0EB923B9B7B41639B8F4@186.114.96.204.in-addr.arpa> X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 need to break the contentious use case into a two sub-cases (neither case has an alternate address): 1. MAIL FROM: RCPT TO: ... From: name 2. MAIL FROM: RCPT TO: ... From: name If I understand your position, it is always acceptable to pass case 1 forward, even if the headers must be down-converted. And I observe that if the recipient replies to this message after down-conversion, the RCPT TO in the reply will use the down-converted address from the From header. Furthermore, in case 2, you believe it is better to bounce rather than downgrade because once the envelope is downgraded any later bounce will be more confusing to the originator. Do I correctly understand your position? My position is that if we define a 7-bit down-conversion for utf-8 local parts, there is no way to prevent the originator's mail system from seeing that 7-bit down-conversion in some cases. As a result, it will at least be a best practice (if not a SHOULD or MUST) for the mail system which supports utf-8 local parts to also support the 7-bit down-conversion. As long as the ACE is easy to recognize and 100% reversible, this seems like a simple problem for the mail system to solve. And given that, the principle that we should bounce as a near last resort trumps any concern that the down-converted return address might cause problems. (And I'd like to experiment with putting the xtext-encoded UTF-8 original recipient in the ORCPT parameter to mitigate your concern further). So I view "ATOMIC=N" as an explicit statement that the originator is deliberately violating best practices and has no wish to communicate with anyone who can't preserve the address in its pure form. If we want to minimize partitioning problems, then I believe we should not make the protocol more complex simply to cater to this case. Now as I'm an engineer rather than a politician, I'm willing to accept that I may be ignorant of political realities in this case and would be willing to compromise if ATOMIC had a clearer name (e.g. BOUNCE-BEFORE-7BIT-GATEWAY=Y). But I do not see a valid engineering argument to ever do anything other than an implicit "ATOMIC=Y". I also see no problem with giving systems that embed processing instructions in the local part a simple choice: either use 7-bit only, or support ACE upgrade as well as UTF-8. If such systems find our present local-part ACE too complex, perhaps we should choose a simpler one (e.g., base 32 with a prefix). - Chris John C Klensin wrote on 3/20/06 18:23 -0500: > Chris, > > I've read your note several times to see if I can figure out where we > disagree. I think it is the nature of the things that are encoded in local > parts and, ultimately, the reason why that "no local-part interpretation by > senders or relays" rule is there. > > Given that rule, if one is sending UTF-8 address material to a current, > RFC821-compliant-only final receiver (the worst case as far as I know), I > think that one needs to know exactly how that receiver interprets and decodes > addresses, and the order in which it does so, in order to downgrade the > addresses. Certainly downgrading other header, or even body, material is not > problematic. This many not be problematic for POP3 or IMAP because any > mailbox routing or other transformations that will be applied by the delivery > SMTP server will presumably be applied before anything gets to the mail store. > > But, for in-transit downgrading in the general case, I think that any > downgrade/recoding mechanism we can devise is a shot in the dark, one that > risks a sender eventually getting a bounce message about an address he or she > has never seen before. Personally, I think _that_ is the worst possible case: > the message gets bounced rather than delivered, and the error message is > unintelligible. If the message is going to bounce, better to have it bounce > from a point at which a plausible error report can be generated. > > Now, a way to read my analysis and yours together is that we need to > drastically narrow the cases for which ATOMIC is relevant. If, for example, > we have a message with UTF-8 header material but all-ASCII addresses, then > one clearly can, and should, downgrade the headers (using encoded words or > the equivalent). (I think this makes the case for no UTF-8 in header _names_ > even stronger.) It is only when the addresses (actually the address > local-parts because we can "downgrade" domain names to punycode) themselves > are in UTF-8 and there is no next-hop support are we in serious trouble. And > it was that case for which ATOMIC was designed. > > That still leaves an interesting case in which the message can be accurately > delivered because the local parts in all of the forward-pointing addresses > are ASCII but the backward-pointing address(es) are not. And that is the old > argument about whether a message should be delivered even if it is known that > it cannot be replied to. You would, I think, say "yes", as would I. The > antispam community generally says "no". And I hope that we can avoid having > to resolve it here. > > john > > > --On Monday, March 20, 2006 02:22 -0600 Chris Newman > wrote: > >> Although I'm sympathetic to the motivations behind the ATOMIC >> parameter, I believe it is an incorrect bias of protocol >> purity over operational robustness. >> >> As a matter of operational robustness it is almost always >> better to move questionable email material forward than to >> bounce it. If the recipient gets something that appears to be >> corrupt, they will contact the sender to resend the material. >> If the message is important, the recipient will probably have >> out-of-band mechanisms to contact the sender that are more >> likely to work than the MAIL FROM address (e.g. a cell phone >> number, etc). >> >> On the flip side, it is quite easy to mis-configure the MAIL >> FROM address and the problem probably won't be noticed unless >> the person who did so gets a complaint from a colleague which >> will only happen if the message moves forward and the >> colleague's attempt to reply fails. We also have widely >> deployed systems that do inappropriate things with MAIL FROM >> that can cause loops or other badness when a bounce happens. >> And in the new world of Spam blowback, many people simply >> ignore almost all bounces (myself included, unfortunately). >> >> This is very unfortunate for those of us who care a great deal >> about protocol purity. It's really painful to pass >> non-interoperable junk forward but the outcome for the users >> involved is more likely to be better, so it's usually the >> right thing to do. >> >> Which brings us to the ATOMIC parameter. We all like the rule >> which forbids local part interpretation by remote systems and >> I respect the ATOMIC parameter approach as a clever way to >> preserve that rule. Unfortunately, ATOMIC=no leaves MTAs in >> an untenable situation: either ignore the standard, >> downconvert and pass forward or bounce. Unfortunately, >> robustness suggests the right answer is to ignore the >> standard. Were I implementing a system, I'd probably ignore >> the standard for this case by default and include an option to >> follow the standard. But having "do the right thing for >> users" and "comply with the standard" as two separate settings >> is not something I like (how often do people use the "strict >> ANSI" option on their C compiler?). >> >> Use of a UTF-8 local part should implicitly grant permission >> to use the 7-bit-encoded alias of that local part. This is >> not significantly different from the rule that >> list-addr@example.com implies the existence of >> list-addr-request@example.com and the converse is true. >> Furthermore, if someone wants to use structured UTF-8 >> addresses for special processing and do so while interacting >> with a 7-bit-only system, I believe it's reasonable to insist >> they upgrade their special processing system to remove the >> 7-bit encoding prior to processing. And as much as I like >> sub-addresses, their use is simply not widespread enough to >> merit additional design complexity simply to avoid requiring >> up-conversion at that point in the system. >> >> Finally, down-conversion is a non-negotiable feature for some >> implementers (myself included). I have to be able to >> down-convert the UTF-8 local parts in the headers, even if an >> alternate address is unavailable (and it doesn't change things >> if the spec requires an alternate address be available, as we >> still have to deal with the non-compliant case in quality >> software). So I suggest ATOMIC=yes should be implicit from >> the use of UTF-8 and thus not necessary to include in the >> protocol specification. >> >> - Chris >> >> >> _______________________________________________ >> 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 > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 22 02:45:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLy28-0004cn-VX; Wed, 22 Mar 2006 02:45:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLy28-0004ci-H5 for ima@ietf.org; Wed, 22 Mar 2006 02:45:32 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLy24-0002jN-Fb for ima@ietf.org; Wed, 22 Mar 2006 02:45:32 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2M7jRQj011476 for ; Wed, 22 Mar 2006 00:45:27 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWI00901N2CDW00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 22 Mar 2006 00:45:27 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org ([204.96.114.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWI001B3QVOG610@mail-amer.sun.com>; Wed, 22 Mar 2006 00:45:27 -0700 (MST) Date: Wed, 22 Mar 2006 01:47:27 -0600 From: Chris Newman Subject: Re: [EAI] An appeal ab out protocol-readng..b In-reply-to: <053233FEFF4BB10CFB1F52B4@as-s2n> To: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <053233FEFF4BB10CFB1F52B4@as-s2n> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 While I largely agree with John, I believe some compromise is in order. When I participate in i18n or security work, I can not become an expert in those areas. I merely have to get to the level of "educated and aware of the gaps in my knowledge" to participate usefully. And my applications perspective can be insightful despite some ignorance of i18n/security issues on my part. The same is true of people with i18n or usability expertise who participate in this effort. While it is helpful for them to learn what they can about the email protocol suite, I do not expect them to become experts on the subtleties. For example, one contributor made a rather insightful comment from a usability perspective despite his lack of knowledge about lexical analysis of email addresses (an area few people understand well). And I was able to make a constructive suggestion based on his insight. It would be a shame to miss such insights. So please participate if you feel you have a useful insight. But please learn what you can about the email protocol suite as John requested, because that can improve the quality of your contributions and help the group conclude faster. Thank you, - Chris John C Klensin wrote on 3/21/06 11:14 -0500: > I'd like to make a request of participants in this WG effort, especially > those who come to the work from the perspective of internationalization > efforts rather than email ones. It is sort of an extension of expecting > people who haven't read the documents to sit in back and be quiet in meetings. > > This effort is very different from the IDN/IDNA one in at least one very > important way. With IDNA, as soon as the decision was made that the > characters that actually went into the DNS would conform to the hostname/LDH > rule, it because possible to essentially ignore how the DNS worked > internally. Whether doing so was wise or not is something we will continue > to debate for years, but it was possible. This effort, at least in the model > contemplated in the WG charter and preliminary documents, actually does need > to interwork with the existing email environment and do so in very > fundamental ways. If we are going to make progress, everyone is going to > need to be familiar with the relevant email specifications -- RFC 2821 and > 2822 for everyone; the MIME specs, especially those pieces that deal with > internal body part headers, encoded words, registrations, constraints on > multipart types and encodings for people thinking about downgrades; the POP > and IMAP specs for people thinking about extensions to those protocols, etc. > Discussions without that familiarity will, at best, cost us a huge amount of > time. And on-list tutorials on mail fundamentals are just not a way to move > the WG forward on the many issues we need to resolve. > > This stuff is complex and subtle. We got a dramatic demonstration of just > how subtle it is yesterday when we discovered that the authors or RFC 822 and > 2822 could remember just what went into a particular header field (I assure > them that I would do much worse with 2822 -- I have learned to never answer a > question without checking the text and I get myself into trouble almost every > time I violate that principle). > > So, please, try to read and understand the documents -- not only the WG > documents but the relevant basic email specifications -- before posting > comments that good lead us on what are often called in English "wild goose > chases". _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 22 07:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2GR-0008J8-9x; Wed, 22 Mar 2006 07:16:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2GQ-0008Ii-B9 for ima@ietf.org; Wed, 22 Mar 2006 07:16:34 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM2GN-0004aY-Gs for ima@ietf.org; Wed, 22 Mar 2006 07:16:34 -0500 Received: from host81-144-65-229.midband.mdip.bt.net ([81.144.65.229]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4421401d.1b1.2224 for ima@ietf.org; Wed, 22 Mar 2006 12:16:29 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k2MACo419848 for ; Wed, 22 Mar 2006 10:12:50 GMT To: "ima@ietf.org" Subject: Re: [EAI] silly states and header label Date: Wed, 22 Mar 2006 10:12:46 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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, 20 Mar 2006 07:15:41 -0000, Chris Newman wrote: > If we must use a labeling mechanism, I suggest using a zero-width > non-joiner UTF-8 character at the beginning of the message. UTF-8 aware > SMTP servers are required to insert Received and Return-Path after the > zero-width non-joiner character. That has some other nice features -- > it permits instant detection of the encoding for certain out-of-band > mechanisms (e.g. UTF-8 editors), it has no impact on display, and if the > message gets to a non-8-bit system the failure is likely to be immediate > and more obvious rather than later and more obscure (indeed it's so > obvious that legacy systems can be patched to check for it easily). I'm > still not sure those benefits outweigh the cost of silly states, but > it's closer to making the cut. Please! Can we establish a basic principle that any feature in a message that can cause some "technical effect" MUST be visible and understandable by a human reader (I grant that the feature may be written in UTF-8, but it must still exhibit a readable text to a human equipped with means to display that UTF-8). So no "zero-width non-joiner UTF-8 characters" in critical parts of the protocol. But it goes further than that. I think everyone agrees that the present ASCII local-part is far too permissive - essentially it seems to allow any combination of ASCII characacters that could not be interpreted as anything else according to RFC (2)822. Hence people devise all sorts of obscure ways of encoding secret information in them, and hence the rule that only the agent at the very end is allowed to interpret what is inside them. If that was a mistake (too late to fix now), then let us not make the same mistake again. It is entirely within our remit to determine what is to be allowed/forbidden within "UTF-8-extended-local-parts", and the first rule there should be "WYSIWYG". That means no invisible characters in there, and no possibility to assign different meanings to different Unicode characters that may be rendered as the same. IOW, the local-parts should be normalized in the Unicode sense at least to level NFC, and maybe to NFKC. Or, equivalently, by using 'stringprep' or some other '*prep'. Only when that basic decision has been made can we begin to consider whether an ATOMIC parameter is needed as well. And we can't really answer that until we have some plausible examples of what hacks end-user-agents might actually want to perform. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Mar 23 11:47:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSxk-0002Ht-NI; Thu, 23 Mar 2006 11:47:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSxj-0002HR-Q3 for ima@ietf.org; Thu, 23 Mar 2006 11:47:03 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSxi-0002nH-GC for ima@ietf.org; Thu, 23 Mar 2006 11:47:03 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D501A259732; Thu, 23 Mar 2006 17:45:13 +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 10762-04; Thu, 23 Mar 2006 17:45:10 +0100 (CET) Received: from [130.129.129.255] (DHCP-Wireless-129-255.ietf65.org [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id D83D1259730; Thu, 23 Mar 2006 17:45:09 +0100 (CET) Message-ID: <4422D0FF.5070008@alvestrand.no> Date: Thu, 23 Mar 2006 10:46:55 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] silly states and header label References: 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: 08170828343bcf1325e4a0fb4584481c 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 Charles Lindsey wrote: > Please! Can we establish a basic principle that any feature in a message > that can cause some "technical effect" MUST be visible and understandable > by a human reader (I grant that the feature may be written in UTF-8, but > it must still exhibit a readable text to a human equipped with means to > display that UTF-8). No, I think establishing this as a basic principle would be inappropriate. For instance, there are many contexts in which the difference between LF and CR/LF is not visible to humans; neither is the difference between unnormalized and normalized Unicode text - yet both are going to be important features of IMA messages. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 23 11:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSza-0005iK-AT; Thu, 23 Mar 2006 11:48:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSzY-0005gZ-Vy for ima@ietf.org; Thu, 23 Mar 2006 11:48:56 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSzX-0002o7-MQ for ima@ietf.org; Thu, 23 Mar 2006 11:48:56 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47034259732; Thu, 23 Mar 2006 17:47: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 10762-06; Thu, 23 Mar 2006 17:47:03 +0100 (CET) Received: from [130.129.129.255] (DHCP-Wireless-129-255.ietf65.org [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id 300E6259730; Thu, 23 Mar 2006 17:47:03 +0100 (CET) Message-ID: <4422D171.3050000@alvestrand.no> Date: Thu, 23 Mar 2006 10:48:49 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Charles Lindsey Subject: Permissivity of local-parts (Re: [EAI] silly states and header label) References: 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: de4f315c9369b71d7dd5909b42224370 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 Administrativia: If people change the subject, PLEASE change the subject line! And if you have multiple issues to raise, PLEASE create more than one thread! > But it goes further than that. I think everyone agrees that the present > ASCII local-part is far too permissive - essentially it seems to allow > any > combination of ASCII characacters that could not be interpreted as > anything else according to RFC (2)822. Hence people devise all sorts of > obscure ways of encoding secret information in them, and hence the rule > that only the agent at the very end is allowed to interpret what is > inside > them. I have detected no such consensus. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 23 15:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWHd-0002vk-Tt; Thu, 23 Mar 2006 15:19:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWHc-0002sx-Jg for ima@ietf.org; Thu, 23 Mar 2006 15:19:48 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWH3-0003x8-Aj for ima@ietf.org; Thu, 23 Mar 2006 15:19:48 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2NKJBQj024043 for ; Thu, 23 Mar 2006 13:19:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWL00I01JX59O00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 23 Mar 2006 13:19:11 -0700 (MST) Received: from dhcp-wireless-128-202.ietf65.org (DHCP-Wireless-128-202.ietf65.org [130.129.128.202]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWL00FEPKFVJL60@mail-amer.sun.com>; Thu, 23 Mar 2006 13:19:11 -0700 (MST) Date: Thu, 23 Mar 2006 14:21:14 -0600 From: Chris Newman Subject: Re: Permissivity of local-parts (Re: [EAI] silly states and header label) In-reply-to: <4422D171.3050000@alvestrand.no> To: Harald Alvestrand , Charles Lindsey Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <4422D171.3050000@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 It would be a good idea to exclude obs-local-part and obs-domain syntax when defining the ABNF for UTF-8-addr-spec in a message header given we have IETF consensus to deprecate that syntax. But I'd oppose more extensive deprecation of syntax as it would distract from more important issues. - Chris Harald Alvestrand wrote on 3/23/06 10:48 -0600: > Administrativia: If people change the subject, PLEASE change the subject line! > > And if you have multiple issues to raise, PLEASE create more than one thread! > >> But it goes further than that. I think everyone agrees that the present >> ASCII local-part is far too permissive - essentially it seems to allow >> any >> combination of ASCII characacters that could not be interpreted as >> anything else according to RFC (2)822. Hence people devise all sorts of >> obscure ways of encoding secret information in them, and hence the rule >> that only the agent at the very end is allowed to interpret what is >> inside >> them. > I have detected no such consensus. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 23 22:19:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMcpQ-0003Ng-Ph; Thu, 23 Mar 2006 22:19:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMcpP-0003KI-8p for ima@ietf.org; Thu, 23 Mar 2006 22:19:07 -0500 Received: from sov-mail-b0013.gradwell.net ([193.84.87.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMcpM-0000Wz-GM for ima@ietf.org; Thu, 23 Mar 2006 22:19:07 -0500 Received: from host81-144-64-71.midband.mdip.bt.net ([81.144.64.71]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44236519.7fc.ac7 for ima@ietf.org; Fri, 24 Mar 2006 03:18:49 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k2NIvj409186 for ; Thu, 23 Mar 2006 18:57:46 GMT To: "ima@ietf.org" Subject: Re: [EAI] silly states and header label References: <4422D0FF.5070008@alvestrand.no> Message-ID: Date: Thu, 23 Mar 2006 18:57:35 -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: <4422D0FF.5070008@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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, 23 Mar 2006 16:46:55 -0000, Harald Alvestrand wrote: > Charles Lindsey wrote: >> Please! Can we establish a basic principle that any feature in a message >> that can cause some "technical effect" MUST be visible and >> understandable >> by a human reader (I grant that the feature may be written in UTF-8, but >> it must still exhibit a readable text to a human equipped with means to >> display that UTF-8). > No, I think establishing this as a basic principle would be > inappropriate. > > For instance, there are many contexts in which the difference between LF > and CR/LF is not visible to humans; neither is the difference between > unnormalized and normalized Unicode text - yet both are going to be > important features of IMA messages. I grant you that you can mostly ingnore the difference between CRLf and a naked LF (which is not supposed to happen on the wire anyway), but the matter of unnormalized Unicode text is a good illustration of my point. If some unnormalized text appears in a header, and normalizing that text would lead to a different outcome somewhere in the protocol, then that would be a Bad Thing. So it hardly matters if some unnormlized text appears in a Subject header (though I would regard it as bad practice), but unnormalized text in a local-part could make quite a difference. Recall that the IDNA people took greate care to ensure (through the use of nameprep) that only the normalized form of a domain name was to be meaningful. We should learn from that when designing the local-part. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Fri Mar 24 09:00:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmqA-0003eA-OY; Fri, 24 Mar 2006 09:00:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmq7-0003bW-1w for ima@ietf.org; Fri, 24 Mar 2006 09:00:31 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmq4-0000RL-Hp for ima@ietf.org; Fri, 24 Mar 2006 09:00:31 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F9AA259774; Fri, 24 Mar 2006 14:58:39 +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 16063-01; Fri, 24 Mar 2006 14:58:34 +0100 (CET) Received: from [130.129.129.255] (DHCP-Wireless-129-255.ietf65.org [130.129.129.255]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF4ED25973A; Fri, 24 Mar 2006 14:58:33 +0100 (CET) Message-ID: <4423FB74.7050203@alvestrand.no> Date: Fri, 24 Mar 2006 08:00:20 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Charles Lindsey Subject: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@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: 7aafa0432175920a4b3e118e16c5cb64 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 Charles Lindsey wrote: > On Thu, 23 Mar 2006 16:46:55 -0000, Harald Alvestrand > wrote: > >> Charles Lindsey wrote: >>> Please! Can we establish a basic principle that any feature in a >>> message >>> that can cause some "technical effect" MUST be visible and >>> understandable >>> by a human reader (I grant that the feature may be written in UTF-8, >>> but >>> it must still exhibit a readable text to a human equipped with means to >>> display that UTF-8). >> No, I think establishing this as a basic principle would be >> inappropriate. >> >> For instance, there are many contexts in which the difference between >> LF and CR/LF is not visible to humans; neither is the difference >> between unnormalized and normalized Unicode text - yet both are going >> to be important features of IMA messages. > > I grant you that you can mostly ingnore the difference between CRLf > and a naked LF (which is not supposed to happen on the wire anyway), > but the matter of unnormalized Unicode text is a good illustration of > my point. I thought it was a refutation of your point. But no matter; we seem to agree that being precise about the requirements on normalization of Unicode text is important. > > If some unnormalized text appears in a header, and normalizing that > text would lead to a different outcome somewhere in the protocol, then > that would be a Bad Thing. So it hardly matters if some unnormlized > text appears in a Subject header (though I would regard it as bad > practice), but unnormalized text in a local-part could make quite a > difference. Recall that the IDNA people took greate care to ensure > (through the use of nameprep) that only the normalized form of a > domain name was to be meaningful. We should learn from that when > designing the local-part. > > --Charles H. Lindsey ---------At Home, doing my own thing------------------------ > > Tel: +44 161 436 6131 Fax: +44 161 436 6133 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 > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 26 14:28:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNauj-00029X-Ti; Sun, 26 Mar 2006 14:28:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNaui-00029S-Ix for ima@ietf.org; Sun, 26 Mar 2006 14:28:36 -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 1FNauh-0004uS-Vb for ima@ietf.org; Sun, 26 Mar 2006 14:28:36 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FNaue-0003YO-Ky; Sun, 26 Mar 2006 14:28:33 -0500 Date: Sun, 26 Mar 2006 14:28:31 -0500 From: John C Klensin To: Harald Alvestrand , Charles Lindsey Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Message-ID: In-Reply-To: <4423FB74.7050203@alvestrand.no> References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 --On Friday, 24 March, 2006 08:00 -0600 Harald Alvestrand wrote: > Charles Lindsey wrote: >> On Thu, 23 Mar 2006 16:46:55 -0000, Harald Alvestrand >> wrote: >> >>> Charles Lindsey wrote: >>>> Please! Can we establish a basic principle that any feature >>>> in a message >>>> that can cause some "technical effect" MUST be visible and >>>> understandable >>>> by a human reader (I grant that the feature may be written >>>> in UTF-8, but >>>> it must still exhibit a readable text to a human equipped >>>> with means to display that UTF-8). >>> No, I think establishing this as a basic principle would be >>> inappropriate. >>> >>> For instance, there are many contexts in which the >>> difference between LF and CR/LF is not visible to humans; >>> neither is the difference between unnormalized and >>> normalized Unicode text - yet both are going to be >>> important features of IMA messages. >> >> I grant you that you can mostly ingnore the difference >> between CRLf and a naked LF (which is not supposed to happen >> on the wire anyway), but the matter of unnormalized Unicode >> text is a good illustration of my point. > I thought it was a refutation of your point. But no matter; we > seem to agree that being precise about the requirements on > normalization of Unicode text is important. Ok so far. As Harald and some others who were in Dallas know, but Charles probably does not yet, a discussion in the applications area meeting on Monday has resulted in my starting work on a "net-UTF8" specification to supplement the traditional "net-ASCII" one. My preference, partially for the reasons below, is to have any discussions we need to have about normalization in that context, then to incorporate those rules in the mail spec. If we end up with more mail-specific (or mail, news, and one or two other things-specific) rules we will, I think, regret it. If others agree, let's look together at the Net-UTF8 draft and see if it meets our needs. If it doesn't, we can revisit this theme again. I hope to have a first draft Net-UTF8 I-D up toward the end of this coming week but, since I need to travel to New Zealand for ICANN, no promises... it could be sometime the week after. >> If some unnormalized text appears in a header, and >> normalizing that text would lead to a different outcome >> somewhere in the protocol, then that would be a Bad Thing. >> So it hardly matters if some unnormlized text appears in a >> Subject header (though I would regard it as bad practice), >> but unnormalized text in a local-part could make quite a >> difference. Well, let's be careful here. If the "no one looks at the address other than the receiving system", it is safe to have the local-part text be the local-part text. Problems would arise only if someone started applying normalization rules to text that wasn't expected to be normalized. I don't know if we should prohibit that, or require some sort of normalization (comments welcome), but it is not obvious that there are problems with either course of action. >> Recall that the IDNA people took greate care to >> ensure (through the use of nameprep) that only the >> normalized form of a domain name was to be meaningful. We >> should learn from that when designing the local-part. There are many things we can learn from that, including learning from the perception by some people after a couple of years of experience in some parts of the community that nameprep, in RFC 3491 form, was a mistake. That particular dissenter community believes that nameprep should have mapped the upper-case characters in scripts that have clear "case" into lower-case ones, should _perhaps_ have mapped pre-composed characters and composition sequences together, but otherwise should have avoided doing anything and that, in particular, other character mappings should have been avoided in favor of simply prohibiting characters that would be mapped to others. For us, traditional rules about the local-part avoid the requirement (or even the desirability) of trying to simulate case-mapping. There is no equivalent in local-parts to the hostname/LDH convention for domain names -- basically, all of NVT-ASCII is permitted. The Unicode consortium essentially claims that, if a character is assigned a code point, it is different from characters assigned other code points. So, there is a case to be made that, if we are to normalize at all, the only things that need normalizing involve making sequences of combining characters that should equal each other or a single precomposed character match. I'd like advice from UTC (and others) as to whether that would be wise or worth doing. Martin, I'm pretty sure you are following this list... comments? Others? Anyone see any strong justification for doing anything else along the lines or normalization? Rathole warning: if we can avoid stepping very far into this topic, it would probably be a really good idea. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 27 06:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNpXK-0006KX-Cq; Mon, 27 Mar 2006 06:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNpXI-0006Ca-D5 for ima@ietf.org; Mon, 27 Mar 2006 06:05:24 -0500 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FNpXF-0000Vo-Ow for ima@ietf.org; Mon, 27 Mar 2006 06:05:24 -0500 Received: (eyou send program); Mon, 27 Mar 2006 19:05:12 +0800 Message-ID: <343457512.10534@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.145 with SMTP; Mon, 27 Mar 2006 19:05:12 +0800 Message-ID: <1ce901c6518e$93ea75a0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Chris Newman" , References: <343008065.09028@cnnic.cn> Subject: Re: [EAI] Input from Sieve WG Date: Mon, 27 Mar 2006 19:07:03 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.0 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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="===============1522040315==" Errors-To: ima-bounces@ietf.org --===============1522040315== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQpvbiBteSB2aWV3LA0KICBmb2N1cyB0aGUgbWFpbiBpc3N1ZXMgZmlyc3QsIHNsb3ZlIGl0LCBh bmQgdGhlbiB0aGVzZSBpc3N1ZXMuDQoNCllhbyBKaWFua2FuZw0KQ05OSUMNCg0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJDaHJpcyBOZXdtYW4iIDxDaHJpcy5OZXdtYW5A U3VuLkNPTT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyMiwg MjAwNiAyOjE2IFBNDQpTdWJqZWN0OiBbRUFJXSBJbnB1dCBmcm9tIFNpZXZlIFdHDQoNCg0KPiBB ZGRpdGlvbmFsIGl0ZW1zIGZvciB0aGUgRUFJIGlzc3VlcyBsaXN0Og0KPiANCj4gKiBTaWV2ZSBl eHRlbnNpb24gZm9yIEVBSS4NCj4gDQo+ICogQSBmZXcgeWVhcnMgYWdvLCBBbGV4ZXkgaGFkIGFu IFNNVFAgbGFuZ3VhZ2UgY29tbWFuZCB0byBsb2NhbGl6ZSBTTVRQIGVycm9yDQo+ICAgcmVzcG9u c2VzLiAgV2hpbGUgd2UncmUgd29ya2luZyBvbiBpMThuLCBzaG91bGQgd2UgcmV2aXZlIHRoYXQg ZHJhZnQgZnJvbSB0aGUNCj4gICBkdXN0YmluPw0KPiANCj4gKiBTaG91bGQgdGhlIFBPUCBFQUkg ZHJhZnQgYWRkIGEgTEFORyBjb21tYW5kIHRvIG5lZ290aWF0ZSBVVEYtOCBlcnJvciB0ZXh0DQo+ ICAgcmVzcG9uc2VzPyAgKElNQVAgYWxyZWFkeSBoYXMgYW4gaTE4biBkcmFmdCBmb3IgdGhpcyBw dXJwb3NlKQ0KPiANCj4gICAgICAgICAgICAgICAgIC0gQ2hyaXMNCj4gDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBs aXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pbWENCj4g --===============1522040315== 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 --===============1522040315==-- From ima-bounces@ietf.org Mon Mar 27 06:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNpnh-0006RM-9r; Mon, 27 Mar 2006 06:22:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNpng-0006RH-3v for ima@ietf.org; Mon, 27 Mar 2006 06:22:20 -0500 Received: from th-mail-b0116.gradwell.net ([193.111.201.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNpnd-00013e-EK for ima@ietf.org; Mon, 27 Mar 2006 06:22:20 -0500 Received: from host81-144-67-170.midband.mdip.bt.net ([81.144.67.170]) by th-mail-b0116.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4427cae7.33be.373 for ima@ietf.org; Mon, 27 Mar 2006 12:22:15 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k2RAuR424910 for ; Mon, 27 Mar 2006 11:56:28 +0100 (BST) To: "ima@ietf.org" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> Message-ID: Date: Mon, 27 Mar 2006 11:56:20 +0100 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.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Sun, 26 Mar 2006 20:28:31 +0100, John C Klensin wrote: > Ok so far. As Harald and some others who were in Dallas know, > but Charles probably does not yet, a discussion in the > applications area meeting on Monday has resulted in my starting > work on a "net-UTF8" specification to supplement the traditional > "net-ASCII" one. My preference, partially for the reasons > below, is to have any discussions we need to have about > normalization in that context, then to incorporate those rules > in the mail spec. If we end up with more mail-specific (or > mail, news, and one or two other things-specific) rules we will, > I think, regret it. OK, if some general principles and conventions can be established at a higher level and we can buy into them, then that is well and good. We are concerned primarily with email addresses here, and I believe these have several concerns that do not apply to other headers that might use UTF-8 for assorted purposes. Essentially, any email address scheme needs to pas two tests, which I shall call the "telephone test" and the "fax test". Suppose Ålice wants to communicate with Bøb. We will presume they are both fluent in whichever Scandinavian language uses those characters, but that they are unaware of how Unicode works or of possible pitfalls within it. Harald can correct me, but I think Ålice (who probably pronounces it as "Arlice") is Norwegian and Bøb (who probably pronounces is as "Berb") is Danish. They use non-ASCII characters in both their local-parts and domain names (ålice@tromsö.edu and bøb@holbæk.edu). The telephone test. It must be possible for Ålice to tell Bøb her email address over the telephone, spelling out the names of the characters if necessary, in such a manner that Bøb will be able to send email that will reach her. The fax test. It must be possible for Ålice to hand write her email address on a piece of paper and fax it to Bøb, in such a manner that Bøb will be able to send email that will reach her. Now those examples were rather simple. But the tests must also succeed when the local-part contains routeing information for intepretation by the destination host and expressed using the conventions of the target language, and they must also work with more complex scripts such as Arabic where (AIUI) the same character may be written differently depending on its position within a word, and even on whether it forms part of a quotation from the Koran. Consider how present-day email addresses would pass those tests. Domain names expressed in ASCII should have no problems at all, and even local-parts should work reliably unless they contain quoted-strings with NO-WS-CTLs inside them. Also, internationalized domain names that have passed through nameprep should work pretty well, unless they have been deliberately obfuscated by using characters of similar appearance taken from different alphabets. Which leave internationalized local-parts ... > Well, let's be careful here. If the "no one looks at the > address other than the receiving system", it is safe to have the > local-part text be the local-part text. Problems would arise > only if someone started applying normalization rules to text > that wasn't expected to be normalized. I don't know if we > should prohibit that, or require some sort of normalization > (comments welcome), but it is not obvious that there are > problems with either course of action. I suspect that normalization enroute is going to happen whether we like it or not - from some unerlying operating system even if not explicitly coded into the mail software :-( . > So, there is a case to be made that, if we are to normalize at > all, the only things that need normalizing involve making > sequences of combining characters that should equal each other > or a single precomposed character match. That is essentially normalization level NFC, which is usually good enough for text intended for human consumption. For words that are of the nature of "identifiers" you usually need NFKC. > I'd like advice from > UTC (and others) as to whether that would be wise or worth > doing. Martin, I'm pretty sure you are following this list... > comments? Others? Yes, we really need Martin to guide us through all of this. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Mar 28 14:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJwZ-0003Zs-Oq; Tue, 28 Mar 2006 14:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJwX-0003Zn-Pi for ima@ietf.org; Tue, 28 Mar 2006 14:33:29 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJwV-0002pV-La for ima@ietf.org; Tue, 28 Mar 2006 14:33:29 -0500 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2SJXR8u016250 for ; Tue, 28 Mar 2006 12:33:27 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWU00J01RF5B200@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 28 Mar 2006 12:33:27 -0700 (MST) Received: from [10.0.1.4] (216-165-224-133.championbroadband.com [216.165.224.133]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWU00ESNRNOBI30@mail-amer.sun.com>; Tue, 28 Mar 2006 12:33:26 -0700 (MST) Date: Tue, 28 Mar 2006 11:35:40 -0800 From: Chris Newman Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) In-reply-to: To: Charles Lindsey , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 While the tests you describe can not be discounted, there is one much= more=20 important test: the gateway test. When a local part passes through an 8-to-7 (or 7-to-8) gateway, I bel= ieve any=20 transformation to the local-part must be 99.99% reversible and our= =20 specifications have to make this very clear. Things in the middle ar= e=20 permitted to alter the syntax used to represent the local part (for t= his=20 down-conversion scenario), but are not permitted to alter the content= s or=20 semantics in any way. I consider this critical to minimize the risk = of=20 partitioning the network. The recipient domain is permitted to perform any normalization on the= recipient=20 local part that it chooses, just as many sites today choose a case-in= sensitive=20 normalization of US-ASCII local parts. Recipients who wish to pass t= he=20 telephone and fax test to the degree you describe will choose to perf= orm more=20 normalization. But our specifications do not need to mandate anythin= g in that=20 area for interoperability. The correct normalization to use is proba= bly a=20 research problem (and varies by language and community) and in this c= ase it's=20 thankfully a problem we need not solve to have a valid specification. What's different from domains names it that we treated the 7-bit=20 down-conversion as the canonical form (and had to due to DNS restrict= ions).=20 Because the e-mail infrastructure is more agile than DNS (because it'= s higher=20 level and more extensible), we can view the 7-bit local-part encoding= as merely=20 a tunneling mechanism. And the best tunneling mechanism is one which= does not=20 damage what it tunnels. We could recommend normalization at the email-address input system. = But I'd=20 say anything beyond a limited Unicode pre-composed canonicalization a= s simple=20 advice is a bad idea. While some email-address input systems are inf= luenced by=20 our standards, many are not (including word processors, text editors,= terminal=20 windows, etc). So true interoperability rests with the canonicalizat= ion done=20 by the recipient system. - Chris Charles Lindsey wrote on 3/27/06 11:56 +0100: > On Sun, 26 Mar 2006 20:28:31 +0100, John C Klensin wrote: > >> Ok so far. As Harald and some others who were in Dallas know, >> but Charles probably does not yet, a discussion in the >> applications area meeting on Monday has resulted in my starting >> work on a "net-UTF8" specification to supplement the traditional >> "net-ASCII" one. My preference, partially for the reasons >> below, is to have any discussions we need to have about >> normalization in that context, then to incorporate those rules >> in the mail spec. If we end up with more mail-specific (or >> mail, news, and one or two other things-specific) rules we will, >> I think, regret it. > > OK, if some general principles and conventions can be established a= t a > higher level and we can buy into them, then that is well and good. > > We are concerned primarily with email addresses here, and I believe= these > have several concerns that do not apply to other headers that might= use > UTF-8 for assorted purposes. Essentially, any email address scheme = needs to > pas two tests, which I shall call the "telephone test" and the "fax= test". > > Suppose =C5lice wants to communicate with B=F8b. We will presume th= ey are both > fluent in whichever Scandinavian language uses those characters, bu= t that > they are unaware of how Unicode works or of possible pitfalls withi= n it. > > Harald can correct me, but I think =C5lice (who probably pronounces= it as > "Arlice") is Norwegian and B=F8b (who probably pronounces is as "Be= rb") is > Danish. They use non-ASCII characters in both their local-parts and= domain > names (=E5lice@troms=F6.edu and b=F8b@holb=E6k.edu). > > The telephone test. > > It must be possible for =C5lice to tell B=F8b her email address ove= r the > telephone, spelling out the names of the characters if necessary, i= n such a > manner that B=F8b will be able to send email that will reach her. > > The fax test. > > It must be possible for =C5lice to hand write her email address on = a piece of > paper and fax it to B=F8b, in such a manner that B=F8b will be able= to send > email that will reach her. > > Now those examples were rather simple. But the tests must also succ= eed when > the local-part contains routeing information for intepretation by t= he > destination host and expressed using the conventions of the target = language, > and they must also work with more complex scripts such as Arabic w= here > (AIUI) the same character may be written differently depending on = its > position within a word, and even on whether it forms part of a quo= tation > from the Koran. > > Consider how present-day email addresses would pass those tests. Do= main > names expressed in ASCII should have no problems at all, and even > local-parts should work reliably unless they contain quoted-strings= with > NO-WS-CTLs inside them. > > Also, internationalized domain names that have passed through namep= rep > should work pretty well, unless they have been deliberately obfusca= ted by > using characters of similar appearance taken from different alphabe= ts. > > Which leave internationalized local-parts ... > > >> Well, let's be careful here. If the "no one looks at the >> address other than the receiving system", it is safe to have the >> local-part text be the local-part text. Problems would arise >> only if someone started applying normalization rules to text >> that wasn't expected to be normalized. I don't know if we >> should prohibit that, or require some sort of normalization >> (comments welcome), but it is not obvious that there are >> problems with either course of action. > > I suspect that normalization enroute is going to happen whether we = like it > or not - from some unerlying operating system even if not explicitl= y coded > into the mail software :-( . > >> So, there is a case to be made that, if we are to normalize at >> all, the only things that need normalizing involve making >> sequences of combining characters that should equal each other >> or a single precomposed character match. > > That is essentially normalization level NFC, which is usually good = enough > for text intended for human consumption. For words that are of the = nature of > "identifiers" you usually need NFKC. > >> I'd like advice from >> UTC (and others) as to whether that would be wise or worth >> doing. Martin, I'm pretty sure you are following this list... >> comments? Others? > > Yes, we really need Martin to guide us through all of this. > > -- > Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own= =A0thing---------------------- > -- > Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0= =A0=A0Web:=A0http://www.cs.man.ac.uk/~c > hl > Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewo= od=A0Ave,=A0CHEADLE,=A0SK8=A03JU,=A0U. > K. > PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051= =A093=A0A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0 > A5 > > _______________________________________________ > 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 Tue Mar 28 14:36:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJzr-0005eJ-Q2; Tue, 28 Mar 2006 14:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJzY-0005bw-IL for ima@ietf.org; Tue, 28 Mar 2006 14:36:36 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJzW-0002z4-4X for ima@ietf.org; Tue, 28 Mar 2006 14:36:36 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2SJaXSD028565 for ; Tue, 28 Mar 2006 12:36:33 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWU00M01RO4P100@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 28 Mar 2006 12:36:33 -0700 (MST) Received: from [10.0.1.4] (216-165-224-133.championbroadband.com [216.165.224.133]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWU00HD0RSUCZ40@mail-amer.sun.com>; Tue, 28 Mar 2006 12:36:33 -0700 (MST) Date: Tue, 28 Mar 2006 11:38:46 -0800 From: Chris Newman Subject: Re: [EAI] Input from Sieve WG In-reply-to: <1ce901c6518e$93ea75a0$1206e29f@cnnicyaojk> To: YAO Jiankang , ima@ietf.org Message-id: <165A0B84F0FD4EB03FB31BB5@[10.0.1.4]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <343008065.09028@cnnic.cn> <1ce901c6518e$93ea75a0$1206e29f@cnnicyaojk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Agreed. But we should be keeping a list of "issues to deal with later". As for POP LANG, I'll just add it to the UTF-8 POP spec (unless there's a strong objection). It's not terribly difficult and we may as well keep the POP i18n extensions in one spec. - Chris YAO Jiankang wrote on 3/27/06 19:07 +0800: > > on my view, > focus the main issues first, slove it, and then these issues. > > Yao Jiankang > CNNIC > > ----- Original Message ----- > From: "Chris Newman" > To: > Sent: Wednesday, March 22, 2006 2:16 PM > Subject: [EAI] Input from Sieve WG > > >> Additional items for the EAI issues list: >> >> * Sieve extension for EAI. >> >> * A few years ago, Alexey had an SMTP language command to localize SMTP error >> responses. While we're working on i18n, should we revive that draft from >> the dustbin? >> >> * Should the POP EAI draft add a LANG command to negotiate UTF-8 error text >> responses? (IMAP already has an i18n draft for this purpose) >> >> - Chris >> >> >> _______________________________________________ >> 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 Wed Mar 29 03:04:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVfB-0005YP-LI; Wed, 29 Mar 2006 03:04:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVfA-0005Xr-4u for ima@ietf.org; Wed, 29 Mar 2006 03:04:20 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVf9-0007eC-GH for ima@ietf.org; Wed, 29 Mar 2006 03:04:20 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2T848d23641; Wed, 29 Mar 2006 17:04:08 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7c8f_99101cae_befa_11da_9bd8_0014221f2a2d; Wed, 29 Mar 2006 17:04:07 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k2T82gAu029758; Wed, 29 Mar 2006 17:03:30 +0900 Message-Id: <6.0.0.20.2.20060329141320.086d2680@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Mar 2006 15:28:42 +0900 To: "Charles Lindsey" , "ima@ietf.org" From: Martin Duerst Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) In-Reply-To: References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 19:56 06/03/27, Charles Lindsey wrote: >On Sun, 26 Mar 2006 20:28:31 +0100, John C Klensin wrote: >We are concerned primarily with email addresses here, and I believe these >have several concerns that do not apply to other headers that might use >UTF-8 for assorted purposes. Essentially, any email address scheme needs >to pas two tests, which I shall call the "telephone test" and the "fax >test". >Now those examples were rather simple. But the tests must also succeed >when the local-part contains routeing information for intepretation by the >destination host and expressed using the conventions of the target >language, I don't see any fundamental difference between routing information and the rest of the address LHS (is there a specific name for that rest?). If there is a difference, it may be between names for people and just plain words from the language. Differences that are significant in people's names may not be significant in plain words. As an example, Johann Wolfgang von Goethe is always written Goethe, not Go"the (with the dots on the 'o', sorry for the limited German capabilities of my Japanese mailer), but in most German words, substituting oe for o" doesn't alter meaning at all. >and they must also work with more complex scripts such as Arabic >where (AIUI) the same character may be written differently depending on >its position within a word, That's duely handled by Unicode. There are some issues if you want a Persian user input an Arabic address or vice versa. There are also some issues regarding orthography, but these may appear in any language, and we can assume that they >and even on whether it forms part of a quotation from the Koran. > >Consider how present-day email addresses would pass those tests. Domain >names expressed in ASCII should have no problems at all, Sorry, wrong. 0/O or l/I/1 may pass the telephone test, but they may easily fail the fax test. >and even >local-parts should work reliably unless they contain quoted-strings with >NO-WS-CTLs inside them. Yes, and if they do, we would all blame the person who came up with the idea of using NO-WS-CTLs, rather than the system, wouldn't we. >Also, internationalized domain names that have passed through nameprep >should work pretty well, unless they have been deliberately obfuscated by >using characters of similar appearance taken from different alphabets. Well, yes, and I think we wouldn't want to change anything in internationalized domain names. (Or each of us might want to change something, but we agree it's not our job as a group.) >> Well, let's be careful here. If the "no one looks at the >> address other than the receiving system", it is safe to have the >> local-part text be the local-part text. Problems would arise >> only if someone started applying normalization rules to text >> that wasn't expected to be normalized. I don't know if we >> should prohibit that, or require some sort of normalization >> (comments welcome), but it is not obvious that there are >> problems with either course of action. > >I suspect that normalization enroute is going to happen whether we like it >or not - from some unerlying operating system even if not explicitly coded >into the mail software :-( . My guess is that this will not happen. First, people working on OSes have rather little interest in I18N. Second, it would create a mess, because the layers above definitely don't all have the same requirements. Third, while normalization could be existing e.g. in a file system for file names (Apple uses, or at least used, decomposition (mostly NFD) for their file system), I can't see it for TCP/IP pipes. As long as the recepient's address isn't in some way included in a file name, it would be weird for the OS to mess with the data. For the OS, in particular on an intermediary MTA, mail addresses are just data. Or am I getting something wrong here? >> So, there is a case to be made that, if we are to normalize at >> all, the only things that need normalizing involve making >> sequences of combining characters that should equal each other >> or a single precomposed character match. > >That is essentially normalization level NFC, Yes. NFC also includes some 'singletons', i.e. it removes what most people think are simple duplicates of characters. The easiest example is A-ring and the Angstro"m sign, which look exactly the same but somehow got coded twice. >which is usually good enough >for text intended for human consumption. For words that are of the nature >of "identifiers" you usually need NFKC. Could be correct, but depends on what exactly you mean by 'need'. More about that in another mail. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 29 11:55:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdwq-0002kL-EC; Wed, 29 Mar 2006 11:55:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdwp-0002kB-Qf for ima@ietf.org; Wed, 29 Mar 2006 11:55:07 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdwo-00063V-AW for ima@ietf.org; Wed, 29 Mar 2006 11:55:07 -0500 Received: from host81-144-65-171.midband.mdip.bt.net ([81.144.65.171]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 442abbe8.101c3.11ca for ima@ietf.org; Wed, 29 Mar 2006 17:55:04 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k2TGnA424358 for ; Wed, 29 Mar 2006 17:49:10 +0100 (BST) Date: Wed, 29 Mar 2006 12:15:42 +0100 From: "Mail Delivery System" To: chl@clerew.man.ac.uk Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Received: from exim by ietf-mx.ietf.org with local (Exim 4.43) id 1FOYeM-00087Q-CC for chl@clerew.man.ac.uk; Wed, 29 Mar 2006 06:15:42 -0500 X-Gradwell-POP3: delivered to at Wed, 29 Mar 2006 12:15:53 +0100 X-Envelope-To: chl@clerew.man.ac.uk X-Forwarding-To: chl@clerew.man.ac.uk Delivered-To: forwarding-chl@clerew.man.ac.uk X-Failed-Recipients: ma@ietf.org Auto-Submitted: auto-generated Message-ID: Resent-To: "ima@ietf.org" Resent-From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-Date: Wed, 29 Mar 2006 17:49:06 +0100 Resent-Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Tue, 28 Mar 2006 20:35:40 +0100, Chris Newman wrote: > While the tests you describe can not be discounted, there is one much > more important test: the gateway test. > > When a local part passes through an 8-to-7 (or 7-to-8) gateway, I > believe any transformation to the local-part must be 99.99% reversible > and our specifications have to make this very clear. Things in the > middle are permitted to alter the syntax used to represent the local > part (for this down-conversion scenario), but are not permitted to alter > the contents or semantics in any way. I consider this critical to > minimize the risk of partitioning the network. That is a fine goal, but may not be achievable. Better to have a guaranteed bounce when that cannot be achieved than to have no I18N at all. The one case of a change that will not be reversible is when an address in some headed contains both a UTF-8 form and an alternate (ASCII) form. Only the ASCII form will be present when the message is delibered to a strict RFC2822-only destination. > > The recipient domain is permitted to perform any normalization on the > recipient local part that it chooses, just as many sites today choose a > case-insensitive normalization of US-ASCII local parts. I think the point of my two tests was that recipient domains need to be aware that they can make no assumptions regarding the normalization state of the local parts they receive (because the whole address may have previously been passed through one of those telephone or fax channels, this losing any of the content which cannot be conveyed by voice or by handwriting). Our documents should make it clear that no such reliance may be placed. But yes, normalization by the recipient domain would be a wise precaution. > Recipients who wish to pass the telephone and fax test to the degree > you describe will choose to perform more normalization. But our > specifications do not need to mandate anything in that area for > interoperability. There is a general principle within the Unicode community known as "early normalization" (which Martin can explain in more detail, since he wrote the document) which says that it is better to normalize stuff at the point where it is generated than for every subsequent stage to repeat the process. One can argue about the robustness of that principle, but it is probably safer, and better practice, to encourage normalization at the outset (MUST or SHOULD). But hopefully John's "Net UTF-8" proposal is going to set at least some minimal standard for that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Wed Mar 29 13:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOf3m-0005jy-35; Wed, 29 Mar 2006 13:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOf3l-0005jt-Pj for ima@ietf.org; Wed, 29 Mar 2006 13:06:21 -0500 Received: from boole.openldap.org ([204.152.186.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOf3k-0001Lb-En for ima@ietf.org; Wed, 29 Mar 2006 13:06:21 -0500 Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k2TI60u6057412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 18:06:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 29 Mar 2006 10:05:26 -0800 To: Martin Duerst From: "Kurt D. Zeilenga" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) In-Reply-To: <6.0.0.20.2.20060329141320.086d2680@localhost> References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Charles Lindsey , "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 10:28 PM 3/28/2006, Martin Duerst wrote: >>Consider how present-day email addresses would pass those tests. Domain >>names expressed in ASCII should have no problems at all, > >Sorry, wrong. 0/O or l/I/1 may pass the telephone test, but they >may easily fail the fax test. C and Z are often confused on the telephone when using American English (especially with non-native speakers, something my wife can attest to :-). 2 (zwei) and 3 (drei) can be confused when speaking German (so much so that some German speakers will instead say zwo instead of 2 to avoid the zwei/drei confusion). Kurt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 30 02:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOrdv-0003Vy-IN; Thu, 30 Mar 2006 02:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOrdu-0003Vt-FJ for ima@ietf.org; Thu, 30 Mar 2006 02:32:30 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOrdt-0004Zc-4G for ima@ietf.org; Thu, 30 Mar 2006 02:32:30 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95991259722; Thu, 30 Mar 2006 09:30:35 +0200 (CEST) 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 09956-06; Thu, 30 Mar 2006 09:30:31 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E438025971F; Thu, 30 Mar 2006 09:30:30 +0200 (CEST) Message-ID: <442B8987.1080707@alvestrand.no> Date: Thu, 30 Mar 2006 09:32:23 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> In-Reply-To: <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> 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: cab78e1e39c4b328567edb48482b6a69 Cc: Charles Lindsey , "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 I think the discussion so far has proved just about conclusively that the standards cannot possibly require recipient systems to have email addresses that pass either the telephone number test or the fax test. It may be a recommendation (good practice for those who pick mailbox names), but a sending system cannot assume that recipient systems' email addresses are different enough to pass those tests. So I think that for the purposes of the EAI WG, this is irrelevant. Harald Kurt D. Zeilenga wrote: >At 10:28 PM 3/28/2006, Martin Duerst wrote: > > >>>Consider how present-day email addresses would pass those tests. Domain >>>names expressed in ASCII should have no problems at all, >>> >>> >>Sorry, wrong. 0/O or l/I/1 may pass the telephone test, but they >>may easily fail the fax test. >> >> > >C and Z are often confused on the telephone when using >American English (especially with non-native speakers, >something my wife can attest to :-). 2 (zwei) >and 3 (drei) can be confused when speaking German >(so much so that some German speakers will instead say >zwo instead of 2 to avoid the zwei/drei confusion). > >Kurt > > >_______________________________________________ >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 Mar 30 03:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsAP-0007DK-Cq; Thu, 30 Mar 2006 03:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsAO-0007Bz-2j for ima@ietf.org; Thu, 30 Mar 2006 03:06:04 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOsAM-0006a9-Eq for ima@ietf.org; Thu, 30 Mar 2006 03:06:04 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k2U85Iu05343; Thu, 30 Mar 2006 17:05:18 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 2389_ed713610_bfc3_11da_8853_0014221fa3c9; Thu, 30 Mar 2006 17:05:17 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k2U81hPA015373; Thu, 30 Mar 2006 17:04:27 +0900 Message-Id: <6.0.0.20.2.20060330160352.090609b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 30 Mar 2006 16:07:14 +0900 To: "Kurt D. Zeilenga" From: Martin Duerst Subject: Re: Normalizing Unicode (Re: [EAI] silly states and headerlabel) In-Reply-To: <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Charles Lindsey , "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 03:05 06/03/30, Kurt D. Zeilenga wrote: >At 10:28 PM 3/28/2006, Martin Duerst wrote: >>>Consider how present-day email addresses would pass those tests. Domain >>>names expressed in ASCII should have no problems at all, >> >>Sorry, wrong. 0/O or l/I/1 may pass the telephone test, but they >>may easily fail the fax test. > >C and Z are often confused on the telephone when using >American English (especially with non-native speakers, >something my wife can attest to :-). I have problems with J and G, and sometimes with V and Y. >2 (zwei) >and 3 (drei) can be confused when speaking German >(so much so that some German speakers will instead say >zwo instead of 2 to avoid the zwei/drei confusion). Yes indeed. In Swiss military service, I was in an artillery- like unit where we had to shout elevation and direction numbers over distances. We were drilled from day one to always use 'zwo' rather than 'zwei'. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 30 10:07:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyk2-0005LI-Un; Thu, 30 Mar 2006 10:07:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyk1-0005GZ-M0 for ima@ietf.org; Thu, 30 Mar 2006 10:07:17 -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 1FOyk0-0000Jx-AV for ima@ietf.org; Thu, 30 Mar 2006 10:07:17 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FOyjw-000Cnr-KJ; Thu, 30 Mar 2006 10:07:13 -0500 Date: Thu, 30 Mar 2006 10:07:10 -0500 From: John C Klensin To: Harald Alvestrand , "Kurt D. Zeilenga" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Message-ID: <1D0DE094973BEDD7D9C1B3F7@[10.100.1.50]> In-Reply-To: <442B8987.1080707@alvestrand.no> References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Charles Lindsey , 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 --On Thursday, March 30, 2006 09:32 +0200 Harald Alvestrand wrote: > I think the discussion so far has proved just about > conclusively that the standards cannot possibly require > recipient systems to have email addresses that pass either the > telephone number test or the fax test. > > It may be a recommendation (good practice for those who pick > mailbox names), but a sending system cannot assume that > recipient systems' email addresses are different enough to > pass those tests. There is a document that people have talked about writing for many years. It would be called "how to choose email addresses for maximum interoperability and minimum confusion" or something like that. There have been versions for other networks, but never, as far as I know, for the Internet, although two of the rules that would go into it are well known: * Don't take advantage of the fact that local-parts are case-sensitive; it just causes trouble. * Don't put anything into an address that requires quoting or escaping -- something, somewhere, will trash the address beyond recognition. Perhaps, after this WG completes its work (under some other name, I hope) someone can write a fully internationalized version of that document. > So I think that for the purposes of the EAI WG, this is > irrelevant. Yep john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 30 21:15:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP9AR-0008Rc-EV; Thu, 30 Mar 2006 21:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP9AQ-0008Qg-5K for ima@ietf.org; Thu, 30 Mar 2006 21:15:14 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP9AN-0005iK-Ko for ima@ietf.org; Thu, 30 Mar 2006 21:15:14 -0500 Received: from host81-144-65-146.midband.mdip.bt.net ([81.144.65.146]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 442c90ad.5780.4063 for ima@ietf.org; Fri, 31 Mar 2006 03:15:09 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k2UH5D408709 for ; Thu, 30 Mar 2006 18:05:14 +0100 (BST) To: "ima@ietf.org" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> Message-ID: Date: Thu, 30 Mar 2006 18:05:03 +0100 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: <442B8987.1080707@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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, 30 Mar 2006 08:32:23 +0100, Harald Alvestrand wrote: > I think the discussion so far has proved just about conclusively that > the standards cannot possibly require recipient systems to have email > addresses that pass either the telephone number test or the fax test. Sure we cannot write rules telling people to say "zwo" rather than "zwei", but we can avoid the grosser failures of the telephone and fax tests (and especially the ones which will still confuse people even if they take the greatest care over their pronunciation and handwriting) by requiring some reaonable level of normalization of email addresses (and of the local-part in particular). John's "Net-utf-8" document may or may not be sufficient for the purpose, so I suggest we wait and see what that covers before returning to this subject again. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Mar 30 22:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAXq-0006qA-EO; Thu, 30 Mar 2006 22:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAXo-0006q2-V6 for ima@ietf.org; Thu, 30 Mar 2006 22:43:29 -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 1FPAXo-0000n0-Hm for ima@ietf.org; Thu, 30 Mar 2006 22:43:28 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FPAXn-000EBn-Oo; Thu, 30 Mar 2006 22:43:28 -0500 Date: Thu, 30 Mar 2006 22:43:25 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Message-ID: In-Reply-To: References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Thursday, March 30, 2006 18:05 +0100 Charles Lindsey wrote: > On Thu, 30 Mar 2006 08:32:23 +0100, Harald Alvestrand > wrote: > >> I think the discussion so far has proved just about >> conclusively that the standards cannot possibly require >> recipient systems to have email addresses that pass either >> the telephone number test or the fax test. > > Sure we cannot write rules telling people to say "zwo" rather > than "zwei", but we can avoid the grosser failures of the > telephone and fax tests (and especially the ones which will > still confuse people even if they take the greatest care over > their pronunciation and handwriting) by requiring some > reaonable level of normalization of email addresses (and of > the local-part in particular). John's "Net-utf-8" document > may or may not be sufficient for the purpose, so I suggest we > wait and see what that covers before returning to this > subject again. That document will certainly not be sufficient for what you intend, since it will "match" characters only to the extent needed to avoid technical problems induced by the nature if Unicode (e.g., resolving differences between composed characters (ones built up from a base character and one or more combining characters) and precomposed characters. What I think you are asking for gets into the area that the Unicode Technical Committee describes as the "identifier" problem, i.e., the characters that are appropriate for use in identifiers. They have a somewhat different view of what constitutes appropriate criteria for identifiers than you do and a debate on those points might be interesting. But, for email, the principle that we impose as few limits of what can be put in a local part should, IMO, still prevail. Limiting characters or character sequences that have operationally proven to cause problems --such as the difficulties with quoting and control characters-- makes sense. Beyond that, as earlier notes have pointed out, it is probably better to rely on advice to mail server operators about the strings they should permit rather than trying to write rules into the protocol. If one doesn't like the theoretical reason for doing things that way, let me suggest a pragmatic one -- making decisions about what characters should and should not be permitted is a huge rathole. Worse, the only way to avoid confusion, even within a single script, involves banning characters within a script (as some examples have pointed out) and we just are not going to get away with that. john john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 31 10:11:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLHR-0001PE-PX; Fri, 31 Mar 2006 10:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLHP-0001N6-T8 for ima@ietf.org; Fri, 31 Mar 2006 10:11:15 -0500 Received: from sov-mail-b0013.gradwell.net ([193.84.87.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPLHO-0006WX-Aa for ima@ietf.org; Fri, 31 Mar 2006 10:11:15 -0500 Received: from host81-144-66-228.midband.mdip.bt.net ([81.144.66.228]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 442d4665.3b06.1e1 for ima@ietf.org; Fri, 31 Mar 2006 16:10:29 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k2VDQQ418836 for ; Fri, 31 Mar 2006 14:26:27 +0100 (BST) To: ima@ietf.org Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> Message-ID: Date: Fri, 31 Mar 2006 14:26:19 +0100 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: 3e15cc4fdc61d7bce84032741d11c8e5 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, 31 Mar 2006 04:43:25 +0100, John C Klensin wrote: > --On Thursday, March 30, 2006 18:05 +0100 Charles Lindsey > wrote: > >> On Thu, 30 Mar 2006 08:32:23 +0100, Harald Alvestrand >> wrote: >> >>> I think the discussion so far has proved just about >>> conclusively that the standards cannot possibly require >>> recipient systems to have email addresses that pass either >>> the telephone number test or the fax test. >> >> Sure we cannot write rules telling people to say "zwo" rather >> than "zwei", but we can avoid the grosser failures of the >> telephone and fax tests (and especially the ones which will >> still confuse people even if they take the greatest care over >> their pronunciation and handwriting) by requiring some >> reaonable level of normalization of email addresses (and of >> the local-part in particular). John's "Net-utf-8" document >> may or may not be sufficient for the purpose, so I suggest we >> wait and see what that covers before returning to this >> subject again. > > That document will certainly not be sufficient for what you intend, > since it will "match" characters only to the extent needed to avoid > technical problems induced by the nature if Unicode (e.g., resolving > differences between composed characters (ones built up from a base > character and one or more combining characters) and precomposed > characters. That is NFC normalization, and is a good starting point. > > What I think you are asking for gets into the area that the Unicode > Technical Committee describes as the "identifier" problem, i.e., the > characters that are appropriate for use in identifiers. And that is essentially NFKC normalization which, since it is defined by the Unicode people, is easy to incorporate if we so decide. I think Nameprep includes at least NFKC for example. If you want to go beyond that, then you can look at the classifications into which Unicode divides things. I would think, at least, that you would want to forbid characters that are not visible, and probably also any characters that are just new forms of whitespace (because those would all fail both the telephone and fax tests). That would probably be far enough. I would not want to disallow punctuation or mathematical symbols, not upper- or title-case letters (since, with due diligence, thay need not fail my two tests). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Fri Mar 31 12:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPNhV-0000gz-ER; Fri, 31 Mar 2006 12:46:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPNhU-0000gu-8A for ima@ietf.org; Fri, 31 Mar 2006 12:46:20 -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 1FPNhS-0005MZ-Rk for ima@ietf.org; Fri, 31 Mar 2006 12:46:20 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FPNhR-000FZ5-Mu; Fri, 31 Mar 2006 12:46:18 -0500 Date: Fri, 31 Mar 2006 12:46:15 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Message-ID: <388B6D3D8DE302FE83B4C91B@[10.100.1.50]> In-Reply-To: References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, March 31, 2006 14:26 +0100 Charles Lindsey wrote: >... >> What I think you are asking for gets into the area that the >> Unicode Technical Committee describes as the "identifier" >> problem, i.e., the characters that are appropriate for use >> in identifiers. > > And that is essentially NFKC normalization which, since it is > defined by the Unicode people, is easy to incorporate if we > so decide. I think Nameprep includes at least NFKC for > example. > > If you want to go beyond that, then you can look at the > classifications into which Unicode divides things. I would > think, at least, that you would want to forbid characters > that are not visible, and probably also any characters that > are just new forms of whitespace (because those would all > fail both the telephone and fax tests). That would probably be > far enough. I would not want to disallow punctuation or > mathematical symbols, not upper- or title-case letters > (since, with due diligence, thay need not fail my two tests). Charles, First, nameprep is essentially NFKC with some additional restrictions. The current UTC thinking on identifiers is more restrictive, see UTR 31 () for more information. Second, please read the rest of my note, where I explained why we probably don't want to go down that path (and Chris Newman's note of several days ago that reached essentially the same conclusion after reasoning from a different perspective. If you want to argue for a more restrictive character model, please respond in terms of my comments, Chris's comments, and the explanations of the "no one looks or interprets before the delivery MTA in RFCs 1123 and 2821. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima