From ima-bounces@ietf.org Tue Oct 04 08:46:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmBM-0000g6-Lg; Tue, 04 Oct 2005 08:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmBJ-0000fq-UI for ima@megatron.ietf.org; Tue, 04 Oct 2005 08:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15607 for ; Tue, 4 Oct 2005 08:46:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMmK0-0007rE-Gx for ima@ietf.org; Tue, 04 Oct 2005 08:55:04 -0400 Received: from root by megatron.ietf.org with local (Exim 4.32) id 1EMmBA-0000a2-IP for ima@ietf.org; Tue, 04 Oct 2005 08:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMjLY-0002W5-Hx for ima@megatron.ietf.org; Tue, 04 Oct 2005 05:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07025 for ; Tue, 4 Oct 2005 05:44:23 -0400 (EDT) Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EMjU4-00039t-1U for ima@ietf.org; Tue, 04 Oct 2005 05:53:22 -0400 Received: (eyou send program); Tue, 04 Oct 2005 17:43:48 +0800 Message-ID: <328419028.17427@cnnic.cn> Received: from 61.48.11.134 by mail.cnnic.cn with HTTP; Tue, 04 Oct 2005 17:43:48 +0800 X-WebMAIL-MUA: [61.48.11.134] From: "Yao Jiankang" To: ima@ietf.org Date: Tue, 04 Oct 2005 17:43:48 +0800 X-Priority: 3 Content-Type: text/plain X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [IMA] new draft for IMA is available now X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yao Jiankang List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Dear all, please see below http://www.ietf.org/internet-drafts/draft-yao-ima-smtpext-00.txt Yao Jiankang CNNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 09 08:36:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOaPp-0004nC-RA; Sun, 09 Oct 2005 08:36:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOaPp-0004n4-2m for ima@megatron.ietf.org; Sun, 09 Oct 2005 08:36:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14185 for ; Sun, 9 Oct 2005 08:36:31 -0400 (EDT) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EOaZQ-0002QO-Bt for ima@ietf.org; Sun, 09 Oct 2005 08:46:34 -0400 Received: (eyou send program); Sun, 09 Oct 2005 20:36:02 +0800 Message-ID: <328861362.24910@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Sun, 09 Oct 2005 20:36:02 +0800 Message-ID: <00ea01c5ccce$25bd7630$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: Date: Sun, 9 Oct 2005 20:37:01 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [IMA] Fw: I-D ACTION:draft-klensin-ima-framework-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2077960050==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============2077960050== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 bmV3IGRyYWZ0IGFib3V0IElNQSBpcyBhdmFpbGFibGUgDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtsZW5zaW4taW1hLWZyYW1ld29yay0wMC50eHQNCg0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPEludGVybmV0LURyYWZ0c0BpZXRm Lm9yZz4NClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgT2N0b2Jl ciAwNCwgMjAwNSAzOjUwIEFNDQpTdWJqZWN0OiBJLUQgQUNUSU9OOmRyYWZ0LWtsZW5zaW4taW1h LWZyYW1ld29yay0wMC50eHQgDQoNCg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IA0KPiAN Cj4gVGl0bGUgOiBPdmVydmlldyBhbmQgRnJhbWV3b3JrIGZvciBJbnRlcm5hdGlvbmFsaXplZCBF bWFpbA0KPiBBdXRob3IocykgOiBKLiBLbGVuc2luLCBZLiBLbw0KPiBGaWxlbmFtZSA6IGRyYWZ0 LWtsZW5zaW4taW1hLWZyYW1ld29yay0wMC50eHQNCj4gUGFnZXMgOiAxNA0KPiBEYXRlIDogMjAw NS0xMC0zDQo+IA0KPiAgICBGdWxsIHVzZSBvZiBlbGVjdHJvbmljIG1haWwgdGhyb3VnaG91dCB0 aGUgd29ybGQgcmVxdWlyZXMgdGhhdCBwZW9wbGUNCj4gICAgYmUgYWJsZSB0byB1c2UgdGhlaXIg b3duIG5hbWVzLCB3cml0dGVuIGNvcnJlY3RseSBpbiB0aGVpciBvd24NCj4gICAgbGFuZ3VhZ2Vz IGFuZCBzY3JpcHRzLCBhcyBtYWlsYm94IG5hbWVzIGluIGVtYWlsIGFkZHJlc3Nlcy4gIFRoaXMN Cj4gICAgZG9jdW1lbnQgaW50cm9kdWNlcyBhIHNlcmllcyBvZiBzcGVjaWZpY2F0aW9ucyBhbmQg b3BlcmF0aW9uYWwNCj4gICAgc3VnZ2VzdGlvbnMgdGhhdCBkZWZpbmUgbWVjaGFuaXNtcyBhbmQg cHJvdG9jb2wgZXh0ZW5zaW9ucyBuZWVkZWQgdG8NCj4gICAgZnVsbHkgc3VwcG9ydCBpbnRlcm5h dGlvbmFsaXplZCBlbWFpbCBhZGRyZXNzZXMuICBUaGVzZSBjaGFuZ2VzDQo+ICAgIGluY2x1ZGUg YW4gU01UUCBleHRlbnNpb24gYW5kIGV4dGVuc2lvbiBvZiBlbWFpbCBoZWFkZXIgc3ludGF4IHRv DQo+ICAgIGFjY29tbW9kYXRlIFVURi04IGRhdGEuICBUaGUgZG9jdW1lbnQgc2V0IGFsc28gd2ls bCBpbmNsdWRlDQo+ICAgIGRpc2N1c3Npb24gb2Yga2V5IGFzc3VtcHRpb25zIGFuZCBpc3N1ZXMg aW4gZGVwbG95aW5nIGZ1bGx5DQo+ICAgIGludGVybmF0aW9uYWxpemVkIGVtYWlsLg0KPiANCj4g QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtsZW5zaW4taW1hLWZyYW1ld29yay0wMC50eHQNCj4gDQo+ IFRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9tIHRoZSBJLUQgQW5ub3VuY2VtZW50IGxpc3QsIHNlbmQg YSBtZXNzYWdlIHRvIA0KPiBpLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3 b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5IG9mIHRoZSBtZXNzYWdlLiAgDQo+IFlvdSBjYW4g YWxzbyB2aXNpdCBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9JLUQtYW5u b3VuY2UgDQo+IHRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy4NCj4gDQo+IA0K PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExv Z2luIHdpdGggdGhlIHVzZXJuYW1lDQo+ICJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlv dXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVyIGxvZ2dpbmcgaW4sDQo+IHR5cGUgImNkIGludGVybmV0 LWRyYWZ0cyIgYW5kIHRoZW4NCj4gImdldCBkcmFmdC1rbGVuc2luLWltYS1mcmFtZXdvcmstMDAu dHh0Ii4NCj4gDQo+IEEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2FuIGJl IGZvdW5kIGluDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgDQo+IG9yIGZ0cDov L2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+IA0KPiANCj4gSW50ZXJuZXQt RHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC4NCj4gDQo+IFNlbmQgYSBtZXNz YWdlIHRvOg0KPiBtYWlsc2VydkBpZXRmLm9yZy4NCj4gSW4gdGhlIGJvZHkgdHlwZToNCj4gIkZJ TEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rbGVuc2luLWltYS1mcmFtZXdvcmstMDAudHh0Ii4N Cj4gDQo+IE5PVEU6IFRoZSBtYWlsIHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBk b2N1bWVudCBpbg0KPiBNSU1FLWVuY29kZWQgZm9ybSBieSB1c2luZyB0aGUgIm1wYWNrIiB1dGls aXR5LiAgVG8gdXNlIHRoaXMNCj4gZmVhdHVyZSwgaW5zZXJ0IHRoZSBjb21tYW5kICJFTkNPRElO RyBtaW1lIiBiZWZvcmUgdGhlICJGSUxFIg0KPiBjb21tYW5kLiAgVG8gZGVjb2RlIHRoZSByZXNw b25zZShzKSwgeW91IHdpbGwgbmVlZCAibXVucGFjayIgb3INCj4gYSBNSU1FLWNvbXBsaWFudCBt YWlsIHJlYWRlci4gIERpZmZlcmVudCBNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRlcnMNCj4gZXho aWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVjaWFsbHkgd2hlbiBkZWFsaW5nIHdpdGgNCj4g Im11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5lLiBkb2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVu IHNwbGl0DQo+IHVwIGludG8gbXVsdGlwbGUgbWVzc2FnZXMpLCBzbyBjaGVjayB5b3VyIGxvY2Fs IGRvY3VtZW50YXRpb24gb24NCj4gaG93IHRvIG1hbmlwdWxhdGUgdGhlc2UgbWVzc2FnZXMuDQo+ IA0KPiANCj4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBs aWFudCBtYWlsIHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJp ZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRlcm5ldC1EcmFmdC4NCj4gDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gSS1E LUFubm91bmNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ktZC1hbm5vdW5jZQ0KPiA= --===============2077960050== 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 --===============2077960050==-- From ima-bounces@ietf.org Sun Oct 09 13:15:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOelZ-00029t-A0; Sun, 09 Oct 2005 13:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOelX-00029o-Os for ima@megatron.ietf.org; Sun, 09 Oct 2005 13:15:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28079 for ; Sun, 9 Oct 2005 13:15:12 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOevF-0000iq-WF for ima@ietf.org; Sun, 09 Oct 2005 13:25:19 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1EOelS-000GqC-T2 for ima@ietf.org; Sun, 09 Oct 2005 13:15:12 -0400 Date: Sun, 09 Oct 2005 13:15:06 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <505AE7401EAD5EEEB468497F@[192.168.0.3]> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========DE7876BFD1F98A1B57B5==========" X-Spam-Score: 2.1 (++) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 Subject: [IMA] FWD: FWD: I-D ACTION:draft-yao-ima-smtpext-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --==========DE7876BFD1F98A1B57B5========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi. The attached two messages were sent to the IMA list on 30 September and 3 October, respectively. They apparently got buried as spam or otherwise disappeared. I hope they will get through this time -- sorry for not resending sooner. In the interim, the BOF slot has been approved and is on the agenda and Harald Alvestrand has agreed to chair it. john --==========DE7876BFD1F98A1B57B5========== Content-Type: message/rfc822; name="FWD: I-D ACTION:draft-yao-ima-smtpext-00.txt" Date: Fri, 30 Sep 2005 17:21:20 -0400 From: John C Klensin To: ima@ietf.org Subject: FWD: I-D ACTION:draft-yao-ima-smtpext-00.txt Message-ID: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========5E754B24CB95171D8C87==========" --==========5E754B24CB95171D8C87========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi. Largely as the result of a JET meeting last week, this list can expect a number of drafts to be posted within the next few days. Discussion on those drafts will, obviously, take place here. The key drafts are going to be: (1) An overview/ framework document, to be posted under the name draft-klensin-ima-framework-00. It discusses all of the other documents, including some as yet unwritten, and provides pointers to them. (2) A draft discussing the SMTP extension to support i18n addressing and UTF-8 headers. It goes into more detail on the addressing issues than the header ones, which are covered in (3). This is draft-yao-ima-smtpext-00, announced in the attached. (3) A draft discussing UTF-8 headers and their implementations. This will be posted as draft-yeh-ima-utf8headers-00 (4) A preliminary draft charter for a WG Other draft documents, including ones that discuss issues with in-transit downgrading and IMAP/POP, are in the pipeline and should appear before the Vancouver posting deadline. More details about those drafts and the relationship among them appear in (4) and (1). This effort by the JET team is intended to jump-start the process of identifying alternatives and moving toward protocol documents. While it has generated a tentative framework and a number of base documents, the effort should be considered a design team one, with responsibility and change control from the time an IETF WG is created belonging to that WG. john --==========5E754B24CB95171D8C87========== Content-Type: message/rfc822; name="I-D ACTION:draft-yao-ima-smtpext-00.txt" Return-path: Envelope-to: klensin+ietf@jck.com Delivery-date: Fri, 30 Sep 2005 16:23:27 -0400 Received: from [132.151.6.71] (helo=megatron.ietf.org) by bs.jck.com with esmtp (Exim 4.34) id 1ELRPY-000G3R-RZ for klensin+ietf@jck.com; Fri, 30 Sep 2005 16:23:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQtp-0005zl-2U; Fri, 30 Sep 2005 15:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQtQ-0005qp-TI for i-d-announce@megatron.ietf.org; Fri, 30 Sep 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03557 for ; Fri, 30 Sep 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELR1K-0008ED-0H for i-d-announce@ietf.org; Fri, 30 Sep 2005 15:58:15 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ELQtN-0007R9-Pd for i-d-announce@ietf.org; Fri, 30 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 30 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: I-D ACTION:draft-yao-ima-smtpext-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP extension for internationalized email address Author(s) : J. Yao Filename : draft-yao-ima-smtpext-00.txt Pages : 10 Date : 2005-9-30 The internationalized email address (IMA) should be solved in the transport-level, which is an architecturally desirable approach. This document specifies the use of SMTP extension for internationalized email address (IMA) delivery. And also mention about the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol propoesed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yao-ima-smtpext-00.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-yao-ima-smtpext-00.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-yao-ima-smtpext-00.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: <2005-9-30134451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yao-ima-smtpext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yao-ima-smtpext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-30134451.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --==========5E754B24CB95171D8C87==========-- --==========DE7876BFD1F98A1B57B5========== Content-Type: message/rfc822; name="Proposed BOF, WG charter, and more documents" Date: Mon, 03 Oct 2005 19:10:21 -0400 From: John C Klensin To: ima@ietf.org Subject: Proposed BOF, WG charter, and more documents Message-ID: <45F76EDF9CFB5F3993B35323@scan.jck.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========248DD0B60A2F09984A95==========" --==========248DD0B60A2F09984A95========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi. I'm attaching a BOF proposal that just went in, with an associated draft WG charter. The overview document, draft-klensin-ima-framework-00.txt was posted earlier today. Comments welcome, of course. john --==========248DD0B60A2F09984A95========== Content-Type: text/plain; charset=utf-8; name="ima-charter20051003.txt" Content-Disposition: attachment; filename="ima-charter20051003.txt"; size=9424 Content-Transfer-Encoding: quoted-printable 1. BOF Request Internationalized Email Addressing and Associated Extensions = (IMA) Two, or preferably 2 1/2, hour session in Vancouver. Chair: To be determined Description: We propose a BOF/ proto-WG session for the = Vancouver IETF to discuss internationalization of email addresses, = including a supporting SMTP Extension and the required = internationalization of email headers, expressing the latter in UTF-8. A = design team based in the Joint Engineering Team, consisting of = specialists from CNNIC, JPNIC/JPRS, KRNIC, and TWNIC plus some invited specialists have prepared and posted key base documents = for this work. Internationalization of email addresses is the key next = step in moving the Internet from its base in ASCII-only = identifiers. People's desire to use their names, correctly spelled, in = email address local-parts is far stronger than the desire to use internationalized domain names, already standardized by = the IETF. The goal of this work is to pursue, via a WG and IETF = processes, one possible approach to email internationalization, = carrying it through to a series of Experimental specifications. Once = those specifications exist, implementations will be created and = tested. If the results of that work are satisfactory, a = reconstituted WG will be proposed to standardize the approach. The longer session is proposed in order to start community = review on the documents and strategy themselves, rather than just establishing interest (which is already clear from the JET = effort and an earlier effort/mailing list that operated under the = "IMAA" label) and reviewing the proposed charter. Agenda Introduction, agenda bashing. Circa 10 minutes. Review of the general approach. Participants will be = expected to have read at least the documents listed below. Circa 20 = minutes. Review and discussion of the proposed charter. 20 minutes Specific document review and discussion. 70-100 minutes Specific Documents These documents may be updated prior to the cutoff. This = agenda will be updated to correspond. Draft charter (attached to this proposal) draft-klensin-ima-framework-00.txt draft-yao-ima-smtpext-00.txt draft-yeh-ima-utf8headers-00.txt Additional documents are expected to be posted before = IETF, as discussed in the "framework" document cited above. 2. Draft IMA Charter 2.1. Chair(s) To be determined 2.2. Applications Area Director(s) Ted Hardie Scott Hollenbeck 2.3. Applications Area Advisor To be determined 2.4. Mailing Lists General Discussion: ima@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ima Archive: http://www1.ietf.org/mail-archive/web/ima/index.html 2.5. Description of Working Group Since early in the effort to internationalize domain names, = which cumulated in the standards associated with IDNA, it has been understood that internationalization of email address local = parts is even more important. After all, most prefer variations on = their names for those addresses. At the same time, email address internationalization poses a series of special problems. = Constraints on the interpretation of local-parts except on the final = delivery system --constraints that go back to before RFC 821 and that = have been vital to the operation of the Internet's email = environment-- make address encoding nearly impossible. The need to use = addresses in both the email envelope and in header fields, and to do so = in ways that are at least compatible suggests that this is not a = simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of = an SMTP extension to enable both the use of UTF-8 in envelope address = local- parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its = initial target will be a set of experimental RFCs that specify the = details of this approach and provide the basis for generating and = testing interoperable implementations. Its work will include = examining whether "downgrading" -- transforming an internationalized = message to one that is compatible with unextended SMTP clients and = servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. Once the Experimental RFCs are completed and implemented, = they will be evaluated. If the approach is found to have been = successful using criteria the WG will establish as an early work item, the WG = will be reactivated to update the documents for processing onto the = standards track. 2.6. Goals and Milestones Very tentative = +-------------+--------------------------------------+-----------= ---+ | 27 Sept: | First draft charter circulated to | Done = | | | ADs and key onlookers | = | | 30 Sept | First draft SMTP extension | Done = | | | specification | = | | Oct 3: | Consolidated overview and framework | Done = | | | draft submitted for I-D posting | = | | Oct 3: | Draft WG charter, formal time-slot | John = | | | request for IETF 64, and fallback | = | | | BOF request submitted to | = | | | Applications Area Directors | = | | Oct 3: | Circulate draft charter to IMA | John = | | | mailing list for comment. | = | | Oct 17: | First draft of downgrade | JPRS = | | | specification | = | | Oct 17: | First draft of key open questions | JPRS = | | | list | = | | Oct 17: | First draft of "UTF-8 headers" | Jeff = | | Oct 24: | Second draft of overview and | = Yangwoo/John | | | framework document if needed. | = | | Oct 24: | New draft of SMTP extension | = Jiankang | | | specification. | = | | Nov 2 | Consolidated/updated list of | JPRS = | | | questions for IETF meeting review to | = | | | mailing list | = | | Week of Nov | Meet at IETF 64, review and identify | = | | 6: | outstanding issues with drafts. | = | | Nov 28: | Third draft of framework document | = | | | (last one?) | = | | Nov 28: | Second draft of base technical | = | | | specification. | = | = +-------------+--------------------------------------+-----------= ---+ Table 1 [[Note in draft: additional documents? For example, do we = need an informational "considerations for MUA authors" one?]] = +--------------+-------------------------------------------------= ---+ | ??? | Framework document complete, submit to IESG = for | | | publication as Experimental or Informational = RFC | | | [[note in draft: I have no idea whether the = IESG | | | will approve this document without enough of = the | | | package to be implementable, but, for = now...]] | | ??? | Base technical and UTF-8 header documents = | | | complete, submit for approval and = publication as | | | Experimental RFCs = | | ??? | Additional documents complete and submitted = for | | | approval and publication as experimental = RFCs. | | ??? - ??? | Period of implementation and evaluation = | | ??? | Implementation and operational experience = | | | evaluation draft posted = | | ??? | Revised versions of all required documents = posted | | ??? | Second version of all required documents = | | ??? | Request to IESG to Last Call required = documents | | | for Proposed Standard and to public the = experience | | | and evaluation draft as an Informational = RFC. | = +--------------+-------------------------------------------------= ---+ 2.7. Internet-Drafts Drafts listed below were posted as initial discussion = documents, preceeding the meeting at IETF 64 2005.06.27 draft-lee-jet-ima-00.txt 2005.07.18 draft-klensin-emailaddr-i18n-03.txt Drafts produced by the WG None as yet 2.8. Request For Comments None as yet --==========248DD0B60A2F09984A95==========-- --==========DE7876BFD1F98A1B57B5========== 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 --==========DE7876BFD1F98A1B57B5==========-- From ima-bounces@ietf.org Mon Oct 10 05:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOuP2-00012k-A8; Mon, 10 Oct 2005 05:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOegw-0001Gn-8G for ima@megatron.ietf.org; Sun, 09 Oct 2005 13:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27899 for ; Sun, 9 Oct 2005 13:10:27 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOeqe-0000d4-Lm for ima@ietf.org; Sun, 09 Oct 2005 13:20:34 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1EOegk-000GpO-SR for ima@ietf.org; Sun, 09 Oct 2005 13:10:20 -0400 Date: Sun, 09 Oct 2005 13:10:14 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <91E6466C57EE93724E61F9F5@[192.168.0.3]> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========477DF9C36DB6D6A80225==========" X-Spam-Score: 2.1 (++) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 X-Mailman-Approved-At: Mon, 10 Oct 2005 05:57:01 -0400 Subject: [IMA] FWD: FWD: I-D ACTION:draft-yao-ima-smtpext-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --==========477DF9C36DB6D6A80225========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi. The attached two messages were sent to the IMA list on 30 September and 3 October, respectively. They apparently got buried as spam or otherwise disappeared. I hope they will get through this time -- sorry for not resending sooner. In the interim, the BOF slot has been approved and is on the agenda and Harald Alvestrand has agreed to chair it. john --==========477DF9C36DB6D6A80225========== Content-Type: message/rfc822; name="FWD: I-D ACTION:draft-yao-ima-smtpext-00.txt" Date: Fri, 30 Sep 2005 17:21:20 -0400 From: John C Klensin To: ima@ietf.org Subject: FWD: I-D ACTION:draft-yao-ima-smtpext-00.txt Message-ID: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========5E754B24CB95171D8C87==========" --==========5E754B24CB95171D8C87========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi. Largely as the result of a JET meeting last week, this list can expect a number of drafts to be posted within the next few days. Discussion on those drafts will, obviously, take place here. The key drafts are going to be: (1) An overview/ framework document, to be posted under the name draft-klensin-ima-framework-00. It discusses all of the other documents, including some as yet unwritten, and provides pointers to them. (2) A draft discussing the SMTP extension to support i18n addressing and UTF-8 headers. It goes into more detail on the addressing issues than the header ones, which are covered in (3). This is draft-yao-ima-smtpext-00, announced in the attached. (3) A draft discussing UTF-8 headers and their implementations. This will be posted as draft-yeh-ima-utf8headers-00 (4) A preliminary draft charter for a WG Other draft documents, including ones that discuss issues with in-transit downgrading and IMAP/POP, are in the pipeline and should appear before the Vancouver posting deadline. More details about those drafts and the relationship among them appear in (4) and (1). This effort by the JET team is intended to jump-start the process of identifying alternatives and moving toward protocol documents. While it has generated a tentative framework and a number of base documents, the effort should be considered a design team one, with responsibility and change control from the time an IETF WG is created belonging to that WG. john --==========5E754B24CB95171D8C87========== Content-Type: message/rfc822; name="I-D ACTION:draft-yao-ima-smtpext-00.txt" Return-path: Envelope-to: klensin+ietf@jck.com Delivery-date: Fri, 30 Sep 2005 16:23:27 -0400 Received: from [132.151.6.71] (helo=megatron.ietf.org) by bs.jck.com with esmtp (Exim 4.34) id 1ELRPY-000G3R-RZ for klensin+ietf@jck.com; Fri, 30 Sep 2005 16:23:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQtp-0005zl-2U; Fri, 30 Sep 2005 15:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQtQ-0005qp-TI for i-d-announce@megatron.ietf.org; Fri, 30 Sep 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03557 for ; Fri, 30 Sep 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELR1K-0008ED-0H for i-d-announce@ietf.org; Fri, 30 Sep 2005 15:58:15 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ELQtN-0007R9-Pd for i-d-announce@ietf.org; Fri, 30 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 30 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: I-D ACTION:draft-yao-ima-smtpext-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP extension for internationalized email address Author(s) : J. Yao Filename : draft-yao-ima-smtpext-00.txt Pages : 10 Date : 2005-9-30 The internationalized email address (IMA) should be solved in the transport-level, which is an architecturally desirable approach. This document specifies the use of SMTP extension for internationalized email address (IMA) delivery. And also mention about the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol propoesed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yao-ima-smtpext-00.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-yao-ima-smtpext-00.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-yao-ima-smtpext-00.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: <2005-9-30134451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yao-ima-smtpext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yao-ima-smtpext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-30134451.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --==========5E754B24CB95171D8C87==========-- --==========477DF9C36DB6D6A80225========== Content-Type: message/rfc822; name="Proposed BOF, WG charter, and more documents" Date: Mon, 03 Oct 2005 19:10:21 -0400 From: John C Klensin To: ima@ietf.org Subject: Proposed BOF, WG charter, and more documents Message-ID: <45F76EDF9CFB5F3993B35323@scan.jck.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========248DD0B60A2F09984A95==========" --==========248DD0B60A2F09984A95========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi. I'm attaching a BOF proposal that just went in, with an associated draft WG charter. The overview document, draft-klensin-ima-framework-00.txt was posted earlier today. Comments welcome, of course. john --==========248DD0B60A2F09984A95========== Content-Type: text/plain; charset=utf-8; name="ima-charter20051003.txt" Content-Disposition: attachment; filename="ima-charter20051003.txt"; size=9424 Content-Transfer-Encoding: quoted-printable 1. BOF Request Internationalized Email Addressing and Associated Extensions = (IMA) Two, or preferably 2 1/2, hour session in Vancouver. Chair: To be determined Description: We propose a BOF/ proto-WG session for the = Vancouver IETF to discuss internationalization of email addresses, = including a supporting SMTP Extension and the required = internationalization of email headers, expressing the latter in UTF-8. A = design team based in the Joint Engineering Team, consisting of = specialists from CNNIC, JPNIC/JPRS, KRNIC, and TWNIC plus some invited specialists have prepared and posted key base documents = for this work. Internationalization of email addresses is the key next = step in moving the Internet from its base in ASCII-only = identifiers. People's desire to use their names, correctly spelled, in = email address local-parts is far stronger than the desire to use internationalized domain names, already standardized by = the IETF. The goal of this work is to pursue, via a WG and IETF = processes, one possible approach to email internationalization, = carrying it through to a series of Experimental specifications. Once = those specifications exist, implementations will be created and = tested. If the results of that work are satisfactory, a = reconstituted WG will be proposed to standardize the approach. The longer session is proposed in order to start community = review on the documents and strategy themselves, rather than just establishing interest (which is already clear from the JET = effort and an earlier effort/mailing list that operated under the = "IMAA" label) and reviewing the proposed charter. Agenda Introduction, agenda bashing. Circa 10 minutes. Review of the general approach. Participants will be = expected to have read at least the documents listed below. Circa 20 = minutes. Review and discussion of the proposed charter. 20 minutes Specific document review and discussion. 70-100 minutes Specific Documents These documents may be updated prior to the cutoff. This = agenda will be updated to correspond. Draft charter (attached to this proposal) draft-klensin-ima-framework-00.txt draft-yao-ima-smtpext-00.txt draft-yeh-ima-utf8headers-00.txt Additional documents are expected to be posted before = IETF, as discussed in the "framework" document cited above. 2. Draft IMA Charter 2.1. Chair(s) To be determined 2.2. Applications Area Director(s) Ted Hardie Scott Hollenbeck 2.3. Applications Area Advisor To be determined 2.4. Mailing Lists General Discussion: ima@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ima Archive: http://www1.ietf.org/mail-archive/web/ima/index.html 2.5. Description of Working Group Since early in the effort to internationalize domain names, = which cumulated in the standards associated with IDNA, it has been understood that internationalization of email address local = parts is even more important. After all, most prefer variations on = their names for those addresses. At the same time, email address internationalization poses a series of special problems. = Constraints on the interpretation of local-parts except on the final = delivery system --constraints that go back to before RFC 821 and that = have been vital to the operation of the Internet's email = environment-- make address encoding nearly impossible. The need to use = addresses in both the email envelope and in header fields, and to do so = in ways that are at least compatible suggests that this is not a = simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of = an SMTP extension to enable both the use of UTF-8 in envelope address = local- parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its = initial target will be a set of experimental RFCs that specify the = details of this approach and provide the basis for generating and = testing interoperable implementations. Its work will include = examining whether "downgrading" -- transforming an internationalized = message to one that is compatible with unextended SMTP clients and = servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. Once the Experimental RFCs are completed and implemented, = they will be evaluated. If the approach is found to have been = successful using criteria the WG will establish as an early work item, the WG = will be reactivated to update the documents for processing onto the = standards track. 2.6. Goals and Milestones Very tentative = +-------------+--------------------------------------+-----------= ---+ | 27 Sept: | First draft charter circulated to | Done = | | | ADs and key onlookers | = | | 30 Sept | First draft SMTP extension | Done = | | | specification | = | | Oct 3: | Consolidated overview and framework | Done = | | | draft submitted for I-D posting | = | | Oct 3: | Draft WG charter, formal time-slot | John = | | | request for IETF 64, and fallback | = | | | BOF request submitted to | = | | | Applications Area Directors | = | | Oct 3: | Circulate draft charter to IMA | John = | | | mailing list for comment. | = | | Oct 17: | First draft of downgrade | JPRS = | | | specification | = | | Oct 17: | First draft of key open questions | JPRS = | | | list | = | | Oct 17: | First draft of "UTF-8 headers" | Jeff = | | Oct 24: | Second draft of overview and | = Yangwoo/John | | | framework document if needed. | = | | Oct 24: | New draft of SMTP extension | = Jiankang | | | specification. | = | | Nov 2 | Consolidated/updated list of | JPRS = | | | questions for IETF meeting review to | = | | | mailing list | = | | Week of Nov | Meet at IETF 64, review and identify | = | | 6: | outstanding issues with drafts. | = | | Nov 28: | Third draft of framework document | = | | | (last one?) | = | | Nov 28: | Second draft of base technical | = | | | specification. | = | = +-------------+--------------------------------------+-----------= ---+ Table 1 [[Note in draft: additional documents? For example, do we = need an informational "considerations for MUA authors" one?]] = +--------------+-------------------------------------------------= ---+ | ??? | Framework document complete, submit to IESG = for | | | publication as Experimental or Informational = RFC | | | [[note in draft: I have no idea whether the = IESG | | | will approve this document without enough of = the | | | package to be implementable, but, for = now...]] | | ??? | Base technical and UTF-8 header documents = | | | complete, submit for approval and = publication as | | | Experimental RFCs = | | ??? | Additional documents complete and submitted = for | | | approval and publication as experimental = RFCs. | | ??? - ??? | Period of implementation and evaluation = | | ??? | Implementation and operational experience = | | | evaluation draft posted = | | ??? | Revised versions of all required documents = posted | | ??? | Second version of all required documents = | | ??? | Request to IESG to Last Call required = documents | | | for Proposed Standard and to public the = experience | | | and evaluation draft as an Informational = RFC. | = +--------------+-------------------------------------------------= ---+ 2.7. Internet-Drafts Drafts listed below were posted as initial discussion = documents, preceeding the meeting at IETF 64 2005.06.27 draft-lee-jet-ima-00.txt 2005.07.18 draft-klensin-emailaddr-i18n-03.txt Drafts produced by the WG None as yet 2.8. Request For Comments None as yet --==========248DD0B60A2F09984A95==========-- --==========477DF9C36DB6D6A80225========== 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 --==========477DF9C36DB6D6A80225==========-- From ima-bounces@ietf.org Thu Oct 13 04:10:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyAd-00074t-1L; Thu, 13 Oct 2005 04:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyAb-00074i-8I for ima@megatron.ietf.org; Thu, 13 Oct 2005 04:10:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01506 for ; Thu, 13 Oct 2005 04:10:30 -0400 (EDT) Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPyL2-0003Bx-QY for ima@ietf.org; Thu, 13 Oct 2005 04:21:23 -0400 Received: from jeffnb (pc092.twnic.net.tw [211.72.211.92]) by twnic.net.tw (8.13.5/8.13.4) with ESMTP id j9D5psFo028080 for ; Thu, 13 Oct 2005 13:51:55 +0800 Message-Id: <200510130551.j9D5psFo028080@twnic.net.tw> From: "Jeff Yeh" To: Date: Thu, 13 Oct 2005 13:56:43 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0126_01C5CFFD.F1FF19B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcXPah9j/q29XBg6QwWOyJcL8pFf6gAULS6w X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [IMA] FW: I-D ACTION:draft-yeh-ima-utf8headers-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0126_01C5CFFD.F1FF19B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all: For your information. Header draft published. Jeff Yeh -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, October 13, 2005 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-yeh-ima-utf8headers-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of Email Headers in UTF-8 Encoding Author(s) : J. Yeh Filename : draft-yeh-ima-utf8headers-00.txt Pages : 10 Date : 2005-10-12 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use international characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail headers. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email headers. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yeh-ima-utf8headers-00.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-yeh-ima-utf8headers-00.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-yeh-ima-utf8headers-00.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_000_0126_01C5CFFD.F1FF19B0 Content-Type: Message/External-body; name="ATT00289.dat" Content-Disposition: attachment; filename="ATT00289.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-12111740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yeh-ima-utf8headers-00.txt ------=_NextPart_000_0126_01C5CFFD.F1FF19B0 Content-Type: Message/External-body; name="draft-yeh-ima-utf8headers-00.txt" Content-Disposition: attachment; filename="draft-yeh-ima-utf8headers-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-12111740.I-D@ietf.org> ------=_NextPart_000_0126_01C5CFFD.F1FF19B0 Content-Type: text/plain; name="ATT00292.txt" Content-Disposition: attachment; filename="ATT00292.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0126_01C5CFFD.F1FF19B0 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_000_0126_01C5CFFD.F1FF19B0-- From ima-bounces@ietf.org Thu Oct 13 07:14:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ12E-0005AA-0K; Thu, 13 Oct 2005 07:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ12D-0005A5-0e for ima@megatron.ietf.org; Thu, 13 Oct 2005 07:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10217 for ; Thu, 13 Oct 2005 07:14:00 -0400 (EDT) Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ1Cg-00086B-1r for ima@ietf.org; Thu, 13 Oct 2005 07:24:56 -0400 Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.192) id 434e4172.1331d.a49; Thu, 13 Oct 2005 12:13:54 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id j9D9bqB14750; Thu, 13 Oct 2005 10:37:52 +0100 (BST) Date: Thu, 13 Oct 2005 10:37:47 +0100 To: uri@w3.org References: <43340C98.8020404@hpl.hp.com> <4344BA1D.1020300@stickdog.com> <434BBEEA.1050300@hpl.hp.com> <20051011170157.6752C4EF11@homer.w3.org> <434CFCC5.2040009@hpl.hp.com> <434D9863.38A1@xyzzy.claranet.de> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Message-ID: In-Reply-To: <434D9863.38A1@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA10217 Cc: ima@ietf.org Subject: [IMA] Mailto & ima (was RFC 2822 email addresses in tag URIs) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: uri@w3.org List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Thu, 13 Oct 2005 00:12:35 +0100, Frank Ellermann =20 wrote: > It's at a very early stage, and I won't bet that it flies in > the next years, but OTOH it would be a bad plan if you limit > tag URLs _unnecessarily_ in a way that cannot work with future > I18N Mail Addresses (=3D IMA). Yes. One of the ideas floated is that a person might have two email =20 addresses - one in his native language and one in strict ASCII, and the =20 mail delivery mechanism would deliver to the first if it knew how, but =20 drop down to the second if it was forced to use existing SMTP =20 implementations. But it should deliver to one or the other, but not both. So how does the guy publish his email address on his web page - or how =20 might one extend the mailto URI to provide that capability? I don't think= =20 this is the time to look into that seriously, but if anyone has any brigh= t =20 ideas as to how it might look, then it would be interesting to hear them. Cc to , but Reply-To set here. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 13 08:04:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1ou-0001Sq-HQ; Thu, 13 Oct 2005 08:04:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1os-0001Rq-RW for ima@megatron.ietf.org; Thu, 13 Oct 2005 08:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13282 for ; Thu, 13 Oct 2005 08:04:18 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ1zI-0001F8-KR for ima@ietf.org; Thu, 13 Oct 2005 08:15:14 -0400 Received: (snipe 29047 invoked by uid 0); 13 Oct 2005 21:05:12 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.058811 secs); Received: from unknown (HELO ?220.69.185.89?) (Z6??own@220.69.185.89) by unknown with SMTP; 13 Oct 2005 21:05:12 +0900 X-RCPTTO: uri@w3.org, ima@ietf.org Message-ID: <434E4D2B.5060905@icu.ac.kr> Date: Thu, 13 Oct 2005 21:03:55 +0900 From: yangwoo ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: uri@w3.org Subject: Re: [IMA] Mailto & ima (was RFC 2822 email addresses in tag URIs) References: <43340C98.8020404@hpl.hp.com> <4344BA1D.1020300@stickdog.com> <434BBEEA.1050300@hpl.hp.com> <20051011170157.6752C4EF11@homer.w3.org> <434CFCC5.2040009@hpl.hp.com> <434D9863.38A1@xyzzy.claranet.de> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > > On Thu, 13 Oct 2005 00:12:35 +0100, Frank Ellermann > wrote: > > >> It's at a very early stage, and I won't bet that it flies in >> the next years, but OTOH it would be a bad plan if you limit >> tag URLs _unnecessarily_ in a way that cannot work with future >> I18N Mail Addresses (= IMA). > > > Yes. One of the ideas floated is that a person might have two email > addresses - one in his native language and one in strict ASCII, and the > mail delivery mechanism would deliver to the first if it knew how, but > drop down to the second if it was forced to use existing SMTP > implementations. But it should deliver to one or the other, but not both. > > So how does the guy publish his email address on his web page - or how > might one extend the mailto URI to provide that capability? I don't > think this is the time to look into that seriously, but if anyone has > any bright ideas as to how it might look, then it would be interesting > to hear them. > > Cc to , but Reply-To set here. > Dear Charles Lindsey, As defined in RFC 2368, a mailto URL designates an "internet resource", which is the mailbox specified in the address. If I have two addresses, one in Korean and the other in ASCII, they are different addresses destined to two separate mailboxes. Serving these two boxes as one unified box is in the operator's discretion and hence out of mail specification effort. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 14 02:31:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJ6O-0003U4-TL; Fri, 14 Oct 2005 02:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJ6N-0003TH-Ti for ima@megatron.ietf.org; Fri, 14 Oct 2005 02:31:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20539 for ; Fri, 14 Oct 2005 02:31:30 -0400 (EDT) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQJGv-0000yJ-3s for ima@ietf.org; Fri, 14 Oct 2005 02:42:37 -0400 Received: (eyou send program); Fri, 14 Oct 2005 14:30:51 +0800 Message-ID: <329271451.30363@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Fri, 14 Oct 2005 14:30:51 +0800 Message-ID: <021e01c5d088$fa1b4cf0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: References: <43340C98.8020404@hpl.hp.com> <4344BA1D.1020300@stickdog.com><434BBEEA.1050300@hpl.hp.com><20051011170157.6752C4EF11@homer.w3.org><434CFCC5.2040009@hpl.hp.com> <434D9863.38A1@xyzzy.claranet.de> <329202074.13735@cnnic.cn> Subject: Re: [IMA] Mailto & ima (was RFC 2822 email addresses in tag URIs) Date: Fri, 14 Oct 2005 14:31:57 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0052078083==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0052078083== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciAgQ2hhcmxlcyBMaW5kc2V5LA0KDQogICAgICBUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29t bWVudHMuDQogICAgICBZb3NoaXJvIFlPTkVZQSB3aWxsIHN1Ym1pdCB0aGUgZHJhZnQ6RG93bmdy YWRpbmcgbWVjaGFuaXNtIGZvciBJbnRlcm5hdGlvbmFsaXplZCBlTWFpbCBBZGRyZXNzIChJTUEp IC0tLS1kcmFmdC15b25leWEtaW1hLWRvd25ncmFkZS0wMC50eHQgc29vbi4gIFRoaXMgZHJhZnQg bWF5IHNvbHZlIHRoZSBwdXp6bGUgaW4gdGhlIG1pbmQuIFBsZWFzZSBrZWVwIGFuIGV5ZSBvbiBp dC4NCg0KWWFvIEppYW5rYW5nDQpDTk5JQw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQpGcm9tOiAiQ2hhcmxlcyBMaW5kc2V5IiA8Y2hsQGNsZXJldy5tYW4uYWMudWs+DQpUbzog PHVyaUB3My5vcmc+DQpDYzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy IDEzLCAyMDA1IDU6MzcgUE0NClN1YmplY3Q6IFtJTUFdIE1haWx0byAmIGltYSAod2FzIFJGQyAy ODIyIGVtYWlsIGFkZHJlc3NlcyBpbiB0YWcgVVJJcykNCg0KDQpPbiBUaHUsIDEzIE9jdCAyMDA1 IDAwOjEyOjM1ICswMTAwLCBGcmFuayBFbGxlcm1hbm4gIA0KPG5vYm9keUB4eXp6eS5jbGFyYW5l dC5kZT4gd3JvdGU6DQoNCg0KPiBJdCdzIGF0IGEgdmVyeSBlYXJseSBzdGFnZSwgYW5kIEkgd29u J3QgYmV0IHRoYXQgaXQgZmxpZXMgaW4NCj4gdGhlIG5leHQgeWVhcnMsIGJ1dCBPVE9IIGl0IHdv dWxkIGJlIGEgYmFkIHBsYW4gaWYgeW91IGxpbWl0DQo+IHRhZyBVUkxzIF91bm5lY2Vzc2FyaWx5 XyBpbiBhIHdheSB0aGF0IGNhbm5vdCB3b3JrIHdpdGggZnV0dXJlDQo+IEkxOE4gTWFpbCBBZGRy ZXNzZXMgKD0gSU1BKS4NCg0KWWVzLiBPbmUgb2YgdGhlIGlkZWFzIGZsb2F0ZWQgaXMgdGhhdCBh IHBlcnNvbiBtaWdodCBoYXZlIHR3byBlbWFpbCAgDQphZGRyZXNzZXMgLSBvbmUgaW4gaGlzIG5h dGl2ZSBsYW5ndWFnZSBhbmQgb25lIGluIHN0cmljdCBBU0NJSSwgYW5kIHRoZSAgDQptYWlsIGRl bGl2ZXJ5IG1lY2hhbmlzbSB3b3VsZCBkZWxpdmVyIHRvIHRoZSBmaXJzdCBpZiBpdCBrbmV3IGhv dywgYnV0ICANCmRyb3AgZG93biB0byB0aGUgc2Vjb25kIGlmIGl0IHdhcyBmb3JjZWQgdG8gdXNl IGV4aXN0aW5nIFNNVFAgIA0KaW1wbGVtZW50YXRpb25zLiBCdXQgaXQgc2hvdWxkIGRlbGl2ZXIg dG8gb25lIG9yIHRoZSBvdGhlciwgYnV0IG5vdCBib3RoLg0KDQpTbyBob3cgZG9lcyB0aGUgZ3V5 IHB1Ymxpc2ggaGlzIGVtYWlsIGFkZHJlc3Mgb24gaGlzIHdlYiBwYWdlIC0gb3IgaG93ICANCm1p Z2h0IG9uZSBleHRlbmQgdGhlIG1haWx0byBVUkkgdG8gcHJvdmlkZSB0aGF0IGNhcGFiaWxpdHk/ IEkgZG9uJ3QgdGhpbmsgIA0KdGhpcyBpcyB0aGUgdGltZSB0byBsb29rIGludG8gdGhhdCBzZXJp b3VzbHksIGJ1dCBpZiBhbnlvbmUgaGFzIGFueSBicmlnaHQgIA0KaWRlYXMgYXMgdG8gaG93IGl0 IG1pZ2h0IGxvb2ssIHRoZW4gaXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciB0aGVtLg0K DQpDYyB0byA8aW1hQGlldGYub3JnPiwgYnV0IFJlcGx5LVRvIHNldCBoZXJlLg0KDQotLSANCkNo YXJsZXMgSC4gTGluZHNleSAtLS0tLS0tLS1BdCBIb21lLCBkb2luZyBteSBvd24gdGhpbmctLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlbDogKzQ0IDE2MSA0MzYgNjEzMSBGYXg6ICs0NCAxNjEg NDM2IDYxMzMgV2ViOiBodHRwOi8vd3d3LmNzLm1hbi5hYy51ay9+Y2hsDQpFbWFpbDogY2hsQGNs ZXJldy5tYW4uYWMudWsgU25haWw6IDUgQ2xlcmV3b29kIEF2ZSwgQ0hFQURMRSwgU0s4IDNKVSwg VS5LLg0KUEdQOiAyQzE1RjFBOSBGaW5nZXJwcmludDogNzMgNkQgQzIgNTEgOTMgQTAgMDEgRTcg NjUgRTggNjQgN0UgMTQgQTQgQUIgQTUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCklNQSBtYWlsaW5nIGxpc3QNCklNQUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo= --===============0052078083== 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 --===============0052078083==-- From ima-bounces@ietf.org Mon Oct 17 10:38:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERW8d-0007dD-Au; Mon, 17 Oct 2005 10:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERW8c-0007cz-3t for ima@megatron.ietf.org; Mon, 17 Oct 2005 10:38:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16044 for ; Mon, 17 Oct 2005 10:38:46 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWJw-000868-Ou for ima@ietf.org; Mon, 17 Oct 2005 10:50:38 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81E03258082 for ; Mon, 17 Oct 2005 16:38:11 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23441-01 for ; Mon, 17 Oct 2005 16:38:05 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD8B6258080 for ; Mon, 17 Oct 2005 16:38:04 +0200 (CEST) Date: Mon, 17 Oct 2005 16:38:16 +0200 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [IMA] Proposed agenda uploaded to ietf.org website X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0460593399==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0460593399== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========AE26A48103D7BADA9F0F==========" --==========AE26A48103D7BADA9F0F========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The proposed agenda for the IEE BOF (the one that was posted on this list=20 earlier) is uploaded to the IETF website: The links don't work; they'll work if you follow the link at the top of the = page: Additional BOF page: http://www.alvestrand.no/ietf/iee-bof/ If anyone wishes to suggest changes, please do - I'm expecting to add the=20 "gateway" draft to the reading list as soon as it appears (hopefully = today). Harald --==========AE26A48103D7BADA9F0F========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDU7dYOMj+2+WY0F4RAiwDAJ9XJeG6BPn3Tuy5xqcv9EK5skbpuQCeLjpl K4hpmTHL/RoXWeR4gLcWybk= =5ZD7 -----END PGP SIGNATURE----- --==========AE26A48103D7BADA9F0F==========-- --===============0460593399== 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 --===============0460593399==-- From ima-bounces@ietf.org Thu Oct 20 03:38:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESV0E-0000H5-Vm; Thu, 20 Oct 2005 03:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESV0C-0000Gc-Pv for ima@megatron.ietf.org; Thu, 20 Oct 2005 03:38:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21786 for ; Thu, 20 Oct 2005 03:38:06 -0400 (EDT) Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESVC4-0005ft-57 for ima@ietf.org; Thu, 20 Oct 2005 03:50:34 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id j9K7beR9010437 for ; Thu, 20 Oct 2005 16:37:40 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2005102016374001947 for ; Thu, 20 Oct 2005 16:37:40 +0900 Date: Thu, 20 Oct 2005 16:37:37 +0900 (JST) Message-Id: <20051020.163737.76897320.yone@jprs.co.jp> To: ima@ietf.org From: Yoshiro YONEYA X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Oct_20_16_37_37_2005_302)--" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [IMA] Fw: I-D ACTION:draft-yoneya-ima-downgrade-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org ----Next_Part(Thu_Oct_20_16_37_37_2005_302)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, IMA downgrade I-D had published. Regards, -- Yoshiro YONEYA ----Next_Part(Thu_Oct_20_16_37_37_2005_302)-- Content-Type: Message/Rfc822 Content-Disposition: inline Return-Path: Received: from localhost [127.0.0.1] by localhost with POP3 (fetchmail-6.2.5) for yone@localhost (single-drop); Thu, 20 Oct 2005 16:26:20 +0900 (JST) Received: from msgmgr01.jprs.co.jp (msgmgr01.jprs.co.jp [172.18.8.17]) by spool01.jprs.co.jp (8.12.10+Sun/8.12.11) with ESMTP id j9K75PhI013107; Thu, 20 Oct 2005 16:05:25 +0900 (JST) Received: from mx01.jprs.co.jp (mx01.jprs.co.jp [202.11.17.111]) by msgmgr01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id j9K75Peg005785; Thu, 20 Oct 2005 16:05:25 +0900 (JST) Received: from mx0.jprs.co.jp ([127.0.0.1]) by mx01.jprs.co.jp (SMSSMTP 4.1.7.33) with SMTP id M2005102016052513045 ; Thu, 20 Oct 2005 16:05:25 +0900 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx0.jprs.co.jp (8.13.4/8.13.4) with ESMTP id j9K75MFI029127; Thu, 20 Oct 2005 16:05:22 +0900 (JST) Authentication-Results: mx0.jprs.co.jp sender=i-d-announce-bounces@ietf.org; sender-id=neutral; spf=neutral Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUFp-0000Ah-3h; Thu, 20 Oct 2005 02:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUFX-0008Pq-15 for i-d-announce@megatron.ietf.org; Thu, 20 Oct 2005 02:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15587 for ; Thu, 20 Oct 2005 02:49:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESURP-0002tr-Gz for i-d-announce@ietf.org; Thu, 20 Oct 2005 03:02:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESUFV-0003AM-Dx for i-d-announce@ietf.org; Thu, 20 Oct 2005 02:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Oct 2005 02:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: I-D ACTION:draft-yoneya-ima-downgrade-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Downgrading mechanism for Internationalized eMail Address (IMA) Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-yoneya-ima-downgrade-00.txt Pages : 10 Date : 2005-10-19 Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail headers. The internationalized email address (IMA) is implemented by allowing UTF-8 characters in the SMTP envelope and mail headers. This document describes downgrading from internationalized addressing with the SMTP extension and UTF-8 headers to traditional email formats and characters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yoneya-ima-downgrade-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yoneya-ima-downgrade-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yoneya-ima-downgrade-00.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: <2005-10-19190343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yoneya-ima-downgrade-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yoneya-ima-downgrade-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-19190343.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- ----Next_Part(Thu_Oct_20_16_37_37_2005_302)-- 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 ----Next_Part(Thu_Oct_20_16_37_37_2005_302)---- From ima-bounces@ietf.org Thu Oct 20 15:49:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgQA-00013Z-7t; Thu, 20 Oct 2005 15:49:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgQ9-00013C-Bv for ima@megatron.ietf.org; Thu, 20 Oct 2005 15:49:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09867 for ; Thu, 20 Oct 2005 15:49:38 -0400 (EDT) Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESgc8-0006S0-EK for ima@ietf.org; Thu, 20 Oct 2005 16:02:13 -0400 Received: from [212.15.83.170] ([212.15.83.170] helo=clerew.man.ac.uk) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.192) id 4357f4ce.3d2d.1b2 for ima@ietf.org; Thu, 20 Oct 2005 20:49:34 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id j9KJHpB27388 for ; Thu, 20 Oct 2005 20:17:52 +0100 (BST) Date: Thu, 20 Oct 2005 20:17:45 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA09867 Subject: [IMA] draft-utf8headers-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Basically, I entirely approve of the general approach taken by this draft= , =20 and by the others in this series.If you want to see my full views on this= , =20 then see which = I =20 wrote at the tail end of Paul Hoffman's attempt on the old imaa list. It = =20 is very similar to what John is now proposing in his freamework draft, bu= t =20 raises a few additional issues. Feel free to make use of it. However, there are two major issues that I wish to raise, and a few lesse= r =20 ones after that: 1. Essentially, we are defining an extension to RFC 2822. However, RFC =20 2822 carefully steered clear of transport issues, and this document shoul= d =20 do the same. What we are defining could be called the "Internationalized Internet =20 Message Format", so let us not be bashful - let us say outright that is =20 what we are defining, and that it is a supserset of the "Internet Message= =20 Format" defined by RFC 2822 - its principal difference, of course, being = =20 that it allows header fields in UTF-8. However, it should be clear that messages in this new format can be =20 transported via any protocol with the necessary capabilities. SMTP is the= =20 obvious candidate (and we have proposals to extend SMTP), but these =20 messages might also be sent via UUCP, or they might be gatewayed into =20 X.400, or into News and then sent via NNTP, or they might be encapsulated= =20 using message/rfc822 and hidden inside some other message, or they might = =20 be bundled up in mbox format and sent by FTP, and I am sure there are man= y =20 other possibilities. Now UUCP is already capable of transporting such messages (I am not sure = =20 whether UTF-8 in Bang Paths would work, but it would not surprise me if =20 they did). NNTP also already has that capability for stuff converted into= =20 News format. I haven't a clue about X.400, but anything involving FTP =20 would already work. The biggest problems, of course, are MUAs and storage= =20 agents (POP3 and IMAP), but that is a matter for the people who want to =20 send/receive such mail to worry about. Therefore, any suggestion in the draft that this format is only for use i= n =20 connection with an extended SMTP needs to come out (last para of 1.1, 2nd= =20 para of 1.2, last para of 1.2 - what you are defining is a "format", not = a =20 "protocol", and most of section 3 and its subsections). All that needs be= =20 said is that messages in this format MUST NOT be sent unless it is known = =20 that the transport to be used supports them (with a remark that, even =20 then, bounces are to be expected) and with a reference to the extended =20 SMTP draft as the prime example. Most (but not all) of what is in section= =20 3 really belongs in that companion SMTP draft. 2. Para 5 of 1.2 gives the impression that UTF-8 can be used anywhere in = =20 headers, though you do point to some of the exceptions later on. However,= =20 you really need to say very precisely where UTF-8 is to be allowed on top= =20 of the present RFC 2822, and where it is not. Clearly it is allowed in s, s and s (which= =20 immediately gives you the Subject, Comments and Keywords headers plus any= =20 X-headers). and remain as they are for the =20 foreseeable future, so that covers Date, Message-ID, In-Reply-To and =20 References, plus their Resent versions. All the headers involving =20 es need further work, as does Received. Naturally, header-names = =20 remain in ASCII on the wire (nobody cares if MUAs display them to users i= n =20 translation). I agree that you have mentioned most of these, but the only way to do it = =20 properly is to include the revised ABNF that will fix it precisely (which= =20 brings up the interesting question of how much UTF-8, if any, you let int= o =20 the "Obsolete Syntax"). OK, this ABNF does not need to be written just yet, but it needs to be =20 made clear that it _will_ be done once we have a proper WG to do it. =20 Moreover, I am in a position to help with that, because at one time the =20 Usefor WG was going to introduce UTF-8 headers as the norm (we backed out= =20 because of the difficulty of gatewaying into email, but we are scheduled = =20 to return to the matter as an Experimental Protocol if/when we have =20 completed our primary tasks). Most of the ABNF changes we made are =20 immediately applicable to the present work, so I can dig them out of our = =20 earlier drafts and present them here when the proper time to do so comes. Then, turning to MIME, we can probably allow UTF-8 in s. but not i= n =20 s (that gives us the Content-Type and Content-Distribution headers= , =20 but definitely not Content-Transfer-Encoding) and after that there are th= e =20 List-* header used by mailing lists, many of which use URIs which could =20 usefully be upgraded to IRIs. Turning to section 2.1, you _appear_ to be saying that everything MUST be= =20 in UTF-8, implying that encoding as in RFC 2047/2231 and in IDNA is =20 forbidden. Looking closely, I don't think that is what you meant to say, = =20 but it could do with some rewriting. My understanding is: a) Anything appearing naked in a header MUST be in UTF-8 (thus =20 excluding naked use of any other charsets whatsoever). b) If you really want to use some other charset (and we would rather = =20 you didn't), then you MAY encode it using RFC 2047/2231, and indeed you =20 MAY continue to use use those encodings even for stuff in UTF-8 as in =20 present usage, and you MAY show domains either in UTF-8 or in punycode. c) That leaves s, and I think we have work to do on those= , =20 which I intend to raise in another thread. d) There are also issues of normalization to be addressed (NFC, NFKC,= =20 stringprep, etc) wherever UTF-8 is allowed. But primary discussion of tha= t =20 really goes with s, and we can see afterwards whether it need= s =20 mention in other contexts. Now we are down to the niggles: 3. Since "alternative" addresses are to be provided in the SMTP extension= , =20 there needs to be some method for the author to specify (in or around the= =20 To: header) what these alternate recipient addresses are, so that the MUA= =20 can provide them to the SMTP (whatever) server. Likewise, he needs to be = =20 able to say (in or around the Reply-To: header) both addresses to be used= =20 to get back to him. I have not heard any proposals on this yet, so it =20 needs to be noted as an omission to be attended to. I can imagine =20 solutions involving tinkering with the syntax, and solutions = =20 involving extra headers (as Paul Hoffman proposed), and I can see nasty =20 snags with both of them :-( . 4. I see two mentions of encoding in quoted-printable (presumably implyin= g =20 the use of RFC 2047). It should be noted that RFC 2047 also allows base64= =20 for that purpose. 5. RFC 2822 had no need to distinguish between characters and octets. =20 However, when it comes th the 78 character limit that RFC 2822 recommends= =20 for line lengths, then I think we have to make it clear that it means =20 _characters_ (since it relates to what can be seen in one line of a =20 reasonable window), whereas the required limit of 998 needs to be =20 expressed in _octets_, because it relates to the maximum size of buffers = =20 that you might need to allocate. See section 4. 6. And finally, we need to decide whether to follow the RFC 2822 =20 convention of talking of "header fields". of whether to speak, as Yeh's =20 draft does, of "headers". Usefor used to do it that way, but it was =20 decided recently (against my advice) to follow the strict RFC 2822 =20 terminology, so I had to go through all the drafts I was responsible for = =20 and change them. I shall be most peeved if you are allowed to get away =20 with making this change :-) . --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 21 06:41:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuL2-00069L-Lf; Fri, 21 Oct 2005 06:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuL1-00069C-RO for ima@megatron.ietf.org; Fri, 21 Oct 2005 06:41:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12808 for ; Fri, 21 Oct 2005 06:41:17 -0400 (EDT) Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESuX8-0003W3-R2 for ima@ietf.org; Fri, 21 Oct 2005 06:53:59 -0400 Received: from jeffnb (pc090.twnic.net.tw [211.72.211.90]) by twnic.net.tw (8.13.5/8.13.4) with ESMTP id j9LAfG1C009273; Fri, 21 Oct 2005 18:41:18 +0800 Message-Id: <200510211041.j9LAfG1C009273@twnic.net.tw> From: "Jeff Yeh" To: "'Charles Lindsey'" , Subject: RE: [IMA] draft-utf8headers-00 Date: Fri, 21 Oct 2005 18:45:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 thread-index: AcXVtlgs7Omm7zyxSvKXcPMXfHF6BwAbhPaQ In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Dear Charles: Thank you for your comment. Please check my response in the content. Jeff Yeh >=20 > Basically, I entirely approve of the general approach taken=20 > by this draft, >=20 > and by the others in this series.If you want to see my full=20 > views on this, >=20 > then see=20 > which I >=20 > wrote at the tail end of Paul Hoffman's attempt on the old=20 > imaa list. It > is very similar to what John is now proposing in his=20 > freamework draft, but >=20 > raises a few additional issues. Feel free to make use of it. >=20 > However, there are two major issues that I wish to raise, and=20 > a few lesser >=20 > ones after that: >=20 > 1. Essentially, we are defining an extension to RFC 2822. However, RFC > 2822 carefully steered clear of transport issues, and this=20 > document should >=20 > do the same. >=20 > What we are defining could be called the "Internationalized Internet > Message Format", so let us not be bashful - let us say=20 > outright that is > what we are defining, and that it is a supserset of the=20 > "Internet Message >=20 > Format" defined by RFC 2822 - its principal difference, of=20 > course, being > that it allows header fields in UTF-8. >=20 (snip) Actually, we had discuss about this part on our last meeting in Beijing. The situation is that we currently focus on the protocol of transporting I-email. And this draft specified the basic idea of using UTF8 header = to=20 carry Internationazed data. We will have to figure out whether our to=20 "updating" 2822 or just as "extending" it, sooner or later. >=20 >=20 > 2. Para 5 of 1.2 gives the impression that UTF-8 can be used=20 > anywhere in > headers, though you do point to some of the exceptions later=20 > on. However, >=20 > you really need to say very precisely where UTF-8 is to be=20 > allowed on top >=20 > of the present RFC 2822, and where it is not. >=20 > Clearly it is allowed in s, s and=20 > s (which >=20 > immediately gives you the Subject, Comments and Keywords=20 > headers plus any >=20 > X-headers). and remain as they are for the > foreseeable future, so that covers Date, Message-ID, In-Reply-To and > References, plus their Resent versions. All the headers involving > es need further work, as does Received. Naturally,=20 > header-names > remain in ASCII on the wire (nobody cares if MUAs display=20 > them to users in >=20 > translation). >=20 > I agree that you have mentioned most of these, but the only=20 > way to do it > properly is to include the revised ABNF that will fix it=20 > precisely (which >=20 > brings up the interesting question of how much UTF-8, if any,=20 > you let into >=20 > the "Obsolete Syntax"). >=20 > OK, this ABNF does not need to be written just yet, but it needs to be > made clear that it _will_ be done once we have a proper WG to do it. > Moreover, I am in a position to help with that, because at=20 > one time the > Usefor WG was going to introduce UTF-8 headers as the norm=20 > (we backed out >=20 > because of the difficulty of gatewaying into email, but we=20 > are scheduled > to return to the matter as an Experimental Protocol if/when we have > completed our primary tasks). Most of the ABNF changes we made are > immediately applicable to the present work, so I can dig them=20 > out of our > earlier drafts and present them here when the proper time to=20 > do so comes. >=20 Totally agree, but which means a lot of content to add. That will be = great If you can provide any useful materials. > Then, turning to MIME, we can probably allow UTF-8 in=20 > s. but not in >=20 > s (that gives us the Content-Type and=20 > Content-Distribution headers, >=20 > but definitely not Content-Transfer-Encoding) and after that=20 > there are the >=20 > List-* header used by mailing lists, many of which use URIs=20 > which could > usefully be upgraded to IRIs. >=20 > Turning to section 2.1, you _appear_ to be saying that=20 > everything MUST be >=20 > in UTF-8, implying that encoding as in RFC 2047/2231 and in IDNA is > forbidden. Looking closely, I don't think that is what you=20 > meant to say, > but it could do with some rewriting. My understanding is: > a) Anything appearing naked in a header MUST be in UTF-8 (thus > excluding naked use of any other charsets whatsoever). > b) If you really want to use some other charset (and we=20 > would rather > you didn't), then you MAY encode it using RFC 2047/2231, and=20 > indeed you > MAY continue to use use those encodings even for stuff in UTF-8 as in > present usage, and you MAY show domains either in UTF-8 or in=20 > punycode. > c) That leaves s, and I think we have work to=20 > do on those, >=20 > which I intend to raise in another thread. > d) There are also issues of normalization to be addressed=20 > (NFC, NFKC, >=20 > stringprep, etc) wherever UTF-8 is allowed. But primary=20 > discussion of that >=20 > really goes with s, and we can see afterwards=20 > whether it needs >=20 > mention in other contexts. a), b) yes. d) no, normalization and stringprep should not performed. Some reason will be described in [history] document, which is not published yet. = But you=20 may refer to draft-klensin-emailaddr-i18n-03.txt, it has most content = about that. >=20 > Now we are down to the niggles: >=20 > 3. Since "alternative" addresses are to be provided in the=20 > SMTP extension, >=20 > there needs to be some method for the author to specify (in=20 > or around the >=20 > To: header) what these alternate recipient addresses are, so=20 > that the MUA >=20 > can provide them to the SMTP (whatever) server. Likewise, he=20 > needs to be > able to say (in or around the Reply-To: header) both=20 > addresses to be used >=20 > to get back to him. I have not heard any proposals on this yet, so it > needs to be noted as an omission to be attended to. I can imagine > solutions involving tinkering with the syntax,=20 > and solutions > involving extra headers (as Paul Hoffman proposed), and I can=20 > see nasty > snags with both of them :-( . >=20 Yes, it's really tough problem. We are trying to solve this problem in=20 The [downgrade] document. The 00 version I-D had already come out. But I think it will be a major revise in our next meeting. >=20 > 4. I see two mentions of encoding in quoted-printable=20 > (presumably implying > the use of RFC 2047). It should be noted that RFC 2047 also=20 > allows base64 > for that purpose. >=20 > 5. RFC 2822 had no need to distinguish between characters and octets. > However, when it comes th the 78 character limit that RFC=20 > 2822 recommends >=20 > for line lengths, then I think we have to make it clear that it means > _characters_ (since it relates to what can be seen in one line of a > reasonable window), whereas the required limit of 998 needs to be > expressed in _octets_, because it relates to the maximum size=20 > of buffers > that you might need to allocate. See section 4. 4 and 5 Agree, will update in next version. >=20 > 6. And finally, we need to decide whether to follow the RFC 2822 > convention of talking of "header fields". of whether to=20 > speak, as Yeh's > draft does, of "headers". Usefor used to do it that way, but it was > decided recently (against my advice) to follow the strict RFC 2822 > terminology, so I had to go through all the drafts I was=20 > responsible for > and change them. I shall be most peeved if you are allowed to get away > with making this change :-) . >=20 > -- > Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0 > thing------------------- > ----- > = Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0 > http://www.cs.man.ac.uk > /~chl > = Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0 > CHEADLE,=A0SK8=A03JU, > =A0U.K. > = PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A0 > 64=A07E=A014=A0A4=A0 > AB=A0A5 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima >=20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 21 17:06:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET46N-0002uW-KJ; Fri, 21 Oct 2005 17:06:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET46M-0002sV-0r for ima@megatron.ietf.org; Fri, 21 Oct 2005 17:06:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09892 for ; Fri, 21 Oct 2005 17:06:45 -0400 (EDT) Received: from [212.15.83.123] (helo=clerew.man.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET4IV-0003AZ-2f for ima@ietf.org; Fri, 21 Oct 2005 17:19:32 -0400 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id j9LL1fB13648 for ; Fri, 21 Oct 2005 22:01:41 +0100 (BST) To: ima@ietf.org Date: Fri, 21 Oct 2005 22:01:39 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by clerew.man.ac.uk id j9LL1fB13648 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Subject: [IMA] draft-smtpext-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org As with my remarks concerning the headers draft, this is absolutely on th= e =20 right lines, but again I have some issues, and some niggles. 1. The main problem is how an SMTP server will know that it is dealing =20 with an I18N Message (I presume it is expected that these servers will =20 also be handling vast quantities of the current RFC 2822 mail). For sure, if it sees an ALT-ADDRESS parameter in a FROM or RCPT command, = =20 it will know, but some I18N messages will still have ASCII-only addresses= . =20 Moreover, this message may well have arrived at this server by a complex = =20 chain of gatewaying and processing by all sorts of intermediate =20 transports, and all traces of its earlier history may have been lost. Clearly, the server can examine the whole of the headers to see if bit-8 = =20 is set in any octet anywhere, but that is tedious, especially since it ha= s =20 to repeated at every intermediate site. I suggest it would be far better = =20 to invent a new header something like I18N-Headers: yes and say in the headers draft that all I18N Messages MUST include it. That= =20 feature would also be of use to other transport mechanisms, gateways and = =20 storage agents, all of which may need to apply special processing to thes= e =20 messages. (The precise name and syntax of this header does not matter for= =20 now - there may well be additional information that may need to be put in= =20 it.) 2. We realise that the Received header is going to be troublesome, =20 especially as regards its "for" clause, but it not quite so bad as has =20 been suggested as regards its "from" clause, since messages will generall= y =20 arrive from other servers which are also handling old-fashioned ASCII =20 messages, and whose own domain names will therefore already be in ASCII. = =20 So you are not likely to see much UTF-8 in there (and also, we are alread= y =20 agreed that EHLO must always be in ASCII - though you do not seem to have= =20 mentioned that). 3. Your document needs to be much more clear that it is doing two jobs: a) Internationalizing the envelope (with downgrading or bouncing as = =20 needed) b) Dealing with I18N within the messages (again, with downgrading). So you need another section within 2.5 dealing with the DATA command =20 because, if it is an I18N Message, that is where the downgrading of the =20 headers in the message will have to be done (and maybe of the body too if= =20 MIME multipart or message types are in there). So, looking at section 2.2, last paragraph, please make it clear that it = =20 is about _envelope_ processing (how to construct the FROM and RCPT for th= e =20 next hop). I suggest s/replace/downgrade/. And if you are going to mentio= n =20 the IDNA rules, you may as well mention 'Nameprep' explicitly. The rest is mostly niggles: 4. In 2.3, I sujspect the definition of 'Atom' will turn out to be more =20 restrictive that arbitrary UTF-8. In any case, you will need to give ABNF= =20 in due course. 5. In 2.4, you will need ABNF for ALT-ADDRESS (the job of the Downgrade =20 document is to tell you how to derive it, not what it looks like). =20 Actually, it will be exactly what RFC 2821 currently permits (it is the =20 main FROM/RCPT address that is going to be different). 6. In 2.5, you need to deal with VRFY and EXPN. Although it is not =20 fashionable to implement them these days, they could actually be quite =20 useful here to give the client a preview of what the downgraded address i= s =20 going to look like before he comits to letting you do it. 7. In 3, current local-parts are not made up of "any ASCII". There are =20 some restrictions (though probably not enough :-( ). As regards current =20 attempts at I18N using backspaces and so on, how prevalent is this? One o= f =20 the mistakes (IMO) in RFC 2822 was allowing NO-WS-CTL in local-parts and = =20 other places. It would be nice if we could simply outlaw the use of =20 backspace (and the rest). Incidentally, there is another custom used in German and other languages,= =20 which is to replace "m=FCnchen" by "muenchen". That too could cause =20 troubles, but would be harder to forbid. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 22 11:13:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETL3P-0001Q4-CP; Sat, 22 Oct 2005 11:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETL3N-0001Pz-FG for ima@megatron.ietf.org; Sat, 22 Oct 2005 11:13:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15929 for ; Sat, 22 Oct 2005 11:12:49 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETLFj-0002TZ-MM for ima@ietf.org; Sat, 22 Oct 2005 11:25:48 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ETL3E-000AxK-B6; Sat, 22 Oct 2005 11:12:52 -0400 Date: Sat, 22 Oct 2005 11:12:52 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [IMA] draft-smtpext-00 Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Charles, While I'm not the author, let me try to answer a few of these questions... --On Friday, 21 October, 2005 22:01 +0100 Charles Lindsey wrote: > As with my remarks concerning the headers draft, this is > absolutely on the right lines, but again I have some issues, > and some niggles. >=20 > 1. The main problem is how an SMTP server will know that it is > dealing with an I18N Message (I presume it is expected that > these servers will also be handling vast quantities of the > current RFC 2822 mail). Please be careful here, since this whole model hinges on what is going on in the envelope, starting with the server advertising IMA capability in the EHLO response. That advertisement specifies that it is willing and able to: * deal with an envelope address (local-part and/or domain) in UTF-8 should one arrive in any forward or reverse path.=20 * deal with an ALT-ADDRESS parameter attached to the forward or reverse path. The document is not, if I recall, specific about whether such a thing is permitted if the (primary) address is all-ASCII; we need to discuss that and make a rule. * deal with UTF-8 headers should they arrive. An "i18n message" is defined by the presence of at least one of those things. There is also an underlying theory in all of this, which perhaps the docs don't make clear. If you (or someone else) can suggest text in the next few hours, there is (barely) time to get a new version of the framework piece posted before the deadline -- given the paucity of comments suggesting changes, I had concluded that was unnecessary, but could change my mind. That theory is that an EHLO response of "IMA" is essentially an assertion that the server is i18n-clean, i.e., that it doesn't need to do anything special to handle these messages. The only exception would arise if downgrading were required in a future step and it was prepared to do that. It is not an assertion that the server is prepared to go out and do strange and unusual internationalization-specific things other than applying IDNA before going to the DNS for any non-ASCII domain name labels. For the servers I've poked at in looking at this extension, that is also the right way to implement this. Making a server 8bit-clean at this level makes much more sense than detecting IMAs as somehow special and generating a new code path. Conversely, if a server is somehow 8bit-hostile, tolerating these changes is going to take a lot more than detection and a special case. > For sure, if it sees an ALT-ADDRESS parameter in a FROM or > RCPT command, it will know, but some I18N messages will still > have ASCII-only addresses. Moreover, this message may well > have arrived at this server by a complex chain of gatewaying > and processing by all sorts of intermediate transports, and > all traces of its earlier history may have been lost. History or state is not needed. All the server needs to do is to announce that it has the relevant capability (otherwise, it is all a client problem) and then handle whichever of those three elements it gets (if any) as if they are normal, which they should be. > Clearly, the server can examine the whole of the headers to > see if bit-8 is set in any octet anywhere, but that is > tedious, especially since it has to repeated at every > intermediate site. I suggest it would be far better to invent > a new header something like > I18N-Headers: yes > and say in the headers draft that all I18N Messages MUST > include it. That feature would also be of use to other > transport mechanisms, gateways and storage agents, all of > which may need to apply special processing to these messages. > (The precise name and syntax of this header does not matter > for now - there may well be additional information that may > need to be put in it.) I see three problems with this. First, headers are of no use to an SMTP server or relay that is trying to follow the "don't mess with headers or content" rule. And that rule is still our target norm, antispam issues notwithstanding. Second, by the time a server finds that header, it will have already processed the envelope and might well have already encountered UTF-8 information, so the information might be useless. Conversely, requiring that all i18n messages must include the header is easy, requiring that all non-i18n messages NOT include it is a lot harder. That leads us down a path in which the right thing for an IMA-capable client to do is simply to insert that header, always, whether a particular message needs it or not. And that takes it very far down the path toward useless noise. Finally, remember that gateways, SMTP implementations on firewalls, and even submission servers, are routinely dropping headers they don't understand these days. So there is no guarantee that the header will arrive and a receiving server that announces IMA capability must be prepared for i18n data regardless of whether the header appears, just to protect = itself. =20 > 2. We realise that the Received header is going to be > troublesome, especially as regards its "for" clause, but it > not quite so bad as has been suggested as regards its "from" > clause, since messages will generally arrive from other > servers which are also handling old-fashioned ASCII messages, > and whose own domain names will therefore already be in ASCII. > So you are not likely to see much UTF-8 in there (and also, we > are already agreed that EHLO must always be in ASCII - though > you do not seem to have mentioned that). This may need either more discussion, or clarification in the document, but I continue to believe that domain names in Received "from" clauses are going to need to be in punycode if they are IDNs. Similarly for EHLO -- I just don't see any choice there. > 3. Your document needs to be much more clear that it is doing > two jobs: > a) Internationalizing the envelope (with downgrading or > bouncing as needed) > b) Dealing with I18N within the messages (again, with > downgrading). > So you need another section within 2.5 dealing with the DATA > command because, if it is an I18N Message, that is where the > downgrading of the headers in the message will have to be > done (and maybe of the body too if MIME multipart or message > types are in there). This material was intended to be in the framework document or the downgrade one. I think it is, but the document boundaries may need more sorting in the next iterations. My own assumption is that, if an IMA-capable server receives a message and is then required to pass it on to an IMA-incapable system, it must then (and only them) make a reliable determination of whether the particular message requires IMA facilities. That means an octet-by-octet scan of envelope address fields and of the headers. I think the body is an issue or not depending on whether the next-hop server supports 8BITMIME and should follow its rules, although one of the tasks that ought to get onto the list or into the downgrade document is a careful analysis of the impact on all of this on internal MIME headers associated with multipart or message. > So, looking at section 2.2, last paragraph, please make it > clear that it is about _envelope_ processing (how to > construct the FROM and RCPT for the next hop). I suggest > s/replace/downgrade/. And if you are going to mention the > IDNA rules, you may as well mention 'Nameprep' explicitly. The latter is a matter of theory. In principle, IDNA is atomic wrt any application that uses it. If we need to start talking specifically about, or dissecting, what Nameprep does, what punycode does, etc., we are going to need to redesign the IDNA specification, since some things that we informally think of as Nameprep are actually done elsewhere, etc. > The rest is mostly niggles: I'll leave these to the author to comment on, at least initially, except for the 7th... >... > 7. In 3, current local-parts are not made up of "any ASCII". > There are some restrictions (though probably not enough :-( > ). As regards current attempts at I18N using backspaces and > so on, how prevalent is this? One of the mistakes (IMO) in > RFC 2822 was allowing NO-WS-CTL in local-parts and other > places. It would be nice if we could simply outlaw the use of > backspace (and the rest). Please read 2821 (or 821) carefully. Some things require quotes and escapes, but... As far as "backspaces and so on", it is one of those architecture-defining cases. Whether it is appropriate to eliminate it now is another question, but the answer, IMO, is probably "no", at least until we have a widely-deployed alternate solution. > Incidentally, there is another custom used in German and other > languages, which is to replace "m=C3=BCnchen" by "muenchen". = That > too could cause troubles, but would be harder to forbid. Open that can of worms, and two-meter rattlesnakes come out. It is a good example of why I don't believe one can automatically derive an all-ASCII address or phrase from an i18n one, and an even better example of why "upgrading" is not on the table, but, beyond that... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 24 03:14:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwXp-0000oX-6s; Mon, 24 Oct 2005 03:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwXn-0000oP-Am for ima@megatron.ietf.org; Mon, 24 Oct 2005 03:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21091 for ; Mon, 24 Oct 2005 03:14:40 -0400 (EDT) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETwkN-0007uv-RJ for ima@ietf.org; Mon, 24 Oct 2005 03:28:02 -0400 Received: (eyou send program); Mon, 24 Oct 2005 15:14:22 +0800 Message-ID: <330138062.26787@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Mon, 24 Oct 2005 15:14:22 +0800 Message-ID: <021b01c5d86a$aed736c0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "Charles Lindsey" References: <329929504.24151@cnnic.cn> Subject: Re: [IMA] draft-smtpext-00 Date: Mon, 24 Oct 2005 15:15:15 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0259618835==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0259618835== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBDaGFybGVzIEguIExpbmRzZXksDQoNCiAgICBUaGFua3MgYSBsb3QgZm9yIHlvdXIgZ29v ZCBjb21tZW50cy4gDQogICBzb21lIGNvbW1lbnMgYmVsb3cuDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIgPGNobEBjbGVyZXcubWFuLmFjLnVr Pg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciAyMiwgMjAwNSA1 OjAxIEFNDQpTdWJqZWN0OiBbSU1BXSBkcmFmdC1zbXRwZXh0LTAwDQoNCg0KPkFzIHdpdGggbXkg cmVtYXJrcyBjb25jZXJuaW5nIHRoZSBoZWFkZXJzIGRyYWZ0LCB0aGlzIGlzIGFic29sdXRlbHkg b24gdGhlICANCj5yaWdodCBsaW5lcywgYnV0IGFnYWluIEkgaGF2ZSBzb21lIGlzc3VlcywgYW5k IHNvbWUgbmlnZ2xlcy4NCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHdvcmRzInRoaXMgaXMgYWJz b2x1dGVseSBvbiB0aGUgIA0KcmlnaHQgbGluZXMuIiBXZSBhcHByZWNpYXRlIHlvdXIgd29yZHMg YW5kIHN1cHBvcnRzLiANCg0KIGZvciB0aGUgbW9zdCBwcm9ibGVtcywgSm9obiBoYXZlIGFscmVh ZHkgZ2l2ZW4geW91IHRoZSBhbnN3ZXJzIG9yIGNsYXJpZmljYXRpb25zLiAodGhhbmtzIEpvaG4p LA0KDQpJIGFuc3dlciB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucy4NCg0KPlRoZSByZXN0IGlzIG1v c3RseSBuaWdnbGVzOg0KDQo+NC4gSW4gMi4zLCBJIHN1anNwZWN0IHRoZSBkZWZpbml0aW9uIG9m ICdBdG9tJyB3aWxsIHR1cm4gb3V0IHRvIGJlIG1vcmUgIA0KPnJlc3RyaWN0aXZlIHRoYXQgYXJi aXRyYXJ5IFVURi04LiBJbiBhbnkgY2FzZSwgeW91IHdpbGwgbmVlZCB0byBnaXZlIEFCTkYgIA0K PmluIGR1ZSBjb3Vyc2UuDQoNCiAgV2Ugd2lsbCBnaXZlIEFCTkYgZGVzY3JpcHRpb24gaW4gdGhl IG5leHQgdmVyc2lvbi4NCg0KDQo+NS4gSW4gMi40LCB5b3Ugd2lsbCBuZWVkIEFCTkYgZm9yIEFM VC1BRERSRVNTICh0aGUgam9iIG9mIHRoZSBEb3duZ3JhZGUgIA0KPmRvY3VtZW50IGlzIHRvIHRl bGwgeW91IGhvdyB0byBkZXJpdmUgaXQsIG5vdCB3aGF0IGl0IGxvb2tzIGxpa2UpLiAgDQo+QWN0 dWFsbHksIGl0IHdpbGwgYmUgZXhhY3RseSB3aGF0IFJGQyAyODIxIGN1cnJlbnRseSBwZXJtaXRz IChpdCBpcyB0aGUgIA0KPm1haW4gRlJPTS9SQ1BUIGFkZHJlc3MgdGhhdCBpcyBnb2luZyB0byBi ZSBkaWZmZXJlbnQpLg0KICANCldlIHdpbGwgZ2l2ZSBBQk5GIGRlc2NyaXB0aW9uIGluIHRoZSBu ZXh0IHZlcnNpb24uDQoNCj42LiBJbiAyLjUsIHlvdSBuZWVkIHRvIGRlYWwgd2l0aCBWUkZZIGFu ZCBFWFBOLiBBbHRob3VnaCBpdCBpcyBub3QgIA0KPmZhc2hpb25hYmxlIHRvIGltcGxlbWVudCB0 aGVtIHRoZXNlIGRheXMsIHRoZXkgY291bGQgYWN0dWFsbHkgYmUgcXVpdGUgIA0KPnVzZWZ1bCBo ZXJlIHRvIGdpdmUgdGhlIGNsaWVudCBhIHByZXZpZXcgb2Ygd2hhdCB0aGUgZG93bmdyYWRlZCBh ZGRyZXNzIGlzICANCj5nb2luZyB0byBsb29rIGxpa2UgYmVmb3JlIGhlIGNvbWl0cyB0byBsZXR0 aW5nIHlvdSBkbyBpdC4NCg0KYWdyZWUuIHdlIHdpbGwgY29uc2lkZXIgdG8gZGVhbCB3aXRoIFZS RlkgYW5kIEVYUE4gaW4gbmV4dCB2ZXJzaW9uLg0KDQp0aGFua3MuDQpZYW8gSmlhbmthbmcNCkNO TklDDQo= --===============0259618835== 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 --===============0259618835==-- From ima-bounces@ietf.org Tue Oct 25 17:59:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWpG-0000X2-8B; Tue, 25 Oct 2005 17:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWpE-0000Wk-2D for ima@megatron.ietf.org; Tue, 25 Oct 2005 17:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17630 for ; Tue, 25 Oct 2005 17:59:02 -0400 (EDT) Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUX23-0003eq-4C for ima@ietf.org; Tue, 25 Oct 2005 18:12:46 -0400 Received: from www.gradwell.com ([193.111.200.100]) by lon-mail-3.gradwell.net with smtp (Gradwell gwh-smtpd 1.198) id 435eaa98.17c08.83; Tue, 25 Oct 2005 22:58:48 +0100 (envelope-sender ) Received: from 213.122.21.181 (SquirrelMail authenticated user postmaster@pop3.clerew.man.ac.uk) by www.gradwell.com with HTTP; Tue, 25 Oct 2005 22:58:48 +0100 (BST) Message-ID: <1297.213.122.21.181.1130277528.squirrel@www.gradwell.com> In-Reply-To: References: Date: Tue, 25 Oct 2005 22:58:48 +0100 (BST) Subject: Re: [IMA] draft-smtpext-00 From: "Charles Lindsey" To: "John C Klensin" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 8bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chl@clerew.man.ac.uk List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org John Klensin wrote >While I'm not the author, let me try to answer a few of these questions... --On Friday, 21 October, 2005 22:01 +0100 Charles Lindsey wrote: >> 1. The main problem is how an SMTP server will know that it is >> dealing with an I18N Message (I presume it is expected that >> these servers will also be handling vast quantities of the >> current RFC 2822 mail). >Please be careful here, since this whole model hinges on what is going on in the envelope, starting with the server advertising IMA capability in the EHLO response. That advertisement specifies that it is willing and able to: * deal with an envelope address... in UTF-8 should one arrive... * deal with an ALT-ADDRESS .... The document is not, if I recall, specific about whether such a thing is permitted if the (primary) address is all-ASCII... Yes, it specifically allows that. Moreover, it is essential that it should. Consider the following scenario: An I18N email is sent to a non-ASCII address (maybe with Alternate), and with UTF-8 in various headers including, say, To: and Subject: and passes through servers with IMA capability until it reaches its destination. So far so good. At the destination server, however, it gets forwarded (something in the /etc/aliases file, perhaps) to an ordinary ASCII address. So there is nothing in the forwarded envelope to show that it is an I18N message, but it still contains UTF-8 in the To: and Subject: headers (which might still need to be downgraded if some subsequent agent does not do IMA). I don't think we want to disallow that perfectly normal behaviour. * deal with UTF-8 headers should they arrive. >An "i18n message" is defined by the presence of at least one of those things. There is also an underlying theory in all of this, which perhaps the docs don't make clear. If you (or someone else) can suggest text in the next few hours, ... Sorry, I am away from home at the moment with limited email access, and an unfamiliar email system. >That theory is that an EHLO response of "IMA" is essentially an assertion that the server is i18n-clean, i.e., that it doesn't need to do anything special to handle these messages. The only exception would arise if downgrading were required in a future step and it was prepared to do that. Sure, but if the next server (or MDA) in line doesn't do IMA, then it MUST either downgrade or bounce. But if the message is _not_ an I18N message (we assume that MTAs will be handling a mix of both kinds of message) then it MUST NOT bounce. Therefore, if the next server does not announce the IMA capability, the current server MUST know somehow whether the mesage in hand is an I18N one, and if there is no clue in the envelope (see above) then it HAS either to scan all the headers looking for bit-8, or else there HAS to be some information in the message to indicate so. If the bulk of the messages handled by the server are ASCII only (which will be true of all servers initially, and of most servers in N.America permanently), then that is a lot of extra work for it to do. >For the servers I've poked at in looking at this extension, that is also the right way to implement this. Making a server 8bit-clean at this level makes much more sense than detecting IMAs as somehow special and generating a new code path. Sure. This server will be 8-bit clean. But it is being prepared for the next server downstream being 8-bit hostile that is going to be the messy part to implement. And there is good precedent for having the information in a header in the message. 10 years ago, when 8BITMIME appeared, there was such a header - Content-Transfer-Encoding. If the CTE was 7bit or Q-P or Base64, the server didn't need to bother with any special actions - it just sent the message on, 8BITMIME or not. But if the CTE was 8bit and the next server did not advertise 8BITMIME, it was required to downgrade (and there was not even a bounce option in those days). >> Clearly, the server can examine the whole of the headers to >> see if bit-8 is set in any octet anywhere, but that is >> tedious, especially since it has to repeated at every >>> intermediate site. I suggest it would be far better to invent >> a new header something like >> I18N-Headers: yes >> and say in the headers draft that all I18N Messages MUST >> include it. >I see three problems with this. First, headers are of no use to an SMTP server or relay that is trying to follow the "don't mess with headers or content" rule.,, And that rule went out when 8BITMIME appeared. >Second, by the time a server finds that header, it will have already processed the envelope and might well have already encountered UTF-8 information,... and it might not > Conversely,... requiring that all non-i18n messages NOT include it is a lot harder. That leads us down a path in which the right thing for an IMA-capable client to do is simply to insert that header, always,... Fine, but it then takes the risk of having its messages bounced. >Finally, remember that gateways, SMTP implementations on firewalls, and even submission servers, are routinely dropping headers they don't understand these days. But IMA capable servers would not be doing that. And the message will never reach an 'old' server unless it has already been downgraded, at which point we don't really care if that header gets lost. >> 2. We realise that the Received header is going to be >> troublesome, especially as regards its "for" clause, but it >> not quite so bad as has been suggested as regards its "from" >> clause, since messages will generally arrive from other >> servers which are also handling old-fashioned ASCII messages, >> and whose own domain names will therefore already be in ASCII. >This may need either more discussion, or clarification in the document, but I continue to believe that domain names in Received "from" clauses are going to need to be in punycode if they are IDNs Sure, you have to be prepared for that. I was only pointing out that servers which also handle non-IMA traffic are unlikely to insert their own identity in a Received header in UTF-8. Charles _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 26 23:22:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyLL-0003OG-0x; Wed, 26 Oct 2005 23:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyLJ-0003KE-I0 for ima@megatron.ietf.org; Wed, 26 Oct 2005 23:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18811 for ; Wed, 26 Oct 2005 23:22:01 -0400 (EDT) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUyYU-0004yN-9i for ima@ietf.org; Wed, 26 Oct 2005 23:36:01 -0400 Received: (eyou send program); Thu, 27 Oct 2005 11:21:37 +0800 Message-ID: <330383297.28535@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Thu, 27 Oct 2005 11:21:37 +0800 Message-ID: <010c01c5daa5$ad66ed70$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: Date: Thu, 27 Oct 2005 11:22:36 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [IMA] formal Agenda of the Sixty-fourth IETF is published X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1414281214==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============1414281214== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C5DAE8.BB7E4690" This is a multi-part message in MIME format. ------=_NextPart_000_0109_01C5DAE8.BB7E4690 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcHVibGljL3ZpZXdfbWVl dGluZ19hZ2VuZGFfdGV4dC5jZ2k/bWVldGluZ19udW09NjQNCg0KYmVsb3cgaXMgb3VyIElNQSBt ZWV0aW5nIGluZm9ybWF0aW9uDQoNCg0KVEhVUlNEQVksIE5vdmVtYmVyIDEwLCAyMDA1DQoNCjEx MzAtMTMwMCBCcmVhaw0KMTMwMC0xNTAwIEFmdGVybm9vbiBTZXNzaW9uIEkNClNhbG9uIEEvQiAg QVBQICBpZWUgICAgICAgSW50ZXJuYXRpb25hbGl6ZWQgRW1haWwgYW5kIEV4dGVuc2lvbnMgQk9G DQoNCg0KDQpZQU8gSmlhbmthbmcNCkJlc3QgUmVnYXJkcw0KVGVsOjg2LTEwLTU4ODEzMDA3DQpG YXg6ODYtMTAtNjI1NTk4OTINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpDaGluYSBJbnRlcm5ldCBOZXR3b3JrIEluZm9ybWF0aW9uIENlbnRlciAo Q05OSUMpDQo0LCBTb3V0aCA0dGggU3RyZWV0LCBaaG9uZ2d1YW5jdW4sDQpIYWlkaWFuIGRpc3Ry aWN0LA0KQmVpamluZyAxMDAwODAsIENoaW5hDQpQT0I6IEJlaWppbmcgMzQ5LCBCcmFuY2ggNg0K aHR0cDovL3d3dy5jbm5pYy5jbg0KRW1haWw6IHlhb2prQGNubmljLmNuDQpoZWFsdGh5YW9AMTYz LmNvbQ0K ------=_NextPart_000_0109_01C5DAE8.BB7E4690 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE1MjIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIGFsbCw8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48QSANCmhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcHVibGljL3Zp ZXdfbWVldGluZ19hZ2VuZGFfdGV4dC5jZ2k/bWVldGluZ19udW09NjQiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvcHVibGljL3ZpZXdfbWVldGluZ19hZ2VuZGFfdGV4dC5jZ2k/bWVldGlu Z19udW09NjQ8L0E+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YmVsb3cgaXMgb3VyIElNQSBtZWV0aW5nIGluZm9y bWF0aW9uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5USFVSU0RBWSwg Tm92ZW1iZXIgMTAsIDIwMDU8QlI+PEJSPjExMzAtMTMwMCBCcmVhazxCUj4xMzAwLTE1MDAgQWZ0 ZXJub29uIA0KU2Vzc2lvbiBJPEJSPlNhbG9uIEEvQiZuYnNwOyBBUFAmbmJzcDsgaWVlJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KSW50ZXJuYXRpb25hbGl6ZWQgRW1haWwg YW5kIEV4dGVuc2lvbnMgQk9GPEJSPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+WUFPIEppYW5rYW5nPEJSPkJlc3QgDQpSZWdhcmRzPEJSPlRlbDo4Ni0xMC01 ODgxMzAwNzxCUj5GYXg6ODYtMTAtNjI1NTk4OTI8QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+Q2hpbmEgDQpJbnRlcm5ldCBOZXR3b3JrIElu Zm9ybWF0aW9uIENlbnRlciAoQ05OSUMpPEJSPjQsIFNvdXRoIDR0aCBTdHJlZXQsIA0KWmhvbmdn dWFuY3VuLDxCUj5IYWlkaWFuIGRpc3RyaWN0LDxCUj5CZWlqaW5nIDEwMDA4MCwgQ2hpbmE8QlI+ UE9COiBCZWlqaW5nIDM0OSwgDQpCcmFuY2ggNjxCUj48QSBocmVmPSJodHRwOi8vd3d3LmNubmlj LmNuIj5odHRwOi8vd3d3LmNubmljLmNuPC9BPjxCUj5FbWFpbDogPEEgDQpocmVmPSJtYWlsdG86 eWFvamtAY25uaWMuY24iPnlhb2prQGNubmljLmNuPC9BPjxCUj48QSANCmhyZWY9Im1haWx0bzpo ZWFsdGh5YW9AMTYzLmNvbSI+aGVhbHRoeWFvQDE2My5jb208L0E+PEJSPjwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0109_01C5DAE8.BB7E4690-- --===============1414281214== 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 --===============1414281214==-- From ima-bounces@ietf.org Thu Oct 27 17:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFdN-0000jG-ED; Thu, 27 Oct 2005 17:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFdM-0000it-3O for ima@megatron.ietf.org; Thu, 27 Oct 2005 17:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19623 for ; Thu, 27 Oct 2005 17:49:47 -0400 (EDT) Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVFqj-00020R-Rb for ima@ietf.org; Thu, 27 Oct 2005 18:03:57 -0400 Received: from www.gradwell.com ([193.111.200.100]) by lon-mail-1.gradwell.net with smtp (Gradwell gwh-smtpd 1.198) id 43614b7e.16048.e85 for ima@ietf.org; Thu, 27 Oct 2005 22:49:50 +0100 (envelope-sender ) Received: from 213.122.132.192 (SquirrelMail authenticated user postmaster@pop3.clerew.man.ac.uk) by www.gradwell.com with HTTP; Thu, 27 Oct 2005 22:49:50 +0100 (BST) Message-ID: <1452.213.122.132.192.1130449790.squirrel@www.gradwell.com> Date: Thu, 27 Oct 2005 22:49:50 +0100 (BST) From: "Charles Lindsey" To: ima@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 8bit Subject: [IMA] Re: draft-downgrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chl@clerew.man.ac.uk List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org As usual, the main principles are fine, but a couple of issues and various niggles. 1. You speak at various places of downgrading things which are not addresses by encoding with base64 with UTF-8 tag. I presume this refers to encoding according to RFC 2047, in which case please say so and give a reference to RFC 2047 (though RFC 2231 also extends RFC 2047 and should be mentioned). Moreover, if it is RFC 2047, then the encoding can be Quoted-Printable as well as base 64 (and in some languages Q-P is better). OTOH, if you did not mean the refer to RFC 2047, then I do not understand - please explain. RFC 2047 is an ugly beast, but at least nearly every MUA knows how to upgrade it. You also need to bear in mind that RFC 2047 can only be used in heades which are 'unstructured' (but that automatically includes all X-headers), or in s and s. But there are plenty of other 'structured' headers which have been defined and in which UTF-8 might be useful, but for which RFC 2047 could not help (except within s). Examples are Content-Type and Content-Distribution, where I think you should mention that RFC 2231 provides a means of downgrading for s (in s); and the various List-* headers, many of which make use of URIs - in an I18N message, these would be sent as IRIs, but could be downgraded to URIs. 2. But there will still be headers where no downgrade method is available, in which case we need a general-purpose downgrade mechanism. It has been suggested that encapsulating the whole message could get around that problem, but I can see problems there, since any Received headers with UTF-8 in them should really remain outside the encapsulation (for if they did not, then further Recevied headers added after the encapsulation would be separated from them, and you might even find a situation where you needed to encapsulate again). So let me suggest an alternative general purpose downgrading method. Suppose we define a new header: Header-Tunnel: (whose syntax is just ) Then if you have a structured header Some-Header: {stuff with UTF-8 in it} You replace it by Header-Tunnel: Some-Header: ?=utf-8?{UTF-8 stuff 2047-encoded}=? with the intention that anyone who wanted to upgrade it would simply decode the 2047 stuff and throw away the "Header-Tunnel: ", leaving the original header behind. This would not work for any header which needed looking at during the transport process (so it might not be a good idea for To: and Cc: and such like - but we already have downgrades for those). But it would be fine for headers intended to be read by humans, and even an MUA that did not understand the "Header-Tunnel:" header would display somethng that a human could understand. And now for the niggles: 3.In your section 4.3, I think you need to say that domains and addresses in Received headers (e.g. in By, From and For) need to be downgraded using ACE/IDN. You certainly cannot use RFC 2047 on the whole of a Received header, because it is a 'structured' header and RFC 2047 does not allow that. 4. I like the idea, in 4.4, of an "IMA-Downgraded" header (but it could not be "X-IMA-Downgraded" because you are not allowed to standardize an "X-" header. However, what happens if there are several headers with the same header-name? How can you tell which of them have been downgraded and which are as originally sent? That could easily happen with Received headers, and also with Keywords. Also, it needs to be mentioned that your Envelope-To and Envelope-From might look different with a non-SMTP transport with a different concept of "envelope". 5. In 5,1, I think you need some mention of "upgrading", if only to say that transports SHOULD NOT do it, but only the "final destination" (which might be the MDA or the MUA or a gateway or a mailing list expander - this is an area we will have to discuss further). 6. And I do not understand your 5.2 at all. I think I would expect that for an MDA to upgrade would be quite a useful feature (but maybe configurable at the request of the owner of the mailbox). But, as said, this needs much more discussion. Charles. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 28 08:32:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTPA-0002Nv-P0; Fri, 28 Oct 2005 08:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTP8-0002NJ-TK for ima@megatron.ietf.org; Fri, 28 Oct 2005 08:32:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11610 for ; Fri, 28 Oct 2005 08:32:01 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVTch-00041N-7R for ima@ietf.org; Fri, 28 Oct 2005 08:46:20 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98B3D2596C0; Fri, 28 Oct 2005 14:31:25 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29941-01; Fri, 28 Oct 2005 14:31:22 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CF19258085; Fri, 28 Oct 2005 14:31:22 +0200 (CEST) Date: Fri, 28 Oct 2005 14:32:40 +0200 From: Harald Tveit Alvestrand To: chl@clerew.man.ac.uk, ima@ietf.org Subject: Re: [IMA] Re: draft-downgrade-00 Message-ID: <3AD0D36A33F5E6D3BD225529@svartdal.hjemme.alvestrand.no> In-Reply-To: <1452.213.122.132.192.1130449790.squirrel@www.gradwell.com> References: <1452.213.122.132.192.1130449790.squirrel@www.gradwell.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org A better question might be: Is a message ever - EVER - upgraded from "normal SMTP" to UTF8HEADERS? The world would be a simpler place if the answer was "no". _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 28 09:15:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVU4W-0001Yg-SD; Fri, 28 Oct 2005 09:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVU4U-0001Xc-IP for ima@megatron.ietf.org; Fri, 28 Oct 2005 09:15:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13777 for ; Fri, 28 Oct 2005 09:14:44 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUI3-00059A-6V for ima@ietf.org; Fri, 28 Oct 2005 09:29:04 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EVU4D-0007X3-QN; Fri, 28 Oct 2005 09:14:45 -0400 Date: Fri, 28 Oct 2005 09:14:45 -0400 From: John C Klensin To: Harald Tveit Alvestrand , chl@clerew.man.ac.uk, ima@ietf.org Subject: Re: [IMA] Re: draft-downgrade-00 Message-ID: <4AA4004FE23FD2DC51AD4532@scan.jck.com> In-Reply-To: <3AD0D36A33F5E6D3BD225529@svartdal.hjemme.alvestrand.no> References: <1452.213.122.132.192.1130449790.squirrel@www.gradwell .com> <3AD0D36A33F5E6D3BD225529@svartdal.hjemme.alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Friday, 28 October, 2005 14:32 +0200 Harald Tveit Alvestrand wrote: > A better question might be: > > Is a message ever - EVER - upgraded from "normal SMTP" to > UTF8HEADERS? > > The world would be a simpler place if the answer was "no". My own conclusion, at least so far, is that "upgrade" is basically impossible unless one carries a large amount of information around that would have to be specially handled in both the originating MUA and in any server doing downgrades. It would also require either separation of trace information into the envelope (for the record, the I-D I wrote about how to do that was an exploration into what would be required -- I didn't believe it was a good idea then and don't believe it would be a good idea now) or even more structure. I've worked up the latter on a whiteboard and can go through it if someone really cares, but it leads to various bad places. A more simple version of this is that we concluded with 8BITMIME that, if downgrading occurred, that was the end of it and there should be no attempt at an upgrade. As far as I can tell, all of the reasons for that apply here too... and there are some additional ones. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 30 00:17:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW4d3-00044K-LS; Sun, 30 Oct 2005 00:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW4d2-000442-5R for ima@megatron.ietf.org; Sun, 30 Oct 2005 00:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12111 for ; Sun, 30 Oct 2005 00:16:50 -0400 (EDT) Received: from [212.15.83.126] (helo=clerew.man.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW4qu-0000p6-9g for ima@ietf.org; Sun, 30 Oct 2005 00:31:30 -0400 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id j9TMItm04647 for ; Sat, 29 Oct 2005 23:18:56 +0100 (BST) To: ima@ietf.org Subject: Re: [IMA] Re: draft-downgrade-00 References: <1452.213.122.132.192.1130449790.squirrel@www.gradwell .com> <3AD0D36A33F5E6D3BD225529@svartdal.hjemme.alvestrand.no> <4AA4004FE23FD2DC51AD4532@scan.jck.com> Message-ID: Date: Sat, 29 Oct 2005 23:18:50 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <4AA4004FE23FD2DC51AD4532@scan.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by clerew.man.ac.uk id j9TMItm04647 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Fri, 28 Oct 2005 14:14:45 +0100, John C Klensin wrot= e: > > --On Friday, 28 October, 2005 14:32 +0200 Harald Tveit > Alvestrand wrote: > >> A better question might be: >> >> Is a message ever - EVER - upgraded from "normal SMTP" to >> UTF8HEADERS? >> >> The world would be a simpler place if the answer was "no". > > My own conclusion, at least so far, is that "upgrade" is > basically impossible unless one carries a large amount of > information around that would have to be specially handled in > both the originating MUA and in any server doing downgrades. Please can you explain further why that should be so. I think it is =20 essential for our scheme that an acceptable upgrading should at least be = =20 *possible*. What is "acceptable" needs discussion, of course. It does not= =20 necessarily mean recovering every byte of the original exactly as =20 originally written. But clearly every bit of text in the original should = =20 appear in some form, though maybe not in exactly the same charset and =20 maybe not encoded (if at all) exactly as before. And the headers added in= =20 the downgrade should probably be left. But I think we need to consider exactly what the limitations on upgrading= =20 would be, if only to ensure that the downgrading we specify does not make= =20 subsequent upgrading more difficult than it needs to be. > It > would also require either separation of trace information into > the envelope Again, it would help if you could explain that further (at least an =20 example to illustrate that there is a problem). Having said that, however, the matter of whether upgrading CAN be done is= =20 entirely separate from whether, when and where it SHOULD be done. For sure, it would be pointless to do it during transport (at the SHOULD = =20 NOT or even MUST NOT level). It it happens at all, it should be when the = =20 message has arrived at its "destination", however that is defined. =20 Essentially, it is up to the recipient how he would like his message deal= t =20 with. But since the MDA is really acting on behalf of that recipient, we = =20 cannot ignore MDAs. If the ultimate recipient has contracted with the MDA= =20 to provide him with POP3 and/or IMAP mailbox(es), then it is reasonable =20 for him to ask for his mailbox to hold (or at least appear to hold) an =20 upgraded form of the message. Moreover, the WG will have to face this whe= n =20 it comes to proposing upgrades for the POP3 and IMAP standards. And then gateways, mailing list expanders, and other examples of special = =20 processing should be able to decide for themselves whether to upgrade =20 before passing it on. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima