From ima-bounces@ietf.org Fri Dec 01 02:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq2lD-0006bC-6F; Fri, 01 Dec 2006 02:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq2lB-0006aw-JQ for ima@ietf.org; Fri, 01 Dec 2006 02:24:37 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq2l9-0006lG-Tl for ima@ietf.org; Fri, 01 Dec 2006 02:24:37 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id kB17OX1A009049; Fri, 1 Dec 2006 15:24:34 +0800 Message-ID: <0bb401c71519$e7a4ee60$c7d348d3@aabbeell> From: "abel" To: "Soobok Lee" References: <364936190.06051@cnnic.cn><004701c714ea$bdbfb9b0$1206e29f@cnnicyao><364940517.17976@cnnic.cn><010a01c714f7$3fcb6380$1206e29f@cnnicyao> <20061201042934.GE24636@ns5.lsb.org> Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Date: Fri, 1 Dec 2006 15:25:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 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 ----- Original Message ----- From: "Soobok Lee" To: "Yao Jiankang" Cc: Sent: Friday, December 01, 2006 12:29 PM Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards > On Fri, Dec 01, 2006 at 11:17:36AM +0800, Yao Jiankang wrote: > > > > ----- Original Message ----- > > > > > > How about having some guideline to *ban* on embedding any data/instruction > > > into the NON-ASCII localpart, since NON-ASCII lables are most for humans > > > not for machines. They will use ASCII localpart for that purpose. No harm > > > at all. > > > > yes, I also considered this issue about *ban* on embedding any data/instruction > > into the NON-ASCII localpart before. > > on another thought, *ban" will also cause some problems and has some inconvenience. > > for example, I can use sub-address such as yao+ietf@organization.com before EAI protocol is published. > > but I can not use sub-address such as [Chinese Character yao]+ietf@IDN after EAI protocol is published. > > > > so after EAI protocols are published, it is not our design aim that some email address form will be dis-allowed. > > in your example, "+" can be added as a legal delimiter for localparts. /=_! can be added as legal delimiters likewise. > For my example, "[SOOBOK in UTF8].[LEE in UTF8]+eai_ietf@lsb.org can be autoconverted into > "xn--sbsbsbs.xn--lelelele+eai_ietf@lsb.org. No loss of information. dot and + and underbar was not lost. > The receiving SMTP server parses it back to NONASCII in order to find data/instruction > for whitelisting filtering. Even the receiving server can work directly > on xn--******+eai_ietf@lsb.org without NON-ASCII version if it is already registered > as an ascii *alias* for NON_ASCII in the server alias database. > Still I can find no problem at all. I very agree Soobok views, But this was a violation of the framework requirements. Harald said: that's a local decision about automatic converting. Even if there are delimters. Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 02:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq2sg-0003d1-Ne; Fri, 01 Dec 2006 02:32:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq2sf-0003cw-Bl for ima@ietf.org; Fri, 01 Dec 2006 02:32:21 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gq2sc-0007hI-DR for ima@ietf.org; Fri, 01 Dec 2006 02:32:21 -0500 Received: (eyou send program); Fri, 01 Dec 2006 15:32:04 +0800 Message-ID: <364958324.04266@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Fri, 01 Dec 2006 15:32:04 +0800 Message-ID: <034e01c7151a$f1a6ec50$1206e29f@cnnicyao> From: "Yao Jiankang" To: "Soobok Lee" References: <364936190.06051@cnnic.cn><004701c714ea$bdbfb9b0$1206e29f@cnnicyao><364940517.17976@cnnic.cn><010a01c714f7$3fcb6380$1206e29f@cnnicyao><20061201042934.GE24636@ns5.lsb.org> <364957934.02667@cnnic.cn> Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Date: Fri, 1 Dec 2006 15:33:06 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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="===============1529978680==" Errors-To: ima-bounces@ietf.org --===============1529978680== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogImFiZWwiIDxhYmVseWFuZ0B0 d25pYy5uZXQudHc+DQpUbzogIlNvb2JvayBMZWUiIDxsc2JAbHNiLm9yZz4NCkNjOiA8aW1hQGll dGYub3JnPg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwMSwgMjAwNiAzOjI1IFBNDQpTdWJqZWN0 OiBSZTogW0VBSV0gaTE4biBvZiBsb2NhbHBhcnQgdmVyc3VzIGkxOG4gb2YgZW1haWwgUkZDIHN0 YW5kYXJkcw0KDQoNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206 ICJTb29ib2sgTGVlIiA8bHNiQGxzYi5vcmc+DQo+IFRvOiAiWWFvIEppYW5rYW5nIiA8eWFvamtA Y25uaWMuY24+DQo+IENjOiA8aW1hQGlldGYub3JnPg0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVy IDAxLCAyMDA2IDEyOjI5IFBNDQo+IFN1YmplY3Q6IFJlOiBbRUFJXSBpMThuIG9mIGxvY2FscGFy dCB2ZXJzdXMgaTE4biBvZiBlbWFpbCBSRkMgc3RhbmRhcmRzDQo+IA0KPiANCj4+IE9uIEZyaSwg RGVjIDAxLCAyMDA2IGF0IDExOjE3OjM2QU0gKzA4MDAsIFlhbyBKaWFua2FuZyB3cm90ZToNCj4+ ID4NCj4+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4+ID4gPg0KPj4gPiA+IEhv dyBhYm91dCBoYXZpbmcgc29tZSBndWlkZWxpbmUgdG8gKmJhbiogb24gZW1iZWRkaW5nIGFueQ0K PiBkYXRhL2luc3RydWN0aW9uDQo+PiA+ID4gaW50byB0aGUgTk9OLUFTQ0lJIGxvY2FscGFydCwg c2luY2UgIE5PTi1BU0NJSSBsYWJsZXMgYXJlIG1vc3QgZm9yDQo+IGh1bWFucw0KPj4gPiA+IG5v dCBmb3IgbWFjaGluZXMuIFRoZXkgd2lsbCB1c2UgQVNDSUkgbG9jYWxwYXJ0IGZvciB0aGF0IHB1 cnBvc2UuIE5vDQo+IGhhcm0NCj4+ID4gPiBhdCBhbGwuDQo+PiA+DQo+PiA+IHllcywgSSBhbHNv IGNvbnNpZGVyZWQgdGhpcyBpc3N1ZSBhYm91dCAqYmFuKiBvbiBlbWJlZGRpbmcgYW55DQo+IGRh dGEvaW5zdHJ1Y3Rpb24NCj4+ID4gIGludG8gdGhlIE5PTi1BU0NJSSBsb2NhbHBhcnQgYmVmb3Jl Lg0KPj4gPiBvbiBhbm90aGVyIHRob3VnaHQsICpiYW4iIHdpbGwgYWxzbyBjYXVzZSBzb21lIHBy b2JsZW1zIGFuZCBoYXMgc29tZQ0KPiBpbmNvbnZlbmllbmNlLg0KPj4gPiBmb3IgZXhhbXBsZSwg SSBjYW4gdXNlIHN1Yi1hZGRyZXNzIHN1Y2ggYXMgeWFvK2lldGZAb3JnYW5pemF0aW9uLmNvbQ0K PiBiZWZvcmUgIEVBSSBwcm90b2NvbCBpcyBwdWJsaXNoZWQuDQo+PiA+IGJ1dCBJIGNhbiBub3Qg dXNlIHN1Yi1hZGRyZXNzIHN1Y2ggYXMgW0NoaW5lc2UgQ2hhcmFjdGVyIHlhb10raWV0ZkBJRE4N Cj4gYWZ0ZXIgIEVBSSBwcm90b2NvbCBpcyBwdWJsaXNoZWQuDQo+PiA+DQo+PiA+IHNvIGFmdGVy IEVBSSBwcm90b2NvbHMgYXJlIHB1Ymxpc2hlZCwgaXQgaXMgbm90IG91ciBkZXNpZ24gYWltIHRo YXQNCj4gc29tZSBlbWFpbCBhZGRyZXNzIGZvcm0gd2lsbCBiZSBkaXMtYWxsb3dlZC4NCj4+DQo+ PiBpbiB5b3VyIGV4YW1wbGUsICIrIiBjYW4gYmUgYWRkZWQgYXMgYSBsZWdhbCBkZWxpbWl0ZXIg Zm9yIGxvY2FscGFydHMuDQo+IC89XyEgY2FuIGJlIGFkZGVkIGFzIGxlZ2FsIGRlbGltaXRlcnMg bGlrZXdpc2UuDQo+PiBGb3IgbXkgZXhhbXBsZSwgIltTT09CT0sgaW4gVVRGOF0uW0xFRSBpbiBV VEY4XStlYWlfaWV0ZkBsc2Iub3JnIGNhbiBiZQ0KPiBhdXRvY29udmVydGVkIGludG8NCj4+ICJ4 bi0tc2JzYnNicy54bi0tbGVsZWxlbGUrZWFpX2lldGZAbHNiLm9yZy4gTm8gbG9zcyBvZiBpbmZv cm1hdGlvbi4gZG90DQo+IGFuZCArIGFuZCB1bmRlcmJhciB3YXMgbm90IGxvc3QuDQo+PiBUaGUg cmVjZWl2aW5nIFNNVFAgc2VydmVyIHBhcnNlcyBpdCBiYWNrIHRvIE5PTkFTQ0lJIGluIG9yZGVy IHRvIGZpbmQNCj4gZGF0YS9pbnN0cnVjdGlvbg0KPj4gZm9yIHdoaXRlbGlzdGluZyBmaWx0ZXJp bmcuIEV2ZW4gdGhlIHJlY2VpdmluZyBzZXJ2ZXIgY2FuIHdvcmsgZGlyZWN0bHkNCj4+IG9uIHhu LS0qKioqKiorZWFpX2lldGZAbHNiLm9yZyAgIHdpdGhvdXQgTk9OLUFTQ0lJIHZlcnNpb24gaWYg aXQgaXMNCj4gYWxyZWFkeSByZWdpc3RlcmVkDQo+PiBhcyBhbiBhc2NpaSAqYWxpYXMqIGZvciBO T05fQVNDSUkgaW4gdGhlIHNlcnZlciBhbGlhcyBkYXRhYmFzZS4NCj4+IFN0aWxsIEkgY2FuIGZp bmQgbm8gcHJvYmxlbSBhdCBhbGwuDQo+IEkgdmVyeSBhZ3JlZSBTb29ib2sgdmlld3MsIEJ1dCB0 aGlzIHdhcyBhIHZpb2xhdGlvbiBvZiB0aGUgZnJhbWV3b3JrDQo+IHJlcXVpcmVtZW50cy4NCg0K WWVzLCBpdCBpcyBhIHZpb2xhdGlvbiBvZiB0aGUgZnJhbWV3b3JrICByZXF1aXJlbWVudHMuDQoN Cj4gSGFyYWxkIHNhaWQ6IHRoYXQncyBhIGxvY2FsIGRlY2lzaW9uIGFib3V0IGF1dG9tYXRpYyBj b252ZXJ0aW5nLg0KPiBFdmVuIGlmIHRoZXJlIGFyZSBkZWxpbXRlcnMuDQoNCkFncmVlLiBpdCBp cyBhIGxvY2FsIGRlY2lzaW9uLCBub3Qgb3VyIHByb3RvY29sIGRlY2lzaW9uLg0KDQpZYW8gSmlh bmthbmcNCg0KPiANCj4gQWJlbA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ== --===============1529978680== 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 --===============1529978680==-- From ima-bounces@ietf.org Fri Dec 01 02:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq35w-00007o-63; Fri, 01 Dec 2006 02:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq35u-00007e-Bk for ima@ietf.org; Fri, 01 Dec 2006 02:46:02 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq35s-0000jc-Pt for ima@ietf.org; Fri, 01 Dec 2006 02:46:02 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB17jiLR026383; Fri, 1 Dec 2006 16:45:44 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB17ji1U026382; Fri, 1 Dec 2006 16:45:44 +0900 Date: Fri, 1 Dec 2006 16:45:44 +0900 From: Soobok Lee To: Yao Jiankang Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Message-ID: <20061201074544.GF24636@ns5.lsb.org> References: <364957934.02667@cnnic.cn> <034e01c7151a$f1a6ec50$1206e29f@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <034e01c7151a$f1a6ec50$1206e29f@cnnicyao> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Fri, Dec 01, 2006 at 03:33:06PM +0800, Yao Jiankang wrote: > > >> in your example, "+" can be added as a legal delimiter for localparts. > > /=_! can be added as legal delimiters likewise. > >> For my example, "[SOOBOK in UTF8].[LEE in UTF8]+eai_ietf@lsb.org can be > > autoconverted into > >> "xn--sbsbsbs.xn--lelelele+eai_ietf@lsb.org. No loss of information. dot > > and + and underbar was not lost. > >> The receiving SMTP server parses it back to NONASCII in order to find > > data/instruction > >> for whitelisting filtering. Even the receiving server can work directly > >> on xn--******+eai_ietf@lsb.org without NON-ASCII version if it is > > already registered > >> as an ascii *alias* for NON_ASCII in the server alias database. > >> Still I can find no problem at all. > > I very agree Soobok views, But this was a violation of the framework > > requirements. > > Yes, it is a violation of the framework requirements. > > > Harald said: that's a local decision about automatic converting. > > Even if there are delimters. > > Agree. it is a local decision, not our protocol decision. > > Yao Jiankang > > Abel Can you suggest the exact paragraph in the framework or other drafts about local decision ? Or articles in this WG? This will help us and audiences to understand that issue. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 03:44:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq40h-0003Mq-Py; Fri, 01 Dec 2006 03:44:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq40g-0003MA-SR for ima@ietf.org; Fri, 01 Dec 2006 03:44:42 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gq40f-0004jt-6k for ima@ietf.org; Fri, 01 Dec 2006 03:44:42 -0500 Received: (eyou send program); Fri, 01 Dec 2006 16:44:26 +0800 Message-ID: <364962666.29719@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Fri, 01 Dec 2006 16:44:26 +0800 Message-ID: <064801c71525$0e292820$1206e29f@cnnicyao> From: "Yao Jiankang" To: "Soobok Lee" References: <364957934.02667@cnnic.cn> <034e01c7151a$f1a6ec50$1206e29f@cnnicyao> <364959142.15727@cnnic.cn> Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Date: Fri, 1 Dec 2006 16:45:29 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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="===============1770511453==" Errors-To: ima-bounces@ietf.org --===============1770511453== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNvb2JvayBMZWUiIDxsc2JA bHNiLm9yZz4NClRvOiAiWWFvIEppYW5rYW5nIiA8eWFvamtAY25uaWMuY24+DQpDYzogPGltYUBp ZXRmLm9yZz47ICJhYmVsIiA8YWJlbHlhbmdAdHduaWMubmV0LnR3Pg0KU2VudDogRnJpZGF5LCBE ZWNlbWJlciAwMSwgMjAwNiAzOjQ1IFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gaTE4biBvZiBsb2Nh bHBhcnQgdmVyc3VzIGkxOG4gb2YgZW1haWwgUkZDIHN0YW5kYXJkcw0KDQoNCj4gT24gRnJpLCBE ZWMgMDEsIDIwMDYgYXQgMDM6MzM6MDZQTSArMDgwMCwgWWFvIEppYW5rYW5nIHdyb3RlOg0KPj4g DQo+PiA+PiBpbiB5b3VyIGV4YW1wbGUsICIrIiBjYW4gYmUgYWRkZWQgYXMgYSBsZWdhbCBkZWxp bWl0ZXIgZm9yIGxvY2FscGFydHMuDQo+PiA+IC89XyEgY2FuIGJlIGFkZGVkIGFzIGxlZ2FsIGRl bGltaXRlcnMgbGlrZXdpc2UuDQo+PiA+PiBGb3IgbXkgZXhhbXBsZSwgIltTT09CT0sgaW4gVVRG OF0uW0xFRSBpbiBVVEY4XStlYWlfaWV0ZkBsc2Iub3JnIGNhbiBiZQ0KPj4gPiBhdXRvY29udmVy dGVkIGludG8NCj4+ID4+ICJ4bi0tc2JzYnNicy54bi0tbGVsZWxlbGUrZWFpX2lldGZAbHNiLm9y Zy4gTm8gbG9zcyBvZiBpbmZvcm1hdGlvbi4gZG90DQo+PiA+IGFuZCArIGFuZCB1bmRlcmJhciB3 YXMgbm90IGxvc3QuDQo+PiA+PiBUaGUgcmVjZWl2aW5nIFNNVFAgc2VydmVyIHBhcnNlcyBpdCBi YWNrIHRvIE5PTkFTQ0lJIGluIG9yZGVyIHRvIGZpbmQNCj4+ID4gZGF0YS9pbnN0cnVjdGlvbg0K Pj4gPj4gZm9yIHdoaXRlbGlzdGluZyBmaWx0ZXJpbmcuIEV2ZW4gdGhlIHJlY2VpdmluZyBzZXJ2 ZXIgY2FuIHdvcmsgZGlyZWN0bHkNCj4+ID4+IG9uIHhuLS0qKioqKiorZWFpX2lldGZAbHNiLm9y ZyAgIHdpdGhvdXQgTk9OLUFTQ0lJIHZlcnNpb24gaWYgaXQgaXMNCj4+ID4gYWxyZWFkeSByZWdp c3RlcmVkDQo+PiA+PiBhcyBhbiBhc2NpaSAqYWxpYXMqIGZvciBOT05fQVNDSUkgaW4gdGhlIHNl cnZlciBhbGlhcyBkYXRhYmFzZS4NCj4+ID4+IFN0aWxsIEkgY2FuIGZpbmQgbm8gcHJvYmxlbSBh dCBhbGwuDQo+IA0KPj4gPiBJIHZlcnkgYWdyZWUgU29vYm9rIHZpZXdzLCBCdXQgdGhpcyB3YXMg YSB2aW9sYXRpb24gb2YgdGhlIGZyYW1ld29yaw0KPj4gPiByZXF1aXJlbWVudHMuDQo+PiANCj4+ IFllcywgaXQgaXMgYSB2aW9sYXRpb24gb2YgdGhlIGZyYW1ld29yayAgcmVxdWlyZW1lbnRzLg0K Pj4gDQo+PiA+IEhhcmFsZCBzYWlkOiB0aGF0J3MgYSBsb2NhbCBkZWNpc2lvbiBhYm91dCBhdXRv bWF0aWMgY29udmVydGluZy4NCj4+ID4gRXZlbiBpZiB0aGVyZSBhcmUgZGVsaW10ZXJzLg0KPj4g DQo+PiBBZ3JlZS4gaXQgaXMgYSBsb2NhbCBkZWNpc2lvbiwgbm90IG91ciBwcm90b2NvbCBkZWNp c2lvbi4NCj4+IA0KPj4gWWFvIEppYW5rYW5nIA0KPj4gPiBBYmVsDQo+IA0KPiBDYW4geW91IHN1 Z2dlc3QgdGhlIGV4YWN0IHBhcmFncmFwaCBpbiB0aGUgZnJhbWV3b3JrIG9yIG90aGVyIGRyYWZ0 cw0KPiBhYm91dCBsb2NhbCBkZWNpc2lvbiA/ICBPciBhcnRpY2xlcyBpbiB0aGlzIFdHPw0KDQpm b3IgZXhhbXBsZSwgdGhpcyBsaW5rOiBodHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2ltYS9jdXJyZW50L21zZzAwOTk1Lmh0bWwNCg0KWWFvIEppYW5rYW5nDQpDTk5JQw0KDQo+ IFRoaXMgd2lsbCBoZWxwIHVzIGFuZCBhdWRpZW5jZXMgdG8gdW5kZXJzdGFuZCB0aGF0IGlzc3Vl Lg0KPiANCj4gU29vYm9r --===============1770511453== 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 --===============1770511453==-- From ima-bounces@ietf.org Fri Dec 01 05:31:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5fl-00040I-NB; Fri, 01 Dec 2006 05:31:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5bJ-0004Db-J8 for ima@ietf.org; Fri, 01 Dec 2006 05:26:37 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5YJ-0001L9-O8 for ima@ietf.org; Fri, 01 Dec 2006 05:23:40 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB1ANPLR017246; Fri, 1 Dec 2006 19:23:25 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB1ANPcZ017245; Fri, 1 Dec 2006 19:23:25 +0900 Date: Fri, 1 Dec 2006 19:23:25 +0900 From: Soobok Lee To: Yao Jiankang Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards Message-ID: <20061201102325.GG24636@ns5.lsb.org> References: <364957934.02667@cnnic.cn> <034e01c7151a$f1a6ec50$1206e29f@cnnicyao> <364959142.15727@cnnic.cn> <064801c71525$0e292820$1206e29f@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <064801c71525$0e292820$1206e29f@cnnicyao> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Fri, Dec 01, 2006 at 04:45:29PM +0800, Yao Jiankang wrote: > > >> > >> Yes, it is a violation of the framework requirements. > >> > >> > Harald said: that's a local decision about automatic converting. > >> > Even if there are delimters. > >> > >> Agree. it is a local decision, not our protocol decision. > >> > >> Yao Jiankang > >> > Abel > > > > Can you suggest the exact paragraph in the framework or other drafts > > about local decision ? Or articles in this WG? > > for example, this link: http://www1.ietf.org/mail-archive/web/ima/current/msg00995.html > > Yao Jiankang > CNNIC > I found also this sentences in the beginning part of EAI WG charter. 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. Would anyone explain the reason behind this decision ? Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 06:12:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6JI-0000S3-Q7; Fri, 01 Dec 2006 06:12:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6JH-0000RL-OA for ima@ietf.org; Fri, 01 Dec 2006 06:12:03 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gq6EM-0006eA-8v for ima@ietf.org; Fri, 01 Dec 2006 06:07:03 -0500 Received: (snipe 21827 invoked by uid 0); 1 Dec 2006 20:08:32 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.023608 secs); Received: from unknown (HELO ?192.168.10.145?) (Zt??own@210.107.249.23) by unknown with SMTP; 1 Dec 2006 20:08:32 +0900 X-RCPTTO: lsb@lsb.org, ima@ietf.org, yangwooko@gmail.com Message-ID: <45700CD1.2050705@icu.ac.kr> Date: Fri, 01 Dec 2006 20:06:57 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards References: <364957934.02667@cnnic.cn> <034e01c7151a$f1a6ec50$1206e29f@cnnicyao> <364959142.15727@cnnic.cn> <064801c71525$0e292820$1206e29f@cnnicyao> <20061201102325.GG24636@ns5.lsb.org> In-Reply-To: <20061201102325.GG24636@ns5.lsb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Soobok Lee wrote: > On Fri, Dec 01, 2006 at 04:45:29PM +0800, Yao Jiankang wrote: >>>> Yes, it is a violation of the framework requirements. >>>> >>>>> Harald said: that's a local decision about automatic converting. >>>>> Even if there are delimters. >>>> Agree. it is a local decision, not our protocol decision. >>>> >>>> Yao Jiankang >>>>> Abel >>> Can you suggest the exact paragraph in the framework or other drafts >>> about local decision ? Or articles in this WG? >> for example, this link: http://www1.ietf.org/mail-archive/web/ima/current/msg00995.html >> >> Yao Jiankang >> CNNIC >> > > I found also this sentences in the beginning part of EAI WG charter. > > 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. > > > Would anyone explain the reason behind this decision ? Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. For discussion why it is impractically difficult to correctly encode local part is found at IMAA mailing list. I guess that nobody seems to repeat that work. Additional comments on "encoding by local policy". I think that my addresses are also encoded by ACE whose algorithm resides in my brain. I locally decided to map my name to all ASCII name. And it has worked well so far. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 06:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6Up-00080k-75; Fri, 01 Dec 2006 06:23:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6Uo-00080K-1P for ima@ietf.org; Fri, 01 Dec 2006 06:23:58 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gq6Um-0001Ia-F8 for ima@ietf.org; Fri, 01 Dec 2006 06:23:58 -0500 Received: (snipe 26208 invoked by uid 0); 1 Dec 2006 20:25:30 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.019696 secs); Received: from unknown (HELO ?192.168.10.145?) (Z???own@210.107.249.23) by unknown with SMTP; 1 Dec 2006 20:25:30 +0900 X-RCPTTO: lsb@lsb.org, ima@ietf.org, yangwooko@gmail.com Message-ID: <457010CB.8040300@icu.ac.kr> Date: Fri, 01 Dec 2006 20:23:55 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Soobok Lee References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> In-Reply-To: <20061201111036.GH24636@ns5.lsb.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 Subject: [EAI] Re: localprep and local decision 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 Soobok Lee wrote: > On Fri, Dec 01, 2006 at 10:16:47AM +0900, Yangwoo Ko wrote: >>> the nameprep with more delimiters(,=/_ etc) would be enough for >>> most asian and european email users. >>> >>> So, I suggest we have a draft for a stringprep profile for localpart >>> encoding in this WG. >> Section 7 of framework document mentions a little bit about >> local(?)-prep. I am very glad if you come up with a draft for >> this. >> >> However, I am confused because you mentioned some-prep the >> local-prep "only" in the context of ACE. I think that the >> usefulness of local-prep is not necessarily coupled with the >> use of a specific encoding. > > Let's call it "localprep" until we have a good name for it. > > You are right that localprep needs not be coupled with ACE > encoding. Its need is very clear even in utf8 localpart. > > As every participants already learned well in the past IDNA effort, > For example, cafe'(e with accent)@free.fr > > e' has two form, one is combind e' (U+00e9) > the other is two char form: e' (U+0065+U+0301) > > nameprep normalizes the latter form into the former one. > > We need some prohibited lists of chars which seems not > appropirate in local part, for example (@-like special symbols). > > My gut feeling is that the exact copy of nameprep is nearly enough > for localprep , only with some additional prohibited sets of chars > and additional set of delimiters other than period. > > But, isn't this vilolating so called "local decision" constraints, > if we set a rule on how to prohibit and normalize the localpart > over which the local site admin have "sovereignity" ? I don't think that using localprep violates anything unless it is used by MTAs except final delivery SMTP server. For example, it can used by email clients when accepting user's input. Or, even it can be used by final delivery SMTP server to find correct mailboxes for received messages. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 08:46:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8iR-0004UF-6f; Fri, 01 Dec 2006 08:46:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8iQ-0004U5-NF for ima@ietf.org; Fri, 01 Dec 2006 08:46:10 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq8iP-0002Fg-Dr for ima@ietf.org; Fri, 01 Dec 2006 08:46:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gq8i8-0000jX-58 for ima@ietf.org; Fri, 01 Dec 2006 14:45:52 +0100 Received: from pd9fba988.dip0.t-ipconnect.de ([217.251.169.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Dec 2006 14:45:52 +0100 Received: from nobody by pd9fba988.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Dec 2006 14:45:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] localprep and local decision Date: Fri, 01 Dec 2006 14:45:12 +0100 Organization: Lines: 18 Message-ID: <457031E8.51C6@xyzzy.claranet.de> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba988.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Soobok Lee wrote: > My gut feeling is that the exact copy of nameprep is nearly enough > for localprep , only with some additional prohibited sets of chars > and additional set of delimiters other than period. At the moment local parts are mixed case, but nameprep removes the differences between upper and lower case. Maybe you want saslprep (?) In another article <20061201042934.GE24636@ns5.lsb.org> you wrote: | MUA will be upgraded easily since their market is occupied | by a few big venders (MS,Mozilla,Opera,Eudora etc). I doubt that, any "upgrade all MUAs" scheme is IMNSHO dead on arrival. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 09:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8yc-0004LL-Vc; Fri, 01 Dec 2006 09:02:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8yb-0004Ac-AV for ima@ietf.org; Fri, 01 Dec 2006 09:02:53 -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 1Gq8ya-00055k-Ig for ima@ietf.org; Fri, 01 Dec 2006 09:02:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gq8yV-0009ly-Qy; Fri, 01 Dec 2006 09:02:48 -0500 Date: Fri, 01 Dec 2006 09:02:46 -0500 From: John C Klensin To: Soobok Lee , Yao Jiankang Subject: Automatic address remapping with and without EAI (was: Re: [EAI] i18n of localpart versus i18n of email RFC standards) Message-ID: <8E985E7DD66916849AE45340@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (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: f49c97ce49302a02285a2d36a99eef8c 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 Because this is off-topic for the WG mailing list and because my private explanation had no effect, it will be my last posting on the subject. However... --On Friday, 01 December, 2006 13:29 +0900 Soobok Lee wrote: >> so after EAI protocols are published, it is not our design >> aim that some email address form will be dis-allowed. > > in your example, "+" can be added as a legal delimiter for > localparts. /=_! can be added as legal delimiters likewise. > For my example, "[SOOBOK in UTF8].[LEE in > UTF8]+eai_ietf@lsb.org can be autoconverted into > "xn--sbsbsbs.xn--lelelele+eai_ietf@lsb.org. No loss of > information. dot and + and underbar was not lost. The > receiving SMTP server parses it back to NONASCII in order to > find data/instruction for whitelisting filtering. Even the > receiving server can work directly on > xn--******+eai_ietf@lsb.org without NON-ASCII version if it > is already registered as an ascii *alias* for NON_ASCII in the > server alias database. Still I can find no problem at all. This suggestion, too, was explored at some length on the old IMAA mailing list. There is no way to know that either "--" or "+" are delimiters in the protocol sense and, as a base SMTP issue, the IETF has consistently rejected proposals to standardize _any_ syntax or syntax elements for the local-part, including delimiters. So while, in principle, "+" could be "added as a legal delimiter for localparts", the IETF has consistently rejected that idea (for, IMO, good reasons and after bad experiences when such things have been tried). Even "--" is much more likely to have been used with specific semantics in an email address than it was in domain names. In addition, based on observation of discussions about IDNs over the last few years, there is every reason to expect the argument to be raised, loudly, that if the local-part cannot be _entirely_ in a non-ASCII script, without loss of functionality, then the effort is a failure. If a local-part of + was globally acceptable, then we would expect IDN1.IDN2. to be globally acceptable. Many people and countries have argued, very loudly, that it is not and should not be. Also note that "special delimiter in the middle of the local part", particularly with a requirement to switch scripts, can raise very complex issues with the presentation of the address (and how the user enters the address given a particular presantation) when one of the scripts runs right to left. These are fairly typical of the issues with these sorts of proposals. Any given one of them makes considerable sense in one or more local contexts. But, if one looks at it globally, there is just no way to standardize the delimiters or the mechanism without either restricting functionality in the i18nemail case or making rather basic changes in the historical email protocols. >> > moreover, ACE encoding for downgrading may be geared to >> > have minimum loss of information. For interoperability, >> > some default ace encoding is good for MUA/MTA. >> >> Yes, as you have already said, the EAI WG has not exclude >> some MUA/MTA which may use its own version of ACE encoding. > > Yes. it's better we have one default ace encoding rather than > having nothing , even though it can not be perfect and has > some costs. For email address local parts, "minimum loss of information" is not good enough. Either the information loss must be zero or it is safer to reject or bounce the message and let the sender correct the addressing (just as would probably be the case if I tried sending mail to 1sb@lab.org). Some of the same issues apply to "localprep". We've given mail system administrators advice for years that they should interpret local parts in a case-insensitive way and avoid the more complex quoting conventions permitted by the protocols if they want messages to get through. We've also advised them that, while very long local parts are permitted, using them may not be smart, or it might be wise to accept seven- or eight-character truncations as aliases (see below). But we have never changed the underlying rules. For non-ASCII addresses, I think it would be silly for a mail administrator who wants as many messages to get through to the intended destinations as possible to specify addresses that are not in NFKC form. Probably we will discover that some characters are a bad idea, or that setting up certain aliases (perhaps according to a JET-like model) is wise because systems elsewhere might inadvertently change what is typed. But, unless rather basic changes are made to how we do mail, it would be a terrible idea to turn those conventions about mailbox naming into a global rule that senders or intermediaries could depend on. Those issues about rules for name formation and alternate addresses are the oddity in the whole downgrade discussion. I've actually got a half-dozen email addresses, some of which might be deliverable when another one is not. And I've used some in the past that won't work at all any more or, worse, might reach someone else. If you send to an address that isn't working today, it is either held until it can be delivered or a non-delivery message is sent back to you (and, with current practices, you may or may not get the non-delivery message). If you sent to an address that isn't working at all, the attempt will probably be rejected. I'd argue that the same situation applies to telephone numbers. If I put two or three of them on a business card, and you are trying to reach me, you pick one and call it. If it doesn't work, you might try another. You don't expect the network to know what is on the business card and to try another one automatically, nor do you transmit all of the numbers at once, expecting the network to sort it out. Of course, you might be able to program your phone to try the numbers in sequence, but that would be like putting the alternate addresses in an address book and telling the MUA to try both addresses (assuming canonical non-delivery messages, a problem that has been discussed on this list before). Or I might be able to set up the network to do automatic forwarding, but that implies that the number you dialed is reachable, at least in the sense of reaching a switch that has the right database. In any event, if you find out that the address you sent over the wire isn't working, you either give up or figure out another address to try, possibly after contacting me in some way that does not involve the email system. We don't have protocols for guessing at different addresses, nor for transporting alternate addresses along with the preferred ones. And, for the last 30-odd years, I'm not aware of anyone thinking that was unusual. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 10:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqA28-0000jV-Dr; Fri, 01 Dec 2006 10:10:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqA27-0000jP-As for ima@ietf.org; Fri, 01 Dec 2006 10:10:35 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqA24-00015Z-Ov for ima@ietf.org; Fri, 01 Dec 2006 10:10:35 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB1FATLR027894; Sat, 2 Dec 2006 00:10:29 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB1FASHA027893; Sat, 2 Dec 2006 00:10:28 +0900 Date: Sat, 2 Dec 2006 00:10:28 +0900 From: Soobok Lee To: Yangwoo Ko Message-ID: <20061201151028.GL24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <457010CB.8040300@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457010CB.8040300@icu.ac.kr> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ima@ietf.org Subject: [EAI] Re: localprep and local decision 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, Dec 01, 2006 at 08:23:55PM +0900, Yangwoo Ko wrote: > > Soobok Lee wrote: > >For example, cafe'(e with accent)@free.fr > > > >e' has two form, one is combind e' (U+00e9) > > the other is two char form: e' (U+0065+U+0301) > > > >nameprep normalizes the latter form into the former one. > > > >But, isn't this vilolating so called "local decision" constraints, > >if we set a rule on how to prohibit and normalize the localpart > >over which the local site admin have "sovereignity" ? > > I don't think that using localprep violates anything unless > it is used by MTAs except final delivery SMTP server. For > example, it can used by email clients when accepting user's > input. Or, even it can be used by final delivery SMTP server > to find correct mailboxes for received messages. But, what if the local site admin wants to maintain separate mailboxes for e' and e+' for some reason. Enforcing NFKC-normalization-enabled localprep to localparts would bad the admin from having separate mailboxes. I think applying normalization to localpart are actually defining a kind of SYNTAXes that should be observed strictly. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 10:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAMv-0004Io-FH; Fri, 01 Dec 2006 10:32:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAMu-0004Ie-GP for ima@ietf.org; Fri, 01 Dec 2006 10:32:04 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqAMp-0004cZ-Va for ima@ietf.org; Fri, 01 Dec 2006 10:32:04 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3#clerew^man$ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.238) id 45704ae4.38b5.111 for ima@ietf.org; Fri, 1 Dec 2006 15:31:48 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kB1FViUC021088 for ; Fri, 1 Dec 2006 15:31:46 GMT Subject: Fwd: Re: [EAI] Local-Part auto converting ? References: <04d201c71360$712c1110$c7d348d3@aabbeell> <456D0558.6010604@icu.ac.kr> <057501c7136f$35401c00$c7d348d3@aabbeell> <456D1A72.9000700@icu.ac.kr> <05c501c71383$253ee1b0$c7d348d3@aabbeell> <5dejrmvhi4.fsf@leija.fmi.fi> <062701c7138e$663aecd0$c7d348d3@aabbeell> <456DA11F.4DD4@xyzzy.claranet.de> <629FC2492D208D2D363DFB44@p3.JCK.COM> <456DAA36.7090800@icu.ac.kr> <456DAFDA.40101@alvestrand.no> <9B0FF6AA6492B6E243B45373@p3.JCK.COM> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 01 Dec 2006 15:31:44 -0000 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Nov 2006 14:18:32 -0000, John C Klensin wrote: > --On Wednesday, 29 November, 2006 20:28 +0000 Charles Lindsey > wrote: >> Personally, I find it useful quite often. I receive some >> (possibly spam)whose To: and From: headers make no sense to >> me. So I look at the Receivedheaders to see why it came to me. >> That way the 'for' field will at leasttell me why it came to >> me, and whether I got it as chl@clerew.man.ac.uk,or as >> daemon@clerew.ac.uk, or as committee@usenet.org.uk or various >> otherpossibilities > > Of course, if there is more than one member of > "committee@usenet.org.uk", anything that supplies a "for" with > an individual address in it is violating the specs. Yes, but before it reached the point where it was split into the various individual members, the Received header will show "for committee@usenet.org.uk". Yes, tracing headers added later will make it clear what is happenng, but the easient thing to do with an email that seems 'odd' is to look at the earliest Received header present, which is usually enough on its own to tell you what was going on. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 10:59:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAnB-0006RL-7O; Fri, 01 Dec 2006 10:59:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAnA-0006RB-EA for ima@ietf.org; Fri, 01 Dec 2006 10:59:12 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqAmz-0000ia-AC for ima@ietf.org; Fri, 01 Dec 2006 10:59:12 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB1FwxLR002697; Sat, 2 Dec 2006 00:58:59 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB1FwwVK002696; Sat, 2 Dec 2006 00:58:58 +0900 Date: Sat, 2 Dec 2006 00:58:58 +0900 From: Soobok Lee To: Frank Ellermann Subject: Re: [EAI] localprep and local decision Message-ID: <20061201155858.GM24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <457031E8.51C6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457031E8.51C6@xyzzy.claranet.de> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Fri, Dec 01, 2006 at 02:45:12PM +0100, Frank Ellermann wrote: > Soobok Lee wrote: > > > My gut feeling is that the exact copy of nameprep is nearly enough > > for localprep , only with some additional prohibited sets of chars > > and additional set of delimiters other than period. > > At the moment local parts are mixed case, but nameprep removes the > differences between upper and lower case. Maybe you want saslprep (?) Yes. Saslprep has no casefolding, so saslprep may be the model we follow. I will refer saslprep profile from now on. Thanks. > > In another article <20061201042934.GE24636@ns5.lsb.org> you wrote: > > | MUA will be upgraded easily since their market is occupied > | by a few big venders (MS,Mozilla,Opera,Eudora etc). > > I doubt that, any "upgrade all MUAs" scheme is IMNSHO dead on arrival. I admit IDNA was adopted by IE7/firefox1.x after 4 years elapsed since IDNA efforts finished in 2002. It surely took some time. But within 2~3 years from now on, IE7+Firefox is expected to occupy 95% or more of end user base, i believe. I expect the similar time for utf8 EAI adoption. Of course, that may vary on how attractively we standardize this EAI protocol suite for industries. Soobok > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 01 11:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBGi-0004i2-BS; Fri, 01 Dec 2006 11:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBGh-0004h8-PY for ima@ietf.org; Fri, 01 Dec 2006 11:29:43 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBGg-0006A2-6f for ima@ietf.org; Fri, 01 Dec 2006 11:29:43 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB1GTdLR007449; Sat, 2 Dec 2006 01:29:39 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB1GTdQ4007447; Sat, 2 Dec 2006 01:29:39 +0900 Date: Sat, 2 Dec 2006 01:29:39 +0900 From: Soobok Lee To: Yangwoo Ko Subject: Re: [EAI] Re: localprep and local decision Message-ID: <20061201162939.GO24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <457010CB.8040300@icu.ac.kr> <20061201151028.GL24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061201151028.GL24636@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Sat, Dec 02, 2006 at 12:10:28AM +0900, Soobok Lee wrote: > On Fri, Dec 01, 2006 at 08:23:55PM +0900, Yangwoo Ko wrote: > > > > Soobok Lee wrote: > > >For example, cafe'(e with accent)@free.fr > > > > > >e' has two form, one is combind e' (U+00e9) > > > the other is two char form: e' (U+0065+U+0301) > > > > > >nameprep normalizes the latter form into the former one. > > > > > >But, isn't this vilolating so called "local decision" constraints, > > >if we set a rule on how to prohibit and normalize the localpart > > >over which the local site admin have "sovereignity" ? > > > > I don't think that using localprep violates anything unless > > it is used by MTAs except final delivery SMTP server. For > > example, it can used by email clients when accepting user's > > input. Or, even it can be used by final delivery SMTP server > > to find correct mailboxes for received messages. > > But, what if the local site admin wants to maintain separate > mailboxes for e' and e+' for some reason. Enforcing > NFKC-normalization-enabled localprep to localparts would > bad the admin from having separate mailboxes. > > I think applying normalization to localpart are actually > defining a kind of SYNTAXes that should be observed strictly. I will go further: In stringprep RFC section 2, i found some kind of syntax enforcement: 4) Check bidi -- Possibly check for right-to-left characters, and if any are found, make sure that the whole string satisfies the requirements for bidirectional strings. If the string does not satisfy the requirements for bidirectional strings, return an error. This is described in section 6. 6. Bidirectional Characters ... 2) If a string contains any RandALCat character, the string MUST NOT contain any LCat character. 3) If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string. Note that requirement 3 prohibits strings such as ("aleph 1") but allows strings such as ("aleph 1 beh"). [UAX9] goes into great detail about the display order of strings that contain particular categories of characters in particular sequences. If we apply bidi stringprep rules, aren't we defining some syntax over localparts? Soobok Lee _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 03 19:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr1KU-0002rw-L3; Sun, 03 Dec 2006 19:05:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr1KT-0002rr-04 for ima@ietf.org; Sun, 03 Dec 2006 19:05:05 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr1KR-0006NA-GN for ima@ietf.org; Sun, 03 Dec 2006 19:05:04 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00C632596DF; Mon, 4 Dec 2006 01:01:49 +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 03394-03; Mon, 4 Dec 2006 01:01:36 +0100 (CET) Received: from [192.168.1.103] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 723A82596D9; Mon, 4 Dec 2006 01:01:36 +0100 (CET) Date: Mon, 04 Dec 2006 00:59:57 +0100 From: Harald Alvestrand To: Soobok Lee , Yangwoo Ko Subject: Bidi (Re: [EAI] Re: localprep and local decision) Message-ID: In-Reply-To: <20061201162939.GO24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <457010CB.8040300@icu.ac.kr> <20061201151028.GL24636@ns5.lsb.org> <20061201162939.GO24636@ns5.lsb.org> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 FWIW, the stuff about bidi in the stringprep RFC has turned out to be less than optimal. I believe those restrictions would have been more appropriate at the nameprep level (IDNA specific) than at the stringprep level, since they are not uniformly useful. But that's water under the bridge. Check draft-alvestrand-idna-bidi for the details on some issues. Harald --On 2. desember 2006 01:29 +0900 Soobok Lee wrote: > On Sat, Dec 02, 2006 at 12:10:28AM +0900, Soobok Lee wrote: >> On Fri, Dec 01, 2006 at 08:23:55PM +0900, Yangwoo Ko wrote: >> > >> > Soobok Lee wrote: >> > > For example, cafe'(e with accent)@free.fr >> > > >> > > e' has two form, one is combind e' (U+00e9) >> > > the other is two char form: e' (U+0065+U+0301) >> > > >> > > nameprep normalizes the latter form into the former one. >> > > >> > > But, isn't this vilolating so called "local decision" constraints, >> > > if we set a rule on how to prohibit and normalize the localpart >> > > over which the local site admin have "sovereignity" ? >> > >> > I don't think that using localprep violates anything unless >> > it is used by MTAs except final delivery SMTP server. For >> > example, it can used by email clients when accepting user's >> > input. Or, even it can be used by final delivery SMTP server >> > to find correct mailboxes for received messages. >> >> But, what if the local site admin wants to maintain separate >> mailboxes for e' and e+' for some reason. Enforcing >> NFKC-normalization-enabled localprep to localparts would >> bad the admin from having separate mailboxes. >> >> I think applying normalization to localpart are actually >> defining a kind of SYNTAXes that should be observed strictly. > > I will go further: > In stringprep RFC section 2, i found some kind of syntax enforcement: > > > 4) Check bidi -- Possibly check for right-to-left characters, and if > any are found, make sure that the whole string satisfies the > requirements for bidirectional strings. If the string does not > satisfy the requirements for bidirectional strings, return an > error. This is described in section 6. > > > > 6. Bidirectional Characters > ... > 2) If a string contains any RandALCat character, the string MUST NOT > contain any LCat character. > > 3) If a string contains any RandALCat character, a RandALCat > character MUST be the first character of the string, and a > RandALCat character MUST be the last character of the string. > > Note that requirement 3 prohibits strings such as > ("aleph 1") but allows strings such as > ("aleph 1 beh"). [UAX9] goes into great detail about the display > order of strings that contain particular categories of characters in > particular sequences. > > > If we apply bidi stringprep rules, aren't we defining some syntax > over localparts? > > Soobok Lee > > _______________________________________________ > 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 Dec 03 23:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr5mZ-00018l-Pd; Sun, 03 Dec 2006 23:50:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr5mY-00018b-P0 for ima@ietf.org; Sun, 03 Dec 2006 23:50:22 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr5mX-0005Ee-73 for ima@ietf.org; Sun, 03 Dec 2006 23:50:22 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB44oELR000461 for ; Mon, 4 Dec 2006 13:50:14 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB44oDUX000460 for ima@ietf.org; Mon, 4 Dec 2006 13:50:13 +0900 Date: Mon, 4 Dec 2006 13:50:13 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20061204045013.GP24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] localprep and pop3 with saslprep username authetication 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 Hi, This is another thread derived from localprep vs local decision subject. If future EAI-capable pop3 MUA clients use saslprep-based authentication for username (which is the same with localpart mailbox name) comparison, Do we have any other choice but to accept saslprep as subset of localprep or saslprep==localprep? Or, should we request EAI-capable MUA vendors that only localprep be used for username preparation for authentication ? this is the saslprep RFC's url: http://www.ietf.org/rfc/rfc4013.txt Soobok Lee _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 04:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr9sw-0001cR-SI; Mon, 04 Dec 2006 04:13:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr9su-0001Yp-Cp for ima@ietf.org; Mon, 04 Dec 2006 04:13:12 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gr9sq-0000AM-On for ima@ietf.org; Mon, 04 Dec 2006 04:13:12 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F0452596E3; Mon, 4 Dec 2006 10:09:53 +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 21659-03; Mon, 4 Dec 2006 10:09:48 +0100 (CET) Received: from [192.168.1.103] (unknown [62.92.16.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id D42982596C2; Mon, 4 Dec 2006 10:09:47 +0100 (CET) Date: Mon, 04 Dec 2006 08:02:05 +0100 From: Harald Alvestrand To: Soobok Lee , ima@ietf.org Subject: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> In-Reply-To: <20061204045013.GP24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 4. desember 2006 13:50 +0900 Soobok Lee wrote: > Hi, > > This is another thread derived from localprep vs local decision subject. > > If future EAI-capable pop3 MUA clients use saslprep-based authentication > for username (which is the same with localpart mailbox name) comparison, False in general. My POP/IMAP mailbox name is "hta", while my normal email address is "harald@alvestrand.no". There's no link between the two required by any protocol. > Do we have any other choice but to accept saslprep as subset of > localprep or saslprep==localprep? > > Or, should we request EAI-capable MUA vendors that only localprep be > used for username preparation for authentication ? Do you mean "request" (offer advice) or "require" (make the standard specify that it has to be that way)? note: saslprep does not have a punycode stage. The result of saslprep is an UTF-8 string. > > this is the saslprep RFC's url: > > http://www.ietf.org/rfc/rfc4013.txt > > Soobok Lee > > _______________________________________________ > 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 Dec 04 04:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAa3-0001ZU-1w; Mon, 04 Dec 2006 04:57:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAa1-0001ZK-MR for ima@ietf.org; Mon, 04 Dec 2006 04:57:45 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrAZx-0001Cc-RB for ima@ietf.org; Mon, 04 Dec 2006 04:57:45 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kB49vZ7r001374 for ; Mon, 4 Dec 2006 18:57:35 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2c48_dd9f2b4c_837d_11db_9144_0014221f2a2d; Mon, 04 Dec 2006 18:57:34 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51343) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 4 Dec 2006 18:56:56 +0900 Message-Id: <6.0.0.20.2.20061204171843.0a518b00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 04 Dec 2006 17:37:37 +0900 To: Soobok Lee , Yangwoo Ko From: Martin Duerst Subject: Re: [EAI] localprep and local decision In-Reply-To: <20061201111036.GH24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 20:10 06/12/01, Soobok Lee wrote: >As every participants already learned well in the past IDNA effort, >For example, cafe'(e with accent)@free.fr > >e' has two form, one is combind e' (U+00e9) > the other is two char form: e' (U+0065+U+0301) I'll refer to these forms as e' and e+' below, same as Soobok did in another mail. >nameprep normalizes the latter form into the former one. > >We need some prohibited lists of chars which seems not >appropirate in local part, for example (@-like special symbols). > >My gut feeling is that the exact copy of nameprep is nearly enough >for localprep , only with some additional prohibited sets of chars >and additional set of delimiters other than period. > >But, isn't this vilolating so called "local decision" constraints, >if we set a rule on how to prohibit and normalize the localpart >over which the local site admin have "sovereignity" ? The situation for local parts is quite different from the situation for IDNA. In IDNA, we had to be very careful to avoid some party registering e' and another party registering e+'. In EAI, it's the same party being responsible for both, and a mail administrator would really be crazy if it registered both e' and e+', other than using e+' as an alias for e'. A mail administrator would also be rather crazy if s/he registered only e+', because e' is much more prevalent. So I think that to a large extent, we can leave things as advice for mail administrators: When you create an address, choose one that is at least NFC, better NFKC (and maybe add some additional advice). Similar advice would be in force for MUAs, where users type in email addresses from name cards. On top of that, there will be the advice that if you want to use a SASL-based security mechanism, you should stay within certain bounds. But in both cases, there is no absolute requirement. If somebody wants to set up an email address with an e+', it's their choice, they may just be way less reachable than with e'. If somebody sends email to e+', when it should be e', it's also their choice, the email will just bounce. In cases where there are regular bounces, an administrator may eventually get aware of it, and if necessary can add an alias e+' -> e'. A very sophisticated mail receiving agent may also do some conversions automatically, but that's not necessary. e' vs. e+' is only one example. For other normalization mappings, the chance that somebody uses the non-normalized notation can be higher (e.g. for the full-width equivalents of ASCII) or lower (e.g. for the number 2 with a circle around it), but essentially, the thinking can be the same for most if not all cases. This means that indeed this can be treated to a large extent as a local/bilateral issue. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 04:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAa3-0001Zb-5p; Mon, 04 Dec 2006 04:57:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAa1-0001ZP-PW for ima@ietf.org; Mon, 04 Dec 2006 04:57:45 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrAZx-0001Cd-RC for ima@ietf.org; Mon, 04 Dec 2006 04:57:45 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kB49vaJn026557 for ; Mon, 4 Dec 2006 18:57:36 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2bdb_de58203e_837d_11db_86e7_0014221f2a2d; Mon, 04 Dec 2006 18:57:35 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51343) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 4 Dec 2006 18:56:58 +0900 Message-Id: <6.0.0.20.2.20061204173809.0a519960@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 04 Dec 2006 17:41:03 +0900 To: Soobok Lee , Frank Ellermann From: Martin Duerst Subject: Re: [EAI] localprep and local decision In-Reply-To: <20061201155858.GM24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <457031E8.51C6@xyzzy.claranet.de> <20061201155858.GM24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 00:58 06/12/02, Soobok Lee wrote: >I admit IDNA was adopted by IE7/firefox1.x after 4 years elapsed since >IDNA efforts finished in 2002. It surely took some time. IDNA was in Mozilla about three years ago. That it took so long for IE7 to appear has nothing to do with IDNA. On the other hand, not every product gets upgraded at the same speed as Web browsers during the browser wars, so such timelags are certainly realistic in some sense. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 05:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAeJ-0003gf-Rd; Mon, 04 Dec 2006 05:02:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAeJ-0003fa-47 for ima@ietf.org; Mon, 04 Dec 2006 05:02:11 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrAeG-0001dO-GI for ima@ietf.org; Mon, 04 Dec 2006 05:02:11 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB4A23LR013306; Mon, 4 Dec 2006 19:02:03 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB4A23NX013305; Mon, 4 Dec 2006 19:02:03 +0900 Date: Mon, 4 Dec 2006 19:02:03 +0900 From: Soobok Lee To: Harald Alvestrand Subject: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <20061204100202.GQ24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, Dec 04, 2006 at 08:02:05AM +0100, Harald Alvestrand wrote: > --On 4. desember 2006 13:50 +0900 Soobok Lee wrote: > > >Hi, > > > >This is another thread derived from localprep vs local decision subject. > > > >If future EAI-capable pop3 MUA clients use saslprep-based authentication > >for username (which is the same with localpart mailbox name) comparison, > > False in general. My POP/IMAP mailbox name is "hta", while my normal email > address is "harald@alvestrand.no". There's no link between the two required > by any protocol. I agree with your that username and its localpart may be different in certain installations. But, in @yahoo.com and @hotmail.com , the localpart(or entire email addresses) is the username. that is very common, though not true in every case. When entire email address is used as username, that would complicate preparation job, because localpart should be prepared by localprep, while hostname part should be done by nameprep. > > >Do we have any other choice but to accept saslprep as subset of > >localprep or saslprep==localprep? > > > >Or, should we request EAI-capable MUA vendors that only localprep be > >used for username preparation for authentication ? > > Do you mean "request" (offer advice) or "require" (make the standard > specify that it has to be that way)? For pop3 authentication, in the case where username==localpart, I think "require localprep" is the answer. in the case where username!=localpart, I think "request for cautions" is the answer. But, pop3 MUA clients have no clue about whether its assinged pop3 server host has username==localpart rule or not. So, we have no other choice but "require localprep". > > note: saslprep does not have a punycode stage. The result of saslprep is an > UTF-8 string. This discustion is not meant directly for ACE-encoding. Under assumption that even utf8 localpart may need some normalization work. My question is that: if we "require" localprep to be applied to localparts, is this defining some syntactical rules over localparts and against "local decision principles/traditions" ? Soobok > > > > > >this is the saslprep RFC's url: > > > > http://www.ietf.org/rfc/rfc4013.txt > > > >Soobok Lee > > > >_______________________________________________ > >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 Dec 04 05:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrApx-0001rg-Bl; Mon, 04 Dec 2006 05:14:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrApw-0001qx-59 for ima@ietf.org; Mon, 04 Dec 2006 05:14:12 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrApu-0003b0-S9 for ima@ietf.org; Mon, 04 Dec 2006 05:14:12 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BA0D2596BB; Mon, 4 Dec 2006 11:10:56 +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 22781-09; Mon, 4 Dec 2006 11:10:50 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE9152580CA; Mon, 4 Dec 2006 11:10:50 +0100 (CET) Message-ID: <4573F4EB.6060701@alvestrand.no> Date: Mon, 04 Dec 2006 11:14:03 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] localprep and pop3 with saslprep username authetication References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> <20061204100202.GQ24636@ns5.lsb.org> In-Reply-To: <20061204100202.GQ24636@ns5.lsb.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: 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 Soobok Lee wrote: > For pop3 authentication, > in the case where username==localpart, I think "require localprep" is the answer. > in the case where username!=localpart, I think "request for cautions" is the answer. > > But, pop3 MUA clients have no clue about whether its assinged pop3 server host has > username==localpart rule or not. > > So, we have no other choice but "require localprep". > Yes, we have another choice. Don't define a localprep, and leave it as a local matter, just like the specs currently say. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 05:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAvl-00007w-Qf; Mon, 04 Dec 2006 05:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAvl-00007r-7f for ima@ietf.org; Mon, 04 Dec 2006 05:20:13 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrAvg-0004mO-IZ for ima@ietf.org; Mon, 04 Dec 2006 05:20:13 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB4AK0LR015734; Mon, 4 Dec 2006 19:20:01 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB4AJvIG015728; Mon, 4 Dec 2006 19:19:57 +0900 Date: Mon, 4 Dec 2006 19:19:57 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] localprep and local decision Message-ID: <20061204101957.GR24636@ns5.lsb.org> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <6.0.0.20.2.20061204171843.0a518b00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061204171843.0a518b00@localhost> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Mon, Dec 04, 2006 at 05:37:37PM +0900, Martin Duerst wrote: > At 20:10 06/12/01, Soobok Lee wrote: > > The situation for local parts is quite different from > the situation for IDNA. In IDNA, we had to be very careful to > avoid some party registering e' and another party registering e+'. > In EAI, it's the same party being responsible for both, and > a mail administrator would really be crazy if it registered > both e' and e+', other than using e+' as an alias for e'. > A mail administrator would also be rather crazy if s/he > registered only e+', because e' is much more prevalent. > > So I think that to a large extent, we can leave things as > advice for mail administrators: When you create an address, > choose one that is at least NFC, better NFKC (and maybe > add some additional advice). Similar advice would be in > force for MUAs, where users type in email addresses from > name cards. On top of that, there will be the advice that > if you want to use a SASL-based security mechanism, you > should stay within certain bounds. > > But in both cases, there is no absolute requirement. If > somebody wants to set up an email address with an e+', > it's their choice, they may just be way less reachable > than with e'. If somebody sends email to e+', when it > should be e', it's also their choice, the email will > just bounce. In cases where there are regular bounces, > an administrator may eventually get aware of it, and > if necessary can add an alias e+' -> e'. A very > sophisticated mail receiving agent may also do some > conversions automatically, but that's not necessary. > > e' vs. e+' is only one example. For other normalization > mappings, the chance that somebody uses the non-normalized > notation can be higher (e.g. for the full-width equivalents > of ASCII) or lower (e.g. for the number 2 with a circle > around it), but essentially, the thinking can be the same > for most if not all cases. > > This means that indeed this can be treated to a large > extent as a local/bilateral issue. If application of localprep is just a local issue, sending MUA clients should not normalize recipients' localparts, rather should send as it is entered. Of course, the receiving smtp/pop3 server admins can decide either to apply localprep or not to apply localprep to localparts according to their site-specific need. That is, "there is localprep RFC, but, applying or not applying this is on your choice". Do you agree with this advice for MUA/MTA implementors? Regards, Soobok > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 05:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrB2j-0007Fu-TI; Mon, 04 Dec 2006 05:27:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrB2i-0007Dp-RJ for ima@ietf.org; Mon, 04 Dec 2006 05:27:24 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrB2h-0005h1-9u for ima@ietf.org; Mon, 04 Dec 2006 05:27:24 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB4ARJLR016787; Mon, 4 Dec 2006 19:27:19 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB4ARJgU016786; Mon, 4 Dec 2006 19:27:19 +0900 Date: Mon, 4 Dec 2006 19:27:19 +0900 From: Soobok Lee To: Harald Alvestrand Subject: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <20061204102719.GS24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> <20061204100202.GQ24636@ns5.lsb.org> <4573F4EB.6060701@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4573F4EB.6060701@alvestrand.no> User-Agent: Mutt/1.4i 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 Mon, Dec 04, 2006 at 11:14:03AM +0100, Harald Alvestrand wrote: > Soobok Lee wrote: > >For pop3 authentication, > >in the case where username==localpart, I think "require localprep" is the > >answer. > >in the case where username!=localpart, I think "request for cautions" is > >the answer. > > > >But, pop3 MUA clients have no clue about whether its assinged pop3 server > >host has username==localpart rule or not. > > > >So, we have no other choice but "require localprep". > > > Yes, we have another choice. > > Don't define a localprep, and leave it as a local matter, just like the > specs currently say. Yet another choice: Define a localprep, leave its adoption as a local matter. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 05:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrB4w-000844-6z; Mon, 04 Dec 2006 05:29:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrB4v-00083z-55 for ima@ietf.org; Mon, 04 Dec 2006 05:29:41 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrB4s-0005tF-R7 for ima@ietf.org; Mon, 04 Dec 2006 05:29:41 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C61122596BB; Mon, 4 Dec 2006 11:26:23 +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 23307-04; Mon, 4 Dec 2006 11:26:18 +0100 (CET) Received: from [192.168.1.103] (unknown [62.92.16.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4516A2580CA; Mon, 4 Dec 2006 11:26:18 +0100 (CET) Date: Mon, 04 Dec 2006 11:29:31 +0100 From: Harald Alvestrand To: Soobok Lee Subject: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <275CF9D0D5B13C9A5CF38B6D@[172.28.60.143]> In-Reply-To: <20061204102719.GS24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> <20061204100202.GQ24636@ns5.lsb.org> <4573F4EB.6060701@alvestrand.no> <20061204102719.GS24636@ns5.lsb.org> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 4. desember 2006 19:27 +0900 Soobok Lee wrote: > On Mon, Dec 04, 2006 at 11:14:03AM +0100, Harald Alvestrand wrote: >> Soobok Lee wrote: >> > For pop3 authentication, >> > in the case where username==localpart, I think "require localprep" is >> > the answer. >> > in the case where username!=localpart, I think "request for cautions" >> > is the answer. >> > >> > But, pop3 MUA clients have no clue about whether its assinged pop3 >> > server host has username==localpart rule or not. >> > >> > So, we have no other choice but "require localprep". >> > >> Yes, we have another choice. >> >> Don't define a localprep, and leave it as a local matter, just like the >> specs currently say. > > Yet another choice: > Define a localprep, leave its adoption as a local matter. > If its adoption is a local matter, it is not required. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 05:31:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrB6Q-0000IM-2C; Mon, 04 Dec 2006 05:31:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrB6P-0000IC-De for ima@ietf.org; Mon, 04 Dec 2006 05:31:13 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrB6N-000671-SA for ima@ietf.org; Mon, 04 Dec 2006 05:31:13 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB4AV7LR017330; Mon, 4 Dec 2006 19:31:07 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB4AV7Zc017329; Mon, 4 Dec 2006 19:31:07 +0900 Date: Mon, 4 Dec 2006 19:31:07 +0900 From: Soobok Lee To: Harald Alvestrand Subject: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <20061204103107.GT24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> <20061204100202.GQ24636@ns5.lsb.org> <4573F4EB.6060701@alvestrand.no> <20061204102719.GS24636@ns5.lsb.org> <275CF9D0D5B13C9A5CF38B6D@[172.28.60.143]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <275CF9D0D5B13C9A5CF38B6D@[172.28.60.143]> User-Agent: Mutt/1.4i 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 List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, Dec 04, 2006 at 11:29:31AM +0100, Harald Alvestrand wrote: > > > --On 4. desember 2006 19:27 +0900 Soobok Lee wrote: > > >On Mon, Dec 04, 2006 at 11:14:03AM +0100, Harald Alvestrand wrote: > >>Soobok Lee wrote: > >>> For pop3 authentication, > >>> in the case where username==localpart, I think "require localprep" is > >>> the answer. > >>> in the case where username!=localpart, I think "request for cautions" > >>> is the answer. > >>> > >>> But, pop3 MUA clients have no clue about whether its assinged pop3 > >>> server host has username==localpart rule or not. > >>> > >>> So, we have no other choice but "require localprep". > >>> > >>Yes, we have another choice. > >> > >>Don't define a localprep, and leave it as a local matter, just like the > >>specs currently say. > > > >Yet another choice: > > Define a localprep, leave its adoption as a local matter. > > > If its adoption is a local matter, it is not required. Yes. Its application will be just an advice, not a requirement. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 06:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrBYq-0007Lx-1L; Mon, 04 Dec 2006 06:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrBYo-0007Hd-MD for ima@ietf.org; Mon, 04 Dec 2006 06:00:34 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrBYa-0002fC-He for ima@ietf.org; Mon, 04 Dec 2006 06:00:22 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB4B0GLR021617; Mon, 4 Dec 2006 20:00:16 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB4B0F4U021616; Mon, 4 Dec 2006 20:00:15 +0900 Date: Mon, 4 Dec 2006 20:00:15 +0900 From: Soobok Lee To: Harald Alvestrand Subject: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <20061204110015.GU24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> <20061204100202.GQ24636@ns5.lsb.org> <4573F4EB.6060701@alvestrand.no> <20061204102719.GS24636@ns5.lsb.org> <275CF9D0D5B13C9A5CF38B6D@[172.28.60.143]> <20061204103107.GT24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061204103107.GT24636@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 this is for clarification of the past issues under the assumption that "define localpre, but whether applying localprep or not is just a local issue": > > --On 4. desember 2006 19:27 +0900 Soobok Lee wrote: > > > > >On Mon, Dec 04, 2006 at 11:14:03AM +0100, Harald Alvestrand wrote: > > >>Soobok Lee wrote: > > >>> For pop3 authentication, > > >>> in the case where username==localpart, I think "require localprep" is > > >>> the answer. In this case where username==localpart && localprep is NOT applied by local decision, if pop3 clients preprocess using "saslprep" for username authentication, there may be a possiblilty that saslprep(username)!=username and login attempt fails. But, this is a local issue and the local site admin should be aware of this possiblity and optionally can manage to add "dual username accounts" that are mapped to single mailbox(localpart). > > >>> in the case where username!=localpart, I think "request for cautions" > > >>> is the answer. In this case where username may not always be equal to localpart, saslprep(username) for authentication is irrelevant to our localprep for localparts issue. it is just a local authentication issue. Soobok > > >>> > > >>> But, pop3 MUA clients have no clue about whether its assinged pop3 > > >>> server host has username==localpart rule or not. > > >>> > > >>> So, we have no other choice but "require localprep". > > >>> > > >>Yes, we have another choice. > > >> > > >>Don't define a localprep, and leave it as a local matter, just like the > > >>specs currently say. > > > > > >Yet another choice: > > > Define a localprep, leave its adoption as a local matter. > > > > > If its adoption is a local matter, it is not required. > > Yes. Its application will be just an advice, not a requirement. > > Soobok > > _______________________________________________ > 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 Dec 04 10:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGAV-0000tX-7j; Mon, 04 Dec 2006 10:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGAU-0000rH-2J for ima@ietf.org; Mon, 04 Dec 2006 10:55:46 -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 1GrGAS-0008Hb-A3 for ima@ietf.org; Mon, 04 Dec 2006 10:55:46 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GrGAM-000CcF-R5; Mon, 04 Dec 2006 10:55:39 -0500 Date: Mon, 04 Dec 2006 10:55:37 -0500 From: John C Klensin To: Martin Duerst , Soobok Lee , Yangwoo Ko Subject: Design of mailbox names (was: Re: [EAI] localprep and local decision) Message-ID: <5D7AF94490C35BD7E5EF3015@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20061204171843.0a518b00@localhost> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <6.0.0.20.2.20061204171843.0a518b00@localhost> X-Mailer: Mulberry/4.0.6 (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: 21bf7a2f1643ae0bf20c1e010766eb78 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 For whatever it is worth, I think Martin's analysis is exactly right. We need to remember that we are operating in an email environment with an extensive deployed base of users, mailboxes, and practices not (as with IDNs) looking at an essentially open field with only the (known) constraints implied by the DNS itself. There are lots of reasons why the email environment is the way it is, most of them good, but, even if there were not, the deployment base is such that we could not realistically reopen them without turning this discussion into "new mail system". In particular, we have told people for years that making addresses case-insensitive (whether that is done by algorithm or aliasing) and aliasing confusing addresses is wise if they want mail to be delivered. We have advised sites that want to use very long local parts to support shorter aliases (provided either by truncation or by out-of-band communication with potential senders who are length-limited). Multiple aliases that reflect alternate variations on the same name have also been considered wise: the idea now has to be traded off against "how much extra spam would you like", but, a few years ago, it would have been reasonable for my "klensin" mailbox to also be accessible with local parts containing "john.klensin", "john.c.klensin", etc., jsut to avoid unnecessary bounces and out-of-band discussions when people decided to guess. We've given out all sorts of advice like this; some written in RFCs and some not. But the protocols, for good reason (IMO), continue to reflect a world in which the range of flexibility in accepting an address belongs strictly to the delivery host and system. Even when looking at POP and IMAP, while it is common to have the "user" name that is associated with a mailbox be the same as, or closely-related to, the name of the mailbox as seen by someone sending traffic to it, that has never been a requirement. Some systems have taken advantage of the fact that it is not and their ability to do that is usually considered A Good Thing. Conversely, no system I know of permits, e.g., a POP mailbox to be accessed using any or all of the "user" names by which traffic can be sent for delivery to that mailbox... and that is not something I've every heard people complain about. It wouldn't be hard to do, it wouldn't violate the protocols, but no one bothers. When this WG was chartered, it was agreed that a "recommendations to mail server operators" document would eventually need to be written. it was also agreed that it didn't belong in the initial charter but that is was something that should be developed as implementations occurred and deployment experience accumulated. However, if people really want to discuss this topic --which isn't about "localprep" but about advice about as to how mailbox names (and appropriate aliases and synonyms) should be designed and developed, I suggest that you start on that document. I think that an early start could be immensely useful, but please do the work by trying to write an I-D, not by speculation and hand waving about some hypothetical "localprep" that is somehow like stringprep2003 but not quite. My own contribution to that effort is that (1) Local mailbox names should be NFKC compliant, at least. (2) They should also not contain spaces (or any Unicode flavor), quotes (ditto), or invisible characters if that can be avoided. And, if it cannot, incoming addresses should be accepted as matching if those characters are stripped. (3) Comparisons between the name of the local mailbox and an incoming local part should be case-independent (and liberal), independent of the next principle. (4) For a local mailbox named LocalMailbox, accept any incoming local part s.t., NFKC(incoming-local-part)=NFKC(LocalMailbox) or NFKD(incoming-local-part)=NFKD(LocalMailbox) Rules like those are less complex than Stringprep (either nameprep or SASLprep). And, for an application which should probably be motivated by "let's see if the incoming-local-part is a good match for a mailbox that we have here", that simplicity is appropriate. I'd be happy to read and comment on drafts of such a document, but please don't do the work on this mailing list. john --On Monday, 04 December, 2006 17:37 +0900 Martin Duerst wrote: > At 20:10 06/12/01, Soobok Lee wrote: > >> As every participants already learned well in the past IDNA >> effort, For example, cafe'(e with accent)@free.fr >> >> e' has two form, one is combind e' (U+00e9) >> the other is two char form: e' (U+0065+U+0301) > > I'll refer to these forms as e' and e+' below, same > as Soobok did in another mail. >... >> But, isn't this vilolating so called "local decision" >> constraints, if we set a rule on how to prohibit and >> normalize the localpart over which the local site admin have >> "sovereignity" ? > > The situation for local parts is quite different from > the situation for IDNA. In IDNA, we had to be very careful to > avoid some party registering e' and another party registering > e+'. In EAI, it's the same party being responsible for both, > and a mail administrator would really be crazy if it registered > both e' and e+', other than using e+' as an alias for e'. A > mail administrator would also be rather crazy if s/he > registered only e+', because e' is much more prevalent. > > So I think that to a large extent, we can leave things as > advice for mail administrators: When you create an address, > choose one that is at least NFC, better NFKC (and maybe > add some additional advice). Similar advice would be in > force for MUAs, where users type in email addresses from > name cards. On top of that, there will be the advice that > if you want to use a SASL-based security mechanism, you > should stay within certain bounds. > > But in both cases, there is no absolute requirement. If > somebody wants to set up an email address with an e+', > it's their choice, they may just be way less reachable > than with e'. If somebody sends email to e+', when it > should be e', it's also their choice, the email will > just bounce. In cases where there are regular bounces, > an administrator may eventually get aware of it, and > if necessary can add an alias e+' -> e'. A very > sophisticated mail receiving agent may also do some > conversions automatically, but that's not necessary. > > e' vs. e+' is only one example. For other normalization > mappings, the chance that somebody uses the non-normalized > notation can be higher (e.g. for the full-width equivalents > of ASCII) or lower (e.g. for the number 2 with a circle > around it), but essentially, the thinking can be the same > for most if not all cases. > > This means that indeed this can be treated to a large > extent as a local/bilateral issue. > > Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 11:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGFk-0004aG-II; Mon, 04 Dec 2006 11:01:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGFi-0004Zg-KW for ima@ietf.org; Mon, 04 Dec 2006 11:01:10 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGFf-0000iV-7J for ima@ietf.org; Mon, 04 Dec 2006 11:01:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GrGFb-0002CH-E4 for ima@ietf.org; Mon, 04 Dec 2006 17:01:03 +0100 Received: from d253117.dialin.hansenet.de ([80.171.253.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Dec 2006 17:01:03 +0100 Received: from nobody by d253117.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Dec 2006 17:01:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] localprep and local decision Date: Mon, 04 Dec 2006 17:00:07 +0100 Organization: Lines: 10 Message-ID: <45744607.33F3@xyzzy.claranet.de> References: <20061130164924.GA24636@ns5.lsb.org> <456F827F.8070902@icu.ac.kr> <20061201111036.GH24636@ns5.lsb.org> <6.0.0.20.2.20061204171843.0a518b00@localhost> <20061204101957.GR24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253117.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Soobok Lee wrote: > Do you agree with this advice for MUA/MTA implementors? FWIW I agree. The sender can't know how the admin at the site of the receiver partitions the available local parts if there's no strict rule (like saslprep) to follow. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 20:13:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrOsN-0004N9-Ns; Mon, 04 Dec 2006 20:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrOsM-0004N0-Cx for ima@ietf.org; Mon, 04 Dec 2006 20:13:38 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrOsK-0006eR-RV for ima@ietf.org; Mon, 04 Dec 2006 20:13:38 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB51DULR000951 for ; Tue, 5 Dec 2006 10:13:30 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB51DU5g000950 for ima@ietf.org; Tue, 5 Dec 2006 10:13:30 +0900 Date: Tue, 5 Dec 2006 10:13:30 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20061205011330.GV24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] design and display of non-ascii mailbox name 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 MSIE 7.0/firefox 2.0 have a feature that displays IDN as its punycode form if the IDN is suspicious of phishing purpose or has some special characters in labels. Then, in EAI context, what should MUA implementors do for NON-ASCII localpart that is thought to be manufactured to confuse/fraud recipients? For example, some localparts may contain space-like and @-like symbols or even a-like chars, 1) c(cyrillic a)t@hotmail.com 2) c(cyrillic a)t@hotm(cyrillic a)il.com 3) cat@hotm(cyrillic a)il.com Do you have any idea about how to warn end users when they received this From: address or are about to reply to this sender address? Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 04 22:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrQww-0005zb-Rg; Mon, 04 Dec 2006 22:26:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrQwv-0005zS-AO for ima@ietf.org; Mon, 04 Dec 2006 22:26:29 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrQwt-0004IV-O7 for ima@ietf.org; Mon, 04 Dec 2006 22:26:29 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB53QPLR020668 for ; Tue, 5 Dec 2006 12:26:25 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB53QPNY020667 for ima@ietf.org; Tue, 5 Dec 2006 12:26:25 +0900 Date: Tue, 5 Dec 2006 12:26:25 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] design and display of non-ascii mailbox name Message-ID: <20061205032625.GW24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061205011330.GV24636@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) 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: , Errors-To: ima-bounces@ietf.org On Tue, Dec 05, 2006 at 10:13:30AM +0900, Soobok Lee wrote: > > MSIE 7.0/firefox 2.0 have a feature that displays IDN > as its punycode form if the IDN is suspicious of > phishing purpose or has some special characters in labels. > > Then, in EAI context, what should MUA implementors do > for NON-ASCII localpart that is thought to be manufactured > to confuse/fraud recipients? For example, some localparts > may contain space-like and @-like symbols or even a-like chars, > > 1) c(cyrillic a)t@hotmail.com > 2) c(cyrillic a)t@hotm(cyrillic a)il.com > 3) cat@hotm(cyrillic a)il.com one of my self-answers is MUA's displaying cyrillic a in localpart ==> %u0430 cyrillic a in hostname ==> entire hostname in punycode form (cyrillic a has U+0430 code number). any other recommendation ? Soobok > > Do you have any idea about how to warn end users when they > received this From: address or are about to reply to > this sender address? > > Soobok > > _______________________________________________ > 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 Dec 05 01:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrTrQ-0002Yu-JT; Tue, 05 Dec 2006 01:33:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrTrP-0002Yp-SK for ima@ietf.org; Tue, 05 Dec 2006 01:32:59 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrTrL-0006NP-3Q for ima@ietf.org; Tue, 05 Dec 2006 01:32:59 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kB56WfB0018368 for ; Tue, 5 Dec 2006 15:32:41 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 377e_686a9264_842a_11db_9baa_0014221fa3c9; Tue, 05 Dec 2006 15:32:41 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53710) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 5 Dec 2006 15:32:02 +0900 Message-Id: <6.0.0.20.2.20061205130036.0b350ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 05 Dec 2006 13:01:34 +0900 To: Soobok Lee , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name In-Reply-To: <20061205011330.GV24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 10:13 06/12/05, Soobok Lee wrote: > >MSIE 7.0/firefox 2.0 have a feature that displays IDN >as its punycode form if the IDN is suspicious of >phishing purpose or has some special characters in labels. > >Then, in EAI context, what should MUA implementors do >for NON-ASCII localpart that is thought to be manufactured >to confuse/fraud recipients? For example, some localparts >may contain space-like and @-like symbols or even a-like chars, > >1) c(cyrillic a)t@hotmail.com >2) c(cyrillic a)t@hotm(cyrillic a)il.com >3) cat@hotm(cyrillic a)il.com > >Do you have any idea about how to warn end users when they >received this From: address or are about to reply to >this sender address? It's a user interface issue, so we don't need a standard. The main point is that users see that something is wrong. I hope that hotmail and friends keep their act together and don't allow registration of such local parts anyway. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 05 01:55:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrUD2-0005sZ-6f; Tue, 05 Dec 2006 01:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrUD0-0005rK-NV for ima@ietf.org; Tue, 05 Dec 2006 01:55:18 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrUCy-0002S8-40 for ima@ietf.org; Tue, 05 Dec 2006 01:55:18 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB56t9LR020688; Tue, 5 Dec 2006 15:55:09 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB56t9S4020687; Tue, 5 Dec 2006 15:55:09 +0900 Date: Tue, 5 Dec 2006 15:55:09 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name Message-ID: <20061205065509.GX24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061205130036.0b350ec0@localhost> User-Agent: Mutt/1.4i 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 On Tue, Dec 05, 2006 at 01:01:34PM +0900, Martin Duerst wrote: > At 10:13 06/12/05, Soobok Lee wrote: > > > >MSIE 7.0/firefox 2.0 have a feature that displays IDN > >as its punycode form if the IDN is suspicious of > >phishing purpose or has some special characters in labels. > > > >Then, in EAI context, what should MUA implementors do > >for NON-ASCII localpart that is thought to be manufactured > >to confuse/fraud recipients? For example, some localparts > >may contain space-like and @-like symbols or even a-like chars, > > > >1) c(cyrillic a)t@hotmail.com > >2) c(cyrillic a)t@hotm(cyrillic a)il.com > >3) cat@hotm(cyrillic a)il.com > > > >Do you have any idea about how to warn end users when they > >received this From: address or are about to reply to > >this sender address? > > It's a user interface issue, so we don't need a standard. Of course, it's a user interface issue. But, past IDNA RFC also recommended (not required) displaying in puny code form when needed, for example,when fonts are not available for IND labels. So touching some user interface issue may be included in RFC in special case. Even in EAI, if MUA find no available fonts for localparts, some actions may be needed as in the case of IDNA. We have no ACE encoding, so, we should instead choose a hexadecimal notation or else somethign equivalent one. %uXXXX is very good common hex notation. > The main point is that users see that something is wrong. Yes. > I hope that hotmail and friends keep their act together > and don't allow registration of such local parts anyway. I am curious whether IDN hotm(cyrillic a)il.com can be registered or not *NOW*. Once we (JET) had released CJK registration guideline so that less confusible CJK domain names are registerd in TLD registries. I don't know GTLD registries respect that guildeline, while eastern asian ccTLDs might have done so. Soobok > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 05 03:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrVh1-0003cB-Dr; Tue, 05 Dec 2006 03:30:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrVh0-0003c6-TA for ima@ietf.org; Tue, 05 Dec 2006 03:30:22 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrVgx-0002n8-10 for ima@ietf.org; Tue, 05 Dec 2006 03:30:22 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kB58UFoS004807 for ; Tue, 5 Dec 2006 17:30:16 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5485_d52c913a_843a_11db_9b3c_0014221f2a2d; Tue, 05 Dec 2006 17:30:15 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50629) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 5 Dec 2006 17:29:35 +0900 Message-Id: <6.0.0.20.2.20061205172211.0b2dec20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 05 Dec 2006 17:26:52 +0900 To: Soobok Lee From: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name In-Reply-To: <20061205065509.GX24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 15:55 06/12/05, Soobok Lee wrote: >Even in EAI, if MUA find no available fonts for localparts, >some actions may be needed as in the case of IDNA. >We have no ACE encoding, so, we should instead choose >a hexadecimal notation or else somethign equivalent one. > >%uXXXX is very good common hex notation. So are many other, similar ones. Some display systems even have the ability to display four hex digits in a 2x2 block the same hight as usual characters. That happens at a much lower level than the application program, so there is no point in us specifying it. >I am curious whether IDN hotm(cyrillic a)il.com can >be registered or not *NOW*. I'd assume that Verisign learned a lot from the p(cyrillic a)ypal.com incident. Making a mistake once can happen to everybody; repeating the same mistake would be really bad. >Once we (JET) had released CJK registration guideline >so that less confusible CJK domain names are registerd >in TLD registries. I don't know GTLD registries respect >that guildeline, while eastern asian ccTLDs might have >done so. My understanding is that .jp doesn't apply JET guidlines. I don't know about .com and friends. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 05 03:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrW6I-0000hU-12; Tue, 05 Dec 2006 03:56:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrW6G-0000hI-Rz for ima@ietf.org; Tue, 05 Dec 2006 03:56:29 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrW6F-0006fE-A8 for ima@ietf.org; Tue, 05 Dec 2006 03:56:28 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB58uPLR007909; Tue, 5 Dec 2006 17:56:25 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB58uPkc007908; Tue, 5 Dec 2006 17:56:25 +0900 Date: Tue, 5 Dec 2006 17:56:25 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name Message-ID: <20061205085625.GY24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061205172211.0b2dec20@localhost> User-Agent: Mutt/1.4i 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 On Tue, Dec 05, 2006 at 05:26:52PM +0900, Martin Duerst wrote: > At 15:55 06/12/05, Soobok Lee wrote: > > >Even in EAI, if MUA find no available fonts for localparts, > >some actions may be needed as in the case of IDNA. > >We have no ACE encoding, so, we should instead choose > >a hexadecimal notation or else somethign equivalent one. > > > >%uXXXX is very good common hex notation. > > So are many other, similar ones. Some display systems > even have the ability to display four hex digits in > a 2x2 block the same hight as usual characters. > That happens at a much lower level than the application > program, so there is no point in us specifying it. BTW, I know your IRI (in W3C) draft had defined some %-escaping conventions for i18ned hostname and path part of i18ned Resource Indicator in order to be put into . Would you tell us about that experience? Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 05 10:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grc7b-0001Ot-5h; Tue, 05 Dec 2006 10:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grc7Z-0001On-Ni for ima@ietf.org; Tue, 05 Dec 2006 10:22:13 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grc7W-000236-9X for ima@ietf.org; Tue, 05 Dec 2006 10:22:13 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Grc7S-0002MV-3U for ima@ietf.org; Tue, 05 Dec 2006 16:22:06 +0100 Received: from d254172.dialin.hansenet.de ([80.171.254.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Dec 2006 16:22:06 +0100 Received: from nobody by d254172.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Dec 2006 16:22:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] design and display of non-ascii mailbox name Date: Tue, 05 Dec 2006 16:12:23 +0100 Organization: Lines: 31 Message-ID: <45758C57.7FB@xyzzy.claranet.de> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> <20061205085625.GY24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254172.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Soobok Lee wrote: [u+1234, IRIs, and other creatures] > Would you tell us about that experience? For an IRI you parse it into its parts, scheme, authority, path, query, etc. The scheme is supposed to be US-ASCII. The authority might contain a host name, for that you'd use IDNA(bis) "punycode", with the xn--what-ever format for the labels. For the rest transform local charset to Unicode, Unicode to UTF-8, and percent-encode it as needed (keeping most ASCII VCHARs as is). Put it together again as parsed, and you've got the corresponding URL. Not very friendly for human readers if they have to look at the URL instead of the IRI, because UTF-8 is modulo 64 magic. In mail you could use a friendlier format for say a local part, decode UTF-8 to Unicode, display all code points also available in the local charset excl. "=" as is, and for the rest use the somewhat familiar =12=34 QP-style, with =3D for a real "=". No showstopper. The most critical EAI point are IMO the "MIME considerations", when John reported a decisive "ick" from an expert. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 06:00:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruVD-0008OB-H8; Wed, 06 Dec 2006 05:59:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruVC-0008Ka-0b for ima@ietf.org; Wed, 06 Dec 2006 05:59:50 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GruV8-0004wU-Q9 for ima@ietf.org; Wed, 06 Dec 2006 05:59:49 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kB6AxXnc006175 for ; Wed, 6 Dec 2006 19:59:33 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5f0c_da918a20_8518_11db_8417_0014221f2a2d; Wed, 06 Dec 2006 19:59:32 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:45652) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 6 Dec 2006 19:58:54 +0900 Message-Id: <6.0.0.20.2.20061206183414.09536ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 06 Dec 2006 18:39:13 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name In-Reply-To: <45758C57.7FB@xyzzy.claranet.de> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> <20061205085625.GY24636@ns5.lsb.org> <45758C57.7FB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 00:12 06/12/06, Frank Ellermann wrote: >Soobok Lee wrote: > > [u+1234, IRIs, and other creatures] >> Would you tell us about that experience? > >For an IRI you parse it into its parts, scheme, authority, >path, query, etc. The scheme is supposed to be US-ASCII. > >The authority might contain a host name, for that you'd >use IDNA(bis) "punycode", with the xn--what-ever format >for the labels. For the rest transform local charset to >Unicode, Unicode to UTF-8, and percent-encode it as needed >(keeping most ASCII VCHARs as is). Put it together again >as parsed, and you've got the corresponding URL. You can convert to an URI without parsing an IRI, just by converting Unicode->UTF-8->%-encoded (leaving US-ASCII as is). The IRI spec also allows using punycode for those cases where an implementation knows the scheme and knows that it deals with a domain name. >Not very friendly for human readers if they have to look >at the URL instead of the IRI, because UTF-8 is modulo 64 >magic. Modulo anything, even simple hex, is not human-friendly. >In mail you could use a friendlier format for say a local >part, decode UTF-8 to Unicode, display all code points >also available in the local charset excl. "=" as is, and >for the rest use the somewhat familiar =12=34 QP-style, >with =3D for a real "=". That won't fly. You can't distinguish two == in a row from U+3D3D (or will have some other problem, depending on how exactly you define your scheme). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 08:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grwdp-00044U-I4; Wed, 06 Dec 2006 08:16:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grwdo-00044P-9L for ima@ietf.org; Wed, 06 Dec 2006 08:16:52 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grwdm-0001iS-Mb for ima@ietf.org; Wed, 06 Dec 2006 08:16:52 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew$man#ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 4576c2bf.8308.19 for ima@ietf.org; Wed, 6 Dec 2006 13:16:47 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kB6DGjHE012180 for ; Wed, 6 Dec 2006 13:16:46 GMT Subject: Fwd: Re: [EAI] localprep and pop3 with saslprep username authetication References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 06 Dec 2006 13:16:44 -0000 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) 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, 04 Dec 2006 07:02:05 -0000, Harald Alvestrand wrote: > --On 4. desember 2006 13:50 +0900 Soobok Lee wrote: >> Or, should we request EAI-capable MUA vendors that only localprep be >> used for username preparation for authentication ? > > Do you mean "request" (offer advice) or "require" (make the standard > specify that it has to be that way)? Well there is also an intermediate option, which is "recommend" (aka SHOULD). If you type é on your keyboard, then your operating system or MUA or whatever is 99.999% likely to give you e' rather than e+. In fact, generating e+ from your keyboard probably requires technical skills beyond the average user. So a domain owner who permits e+ in a local-part of an address in his system is going to find that people worldwide are going to have great difficulty communicating with him. So much so, that you can well argue that it is a matter of interoperability, and hence SHOULD (and maybe even MUST, but I will settle for SHOULD) is justified. If that is accepted, then the next question is where you apply it. At the minimum you would say that domains allocating local-parts to their users SHOULD make them NFC-compatible (or else normalize them on receipt). You might also say that MUAs when composing addreseses SHOULD make them NFC-compatible, but that is likely to be their default behaviour anyway. That also accords with the Unicode tradition of "early normalization". For sure, all intermediate MTAs should pass on exactly what they receive. You might argue that if an MUA sees an e+ in a Reply-To, it should reply to exactly what it sees. Anf finally, if you are making such a rule, then you can choose between NFC, NFKC, saslprep or some other localprep. And finally, if it is a SHOULD rather than a MUST, then the script kiddies can have fun by using non-normalized local-parts by mutual agreement, so that us adults will have difficulty communicating with them. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 08:54:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrxEL-0004uZ-4K; Wed, 06 Dec 2006 08:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrxEJ-0004uD-Pa for ima@ietf.org; Wed, 06 Dec 2006 08:54:35 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrxEH-00088z-9I for ima@ietf.org; Wed, 06 Dec 2006 08:54:35 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB6DsELR024115; Wed, 6 Dec 2006 22:54:14 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB6DsDCn024113; Wed, 6 Dec 2006 22:54:13 +0900 Date: Wed, 6 Dec 2006 22:54:13 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: Fwd: Re: [EAI] localprep and pop3 with saslprep username authetication Message-ID: <20061206135413.GZ24636@ns5.lsb.org> References: <20061204045013.GP24636@ns5.lsb.org> <02D07E33DF7855CC87DF2E92@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Dec 06, 2006 at 01:16:44PM -0000, Charles Lindsey wrote: > On Mon, 04 Dec 2006 07:02:05 -0000, Harald Alvestrand > > > >Do you mean "request" (offer advice) or "require" (make the standard > >specify that it has to be that way)? > > Well there is also an intermediate option, which is "recommend" (aka > SHOULD). > > .... > > At the minimum you would say that domains allocating local-parts to their > users SHOULD make them NFC-compatible (or else normalize them on receipt). > > You might also say that MUAs when composing addreseses SHOULD make them > NFC-compatible, but that is likely to be their default behaviour anyway. I also prefer SHOULD to MUST or MAY. If we use "MUST", it would force syntaxes over localparts. > That also accords with the Unicode tradition of "early normalization". Do you have any tech reports (utc) known about this "early normaliation" ? > For sure, all intermediate MTAs should pass on exactly what they receive. You > might argue that if an MUA sees an e+ in a Reply-To, it should reply to > exactly what it sees. If MUA implementation shares the same email address postprocessing routines for replying and composing, their may be no way to "reply to exactly what it sees". I can't imagine MUA architects normalized differently for reply-to sender address and typed/addrbooked recipient addresses. "All or nothing" seems simpler to me. > > Anf finally, if you are making such a rule, then you can choose between > NFC, NFKC, saslprep or some other localprep. Are you suggesting that our draft enumerate those alternatives and recommend them to choose one among them ? Or, should we designate single most preferrable one in our draft ? > > And finally, if it is a SHOULD rather than a MUST, then the script kiddies > can have fun by using non-normalized local-parts by mutual agreement, so > that us adults will have difficulty communicating with them. Yes. it will allow rooms for other normailzation or no normalization. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 10:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryMS-0006df-60; Wed, 06 Dec 2006 10:07:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryMQ-0006dY-P8 for ima@ietf.org; Wed, 06 Dec 2006 10:07:02 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryMP-0002Ag-6M for ima@ietf.org; Wed, 06 Dec 2006 10:07:02 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB6F6wLR001070; Thu, 7 Dec 2006 00:06:58 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB6F6tCW001067; Thu, 7 Dec 2006 00:06:55 +0900 Date: Thu, 7 Dec 2006 00:06:55 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name Message-ID: <20061206150655.GA24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> <20061205085625.GY24636@ns5.lsb.org> <45758C57.7FB@xyzzy.claranet.de> <6.0.0.20.2.20061206183414.09536ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061206183414.09536ec0@localhost> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Dec 06, 2006 at 06:39:13PM +0900, Martin Duerst wrote: > At 00:12 06/12/06, Frank Ellermann wrote: > > >In mail you could use a friendlier format for say a local > >part, decode UTF-8 to Unicode, display all code points > >also available in the local charset excl. "=" as is, and If MUA "knows" which local charsets are being used in users' computing environment, we MAY display in alternative forms those unfamilar/exotic character for users. > >for the rest use the somewhat familiar =12=34 QP-style, > >with =3D for a real "=". > > That won't fly. You can't distinguish two == in a row > from U+3D3D (or will have some other problem, depending > on how exactly you define your scheme). As Martin and Frank suggested, there may be good multiple hex notations on the table or MUA's own innovative method of alternative display of exotic/suspicious localparts. Unlink that of IDNA, we have no "fallback" ACE encoding. I welcome any suggestion from your about most desired wording for this. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 10:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryRE-00015o-DA; Wed, 06 Dec 2006 10:12:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryRD-00015j-4X for ima@ietf.org; Wed, 06 Dec 2006 10:11:59 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryR9-0002xw-GV for ima@ietf.org; Wed, 06 Dec 2006 10:11:59 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB6FBrLR001672; Thu, 7 Dec 2006 00:11:53 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB6FBqab001671; Thu, 7 Dec 2006 00:11:52 +0900 Date: Thu, 7 Dec 2006 00:11:52 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] design and display of non-ascii mailbox name Message-ID: <20061206151152.GB24636@ns5.lsb.org> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> <20061205085625.GY24636@ns5.lsb.org> <45758C57.7FB@xyzzy.claranet.de> <6.0.0.20.2.20061206183414.09536ec0@localhost> <20061206150655.GA24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061206150655.GA24636@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Dec 07, 2006 at 12:06:55AM +0900, Soobok Lee wrote: > > Unlink that of IDNA, we have no "fallback" ACE encoding. I am sorry for this late correction: Unlike the case of IDNA, we have no "fallback" ACE encoding for EAI. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 11:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzRO-00069H-Oh; Wed, 06 Dec 2006 11:16:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzRO-00069B-5L for ima@ietf.org; Wed, 06 Dec 2006 11:16:14 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrzRK-00005W-HZ for ima@ietf.org; Wed, 06 Dec 2006 11:16:13 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GrzRF-000624-5N for ima@ietf.org; Wed, 06 Dec 2006 17:16:05 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 17:16:05 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 17:16:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] design and display of non-ascii mailbox name Date: 06 Dec 2006 18:15:54 +0200 Lines: 13 Message-ID: <5d8xhlq9tx.fsf@Hurtta06k.keh.iki.fi> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> <20061205085625.GY24636@ns5.lsb.org> <45758C57.7FB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > In mail you could use a friendlier format for say a local > part, decode UTF-8 to Unicode, display all code points > also available in the local charset excl. "=" as is, and > for the rest use the somewhat familiar =12=34 QP-style, > with =3D for a real "=". Or printing them in from `xxxx using reverse video for example. > Frank / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 12:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0ko-0005KG-JH; Wed, 06 Dec 2006 12:40:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0kn-0005K4-19 for ima@ietf.org; Wed, 06 Dec 2006 12:40:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs0kl-0003BM-N3 for ima@ietf.org; Wed, 06 Dec 2006 12:40:21 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gs0kf-0002GW-ML for ima@ietf.org; Wed, 06 Dec 2006 18:40:13 +0100 Received: from d255228.dialin.hansenet.de ([80.171.255.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 18:40:13 +0100 Received: from nobody by d255228.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 18:40:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] design and display of non-ascii mailbox name Date: Wed, 06 Dec 2006 18:38:20 +0100 Organization: Lines: 19 Message-ID: <4577000C.119D@xyzzy.claranet.de> References: <20061205011330.GV24636@ns5.lsb.org> <6.0.0.20.2.20061205130036.0b350ec0@localhost> <20061205065509.GX24636@ns5.lsb.org> <6.0.0.20.2.20061205172211.0b2dec20@localhost> <20061205085625.GY24636@ns5.lsb.org> <45758C57.7FB@xyzzy.claranet.de> <6.0.0.20.2.20061206183414.09536ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255228.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > Modulo anything, even simple hex, is not human-friendly. I like hex. or similar better than UTF-8 or B64, but for a greater audience it's probably both "some kind of gibberish different from ROT13". [pseudo-QP proposal] > That won't fly. You can't distinguish two == in a row > from U+3D3D ACK, I forgot the delimiter problem -- embarassing, I read CHARMOD, but that was 2005... :-) A possible choice is the the ሴ notation. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 12:57:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs11L-00062o-Ul; Wed, 06 Dec 2006 12:57:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs11L-00062j-5H for ima@ietf.org; Wed, 06 Dec 2006 12:57:27 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs11H-0005Mk-Sr for ima@ietf.org; Wed, 06 Dec 2006 12:57:27 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.20; Wed, 6 Dec 2006 09:57:23 -0800 Received: from WINSE-MSG-01.segroup.winse.corp.microsoft.com (157.54.2.134) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.20; Wed, 6 Dec 2006 09:57:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Dec 2006 09:57:56 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design and display of non-ascii mailbox name thread-index: AccZPhQYozxOfq19Q0mVeG2wo5hB1wAIV8hQ References: From: Shawn Steele To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] Re: design and display of non-ascii mailbox name 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 Homographs and other issues are addressed somewhat by Unicode TR#36 "Unicode Security Considerations". http://www.unicode.org/reports/tr36/ IMHO this is a problem with any sort of protocol like this and it should be left to a different standard or the software designer to address. Hopefully there'd be a consistent behavior on a machine so that the end user would have a consistent experience. - Shawn _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 19:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7AK-0002on-3u; Wed, 06 Dec 2006 19:31:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7AJ-0002oc-8b for ima@ietf.org; Wed, 06 Dec 2006 19:31:07 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7AH-0001q7-EN for ima@ietf.org; Wed, 06 Dec 2006 19:31:07 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB70V2LR005332; Thu, 7 Dec 2006 09:31:02 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB70V2JN005331; Thu, 7 Dec 2006 09:31:02 +0900 Date: Thu, 7 Dec 2006 09:31:02 +0900 From: Soobok Lee To: Shawn Steele Subject: Re: [EAI] Re: design and display of non-ascii mailbox name Message-ID: <20061207003102.GC24636@ns5.lsb.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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 On Wed, Dec 06, 2006 at 09:57:56AM -0800, Shawn Steele wrote: > Homographs and other issues are addressed somewhat by Unicode TR#36 > "Unicode Security Considerations". http://www.unicode.org/reports/tr36/ > IMHO this is a problem with any sort of protocol like this and it should > be left to a different standard or the software designer to address. > Hopefully there'd be a consistent behavior on a machine so that the end > user would have a consistent experience. 2.10.3 User Agent Recommendations The following recommendations are for user agents in handling domain names. The term 'user agent' is interpreted broadly to mean any program that displays Internationalized Domain Names to a user, including browsers and emailers. For information on the confusable tests mentioned below, see Section 4. Confusable Detection [UTS39]. If the user can see the case-folded form, use the lowercase-only confusable mappings; otherwise use the broader mappings. 1. Follow Section 2.10.2 General Programmer Recommendations. 2. Display 1. Either always show the domain name in nameprepped form [RFC3491], or make it very easy for the user to see it (see Section 2.8.1 Case-Folded Format). For example, this could be a tooltip interface, or a separate box. 2. Always display the domain name with a visually highlighted domain name, to prevent syntax spoofs (see Section 2.6 Syntax Spoofing). 3. Always display IRIs with bidi content according to the IRI specification [RFC3987]. 3. Preferences 1. In preferences, allow the user to select the desired Restriction Level to apply to domain names. Set the default to Restriction Level 2. 2. In preferences, allow the user to select among additional scripts that can be used without alerting. The default can be based on the user's locale. 3. In preferences, allow the user to choose a backwards compatibility setting; see Section 2.9.1 Backwards Compatibility. comment: 2.1) localparts are not domain names, so they are not (MUST BE) nameprepped,and are put in different location in IRI/URL, but optionally normailzed by something other. 2.2) we hope to check whether some syntax spoofs/interferences with neighboring @hostname part is possible and problematic. 2.3) IRI has all %escaped non-ascii chars (both localpart and hostname). I hope we could display only problematic parts in alternative form. 3.1~2) "restriction level" and "default locale" is a good starding point. I think our draft can refer to TR#36 for this matter, as informative reference. Thanks. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 19:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7R0-00060S-7N; Wed, 06 Dec 2006 19:48:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7Qz-00060N-5a for ima@ietf.org; Wed, 06 Dec 2006 19:48:21 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7Qx-0005OW-Ha for ima@ietf.org; Wed, 06 Dec 2006 19:48:21 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB70mHLR008420 for ; Thu, 7 Dec 2006 09:48:17 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB70mHGj008419 for ima@ietf.org; Thu, 7 Dec 2006 09:48:17 +0900 Date: Thu, 7 Dec 2006 09:48:17 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20061207004817.GD24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [EAI] display of RightToLeft chars in localparts and hostnames 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 http://www.ietf.org/internet-drafts/draft-alvestrand-idna-bidi-00.txt (page 6) and http://www.unicode.org/reports/tr36/#Bidirectional_Text_Spoofing If you read above references, you can understand why this: (storage order) LocalRTL@FirstRTL.SecondRTL.com (display order) LTRdnoceS.LTRtsriF@LTRlacoL.com ( @ and dot are neutral chars wrt RtL and LtR direction) I remember that there had been some discussion about whether we should do "RtoL stopper chars"(this may be not the right tech term, sorry) around delimiters like @ or dot. this may not have any definitive right answer, but we may have better choose one anyway. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 19:59:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7bU-0002wS-Oe; Wed, 06 Dec 2006 19:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7bT-0002wL-8N for ima@ietf.org; Wed, 06 Dec 2006 19:59:11 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7bR-00079c-In for ima@ietf.org; Wed, 06 Dec 2006 19:59:11 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB70x7LR010247 for ; Thu, 7 Dec 2006 09:59:07 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB70x7sg010239 for ima@ietf.org; Thu, 7 Dec 2006 09:59:07 +0900 Date: Thu, 7 Dec 2006 09:59:07 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] display of RightToLeft chars in localparts and hostnames Message-ID: <20061207005907.GE24636@ns5.lsb.org> References: <20061207004817.GD24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207004817.GD24636@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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, Dec 07, 2006 at 09:48:17AM +0900, Soobok Lee wrote: > > > > http://www.ietf.org/internet-drafts/draft-alvestrand-idna-bidi-00.txt (page 6) > and http://www.unicode.org/reports/tr36/#Bidirectional_Text_Spoofing > > If you read above references, you can understand why this: > (storage order) > LocalRTL@FirstRTL.SecondRTL.com > > (display order) > LTRdnoceS.LTRtsriF@LTRlacoL.com > > ( @ and dot are neutral chars wrt RtL and LtR direction) > > I remember that there had been some discussion about whether > we should do "RtoL stopper chars"(this may be not the right tech term, sorry) > around delimiters like @ or dot. > > this may not have any definitive right answer, but we may have better choose > one anyway. one of my self-answer is "for display preparation, insert RtoL stopper around all special chars in IRI/URL". If we follow this: (new display order) LTRlacoL@LTRtsriF.LTRdnoceS.com here each @ and dot have preceding unseen(transparent) RtoL stopper char. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 06 21:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8ck-0003oX-V4; Wed, 06 Dec 2006 21:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8cj-0003oM-OO for ima@ietf.org; Wed, 06 Dec 2006 21:04:33 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs8ci-0006xA-3T for ima@ietf.org; Wed, 06 Dec 2006 21:04:33 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB724QLR021603 for ; Thu, 7 Dec 2006 11:04:26 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB724P3n021600 for ima@ietf.org; Thu, 7 Dec 2006 11:04:25 +0900 Date: Thu, 7 Dec 2006 11:04:25 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20061207020425.GF24636@ns5.lsb.org> References: <20061207004817.GD24636@ns5.lsb.org> <20061207005907.GE24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207005907.GE24636@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [EAI] (summary) display of RightToLeft chars in localparts and hostnames 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, Dec 07, 2006 at 09:59:07AM +0900, Soobok Lee wrote: > On Thu, Dec 07, 2006 at 09:48:17AM +0900, Soobok Lee wrote: > > > > http://www.ietf.org/internet-drafts/draft-alvestrand-idna-bidi-00.txt (page 6) > > and http://www.unicode.org/reports/tr36/#Bidirectional_Text_Spoofing > > > > If you read above references, you can understand why this: > > (storage order) > > LocalRTL@FirstRTL.SecondRTL.com > > > > (old display order) > > LTRdnoceS.LTRtsriF@LTRlacoL.com > > > > ( @ and dot are neutral chars wrt RtL and LtR direction) > > > > I remember that there had been some discussion about whether > > we should do "RtoL stopper chars"(this may be not the right tech term, sorry) > > around delimiters like @ or dot. > > > > this may not have any definitive right answer, but we may have better choose > > one anyway. > > one of my self-answer is "for display preparation, insert RtoL stopper around > all special chars in IRI/URL". > > If we follow this: > > (new display order) > LTRlacoL@LTRtsriF.LTRdnoceS.com > > here each @ and dot have preceding unseen(transparent) RtoL stopper char. For RtoL stopper, we can use "LRE dot PDF" sequence. But, we still have 3 problems: 1) the above choice would still make input-time display order still look as (old display order), since we can't expect input method editors for BIDI chars intelligently determine when to insert such surrounding stoppers on the running input entry form. So we should provide consistent user experience around all of storage order, input time order,old display order, and new display order. But, it won't be a trvial task. 2) Moreover, when we copy and paste (new display order) hostname and localpart strings, they may contain hidden LRE and PDF chars which have been *prohibited* in stringprep. (http://www.ietf.org/rfc/rfc3454.txt section 5 and section 5.8) When IDN hostnames contains prohibited chars, they will fail be stringpreped and return an error. To prevent this from happening, bidi LRE /PDF should not be copied by mouse operation. 3) localparts may contain dots, for example, [OSAMA].[BIN].[LADEN]@free.af how to display dot-containing bidi localparts would complicate this problem. I guess localpart dot should follow the way that hostname dot does . I welcome any criticism/suggestion. Soobok > > Soobok > > _______________________________________________ > 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 Dec 07 08:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJUi-0007ny-Fu; Thu, 07 Dec 2006 08:41:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJUg-0007kS-TR for ima@ietf.org; Thu, 07 Dec 2006 08:40:58 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsJUc-000478-EK for ima@ietf.org; Thu, 07 Dec 2006 08:40:58 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GsJUF-0003WD-V4 for ima@ietf.org; Thu, 07 Dec 2006 14:40:31 +0100 Received: from d252141.dialin.hansenet.de ([80.171.252.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Dec 2006 14:40:31 +0100 Received: from nobody by d252141.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Dec 2006 14:40:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Re: design and display of non-ascii mailbox name Date: Thu, 07 Dec 2006 14:39:17 +0100 Organization: Lines: 27 Message-ID: <45781985.2164@xyzzy.claranet.de> References: <20061207003102.GC24636@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252141.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Soobok Lee wrote: > I think our draft can refer to TR#36 for this matter, as informative > reference. Just in case, it's not in the general bibxml library: Unicode Security Considerations Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 07 09:39:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKPW-0005I6-H2; Thu, 07 Dec 2006 09:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKPV-0005Hu-CN for ima@ietf.org; Thu, 07 Dec 2006 09:39:41 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKPP-0006iJ-EN for ima@ietf.org; Thu, 07 Dec 2006 09:39:41 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew*man&ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.238) id 4578279b.172af.437 for ima@ietf.org; Thu, 7 Dec 2006 14:39:23 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kB7EdK6D000624 for ; Thu, 7 Dec 2006 14:39:21 GMT Date: Thu, 07 Dec 2006 14:39:20 -0000 To: IMA References: <4575E2F5.6C97@xyzzy.claranet.de> 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: In-Reply-To: <4575E2F5.6C97@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [EAI] Re: draft-ellermann-news-nntp-uri-04 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 Tue, 05 Dec 2006 21:21:57 -0000, Frank Ellermann wrote: > Charles Lindsey wrote: >> Again, you have a format for a whole group: > >> nntp://server.example/comp/lang.c > >> which was not actually allowed in RFC 1738, but might be useful even >> though it means the same as > >> news://server.example/comp/lang.c > > Oddly RFC 1738 allows the server + group syntax only for the > nntp-scheme. Yes, but the point I was trying to make is that you were introducing a new feature not present in RFC 1738, which does not permit "nntp://server.example/comp.lang.c" or "nntp://server.example/comp.lang.c/" at all. Not that I object to that (since I want to go further by adding s), but you did not point out that you were introducing an extension. > It's frustrating for users if some URLs don't work for them. It's also > bad for the support stuff if they'd have to answer question why some > fancy style of URLs for a protocol they've never before heard of (their > own NNTP server) doesn't work. But that's a problem with NNTP, not with your URIs. Generally speaking, RFC 3977 is not backwards compatible with RFC 977 insofar as several new features in 3977 (including full wildmats and ranges in some contexts) will not be understood by existing implementations of 977. Nevertheless, 3977 is a vast improvement on 977 because it makes the usage of wildmats and ranges consistently available in all the places where they would make sense. But it is reasonable to suppose that implementations will catch up within the next few years, and it would be a pity if URIs were artificially constrained from taking advantage when they do. > > Not all features of a decent newsreader or NNTP-server implemented after > 3977 was published some weeks ago need a 1:1 correspondence in URIs. An > URL is a "hey, look at this" thing, it's supposed to work for anybody. > > That's not the case with the fancier wildmats, and also unnecessary. > The comma doesn't work unencoded with some UAs, the question mark is a > nightmare, and the exclamation mark doesn't fly without the comma. I see absolutely nothing in RFC 3986 which would require %-encoding of comma or exclamation (or course, %-encoding, even if not necessary, never does any harm). RFC 3986 provides: reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" where the are the ones given meaning in RFC 3986 itself. What that means is that no scheme is allowed to give special meeaning to a non-reserved character that would ever make %-encoding it necessary. But %-encoding of will never be necessary unless some particular scheme chooses to make it so. Comma and exclamation are therefore perfectly safe in the news and nntp schemes, and any UA that does not accept them at face value is severely broken. I agree that the '?' in wildmats is not especially useful and will not often be used, and so it is no great inconvenience to require it to be %-encoded. Though actually it should be safe left naked, except for the unofficial and undocumented practice you discovered in relation to multiparts. So there is no argument against full s there. > Doing it all in one giant jump doesn't work, look at the mailto-bis I-D, > it tried to throw in IRIs and EAI and making coffee in various scripts. > It's too much. It breaks. RFC 1738 is state of the art 1994. I want > to document state of the art 2005 (when 3986 was published) + Usefor-11. > > It uses the usefor-11 concept of Message-ID, that's a huge step forward, > even in relation to 2822. That's something I care about, because it is > essential for NetNews, unlike those wildmats or article ranges. And that is where you have made one huge mistake. The syntax of in USEFOR is hideous (and you and I were instrumental in making it so); but sadly it is necessary. But that does not mean you have to copy it all into the URI draft (and even less that you only copy part of it, as you have done). There is no need for any implementation of the news scheme to check that syntax. If it is offered some plausible sequence of characters with an "@" in the middle, then you just throw it at the NNTP server and see what comes back. It it is syntactically incorrect, then there will be no article that matches it, and you will be told so. So you can afford to be exceedingly liberal in what you accept and send to the server, just so long as you avoid anything that might be a URI delimiter. Your scheme is supposed to be an interface to RFC 3977, not to USEFOR, and the only syntax you need for is the liberal syntax given in RFC 3977, which is message-id = "<" 1*248A-NOTGT ">" A-NOTGT = %x21-3D / %x3F-7E ; exclude ">" Well, you need to omit that "<" and ">", and you need to enforce an "@" in the middle, and you probably need to enforce %-encoding of a few characters. But that is all. > The idea is to discourage nntp URLs, not to "improve" them. I can see > a point in an XREF to nntp URL transformation on dedicated servers like > GMaNe, and that's documented. I will grant you that the case for adding s to the nntp scheme is much weaker than the case for adding proper wildmats to the news scheme (but then why did you add the "nntp://server.example/comp.lang.c" extension which has no use at all?). And for sure the current use of the nntp scheme in the wild is rare (I do not even own a browser that supports it). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 08 09:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsgr5-00085f-Tf; Fri, 08 Dec 2006 09:37:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsgr4-00085E-Bc for ima@ietf.org; Fri, 08 Dec 2006 09:37:38 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsgr1-0003KJ-QT for ima@ietf.org; Fri, 08 Dec 2006 09:37:38 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew*man#ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 457978a8.1611f.367 for ima@ietf.org; Fri, 8 Dec 2006 14:37:28 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kB8EbQf4017528 for ; Fri, 8 Dec 2006 14:37:27 GMT To: IMA Subject: Re: [EAI] Re: draft-ellermann-news-nntp-uri-04 References: <4575E2F5.6C97@xyzzy.claranet.de> Message-ID: Date: Fri, 08 Dec 2006 14:37:26 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 07 Dec 2006 14:39:20 -0000, Charles Lindsey wrote: > On Tue, 05 Dec 2006 21:21:57 -0000, Frank Ellermann > wrote: > >> Charles Lindsey wrote: > >>> Again, you have a format for a whole group: >> >>> nntp://server.example/comp/lang.c Sorry! This was meant for the URI list. Forget it! -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 08 10:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshm3-0005uA-7u; Fri, 08 Dec 2006 10:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshm2-0005qR-B3 for ima@ietf.org; Fri, 08 Dec 2006 10:36:30 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gshm0-0006oL-Nx for ima@ietf.org; Fri, 08 Dec 2006 10:36:30 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kB8FaJLR012682 for ; Sat, 9 Dec 2006 00:36:19 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kB8FaJFb012681 for ima@ietf.org; Sat, 9 Dec 2006 00:36:19 +0900 Date: Sat, 9 Dec 2006 00:36:19 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061208153618.GB3420@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Dec 06, 2006 at 01:16:44PM -0000, Charles Lindsey wrote: > On Mon, 04 Dec 2006 07:02:05 -0000, Harald Alvestrand > > > >Do you mean "request" (offer advice) or "require" (make the standard > >specify that it has to be that way)? > > Well there is also an intermediate option, which is "recommend" (aka > SHOULD). > > .... > > At the minimum you would say that domains allocating local-parts to their > users SHOULD make them NFC-compatible (or else normalize them on receipt). > > You might also say that MUAs when composing addreseses SHOULD make them > NFC-compatible, but that is likely to be their default behaviour anyway. I also prefer SHOULD to MUST or MAY. If we use "MUST", it would force syntaxes over localparts. > That also accords with the Unicode tradition of "early normalization". Do you have any tech reports (utc) known about this "early normaliation" ? > For sure, all intermediate MTAs should pass on exactly what they receive. You > might argue that if an MUA sees an e+ in a Reply-To, it should reply to > exactly what it sees. If MUA implementation shares the same email address postprocessing routines for replying and composing, their may be no way to "reply to exactly what it sees". I can't imagine MUA architects normalized differently for reply-to sender address and typed/addrbooked recipient addresses. "All or nothing" seems simpler to me. > > Anf finally, if you are making such a rule, then you can choose between > NFC, NFKC, saslprep or some other localprep. Are you suggesting that our draft enumerate those alternatives and recommend them to choose one among them ? Or, should we designate single most preferrable one in our draft ? > > And finally, if it is a SHOULD rather than a MUST, then the script kiddies > can have fun by using non-normalized local-parts by mutual agreement, so > that us adults will have difficulty communicating with them. Yes. it will allow rooms for other normailzation or no normalization. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 11 07:09:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjxQ-00025H-1c; Mon, 11 Dec 2006 07:08:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjxO-00023z-Kq for ima@ietf.org; Mon, 11 Dec 2006 07:08:30 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtjxK-0005Lo-1l for ima@ietf.org; Mon, 11 Dec 2006 07:08:30 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew^man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 457d4a36.2891.207 for ima@ietf.org; Mon, 11 Dec 2006 12:08:22 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBBC8JvP014809 for ; Mon, 11 Dec 2006 12:08:20 GMT To: IMA Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> Message-ID: Date: Mon, 11 Dec 2006 12:08:18 -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: <20061208153618.GB3420@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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, 08 Dec 2006 15:36:19 -0000, Soobok Lee wrote: > On Wed, Dec 06, 2006 at 01:16:44PM -0000, Charles Lindsey wrote: >> At the minimum you would say that domains allocating local-parts to >> their >> users SHOULD make them NFC-compatible (or else normalize them on >> receipt). >> >> You might also say that MUAs when composing addreseses SHOULD make them >> NFC-compatible, but that is likely to be their default behaviour anyway. > > I also prefer SHOULD to MUST or MAY. If we use "MUST", it would force > syntaxes over localparts. Agreed. The main thing is that the receiving domain should choose normalized localparts, and we could usefully say this somewhere. Where? > >> That also accords with the Unicode tradition of "early normalization". > > Do you have any tech reports (utc) known about this "early normaliation" > ? I will let Martin Dürst asnwer that, since he wrote it. Somewhere on the Unicode site IIRC. >> Anf finally, if you are making such a rule, then you can choose between >> NFC, NFKC, saslprep or some other localprep. > > Are you suggesting that our draft enumerate those alternatives and > recommend > them to choose one among them ? Or, should we designate single most > preferrable > one in our draft ? If we are going to write it in somewhere, then that is a matter we would need to discuss. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 11 08:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtlTi-0005s1-5F; Mon, 11 Dec 2006 08:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtlTg-0005ng-OX for ima@ietf.org; Mon, 11 Dec 2006 08:45:56 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtlTe-0003zy-U3 for ima@ietf.org; Mon, 11 Dec 2006 08:45:56 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2219C2596C6; Mon, 11 Dec 2006 14:42:34 +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 23227-07; Mon, 11 Dec 2006 14:42:20 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 093E52596C3; Mon, 11 Dec 2006 14:42:20 +0100 (CET) Message-ID: <457D6103.6060404@alvestrand.no> Date: Mon, 11 Dec 2006 14:45:39 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> 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 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 Gentlemen, while this discussion can certainly be entertaining, it is hardly on the critical path of our working group. The only piece of our charter it could possibly be relevant for is this one: > Additional possible documents suggested: > Advice for MUA implementors (Info) > > And that is something the WG will only get to if it gets the basic specifications nailed. So please - let's concentrate on what IS on our plate now. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 05:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu4zF-0001UO-5S; Tue, 12 Dec 2006 05:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu4zD-0001UC-CU for ima@ietf.org; Tue, 12 Dec 2006 05:35:47 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu4z8-0005am-Rh for ima@ietf.org; Tue, 12 Dec 2006 05:35:47 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew*man#ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 457e85fc.c49a.139 for ima@ietf.org; Tue, 12 Dec 2006 10:35:40 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBCAZcL2020515 for ; Tue, 12 Dec 2006 10:35:39 GMT To: IMA Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> Message-ID: Date: Tue, 12 Dec 2006 10:35:38 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <457D6103.6060404@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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, 11 Dec 2006 13:45:39 -0000, Harald Alvestrand wrote: > while this discussion can certainly be entertaining, it is hardly on the > critical path of our working group. > > The only piece of our charter it could possibly be relevant for is this > one: >> Additional possible documents suggested: >> Advice for MUA implementors (Info) >> I am not so sure of that. We could easily say in utf8headers that s SHOULD be normalized to some level (TBD, but say NFC for now). That would be expressed as a RECOMMENDATION directed at those responsbible for allocating localparts at the recipient's domain (which is the only place, as we have agreed, where any internal structure of localparts can be determined). And the grounds for making that recommendation are that senders' keyboards/MUAs/OSs will have difficulty in generating anything other than NFC-normalized codes, and so will not interoperate without some such restriction. E.e , it is more than mere advice - UTFF8SMTP will not work well without it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 07:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7BN-0006wW-Av; Tue, 12 Dec 2006 07:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7BM-0006wN-1Q for ima@ietf.org; Tue, 12 Dec 2006 07:56:28 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu7BH-0002ys-De for ima@ietf.org; Tue, 12 Dec 2006 07:56:28 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBCCoALR018064; Tue, 12 Dec 2006 21:50:10 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBCCo9Rv018063; Tue, 12 Dec 2006 21:50:09 +0900 Date: Tue, 12 Dec 2006 21:50:09 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061212125009.GB11231@ns5.lsb.org> References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Dec 12, 2006 at 10:35:38AM -0000, Charles Lindsey wrote: > On Mon, 11 Dec 2006 13:45:39 -0000, Harald Alvestrand > wrote: > > > >while this discussion can certainly be entertaining, it is hardly on the > >critical path of our working group. > > > >The only piece of our charter it could possibly be relevant for is this > >one: > >>Additional possible documents suggested: > >>Advice for MUA implementors (Info) > >> > > I am not so sure of that. We could easily say in utf8headers that > s SHOULD be normalized to some level (TBD, but say NFC for Personally I do not oppose that. But, if we say email address SHOULD be NFCed in [uff8header] draft, we should do also in [downgrade][utf8smtp], because [downgrade] use [utf8smtp]-provided recipient email address parameter to upgrade/downgrade To: utf8header. If utf8smtp-provided email addresses are not NFCed, there may be some occasions that utf8header_NFCed_To:_email_address != utf8smtp-envelope-unNFCed-email-address. If this ever causes upgrade/downgrade failure, that may be obviously regarded as *protocol failure*. Again, "All or nothing". > now). That would be expressed as a RECOMMENDATION directed at those > responsbible for allocating localparts at the recipient's domain (which is > the only place, as we have agreed, where any internal structure of > localparts can be determined). > > And the grounds for making that recommendation are that senders' > keyboards/MUAs/OSs will have difficulty in generating anything other than > NFC-normalized codes, and so will not interoperate without some such I am finding some DBMS's primary key restriction, filesystems, language compilers/libraries that assume both NFCed input and NFCed output by default. Soobok > restriction. E.e , it is more than mere advice - UTFF8SMTP will not work > well without it. > > -- > Charles?H.?Lindsey?---------At?Home,?doing?my?own?thing------------------------ > Tel:?+44?161?436?6131? > ???Web:?http://www.cs.man.ac.uk/~chl > Email:?chl@clerew.man.ac.uk??????Snail:?5?Clerewood?Ave,?CHEADLE,?SK8?3JU,?U.K. > PGP:?2C15F1A9??????Fingerprint:?73?6D?C2?51?93?A0?01?E7?65?E8?64?7E?14?A4?AB?A5 > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 10:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9qC-0004vu-Ib; Tue, 12 Dec 2006 10:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9qA-0004uY-Q8 for ima@ietf.org; Tue, 12 Dec 2006 10:46:46 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9q9-0000VM-8U for ima@ietf.org; Tue, 12 Dec 2006 10:46:46 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F91D2596F1; Tue, 12 Dec 2006 16:43:22 +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 02098-04; Tue, 12 Dec 2006 16:43:08 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F5012596F0; Tue, 12 Dec 2006 16:43:08 +0100 (CET) Message-ID: <457ECED4.6040605@alvestrand.no> Date: Tue, 12 Dec 2006 16:46:28 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> In-Reply-To: <20061212125009.GB11231@ns5.lsb.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: d6b246023072368de71562c0ab503126 Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > But, if we say email address SHOULD be NFCed in [uff8header] draft, > we should do also in [downgrade][utf8smtp], because > [downgrade] use [utf8smtp]-provided recipient email address parameter > to upgrade/downgrade To: utf8header. If utf8smtp-provided > email addresses are not NFCed, there may be some occasions that > utf8header_NFCed_To:_email_address != utf8smtp-envelope-unNFCed-email-address. > If this ever causes upgrade/downgrade failure, that may be > obviously regarded as *protocol failure*. Again, "All or nothing". I cannot parse this at all. The envelope MAIL TO email address is completely independent of the header To: address. It is the NORMAL CASE that they are different. (In fact, for all recipients of this message except Soobok, this message will have the two different.) Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 14:12:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuD3K-0006WR-R0; Tue, 12 Dec 2006 14:12:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuD3J-0006WH-Ni for ima@ietf.org; Tue, 12 Dec 2006 14:12:33 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuD3F-0008WE-5l for ima@ietf.org; Tue, 12 Dec 2006 14:12:33 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew&man*ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 457eff1b.b22.3d for ima@ietf.org; Tue, 12 Dec 2006 19:12:27 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBCJCKfJ023692 for ; Tue, 12 Dec 2006 19:12:20 GMT To: IMA Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> Message-ID: Date: Tue, 12 Dec 2006 19:12:19 -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: <457ECED4.6040605@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Tue, 12 Dec 2006 15:46:28 -0000, Harald Alvestrand wrote: > Soobok Lee wrote: >> But, if we say email address SHOULD be NFCed in [uff8header] draft, we >> should do also in [downgrade][utf8smtp], because >> [downgrade] use [utf8smtp]-provided recipient email address parameter >> to upgrade/downgrade To: utf8header. If utf8smtp-provided >> email addresses are not NFCed, there may be some occasions that >> utf8header_NFCed_To:_email_address != >> utf8smtp-envelope-unNFCed-email-address. >> If this ever causes upgrade/downgrade failure, that may be >> obviously regarded as *protocol failure*. Again, "All or nothing". > I cannot parse this at all. OK, I get the general gist of it. Essentially, I suggested that domain-owners/postmasters/whoever gets to choose s SHOULD choose them already normalized (e.g. to NFC). That should cause them to be normalized also in Froms and Reply-Tos in mail originating from that domain, and also in mailtos, Vcards and other means of publicising email addresses. And that in turn should lead to them appearing correctly in To headers, RCPT TO commands, etc (that, plus the tendency of hand typed versions to come out NFC-compliant anyway). I suggested this could be written into utf8headers. I think you and/or Soobok are now saying it should then also be written, or otherwise mentioned, in smtpext. I am not so sure it needs to be said in downgrade. It would also be wise for domain-owners/postmasters/whoever to re-normalize incoming s before attempting to interpret them, and that could also usefully be suggested somewhere. > > The envelope MAIL TO email address is completely independent of the > header To: address. It is the NORMAL CASE that they are different. ITYM RCPT TO :-) . But even RCPT TO is usually constructed out of what the author typed/copied/pasted into the To header in his MUA, so in practice it usually comes to the same thing. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 20:15:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuIiF-0000N6-Px; Tue, 12 Dec 2006 20:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuIiE-0000MF-Ng for ima@ietf.org; Tue, 12 Dec 2006 20:15:10 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuIiD-0005hH-6V for ima@ietf.org; Tue, 12 Dec 2006 20:15:10 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBD1EuLR015186; Wed, 13 Dec 2006 10:14:56 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBD1EuUh015185; Wed, 13 Dec 2006 10:14:56 +0900 Date: Wed, 13 Dec 2006 10:14:56 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061213011456.GA13231@ns5.lsb.org> References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Dec 12, 2006 at 07:12:19PM -0000, Charles Lindsey wrote: > I suggested this could be written into utf8headers. I think you and/or > Soobok are now saying it should then also be written, or otherwise > mentioned, in smtpext. I am not so sure it needs to be said in downgrade. If [utm8smtpext] does NFC, [downgrade] don't need to specify it, as you pointed out, since [utf8smtpext] feed NFC(NON-ASCII) into [downgrade]. So, I agree with you about that. there are two cases: non-ascii addresses are normalized very "early" (right after entered), non-ascii addresses are not normalized until it enters utf8header/smtpsession. In the latter case, utf8header/utf8smtpext both need NFC recommendation, if this WG agree on that. In the former case, we need NFC recommendation in framework document, rather than [utf8header]. > > > >The envelope MAIL TO email address is completely independent of the > >header To: address. It is the NORMAL CASE that they are different. > My previous text was intended narrowly to "downgrade/upgrade" context, so Harald is right generally. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 22:03:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuKOv-00035Y-2B; Tue, 12 Dec 2006 22:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuKOu-00033Z-5k for ima@ietf.org; Tue, 12 Dec 2006 22:03:20 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuKOq-0001zS-Sz for ima@ietf.org; Tue, 12 Dec 2006 22:03:20 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBD332LR002322; Wed, 13 Dec 2006 12:03:02 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBD332Xf002321; Wed, 13 Dec 2006 12:03:02 +0900 Date: Wed, 13 Dec 2006 12:03:02 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061213030302.GB13231@ns5.lsb.org> References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061213011456.GA13231@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.2 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Dec 13, 2006 at 10:14:56AM +0900, Soobok Lee wrote: > > >The envelope MAIL TO email address is completely independent of the > > >header To: address. It is the NORMAL CASE that they are different. > > > > My previous text was intended narrowly to "downgrade/upgrade" context, > so Harald is right generally. I attach [downgrade] appendix that shows how RCPT_TO addresses are used for EAI downgrade. If we assume, RCPT TO: NON-ASCII-TO address is not NFCed, RCPT TO: ALT-ADDRESS EAI-Downgraded-To: To: if NON-ASCII-TO_noNFC != NON-ASCII-TO_NFC in some cases, downgrade/upgrade may be not successful, because the search&convert jobs over the header section may fail. In some inplementations where NON-ASCII-TO addresses are normalized very "early", we need not care about this problem, because the same normalized address will be fed as RCPT_TO parameter. Soobok (attached [downgrade] excerpts) YONEYA & Fujiwara Expires February 17, 2007 [Page 10] Internet-Draft EAI Downgrade Aug 2006 Original EAI message SMTP session MAIL From: ALT-ADDRESS RCPT TO: ALT-ADDRESS RCPT TO: ------------------------------------------------------------- UTF8SMTP: UTF8 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF8-SUBJECT From: To: CC: Date: DATE MAIL_BODY Figure 1: Original EAI message In this example, there are two sessions, one is To:, the other is CC:. The CC: session does not contain ASCII alternative address, it is not downgradable and bounced. The To: session can be downgraded to the next example Figure 2. YONEYA & Fujiwara Expires February 17, 2007 [Page 11] Internet-Draft EAI Downgrade Aug 2006 After SMTP Downgrading MAIL From: RCPT TO: ------------------------------------------------------------- EAI-Downgraded-From: EAI-Downgraded-To: UTF8SMTP: UTF8 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF8-SUBJECT From: To: CC: Date: DATE MAIL_BODY Figure 2: SMTP Downgraded EAI message YONEYA & Fujiwara Expires February 17, 2007 [Page 12] Internet-Draft EAI Downgrade Aug 2006 SMTP Downgrading adds EAI-Downgraded-From: and EAI-Downgraded-To: headers. EAI-Downgraded-From: EAI-Downgraded-To: Figure 4: Headers added by SMTP Downgrading Result of the header conversion downgrading. EAI-Downgraded-From: MIME( EAI-Downgraded-To: MIME( UTF8SMTP: Downgraded Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: MIME(UTF-8_SUBJECT) Downgraded: From: MIME() From: Downgraded: To: MIME() To: Downgraded: CC: MIME() Date: DATE MAIL_BODY Figure 5: Header conversion downgraded message MIME() stands for [RFC2047] encoding. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 22:53:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLB2-0007U7-Cs; Tue, 12 Dec 2006 22:53:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLB0-0007Tz-SD for ima@ietf.org; Tue, 12 Dec 2006 22:53: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 1GuLAz-0007yw-J5 for ima@ietf.org; Tue, 12 Dec 2006 22:53:02 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GuLAu-0009Fp-M5; Tue, 12 Dec 2006 22:52:56 -0500 Date: Tue, 12 Dec 2006 22:52:55 -0500 From: John C Klensin To: Soobok Lee , Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: In-Reply-To: <20061213011456.GA13231@ns5.lsb.org> References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> X-Mailer: Mulberry/4.0.6 (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: 7655788c23eb79e336f5f8ba8bce7906 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 13 December, 2006 10:14 +0900 Soobok Lee wrote: >... > In the latter case, utf8header/utf8smtpext both need NFC > recommendation, if this WG agree on that. In the former case, > we need NFC recommendation in framework document, rather than > [utf8header]. >... For reasons that, I hope, have been explained adequately already, these ideas, however good they may be, cannot be part of the core protocol. They simply need to be recommendations to those who write or configure delivery MTAs and hence don't belong in "framework" and probably not in "utf8headers" or "downgrade" either. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 12 23:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLMI-0004df-0E; Tue, 12 Dec 2006 23:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLMG-0004dU-Ip for ima@ietf.org; Tue, 12 Dec 2006 23:04:40 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuLMF-0002tu-05 for ima@ietf.org; Tue, 12 Dec 2006 23:04:40 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBD446LR012743; Wed, 13 Dec 2006 13:04:06 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBD445xM012742; Wed, 13 Dec 2006 13:04:05 +0900 Date: Wed, 13 Dec 2006 13:04:05 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061213040405.GC13231@ns5.lsb.org> References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Dec 12, 2006 at 10:52:55PM -0500, John C Klensin wrote: > > > --On Wednesday, 13 December, 2006 10:14 +0900 Soobok Lee > wrote: > > >... > > In the latter case, utf8header/utf8smtpext both need NFC > > recommendation, if this WG agree on that. In the former case, > > we need NFC recommendation in framework document, rather than > > [utf8header]. > >... > > For reasons that, I hope, have been explained adequately > already, these ideas, however good they may be, cannot be part > of the core protocol. They simply need to be recommendations to > those who write or configure delivery MTAs and hence don't > belong in "framework" and probably not in "utf8headers" or > "downgrade" either. Still I stand on the same position: normalization is a local matter, as you advised previously. my previous post was under assumption of sweeping-NFC-recommendation. Some sites or implementors may prefer NFKC over NFC for their local needs, for example, fullwidth katakana ->halfwidth one conversion. someone may think NFKC is used already in IDNA and NFKC is also good for localparts etc for consistency reason or for easy implementation. "Let's leave implementors the choice of normalization forms" may be not so bad, i think. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 13 04:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuQ64-0008BC-Gr; Wed, 13 Dec 2006 04:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuQ63-00086X-2u for ima@ietf.org; Wed, 13 Dec 2006 04:08:15 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuQ60-0002QT-Pk for ima@ietf.org; Wed, 13 Dec 2006 04:08:15 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8368C259708 for ; Wed, 13 Dec 2006 10:04:50 +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 01161-08 for ; Wed, 13 Dec 2006 10:04:39 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DAA52596FE for ; Wed, 13 Dec 2006 10:04:39 +0100 (CET) Message-ID: <457FC2F0.2080209@alvestrand.no> Date: Wed, 13 Dec 2006 10:08:00 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) 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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] -framework discussion seems to be finished 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 Since nobody's posted anything about framework-03 here recently, I'm assuming that there's nothing more that needs saying about it. Framework -04 will be posted shortly, and there will be an 1-week pause to allow people the chance to protest before we send the document to the IESG for approval. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 13 07:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuSq7-0003Km-VP; Wed, 13 Dec 2006 07:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuSq5-0003Ke-W7 for ima@ietf.org; Wed, 13 Dec 2006 07:03:57 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuSq1-0001GN-Ei for ima@ietf.org; Wed, 13 Dec 2006 07:03:57 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew^man*ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.238) id 457fec1d.17201.2bd for ima@ietf.org; Wed, 13 Dec 2006 12:03:41 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBDC3ahr010416 for ; Wed, 13 Dec 2006 12:03:37 GMT To: IMA Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> Message-ID: Date: Wed, 13 Dec 2006 12:03: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: <20061213011456.GA13231@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 13 Dec 2006 01:14:56 -0000, Soobok Lee wrote: > On Tue, Dec 12, 2006 at 07:12:19PM -0000, Charles Lindsey wrote: >> I suggested this could be written into utf8headers. ... > there are two cases: > non-ascii addresses are normalized very "early" (right after entered), > > non-ascii addresses are not normalized until it enters > utf8header/smtpsession. > > In the latter case, utf8header/utf8smtpext both need NFC recommendation, > if this WG agree on that. In the former case, we need NFC recommendation > in framework document, rather than [utf8header]. NO! You are making it all too complicated. If it leaves the originating MUA already normalized, then that is a Good Thing. But if, for whatever reason, it doesn't (either in the headers or the envelope), then you should LEAVE IT ALONE all the way through tramsmission, downgrading, or whatever else. Only when it reaches the (apparent) final destination where the gets looked at should anybody be worrying about it. If that site has followed our advice only to allocate normalized (to NFC, NFKC or whatever else) localparts, then that would be a good time for it to normalize whatever has come in before trying to deliver it further. One might then discuss whether it then normalizes the headers as well as the envelope, and whether that is or is not part of any upgrading that may then be done. BUT, if you start normalizing it en route, then you run the risk of breaking any DKIM signatures that may be present, and it is going to be troublesome enough to get DKIM signatures to work with UTF8SMTP without adding extra complications such as that. However (in disagreement with John), I do think that we should specify "localparts SHOULD be chosen by postmasters (whoever) in an already normalized form (to whatever level, but at least NFC, they choose)" and write that into one of our documents, probably utf8headers. But that is all. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 13 10:28:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW1e-0003tm-7y; Wed, 13 Dec 2006 10:28:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW1c-0003t8-Tm for ima@ietf.org; Wed, 13 Dec 2006 10:28:04 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuW1a-0006IO-VQ for ima@ietf.org; Wed, 13 Dec 2006 10:28:04 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBDFRkLR018577; Thu, 14 Dec 2006 00:27:46 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBDFRiBF018576; Thu, 14 Dec 2006 00:27:44 +0900 Date: Thu, 14 Dec 2006 00:27:44 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061213152744.GE13231@ns5.lsb.org> References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Dec 13, 2006 at 12:03:35PM -0000, Charles Lindsey wrote: > On Wed, 13 Dec 2006 01:14:56 -0000, Soobok Lee wrote: > > >On Tue, Dec 12, 2006 at 07:12:19PM -0000, Charles Lindsey wrote: > >>I suggested this could be written into utf8headers. ... > > >there are two cases: > > non-ascii addresses are normalized very "early" (right after entered), > > > > non-ascii addresses are not normalized until it enters > >utf8header/smtpsession. > > > >In the latter case, utf8header/utf8smtpext both need NFC recommendation, > >if this WG agree on that. In the former case, we need NFC recommendation > >in framework document, rather than [utf8header]. > > NO! You are making it all too complicated. If it leaves the originating > MUA already normalized, then that is a Good Thing. But if, for whatever > reason, it doesn't (either in the headers or the envelope), then you > should LEAVE IT ALONE all the way through tramsmission, downgrading, or > whatever else. You are right. I had the same idea with you. What I really intended was "RCPT_TO parameter SHOULD be normalized *before* it enters smtp-session. So, SMTP server SHOULD assume RCPT_Address is already in normalized form in downgrade/upgrade conversion and so the server don't need en route normalization/modification." > Only when it reaches the (apparent) final destination where > the gets looked at should anybody be worrying about it. If > that site has followed our advice only to allocate normalized (to NFC, > NFKC or whatever else) localparts, then that would be a good time for it > to normalize whatever has come in before trying to deliver it further. > > One might then discuss whether it then normalizes the headers as well as > the envelope, and whether that is or is not part of any upgrading that may > then be done. > > BUT, if you start normalizing it en route, then you run the risk of > breaking any DKIM signatures that may be present, and it is going to be > troublesome enough to get DKIM signatures to work with UTF8SMTP without > adding extra complications such as that. > > However (in disagreement with John), I do think that we should specify > "localparts SHOULD be chosen by postmasters (whoever) in an already Localparts( LHS of @ ) are mapped into or compared against local mailbox name for which postmaster/adminstrator have the sole right to create in the normalized form. How to design local mailbox namespace is out-of-protocol issue and had better be put into advice document for administrator/implementor. So do mapping/comparison rules between (localpart) ==> (local mailbox name). For example, while local mailbox name is created in NFC form, the mapping rule can be looser (NFKC or NFKD), like this: " SELECT mailbox from mailbox_tbl where mailbox=NFKD(localpart) or mailbox=NFKC(localpart) ". Such rule had better be put into advice document to allow more freedom to adminstrator/postmasters, i think. > normalized form (to whatever level, but at least NFC, they choose)" and > write that into one of our documents, probably utf8headers. But that is > all. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 13 11:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWyL-0001Gt-Gj; Wed, 13 Dec 2006 11:28:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWyJ-0001Eu-W6 for ima@ietf.org; Wed, 13 Dec 2006 11:28:43 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuWyH-00060g-Cd for ima@ietf.org; Wed, 13 Dec 2006 11:28:43 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBDGSdLR027658 for ; Thu, 14 Dec 2006 01:28:39 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBDGSc7c027656 for ima@ietf.org; Thu, 14 Dec 2006 01:28:38 +0900 Date: Thu, 14 Dec 2006 01:28:38 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20061213162838.GF13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [EAI] SMIME certificate and utf8header normalization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As Charles expressed concerns about "no requirement for header normalization", that prompts me to raise the following SMIME related issue: SMIME signature/encryption use sender/recipient's certificates respectively. Email certificate contains Issuer and Subject field. Subject field's DN contains the email address which should be the same with From: or TO: address in the message header. If MUA's email address is _not_ in NFC/NFKC, SMIME signature/encryption may fail in some cases, due to failure to find the matching email certificate which may be in NFC or in NFKC. The signature verification will succeed always because it is already successfully signed (find the matched certificate successfully). Subject's DN should be unique under the Issuer CA, so the DN's email address also should be unique. To be unique, the EAI email address had better be created in a normalized form. Then, From/To/Cc email addresses should have the same normalization form as future SMIME certificate's normalization. Is this issue is valid ? or already discussed ? Is this issue out of protocol issue and better be put in advice draft ? I read x.509 certificate standard RFC2459 ( http://www.ietf.org/rfc/rfc2459.txt), and DN standard RFC2247 ( http://www.ietf.org/rfc/rfc2247.txt), but I can't find any normalization-related stuff in these RFCes. I have little knowledge about commercial CA's policy on normalization of NON-ASCII DN/email address. They may have no policy yet on EAI email address which is in still in embryo stage. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 13 15:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub4H-0000rO-An; Wed, 13 Dec 2006 15:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub4E-0000ph-NX; Wed, 13 Dec 2006 15:51:06 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gub4E-0002ss-GA; Wed, 13 Dec 2006 15:51:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6E22232848; Wed, 13 Dec 2006 20:51:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gub46-00069c-Ns; Wed, 13 Dec 2006 15:51:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 13 Dec 2006 15:50:58 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-framework-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-framework-04.txt Pages : 23 Date : 2006-12-13 Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-framework-04.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-12-13143042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-13143042.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Wed Dec 13 20:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufPc-0001qX-K6; Wed, 13 Dec 2006 20:29:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufPb-0001ph-P1 for ima@ietf.org; Wed, 13 Dec 2006 20:29:27 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufPW-0006MK-AH for ima@ietf.org; Wed, 13 Dec 2006 20:29:27 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBE1TGLR006334 for ; Thu, 14 Dec 2006 10:29:17 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBE1TG1w006332 for ima@ietf.org; Thu, 14 Dec 2006 10:29:16 +0900 Date: Thu, 14 Dec 2006 10:29:16 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] SMIME certificate and utf8header normalization Message-ID: <20061214012916.GG13231@ns5.lsb.org> References: <20061213162838.GF13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061213162838.GF13231@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org FYI, I followed also RFC2459 -> RFC3280 -> RFC4630 path and RFC2279 for UTF8String cited by RFC4630 & RFC3280. But, I can't find any normalization stuff in these drafts. And RFC3280 says: ====== Housley, et. al. Standards Track [Page 33] RFC 3280 Internet X.509 Public Key Infrastructure April 2002 subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical. When the subjectAltName extension contains an Internet mail address, the address MUST be included as an rfc822Name. The format of an rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has the form "local-part@domain". Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Note that while upper and lower case letters are allowed in an RFC 822 addr-spec, no significance is attached to the case. When the subjectAltName extension contains a iPAddress, the address MUST be stored in the octet string in "network byte order," as specified in RFC 791 [RFC 791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string MUST contain exactly four octets. For IP Version 6, as specified in RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1883]. When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by RFC 1034 [RFC 1034]. Note that while upper and lower case letters are allowed in domain names, no signifigance is attached to the case. In addition, while the string " " is a legal domain name, subjectAltName extensions with a dNSName of " " MUST NOT be used. Finally, the use of the DNS representation for Internet mail addresses (wpolk.nist.gov instead of wpolk@nist.gov) MUST NOT be used; such identities are to be encoded as rfc822Name. Note: work is currently underway to specify domain names in international character sets. Such names will likely not be accommodated by IA5String. Once this work is complete, this profile will be revisited and the appropriate functionality will be added. ====== This means we should have punycode-encoded hostname part for EAI email address for certificate subject DN or subjectAltName unless these paragraph are revised ?? Soobok ----- Conclusion: If RFC3280 is the most recent one, we should encode NON-ASCII@IDN.com as NON-ASCII@xn--****.com. On Thu, Dec 14, 2006 at 01:28:38AM +0900, Soobok Lee wrote: > > As Charles expressed concerns about "no requirement for header normalization", > that prompts me to raise the following SMIME related issue: > > > SMIME signature/encryption use sender/recipient's certificates respectively. > > Email certificate contains Issuer and Subject field. > Subject field's DN contains the email address which > should be the same with From: or TO: address in the message header. > > If MUA's email address is _not_ in NFC/NFKC, > SMIME signature/encryption may fail in some cases, due to failure > to find the matching email certificate which may be in NFC or in NFKC. > The signature verification will succeed always because it is already > successfully signed (find the matched certificate successfully). > > Subject's DN should be unique under the Issuer CA, so the DN's > email address also should be unique. > To be unique, the EAI email address had better be created > in a normalized form. > > Then, From/To/Cc email addresses should have the same normalization form > as future SMIME certificate's normalization. > > > Is this issue is valid ? or already discussed ? > Is this issue out of protocol issue and better be put in advice draft ? > > I read x.509 certificate standard RFC2459 ( http://www.ietf.org/rfc/rfc2459.txt), > and DN standard RFC2247 ( http://www.ietf.org/rfc/rfc2247.txt), > but I can't find any normalization-related stuff in these RFCes. > > I have little knowledge about commercial CA's policy on normalization of > NON-ASCII DN/email address. They may have no policy yet on EAI email address > which is in still in embryo stage. > > Soobok > > _______________________________________________ > 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 Dec 13 22:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guh1T-0000qU-8R; Wed, 13 Dec 2006 22:12:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guh1S-0000qK-4H for ima@ietf.org; Wed, 13 Dec 2006 22:12:38 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guh1Q-0006QV-DP for ima@ietf.org; Wed, 13 Dec 2006 22:12:38 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBE3CWLR023067 for ; Thu, 14 Dec 2006 12:12:32 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBE3CV4h023066 for ima@ietf.org; Thu, 14 Dec 2006 12:12:31 +0900 Date: Thu, 14 Dec 2006 12:12:31 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] SMIME certificate and utf8header normalization Message-ID: <20061214031231.GH13231@ns5.lsb.org> References: <20061213162838.GF13231@ns5.lsb.org> <20061214012916.GG13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061214012916.GG13231@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 my finding is correct (i am not sure of it yet), these paragraphs may be added to some drafts: current x.509 PKI certficate profile (RFC4630,RFC3280) does not allow full UTF8-encoded email addresses in Subject DN and subjectAltName. Further standardization is required in X.509 PKI profile and SMIME. Future x.509 certificate profile is expected to state: o EmailAddress attribute value should be encoded in UTF8String for both local-part and hostname part and and no normalization and casefolding is required for them. o EmailAddress attribute value should be treated by applications in normalization-insensitive and case-insensitive way. So, utf8header now don't need any requirement for normalization especially for future SMIME and x.509 PKI certificate profile, if EAI email address is treated in normalization-insensitive way. By "normalization-insensitive & case-insensitive", I mean A === B if lowercase(NFKC(A))==lowercase(NFKC(B)) OR lowercase(NFKD(A))==lowercase(NFKD(B)). (NFC is included in NFKC). My finding is not yet complete. I welcome any correction. Soobok On Thu, Dec 14, 2006 at 10:29:16AM +0900, Soobok Lee wrote: > > FYI, > I followed also RFC2459 -> RFC3280 -> RFC4630 path and > RFC2279 for UTF8String cited by RFC4630 & RFC3280. > But, I can't find any normalization stuff in these drafts. > > And RFC3280 says: > ====== > Housley, et. al. Standards Track [Page 33] > RFC 3280 Internet X.509 Public Key Infrastructure April 2002 > > subjectAltName extension MUST be present. If the subject field > contains an empty sequence, the subjectAltName extension MUST be > marked critical. > > When the subjectAltName extension contains an Internet mail address, > the address MUST be included as an rfc822Name. The format of an > rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An > addr-spec has the form "local-part@domain". Note that an addr-spec > has no phrase (such as a common name) before it, has no comment (text > surrounded in parentheses) after it, and is not surrounded by "<" and > ">". Note that while upper and lower case letters are allowed in an > RFC 822 addr-spec, no significance is attached to the case. > > When the subjectAltName extension contains a iPAddress, the address > MUST be stored in the octet string in "network byte order," as > specified in RFC 791 [RFC 791]. The least significant bit (LSB) of > each octet is the LSB of the corresponding byte in the network > address. For IP Version 4, as specified in RFC 791, the octet string > MUST contain exactly four octets. For IP Version 6, as specified in > RFC 1883, the octet string MUST contain exactly sixteen octets [RFC > 1883]. > > When the subjectAltName extension contains a domain name system > label, the domain name MUST be stored in the dNSName (an IA5String). > The name MUST be in the "preferred name syntax," as specified by RFC > 1034 [RFC 1034]. Note that while upper and lower case letters are > allowed in domain names, no signifigance is attached to the case. In > addition, while the string " " is a legal domain name, subjectAltName > extensions with a dNSName of " " MUST NOT be used. Finally, the use > of the DNS representation for Internet mail addresses (wpolk.nist.gov > instead of wpolk@nist.gov) MUST NOT be used; such identities are to > be encoded as rfc822Name. > > Note: work is currently underway to specify domain names in > international character sets. Such names will likely not be > accommodated by IA5String. Once this work is complete, this profile > will be revisited and the appropriate functionality will be added. > ====== > This means we should have punycode-encoded hostname part for EAI email > address for certificate subject DN or subjectAltName > unless these paragraph are revised ?? > > Soobok > > ----- > Conclusion: If RFC3280 is the most recent one, > we should encode NON-ASCII@IDN.com as NON-ASCII@xn--****.com. > > > On Thu, Dec 14, 2006 at 01:28:38AM +0900, Soobok Lee wrote: > > > > As Charles expressed concerns about "no requirement for header normalization", > > that prompts me to raise the following SMIME related issue: > > > > > > SMIME signature/encryption use sender/recipient's certificates respectively. > > > > Email certificate contains Issuer and Subject field. > > Subject field's DN contains the email address which > > should be the same with From: or TO: address in the message header. > > > > If MUA's email address is _not_ in NFC/NFKC, > > SMIME signature/encryption may fail in some cases, due to failure > > to find the matching email certificate which may be in NFC or in NFKC. > > The signature verification will succeed always because it is already > > successfully signed (find the matched certificate successfully). > > > > Subject's DN should be unique under the Issuer CA, so the DN's > > email address also should be unique. > > To be unique, the EAI email address had better be created > > in a normalized form. > > > > Then, From/To/Cc email addresses should have the same normalization form > > as future SMIME certificate's normalization. > > > > > > Is this issue is valid ? or already discussed ? > > Is this issue out of protocol issue and better be put in advice draft ? > > > > I read x.509 certificate standard RFC2459 ( http://www.ietf.org/rfc/rfc2459.txt), > > and DN standard RFC2247 ( http://www.ietf.org/rfc/rfc2247.txt), > > but I can't find any normalization-related stuff in these RFCes. > > > > I have little knowledge about commercial CA's policy on normalization of > > NON-ASCII DN/email address. They may have no policy yet on EAI email address > > which is in still in embryo stage. > > > > Soobok > > > > _______________________________________________ > > 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 Thu Dec 14 06:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoNQ-0004k3-Mf; Thu, 14 Dec 2006 06:03:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoNP-0004ij-Hp for ima@ietf.org; Thu, 14 Dec 2006 06:03:47 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoKx-0004Z4-27 for ima@ietf.org; Thu, 14 Dec 2006 06:01:16 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C95A25975A; Thu, 14 Dec 2006 11:57: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 14285-05; Thu, 14 Dec 2006 11:57:47 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA33C259755; Thu, 14 Dec 2006 11:57:46 +0100 (CET) Message-ID: <45812EF4.4020609@alvestrand.no> Date: Thu, 14 Dec 2006 12:01:08 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] SMIME certificate and utf8header normalization References: <20061213162838.GF13231@ns5.lsb.org> <20061214012916.GG13231@ns5.lsb.org> <20061214031231.GH13231@ns5.lsb.org> In-Reply-To: <20061214031231.GH13231@ns5.lsb.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: b19722fc8d3865b147c75ae2495625f2 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 Soobok Lee wrote: > If my finding is correct (i am not sure of it yet), > these paragraphs may be added to some drafts: > > > current x.509 PKI certficate profile (RFC4630,RFC3280) does not > allow full UTF8-encoded email addresses > in Subject DN and subjectAltName. > Further standardization is required in X.509 PKI profile and SMIME. > > Future x.509 certificate profile is expected to state: > o EmailAddress attribute value should be > encoded in UTF8String for both local-part and hostname part and > and no normalization and casefolding is required for them. > o EmailAddress attribute value should be treated by applications > in normalization-insensitive and case-insensitive way. > > > So, utf8header now don't need any requirement for normalization > especially for future SMIME and x.509 PKI certificate profile, > if EAI email address is treated in normalization-insensitive way. > > By "normalization-insensitive & case-insensitive", I mean > A === B if lowercase(NFKC(A))==lowercase(NFKC(B)) OR > lowercase(NFKD(A))==lowercase(NFKD(B)). > (NFC is included in NFKC). > > My finding is not yet complete. I welcome any correction. > Again: S/MIME is not on our current agenda. It is on the list of issues we have to tackle once we have the basic protocol proposals done. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 14 07:18:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GupWv-0003Bw-16; Thu, 14 Dec 2006 07:17:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GupWt-0003Br-LR for ima@ietf.org; Thu, 14 Dec 2006 07:17:39 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GupWn-0008Mh-1k for ima@ietf.org; Thu, 14 Dec 2006 07:17:39 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3&clerew^man^ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 458140d9.14e2e.284 for ima@ietf.org; Thu, 14 Dec 2006 12:17:29 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBECHRRW026177 for ; Thu, 14 Dec 2006 12:17:28 GMT To: IMA Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] References: <20061208153618.GB3420@ns5.lsb.org> <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> <20061213152744.GE13231@ns5.lsb.org> Message-ID: Date: Thu, 14 Dec 2006 12:17:25 -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: <20061213152744.GE13231@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 13 Dec 2006 15:27:44 -0000, Soobok Lee wrote: > You are right. I had the same idea with you. > recommendation> > What I really intended was "RCPT_TO parameter SHOULD be > normalized *before* it enters smtp-session. So, SMTP server SHOULD > assume RCPT_Address is already in normalized form in downgrade/upgrade > conversion and so the server don't need en route > normalization/modification." > Not quite. Change "SHOULD" to "should" and I would agree with you. I.e. it may be good practice, but should not be necessary for correct operation. The only place where I want to see SHOULD is in regard to the practices of domain owners and their postmasters. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 14 07:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gupdn-0006Bk-Vz; Thu, 14 Dec 2006 07:24:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gupdn-0006Be-LN for ima@ietf.org; Thu, 14 Dec 2006 07:24:47 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gupdm-0001Jt-27 for ima@ietf.org; Thu, 14 Dec 2006 07:24:47 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew#man$ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 4581428d.ba66.a for ima@ietf.org; Thu, 14 Dec 2006 12:24:45 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBECOhiS026689 for ; Thu, 14 Dec 2006 12:24:43 GMT To: IMA Subject: Re: [EAI] SMIME certificate and utf8header normalization References: <20061213162838.GF13231@ns5.lsb.org> Message-ID: Date: Thu, 14 Dec 2006 12:24:42 -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: <20061213162838.GF13231@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 13 Dec 2006 16:28:38 -0000, Soobok Lee wrote: > As Charles expressed concerns about "no requirement for header > normalization", > that prompts me to raise the following SMIME related issue: > > > SMIME signature/encryption use sender/recipient's certificates > respectively. > > Email certificate contains Issuer and Subject field. > Subject field's DN contains the email address which > should be the same with From: or TO: address in the message header. > Yes, this is just another example, on top of mailtos and Vcards that I have already mentioned, where mail addresses may appear and be publicised. And maybe at a later stage we have to produce documents about them. But what these all have in common is that they are usually generated by the owners of the domains (or their postmasters, or their users), and are therefore under their control, So if the domain has established some policy regarding normalization of their s (as I think they SHOULD), then any certificates, mailtos, Vcards, etc that they generate will naturally be in that normalized form. In which case everything will work fine and there is no need for us to worry about it at this stage. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 14 08:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqUh-0001c5-G4; Thu, 14 Dec 2006 08:19:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqUg-0001bz-AZ for ima@ietf.org; Thu, 14 Dec 2006 08:19:26 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuqUe-0000eU-Pa for ima@ietf.org; Thu, 14 Dec 2006 08:19:26 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id kBEDJFLR024172; Thu, 14 Dec 2006 22:19:15 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id kBEDJEwp024171; Thu, 14 Dec 2006 22:19:14 +0900 Date: Thu, 14 Dec 2006 22:19:14 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] Message-ID: <20061214131914.GJ13231@ns5.lsb.org> References: <457D6103.6060404@alvestrand.no> <20061212125009.GB11231@ns5.lsb.org> <457ECED4.6040605@alvestrand.no> <20061213011456.GA13231@ns5.lsb.org> <20061213152744.GE13231@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Dec 14, 2006 at 12:17:25PM -0000, Charles Lindsey wrote: > On Wed, 13 Dec 2006 15:27:44 -0000, Soobok Lee wrote: > > >You are right. I had the same idea with you. > > >recommendation> > >What I really intended was "RCPT_TO parameter SHOULD be > >normalized *before* it enters smtp-session. So, SMTP server SHOULD > >assume RCPT_Address is already in normalized form in downgrade/upgrade > >conversion and so the server don't need en route > >normalization/modification." > > > > Not quite. Change "SHOULD" to "should" and I would agree with you. I.e. it > may be good practice, but should not be necessary for correct operation. > The only place where I want to see SHOULD is in regard to the practices of > domain owners and their postmasters. I agree with you. This recommendation may be put into the guideline document section for postmasters. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 14 11:16:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutG3-00044d-V3; Thu, 14 Dec 2006 11:16:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutEi-0003bT-Ic for ima@ietf.org; Thu, 14 Dec 2006 11:15:08 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GutDr-0004Ov-Kn for ima@ietf.org; Thu, 14 Dec 2006 11:14:16 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA60D25975F; Thu, 14 Dec 2006 17:10: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 22521-01; Thu, 14 Dec 2006 17:10:38 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51ED125975E; Thu, 14 Dec 2006 17:10:38 +0100 (CET) Message-ID: <45817848.3020805@alvestrand.no> Date: Thu, 14 Dec 2006 17:14:00 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [EAI] -framework discussion seems to be finished References: <457FC2F0.2080209@alvestrand.no> In-Reply-To: <457FC2F0.2080209@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 -04 was posted, with a date on my disk of December 13, 20:30 CET (European time). One week from then is December 20, 20:30 CET. If no show-stopper issues have been found by then, we'll send it to the IESG for Last Call and approval. Harald Harald Alvestrand wrote: > Since nobody's posted anything about framework-03 here recently, I'm > assuming that there's nothing more that needs saying about it. > > Framework -04 will be posted shortly, and there will be an 1-week > pause to allow people the chance to protest before we send the > document to the IESG for approval. > > 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 Fri Dec 15 08:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvD2Y-0006dt-EA; Fri, 15 Dec 2006 08:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvD2W-0006dn-Tu for ima@ietf.org; Fri, 15 Dec 2006 08:23:52 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvD2V-0003Ca-5E for ima@ietf.org; Fri, 15 Dec 2006 08:23:52 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew^man*ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 4582a1e2.151e0.5e for ima@ietf.org; Fri, 15 Dec 2006 13:23:46 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBFDNhPb010150 for ; Fri, 15 Dec 2006 13:23:44 GMT To: IMA Subject: Re: [EAI] -framework discussion seems to be finished References: <457FC2F0.2080209@alvestrand.no> <45817848.3020805@alvestrand.no> Message-ID: Date: Fri, 15 Dec 2006 13:23:43 -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: <45817848.3020805@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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, 14 Dec 2006 16:14:00 -0000, Harald Alvestrand wrote: > -04 was posted, with a date on my disk of December 13, 20:30 CET > (European time). > > One week from then is December 20, 20:30 CET. If no show-stopper issues > have been found by then, we'll send it to the IESG for Last Call and > approval. My view is (as you might expect) that it should be regarded as complete, but left in a frozen state until we are nearer completion with our other documents. The protocols described in those are still far from complete, and may yet bring up some issue which might require some revision of the framework. I do not see what is gained by having the framework on its own as a published RFC. Its main use now is a a guide for us in working out the details in the other documents. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 20 23:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxFsV-0007Rf-LS; Wed, 20 Dec 2006 23:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxFsU-0007RZ-Ml for ima@ietf.org; Wed, 20 Dec 2006 23:49:58 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxFsS-0000cD-2P for ima@ietf.org; Wed, 20 Dec 2006 23:49:58 -0500 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id kBL4nrAa017190 for ; Thu, 21 Dec 2006 12:49:54 +0800 Message-ID: <458A154A.4090707@twnic.net.tw> Date: Thu, 21 Dec 2006 13:02:02 +0800 From: Jeff Yeh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [EAI] Status of utf8header draft 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 Hi all: While I'm trying to update the header draft, there comes some issues (solved/un-solved). Listed below: * Removing the "Header-Type" header (was UTF8SMTP) The basic idea to have a "Header-Type" new header is for identifying a email is EAI or non-EAI. And the new header could also carry some useful information like downgrade information/language tag. However, this kind of self-labeling mechanism was found useless as the history of "MIME-Version" header. For the robustness of email software, programmers usually ignore the "MIME-Version" header, directly check the presents of MIME headers and the MIME encoded stuff. This is also happened in TWNIC's implementation on EAI testbed, "Header-Type" header is ignored, we check the presents of UTF8 instead. Thus, the demand of the "Header-Type" is being raise up again. Although we already have consensus about this point on San Diego meeting, it's still necessary to bring on the mailing list for everyone's opinion. --harald offers choices: a) leave UTF8SMTP header field in:one vote b) take it out: 10 votes c) mime-version 2.0: none d) can't decide: 5 votes --harald: will take proposal to list to take it out * The alt-addr syntax There is a roughly consensus on >, but still some concern on parser updating effort. By TWNIC's EAI implementation experience, working just fine with a little bit change on parser. Though there is a possible conflict to domain-literal, but the use of domain-literal is quite few, I think. * Trace Field Solved, will update in the upcoming version. "Received" must put in ASCII, "for" could ignore (optional). "Return-Path" syntax need to update to allow UTF8 characters. * UTF8 in MIME headers (RFC 2231) Should be allowed. Will update in the upcoming version. Did I miss anything related to utf8header draft? Regards, Jeff Yeh -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 21 01:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxHp4-0001l7-PG; Thu, 21 Dec 2006 01:54:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxHp3-0001l2-MJ for ima@ietf.org; Thu, 21 Dec 2006 01:54:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxHp0-00012Y-3J for ima@ietf.org; Thu, 21 Dec 2006 01:54:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GxHor-00006S-R1 for ima@ietf.org; Thu, 21 Dec 2006 07:54:21 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 07:54:21 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 07:54:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Status of utf8header draft Date: 21 Dec 2006 08:54:14 +0200 Lines: 75 Message-ID: <5dr6utzqll.fsf@leija.fmi.fi> References: <458A154A.4090707@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Jeff Yeh writes in gmane.ietf.ima: > Hi all: > > While I'm trying to update the header draft, there comes some issues > (solved/un-solved). Listed below: > > * Removing the "Header-Type" header (was UTF8SMTP) > The basic idea to have a "Header-Type" new header is for identifying a > email is EAI or non-EAI. And the new header could also carry some > useful information like downgrade information/language tag. However, > this kind of self-labeling mechanism was found useless as the history > of "MIME-Version" header. For the robustness of email software, > programmers usually ignore the "MIME-Version" header, directly check > the presents of MIME headers and the MIME encoded stuff. This is also > happened in TWNIC's implementation on EAI testbed, "Header-Type" > header is ignored, we check the presents of UTF8 instead. Thus, the > demand of the "Header-Type" is being raise up again. > Although we already have consensus about this point on San Diego > meeting, it's still necessary to bring on the mailing list for > everyone's opinion. > > --harald offers choices: > a) leave UTF8SMTP header field in:one vote > b) take it out: 10 votes > c) mime-version 2.0: none > d) can't decide: 5 votes > --harald: will take proposal to list to take it out > Leaving out Header-Type is OK, if - correspond new parameter is added to ESMTP (ie. HEADER=UTF8SMTP compare with BODY=8BITMIME ) - message/rfc822 is labeled or some other type is used - something may required for parameters, which was added to Header-Type -header field 'This messages is downgraded UTF8SMTP message' can not be added as ESMTP parameter. It can only be on some header field (new ESMTP parameter requires that UTF8SMTP is supported and if it is, then downgrading is not required.) Perhaps then is needed Downgrade-Type: none (message is not downgraded (*)) and Downgrade-Type: utf8smtp (message is downgraded from UTF8SMTP) with parameters ? (*) Downgrade-Type: none do not indicate that message is UTF8SMTP message. > * Trace Field > Solved, will update in the upcoming version. > "Received" must put in ASCII, "for" could ignore > (optional). "Return-Path" syntax need to update to allow UTF8 > characters. OK. > * UTF8 in MIME headers (RFC 2231) > Should be allowed. Will update in the upcoming version. OK. > Did I miss anything related to utf8header draft? > > Regards, > > Jeff Yeh > -TWNIC / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 21 12:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRvk-0007kl-Jw; Thu, 21 Dec 2006 12:42:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRvi-0007kV-LP for ima@ietf.org; Thu, 21 Dec 2006 12:42:06 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRvc-0001mV-P7 for ima@ietf.org; Thu, 21 Dec 2006 12:42:06 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew^man*ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 458ac764.11df2.9 for ima@ietf.org; Thu, 21 Dec 2006 17:41:56 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBLHfskM010965 for ; Thu, 21 Dec 2006 17:41:56 GMT Date: Thu, 21 Dec 2006 17:41:53 -0000 To: IMA Subject: Re: [EAI] Status of utf8header draft References: <458A154A.4090707@twnic.net.tw> 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: In-Reply-To: <458A154A.4090707@twnic.net.tw> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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, 21 Dec 2006 05:02:02 -0000, Jeff Yeh wrote: > * Removing the "Header-Type" header (was UTF8SMTP) > The basic idea to have a "Header-Type" new header is for identifying a > email is EAI or non-EAI. And the new header could also carry some useful > information like downgrade information/language tag. However, this kind > of self-labeling mechanism was found useless as the history of > "MIME-Version" header. For the robustness of email software, programmers > usually ignore the "MIME-Version" header, directly check the presents of > MIME headers and the MIME encoded stuff. This is also happened in > TWNIC's implementation on EAI testbed, "Header-Type" header is ignored, > we check the presents of UTF8 instead. Thus, the demand of the > "Header-Type" is being raise up again. > Although we already have consensus about this point on San Diego > meeting, it's still necessary to bring on the mailing list for > everyone's opinion. > > --harald offers choices: > a) leave UTF8SMTP header field in:one vote > b) take it out: 10 votes > c) mime-version 2.0: none > d) can't decide: 5 votes > --harald: will take proposal to list to take it out > How is it that a small subset if this list (those that have funding and/or time to travel to IETF meetings) can make "decisions" at those meetings, of which the rest are not informed until months afterwards? That is a most unsatisf\ctory way of proceeding. AFAIAC, the Header-Type header field is VITAL, for the following reasons: 1. It is the only way to tell that a message is UTF8SMTP in the case where the transport mechanism is _not_ SMTP (a situation which the draft now claims to allow). 2. Even when the transport mechanism _is_ SMTP, you cannot tell in the case where all the addresses are in pure ASCII; there could still be Subject and other headers with UTF8 in them, and there could be embedded MIME objects with UTF8 in their headers (e.g. message/rfc822 or filenames in Content-Disposition). It would need an SMTP parameter such as BODY-UTF8SMTP to indicate that. 3. Once a message has passed "final delivery" (whatever that is), the SMTP information is no longer available, but you may still need to know whether it is a UTF8SMTP message. Even if IMAP and POP3 contrive to keep this information somehow, they are not the only storage mechanisms in use; for example, good ol' mbox format is still around, and has no other way to store that information. 4. You NEED that information before you can gateway the message to some other medium (gatewaying is always dificult in the general case, and the other medium may or may not require some downgrade, and even if it doesn't it may need to know so that it in turn can gateway it on to something else). 5. You NEED that information before you can Resend the message (or maybe even forward it, or encapsulate it as a message/rfc822 within something else). 6. Your MUA may NEED that information before it can display it (e.g. does it need to upgrade it first?), or else you NEED it in order to determine whether it requires to be downgraded before submission to the MUA, or even whether it needs to be upgraded first. 7. You NEED that information if the message has been DKIM-Signed, so you can either upgrade it before checking the signature, or else report "Sorry! This signature cannot be verified because of downgrading". Note that there is a feature in DKIM whereby you can say, in the signature, "here is how such-and-such a header was at the point where it was signed". You might use that feature to record the original From, etc, but more importantly if you used it on the Header-Type (which itself MUST NOT be included in the signed hash, because it can change en route) then you could detect that the Header-Type was "UTF8" when it was signed but it now shows as "downgraded", and so you know exactly where you stand. OK, there may still be lots of problems with DKIM-Signatures on UTF8SMTP messages, and we will need to look at them later on; but in the meantime let us not do anything that would make those propblems worse. > * The alt-addr syntax > There is a roughly consensus on >, but still some concern > on parser updating effort. By TWNIC's EAI implementation experience, > working just fine with a little bit change on parser. > Though there is a possible conflict to domain-literal, but the use of > domain-literal is quite few, I think. I could live with either, but marginally prefer >. But if someone can show that one or the other is technically more difficult (and I don't think we have seen that yet), then that would settle the matter. > > * Trace Field > Solved, will update in the upcoming version. > "Received" must put in ASCII, "for" could ignore (optional). > "Return-Path" syntax need to update to allow UTF8 characters. 2 issues there, I think: 1. You can't have UTF8 in the "for", so you may have to omit the "for" in those cases. 2. What about comments? Either you allow UTF8 in them (as we do in comments in other headers) and accept downgrading of those cases, or you write explicitly that comments in References header fields MUST be in ASCII (which still allows RFC 2047 encoded-words if you really need them). > > * UTF8 in MIME headers (RFC 2231) > Should be allowed. Will update in the upcoming version. > The 02 draft seems more or less OK on this. > Did I miss anything related to utf8header draft? BUG in (section 6.3) ---------------------------------- An MUST be pure ASCII. Yes? Currently, you have alt-address = [CFWS] "[" addr-spec "]" [CFWS] where addr-spec = local-part "@" domain domain is OK (it uses the old dot-atom and old domain-literal) but local-part = dot-atom / quoted-string / obs-local-part and quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] where qcontent = qtext / quoted-pair quoted-pair = ("\" text) / obs-qp BUT you have changed both and to allow UTF-8 :-( . Unravelling that is going to be tedious, but here goes: 1. Rename your and your as follows: utf8-qtext = NO-WS-CTL / ; all of except %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 / ; or the quote character UTF8-xtra-char utf8-text = %d1-9 / ; all UTF-8 characters except %d11-12 / ; US-ASCII NUL, CR and LF %d14-127 / UTF8-xtra-char 2. Invent utf8-quoted-pair and utf8-qcontent etc.: utf8-quoted-pair = ("\" utf8-text) / obs-qp utf8-qcontent = utf8-qtext / utf8-quoted-pair utf8-quoted-string = [CFWS] DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE [CFWS] utf8-ccontent = ctext / utf8-quoted-pair / comment 3. Find all the places where is used, and see which version is now needed: comment = "(" *([FWS] utf8-ccontent) [FWS] ")" word = utf8-atom / utf8-quoted-string utf8-local-part = utf8-dot-atom / utf8-quoted-string / obs-local-part Observe that I also fixed another bug there, because you had not allowed a in a and other such places. Message-ID ---------- I thought we had always agreed this should remain in ASCII (to allow UTF8 there might cause all sorts of problems in Netnews unless it were VERY heavily normalized). There is some slight mention of this in 6.2, but not strong enough. Also a reference to 6.4 there which I do not understand, since does not occur in Received fields, or does it? And, in any case, shouldn't it be rather than ? However, my revised syntax above has magically fixed this problem, since was based on , and . So all you now need is a remark such as: Observe that none of this revised syntax affects what is allowed in a , which will still remain in pure ASCII. s ------------------ Soobok and I have been pressing for something about normalization here. So I would like to suggest, somewhere in 6,3: "Although the syntax allows unfettered use of s in s, it should be realized that many combinations of such characters (notably those not properly normalized according to the appropriate Unicode Normalization Forms [http://www.unicode.org/reports/tr15/] will be almost impossible to enter using typical keyboard and MUA software. Moreover, accurate conveyance of such sequences by means of handwriting or the spoken word is hardly possible. Therefore, those responsible for allocating s for use in domains where UTF8SMTP mail addresses are to be recognized SHOULD choose them in forms that are normalized at least to level NFC, and preferebly NFKC, and they MAY arrange that s in incoming emails are correspondingly normalized before attempting to interpret them further." Message/rfc822 -------------- We discussed this, but never came to any firm conclusion. What I would like to see, somewhere in 7.2, is: "The media type "message/rfc822", as defined in [RFC 2046] is extended to allow all messages defined by this document. However, objects conforming to that extended media type MUST NOT be used except within UTF8SMTP messages, as defined in this document, and thus they will need to be downgraded [downgrade document] (or bounced/rejected) whenever the parent message is downgraded. {And then our {downgrade document] needs to pick this up and to say that this needs to be done Other niggles ------------- I think Frank Ellerman has already reported most of the typos in the present draft, so I will just mention the paragraph mentioning "required fields" in section 5. I don't understand this at all. I think you are trying to say that the only s (syntax of ) defined by this document is the that you give, but I cannot really deduce that from the paragraph as written, since the term "required fields" is nowhere defined. So what is it really all about? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 21 13:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSPk-00015k-Dc; Thu, 21 Dec 2006 13:13:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSPj-00015c-VO for ima@ietf.org; Thu, 21 Dec 2006 13:13:07 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxSPg-0006rh-7N for ima@ietf.org; Thu, 21 Dec 2006 13:13:07 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GxSPL-0000WH-RU for ima@ietf.org; Thu, 21 Dec 2006 19:12:44 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 19:12:43 +0100 Received: from hurtta+ietf by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 19:12:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Status of utf8header draft Date: 21 Dec 2006 20:12:18 +0200 Lines: 150 Message-ID: <5dlkl1azjx.fsf@Hurtta06k.keh.iki.fi> References: <458A154A.4090707@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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" writes in gmane.ietf.ima: > Other niggles > ------------- > > I think Frank Ellerman has already reported most of the typos in the > present draft, so I will just mention the paragraph mentioning > "required fields" in section 5. I don't understand this at all. I > think you are trying to say that the only s (syntax of > ) defined by this document is the > that you give, but I cannot really deduce > that from the paragraph as written, since the term "required fields" > is nowhere defined. So what is it really all about? What was my suggestion. In short draft-ietf-eai-downgrade was meant to say that if it removes any header field mentioned on "required fields", downgrading fails. / Kari Hurtta -------------------------------------------------------------------- From: Kari Hurtta Subject: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion Newsgroups: gmane.ietf.ima Cc: Kari Hurtta Date: Sat, 14 Oct 2006 14:48:07 +0300 (EEST) draft-ietf-eai-utf8headers-01.txt: header-content = "UTF8SMTP:" [FWS] content-code [FWS] *( ";" parameter ) CRLF content-code = "UTF8" / "ASCII" / "Downgraded" parameter = "Header-Language:" [FWS] Language-List Language-List = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) following was suggested: header-content = "Header-Type:" [FWS] content-code [FWS] *( ";" parameter ) CRLF ; parameter is defined on RFC 2045 content-code = "UTF8SMTP" / "ASCII" / "Downgraded" The "header-language" parameter is defined for "Header-Type" header-field. Value of "header-language" parameter is defined as following (after possible quotation of quoted-string is decode): header-language-value = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) I also suggest following (almost same was also suggested): The "required-fields" parameter is defined for "Header-Type" header-field. Value of "required-fields" parameter is defined as following (after possible quotation of quoted-string is decode): required-fields-value = field-name [FWS] *("," [FWS] field-name [FWS]) ; field-name is defined on RFC 2822 draft-ietf-eai-downgrade-02.txt: Downgrading: * Check if the mail has 'UTF8SMTP' header and its value is "UTF8". Otherwise, downgrading is not required. * Check each header whether it contains UTF-8 characters or not. If the header contains UTF-8 characters, + If the header is an address header which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header. - Downgrade the header defined in Section 5.1.1. + The other header case, encode the header by [RFC2047] with UTF-8 tag. * Change 'UTF8SMTP' header value to "Downgraded". Suggested changes: Downgrading: * Check if the mail has 'Header-Type' header field and its value is "UTF8SMTP". Otherwise, downgrading is not required. * Check each header field whether it contains UTF-8 characters or not. If the header field contains UTF-8 characters, + If the header field is an address header field which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header field. - Downgrade the header field defined in Section 5.1.1. + Otherwise if syntax of header field is known: - Encode header elements according of [RFC2047] and [RFC2231] - If encoding is not possible, preserve the header in 'Downgraded' header field and remove original header field. - If syntax of header field is not known - Preserve the header in 'Downgraded' header field and remove original header field. * If some header field was removed, which is mentioned on "required-fields" parameter on 'Header-Type' header field, downgrading fails. * Change 'Header-Type' header field value to "Downgraded". NOTE: Address header downgrading in Section 5.1.1 may also remove header field. If that header field is mentioned on "required-fields" parameter on 'Header-Type' header field, downgrading fails. draft-ietf-eai-downgrade-02.txt: Upgrading: * Check if the mail has 'UTF8SMTP' header and its value is "Downgraded". Otherwise, upgrading is not required. * Decode all 'Downgraded' headers. + Decode header value field string which is [RFC2047] encoded. + If the header is address header described in Section 5.1.1, - Apply address header downgrading to the decoded header. - Remove the header line which is the same with the downgraded line. + Remove the 'Downgraded' header. + Add decoded header to mail header. * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. * Change 'UTF8SMTP' header value to "UTF8". Suggested changes: * Check if the mail has 'Header-Type' header field and its value is "Downgraded". Otherwise, upgrading is not required. + Decode header value field string which is [RFC2047] encoded. + If the header is address header field described in Section 5.1.1, - Apply address header field downgrading to the decoded header. - Remove the header field line which is the same with the downgraded line. + Remove the 'Downgraded' header field. + Add decoded header to mail header field. * For every mail header field, which syntax is known + If each mail header field has [RFC2047] or [RFC2231] encoded part and which encoding is "UTF-8", it is a downgraded header field, so decode it. * Change 'Header-Type' header value to "UTF8SMTP". / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 04:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxgTH-0002e1-Ad; Fri, 22 Dec 2006 04:13:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxgTF-0002dv-Sk for ima@ietf.org; Fri, 22 Dec 2006 04:13:41 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxgTE-0007Gi-D0 for ima@ietf.org; Fri, 22 Dec 2006 04:13:41 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6CE91259708; Fri, 22 Dec 2006 10:10:11 +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 23777-10; Fri, 22 Dec 2006 10:10:06 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B6FA259706; Fri, 22 Dec 2006 10:10:06 +0100 (CET) Message-ID: <458BA1BE.2010700@alvestrand.no> Date: Fri, 22 Dec 2006 10:13:34 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] Status of utf8header draft References: <458A154A.4090707@twnic.net.tw> 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: 8b30eb7682a596edff707698f4a80f7d Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Thu, 21 Dec 2006 05:02:02 -0000, Jeff Yeh wrote: > > >> * Removing the "Header-Type" header (was UTF8SMTP) >> The basic idea to have a "Header-Type" new header is for identifying >> a email is EAI or non-EAI. And the new header could also carry some >> useful information like downgrade information/language tag. However, >> this kind of self-labeling mechanism was found useless as the history >> of "MIME-Version" header. For the robustness of email software, >> programmers usually ignore the "MIME-Version" header, directly check >> the presents of MIME headers and the MIME encoded stuff. This is also >> happened in TWNIC's implementation on EAI testbed, "Header-Type" >> header is ignored, we check the presents of UTF8 instead. Thus, the >> demand of the "Header-Type" is being raise up again. >> Although we already have consensus about this point on San Diego >> meeting, it's still necessary to bring on the mailing list for >> everyone's opinion. >> >> --harald offers choices: >> a) leave UTF8SMTP header field in:one vote >> b) take it out: 10 votes >> c) mime-version 2.0: none >> d) can't decide: 5 votes >> --harald: will take proposal to list to take it out >> > > How is it that a small subset if this list (those that have funding > and/or time to travel to IETF meetings) can make "decisions" at those > meetings, of which the rest are not informed until months afterwards? > That is a most unsatisf\ctory way of proceeding. It's been exactly 6 weeks and one day from the WG meeting to today, but yes, the chairs have been remiss in getting the minutes posted and reviewed. My apologies. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 04:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxgoa-0005rK-BH; Fri, 22 Dec 2006 04:35:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxgoY-0005rD-9P for ima@ietf.org; Fri, 22 Dec 2006 04:35:42 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxgoX-00026l-9i for ima@ietf.org; Fri, 22 Dec 2006 04:35:42 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 96711259708 for ; Fri, 22 Dec 2006 10:32:12 +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 24767-05 for ; Fri, 22 Dec 2006 10:32:05 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 781D8259707 for ; Fri, 22 Dec 2006 10:32:05 +0100 (CET) Message-ID: <458BA6E5.4010001@alvestrand.no> Date: Fri, 22 Dec 2006 10:35:33 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Subject: [EAI] Meeting minutes from the San Diego IETF meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Here are the minutes as posted to the IETF website: http://www3.ietf.org/proceedings/06nov/minutes/eai.txt We will attempt to get corrections uploaded if needed, even though the official minutes deadline is already well passed. Again, the chairs' apology for our lack of timeliness. Harald, for the chairs Minutes for IETF EAI WG Meeting in San Diego @ IETF67 TIME: 13:00 to 1500, Nov.9, 2006 VENUE: Room Spinnaker, Sheraton San Diego Hotel & Marina Items of Minutes : A.Agenda Bashing B.Status of Work C.Framework D.SMTP extensions E.Header draft F.Downgrade document G.End-system docs H.Other docs I.Key Points Summary A.Agenda Bashing --No tutorial materials in this meeting, only to discuss the open issues;= --No modification on agenda. --Harald makes the presentation on the status of EAI WG and issues list=20 of every WG draft. B.Status of Work --Framework has finished the WG Last Call; --SMTP Ext., UTF8 Header, and Downgrade draft are in discussion; --Supporting documents drafted. IMAP, POP, Mailing List draft. And DSN=20 draft is coming soon, encapsulation and mailto drafts exist; --Implementation tests have started. (CDNC test the EAI solution) C.Framework --Show the issues list, and assumption the silent ones agree or find it=20 acceptable, based on the mailing list discussion; --Setup the issue tracker: https://rt.psg.com; user/passwork: ietf/ietf; --Issues list: #1387 1.3 - i18mail user clarification: Editorial, accepted #1388 -3 - Missing MIME considerations: Note that -headers needs to=20 address MIME issues #1389 4.1 - term "bounce" vs "reject": Remove term "bounce". Exact=20 term to use debated. #1390 4.1 - "POP": Editorial, accepted #1391 5 - delivery to final delivery MTA: Being wordsmithed #1392 6 - delete i18n section: Accepted #1393 7 - missing local part abuses as label: Resolution not clear;=20 non-EAI issues involved #1394 10 - too long security section: Wordsmithing, but no changes #1395 13 - nits: Editorial, accepted #1396 7.1 - title change IRI -> URI: Accepted #1397 10 - UTF-8: Resolution not clear, still open --Editor will make changes based on the existing mailing list=20 discussion,and do version 03 rev; --Chair will issue WG Last Call on those fixed; --There are no new issues; --If necessary, version 04 will be issued and passed to IESG for approval= =2E D.SMTP extensions --Resolved issue is that identifier is UTF8SMTP; --The open issue is that DSN extension should be a new document? --Chris Newman: we have extensions that add parameters to SMTP MAIL FROM = and RCPT TO, should the UTF8SMTP draft look at published extensions and=20 loosen syntax to permit UTF-8 in _some_ parameters? in particular: AUTH=20 parameter on MAIL FROM=EF=BF=BD=EF=BF=BD any other issues on UTF8SMTP? Alexey: I will be revising SMTP AUTH soon, so I can try to address UTF-8 = in the AUTH parameter --chris: ORCPT is the other big one, but that's being addressed in DSN re= v Alexey: it might be better to do it in the EAI document, so as not to=20 introduce a dependency on EAI into SMTP AUTH. --Chris: why EAI needs DSN? Since EAI will be experimental, not stds. --draft standard DSN RFCs are 7bit only, original UTF-8 rcpt address=20 important to preserve on bounce for end-user correlation, as we have=20 more address translation in system, preserving them in bounces important --technical issues:use new 'utf-8' address type and URI-style %encoding=20 on downgrade; message/delivery-status --> messages (note that ORCPT=20 value is xtext, so kind of double-encoding would occur).=20 message/delivery-status --> message/utf-8-delivery-status, other option=20 to use message/delivery-status; charset=3Dutf-8 but that hard to use in=20 many architectures for content return: message/rfc822 vs message/utf-8 --leaning towards message/utf-8 due to interaction with IMAP=20 BODYSTRUCTURE interaction, if any unextended IMAP server hit a=20 message/rfc822 with UTF-8 addresses, the returned BODYSTRUCTURE would=20 probably give IMAP clients trouble --need localized & i-default error text --- end-user sees DSNs, needs comprehensible reason string --pguenther: how to know which language to return? --chris: Alexey's draft has LANG command for session and a LANG=20 parameterfor MAIL command for the transaction --Ted: this could have come up before EAI. Why didn't it? Chris: there has been SMTP LANG extensions floating around for years, as = a server vendor, have had requests for this, primarily from Japanese=20 customers E.Header draft --resolved issues: a)marker on messages: "UTF8SMTP: UTF8" header field,=20 "UTF8SMTP: downgrade" for downgraded messages, b)I18mail address=20 *always*has angle brackets --open issues:a)alt-address representation, b) UTF-8 in MIME headers. --JohnK: when 1123 added sans leading phrase, some MUAs=20 used a trick to parse these, that trick will blow up on the proposed=20 alt-addr representation --chris: propose we take a hum on using the proposed rep --resnick>: Can someone give me a quick explanation of why we want a=20 UTF8SMTP header? --ted: wonky headers inserted by virus checkers. Are there people in the = room or on the list who know or are involved --pete: explicit marker. Redundant, but useful. --resnick: tells you whether it is utf8 or has been downgraded, if so,=20 could they check whether they already use the proposed syntax or do=20 something with them, can tell you if it started ascii-as Harald said,=20 complete to have such, though no use case springs to mind, It's=20 redundant, but thatmeans it might disagree with reality. --randy: worried by syntax --harald: takes hum for support of the syntax --room in favor, to be taken to list --johnk: another proposal for the marker header: use MIME-Version: 2.0 --pete: worried about why we have this header --johnk: we've been here this before, so why not be here before with the = old one --chris: will anyone actually implement this as other than MUST=20 generate,MUST ignore? --harald: does anyone have a *use* for this marker? does anyone recall=20 why that header was added? --randy: useful strictly for debugging --tony: optimization for UTF8 case? --don't have to scan everything --pguenther: new received: via type? Received: via UTF8SMTP ? --randy: likes it --johnk: like it too --harald: so, change SMTP doc to register UTF8SMTP via type? --ted: but this was inserted by MUA? --randy: not a problem, because MUA uses UTF8SMTP to submit --alexey: recall that chris registered ESMTPA/ESMTPS/ESMTPSA/... via type= s --harald offers choices: a) leave UTF8SMTP header field in:one vote b) take it out: 10 votes c) mime-version 2.0: none d) can't decide: 5 votes --harald: will take proposal to list to take it out --next open issue: UTF-8 in MIME headers --chris: we have real mess with filenames in mime headers=20 (content-disposition), would be real good if we deprecated the existing=20 coding methods and replaced them with unencoded UTF-8 --pete: non-controversial to say we want that, but what's the downgrade? = deprecate 2231 and use 2047? --chris: yep --pete: worried about _us_ (EAI WG) deprecating 2231 --William Leibzon: what about other MIME using groups? --Kazunori Fujiwara: makes downgrade much harder; have to walk MIME=20 structure, go to 2231 --allow in mime-version: 2.0 ? --straw poll: most people don't know whether we should do this --straw poll #2: 2231 vs 2047 vs don't know? Answer: don't know --alexeymelnikov: Excuse my ignorance: Is UTF8SMTP header field is the=20 same as Header-Type in draft-ietf-eai-utf8headers-02.txt? --johnk: or we could jsut drop the filename parameter when it contains=20 non-ASCII F.Downgrade document --Resolved issues: conversion is used , not encapsulation: target is=20 ASCII mail users. --open issues: - downgrade: header fields for storage of prev-converted data - representation of utf8 address after conversiom? - bounce vs leave out when addresses in header donm't have alt-address= - headling of 2047/2231 in header when already present - MIME body part headers --chris: should be selective about data for which we preserve the=20 pre-conversion form, thinks we should preserve original addresses and=20 leave out everything else, don't need to preserve which header had the=20 utf8 form. we need to preserve the mapping of ut8-address to=20 ascii-address, i.e., don't need to record that a given utf8 address=20 appeared in the 'to' header but just that a given ascii address was the=20 alt of particular utf8 address --pete: worried when stuff it isn't perfectly reversible --alexey: +1 on Pete's concern --pete: only stuff we can't downconvert are addresses, so, use 2047/2231 = for others and downgrade header for addresses only --william: prefer encapsulation --harald: rejected by list. DKIM is problem; so don't go there?=20 consensuson keeping address original forms but not other headers. --Pete Resnick: DKIM is just like any signing/encrypting situation: The=20 only choice is to encapsulate and you won't be able to verify anything=20 outside of the encapsulation. That means DKIM can't verify at the server = level. Bummer, but that's what you get. downgrade everything at gateway=20 before signing...? --harald: what to do with header address w/o alt-address? drop address=20 orbounce? --johnk: uncomfortable with anything but bounce less so with leaving a=20 comment --barry: how is this different from messages to N people where M bounce? --johnk: change to header --daveC: this is effort to enhance mail system, not replace it, right?=20 Dropping addresses/headers seems like crossing of fine-line into having=20 twoemail systems that are being gatewayed --pete: really think deleting headers is Wrong Thing. Violation of=20 envelope/header separation? --randy: agrees with john+pete. bouncing important during upgrade, so=20 that people know how to fix things --barry: sender doesn't care or screwed up, or address _has_ no equiv;=20 noway to reply, loss is a given; sender didn't provide alternate, would=20 still prefer to deliver -- Is there any precedence case of header deletion in the specs? --Yao: prefer bounce; alternative sends useless message --barry: bouncing may put sender in odd situation where they may need to = pull address and resend, no? --ned freed: deja vu all over again, downgrading in the 8bit mime case=20 similar bouncing is problematic: blowback spam (aka joe jobs) confidence = inanti-spam required? --randy: do we really have another choice? proposals for better bounces=20 exist, deleting header or address is worst case, cause neither end sees=20 the change --ned: so annotate the removal in the message --Yao: bouncing lets sender improve the situation; retry with ascii=20 address, etc --Ted: "learning experience for the user" is _not_ a good thing very=20 expensive, very rare that people will have control of stuff in the=20 middle, oreven be aware of it. suggest that WG make it task to find a=20 third solution. --randy: DSN extensions provide tools for recognizing bounces, tie DSN=20 support into UTF8SMTP support? --chris: the model for email is that envelope is transport, header is=20 "commentary", not related to transport is bouncing based on content a=20 violation of the model? given address books, bouncing based on headers=20 may makeit impossible to send a message to mixed EAI and non-EAI users --william: bounce is best of bad choices so far; drafts for each=20 alternative? --harald: strong opinion in room that dropping header is bad --pete: dropping includes downgrade header? --harald: doesn't matter, strong against either way -- So long as you get the Downgraded header, I think deleting=20 the original and not bouncing is fine with me. --harald: bouncing has problems --harald: G.End-system docs --POP3: no open issues --IMAP: waiting on IMAP ENABLE draft --IMAP waiting on downgrade and DSN --mailing lists: randy taking on this draft --Cyrus: Contributing a draft on a "UTF8 IMAP". --has open issues, randy given free rein for now H.Other docs --forward as attachment in scope? --encapsulation: needed for DSN content return; adopt as WG doc? --pete: +1 --mailto: URI --wait until core set published? --scenarios doc: polish and publish? --ted: volunteers for action item, but needs help: lots of other IETF=20 stuff thinks it knows what an email address looks like --johnk: clarification on the instructions to him: what should he do for = items that are "resolution uncertain" --harald: make sure you're happy with the resolutions that exist; john=20 tomove as expediently as reasonable --doug Otis: problems with munging of downgraded but not --johnk: read drafts I.Key Points Summary -- Verison 04 of Framework draft will be passed to IESG -- Chris will take the DSN draft. -- randy taking on mailing list draft _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 04:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxgom-0005ug-Nm; Fri, 22 Dec 2006 04:35:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxgol-0005tS-Gk for ima@ietf.org; Fri, 22 Dec 2006 04:35:55 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxgok-00028E-6x for ima@ietf.org; Fri, 22 Dec 2006 04:35:55 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DF74259708 for ; Fri, 22 Dec 2006 10:32:25 +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 24809-04 for ; Fri, 22 Dec 2006 10:32:20 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACEF9259707 for ; Fri, 22 Dec 2006 10:32:20 +0100 (CET) Message-ID: <458BA6F4.2070204@alvestrand.no> Date: Fri, 22 Dec 2006 10:35:48 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) 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: b19722fc8d3865b147c75ae2495625f2 Subject: [EAI] Key decisions from San Diego 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 Extracted from the minutes: - No new issues have been identified on - framework. Will go to IESG after WG Last Call. - Randy Gellens will write a new version of the mailing list draft - Chris Newman will write a new draft on DSN extensions for UTF8SMTP. - A strong leaning of the room towards removing the UTF8SMTP field from the headers, but enough people said "can't decide" that we need a list discussion of this issue - The WG meeting was unable to decide on what to do with UTF-8 in headers on MIME body parts. The alternatives were: - Do not allow it (probably unacceptable, especially for filename parameter) - Allow it, and downgrade to 2047 outside quotes and 2231 inside quotes - Allow it, and downgrade to 2047 both outside and inside quotes List discussion needed. - The WG meeting decided that dropping a To: or Cc: header that has an UTF8SMTP address without an alt-address is not acceptable, and neither is bouncing such a message. Alternatives for encoding the content of the header were discussed, but none were selected. I think that's the key resolutions. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 06:31:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxick-00024P-Td; Fri, 22 Dec 2006 06:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxick-00024J-1E for ima@ietf.org; Fri, 22 Dec 2006 06:31:38 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxich-0002lj-KF for ima@ietf.org; Fri, 22 Dec 2006 06:31:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GxicT-0007LS-Rw for ima@ietf.org; Fri, 22 Dec 2006 12:31:21 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Dec 2006 12:31:21 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Dec 2006 12:31:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: UTF-8 on MIME headers (Re: [EAI] Key decisions from San Diego) Date: 22 Dec 2006 13:31:12 +0200 Lines: 20 Message-ID: <5d8xh09ngf.fsf@leija.fmi.fi> References: <458BA6F4.2070204@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) 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 Harald Alvestrand writes in gmane.ietf.ima: > - The WG meeting was unable to decide on what to do with UTF-8 in > headers on MIME body parts. The alternatives were: > - Do not allow it (probably unacceptable, especially for filename > parameter) > - Allow it, and downgrade to 2047 outside quotes and 2231 inside quotes > - Allow it, and downgrade to 2047 both outside and inside quotes > List discussion needed. Uhh. RFC 2047 is valid here only on comments ie. inside of ( ) Therefore only comments can be RFC 2047 encoded. Mime parameter values can be RFC 2231 encoded. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 07:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxj7A-00013E-HD; Fri, 22 Dec 2006 07:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxj79-000130-Lm for ima@ietf.org; Fri, 22 Dec 2006 07:03:03 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxj77-0000Cv-7l for ima@ietf.org; Fri, 22 Dec 2006 07:03:03 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gxj6w-0002At-LE for ima@ietf.org; Fri, 22 Dec 2006 13:02:50 +0100 Received: from d252196.dialin.hansenet.de ([80.171.252.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Dec 2006 13:02:50 +0100 Received: from nobody by d252196.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Dec 2006 13:02:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Meeting minutes from the San Diego IETF meeting Date: Fri, 22 Dec 2006 12:57:11 +0100 Organization: Lines: 46 Message-ID: <458BC817.74E1@xyzzy.claranet.de> References: <458BA6E5.4010001@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252196.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: Random comments: > --pguenther: new received: via type? Received: via UTF8SMTP ? > --randy: likes it > --johnk: like it too > --harald: so, change SMTP doc to register UTF8SMTP via type? > --ted: but this was inserted by MUA? > --randy: not a problem, because MUA uses UTF8SMTP to submit > --alexey: recall that chris registered ESMTPA/ESMTPS/ESMTPSA/... via types A complete set is UTF8SMTP, UTF8SMTPA, UTF8SMTPS, UTF8SMTPSA. What about the LMTP set, does anybody care, or can we lump that together ? Maybe using USMTP[S][A], where "US" stands for either "ES" plus UTF-8, or "L" plus UTF-8. > --pete: worried about _us_ (EAI WG) deprecating 2231 IFF it's done (2231 isn't completely bad) please do it fast, some 2231 considerations in USEFOR could be still trimmed. > --barry: sender doesn't care or screwed up, or address _has_ > no equiv; noway to reply, loss is a given; sender didn't > provide alternate, would still prefer to deliver Strong NAK, "prefer to deliver" is a wrong decision, "prefer to reject" MUST be the first choice. 80% of mail is spam, we don't need wannabe-improved UTF-8 one-way spam to achieve 95%. > --ned freed: deja vu all over again, downgrading in the 8bit > mime case similar bouncing is problematic: blowback spam (aka > joe jobs) confidence inanti-spam required? SMTP without SPF (or something better covering the RMX idea) is FUBAR since the day when RFC 1123 5.3.6(a) was published. With "reject at the MX" legit senders get at least a fighting chance. > --harald: bouncing has problems > --harald: 4408 is the only game in town, not counting the pre-1123 SMTP. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 09:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxlo4-00086a-Ob; Fri, 22 Dec 2006 09:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxlo3-000855-NW for ima@ietf.org; Fri, 22 Dec 2006 09:55:31 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxlo2-0004IC-4q for ima@ietf.org; Fri, 22 Dec 2006 09:55:31 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew^man$ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 458bf1e0.c10.56 for ima@ietf.org; Fri, 22 Dec 2006 14:55:28 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBMEtPAj011684 for ; Fri, 22 Dec 2006 14:55:27 GMT To: IMA Subject: Re: [EAI] Status of utf8header draft References: <458A154A.4090707@twnic.net.tw> <5dlkl1azjx.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Fri, 22 Dec 2006 14:55:24 -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: <5dlkl1azjx.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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, 21 Dec 2006 18:12:18 -0000, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: > >> Other niggles >> ------------- >> >> I think Frank Ellerman has already reported most of the typos in the >> present draft, so I will just mention the paragraph mentioning >> "required fields" in section 5. I don't understand this at all. I >> think you are trying to say that the only s (syntax of >> ) defined by this document is the >> that you give, but I cannot really deduce >> that from the paragraph as written, since the term "required fields" >> is nowhere defined. So what is it really all about? > > What was my suggestion. In short draft-ietf-eai-downgrade was meant > to say that if it removes any header field mentioned on "required > fields", > downgrading fails. Ah! I understand now. Just needs a little more explanation in utf8headers, then. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 22 10:06:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxlyY-0004Ps-U7; Fri, 22 Dec 2006 10:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxlyX-0004NQ-QQ for ima@ietf.org; Fri, 22 Dec 2006 10:06:21 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxlyW-00065M-8b for ima@ietf.org; Fri, 22 Dec 2006 10:06:21 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3$clerew&man^ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 458bf46b.7b22.128 for ima@ietf.org; Fri, 22 Dec 2006 15:06:19 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kBMF6HOA012348 for ; Fri, 22 Dec 2006 15:06:18 GMT To: IMA Subject: Re: [EAI] Key decisions from San Diego References: <458BA6F4.2070204@alvestrand.no> Message-ID: Date: Fri, 22 Dec 2006 15:06:16 -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: <458BA6F4.2070204@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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, 22 Dec 2006 09:35:48 -0000, Harald Alvestrand wrote: > Extracted from the minutes: > > - No new issues have been identified on - framework. Will go to IESG > after WG Last Call. > > - Randy Gellens will write a new version of the mailing list draft > > - Chris Newman will write a new draft on DSN extensions for UTF8SMTP. > > - A strong leaning of the room towards removing the UTF8SMTP field from > the headers, but enough people said "can't decide" that we need a list > discussion of this issue OK, I have given reasons why that is a Bad Thing. > > - The WG meeting was unable to decide on what to do with UTF-8 in > headers on MIME body parts. The alternatives were: > - Do not allow it (probably unacceptable, especially for filename > parameter) > - Allow it, and downgrade to 2047 outside quotes and 2231 inside quotes > - Allow it, and downgrade to 2047 both outside and inside quotes > List discussion needed. I think it HAS to be 2231. It is a mess, and nobody likes it, but it is the proposed standard on the matter. Let us not invent any new encoding schemes. And for message that begin and end in UTF8SMTP, the question will never arise. For the odd case that goes through downgrading, the 'filename' (which is only advisory) will not get interpreted, or it will be interpreted as some garbage and the filename created with that garbage name. The sky will not fall in either way. > > - The WG meeting decided that dropping a To: or Cc: header that has an > UTF8SMTP address without an alt-address is not acceptable, and neither > is bouncing such a message. Alternatives for encoding the content of the > header were discussed, but none were selected. I think the _essential_ feature is that a Downgraded header is created, so that the original is not lost. Given that, I don't care if the headers carried forward contain just '<>', or even if they are deleted. An 'upgrade' program can probably restore them, and if not a human can do it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 28 02:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzphk-0003Ho-Ap; Thu, 28 Dec 2006 02:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzphj-0003Gf-8L for ima@ietf.org; Thu, 28 Dec 2006 02:29:31 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzphe-0005Qy-Fh for ima@ietf.org; Thu, 28 Dec 2006 02:29:31 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kBS7TN0p029166 for ; Thu, 28 Dec 2006 16:29:23 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7eb6_23913fbc_9645_11db_8f1f_0014221f2a2d; Thu, 28 Dec 2006 16:29:23 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60551) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Dec 2006 16:28:38 +0900 Message-Id: <6.0.0.20.2.20061228130549.0749a5c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Dec 2006 13:09:16 +0900 To: "Charles Lindsey" , IMA From: Martin Duerst Subject: Re: [EAI] localprep and pop3 with saslprep username authetication] In-Reply-To: References: <20061208153618.GB3420@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 21:08 06/12/11, Charles Lindsey wrote: >On Fri, 08 Dec 2006 15:36:19 -0000, Soobok Lee wrote: > >> On Wed, Dec 06, 2006 at 01:16:44PM -0000, Charles Lindsey wrote: >>> That also accords with the Unicode tradition of "early normalization". >> >> Do you have any tech reports (utc) known about this "early normaliation" >> ? > >I will let Martin Duerst asnwer that, since he wrote it. Somewhere on the >Unicode site IIRC. No, at W3C: Requirements for String Identity Matching and String Indexing, http://www.w3.org/TR/WD-charreq, in particular http://www.w3.org/TR/WD-charreq#3. It's almost the oldest Working Draft still under development at W3C (see just above http://www.w3.org/TR/#WD-stop). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 28 02:35:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzpno-0005FM-3b; Thu, 28 Dec 2006 02:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzpnm-0005FH-Vh for ima@ietf.org; Thu, 28 Dec 2006 02:35:46 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzpnl-0006uK-Cj for ima@ietf.org; Thu, 28 Dec 2006 02:35:46 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kBS7ZiQ8029990 for ; Thu, 28 Dec 2006 16:35:44 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 6db6_06cc5c4e_9646_11db_87f6_0014221fa3c9; Thu, 28 Dec 2006 16:35:43 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49529) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 Dec 2006 16:34:59 +0900 Message-Id: <6.0.0.20.2.20061228131351.07498650@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 28 Dec 2006 16:35:35 +0900 To: ima@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Masato Nakajima Subject: [EAI] comments on draft-ietf-eai-smtpext-02 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 These are some comments on draft-ietf-eai-smtpext-02 based on questions from my student with whom I'm currently working on an implementation. If these have already been made, please ignore. 1) The draft doesn't say what syntax it is using to describe the syntax. I guess this is ABNF, but this should be made explicit, with a reference (RFC 4234). 2) In section 2.4, literal characters and nonterminals are not clearly separated. As an example, I'd expect the first rule to read something like "MAIL FROM:" SP reverse-path [ SP Mail-parameters ] CRLF If some other formalism is used, this should be clearly documented, but I hope everybody agrees that ABNF is the way to go. Btw, one of my guesses is that the addition of "<" and ">" in some of the rules is due to the fact that RFC 4234 uses these quite a bit in the text (although only in very special cases, such as for variables denoting integers, in the examples). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 28 03:07:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzqIo-0005C5-D1; Thu, 28 Dec 2006 03:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzqIm-0005C0-O9 for ima@ietf.org; Thu, 28 Dec 2006 03:07:48 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzqIj-0003AR-Dd for ima@ietf.org; Thu, 28 Dec 2006 03:07:48 -0500 Received: (eyou send program); Thu, 28 Dec 2006 16:07:27 +0800 Message-ID: <367293247.30999@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Thu, 28 Dec 2006 16:07:27 +0800 Message-ID: <02b901c72a57$3b91ca00$1206e29f@cnnicyao> From: "Yao Jiankang" To: , "Martin Duerst" References: <367291351.19283@cnnic.cn> Subject: Re: [EAI] comments on draft-ietf-eai-smtpext-02 Date: Thu, 28 Dec 2006 16:07:35 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Masato Nakajima 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="===============1951958486==" Errors-To: ima-bounces@ietf.org --===============1951958486== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcnRpbiBEdWVyc3QiIDxk dWVyc3RAaXQuYW95YW1hLmFjLmpwPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpDYzogIk1hc2F0byBO YWthamltYSIgPGE1ODAzMDYwQGNjLmFveWFtYS5hYy5qcD4NClNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciAyOCwgMjAwNiAzOjM1IFBNDQpTdWJqZWN0OiBbRUFJXSBjb21tZW50cyBvbiBkcmFmdC1p ZXRmLWVhaS1zbXRwZXh0LTAyDQoNCg0KPiBUaGVzZSBhcmUgc29tZSBjb21tZW50cyBvbiBkcmFm dC1pZXRmLWVhaS1zbXRwZXh0LTAyIGJhc2VkDQo+IG9uIHF1ZXN0aW9ucyBmcm9tIG15IHN0dWRl bnQgd2l0aCB3aG9tIEknbSBjdXJyZW50bHkgd29ya2luZw0KPiBvbiBhbiBpbXBsZW1lbnRhdGlv bi4gSWYgdGhlc2UgaGF2ZSBhbHJlYWR5IGJlZW4gbWFkZSwgcGxlYXNlDQo+IGlnbm9yZS4NCj4g DQo+IDEpIFRoZSBkcmFmdCBkb2Vzbid0IHNheSB3aGF0IHN5bnRheCBpdCBpcyB1c2luZyB0byBk ZXNjcmliZQ0KPiAgIHRoZSBzeW50YXguIEkgZ3Vlc3MgdGhpcyBpcyBBQk5GLCBidXQgdGhpcyBz aG91bGQgYmUgbWFkZQ0KPiAgIGV4cGxpY2l0LCB3aXRoIGEgcmVmZXJlbmNlIChSRkMgNDIzNCku DQoNCmluIHNlY3Rpb24gMi4zLCAgdGhlcmUgaXMgYWxyZWFkeSBhIHJlZmVyZW5jZSB0byBSRkM0 MjM0ICgiQWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBhYm92ZSwgZGVmaW5lIHRoZSBzeW50 YXggb2YgYW4NCiAgIGludGVybmF0aW9uYWxpemVkIGVtYWlsIG1haWxib3ggd2l0aCBBQk5GIFtS RkM0MjM0XSBhcyIpDQoNCnBscyBjaGVjayBpdCBpbiBzbXRwZXh0IGRyYWZ0Lg0KDQoNCg0KPiAy KSBJbiBzZWN0aW9uIDIuNCwgbGl0ZXJhbCBjaGFyYWN0ZXJzIGFuZCBub250ZXJtaW5hbHMgYXJl DQo+ICAgbm90IGNsZWFybHkgc2VwYXJhdGVkLiBBcyBhbiBleGFtcGxlLCBJJ2QgZXhwZWN0IHRo ZQ0KPiAgIGZpcnN0IHJ1bGUgdG8gcmVhZCBzb21ldGhpbmcgbGlrZQ0KPiANCj4gICAiTUFJTCBG Uk9NOiIgU1AgcmV2ZXJzZS1wYXRoIFsgU1AgTWFpbC1wYXJhbWV0ZXJzIF0gQ1JMRg0KPiANCj4g SWYgc29tZSBvdGhlciBmb3JtYWxpc20gaXMgdXNlZCwgdGhpcyBzaG91bGQgYmUgY2xlYXJseQ0K PiBkb2N1bWVudGVkLCBidXQgSSBob3BlIGV2ZXJ5Ym9keSBhZ3JlZXMgdGhhdCBBQk5GIGlzIHRo ZQ0KPiB3YXkgdG8gZ28uDQoNCmFjdHVhbGx5LCB0aGUgbWFpbiBzbXRwIGV4dGVuc2lvbiBzeW50 YXggaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMuMw0KcmZjMjgyMS4geW91IG1heSBjaGVjayB0aGVy ZSBmb3IgZGV0YWlscy4NCg0KdGhhbmtzDQoNCllhbyBKaWFua2FuZw0KQ05OSUMNCj4gDQo+IEJ0 dywgb25lIG9mIG15IGd1ZXNzZXMgaXMgdGhhdCB0aGUgYWRkaXRpb24gb2YgIjwiIGFuZCAiPiIN Cj4gaW4gc29tZSBvZiB0aGUgcnVsZXMgaXMgZHVlIHRvIHRoZSBmYWN0IHRoYXQgUkZDIDQyMzQg dXNlcw0KPiB0aGVzZSBxdWl0ZSBhIGJpdCBpbiB0aGUgdGV4dCAoYWx0aG91Z2ggb25seSBpbiB2 ZXJ5DQo+IHNwZWNpYWwgY2FzZXMsIHN1Y2ggYXMgZm9yIHZhcmlhYmxlcyBkZW5vdGluZyBpbnRl Z2VycywNCj4gaW4gdGhlIGV4YW1wbGVzKS4NCj4gDQo+IFJlZ2FyZHMsICAgICBNYXJ0aW4uDQo+ IA0KPiANCj4gDQo+ICMtIy0jICBNYXJ0aW4gSi4gRHUicnN0LCBBc3NvYy4gUHJvZmVzc29yLCBB b3lhbWEgR2FrdWluIFVuaXZlcnNpdHkNCj4gIy0jLSMgIGh0dHA6Ly93d3cuc3cuaXQuYW95YW1h LmFjLmpwICAgICAgbWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMuanAgICAgDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1h aWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaW1h --===============1951958486== 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 --===============1951958486==-- From ima-bounces@ietf.org Thu Dec 28 12:00:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzybn-0000tN-Lj; Thu, 28 Dec 2006 11:59:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzybm-0000sT-4s for ima@ietf.org; Thu, 28 Dec 2006 11:59: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 1Gzybj-0000N1-MW for ima@ietf.org; Thu, 28 Dec 2006 11:59:58 -0500 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1Gzybd-000Dgo-5r; Thu, 28 Dec 2006 11:59:49 -0500 Date: Thu, 28 Dec 2006 11:59:48 -0500 From: John C Klensin To: Yao Jiankang , Martin Duerst Subject: Re: [EAI] comments on draft-ietf-eai-smtpext-02 Message-ID: In-Reply-To: <367293247.30999@cnnic.cn>, <02b901c72a57$3b91ca00$1206e29f@cnnicyao> References: <367291351.19283@cnnic.cn> <367293247.30999@cnnic.cn>, <02b901c72a57$3b91ca00$1206e29f@cnnicyao> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Masato Nakajima , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yao, While I agree that it should not be strictly necessary given the references you have cited, it seems to me that Martin's suggestions would help to improve clarity. regards, john --On Thursday, December 28, 2006 4:07 PM +0800 Yao Jiankang wrote: > > ----- Original Message ----- > From: "Martin Duerst" > To: > Cc: "Masato Nakajima" > Sent: Thursday, December 28, 2006 3:35 PM > Subject: [EAI] comments on draft-ietf-eai-smtpext-02 > > >> These are some comments on draft-ietf-eai-smtpext-02 based >> on questions from my student with whom I'm currently working >> on an implementation. If these have already been made, please >> ignore. >> >> 1) The draft doesn't say what syntax it is using to describe >> the syntax. I guess this is ABNF, but this should be made >> explicit, with a reference (RFC 4234). > > in section 2.3, there is already a reference to RFC4234 > ("According to the description above, define the syntax of an > internationalized email mailbox with ABNF [RFC4234] as") > > pls check it in smtpext draft. > > > >> 2) In section 2.4, literal characters and nonterminals are >> not clearly separated. As an example, I'd expect the >> first rule to read something like >> >> "MAIL FROM:" SP reverse-path [ SP Mail-parameters ] CRLF >> >> If some other formalism is used, this should be clearly >> documented, but I hope everybody agrees that ABNF is the >> way to go. > > actually, the main smtp extension syntax is defined in section > 3.3 rfc2821. you may check there for details. > > thanks > > Yao Jiankang > CNNIC >> >> Btw, one of my guesses is that the addition of "<" and ">" >> in some of the rules is due to the fact that RFC 4234 uses >> these quite a bit in the text (although only in very >> special cases, such as for variables denoting integers, >> in the examples). >> >> Regards, Martin. >> >> >> >> # -#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin >> # University -#-# http://www.sw.it.aoyama.ac.jp >> # mailto:duerst@it.aoyama.ac.jp >> >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima