From ima-bounces@ietf.org Fri Dec 02 06:26:31 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 1Ei93f-0005ym-UR; Fri, 02 Dec 2005 06:26:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei93d-0005sn-A3 for ima@megatron.ietf.org; Fri, 02 Dec 2005 06:26:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09794 for ; Fri, 2 Dec 2005 06:25:41 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei9OG-0002zs-UF for ima@ietf.org; Fri, 02 Dec 2005 06:47:50 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jB2BQCu29822; Fri, 2 Dec 2005 20:26:12 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1549_715fa6e6_6326_11da_8aae_00304811fd80; Fri, 02 Dec 2005 20:26:12 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB2BNgFS032397; Fri, 2 Dec 2005 20:25:51 +0900 Message-Id: <6.0.0.20.2.20051202184738.070908f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 02 Dec 2005 18:48:23 +0900 To: Harald Tveit Alvestrand From: Martin Duerst Subject: Re: [IMA] DRAFT minutes from IEE BOF In-Reply-To: <438D3EF0.3050908@icu.ac.kr> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Harald Tveit Alvestrand wrote: > 5. Downgrading, draft-yoneya-ima-downgrade - K. Fujiwarea Fujiwarea -> Fujiwara. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 02 06:26:52 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 1Ei940-00064r-8y; Fri, 02 Dec 2005 06:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei93y-00064j-Q8 for ima@megatron.ietf.org; Fri, 02 Dec 2005 06:26:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09862 for ; Fri, 2 Dec 2005 06:26:03 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei9Od-00031E-Sw for ima@ietf.org; Fri, 02 Dec 2005 06:48:12 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jB2BQdu29843; Fri, 2 Dec 2005 20:26:39 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1507_81a4edd6_6326_11da_9cd7_00304811fd80; Fri, 02 Dec 2005 20:26:39 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB2BNgFU032397; Fri, 2 Dec 2005 20:25:51 +0900 Message-Id: <6.0.0.20.2.20051202185217.0700ead0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 02 Dec 2005 19:05:00 +0900 To: ima@ietf.org From: Martin Duerst In-Reply-To: <438D3EF0.3050908@icu.ac.kr> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Jamie Zawinski , Larry Masinter Subject: [IMA] URIs/IRIs 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 IEE BOF participants, As some of you may know, I'm working on an update of the 'mailto:' URI RFC to bring it more in line with newer practice, in particular IRIs. The latest draft can be found at: http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt There are still a few open issues/comments that need to be addressed. I have tried to make this draft forward-compatible with any future solution to the internationalization of email addresses (in particular, the LHS). Given that the current draft is using UTF-8 for compatibility with IRIs, and given that the proposed work in the charter is going into the direction of UTF-8, this should work out fine. But it may make sense for you to have a look at the draft, both for technical issues as well as with respect to the proposed charter. With respect to the charter, I can see various solutions: 1) There is no need to coordinate 2) The draft can go ahead as an individual submission, but there should be some coordination, maybe put down in the charter. 3) The draft can be an individual submission, but should be delayed until the solution being worked on is clearer. 4) The draft should become part of chartered WG. My preference is somewhere around 2). Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 02 09:05:58 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 1EiBXy-0007O9-4Z; Fri, 02 Dec 2005 09:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiBXw-0007NB-0F for ima@megatron.ietf.org; Fri, 02 Dec 2005 09:05:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27033 for ; Fri, 2 Dec 2005 09:05:08 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiBsd-0000At-6j for ima@ietf.org; Fri, 02 Dec 2005 09:27:19 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EiBXi-000NeC-I9; Fri, 02 Dec 2005 09:05:42 -0500 Date: Fri, 02 Dec 2005 09:05:42 -0500 From: John C Klensin To: Martin Duerst , ima@ietf.org Subject: Re: [IMA] URIs/IRIs Message-ID: In-Reply-To: <6.0.0.20.2.20051202185217.0700ead0@localhost> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <6.0.0.20.2.20051202185217.0700ead0@localhost> 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: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Jamie Zawinski , Scott Hollenbeck , Larry Masinter 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 Martin, I've taken the liberty of copying Ted and Scott, since I'm not sure they both are on the mailing list. Let me give you my take on this... We need to get a charter approved by the IESG. Until we do, this group is just the outgrowth of a design team and can't really say anything definitive. I've been preoccupied since IETF with trying to get some things out vis-a-vis the ICANN meeting, but should be able to sit with the minutes in one hand and the charter in the other over this weekend and then work with Harald to get a revised draft posted early next week. I think we can reasonably make something like "check the general design of the framework and SMTP extensions document and verify that their syntax assumptions and those of the IRI draft are consistent" the WG's first work item, with a very short timeframe. While I assume that there will be some tuning of the document, I hope we can lock down framework and syntax quickly. The notion that should be possible was reinforced by the BOF: all of the controversy seems to be about headers, indications of UTF-8 presence in the headers and how it (or they) are handled, downgrading and support for it, and a collection of fine details. I think that falls somewhere between your (2) and your (3). That said, it would clearly be up to the IESG, but I have trouble seeing how, once this work is started, you will be able to publish a standards-track IRI mailto document without a normative reference to it :-( john p.s. UTF-8 was chosen for the LHS (and, optionally, the RHS) for compatibility with RFC 2821 given UTF-8's upward compatibility with ASCII and in conformance with RFC 2277. "Compatibility with IRIs" was, at best, a secondary consideration. --On Friday, 02 December, 2005 19:05 +0900 Martin Duerst wrote: > Dear IEE BOF participants, > > As some of you may know, I'm working on an update of the > 'mailto:' URI RFC to bring it more in line with newer > practice, in particular IRIs. The latest draft can be > found at: > http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01 > .txt > There are still a few open issues/comments that > need to be addressed. > > I have tried to make this draft forward-compatible with > any future solution to the internationalization of email > addresses (in particular, the LHS). Given that the current > draft is using UTF-8 for compatibility with IRIs, and > given that the proposed work in the charter is going into > the direction of UTF-8, this should work out fine. > But it may make sense for you to have a look at the draft, > both for technical issues as well as with respect to the > proposed charter. > > With respect to the charter, I can see various solutions: > 1) There is no need to coordinate > 2) The draft can go ahead as an individual submission, but > there should be some coordination, maybe put down in > the charter. > 3) The draft can be an individual submission, but should > be delayed until the solution being worked on is clearer. > 4) The draft should become part of chartered WG. > > My preference is somewhere around 2). > > Regards, Martin. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 02 23:06:17 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 1EiOfB-0005Fb-7x; Fri, 02 Dec 2005 23:06:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiOf9-0005Dy-8S for ima@megatron.ietf.org; Fri, 02 Dec 2005 23:06:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13565 for ; Fri, 2 Dec 2005 23:05:26 -0500 (EST) Received: from [159.226.7.151] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EiOzS-0000yE-EL for ima@ietf.org; Fri, 02 Dec 2005 23:27:45 -0500 Received: (eyou send program); Sat, 03 Dec 2005 12:04:42 +0800 Message-ID: <333582682.26046@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Sat, 03 Dec 2005 12:04:42 +0800 Message-ID: <004801c5f7be$cd1883f0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "John C Klensin" References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126><438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net><78EF5B4A20A4F218B6968ABF@scan.jck.com> <333385780.00314@cnnic.cn> Subject: Re: [IMA] Re: Header for stored messages Date: Sat, 3 Dec 2005 12:05:30 +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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============2014363474==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============2014363474== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ3JvY2tlciIgPGRo YzJAZGNyb2NrZXIubmV0Pg0KVG86ICJKb2huIEMgS2xlbnNpbiIgPGtsZW5zaW5AamNrLmNvbT4N CkNjOiA8aW1hQGlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDAxLCAyMDA1IDQ6 NDggQU0NClN1YmplY3Q6IFtJTUFdIFJlOiBIZWFkZXIgZm9yIHN0b3JlZCBtZXNzYWdlcw0KDQoN Cj4gDQo+IA0KPiA+IEluIHRoZW9yeSwgdGhlIGNvbnRlbnQgb2YgbWVzc2FnZXMgaW4gdHJhbnNp dCBpcyBub3QgZXhhbWluZWQgYXQNCj4gPiBhbGwsIHNvIGl0IG1ha2VzIGxpdHRsZSBkaWZmZXJl bmNlIHdoYXQgaXMgaW4gdGhlIGhlYWRlcnMgZXhjZXB0DQo+ID4gYXQgdGhlIGVuZHBvaW50cy4g IA0KPiANCj4gUGFydHMgb2YgdHJhbnNpdCBhcmUgcGFja2FnaW5nIGFuZCB1bnBhY2thZ2luZyBm b3IgcG9zdGluZyBhbmQgZGVsaXZlcnkuDQo+IA0KPiBUaGVzZSBhcmUgZXhhbXBsZXMgb2YgbmVl ZGluZyBzZWxmLWxhYmVsaW5nLg0KPiANCj4gDQo+ID4gSSdtIGFsc28gcmVtaW5kZWQgb2YgdGhl IGZhbW91cyAiTUlNRS1WZXJzaW9uOiAxLjAiIGhlYWRlcg0KPiA+IGZpZWxkLCB3aGljaCB3YXMg c3VwcG9zZWQgdG8gZGVub3RlIGEgbmV3IHdheSBvZiBpZGVudGlmeWluZw0KPiA+IGhlYWRlcnMg KHBhcnRpY3VsYXJseSB0aGUgcHJlc2VuY2UgYW5kIGludGVycHJldGF0aW9uIG9mDQo+ID4gIkNv bnRlbnQtdHlwZToiKSBhcyB3ZWxsIGFzIGEgZm9ybWF0dGVkIGJvZHkuICBOb3csIGl0IHdhcw0K PiA+IGFyZ3VhYmx5IG5lY2Vzc2FyeSBiZWNhdXNlICJDb250ZW50LXR5cGU6IiB3YXMgYWxyZWFk eSBpbiB1c2UNCj4gDQo+IFJpZ2h0LiAgU2VsZi1sYWJlbGluZy4NCj4gDQo+IFdlIGNhbiBxdWli YmxlIGFib3V0IHRoZSBob3csIGJ1dCB0aGUgbWFpbiBwb2ludCBpcyB0aGF0IGEgbWVzc2FnZSB3 aXRoIGENCj4gZnJlZS10ZXh0IGJvZHkgaGFzIGEgZGlmZmVyZW50IGxhYmVsaW5nIHRoYW4gYSBt ZXNzYWdlIHdpdGggYSBNSU1FIGJvZHksIHNvDQo+IHRoYXQgYSBwcm9jZXNzb3IgY2FuIGtub3cg d2hpY2ggbW9kZWwgdG8gYXBwbHkuDQo+IA0KPiANCj4gPiBNb3JlIGdlbmVyYWxseSwgaXMgdGhp cyBhIGhlYWRlciB0aGF0IHNob3VsZCBiZSByZXF1aXJlZCB0byBiZQ0KPiA+IHB1c2hlZCBpbnRv IHRoZSBtZXNzYWdlIG9uIGZpbmFsIGRlbGl2ZXJ5IG9yIGFzIHBhcnQgb2YgYQ0KPiA+IGdhdGV3 YXkgcHJvY2Vzcywgbm90IHVubGlrZSAiUmV0dXJuLXBhdGg6Ii4gIEFuZCwgaWYgbm90LCB3aGF0 DQo+ID4gaXMgdGhlIHZhbHVlIG9mIGhhdmluZyBpdCBpbiB0cmFuc2l0Pw0KPiANCj4gWWVhaCwg SSBzdXBwb3NlIHdlIGNvdWxkIHF1aWJibGUgd2hldGhlciB0byBoYXZlIGl0IG9ubHkgaW4gdGhl IFNNVFANCj4gY29tbWFuZHMgZHVyaW5nIHRyYW5zaXQsIGJ1dCBpbiB0aGUgbWVzc2FnZSBpdHNl bGYgb3RoZXJ3aXNlLCBidXQgbXkgbWFpbg0KPiBjb25jZXJuIGlzIHJvYnVzdG5lc3MgaW4gdGhl IGFic2VuY2Ugb2YgY29udGV4dC4NCj4gDQoNClllcywgaW4gb3JkZXIgdG8gZ2V0IHRoZSByb2J1 c3RuZXNzIGluIHRoZSBhYnNlbmNlIG9mIGNvbnRleHQsICBpdCBtYXkgYmUgYSBpc3N1ZSB3ZSBz aG91bGQgY29uc2lkZXIgdGhhdCB3aGV0aGVyIG9yIG5vdCB3ZSBuZWVkIGEgbWVjaGFuaXNtIG9y IHNvbWUgaW5kaWNhdG9yIHRvIGRpc3Rpbmd1aXNoIG9yIHJlY29nbml6ZSAgd2V0aGVyIHRoZSBt ZXNzYWdlIGlzIGEgInN0b3JlZCIgbWVzc2FnZSBiZSBvZiBuZXcgZm9ybWF0KGkuZS4gSUVFIGNv bXBsaWFudCkgb3Igb2xkIG9uZSAgKGkuZS4gUkZDIDgyMiBjb21wbGlhbnQpLg0KDQoNCllhbyBK aWFua2FuZw0KDQoNCg0KDQoNCg0KPiBkLw0KPiAtLSANCj4gDQo+IERhdmUgQ3JvY2tlcg0KPiBC cmFuZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmcNCj4gPGh0dHA6Ly9iYml3Lm5ldD4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWls aW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ltYQ0KPiA= --===============2014363474== 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 --===============2014363474==-- From ima-bounces@ietf.org Fri Dec 02 23:40:41 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 1EiPCT-0005hS-91; Fri, 02 Dec 2005 23:40:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiPCR-0005gS-Gg for ima@megatron.ietf.org; Fri, 02 Dec 2005 23:40:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16658 for ; Fri, 2 Dec 2005 23:39:50 -0500 (EST) Received: from [159.226.7.151] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EiPWl-000259-6j for ima@ietf.org; Sat, 03 Dec 2005 00:02:10 -0500 Received: (eyou send program); Sat, 03 Dec 2005 12:39:08 +0800 Message-ID: <333584748.09895@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Sat, 03 Dec 2005 12:39:08 +0800 Message-ID: <009501c5f7c3$9c46dba0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "Martin Duerst" References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126><438D3EF0.3050908@icu.ac.kr> <333522948.21900@cnnic.cn> Subject: Re: [IMA] URIs/IRIs Date: Sat, 3 Dec 2005 12:39:56 +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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Jamie Zawinski , Larry Masinter 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="===============1491713434==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1491713434== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcnRpbiBEdWVyc3QiIDxk dWVyc3RAaXQuYW95YW1hLmFjLmpwPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpDYzogIkphbWllIFph d2luc2tpIiA8and6QGp3ei5vcmc+OyAiTGFycnkgTWFzaW50ZXIiIDxtYXNpbnRlckBhZG9iZS5j b20+DQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDAyLCAyMDA1IDY6MDUgUE0NClN1YmplY3Q6IFtJ TUFdIFVSSXMvSVJJcw0KDQoNCj4gRGVhciBJRUUgQk9GIHBhcnRpY2lwYW50cywNCj4gDQo+IEFz IHNvbWUgb2YgeW91IG1heSBrbm93LCBJJ20gd29ya2luZyBvbiBhbiB1cGRhdGUgb2YgdGhlDQo+ ICdtYWlsdG86JyBVUkkgUkZDIHRvIGJyaW5nIGl0IG1vcmUgaW4gbGluZSB3aXRoIG5ld2VyDQo+ IHByYWN0aWNlLCBpbiBwYXJ0aWN1bGFyIElSSXMuIFRoZSBsYXRlc3QgZHJhZnQgY2FuIGJlDQo+ IGZvdW5kIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1k dWVyc3QtbWFpbHRvLWJpcy0wMS50eHQNCj4gVGhlcmUgYXJlIHN0aWxsIGEgZmV3IG9wZW4gaXNz dWVzL2NvbW1lbnRzIHRoYXQNCj4gbmVlZCB0byBiZSBhZGRyZXNzZWQuDQo+IA0KPiBJIGhhdmUg dHJpZWQgdG8gbWFrZSB0aGlzIGRyYWZ0IGZvcndhcmQtY29tcGF0aWJsZSB3aXRoDQo+IGFueSBm dXR1cmUgc29sdXRpb24gdG8gdGhlIGludGVybmF0aW9uYWxpemF0aW9uIG9mIGVtYWlsDQo+IGFk ZHJlc3NlcyAoaW4gcGFydGljdWxhciwgdGhlIExIUykuIEdpdmVuIHRoYXQgdGhlIGN1cnJlbnQN Cj4gZHJhZnQgaXMgdXNpbmcgVVRGLTggZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBJUklzLCBhbmQN Cj4gZ2l2ZW4gdGhhdCB0aGUgcHJvcG9zZWQgd29yayBpbiB0aGUgY2hhcnRlciBpcyBnb2luZyBp bnRvDQo+IHRoZSBkaXJlY3Rpb24gb2YgVVRGLTgsIHRoaXMgc2hvdWxkIHdvcmsgb3V0IGZpbmUu DQoNClRoZSBzb2x1dGlvbiBzaG91bGQgYmUgdGhlIGRpcmVjdGlvbiBvZiBVVEYtOC4NCg0KDQo+ IEJ1dCBpdCBtYXkgbWFrZSBzZW5zZSBmb3IgeW91IHRvIGhhdmUgYSBsb29rIGF0IHRoZSBkcmFm dCwNCj4gYm90aCBmb3IgdGVjaG5pY2FsIGlzc3VlcyBhcyB3ZWxsIGFzIHdpdGggcmVzcGVjdCB0 byB0aGUNCj4gcHJvcG9zZWQgY2hhcnRlci4NCj4gDQo+IFdpdGggcmVzcGVjdCB0byB0aGUgY2hh cnRlciwgSSBjYW4gc2VlIHZhcmlvdXMgc29sdXRpb25zOg0KPiAxKSBUaGVyZSBpcyBubyBuZWVk IHRvIGNvb3JkaW5hdGUNCj4gMikgVGhlIGRyYWZ0IGNhbiBnbyBhaGVhZCBhcyBhbiBpbmRpdmlk dWFsIHN1Ym1pc3Npb24sIGJ1dA0KPiAgICAgdGhlcmUgc2hvdWxkIGJlIHNvbWUgY29vcmRpbmF0 aW9uLCBtYXliZSBwdXQgZG93biBpbg0KPiAgICAgdGhlIGNoYXJ0ZXIuDQo+IDMpIFRoZSBkcmFm dCBjYW4gYmUgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uLCBidXQgc2hvdWxkDQo+ICAgICBiZSBk ZWxheWVkIHVudGlsIHRoZSBzb2x1dGlvbiBiZWluZyB3b3JrZWQgb24gaXMgY2xlYXJlci4NCj4g NCkgVGhlIGRyYWZ0IHNob3VsZCBiZWNvbWUgcGFydCBvZiBjaGFydGVyZWQgV0cuDQoNCg0KV2hh dCB5b3VyIGNvbmNlcm4gaXMgbWF5IGFsc28gYmUgYSBjb25jZXJuIG9mIEFyZWFkIGRpcmVjdG9y cyBvciBJRVNHLg0KSWYgeW91ciBkcmFmdCBpcyBnb2luZyB0byBSRkMsIHRvIG1ha2UgeW91ciBk b2N1bWVudCBjb21wYXRpYmxlIHdpdGggdGhlIGZ1dHVyZSBwb3NzaWJsZSBJRUUgc3RhbmRhcmQs DQppdCBpcyBiZXR0ZXIgdGhhdCB0aGUgcGFydCByZWxhdGluZyB0byBJRUUgaW4geW91ciBkb2N1 bWVudCBpcyByZWZlcmVuY2VkIHRvIHRoZSBmdXR1cmUgSUVFIHN0YW5kYXJkLg0KaWYgeW91ciBk cmFmdCBpcyBqdXN0IGEgZHJhZnQsIHNpbmNlIG91ciBnZW5lcmFsIGRpcmVjdGlvbiBpcyBzYW1l ICAodXRmLTgpLCB5b3UgbWF5IGRvIHNvbWV0aGluZyBiZXR3ZWVuIHRoZSBzb2x1dGlvbiAyIGFu ZCBzb2x1dGlvbiAzLg0KDQp0aGFua3MuDQpZYW8gSmlhbmthbmcNCkNOTklDDQoNCg0KPiANCj4g TXkgcHJlZmVyZW5jZSBpcyBzb21ld2hlcmUgYXJvdW5kIDIpLg0KPiANCj4gUmVnYXJkcywgICAg TWFydGluLiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4g --===============1491713434== 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 --===============1491713434==-- From ima-bounces@ietf.org Mon Dec 05 05:24:12 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 1EjDW0-0002ka-GB; Mon, 05 Dec 2005 05:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjDVy-0002kN-Bh for ima@megatron.ietf.org; Mon, 05 Dec 2005 05:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27076 for ; Mon, 5 Dec 2005 05:23:19 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjDrC-000315-Cm for ima@ietf.org; Mon, 05 Dec 2005 05:46:08 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jB5ANSd15789; Mon, 5 Dec 2005 19:23:29 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 36ae_2d74de6a_6579_11da_8cae_00304811fd80; Mon, 05 Dec 2005 19:23:28 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB5ALclc013720; Mon, 5 Dec 2005 19:22:09 +0900 Message-Id: <6.0.0.20.2.20051205172320.05818260@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 05 Dec 2005 17:37:42 +0900 To: John C Klensin , ima@ietf.org From: Martin Duerst Subject: Re: [IMA] URIs/IRIs In-Reply-To: References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <6.0.0.20.2.20051202185217.0700ead0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Jamie Zawinski , Scott Hollenbeck , Larry Masinter 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 At 23:05 05/12/02, John C Klensin wrote: >Martin, > >I've taken the liberty of copying Ted and Scott, since I'm not >sure they both are on the mailing list. Thanks. >Let me give you my take on this... > >We need to get a charter approved by the IESG. Until we do, >this group is just the outgrowth of a design team and can't >really say anything definitive. I've been preoccupied since >IETF with trying to get some things out vis-a-vis the ICANN >meeting, but should be able to sit with the minutes in one hand >and the charter in the other over this weekend and then work >with Harald to get a revised draft posted early next week. Of course I know this group isn't yet chartered, but that's exactly why I wrote this mail. >I think we can reasonably make something like "check the general >design of the framework and SMTP extensions document and verify >that their syntax assumptions and those of the IRI draft are Maybe just a detail: Please don't confuse the IRI spec (RFC 3987, Proposed Standard) and draft-duerst-mailto-bis-01, a draft for an update of the mailto: scheme. >consistent" the WG's first work item, with a very short >timeframe. While I assume that there will be some tuning of >the document, I hope we can lock down framework and syntax >quickly. The notion that should be possible was reinforced by >the BOF: all of the controversy seems to be about headers, >indications of UTF-8 presence in the headers and how it (or >they) are handled, downgrading and support for it, and a >collection of fine details. > >I think that falls somewhere between your (2) and your (3). > >That said, it would clearly be up to the IESG, but I have >trouble seeing how, once this work is started, you will be able >to publish a standards-track IRI mailto document without a >normative reference to it :-( Again, first the details: draft-duerst-mailto-bis-01 is a mailto URI document, not a mailto IRI document. But it is written so that it works well with IRIs. So what you are saying is that we'd better finish up the mailto URI update before the new WG is chartered, or we have to wait for quite a while :-). > john > >p.s. UTF-8 was chosen for the LHS (and, optionally, the RHS) for >compatibility with RFC 2821 given UTF-8's upward compatibility >with ASCII and in conformance with RFC 2277. "Compatibility with >IRIs" was, at best, a secondary consideration. That's fine. The mailto: URI needs to use (%-encoding based on) UTF-8 for compatibility with IRIs. But there is no requirement that URIs in a certain scheme and the underlying protocol use the same encoding; the classical example is the imap: URI scheme uses UTF-8 for compatibility with IRIs, but the IMAP protocol uses a modified version of UTF-7 for compatibility with very old file systems. Of course, using UTF-8 in both places makes things easier. And in both places, the reason for using UTF-8 is the same: the upwards compatibity with ASCII. So this is more than just a coincidence. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 05 09:10:48 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 1EjH3I-0003mD-60; Mon, 05 Dec 2005 09:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjH3F-0003kq-Fa for ima@megatron.ietf.org; Mon, 05 Dec 2005 09:10:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22784 for ; Mon, 5 Dec 2005 09:09:54 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjHOX-0002sL-6A for ima@ietf.org; Mon, 05 Dec 2005 09:32:46 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EjH33-00085J-5N; Mon, 05 Dec 2005 09:10:33 -0500 Date: Mon, 05 Dec 2005 09:10:33 -0500 From: John C Klensin To: Martin Duerst , ima@ietf.org Subject: Re: [IMA] URIs/IRIs Message-ID: <1D5173079C8D732E930C685A@scan.jck.com> In-Reply-To: <6.0.0.20.2.20051205172320.05818260@localhost> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <6.0.0.20.2.20051202185217.0700ead0@localhost> <6.0.0.20.2.20051205172320.05818260@localhost> 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Jamie Zawinski , Scott Hollenbeck , Larry Masinter 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 Monday, 05 December, 2005 17:37 +0900 Martin Duerst wrote: > Of course, using UTF-8 in both places makes things easier. > And in both places, the reason for using UTF-8 is the same: > the upwards compatibity with ASCII. So this is more than > just a coincidence. That was the key point, and really the only point, I was trying to make. I think some of us should just look at the thing, soon, and get comments to you, rather than tying things up in formalities. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 05 21:53:48 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 1EjSxg-0007Xc-LY; Mon, 05 Dec 2005 21:53:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjSxf-0007XX-Lu for ima@megatron.ietf.org; Mon, 05 Dec 2005 21:53:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23191 for ; Mon, 5 Dec 2005 21:52:55 -0500 (EST) Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjTJ3-0006AO-VU for ima@ietf.org; Mon, 05 Dec 2005 22:15:55 -0500 Received: from jeffnb (pc092.twnic.net.tw [211.72.211.92]) by twnic.net.tw (8.13.5/8.13.5) with ESMTP id jB62rUWE010863; Tue, 6 Dec 2005 10:53:33 +0800 Message-Id: <200512060253.jB62rUWE010863@twnic.net.tw> From: "Jeff Yeh" To: , "'John C Klensin'" Subject: RE: [IMA] Re: Header for stored messages Date: Tue, 6 Dec 2005 10:59:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <438E1036.2070706@dcrocker.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcX19Df7ZXNPodoZT3qoy5I4NTwUNgEGQtdg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 It seems to me that to have a labeling mechanism is better. And since the sender would like to sent out the message in UTF8, it make most sense to require sender to add the label. The problem is that are we going to 1. introduce new header like "IEE-Version: 1.0" 2. or use "MIME-Version: 2.0" 3. or more meaningful "MIME-Content-Type" I preferred 3>1>2. However, if we do any of these 3 option, we have to take more action when downgrading occurs. Because the header are not UTF8 anymore. Jeff Yeh TWNIC > -----Original Message----- > From: ima-bounces@ietf.org [mailto:ima-bounces@ietf.org] On > Behalf Of Dave Crocker > Sent: Thursday, December 01, 2005 4:49 AM > To: John C Klensin > Cc: ima@ietf.org > Subject: [IMA] Re: Header for stored messages > > > > > In theory, the content of messages in transit is not > examined at all, > > so it makes little difference what is in the headers except at the > > endpoints. > > Parts of transit are packaging and unpackaging for posting > and delivery. > > These are examples of needing self-labeling. > > > > I'm also reminded of the famous "MIME-Version: 1.0" header field, > > which was supposed to denote a new way of identifying headers > > (particularly the presence and interpretation of > > "Content-type:") as well as a formatted body. Now, it was arguably > > necessary because "Content-type:" was already in use > > Right. Self-labeling. > > We can quibble about the how, but the main point is that a > message with a free-text body has a different labeling than a > message with a MIME body, so that a processor can know which > model to apply. > > > > More generally, is this a header that should be required to > be pushed > > into the message on final delivery or as part of a gateway process, > > not unlike "Return-path:". And, if not, what is the value > of having > > it in transit? > > Yeah, I suppose we could quibble whether to have it only in > the SMTP commands during transit, but in the message itself > otherwise, but my main concern is robustness in the absence > of context. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 07:07:21 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 1EjbbN-0005rP-J3; Tue, 06 Dec 2005 07:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjbbM-0005rK-JB for ima@megatron.ietf.org; Tue, 06 Dec 2005 07:07:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18048 for ; Tue, 6 Dec 2005 07:06:29 -0500 (EST) Received: from lon-mail-2.gradwell.net ([193.111.201.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejbwq-0007EK-Cl for ima@ietf.org; Tue, 06 Dec 2005 07:29:33 -0500 Received: from host81-144-64-244.midband.mdip.bt.net ([81.144.64.244]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43957ee2.17a44.2af for ima@ietf.org; Tue, 6 Dec 2005 12:06:58 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB5I1AL08164 for ; Mon, 5 Dec 2005 18:01:11 GMT To: ima@ietf.org Subject: Re: [IMA] URIs/IRIs References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <6.0.0.20.2.20051202185217.0700ead0@localhost> <6.0.0.20.2.20051205172320.05818260@localhost> <1D5173079C8D732E930C685A@scan.jck.com> Message-ID: Date: Mon, 05 Dec 2005 18:01:03 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <1D5173079C8D732E930C685A@scan.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA18048 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 Mon, 05 Dec 2005 14:10:33 -0000, John C Klensin wrot= e: > That was the key point, and really the only point, I was trying > to make. > > I think some of us should just look at the thing, soon, and get > comments to you, rather than tying things up in formalities. The most important thing to decide, but one not likely to be clear for =20 some time, arises from the proposal to allow an alternatate delivery =20 address in the RCPT TO: command. Nobody has really indicated how these tw= o =20 addresses get generated. But it would seem desirable to be able to =20 indicate in a mailto: URI "this is my address if you are sending mail to = =20 my I18N address, but if your system cannot manage that, then please send = =20 to this alterative (but not to both)". Now there are many notations in which that might be expressed, but we als= o =20 need to consider what would appear in the To: and Reply-To: headers of a = =20 message, because the same problem arises there too. For example, if you want a gold-plated solution, you might invent a new =20 format for , such as <=E5lice@troms=F6.edu|alice@tromso.edu> (Harald can suggest more plausible Norwegian examples). OTOH, that might be considered too big an upgrade of RFC 2822 for us to b= e =20 making, though it would lead to an obvious corresponding upgrade for the = =20 mailto: URI. NOTE: "=E5lice" above is written in ISO-8859-1, because that is what my =20 mailer does, but clearly the corresponding UTF-8 was intended. --=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 Tue Dec 06 08:06:29 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 1EjcWb-0007es-Ah; Tue, 06 Dec 2005 08:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcWZ-0007dM-OR for ima@megatron.ietf.org; Tue, 06 Dec 2005 08:06:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25545 for ; Tue, 6 Dec 2005 08:05:36 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejcs3-00010M-Km for ima@ietf.org; Tue, 06 Dec 2005 08:28:41 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5981F259702; Tue, 6 Dec 2005 14:05:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18846-03; Tue, 6 Dec 2005 14:05:34 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7EB842596EF; Tue, 6 Dec 2005 14:05:34 +0100 (CET) Date: Tue, 06 Dec 2005 14:08:28 +0100 From: Harald Tveit Alvestrand To: dcrocker@bbiw.net, John C Klensin Subject: Re: [IMA] Re: Header for stored messages Message-ID: <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> In-Reply-To: <438E1036.2070706@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> 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: 50a516d93fd399dc60588708fd9a3002 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 --On onsdag, november 30, 2005 12:48:54 -0800 Dave Crocker wrote: >> I'm also reminded of the famous "MIME-Version: 1.0" header >> field, which was supposed to denote a new way of identifying >> headers (particularly the presence and interpretation of >> "Content-type:") as well as a formatted body. Now, it was >> arguably necessary because "Content-type:" was already in use > > Right. Self-labeling. > > We can quibble about the how, but the main point is that a message with a > free-text body has a different labeling than a message with a MIME body, > so > that a processor can know which model to apply. This is actually an example of how our standards for self-identifying stuff often turn out not to work as well as we'd like them to, but standards for container-identifying-content works fairly well. Viz. - the MIME-Version is an example of self-labelling, and has not worked well. The content-type is an example of a label outside the labelled object, as is the protocol identifier in IP packets, the port number (an example of a "weak" label, btw - it's often misleading) and so on. The HTTP version number (GET /URL/goes/here HTTP/1.1) turned out to be in the wrong place when we wanted to modify the way URLs were encoded - so we added the "Host: " header hack instead, and the "URL=*" hack for the case of shttp (another good idea lost in history...) The version number in the IP header, on the other hand, seems to have worked reasonably well - the container label says "some kind of IP", and one of the first few bytes of the header says which version it is. My worry is the same as was voiced about the SMTP MTA: All legal "legacy" SMTP messages will be legal IMA messages, and there will be implementations that need to do no more to support IMA than to stop checking for the 8th bit of data - apart from the gateway scenario. So.... what is the scenario where the processor needs to apply a different processing to an IMA-labelled message, AND can safely assume that all non-IMA-labelled messages are "legacy" conformant? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 11:36:57 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 1EjfoH-0005BL-GY; Tue, 06 Dec 2005 11:36:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfoF-0005Ac-NZ for ima@megatron.ietf.org; Tue, 06 Dec 2005 11:36:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21091 for ; Tue, 6 Dec 2005 11:36:05 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejg9m-0008W3-Nw for ima@ietf.org; Tue, 06 Dec 2005 11:59:11 -0500 Received: from [172.17.196.249] ([65.198.0.67]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jB6GbDmT013701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Dec 2005 08:37:16 -0800 Message-ID: <4395BE10.5050402@dcrocker.net> Date: Tue, 06 Dec 2005 08:36:32 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> In-Reply-To: <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net 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 sigh. > Viz. - the MIME-Version is an example of self-labelling, and has not > worked well. It hasn't? If you mean it does not simply, accurately and reliable distinguish between MIME-structured email body content, and free-form lines of ASCII text content, this is the first I have heard of its failing. You need to substantiate the claim, since simply, accurately and reliably distinguishing between two forms of data is the reason I gave for needing a context-independent label. (Reference to the problem of having an unchangeable version number is quite irrelevant to the current discussion.) > The content-type is an example of a label outside the > labelled object, MIME was offered as an example of distinguishing a characteristic of an email message body. The first Content-type is within the email message header, so it is NOT outside the labeled object. > as is the protocol identifier in IP packets, the port > number (an example of a "weak" label, btw - it's often misleading) and > so on. Since Content-type and these additional examples have no goal of being used outside of their immediate context -- and since the point I made was specifically about identification outside of the transit context -- these examples are irrelevant to the discussion. > My worry is the same as was voiced about the SMTP MTA: All legal > "legacy" SMTP messages will be legal IMA messages, and there will be > implementations that need to do no more to support IMA than to stop > checking for the 8th bit of data - apart from the gateway scenario. > > So.... what is the scenario where the processor needs to apply a > different processing to an IMA-labelled message, AND can safely assume > that all non-IMA-labelled messages are "legacy" conformant? A nicely useful question. A shame it was obfuscated by the earlier portions of the message. The example I'll suggest is a message standing alone in a file, after receipt. We already have an example of having to correct this problem: the Return-Path header field. It corrects the error of having that information only be in the transit context (SMTP envelope) and not in the stand-alone email object. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 11:57:51 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 1Ejg8V-0002wM-S8; Tue, 06 Dec 2005 11:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejg8S-0002vX-Co for ima@megatron.ietf.org; Tue, 06 Dec 2005 11:57:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23767 for ; Tue, 6 Dec 2005 11:56:57 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjgTy-0000xO-GW for ima@ietf.org; Tue, 06 Dec 2005 12:20:03 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D257325971D; Tue, 6 Dec 2005 17:56:58 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25017-06; Tue, 6 Dec 2005 17:56:54 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id C3EAC259717; Tue, 6 Dec 2005 17:56:54 +0100 (CET) Date: Tue, 06 Dec 2005 17:59:49 +0100 From: Harald Tveit Alvestrand To: dcrocker@bbiw.net Subject: Re: [IMA] Re: Header for stored messages Message-ID: <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> In-Reply-To: <4395BE10.5050402@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> 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: 5011df3e2a27abcc044eaa15befcaa87 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 --On tirsdag, desember 06, 2005 08:36:32 -0800 Dave Crocker wrote: > > sigh. > >> Viz. - the MIME-Version is an example of self-labelling, and has not >> worked well. > > It hasn't? > > If you mean it does not simply, accurately and reliable distinguish > between > MIME-structured email body content, and free-form lines of ASCII text > content, this is the first I have heard of its failing. People who write UAs for a living will have to speak to whether they actually check it. It was supposed to give the rule for parsing the content-type header, but can occur before or after the content-type header, so if they actually use it for that, it means that they have to delay content-type header processing until after the whole header is parsed. Is that how people's code works? > You need to substantiate the claim, since simply, accurately and reliably > distinguishing between two forms of data is the reason I gave for needing > a context-independent label. > > (Reference to the problem of having an unchangeable version number is > quite > irrelevant to the current discussion.) > > >> The content-type is an example of a label outside the >> labelled object, > > MIME was offered as an example of distinguishing a characteristic of an > email message body. The first Content-type is within the email message > header, so it is NOT outside the labeled object. But the content-type labels the content, not the header. And it's outside the content. >> as is the protocol identifier in IP packets, the port >> number (an example of a "weak" label, btw - it's often misleading) and >> so on. > > Since Content-type and these additional examples have no goal of being > used > outside of their immediate context -- and since the point I made was > specifically about identification outside of the transit context -- these > examples are irrelevant to the discussion. > > >> My worry is the same as was voiced about the SMTP MTA: All legal >> "legacy" SMTP messages will be legal IMA messages, and there will be >> implementations that need to do no more to support IMA than to stop >> checking for the 8th bit of data - apart from the gateway scenario. >> >> So.... what is the scenario where the processor needs to apply a >> different processing to an IMA-labelled message, AND can safely assume >> that all non-IMA-labelled messages are "legacy" conformant? > > A nicely useful question. > > A shame it was obfuscated by the earlier portions of the message. > > The example I'll suggest is a message standing alone in a file, after > receipt. And what scenario do you have where a processor needs to apply a different processing to an IMA-labelled message, standing alone in a file, to what processing it needs to apply to a non-IMA-labelled message, AND can safely assume that all non-IMA-labelled messages, standing alone in a file, are "legacy" conformant? > We already have an example of having to correct this problem: the > Return-Path header field. It corrects the error of having that > information > only be in the transit context (SMTP envelope) and not in the stand-alone > email object. In that case, I think we have a lot of procmail-type scripts that attest to the fact that the information is useful. Note also that in the proposals this week, the transit context (SMTP envelope) has been proposed to NOT contain information about whether a specific message is "IMA" or not. Harald (Personal note: I am in two minds about whether or not a label in the headers is an useful thing. My gut feeling is that it might be, but I haven't seen the clincher argument for it yet - nor have I seen the clincher argument that it's a significant cost and complexity that needs to be avoided.) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 12:51:03 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 1Ejgxz-0008E4-9H; Tue, 06 Dec 2005 12:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejgxy-0008Dw-5O for ima@megatron.ietf.org; Tue, 06 Dec 2005 12:51:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00595 for ; Tue, 6 Dec 2005 12:50:11 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjhJU-0002sr-Jc for ima@ietf.org; Tue, 06 Dec 2005 13:13:18 -0500 Received: from [172.17.196.249] ([65.198.0.67]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jB6HpLNA022873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Dec 2005 09:51:24 -0800 Message-ID: <4395CF70.6020401@dcrocker.net> Date: Tue, 06 Dec 2005 09:50:40 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> In-Reply-To: <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net 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 >>> The content-type is an example of a label outside the >>> labelled object, >> >> MIME was offered as an example of distinguishing a characteristic of an >> email message body. The first Content-type is within the email message >> header, so it is NOT outside the labeled object. > > But the content-type labels the content, not the header. And it's > outside the content. But it is not outside the message. Your point is not magically made helpful by your re-defining the question. Self-labeling of message content was the stated task. Hence the issue is whether the label needs to be within the message, not whether it needs to be within a particular portion of the message. For your example to be useful, you would need to show that the type of the data is correctly identified when that data are outside the message, yet still be identified correctly. To that end, the translation from content-type to the field extension of a specific piece of mail body content -- stored on its own and without the message -- would be a representative case. In fact that is done with reasonable success, though certainly not always correct. >> The example I'll suggest is a message standing alone in a file, after >> receipt. > > And what scenario do you have where a processor needs to apply a > different processing to an IMA-labelled message, standing alone in a > file, to what processing it needs to apply to a non-IMA-labelled > message, AND can safely assume that all non-IMA-labelled messages, > standing alone in a file, are "legacy" conformant? Perhaps you have not noticed that it is quite common to have Internet Mail stored in files in a form that is identical -- or, at least, very close -- to the form used in transit? I have used quite a number of MUAs in recent years and they have all retained the original form. >> We already have an example of having to correct this problem: the >> Return-Path header field. It corrects the error of having that >> information >> only be in the transit context (SMTP envelope) and not in the stand-alone >> email object. > > In that case, I think we have a lot of procmail-type scripts that attest > to the fact that the information is useful. Harald, you have again missed my point, though I could have sworn it was made very clearly: Return-path is a retrofit. It was added later, specifically because having that information be only in envelope was not sufficient. The envelope is lost after transit, unless its information is added to the message. It needs to be associated with the message data directly. In other words, Harald, Return-path is an example of needing to have the information available outside the context of the transit. As for procmail, the fact that some software uses the envelope information does not have any relevance at all to this discussion. No one said the envelope information was not useful. So your example does not demonstrate that the information is not needed after transit. (Really, Harald, I strongly suggest you get a copy of "Crimes Against Logic" and read it carefully.) d/ -- Dave Crocker Brandenburg InternetWorking -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 14:37:02 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 1EjicY-0001Uh-DG; Tue, 06 Dec 2005 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjicW-0001UW-Q3 for ima@megatron.ietf.org; Tue, 06 Dec 2005 14:37:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12643 for ; Tue, 6 Dec 2005 14:36:09 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejiy3-0006eI-Jj for ima@ietf.org; Tue, 06 Dec 2005 14:59:17 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 809722596D5; Tue, 6 Dec 2005 20:36:10 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29650-10; Tue, 6 Dec 2005 20:36:05 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FF032596CE; Tue, 6 Dec 2005 20:36:05 +0100 (CET) Date: Tue, 06 Dec 2005 20:39:00 +0100 From: Harald Tveit Alvestrand To: dcrocker@bbiw.net Subject: Re: [IMA] Re: Header for stored messages Message-ID: In-Reply-To: <4395CF70.6020401@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> 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: 057ebe9b96adec30a7efb2aeda4c26a4 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 Dave, I have obtained my copy of "crimes against logic" already (arrived today), and look forward to reading it. And now - could you please answer my question about processing? --On tirsdag, desember 06, 2005 09:50:40 -0800 Dave Crocker wrote: > > >>>> The content-type is an example of a label outside the >>>> labelled object, >>> >>> MIME was offered as an example of distinguishing a characteristic of an >>> email message body. The first Content-type is within the email message >>> header, so it is NOT outside the labeled object. >> >> But the content-type labels the content, not the header. And it's >> outside the content. > > But it is not outside the message. > > > Your point is not magically made helpful by your re-defining the question. > and irony is not made effective by ignoring the division of a message into a header and a content.... these are two pieces, the content-type is in one of them, and the content that it labels is in the other. > Self-labeling of message content was the stated task. Hence the issue is > whether the label needs to be within the message, not whether it needs to > be within a particular portion of the message. > > For your example to be useful, you would need to show that the type of > the data is correctly identified when that data are outside the message, > yet still be identified correctly. To that end, the translation from > content-type to the field extension of a specific piece of mail body > content -- stored on its own and without the message -- would be a > representative case. In fact that is done with reasonable success, > though certainly not always correct. Here, I'm entirely lost about what you intended to say, and its relevance to the previous parts of the thread, so I'll not attempt a response. >>> The example I'll suggest is a message standing alone in a file, after >>> receipt. >> >> And what scenario do you have where a processor needs to apply a >> different processing to an IMA-labelled message, standing alone in a >> file, to what processing it needs to apply to a non-IMA-labelled >> message, AND can safely assume that all non-IMA-labelled messages, >> standing alone in a file, are "legacy" conformant? > > Perhaps you have not noticed that it is quite common to have Internet > Mail stored in files in a form that is identical -- or, at least, very > close -- to the form used in transit? > > I have used quite a number of MUAs in recent years and they have all > retained the original form. I have not questioned that at all. I've asked you (and I ask you again): What scenario do you have where a processor (that is, something that processes a message) needs to apply a different processing to an IMA-labelled message than to a non-IMA-labelled message? This is about *processing* - that is, doing something about a message. Having a message stored in a file is not processing. >>> We already have an example of having to correct this problem: the >>> Return-Path header field. It corrects the error of having that >>> information >>> only be in the transit context (SMTP envelope) and not in the >>> stand-alone email object. >> >> In that case, I think we have a lot of procmail-type scripts that attest >> to the fact that the information is useful. > > Harald, you have again missed my point, though I could have sworn it was > made very clearly: Return-path is a retrofit. It was added later, > specifically because having that information be only in envelope was not > sufficient. The envelope is lost after transit, unless its information > is added to the message. It needs to be associated with the message data > directly. In other words, Harald, Return-path is an example of needing > to have the information available outside the context of the transit. I could have sworn that I was agreeing with you about Return-Path - both the fact that it's useful and the fact that it's a retrofit. Obviously I did not specify clearly enough that I agreed with you on those points. > As for procmail, the fact that some software uses the envelope > information does not have any relevance at all to this discussion. No > one said the envelope information was not useful. So your example does > not demonstrate that the information is not needed after transit. > (Really, Harald, I strongly suggest you get a copy of "Crimes Against > Logic" and read it carefully.) I have, and I will. And can you now please answer my previous question about processing? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 15:45:13 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 1EjjgX-0004qb-T5; Tue, 06 Dec 2005 15:45:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjgW-0004pT-9w for ima@megatron.ietf.org; Tue, 06 Dec 2005 15:45:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20398 for ; Tue, 6 Dec 2005 15:44:20 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejk22-0000iA-TD for ima@ietf.org; Tue, 06 Dec 2005 16:07:29 -0500 Received: from [192.168.0.3] (adsl-68-120-85-54.dsl.irvnca.pacbell.net [68.120.85.54]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jB6KjXTi009898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Dec 2005 12:45:35 -0800 Message-ID: <4395F845.9060908@dcrocker.net> Date: Tue, 06 Dec 2005 12:44:53 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net 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 Harald, > and irony is not made effective by ignoring the division of a message > into a header and a content.... these are two pieces, the content-type > is in one of them, and the content that it labels is in the other. No, but focus of the current discussion definitely IS made effective. As I said, you are trying to answer a question that was not asked. The question that was asked was about a "message", not about "part of a message when it is separate from the message". Hence, the distinction between header and body is not relevant. >> Self-labeling of message content was the stated task. My original text was "a message with a free-text body has a different labeling than a message with a MIME body," So my original text was about a message, not about content that is not currently part of the message. That's not the same thing as you keep trying to focus on, Harald. You keep wanting to consider identifying the content when it is outside of the message. That's not the issue that I originally raised. >> For your example to be useful, you would need to show that the type of >> the data is correctly identified when that data are outside the message, >> yet still be identified correctly. To that end, the translation from >> content-type to the field extension of a specific piece of mail body >> content -- stored on its own and without the message -- would be a >> representative case. In fact that is done with reasonable success, >> though certainly not always correct. > > Here, I'm entirely lost about what you intended to say, and its > relevance to the previous parts of the thread, so I'll not attempt a > response. Is the message in its transit context or is it separate from that context? If the IMA label is only in the envelope, then it is only available during transit. It is not available after transit. Further, my focus has been on a a message -- not content that is separate from a message -- when the message is outside the context of transfer. By contrast, the distinction you keep focusing on is an example of having message content that is separate from (the context of) the message. (Otherwise, your claim that the content-type label is "outside" does not make sense.) >> I have used quite a number of MUAs in recent years and they have all >> retained the original form. > > I have not questioned that at all. I've asked you (and I ask you again): > What scenario do you have where a processor (that is, something that > processes a message) needs to apply a different processing to an > IMA-labelled message than to a non-IMA-labelled message? When does a processor need to know that the data are 7-bit ascii vs. unicode? I would think that any processor that is going to render the data would need to know that. Are you claiming that the difference is self-identifying? Especially if it is 7-bit net-ascii, rather than pure 7-bit ascii, I think it unlikely that it is automatically self-identifying and think it likely that failing to distinguish between them would not be so wonderful. I will, of course, defer to the unicode experts. > This is about *processing* - that is, doing something about a message. > Having a message stored in a file is not processing. I was under the impression that data, without the ability to process it, was not very useful. Therefore discussing data in a file, without worrying about its being processed, would not occur to me. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 17:15:33 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 1Ejl5x-0000xB-Dz; Tue, 06 Dec 2005 17:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejl5v-0000wz-8v for ima@megatron.ietf.org; Tue, 06 Dec 2005 17:15:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28973 for ; Tue, 6 Dec 2005 17:14:40 -0500 (EST) Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjlRR-0003XX-LO for ima@ietf.org; Tue, 06 Dec 2005 17:37:49 -0500 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB6MEwHG014345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2005 23:15:01 +0100 From: Simon Josefsson To: Harald Tveit Alvestrand References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051206:harald@alvestrand.no::dX+Yt9VDJLUH6IxV:2OX1 X-Hashcash: 1:21:051206:ima@ietf.org::jVvzdpeggMrlDKRf:84m+ X-Hashcash: 1:21:051206:dcrocker@bbiw.net::OYzPjXMadOrshn6M:HDVa Date: Tue, 06 Dec 2005 23:14:55 +0100 In-Reply-To: <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> (Harald Tveit Alvestrand's message of "Tue, 06 Dec 2005 17:59:49 +0100") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ima@ietf.org, dcrocker@bbiw.net Subject: [IMA] Re: Header for stored messages 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 Harald Tveit Alvestrand writes: >>> Viz. - the MIME-Version is an example of self-labelling, and has not >>> worked well. >> >> It hasn't? >> >> If you mean it does not simply, accurately and reliable distinguish >> between >> MIME-structured email body content, and free-form lines of ASCII text >> content, this is the first I have heard of its failing. > > People who write UAs for a living will have to speak to whether they > actually check it. Gnus doesn't require the header field by default. Gnus did for some period of time, but we discovered in 2004 that some MUA/MTAs strip the header, making it appear to our users as if Gnus is MIME-unaware. One report suggested that Lotus Domino clients (version 5.0.6, if it means anything to anyone) was one such buggy client. To improve interoperability, Gnus will now guess whether the message is MIME encoded based on the presence of other MIME headers. This has proven to be more reliable than to require the MIME-Version header before applying any MIME treatment. > It was supposed to give the rule for parsing the content-type header, > but can occur before or after the content-type header, so if they > actually use it for that, it means that they have to delay > content-type header processing until after the whole header is > parsed. Is that how people's code works? That is not my experience. All applications I've worked with store the entire e-mail header in memory before looking at specific fields. Hope this helps, Simon _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 06 21:19:33 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 1Ejou5-0006vk-KD; Tue, 06 Dec 2005 21:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejou3-0006v0-Ud for ima@megatron.ietf.org; Tue, 06 Dec 2005 21:19:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22796 for ; Tue, 6 Dec 2005 21:18:39 -0500 (EST) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjpFY-00030r-MF for ima@ietf.org; Tue, 06 Dec 2005 21:41:51 -0500 Received: (eyou send program); Wed, 07 Dec 2005 10:18:55 +0800 Message-ID: <333921935.01989@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Wed, 07 Dec 2005 10:18:55 +0800 Message-ID: <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Charles Lindsey" References: <333920316.24007@cnnic.cn> Subject: Re: [IMA] URIs/IRIs Date: Wed, 7 Dec 2005 10:19: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: 4d87d2aa806f79fed918a62e834505ca 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="===============1525660325==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1525660325== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiQ2hhcmxlcyBMaW5k c2V5IiA8Y2hsQGNsZXJldy5tYW4uYWMudWs+DQo+IFRvOiA8aW1hQGlldGYub3JnPg0KPiBTZW50 OiBUdWVzZGF5LCBEZWNlbWJlciAwNiwgMjAwNSAyOjAxIEFNDQo+IFN1YmplY3Q6IFJlOiBbSU1B XSBVUklzL0lSSXMNCj4gDQo+IA0KPiBPbiBNb24sIDA1IERlYyAyMDA1IDE0OjEwOjMzIC0wMDAw LCBKb2huIEMgS2xlbnNpbiA8a2xlbnNpbkBqY2suY29tPiB3cm90ZToNCj4gDQo+ID4gVGhhdCB3 YXMgdGhlIGtleSBwb2ludCwgYW5kIHJlYWxseSB0aGUgb25seSBwb2ludCwgSSB3YXMgdHJ5aW5n DQo+ID4gdG8gbWFrZS4NCj4gPg0KPiA+IEkgdGhpbmsgc29tZSBvZiB1cyBzaG91bGQganVzdCBs b29rIGF0IHRoZSB0aGluZywgc29vbiwgYW5kIGdldA0KPiA+IGNvbW1lbnRzIHRvIHlvdSwgcmF0 aGVyIHRoYW4gdHlpbmcgdGhpbmdzIHVwIGluIGZvcm1hbGl0aWVzLg0KPiANCj4gVGhlIG1vc3Qg aW1wb3J0YW50IHRoaW5nIHRvIGRlY2lkZSwgYnV0IG9uZSBub3QgbGlrZWx5IHRvIGJlIGNsZWFy IGZvciAgDQo+IHNvbWUgdGltZSwgYXJpc2VzIGZyb20gdGhlIHByb3Bvc2FsIHRvIGFsbG93IGFu IGFsdGVybmF0YXRlIGRlbGl2ZXJ5ICANCj4gYWRkcmVzcyBpbiB0aGUgUkNQVCBUTzogY29tbWFu ZC4gTm9ib2R5IGhhcyByZWFsbHkgaW5kaWNhdGVkIGhvdyB0aGVzZSB0d28gIA0KPiBhZGRyZXNz ZXMgZ2V0IGdlbmVyYXRlZC4gDQoNCmFmdGVyIG5lZ290aWF0aW9uIGJldHdlZW4gc2VuZGVyIFNN VFAgYW5kIHJlY2VpdmVyIFNNVFAsIGlmIHNlbmRlciBTTVRQIGZpbmRzIHRoYXQgcmVjZWl2ZXIg U01UUCBkb2VzIG5vdCBzdXBwb3J0IElFRSwgdGhlIHNlbmRlciBTTVRQIG1heSB1c2UgYWx0LWFk ZHJlc3MuDQppbiB0aGVzZSBzY2VuYXJpb3MsIA0KIGlmIGFsdC1hZGRyZXNzIHZhbHVlIGlzIG5v dCBzcGVjaWZpZWQsIHRoZSBTTVRQIHNlcnZlciBjYW4gYm91bmNlIHRoZSBlbWFpbCB0byBlbWFp bCBzZW5kZXI7DQppZiBhbHQtYWRkcmVzcyB2YWx1ZSBpcyBzcGVjaWZpZWQsICBTTVRQIG1heSB1 c2UgdGhpcyBhbHQtYWRkcmVzcy4NClRoZSBhbHQtYWRkcmVzcyBtYXkgYmUgZ2VuZXJhdGVkIGJ5 IG9uZSBvZiB0aGUgbWV0aG9kcyBiZWxvdzoNCiAxLiB0aGUgYWx0LWFkZHJlc3MgaXMgc3BlY2lm aWVkIGJ5IGVtYWlsIHNlbmRlci4NCiAyLiB0aGUgYWx0LWFkZHJlc3MgaXMgcHJvZHVjZWQgdXNp bmcgc29tZSBhbGdvcml0aG1zIGlmIHRoZSBJMThOIGFkZHJlc3MgaXMgc3VpdGFibGUgdG8gYmUg dHJhbnNmb3JtZWQuDQoNCg0KPkJ1dCBpdCB3b3VsZCBzZWVtIGRlc2lyYWJsZSB0byBiZSBhYmxl IHRvICANCj4gaW5kaWNhdGUgaW4gYSBtYWlsdG86IFVSSSAidGhpcyBpcyBteSBhZGRyZXNzIGlm IHlvdSBhcmUgc2VuZGluZyBtYWlsIHRvICANCj4gbXkgSTE4TiBhZGRyZXNzLCBidXQgaWYgeW91 ciBzeXN0ZW0gY2Fubm90IG1hbmFnZSB0aGF0LCB0aGVuIHBsZWFzZSBzZW5kICANCj4gdG8gdGhp cyBhbHRlcmF0aXZlIChidXQgbm90IHRvIGJvdGgpIi4NCj4gDQo+IE5vdyB0aGVyZSBhcmUgbWFu eSBub3RhdGlvbnMgaW4gd2hpY2ggdGhhdCBtaWdodCBiZSBleHByZXNzZWQsIGJ1dCB3ZSBhbHNv ICANCj4gbmVlZCB0byBjb25zaWRlciB3aGF0IHdvdWxkIGFwcGVhciBpbiB0aGUgVG86IGFuZCBS ZXBseS1UbzogaGVhZGVycyBvZiBhICANCj4gbWVzc2FnZSwgYmVjYXVzZSB0aGUgc2FtZSBwcm9i bGVtIGFyaXNlcyB0aGVyZSB0b28uDQo+IA0KPiBGb3IgZXhhbXBsZSwgaWYgeW91IHdhbnQgYSBn b2xkLXBsYXRlZCBzb2x1dGlvbiwgeW91IG1pZ2h0IGludmVudCBhIG5ldyAgDQo+IGZvcm1hdCBm b3IgPGFkZHItc3BlYz4sIHN1Y2ggYXMNCj4gDQo+ICAgICAgPOVsaWNlQHRyb21z9i5lZHV8YWxp Y2VAdHJvbXNvLmVkdT4NCj4gDQo+IChIYXJhbGQgY2FuIHN1Z2dlc3QgbW9yZSBwbGF1c2libGUg Tm9yd2VnaWFuIGV4YW1wbGVzKS4NCj4gDQo+IE9UT0gsIHRoYXQgbWlnaHQgYmUgY29uc2lkZXJl ZCB0b28gYmlnIGFuIHVwZ3JhZGUgb2YgUkZDIDI4MjIgZm9yIHVzIHRvIGJlICANCj4gbWFraW5n LCB0aG91Z2ggaXQgd291bGQgbGVhZCB0byBhbiBvYnZpb3VzIGNvcnJlc3BvbmRpbmcgdXBncmFk ZSBmb3IgdGhlICANCj4gbWFpbHRvOiBVUkkuDQo+IA0KPiBOT1RFOiAi5WxpY2UiIGFib3ZlIGlz IHdyaXR0ZW4gaW4gSVNPLTg4NTktMSwgYmVjYXVzZSB0aGF0IGlzIHdoYXQgbXkgIA0KPiBtYWls ZXIgZG9lcywgYnV0IGNsZWFybHkgdGhlIGNvcnJlc3BvbmRpbmcgVVRGLTggd2FzIGludGVuZGVk Lg0KPiANCj4gLS0gDQo+IENoYXJsZXMgSC4gTGluZHNleSAtLS0tLS0tLS1BdCBIb21lLCBkb2lu ZyBteSBvd24gdGhpbmctLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGVsOiArNDQgMTYxIDQz NiA2MTMxIEZheDogKzQ0IDE2MSA0MzYgNjEzMyBXZWI6IGh0dHA6Ly93d3cuY3MubWFuLmFjLnVr L35jaGwNCj4gRW1haWw6IGNobEBjbGVyZXcubWFuLmFjLnVrIFNuYWlsOiA1IENsZXJld29vZCBB dmUsIENIRUFETEUsIFNLOCAzSlUsIFUuSy4NCj4gUEdQOiAyQzE1RjFBOSBGaW5nZXJwcmludDog NzMgNkQgQzIgNTEgOTMgQTAgMDEgRTcgNjUgRTggNjQgN0UgMTQgQTQgQUIgQTUNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWls aW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ltYQ0KPiA= --===============1525660325== 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 --===============1525660325==-- From ima-bounces@ietf.org Wed Dec 07 06:20:29 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 1EjxLZ-0006YY-TB; Wed, 07 Dec 2005 06:20:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjxLX-0006YN-QJ for ima@megatron.ietf.org; Wed, 07 Dec 2005 06:20:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20284 for ; Wed, 7 Dec 2005 06:19:36 -0500 (EST) Received: from lon-mail-2.gradwell.net ([193.111.201.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjxhC-0003e8-Ua for ima@ietf.org; Wed, 07 Dec 2005 06:42:52 -0500 Received: from host81-144-66-35.midband.mdip.bt.net ([81.144.66.35]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 4396c2ca.18374.13f; Wed, 7 Dec 2005 11:08:58 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB7AA4L28774; Wed, 7 Dec 2005 10:10:05 GMT To: "YAO Jiankang" Subject: Re: [IMA] URIs/IRIs References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> Message-ID: Date: Wed, 07 Dec 2005 10:09:58 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA20284 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 On Wed, 07 Dec 2005 02:19:36 -0000, YAO Jiankang wrote: > >> ----- Original Message ----- >> From: "Charles Lindsey" >> The most important thing to decide, but one not likely to be clear for >> some time, arises from the proposal to allow an alternatate delivery >> address in the RCPT TO: command. Nobody has really indicated how these= =20 >> two >> addresses get generated. > > after negotiation between sender SMTP and receiver SMTP, if sender SMTP= =20 > finds that receiver SMTP does not support IEE, the sender SMTP may use = =20 > alt-address. > in these scenarios, > if alt-address value is not specified, the SMTP server can bounce the = =20 > email to email sender; > if alt-address value is specified, SMTP may use this alt-address. > The alt-address may be generated by one of the methods below: > 1. the alt-address is specified by email sender. > 2. the alt-address is produced using some algorithms if the I18N =20 > address is suitable to be transformed. Exactly. It was case #1 I was concerned about. But how does the email =20 sender specify the two possible addresses? Currently, in most MUAs, he =20 does it by writing what will become the "To:" header, as in To: =C5lice <=E5lice@troms=F6.edu|alice@tromso.edu> And if =C5lice wants to tell B=F8b how to send replies to her, she will =20 include in her message Reply-To: =C5lice <=E5lice@troms=F6.edu|alice@tromso.edu> or she will include, on her website, mailto: <=E5lice@troms=F6.edu|alice@tromso.edu> All of which shows that it would be very useful to be able to specify the= =20 alternate address in To: and Reply-To: headers, whether or not we use the= =20 particular notation in my examples above. --=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 Wed Dec 07 06:36:12 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 1Ejxam-0002Cj-IU; Wed, 07 Dec 2005 06:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejxak-0002Ac-3L for ima@megatron.ietf.org; Wed, 07 Dec 2005 06:36:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22157 for ; Wed, 7 Dec 2005 06:35:18 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjxwP-0004B7-98 for ima@ietf.org; Wed, 07 Dec 2005 06:58:34 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jB7BZpd06643; Wed, 7 Dec 2005 20:35:51 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 3209_9e7f2fd2_6715_11da_8af7_00304811fd80; Wed, 07 Dec 2005 20:35:50 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB7BYDod016107; Wed, 7 Dec 2005 20:35:13 +0900 Message-Id: <6.0.0.20.2.20051207154724.06d304a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 07 Dec 2005 15:53:19 +0900 To: Harald Tveit Alvestrand , dcrocker@bbiw.net From: Martin Duerst Subject: Re: [IMA] Re: Header for stored messages In-Reply-To: <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 At 01:59 05/12/07, Harald Tveit Alvestrand wrote: >(Personal note: I am in two minds about whether or not a label in the headers is an useful thing. My gut feeling is that it might be, but I haven't seen the clincher argument for it yet - nor have I seen the clincher argument that it's a significant cost and complexity that needs to be avoided.) [I'm likewise of two minds, or maybe just of no mind for the moment.] As I have joined this list recently, this may be an old argument, but what about thinking from the other end: What are the scenarios where it is necessary to have such a header? Technically, it would always suffice to check headers for UTF-8, I assume. Are there cases where that might go wrong, but a header would be correct? What are they. Are there cases where the overhead of checking each header for UTF-8 is significantly higher than checking for the specific header? Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 07 06:36:39 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 1EjxbD-0002Mc-M1; Wed, 07 Dec 2005 06:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjxbC-0002MS-LR for ima@megatron.ietf.org; Wed, 07 Dec 2005 06:36:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22242 for ; Wed, 7 Dec 2005 06:35:47 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejxwt-0004CV-91 for ima@ietf.org; Wed, 07 Dec 2005 06:59:03 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jB7BaOu25000; Wed, 7 Dec 2005 20:36:24 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 3217_b221593e_6715_11da_97ed_00304811fd80; Wed, 07 Dec 2005 20:36:24 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB7BYDon016107; Wed, 7 Dec 2005 20:35:58 +0900 Message-Id: <6.0.0.20.2.20051207184012.04194ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 07 Dec 2005 18:50:20 +0900 To: dcrocker@bbiw.net, Harald Tveit Alvestrand From: Martin Duerst Subject: Re: [IMA] Re: Header for stored messages In-Reply-To: <4395F845.9060908@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> <4395F845.9060908@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 At 05:44 05/12/07, Dave Crocker wrote: >When does a processor need to know that the data are 7-bit ascii vs. unicode? > >I would think that any processor that is going to render the data would need >to know that. Are you claiming that the difference is self-identifying? The difference between 7-bit ascii and UTF-8 is definitely self-identifying, unless you want to make a distinction between data intended to be 7-bit ascii only and data that is UTF-8 but by chance doesn't contain any characters above U+007F, and therefore looks like US-ASCII. But I don't think that such a distinction would make any sense. >Especially if it is 7-bit net-ascii, This is the first time I have seen the term 'net-ascii', although I consider myself somewhat familiar with character encoding on the net :-). Can you clarify? >rather than pure 7-bit ascii, I think >it unlikely that it is automatically self-identifying and think it likely >that failing to distinguish between them would not be so wonderful. I will, >of course, defer to the unicode experts. UTF-8 is extremely highly self-identifying. For some detailled discussion, see e.g. http://www.ifi.unizh.ch/groups/mml/people/mduerst/papers/PDF/IUC11-UTF-8.pdf (rather old now). See in particular p.13 and following. However, if we are talking about a couple characters e.g. in an email address, AND we are talking about distinction from arbitrary other encodings (e.g. EUC-xx, Shift_JIS, and so on), rather than US-ASCII, then there is indeed a certain probability of false positives. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 07 07:12:33 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 1Ejy9x-0002NU-Ov; Wed, 07 Dec 2005 07:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejy9w-0002Mu-6B for ima@megatron.ietf.org; Wed, 07 Dec 2005 07:12:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26426 for ; Wed, 7 Dec 2005 07:11:40 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjyVd-0005bE-61 for ima@ietf.org; Wed, 07 Dec 2005 07:34:57 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 260352596F3; Wed, 7 Dec 2005 13:11:43 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28208-03; Wed, 7 Dec 2005 13:11:38 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FBBB259722; Wed, 7 Dec 2005 13:11:37 +0100 (CET) Date: Wed, 07 Dec 2005 09:27:37 +0100 From: Harald Tveit Alvestrand To: dcrocker@bbiw.net Subject: Re: [IMA] Re: Header for stored messages Message-ID: <86A1ACA1AFA1D1D77B45541E@B50854F0A9192E8EC6CDA126> In-Reply-To: <4395F845.9060908@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> <4395F845.9060908@dcrocker.net> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.7 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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="===============0491265814==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0491265814== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========75974E74392F9FB607A1==========" --==========75974E74392F9FB607A1========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 6. desember 2005 12:44 -0800 Dave Crocker wrote: >> I have not questioned that at all. I've asked you (and I ask you again): >> What scenario do you have where a processor (that is, something that >> processes a message) needs to apply a different processing to an >> IMA-labelled message than to a non-IMA-labelled message? > > When does a processor need to know that the data are 7-bit ascii vs. > unicode? > > I would think that any processor that is going to render the data would > need > to know that. Thanks for coming up with a specific example! > Are you claiming that the difference is self-identifying? In fact UTF-8 is 100% self-identifying if the only two alternatives are=20 UTF-8 and 7-bit ASCII stored in 8-bit bytes in the usual way - you simply=20 check for whether anything has the high bit set. For the current definitions, any processor capable of displaying an IMA=20 message would also correctly display a traditional email message, since=20 displaying the ASCII code positions is required to display UTF-8 correctly. If there turns out to be any differences between an IMA object and a=20 traditional mail object apart from the character set allowed in pieces of=20 the header, it's an open question whether they are self-identifying - at=20 the moment, I don't think any such differences have been proposed. > Especially if it is 7-bit net-ascii, rather than pure 7-bit ascii, I = think > it unlikely that it is automatically self-identifying and think it likely > that failing to distinguish between them would not be so wonderful. I > will, > of course, defer to the unicode experts. query: what difference do you see between "7-bit net-ascii" and "pure 7-bit = ascii" - ie which of them isn't correctly characterized by=20 "charset=3Dus-ascii"? --==========75974E74392F9FB607A1========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDlpz5OMj+2+WY0F4RAuPNAJ9drI6WxJ5Lz9fEPm2IWOx4hYIiIwCfQ4mD 77l5O1NI2wlcM1I5OgS0WLE= =y8GE -----END PGP SIGNATURE----- --==========75974E74392F9FB607A1==========-- --===============0491265814== 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 --===============0491265814==-- From ima-bounces@ietf.org Wed Dec 07 10:59:42 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 1Ek1hm-0005I8-Qk; Wed, 07 Dec 2005 10:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1hl-0005Hu-59 for ima@megatron.ietf.org; Wed, 07 Dec 2005 10:59:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23397 for ; Wed, 7 Dec 2005 10:58:48 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek23T-00051N-Cm for ima@ietf.org; Wed, 07 Dec 2005 11:22:08 -0500 Received: from [172.17.196.249] ([65.198.0.67]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jB7G05Ge025083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Dec 2005 08:00:09 -0800 Message-ID: <439706DE.6090202@dcrocker.net> Date: Wed, 07 Dec 2005 07:59:26 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> <4395F845.9060908@dcrocker.net> <86A1ACA1AFA1D1D77B45541E@B50854F0A9192E8EC6CDA126> In-Reply-To: <86A1ACA1AFA1D1D77B45541E@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net 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 >> I would think that any processor that is going to render the data would >> need to know that. > > Thanks for coming up with a specific example! tsk, tsk, harald. >> Are you claiming that the difference is self-identifying? > > In fact UTF-8 is 100% self-identifying if the only two alternatives are > UTF-8 and 7-bit ASCII stored in 8-bit bytes in the usual way - you > simply check for whether anything has the high bit set. Ahh, good. Then we do not need any of this protocol overhead people keep insisting on, for distinguishing between them. We'll just let processing engines wander over the data and figure it out. I guess we don't have to worry about UTF-8 that happens to contain only data in the netascii set. Designing heuristics into basic protocol mechanism ought to become quite fashionable. > query: what difference do you see between "7-bit net-ascii" and "pure > 7-bit ascii" - ie which of them isn't correctly characterized by > "charset=us-ascii"? Take a look at the Telnet specification. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 07 11:05:36 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 1Ek1nU-0006Tf-UB; Wed, 07 Dec 2005 11:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1nT-0006TZ-IF for ima@megatron.ietf.org; Wed, 07 Dec 2005 11:05:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23901 for ; Wed, 7 Dec 2005 11:04:42 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek298-0005BN-Ix for ima@ietf.org; Wed, 07 Dec 2005 11:28:03 -0500 Received: from [172.17.196.249] ([65.198.0.67]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jB7G5w3q025823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Dec 2005 08:06:00 -0800 Message-ID: <4397083F.5050705@dcrocker.net> Date: Wed, 07 Dec 2005 08:05:19 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> <4395F845.9060908@dcrocker.net> <6.0.0.20.2.20051207184012.04194ec0@localhost> In-Reply-To: <6.0.0.20.2.20051207184012.04194ec0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net 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 > The difference between 7-bit ascii and UTF-8 is definitely > self-identifying, unless you want to make a distinction between > data intended to be 7-bit ascii only and data that is UTF-8 > but by chance doesn't contain any characters above U+007F, I do. The idea of using heuristics for identitying data form strikes me as poor protocol design. > >Especially if it is 7-bit net-ascii, > > This is the first time I have seen the term 'net-ascii', although I > consider myself somewhat familiar with character encoding on the net :-). > Can you clarify? Shortened form for "Network Virtual ASCII" as defined in Telnet (RFC 854). When Internet protocols use 7-bit ASCII it is pretty much always netascii. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 07 14:14:16 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 1Ek4k4-0006i7-4t; Wed, 07 Dec 2005 14:14:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4k2-0006hy-Mb for ima@megatron.ietf.org; Wed, 07 Dec 2005 14:14:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15055 for ; Wed, 7 Dec 2005 14:13:22 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek55l-0003lQ-Ox for ima@ietf.org; Wed, 07 Dec 2005 14:36:43 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1Ek4jp-000FWZ-9u; Wed, 07 Dec 2005 14:14:01 -0500 Date: Wed, 07 Dec 2005 14:14:01 -0500 From: John C Klensin To: Charles Lindsey Subject: Re: [IMA] URIs/IRIs Message-ID: In-Reply-To: References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> 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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable 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 --On Wednesday, 07 December, 2005 10:09 +0000 Charles Lindsey wrote: >... >> if alt-address value is specified, SMTP may use this >> alt-address. The alt-address may be generated by one of the >> methods below: 1. the alt-address is specified by email >> sender. >> 2. the alt-address is produced using some algorithms if the >> I18N address is suitable to be transformed. >=20 > Exactly. It was case #1 I was concerned about. But how does > the email sender specify the two possible addresses? > Currently, in most MUAs, he does it by writing what will > become the "To:" header, as in >=20 > To: =C3=85lice = <=C3=A5lice@troms=C3=B6.edu|alice@tromso.edu> >=20 > And if =C3=85lice wants to tell B=C3=B8b how to send replies = to her, > she will include in her message >=20 > Reply-To: =C3=85lice = <=C3=A5lice@troms=C3=B6.edu|alice@tromso.edu> >=20 > or she will include, on her website, >=20 > mailto: <=C3=A5lice@troms=C3=B6.edu|alice@tromso.edu> >=20 > All of which shows that it would be very useful to be able to > specify the alternate address in To: and Reply-To: headers, > whether or not we use the particular notation in my examples > above. Charles, While an extended mailto syntax might well work (we would need to review the syntax carefully), I think it would be a terrible idea to change the syntax of the address fields in the headers. The difficulty is related to the one that has already been explained about "MIME-Version" -- one really cannot use one header, which might appear in arbitrary order-- to determine how another one is to be parsed, especially if the new parsing violates the basic syntax rules of the old one. And, of course, trying to parse new headers in the absence of such clues would make the requirement for some sort of header-marker of the new syntax even more important. =20 So, if this stuff needs to be in the headers, I think you need to invent some new headers and hope that systems that don't understand them won't try to parse them at all. That said, a different way to look at this would be that any such headers would be strictly a matter between the MUA and the submission server, with the latter having the ability to parse them and turn them into something else if needed. Please also remember, in that context, that the convention of sending 822 information only off to the submission server, and doing it via SMTP, have never been required. Some MTAs have always provided different models for the submission MUAs to communicate with them and have provided, in those models, mechanisms for specifying envelope information separately from the header information... rather than expecting the Submission MTA to guess at the relevant envelope information from the headers. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 08 00:50:48 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 1EkEg4-0007wo-2P; Thu, 08 Dec 2005 00:50:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkEg3-0007wj-Kc for ima@megatron.ietf.org; Thu, 08 Dec 2005 00:50:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28872 for ; Thu, 8 Dec 2005 00:49:53 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkF1p-0002Qv-EJ for ima@ietf.org; Thu, 08 Dec 2005 01:13:20 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jB85oOd19596; Thu, 8 Dec 2005 14:50:24 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 51d7_86d2e1f0_67ae_11da_8dcb_00304811fd80; Thu, 08 Dec 2005 14:50:23 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB85n5bZ027621; Thu, 8 Dec 2005 14:49:33 +0900 Message-Id: <6.0.0.20.2.20051208120219.07b614e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 08 Dec 2005 12:24:52 +0900 To: Dave Crocker From: Martin Duerst Subject: Re: [IMA] Re: Header for stored messages In-Reply-To: <43970523.5010604@bbiw.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> < <43970523.5010604@bbiw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 At 00:52 05/12/08, Dave Crocker wrote: > > >> The difference between 7-bit ascii and UTF-8 is definitely >> self-identifying, unless you want to make a distinction between >> data intended to be 7-bit ascii only and data that is UTF-8 >> but by chance doesn't contain any characters above U+007F, > >I do. Could you explain why you want to do it? Actually, I can at least see one good reason for not wanting to do it: A message where all headers are 7-bit US-ASCII can be sent with non-IMA SMTP, without any problems. But once it is labeled as IMA, that won't happen. This is unnecessarily reducing interoperability. >The idea of using heuristics for identitying data form strikes me as poor protocol design. Is using a heuristic with a 100% success rate poor protocol design? Would we even want to call that a heuristic? >> >Especially if it is 7-bit net-ascii, >> This is the first time I have seen the term 'net-ascii', although I >> consider myself somewhat familiar with character encoding on the net :-). >> Can you clarify? > >Shortened form for "Network Virtual ASCII" as defined in Telnet (RFC 854). Thanks. I have looked at RFC 854. >When Internet protocols use 7-bit ASCII it is pretty much always netascii. I have found nothing in RFC 854 that is in any way relevant to the current discussion, but just to be sure: That RFC mentions the following code ranges: - 95 USASCII graphics (codes 32 through 126): No prolem at all - 33 USASCII control codes (0 through 31 and 127): Of these, NUL, LF, CR, BEL, BS, HT, VT, and FF are used. I don't think email headers use all of these, but none of them are a problem for the current discussion. - 128 uncovered codes (128 through 255): These are the values that UTF-8 uses to represent non-ASCII characters, so here it gets interesting. Codes 240-255 are indeed used in the telnet protocol for escape sequences that transmit commands. Are you saying that these are part of what you call 7-bit net-ascii (I wouldn't call that 7-bit anymore in that case)? Are you saying that these escape sequences actually turn up in decent email headers? Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 08 00:50:50 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 1EkEg6-0007xG-7Z; Thu, 08 Dec 2005 00:50:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkEg3-0007wi-Kb for ima@megatron.ietf.org; Thu, 08 Dec 2005 00:50:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28873 for ; Thu, 8 Dec 2005 00:49:53 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkF1p-0002Qu-Eb for ima@ietf.org; Thu, 08 Dec 2005 01:13:20 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jB85oOu01611; Thu, 8 Dec 2005 14:50:24 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 15f1_86df17f4_67ae_11da_9d0e_0030482533a1; Thu, 08 Dec 2005 14:50:23 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jB85n5bb027621; Thu, 8 Dec 2005 14:49:59 +0900 Message-Id: <6.0.0.20.2.20051208122528.07b62150@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 08 Dec 2005 12:34:57 +0900 To: dcrocker@bbiw.net, Harald Tveit Alvestrand From: Martin Duerst Subject: Re: [IMA] Re: Header for stored messages In-Reply-To: <439706DE.6090202@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> < <439706DE.6090202@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 At 00:59 05/12/08, Dave Crocker wrote: >>> Are you claiming that the difference is self-identifying? >> In fact UTF-8 is 100% self-identifying if the only two alternatives are UTF-8 and 7-bit ASCII stored in 8-bit bytes in the usual way - you simply check for whether anything has the high bit set. > >Ahh, good. Then we do not need any of this protocol overhead people keep insisting on, for distinguishing between them. We'll just let processing engines wander over the data and figure it out. Well, if we use a specific header, processing engines will have to find and parse that header. Which means that they have to wander over the header data and figure it out. Depending on the details, one or the other 'wandering over the data' may be faster, but there shuldn't be a huge difference. >I guess we don't have to worry about UTF-8 that happens to contain only data in the netascii set. Yes indeed. Unless for some reason, which I hope you can tell us, you would think it is a feature that you can make sure that a plain old mail (with all headers ASCII-only) always gets treated as an IMA message. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 08 03:29:58 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 1EkHA6-00065j-QG; Thu, 08 Dec 2005 03:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHA4-00065V-IJ for ima@megatron.ietf.org; Thu, 08 Dec 2005 03:29:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12016 for ; Thu, 8 Dec 2005 03:29:03 -0500 (EST) Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkHVu-0006hf-I6 for ima@ietf.org; Thu, 08 Dec 2005 03:52:32 -0500 Received: from host81-144-64-236.midband.mdip.bt.net ([81.144.64.236]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 4397a815.185e3.c for ima@ietf.org; Thu, 8 Dec 2005 03:27:17 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB7IwML06264 for ; Wed, 7 Dec 2005 18:58:22 GMT Date: Tue, 06 Dec 2005 17:58:09 -0000 From: "Charles Lindsey" To: "Harald Tveit Alvestrand" Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> Message-ID: In-Reply-To: <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) Resent-To: "ima@ietf.org" Resent-From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Resent-Date: Wed, 07 Dec 2005 18:58:11 -0000 Resent-Message-ID: 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 DAA12016 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 Tue, 06 Dec 2005 13:08:28 -0000, Harald Tveit Alvestrand wrote: > So.... what is the scenario where the processor needs to apply a =20 > different processing to an IMA-labelled message, AND can safely assume = =20 > that all non-IMA-labelled messages are "legacy" conformant? Where it might need to be downgraded/bounced before further transport N.B. the proposed SMTP enhancements do *not* give enough informatio= n to decide this. In IMAP (almost certainly) In Gateways (in both directions) When stored in a file (as Dave has suggested) and it needs to be re-inserted into the mail system, for whatever reason. N.B. It is obviously possible to scan thrpough the headers looking for bit-8, instead of having a label, but that is extra work - it all depends how often it will need to happen. --=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 Dec 08 03:29:59 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 1EkHA6-000667-Vb; Thu, 08 Dec 2005 03:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHA4-00065U-Ht for ima@megatron.ietf.org; Thu, 08 Dec 2005 03:29:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12015 for ; Thu, 8 Dec 2005 03:29:03 -0500 (EST) Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkHVu-0006hl-I4 for ima@ietf.org; Thu, 08 Dec 2005 03:52:32 -0500 Received: from host81-144-64-236.midband.mdip.bt.net ([81.144.64.236]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 4397a816.185e3.d for ima@ietf.org; Thu, 8 Dec 2005 03:27:18 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB7JExL06354 for ; Wed, 7 Dec 2005 19:14:59 GMT To: ima@ietf.org Subject: Re: [IMA] Re: Header for stored messages References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@svartdal.hjemme.alvestrand.no> <4395CF70.6020401@dcrocker.net> <4395F845.9060908@dcrocker.net> <6.0.0.20.2.20051207184012.04194ec0@localhost> <4397083F.5050705@dcrocker.net> Message-ID: Date: Wed, 07 Dec 2005 19:14:53 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <4397083F.5050705@dcrocker.net> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA12015 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 Wed, 07 Dec 2005 16:05:19 -0000, Dave Crocker wrot= e: >> The difference between 7-bit ascii and UTF-8 is definitely >> self-identifying, unless you want to make a distinction between >> data intended to be 7-bit ascii only and data that is UTF-8 >> but by chance doesn't contain any characters above U+007F, > > I do. The idea of using heuristics for identitying data form strikes m= e =20 > as > poor protocol design. I don't. If a pure ASCII message gets labelled as "IEE", no protocols wil= l =20 be broken, but eyebrows may be raised, time wasted in some agents, and =20 even the message may be bounced or otherwise treated differently if some = =20 agent believes the label rather than the actual content. But I agree that using heuristics to identify format is poor design. And = =20 even though checking for the lack of any 8th bit is not a heuristic it is= =20 still a waste of time if it has to be done often on the same message. --=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 Dec 08 09:33:01 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 1EkMpR-0000Xc-H8; Thu, 08 Dec 2005 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkMpP-0000XX-RR for ima@megatron.ietf.org; Thu, 08 Dec 2005 09:32:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20783 for ; Thu, 8 Dec 2005 09:32:07 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkMpO-0002JZ-II for ima@ietf.org; Thu, 08 Dec 2005 09:33:00 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EkMpJ-000ICW-0s for ima@ietf.org; Thu, 08 Dec 2005 09:32:53 -0500 Date: Thu, 08 Dec 2005 09:32:52 -0500 From: John C Klensin To: ima@ietf.org Message-ID: <6A99DA789ED094B7BE28FE1D@scan.jck.com> 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: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Subject: [IMA] Identifying i18n messages 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 Hi. I've been following this discussion and trying to work out the case analysis. Dave's comparison to Return-path was quite useful to me although I drew slightly different inferences from it (not unusual). In my first round of thinking about this, I was strongly influenced by the implementation and deployment experience with 8BITMIME. With that option, virtually all implementations that advertise the option do so on the basis of "I can handle this, transparently, if you send it". As far as I know, very few transport or MUA implementations exist that accept 8BITMIME and then handle it any differently from ordinary 7bit messages. But those that might need to do so do have the needed content-transfer-encoding header to give them a clue. I also didn't go back and redo that analysis adequately when the idea of UTF-8 headers was introduced and, with it, the possibility of having UTF-8 headers without any envelope symptoms. I've also been concerned about depending on a header that would either force header ordering dependencies or that might be casually deleted in transit, especially by none-too-bright gateway or firewall implementations of SMTP. I think, after working through all of the cases I could find, that we need a two-pronged approach: (1) If i18n features are being used, the SMTP client must announce that fact via a parameter. We need to sort out whether that parameter is optional if one of the downgrade parameters is specified or must be specified in any case but, assuming the latter, this would be something like "I18N" on the MAIL command (the first command that is guaranteed to be present in the mail transaction). (2) We invent a new header that identifies the presence of i18n information (particularly UTF-8 headers) in the message. While we can't require header ordering, it would be good to have it appear as near the top of the headers as possible. It would also be good to be able to (as nearly as possible) guarantee that it will be there when the message is dropped into a mail store. I think this means: (2a) The header MUST be inserted, along with (and either before or after) Return-path, by the final delivery MTA. (2b) The header MAY be inserted by the originating MUA or, on its behalf, by the submission MTA. (2c) The header, if present, MUST be removed as part of any downgrading process that eliminates the UTF-8 header information. (2d) An MTA that inserts the header MAY check for duplicates (an instance of the header that is already present) and eliminate all but one of them. However, if a receiving MUA encounters more than one of these headers, it SHOULD simply ignore any excess ones without comment (I have not convinced myself yet that this could safely be a "MUST", and that may partially depend on (3)). Note that combination guarantees that the header will be present on delivery even if it is deleted in transit. That is probably an important case; I don't know how to get it in any other way. I haven't come up with a good name for the header, but would suggest that, given our bad experiences so far with both IMA (another WG) and IEE (an historical component, and registered trademark, of IEEE), any names for header fields or parameters be based on something like "i18n-email" rather than on IMA or IEE. I also haven't sorted through the syntax of that header. I have tried to figure out if we could just use "MIME-Version: 2.0" (since this really requires a different parsing model that is able to deal with non-ASCII text), but I think I've convinced myself that is not a good idea -- others should repeat the exercise themselves, since it would be attractive to not invent a completely new header requirement. If the "MIME-Version" approach were used, insertion by the originating system would, of course, become a "MUST" but not change anything else. Having the header potentially has another benefit, which is that it would provide a place to put the alternate address information that Charles wants to see in the headers. I am still not convinced that is a good idea or ought to be a requirement and the syntax might get complicated, but the "can be inserted by the originating MUA but is guaranteed to be there on delivery" property that I think this header needs to have is probably the right one for those addresses. The above obviously raises as many questions -- about names, syntax, and edge conditions-- as it answers but (i) does it sound like a plausible approach that meeting the perceived needs? And (ii) if so, can we start sorting out the details? john (3) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 08 09:41:41 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 1EkMxp-0003fW-N7; Thu, 08 Dec 2005 09:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkMxi-0003es-Fh for ima@megatron.ietf.org; Thu, 08 Dec 2005 09:41:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22114 for ; Thu, 8 Dec 2005 09:40:33 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkMxZ-0002eX-GB for ima@ietf.org; Thu, 08 Dec 2005 09:41:26 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EkMxT-000IEM-1M; Thu, 08 Dec 2005 09:41:19 -0500 Date: Thu, 08 Dec 2005 09:41:18 -0500 From: John C Klensin To: Simon Josefsson , Harald Tveit Alvestrand Subject: Re: [IMA] Re: Header for stored messages Message-ID: In-Reply-To: References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> <438E1036.2070706@dcrocker.net> <486F5543F190698E144A6AF3@svartdal.hjemme.alvestrand.no> <4395BE10.5050402@dcrocker.net> <795E5A2413E6A0F5F5BB1BB0@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: 9182cfff02fae4f1b6e9349e01d62f32 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 --On Tuesday, 06 December, 2005 23:14 +0100 Simon Josefsson wrote: >> It was supposed to give the rule for parsing the content-type >> header, but can occur before or after the content-type >> header, so if they actually use it for that, it means that >> they have to delay content-type header processing until after >> the whole header is parsed. Is that how people's code works? > > That is not my experience. All applications I've worked with > store the entire e-mail header in memory before looking at > specific fields. But, FWIW, there certainly have been implementations that work the other way. Remember that we have email implementations around that work in very constrained embedded environments in which "read everything in at once" is a bad implementation strategy -- especially in the presence of some of the very long and drawn-out headers that have come into existence as the result of various antispam and authentication strategies. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 08 12:29:03 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 1EkPZn-00087D-AL; Thu, 08 Dec 2005 12:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPZm-00083u-Ty for ima@megatron.ietf.org; Thu, 08 Dec 2005 12:29:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14053 for ; Thu, 8 Dec 2005 12:28:00 -0500 (EST) Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkPZg-00011k-4d for ima@ietf.org; Thu, 08 Dec 2005 12:28:56 -0500 Received: from host81-144-65-124.midband.mdip.bt.net ([81.144.65.124]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43986ae5.6102.2a4 for ima@ietf.org; Thu, 8 Dec 2005 17:18:29 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB8Ev2L15223 for ; Thu, 8 Dec 2005 14:57:03 GMT To: ima@ietf.org Subject: Re: [IMA] URIs/IRIs References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> Message-ID: Date: Thu, 08 Dec 2005 14:56:57 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA14053 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 Wed, 07 Dec 2005 19:14:01 -0000, John C Klensin wrot= e: > --On Wednesday, 07 December, 2005 10:09 +0000 Charles Lindsey > wrote: >> To: =C5lice <=E5lice@troms=F6.edu|alice@tromso.edu> >> Reply-To: =C5lice <=E5lice@troms=F6.edu|alice@tromso.edu> >> All of which shows that it would be very useful to be able to >> specify the alternate address in To: and Reply-To: headers, >> whether or not we use the particular notation in my examples >> above. > > While an extended mailto syntax might well work (we would need > to review the syntax carefully), I think it would be a terrible > idea to change the syntax of the address fields in the headers. > The difficulty is related to the one that has already been > explained about "MIME-Version" -- one really cannot use one > header, which might appear in arbitrary order-- to determine how > another one is to be parsed,.... One of the properties we are trying to achieve is that no IEE message is = =20 sent to another agent without first establishing (by looking at the =20 capabilities advertised) that agent #2 is able to handle it (e.g. that it= s =20 parser will accept the extended syntax without needing to look at the =20 'label' header first). I grant you that if one invented a header Use-Header-Parsing Syntax: A (or B) where syntaxes A and B were mutually incompatible, then you would have =20 real problems (for example if, in MIME Version 2.0, the old Content-Type = =20 syntax is not a subset of the new). But in the case we are considering =20 that would not be so - if you know how to parse the extended syntax then = =20 you can still parse the old, and if you cannot parse the new, then it =20 should never have been sent to you in the first place. There are indeed dangers in inventing new syntax for ,and we =20 would have to consider it very carefully, but the particular problem you = =20 raise need not be one of them > > So, if this stuff needs to be in the headers, I think you need > to invent some new headers and hope that systems that don't > understand them won't try to parse them at all. You mean a new set such as: Alt-To: Alt-Cc: Alt-From: Alt-Reply-To Alt-Sender: and probably some more. > That said, a > different way to look at this would be that any such headers > would be strictly a matter between the MUA and the submission > server, with the latter having the ability to parse them and > turn them into something else if needed. Yes, if it advertised the IEE capability to the MUA, then it would be =20 obliged to downgrade any extended headers (or to bounce) if the next =20 server in line could not cope. But I think the point is that we do have a need for some such capability,= =20 particularly in the From/Reply-To. But there are many ways we might be =20 able to provide it. --=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 Dec 08 16:08:14 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 1EkSzu-0002vD-Qw; Thu, 08 Dec 2005 16:08:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSzs-0002tE-6o for ima@megatron.ietf.org; Thu, 08 Dec 2005 16:08:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12601 for ; Thu, 8 Dec 2005 16:07:09 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSzk-000235-MF for ima@ietf.org; Thu, 08 Dec 2005 16:08:06 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EkSza-000JCj-T0; Thu, 08 Dec 2005 16:07:54 -0500 Date: Thu, 08 Dec 2005 16:07:54 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [IMA] URIs/IRIs Message-ID: <995FDB9A1E0731F0215362CE@scan.jck.com> In-Reply-To: References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> 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: a8a20a483a84f747e56475e290ee868e 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 --On Thursday, 08 December, 2005 14:56 +0000 Charles Lindsey wrote: > On Wed, 07 Dec 2005 19:14:01 -0000, John C Klensin > wrote: >=20 >> --On Wednesday, 07 December, 2005 10:09 +0000 Charles Lindsey >> wrote: >=20 >>> To: =C3=85lice = <=C3=A5lice@troms=C3=B6.edu|alice@tromso.edu> >=20 >>> Reply-To: =C3=85lice = <=C3=A5lice@troms=C3=B6.edu|alice@tromso.edu> >=20 >>> All of which shows that it would be very useful to be able = to >>> specify the alternate address in To: and Reply-To: headers, >>> whether or not we use the particular notation in my = examples >>> above. >>=20 >=20 >> While an extended mailto syntax might well work (we would = need >> to review the syntax carefully), I think it would be a >> terrible idea to change the syntax of the address fields in >> the headers. The difficulty is related to the one that has >> already been explained about "MIME-Version" -- one really >> cannot use one header, which might appear in arbitrary >> order-- to determine how another one is to be parsed,.... >=20 > One of the properties we are trying to achieve is that no IEE > message is sent to another agent without first establishing > (by looking at the capabilities advertised) that agent #2 is > able to handle it (e.g. that its parser will accept the > extended syntax without needing to look at the 'label' header > first). Yes. But one of the arguments for an indicating header field is apparently that one should be able to use it to determine whether a message is really in the new form, absent envelope capabilities. I don't quite believe that (either?), but, if one changes the syntax of existing fields, it would require a parser to handle the headers in two passes --one to look for the indicator header and one to apply the correct parsing rules to the fields with legacy names. That strikes me as a not-so-wonderful idea. =20 > I grant you that if one invented a header > Use-Header-Parsing Syntax: A (or B) > where syntaxes A and B were mutually incompatible, then you > would have real problems (for example if, in MIME Version > 2.0, the old Content-Type syntax is not a subset of the new). > But in the case we are considering that would not be so - if > you know how to parse the extended syntax then you can still > parse the old, and if you cannot parse the new, then it > should never have been sent to you in the first place. But the "new" is a serious error under the old, whether one can parse it or not. > There are indeed dangers in inventing new syntax for > ,and we would have to consider it very carefully, > but the particular problem you raise need not be one of them >>=20 >> So, if this stuff needs to be in the headers, I think you = need >> to invent some new headers and hope that systems that don't >> understand them won't try to parse them at all. >=20 > You mean a new set such as: > Alt-To: > Alt-Cc: > Alt-From: > Alt-Reply-To > Alt-Sender: > and probably some more. That has been the historical suggestion. I don't like it very much either. >> That said, a >> different way to look at this would be that any such headers >> would be strictly a matter between the MUA and the submission >> server, with the latter having the ability to parse them and >> turn them into something else if needed. >=20 > Yes, if it advertised the IEE capability to the MUA, then it > would be obliged to downgrade any extended headers (or to > bounce) if the next server in line could not cope. >=20 > But I think the point is that we do have a need for some such > capability, particularly in the From/Reply-To. But there are > many ways we might be able to provide it. Yes john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 09 06:00:49 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 1Ekfzc-0004ns-VK; Fri, 09 Dec 2005 06:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekfzb-0004nU-V7 for ima@megatron.ietf.org; Fri, 09 Dec 2005 06:00:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17334 for ; Fri, 9 Dec 2005 05:59:46 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekfzd-0006rc-P9 for ima@ietf.org; Fri, 09 Dec 2005 06:00:51 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 94659259746 for ; Fri, 9 Dec 2005 11:59:48 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14205-03 for ; Fri, 9 Dec 2005 11:59:44 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF13D259745 for ; Fri, 9 Dec 2005 11:59:43 +0100 (CET) Date: Fri, 09 Dec 2005 12:02:56 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [IEE] Minutes uploaded to IETF website X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org I have uploaded the minutes as corrected on the list. You can check them at Thanks for all the fixes! Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 09 07:30:35 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 1EkhOV-0004J1-5T; Fri, 09 Dec 2005 07:30:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkhOU-0004EG-MD for ima@megatron.ietf.org; Fri, 09 Dec 2005 07:30:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26717 for ; Fri, 9 Dec 2005 07:29:35 -0500 (EST) Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkhOa-0001FC-UL for ima@ietf.org; Fri, 09 Dec 2005 07:30:41 -0500 Received: from host81-144-66-54.midband.mdip.bt.net ([81.144.66.54]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 439978d8.d003.9e for ima@ietf.org; Fri, 9 Dec 2005 12:30:16 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB9BomL25682 for ; Fri, 9 Dec 2005 11:50:48 GMT Date: Fri, 09 Dec 2005 11:50:43 -0000 To: ima@ietf.org References: <6A99DA789ED094B7BE28FE1D@scan.jck.com> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Message-ID: In-Reply-To: <6A99DA789ED094B7BE28FE1D@scan.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA26717 Subject: [IEE] Re: [IMA] Identifying i18n messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Thu, 08 Dec 2005 14:32:52 -0000, John C Klensin wrot= e: > I think, after working through all of the cases I could find, > that we need a two-pronged approach: > > (1) If i18n features are being used, the SMTP client must > announce that fact via a parameter.... Essentially, that is conveying this information in the envelope, as well = =20 as in some 'label' header. But it only works in parts of the protocol =20 where something like the "envelope" concept exists. > > (2) We invent a new header that identifies the presence of i18n > information (particularly UTF-8 headers) in the message. While > we can't require header ordering, it would be good to have it > appear as near the top of the headers as possible. It would > also be good to be able to (as nearly as possible) guarantee > that it will be there when the message is dropped into a mail > store. I think this means: > > (2a) The header MUST be inserted, along with (and either before > or after) Return-path, by the final delivery MTA. That is the latest point to insert it, but ideally it should be there =20 already. And you need a definition of "final delivery MTA" that covers al= l =20 the edge cases, such as gateways and list expanders. > > (2b) The header MAY be inserted by the originating MUA or, on > its behalf, by the submission MTA. I would make that SHOULD, at least. > > (2c) The header, if present, MUST be removed as part of any > downgrading process that eliminates the UTF-8 header information. Not necessarily. > > (2d) An MTA that inserts the header MAY check for duplicates (an > instance of the header that is already present) and eliminate > all but one of them. However, if a receiving MUA encounters > more than one of these headers, it SHOULD simply ignore any > excess ones without comment (I have not convinced myself yet > that this could safely be a "MUST", and that may partially > depend on (3)). Again, duplicates SHOULD be avoided. Depending on what extra information = =20 we might convey with this header, they might even be harmful. > > Note that combination guarantees that the header will be present > on delivery even if it is deleted in transit. That is probably > an important case; I don't know how to get it in any other way. > > I haven't come up with a good name for the header, but would > suggest that, given our bad experiences so far with both IMA > (another WG) and IEE (an historical component, and registered > trademark, of IEEE), any names for header fields or parameters > be based on something like "i18n-email" rather than on IMA or > IEE. Given that we have a Content-Type header to describe the format of the =20 body of the message, I would suggest this be a "Header-Type". Then it =20 would need two keywords - let us call them "OLD" and "NEW" for now (I =20 agree the final choice is tricky), where absence of this header implies =20 OLD. Then we might find the need for further parameters (so perhaps it could =20 incorporate what Yoneya suggested in his X-IMA-Downgraded: header, and =20 other useful stuff). So it might look like Header-Type: NEW; language=3Djp_JP Header-Type: OLD; downgraded-by=3D"site-which-downgraded-it" NOTE. Bruce Lilly will shortly be along to remind us of RFC 2277, which =20 REQUIREs us to provide langage information somewhere, so we will have to = =20 think about it at some stage. OTOH, we do NOT want any "charset=3Dutf-8" = =20 parameter. --=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 Dec 09 07:30:40 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 1EkhOa-0004Oa-9r; Fri, 09 Dec 2005 07:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkhOV-0004EN-OH for ima@megatron.ietf.org; Fri, 09 Dec 2005 07:30:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26720 for ; Fri, 9 Dec 2005 07:29:36 -0500 (EST) Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkhOa-0001FG-UI for ima@ietf.org; Fri, 09 Dec 2005 07:30:42 -0500 Received: from host81-144-66-54.midband.mdip.bt.net ([81.144.66.54]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 439978d7.d003.9d; Fri, 9 Dec 2005 12:30:15 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jB9AtfL25530; Fri, 9 Dec 2005 10:55:42 GMT To: "John C Klensin" , ima@ietf.org References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <995FDB9A1E0731F0215362CE@scan.jck.com> Message-ID: Date: Fri, 09 Dec 2005 10:55:35 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <995FDB9A1E0731F0215362CE@scan.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA26720 Cc: Subject: [IEE] Re: [IMA] URIs/IRIs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Thu, 08 Dec 2005 21:07:54 -0000, John C Klensin wrot= e: > --On Thursday, 08 December, 2005 14:56 +0000 Charles Lindsey > wrote: >> I grant you that if one invented a header >> Use-Header-Parsing Syntax: A (or B) >> where syntaxes A and B were mutually incompatible, then you >> would have real problems (for example if, in MIME Version >> 2.0, the old Content-Type syntax is not a subset of the new). >> But in the case we are considering that would not be so - if >> you know how to parse the extended syntax then you can still >> parse the old, and if you cannot parse the new, then it >> should never have been sent to you in the first place. > > But the "new" is a serious error under the old, whether one can > parse it or not. Indeed, but it would be a protocol violation to send a "new" header to =20 some agent without first checking it had the capability to process it, in= =20 which case "garbage in/garbage out" would apply. Of course, when designin= g =20 the protocol we need to satisfy ourselves that it is robust enough for =20 such accidents to be rare (but for sure there will always be a few =20 rfc-ignorant sites out there). The 'label' header that is proposed is not intended to be used by agents = =20 in order to determine what parsing syntax to use (if they know how to =20 parse "new" headers at all, then that capability should be turned on =20 permanently, because "old" is a subset of "new"). But one of the proper uses for the proposed 'label' header *would* be for= =20 an agent (which could not tell by other knowledge available to it) to =20 decide whether it was necessary to check the capabilities of the next =20 agent it was about to contact. --=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 Dec 09 22:17:36 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 1EkvEu-0002Y4-AE; Fri, 09 Dec 2005 22:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkvEr-0002Wx-40 for ima@megatron.ietf.org; Fri, 09 Dec 2005 22:17:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02905 for ; Fri, 9 Dec 2005 22:16:00 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkvEW-0005pD-5X for ima@ietf.org; Fri, 09 Dec 2005 22:17:13 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jBA3GBu17174; Sat, 10 Dec 2005 12:16:11 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 12ba_504ac3d6_692b_11da_883e_00304811fd80; Sat, 10 Dec 2005 12:16:10 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jBA3ENVW023741; Sat, 10 Dec 2005 12:15:19 +0900 Message-Id: <6.0.0.20.2.20051209101214.07b43060@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 09 Dec 2005 14:17:05 +0900 To: John C Klensin , Charles Lindsey , ima@ietf.org From: Martin Duerst In-Reply-To: <995FDB9A1E0731F0215362CE@scan.jck.com> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <995FDB9A1E0731F0215362CE@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Subject: [IEE] Re: [IMA] URIs/IRIs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org At 06:07 05/12/09, John C Klensin wrote: >--On Thursday, 08 December, 2005 14:56 +0000 Charles Lindsey > wrote: >> One of the properties we are trying to achieve is that no IEE >> message is sent to another agent without first establishing >> (by looking at the capabilities advertised) that agent #2 is >> able to handle it (e.g. that its parser will accept the >> extended syntax without needing to look at the 'label' header >> first). > >Yes. But one of the arguments for an indicating header field is >apparently that one should be able to use it to determine >whether a message is really in the new form, absent envelope >capabilities. I don't quite believe that (either?), Just a check: What are, in your view, the reasons for an indicating header field, if any? >> I grant you that if one invented a header >> Use-Header-Parsing Syntax: A (or B) >> where syntaxes A and B were mutually incompatible, then you >> would have real problems (for example if, in MIME Version >> 2.0, the old Content-Type syntax is not a subset of the new). >> But in the case we are considering that would not be so - if >> you know how to parse the extended syntax then you can still >> parse the old, and if you cannot parse the new, then it >> should never have been sent to you in the first place. > >But the "new" is a serious error under the old, whether one can >parse it or not. Yes, but I think what Charles is trying to say is that the new never appears under the old. The reason is that only email addresses with a truely new address need the syntax that includes the backup address. To create an example, let's assume that somebody havs two email addresses, the current one, alice@tromso.edu, and a new one, which I'll denote by ALICE@TROMSO.edu. What's in upper-case here is 'true' UTF-8 (i.e. more than just US-ASCII). Given these two addresses, and [just to take one] the syntax that Charles has proposed, the following addresses will exist: 1) ALICE@TROMSO.edu 2) ALICE@TROMSO.edu|alice@tromso.edu 3) alice@tromso.edu 1) is just a simple new address 2) is a new address that contains the old address 3) is a simple old address So the special combination syntax only appears when there is a new address. Writing something like alice@tromso.edu|alice@tromso.edu just doesn't make sense. Now if we use the rule that in 2), the new form always has to come first, we don't need to rely on another header or anything like that to distinguish new and old. The only thing that's needed is to make sure that 2) can be unambiguosly parsed. For this, in the specific syntax, we would have to prohibit the character "|" in new addresses. Because we are going to define exactly what a new address is, it should not be a problem to exclude "|", or any other character or syntax we choose as a separator. If an ASCII character such as "|" doesn't look desirable, we could also just use a character from Unicode. There's quite a few of them :-). Of course, in that case, it may not be easy to type. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 11 12:54:14 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 1ElVOo-0006en-0N; Sun, 11 Dec 2005 12:54:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElVOl-0006ei-UZ for ima@megatron.ietf.org; Sun, 11 Dec 2005 12:54:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17386 for ; Sun, 11 Dec 2005 12:53:16 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElVPK-0006Ow-GR for ima@ietf.org; Sun, 11 Dec 2005 12:54:50 -0500 Received: from [192.168.0.3] (adsl-71-131-4-199.dsl.sntc01.pacbell.net [71.131.4.199]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jBBHsBh1017141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Dec 2005 09:54:12 -0800 Message-ID: <439C6799.3000607@dcrocker.net> Date: Sun, 11 Dec 2005 09:53:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Charles Lindsey References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: [IEE] Re: [IMA] URIs/IRIs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > One of the properties we are trying to achieve is that no IEE message is > sent to another agent without first establishing (by looking at the > capabilities advertised) that agent #2 is able to handle it (e.g. that > its parser will accept the extended syntax without needing to look at > the 'label' header first). This seems a rather onerous prerequisite. It places an enormous, ongoing barrier to use, given that email does not have any large-scale history with requiring prior knowledge about the recipient. Quite the opposite. That said, folks might want to look at RFC3297, "Content Negotiation for Messaging Services based on Email". John C Klensin wrote: > Yes. But one of the arguments for an indicating header field is > apparently that one should be able to use it to determine > whether a message is really in the new form, absent envelope > capabilities. I don't quite believe that (either?), but, if one > changes the syntax of existing fields, it would require a parser > to handle the headers in two passes --one to look for the Alas, I had missed the 2-pass impact and the fact the related examples do not suffer that bit of overhead. Helpful exchange. It is prompting me to formulate a proposal, sent under separate cover. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 11 13:13:14 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 1ElVhC-0002R0-Id; Sun, 11 Dec 2005 13:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElVh9-0002Qi-Nn for ima@megatron.ietf.org; Sun, 11 Dec 2005 13:13:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19330 for ; Sun, 11 Dec 2005 13:12:08 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElVhe-000735-Gq for ima@ietf.org; Sun, 11 Dec 2005 13:13:43 -0500 Received: from [192.168.0.3] (adsl-71-131-4-199.dsl.sntc01.pacbell.net [71.131.4.199]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jBBIDLEm018907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Dec 2005 10:13:21 -0800 Message-ID: <439C6C17.5000109@dcrocker.net> Date: Sun, 11 Dec 2005 10:12:39 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin References: <6A99DA789ED094B7BE28FE1D@scan.jck.com> In-Reply-To: <6A99DA789ED094B7BE28FE1D@scan.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: [IEE] Packaging IEE Messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Folks, PROBLEMS: The various threads that have explored different ways to make IEE messages -- as distinct from 'legacy' messages -- seem to have uncovered the usual problems of trying to run a dual-stack service. In effect, IEE messages are not compatible with the existing message-parsing infrastructure, so we are trying to find a way to distinguish them, without breaking anything. The SMTP option approach essentially checks for a safe path between originator and recipient. There is a long-term appeal to this approach, given that it provides the cleanest handling of the new object itself. Unfortunately this approach has an enormously high barrier to adoption, since it requires changing much of the SMTP infrastructure before gaining much utility. I am afraid, therefore, that this looks like a good *adjunct* procedure, rather than an appealing first step. Changing the message header, to add a single field -- as a flag -- or multiple fields -- as alternate content -- makes the header a mess to parse, creates dangers with synchronization across headers, and otherwise looks like an attempt to merge two, frankly incompatible formats. One almost wishes that email had an "envelope" header section, as distinct from the "content" header. (In effect, this serves to create an ordering between 2 sets of header fields.) After all, the reason that Content-type works, in describing alternate forms of data, is that it is guaranteed to occur before the content it labels. Hence it does not impose a 2-pass parsing model. TUNNELING: In looking for an approach that might be simple and sufficient, it occurs to me that there is an easy way to achieve a similar effect, that is entirely comfortable within the current SMTP *and* Header processing environment: Content-type: message/iee The new form is entirely packaged as a body-part, within an old-form message. There is no danger to existing parsers or handlers. And there is explicit labeling of the new form. Best of all, this is an approach that is quite similar to that done in adopting MIME and ESMTP. That is, they have proved complementary, with a low barrier to adoption and quite a bit of benefit for early adopters. So, the legacy header is used as an envelope header, and the header within message/iee is used as the "real" rfc2822bis message header. The RFC3297 negotiation mechanism ought to nicely support this enhancement, too. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 11 14:46:39 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 1ElX9b-0006On-He; Sun, 11 Dec 2005 14:46:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElX9Z-0006Kh-DW for ima@megatron.ietf.org; Sun, 11 Dec 2005 14:46:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29881 for ; Sun, 11 Dec 2005 14:45:41 -0500 (EST) Received: from venus.ezyra.com ([65.61.202.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElXAD-0001wg-Nb for ima@ietf.org; Sun, 11 Dec 2005 14:47:18 -0500 Received: from wireless.colubris.com (cpe00035201fd8c-cm0013718d203c.cpe.net.cable.rogers.com [72.60.23.131]) (authenticated bits=0) by venus.ezyra.com (8.13.1/8.13.1) with ESMTP id jBBJkBQk008184 for ; Sun, 11 Dec 2005 11:46:13 -0800 Message-ID: <01d701c5fe8b$87e50690$f6c3df0a@edmontr3> From: "Edmon Chung" To: References: <6A99DA789ED094B7BE28FE1D@scan.jck.com> <439C6C17.5000109@dcrocker.net> Subject: Re: [IEE] Packaging IEE Messages Date: Sun, 11 Dec 2005 14:43:08 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Ezyra-MailScanner-Information: Please contact the ISP for more information X-Ezyra-MailScanner: Found to be clean X-Ezyra-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.112, required 6, AWL 0.94, BAYES_00 -2.60, MIME_BASE64_BLANKS 1.47, MIME_BASE64_TEXT 0.30) X-Ezyra-MailScanner-From: edmon@afilias.info X-Ezyra-MailScanner-To: ima@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0876325381==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0876325381== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0aGluayB0aGlzIGlzIG5vdCBhIGJhZCBpZGVhLiAgSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3Rs eSwgeW91IGFyZSBzdWdnZXN0aW5nIHRvIGhhdmUgYW4gYWRkaXRpb25hbCBwYXJ0IG9mIGEgbXVs dGlwYXJ0IGZvciBhbiBJRUUgSGVhZGVyLCBwZXJoYXBzIGl0IGNvdWxkIGJlOg0KDQpDb250ZW50 LXR5cGU6IGhlYWRlci9pZWUNCg0KVGhhdCB3b3VsZCBiZSBzaW1pbGFyIHRvIG9yIGFsbG93IHNv bWV0aGluZyBJIGhhdmUgY2hhdHRlZCB3aXRoIG90aGVyIGZvbGtzIGJlZm9yZSwgd2hpY2ggaXMs IHRvIGhhdmUgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBoZWFkZXIgc2VjdGlvbiBmb3IgSW50ZXJu YXRpb25hbGl6ZWQgZW1haWwuICBJbiBmYWN0LCB0byB0YWtlIHRoYXQgZnVydGhlciwgaXQgY291 bGQgYmUgYSBmb3VuZGF0aW9uIGZvciBhZGRpdGlvbnMgdG8gaGVhZGVyIGRhdGEgaW4gdGhlIGZ1 dHVyZS4NCg0KVGhlIGhlYWRlciBwb3J0aW9uIGNhbiBldmVuIGJlIHN0cnVjdHVyZWQgaW4geG1s IHRvIGFsbG93IGZvciBleHRlbnNpYmlsdGl5LCBwZXJoYXBzOg0KDQpDb250ZW50LXR5cGU6IGhl YWRlci94bWwNCg0KV2hpY2ggd2lsbCBhbGxvdyBieSBkZWZhdWx0IHVzZSBvZiBVVEY4IGRhdGEu DQoNCkkgZG8gbm90IGludGVuZCB0byBzaWRldHJhY2sgdGhlIGRpc2N1c3Npb24gb2YgSUVFIGhl cmUsIGJ1dCBJIHRoaW5rIGl0IG1pZ2h0IGJlIHdvcnRoIGV4cGxvcmluZyBzaW5jZSB3ZSBhbHJl YWR5IG5lZWQgdG8gYWRkcmVzcyB0aGlzIGlzc3VlLCBwZXJoYXBzIGl0IGlzIHdvcnRoIHRha2lu ZyBhIGxvb2sgYXQgdGhpcy4gIFRoZSBhZHZhbnRhZ2Ugb2YgdXNpbmcgYW4geG1sIHNjaGVtZSBp cyB0byBhbGxvdyBmb3IgZXh0ZW5zaW9uIGFuZCB3ZSBjYW4gc3RhcnQgc21hbGwsIGZvY3VzaW5n IG9ubHkgb24gSUVFIHJlcXVpcmVkIGZpZWxkcy4gIElmIHRoZXJlIGhhcHBlbnMgdG8gYmUgaW50 ZXJlc3QgaW4gdGhlIGZ1dHVyZSwgaXQgaXMgdGhlbiBwb3NzaWJsZSB0byBpbmNvcnBvcmF0ZSBt dWNoIG1vcmUgZmllbGRzIChmb3Igd2hpY2ggbWF5IG5vdCBiZSBuZWNlc3NhcnkgdG8gcmVwZWF0 IGluIHRoZSBjdXJyZW50IGhlYWRlcikuDQoNCkVkbW9uDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ3JvY2tlciIgPGRoYzJAZGNyb2NrZXIubmV0Pg0K VG86ICJKb2huIEMgS2xlbnNpbiIgPGtsZW5zaW5AamNrLmNvbT4NCkNjOiA8aW1hQGlldGYub3Jn Pg0KU2VudDogU3VuZGF5LCBEZWNlbWJlciAxMSwgMjAwNSAxOjEyIFBNDQpTdWJqZWN0OiBbSUVF XSBQYWNrYWdpbmcgSUVFIE1lc3NhZ2VzDQoNCg0KPiBGb2xrcywNCj4gDQo+IA0KPiBQUk9CTEVN UzoNCj4gDQo+IFRoZSB2YXJpb3VzIHRocmVhZHMgdGhhdCBoYXZlIGV4cGxvcmVkIGRpZmZlcmVu dCB3YXlzIHRvIG1ha2UgSUVFIA0KPiBtZXNzYWdlcyAtLSBhcyBkaXN0aW5jdCBmcm9tICdsZWdh Y3knIG1lc3NhZ2VzIC0tIHNlZW0gdG8gaGF2ZSB1bmNvdmVyZWQgDQo+IHRoZSB1c3VhbCBwcm9i bGVtcyBvZiB0cnlpbmcgdG8gcnVuIGEgZHVhbC1zdGFjayBzZXJ2aWNlLiAgSW4gZWZmZWN0LCAN Cj4gSUVFIG1lc3NhZ2VzIGFyZSBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBleGlzdGluZyBtZXNz YWdlLXBhcnNpbmcgDQo+IGluZnJhc3RydWN0dXJlLCBzbyB3ZSBhcmUgdHJ5aW5nIHRvIGZpbmQg YSB3YXkgdG8gZGlzdGluZ3Vpc2ggdGhlbSwgDQo+IHdpdGhvdXQgYnJlYWtpbmcgYW55dGhpbmcu DQo+IA0KPiBUaGUgU01UUCBvcHRpb24gYXBwcm9hY2ggZXNzZW50aWFsbHkgY2hlY2tzIGZvciBh IHNhZmUgcGF0aCBiZXR3ZWVuIA0KPiBvcmlnaW5hdG9yIGFuZCByZWNpcGllbnQuICBUaGVyZSBp cyBhIGxvbmctdGVybSBhcHBlYWwgdG8gdGhpcyBhcHByb2FjaCwgDQo+IGdpdmVuIHRoYXQgaXQg cHJvdmlkZXMgdGhlIGNsZWFuZXN0IGhhbmRsaW5nIG9mIHRoZSBuZXcgb2JqZWN0IGl0c2VsZi4g DQo+IFVuZm9ydHVuYXRlbHkgdGhpcyBhcHByb2FjaCBoYXMgYW4gZW5vcm1vdXNseSBoaWdoIGJh cnJpZXIgdG8gYWRvcHRpb24sIA0KPiBzaW5jZSBpdCByZXF1aXJlcyBjaGFuZ2luZyBtdWNoIG9m IHRoZSBTTVRQIGluZnJhc3RydWN0dXJlIGJlZm9yZSANCj4gZ2FpbmluZyBtdWNoIHV0aWxpdHku IEkgYW0gYWZyYWlkLCB0aGVyZWZvcmUsIHRoYXQgdGhpcyBsb29rcyBsaWtlIGEgDQo+IGdvb2Qg KmFkanVuY3QqIHByb2NlZHVyZSwgcmF0aGVyIHRoYW4gYW4gYXBwZWFsaW5nIGZpcnN0IHN0ZXAu DQo+IA0KPiBDaGFuZ2luZyB0aGUgbWVzc2FnZSBoZWFkZXIsIHRvIGFkZCBhIHNpbmdsZSBmaWVs ZCAtLSBhcyBhIGZsYWcgLS0gb3IgDQo+IG11bHRpcGxlIGZpZWxkcyAtLSBhcyBhbHRlcm5hdGUg Y29udGVudCAtLSBtYWtlcyB0aGUgaGVhZGVyIGEgbWVzcyB0byANCj4gcGFyc2UsIGNyZWF0ZXMg ZGFuZ2VycyB3aXRoIHN5bmNocm9uaXphdGlvbiBhY3Jvc3MgaGVhZGVycywgYW5kIA0KPiBvdGhl cndpc2UgbG9va3MgbGlrZSBhbiBhdHRlbXB0IHRvIG1lcmdlIHR3bywgZnJhbmtseSBpbmNvbXBh dGlibGUgZm9ybWF0cy4NCj4gDQo+IE9uZSBhbG1vc3Qgd2lzaGVzIHRoYXQgZW1haWwgaGFkIGFu ICJlbnZlbG9wZSIgaGVhZGVyIHNlY3Rpb24sIGFzIA0KPiBkaXN0aW5jdCBmcm9tIHRoZSAiY29u dGVudCIgaGVhZGVyLiAgKEluIGVmZmVjdCwgdGhpcyBzZXJ2ZXMgdG8gY3JlYXRlIA0KPiBhbiBv cmRlcmluZyBiZXR3ZWVuIDIgc2V0cyBvZiBoZWFkZXIgZmllbGRzLikgIEFmdGVyIGFsbCwgdGhl IHJlYXNvbiANCj4gdGhhdCBDb250ZW50LXR5cGUgd29ya3MsIGluIGRlc2NyaWJpbmcgYWx0ZXJu YXRlIGZvcm1zIG9mIGRhdGEsIGlzIHRoYXQgDQo+IGl0IGlzIGd1YXJhbnRlZWQgdG8gb2NjdXIg YmVmb3JlIHRoZSBjb250ZW50IGl0IGxhYmVscy4gIEhlbmNlIGl0IGRvZXMgDQo+IG5vdCBpbXBv c2UgYSAyLXBhc3MgcGFyc2luZyBtb2RlbC4NCj4gDQo+IA0KPiANCj4gVFVOTkVMSU5HOg0KPiAN Cj4gSW4gbG9va2luZyBmb3IgYW4gYXBwcm9hY2ggdGhhdCBtaWdodCBiZSBzaW1wbGUgYW5kIHN1 ZmZpY2llbnQsIGl0IA0KPiBvY2N1cnMgdG8gbWUgdGhhdCB0aGVyZSBpcyBhbiBlYXN5IHdheSB0 byBhY2hpZXZlIGEgc2ltaWxhciBlZmZlY3QsIHRoYXQgDQo+IGlzIGVudGlyZWx5IGNvbWZvcnRh YmxlIHdpdGhpbiB0aGUgY3VycmVudCBTTVRQICphbmQqIEhlYWRlciBwcm9jZXNzaW5nIA0KPiBl bnZpcm9ubWVudDoNCj4gDQo+ICAgIENvbnRlbnQtdHlwZTogbWVzc2FnZS9pZWUNCj4gDQo+IFRo ZSBuZXcgZm9ybSBpcyBlbnRpcmVseSBwYWNrYWdlZCBhcyBhIGJvZHktcGFydCwgd2l0aGluIGFu IG9sZC1mb3JtIA0KPiBtZXNzYWdlLiAgVGhlcmUgaXMgbm8gZGFuZ2VyIHRvIGV4aXN0aW5nIHBh cnNlcnMgb3IgaGFuZGxlcnMuICBBbmQgdGhlcmUgDQo+IGlzIGV4cGxpY2l0IGxhYmVsaW5nIG9m IHRoZSBuZXcgZm9ybS4NCj4gDQo+IEJlc3Qgb2YgYWxsLCB0aGlzIGlzIGFuIGFwcHJvYWNoIHRo YXQgaXMgcXVpdGUgc2ltaWxhciB0byB0aGF0IGRvbmUgaW4gDQo+IGFkb3B0aW5nIE1JTUUgYW5k IEVTTVRQLiAgVGhhdCBpcywgdGhleSBoYXZlIHByb3ZlZCBjb21wbGVtZW50YXJ5LCB3aXRoIA0K PiBhIGxvdyBiYXJyaWVyIHRvIGFkb3B0aW9uIGFuZCBxdWl0ZSBhIGJpdCBvZiBiZW5lZml0IGZv ciBlYXJseSBhZG9wdGVycy4NCj4gDQo+IFNvLCB0aGUgbGVnYWN5IGhlYWRlciBpcyB1c2VkIGFz IGFuIGVudmVsb3BlIGhlYWRlciwgYW5kIHRoZSBoZWFkZXIgDQo+IHdpdGhpbiBtZXNzYWdlL2ll ZSBpcyB1c2VkIGFzIHRoZSAicmVhbCIgcmZjMjgyMmJpcyBtZXNzYWdlIGhlYWRlci4NCj4gDQo+ IFRoZSBSRkMzMjk3IG5lZ290aWF0aW9uIG1lY2hhbmlzbSBvdWdodCB0byBuaWNlbHkgc3VwcG9y dCB0aGlzIA0KPiBlbmhhbmNlbWVudCwgdG9vLg0KPiANCj4gZC8NCj4gLS0gDQo+IA0KPiAgRGF2 ZSBDcm9ja2VyDQo+ICBCcmFuZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmcNCj4gICsxLjQwOC4yNDYu ODI1Mw0KPiAgZGNyb2NrZXIgIGEgdCAuLi4NCj4gIFdFJ1ZFIE1PVkVEIHRvOiAgd3d3LmJiaXcu bmV0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4gDQo+ --===============0876325381== 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 --===============0876325381==-- From ima-bounces@ietf.org Sun Dec 11 15:54:02 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 1ElYCo-0004bW-5I; Sun, 11 Dec 2005 15:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElYCj-0004bJ-IV for ima@megatron.ietf.org; Sun, 11 Dec 2005 15:54:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06613 for ; Sun, 11 Dec 2005 15:52:53 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElYDF-00049R-On for ima@ietf.org; Sun, 11 Dec 2005 15:54:31 -0500 Received: from [192.168.0.3] (adsl-71-131-4-199.dsl.sntc01.pacbell.net [71.131.4.199]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jBBKsCDG001490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Dec 2005 12:54:13 -0800 Message-ID: <439C91CB.3040300@dcrocker.net> Date: Sun, 11 Dec 2005 12:53:31 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Edmon Chung Subject: Re: [IEE] Packaging IEE Messages References: <6A99DA789ED094B7BE28FE1D@scan.jck.com> <439C6C17.5000109@dcrocker.net> <01d701c5fe8b$87e50690$f6c3df0a@edmontr3> In-Reply-To: <01d701c5fe8b$87e50690$f6c3df0a@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Edmon Chung wrote: > I think this is not a bad idea. If I understand correctly, you are > suggesting to have an additional part of a multipart for an IEE > Header, perhaps it could be: > > Content-type: header/iee Since there is no "major" type of "header", I am not suggesting creating one. I am suggesting a new form of "message" content type, so that rather than Content-type:Message/RFC822, there is Content-type:message/IEE. If would contain one entire message, complete with RFC2822bis IEE header and the associated body content. So a message would be: RFC2822 header Content-type: message/iee Mime-header for message/iee RFC2822bis IEE header MIME body for IEE header Of course, there is nothing preventing more elaborate uses, in which the message/iee portion is merely one body-part out of several. -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 11 20:57:12 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 1ElcwC-000347-Sq; Sun, 11 Dec 2005 20:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElcwB-00033M-OX for ima@megatron.ietf.org; Sun, 11 Dec 2005 20:57:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06301 for ; Sun, 11 Dec 2005 20:56:15 -0500 (EST) Received: from venus.ezyra.com ([65.61.202.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elcws-0005aN-GI for ima@ietf.org; Sun, 11 Dec 2005 20:57:55 -0500 Received: from wireless.colubris.com (cpe00035201fd8c-cm0013718d203c.cpe.net.cable.rogers.com [72.60.23.131]) (authenticated bits=0) by venus.ezyra.com (8.13.1/8.13.1) with ESMTP id jBC1upGE009033 for ; Sun, 11 Dec 2005 17:56:53 -0800 Message-ID: <01f201c5febf$501acef0$f6c3df0a@edmontr3> From: "Edmon Chung" To: References: <6A99DA789ED094B7BE28FE1D@scan.jck.com> <439C6C17.5000109@dcrocker.net> <01d701c5fe8b$87e50690$f6c3df0a@edmontr3> <439C91CB.3040300@dcrocker.net> Subject: Re: [IEE] Packaging IEE Messages Date: Sun, 11 Dec 2005 20:55:33 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Ezyra-MailScanner-Information: Please contact the ISP for more information X-Ezyra-MailScanner: Found to be clean X-Ezyra-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.36, required 6, AWL 0.47, BAYES_00 -2.60, MIME_BASE64_BLANKS 1.47, MIME_BASE64_TEXT 0.30) X-Ezyra-MailScanner-From: edmon@afilias.info X-Ezyra-MailScanner-To: ima@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487149492==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1487149492== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 T0suIFNvIGVzc2VudGlhbGx5IGl0IHdvdWxkIG9ubHkgYmUgYSAic3R1YiIgZm9yIElFRSBpbmZv cm1hdGlvbj8NCkVkbW9uDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIkRhdmUgQ3JvY2tlciIgPGRoYzJAZGNyb2NrZXIubmV0Pg0KVG86ICJFZG1vbiBDaHVuZyIg PGVkbW9uQGFmaWxpYXMuaW5mbz4NCkNjOiA8aW1hQGlldGYub3JnPg0KU2VudDogU3VuZGF5LCBE ZWNlbWJlciAxMSwgMjAwNSAzOjUzIFBNDQpTdWJqZWN0OiBSZTogW0lFRV0gUGFja2FnaW5nIElF RSBNZXNzYWdlcw0KDQoNCj4gRWRtb24gQ2h1bmcgd3JvdGU6DQo+PiBJIHRoaW5rIHRoaXMgaXMg bm90IGEgYmFkIGlkZWEuICBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB5b3UgYXJlDQo+PiBz dWdnZXN0aW5nIHRvIGhhdmUgYW4gYWRkaXRpb25hbCBwYXJ0IG9mIGEgbXVsdGlwYXJ0IGZvciBh biBJRUUNCj4+IEhlYWRlciwgcGVyaGFwcyBpdCBjb3VsZCBiZToNCj4+IA0KPj4gQ29udGVudC10 eXBlOiBoZWFkZXIvaWVlDQo+IA0KPiBTaW5jZSB0aGVyZSBpcyBubyAibWFqb3IiIHR5cGUgb2Yg ImhlYWRlciIsIEkgYW0gbm90IHN1Z2dlc3RpbmcgY3JlYXRpbmcNCj4gb25lLg0KPiANCj4gSSBh bSBzdWdnZXN0aW5nIGEgbmV3IGZvcm0gb2YgIm1lc3NhZ2UiIGNvbnRlbnQgdHlwZSwgc28gdGhh dA0KPiByYXRoZXIgdGhhbiBDb250ZW50LXR5cGU6TWVzc2FnZS9SRkM4MjIsIHRoZXJlIGlzDQo+ IENvbnRlbnQtdHlwZTptZXNzYWdlL0lFRS4gIElmIHdvdWxkIGNvbnRhaW4gb25lIGVudGlyZSBt ZXNzYWdlLCBjb21wbGV0ZQ0KPiB3aXRoIFJGQzI4MjJiaXMgSUVFIGhlYWRlciBhbmQgdGhlIGFz c29jaWF0ZWQgYm9keSBjb250ZW50Lg0KPiANCj4gU28gYSBtZXNzYWdlIHdvdWxkIGJlOg0KPiAN Cj4gUkZDMjgyMiBoZWFkZXINCj4gQ29udGVudC10eXBlOiBtZXNzYWdlL2llZQ0KPiANCj4gICAg TWltZS1oZWFkZXIgZm9yIG1lc3NhZ2UvaWVlDQo+IA0KPiAgICAgICBSRkMyODIyYmlzIElFRSBo ZWFkZXINCj4gDQo+ICAgICAgIE1JTUUgYm9keSBmb3IgSUVFIGhlYWRlcg0KPiANCj4gT2YgY291 cnNlLCB0aGVyZSBpcyBub3RoaW5nIHByZXZlbnRpbmcgbW9yZSBlbGFib3JhdGUgdXNlcywgaW4g d2hpY2ggdGhlIA0KPiBtZXNzYWdlL2llZSBwb3J0aW9uIGlzIG1lcmVseSBvbmUgYm9keS1wYXJ0 IG91dCBvZiBzZXZlcmFsLg0KPiANCj4gDQo+IA0KPiAtLSANCj4gDQo+ICAgRGF2ZSBDcm9ja2Vy DQo+ICAgQnJhbmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nDQo+ICAgKzEuNDA4LjI0Ni44MjUzDQo+ ICAgZGNyb2NrZXIgIGEgdCAuLi4NCj4gICBXRSdWRSBNT1ZFRCB0bzogIHd3dy5iYml3Lm5ldA0K PiANCj4= --===============1487149492== 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 --===============1487149492==-- From ima-bounces@ietf.org Mon Dec 12 12:16:47 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 1ElrI7-0007re-Q3; Mon, 12 Dec 2005 12:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElrI3-0007p9-D3 for ima@megatron.ietf.org; Mon, 12 Dec 2005 12:16:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19306 for ; Mon, 12 Dec 2005 12:15:35 -0500 (EST) Received: from lon-mail-2.gradwell.net ([193.111.201.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElrIh-0003ty-Ag for ima@ietf.org; Mon, 12 Dec 2005 12:17:24 -0500 Received: from host81-144-66-202.midband.mdip.bt.net ([81.144.66.202]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 439db060.1701e.4e for ima@ietf.org; Mon, 12 Dec 2005 17:16:16 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jBCElLL21133 for ; Mon, 12 Dec 2005 14:47:22 GMT To: "ima@ietf.org" Subject: Re: [IEE] Re: [IMA] URIs/IRIs References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> Message-ID: Date: Mon, 12 Dec 2005 14:47:17 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <439C6799.3000607@dcrocker.net> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA19306 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Sun, 11 Dec 2005 17:53:29 -0000, Dave Crocker wrot= e: > Charles Lindsey wrote: >> One of the properties we are trying to achieve is that no IEE message = =20 >> is sent to another agent without first establishing (by looking at the= =20 >> capabilities advertised) that agent #2 is able to handle it (e.g. that= =20 >> its parser will accept the extended syntax without needing to look at = =20 >> the 'label' header first). > > This seems a rather onerous prerequisite. It places an enormous, =20 > ongoing barrier to use, given that email does not have any large-scale = =20 > history with requiring prior knowledge about the recipient. Quite the = =20 > opposite. Nevertheless, it is the prequisite implied by John's original 'Framework'= =20 draft and by the draft charter of the proposed WG, and it is the reason w= e =20 are to be charged with producing an Experimental ID, rather than a =20 Proposed Standard. Moreover, it was the prequisite for the 8BITMIME idea = =20 many years back. If you want to send a message to someone in Chinese, then it is a good =20 idea to be sure in advance that he understands Chinese (and has software = =20 that will cope). Likewise, if you want to send an IEE message with header= s =20 in UTF-8. --=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 Mon Dec 12 12:16:49 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 1ElrI9-0007rp-12; Mon, 12 Dec 2005 12:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElrI5-0007oy-SJ for ima@megatron.ietf.org; Mon, 12 Dec 2005 12:16:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19309 for ; Mon, 12 Dec 2005 12:15:35 -0500 (EST) Received: from lon-mail-2.gradwell.net ([193.111.201.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElrIh-0003tz-Ag for ima@ietf.org; Mon, 12 Dec 2005 12:17:25 -0500 Received: from host81-144-66-202.midband.mdip.bt.net ([81.144.66.202]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 439db061.1701e.4f for ima@ietf.org; Mon, 12 Dec 2005 17:16:17 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jBCFHKL21179 for ; Mon, 12 Dec 2005 15:17:20 GMT To: "ima@ietf.org" Subject: Re: [IEE] Re: [IMA] URIs/IRIs References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <995FDB9A1E0731F0215362CE@scan.jck.com> <6.0.0.20.2.20051209101214.07b43060@localhost> Message-ID: Date: Mon, 12 Dec 2005 15:17:16 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <6.0.0.20.2.20051209101214.07b43060@localhost> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA19309 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Fri, 09 Dec 2005 05:17:05 -0000, Martin Duerst =20 wrote: > At 06:07 05/12/09, John C Klensin wrote: > > >--On Thursday, 08 December, 2005 14:56 +0000 Charles Lindsey > > wrote: > > >> One of the properties we are trying to achieve is that no IEE > >> message is sent to another agent without first establishing > >> (by looking at the capabilities advertised) that agent #2 is > >> able to handle it (e.g. that its parser will accept the > >> extended syntax without needing to look at the 'label' header > >> first). > > > >Yes. But one of the arguments for an indicating header field is > >apparently that one should be able to use it to determine > >whether a message is really in the new form, absent envelope > >capabilities. I don't quite believe that (either?), > > Just a check: What are, in your view, the reasons for an > indicating header field, if any? So that any agent which is asked to handle the message (and that includes= =20 confused human agents), and cannot tell whether it is IEE just from the =20 envelope (if any), can take steps to do any special processing that may b= e =20 needed. Special processing might include .Not forwarding it to other agents which did not announce the necessary =20 capability. .Downgrading it .Bouncing it .Deciding (inside some upgraded IMAP setup) that it could be delivered in= =20 UTF-8 rather than UTF-7 (though we have a lot of work to do when it comes= =20 to proposing an IMAP extension for all this). > > >> I grant you that if one invented a header > >> Use-Header-Parsing Syntax: A (or B) > >> where syntaxes A and B were mutually incompatible, then you > >> would have real problems (for example if, in MIME Version > >> 2.0, the old Content-Type syntax is not a subset of the new). > >> But in the case we are considering that would not be so - if > >> you know how to parse the extended syntax then you can still > >> parse the old, and if you cannot parse the new, then it > >> should never have been sent to you in the first place. > ... To create an example, let's assume that somebody > havs two email addresses, the current one, alice@tromso.edu, > and a new one, which I'll denote by ALICE@TROMSO.edu. > What's in upper-case here is 'true' UTF-8 (i.e. more than just > US-ASCII). Given these two addresses, and [just to take one] > the syntax that Charles has proposed, the following addresses > will exist: > 1) ALICE@TROMSO.edu > 2) ALICE@TROMSO.edu|alice@tromso.edu > 3) alice@tromso.edu > > 1) is just a simple new address > 2) is a new address that contains the old address > 3) is a simple old address > If an ASCII character such as "|" doesn't look desirable, we > could also just use a character from Unicode. There's quite > a few of them :-). Of course, in that case, it may not be > easy to type. Hmmm! It seems '|' is a member of and hence can appear in an atom= , =20 but is still not allowed in a present =20 because it has two '@'s in it. Perhaps `\` would be safer, or = =20 we could enclose the alternate address in [...] as in =20 . It is hardly rocket science to =20 devise syntax that would work. --=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 Mon Dec 12 12:48:46 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 1Elrn4-0006UY-2Z; Mon, 12 Dec 2005 12:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elrn2-0006UI-Kk for ima@megatron.ietf.org; Mon, 12 Dec 2005 12:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22533 for ; Mon, 12 Dec 2005 12:47:39 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elrnh-0004tQ-Mk for ima@ietf.org; Mon, 12 Dec 2005 12:49:27 -0500 Received: from [192.168.0.3] (adsl-71-131-72-163.dsl.sntc01.pacbell.net [71.131.72.163]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jBCHmRXP027935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Dec 2005 09:48:27 -0800 Message-ID: <439DB7C1.8020009@dcrocker.net> Date: Mon, 12 Dec 2005 09:47:45 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [IEE] Re: [IMA] URIs/IRIs References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org >> This seems a rather onerous prerequisite. ... > > Nevertheless, it is the prequisite implied by John's original > 'Framework' draft and by the draft charter of the proposed WG, and it is > the reason we are to be charged with producing an Experimental ID, > rather than a Proposed Standard. Moreover, it was the prequisite for the > 8BITMIME idea many years back. Charles, Were this a working group with a charter, then excluding something like my suggestion, as being out of scope, would make a lot of sense. But this is a working group in formation, where consideration of the pragmatics constraining particular approaches is more than reasonable. I cited the MIME/ESMTP (8bitmime) example, too. I did that because it demonstrated an approach that worked quite well, and achieved initial utility with the MIME mechanism. Meaningful infrastructure change, to support the 8bitmime ESMTP option took much longer. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 12 13:19:54 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 1ElsHC-00053g-7T; Mon, 12 Dec 2005 13:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsH8-00052B-MY for ima@megatron.ietf.org; Mon, 12 Dec 2005 13:19:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26367 for ; Mon, 12 Dec 2005 13:18:47 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElsHq-0005zg-NF for ima@ietf.org; Mon, 12 Dec 2005 13:20:35 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ElsGx-000Ab8-L4; Mon, 12 Dec 2005 13:19:39 -0500 Date: Mon, 12 Dec 2005 13:19:39 -0500 From: John C Klensin To: dcrocker@bbiw.net Message-ID: <5C14091E1C376EFB59ED81A2@scan.jck.com> In-Reply-To: <439C6C17.5000109@dcrocker.net> References: <6A99DA789ED094B7BE28FE1D@scan.jck.com> <439C6C17.5000109@dcrocker.net> 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: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: [IEE] IEE/IMA/i18n email Procedural note (was: Re: Packaging IEE Messages) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Dave, There are several different issues here, some technical and some procedural. I will try to respond to the technical ones in a separate note, but want to address the procedural one first. Partially at the suggestion of the ADs, this effort is oriented toward exploration of one particular approach toward internationalization of email. The intent is to explore that approach through experimental RFCs, implementation, and evaluation of those implementations. While, based on doing a lot of analysis on my own, I personally have my doubts, other approaches are, of course, possible. But neither exploring them nor proving that this approach is the best of all possible ones are the topic of this effort. The clear requirements for the present effort include being able to use i18n addresses on the network without loss of functionality. More specifically, the objective is to permit those who want to use non-ASCII local parts in addresses to do so without incurring any long-term penalties vis-a-vis those who happen to prefer to write their addresses entirely in ASCII characters. Message encapsulation may well have a role in downgrading (indeed, it is my personal hunch that will turn out to be the most viable -- or least-unviable) of downgrade approaches), but, for conventional use in conventional email, forcing a different message structure on i18n email than that which is used for mail with ASCII-based addresses is not acceptable --at least within the bounds and focus of the current effort. Within the bounds of the thinking that has motivated this effort, the reason for UTF-8 headers isn't as an end in themselves, but because i18n addressing appears to make those headers the least complex option (an insight for which I need to thank Paul Hoffman). In addition to those requirements, there is an assumption that should probably be explicit if it is not clear already: The primary target is effective, long-term, communication within communities that use the same language in a way that is compatible with the Internet email infrastructure. The other cases are less important in practice because, if I send you a message whose addresses and content you can't read, can't type, and may not even be able to accurately cut and paste, it isn't going to do you a tremendous amount of good. Because of that, it also won't be a common case. It is obviously desirable that you be able to translate (or decode) it if you want to --which is one of many reasons why formats, infrastructure, and definitions need to remain within the bounds of a single Internet standard-- but, if that is a tad more difficult that it might be as a consequence of optimizing things for users who share languages and scripts, that is probably reasonable. Conversely, imposing kludges --or different message structure organization-- on anyone who chooses to use a non-ASCII address for communication with others within their language and script community is not reasonable. I note that we got this right with MIME: the "content-type: text/plain; charset=XXX" structure is the same regardless of the value of XXX -- we did not require an embedded message structure for anyone using a non-ASCII charset. One corollary to that assumption is that these changes will deploy rapidly within the self-defined communities that see themselves as needing it most. Note that statement is nearly tautological: if I'm part of a community that, as a community, is very anxious to deploy i18n email, then I, and that community, will see that the needed pieces are in place for our use. Downgrading is important for people who are part of the community from a cultural and linguistic perspective but not part of it geographically or topologically. It is less important (one can debate how much less, but I'm not convinced that question is interesting) for communications between communities. The goal of this effort thus focuses on finding a way to do i18n email that will serve the community who want to use it well _and_ avoid causing harm or unexpected surprises to those for which it is less important or irrelevant. Just as it does not aspire to have me learn Chinese or you learn Swahili (much as either of us might aspire to do so), it puts much less emphasis on effective communication and regular use across languages, scripts, and cultural groups. The more technical note will follow, but please consider it in the context of the above and, if you want to go to work on a different approach, please take it somewhere else. john So, at a procedural level --On Sunday, 11 December, 2005 10:12 -0800 Dave Crocker wrote: >... > TUNNELING: > > In looking for an approach that might be simple and > sufficient, it occurs to me that there is an easy way to > achieve a similar effect, that is entirely comfortable within > the current SMTP *and* Header processing environment: > > Content-type: message/iee > > The new form is entirely packaged as a body-part, within an > old-form message. There is no danger to existing parsers or > handlers. And there is explicit labeling of the new form. >... > So, the legacy header is used as an envelope header, and the > header within message/iee is used as the "real" rfc2822bis > message header. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 12 15:17:36 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 1Elu76-00074s-Hx; Mon, 12 Dec 2005 15:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elu74-00073S-Vz for ima@megatron.ietf.org; Mon, 12 Dec 2005 15:17:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19157 for ; Mon, 12 Dec 2005 15:16:26 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elu7j-0004LH-1v for ima@ietf.org; Mon, 12 Dec 2005 15:18:16 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1Elu6q-000Ay5-Dk; Mon, 12 Dec 2005 15:17:20 -0500 Date: Mon, 12 Dec 2005 15:17:20 -0500 From: John C Klensin To: dcrocker@bbiw.net Message-ID: 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: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: [IEE] Tunneling and packaging (was: Re: Packaging IEE Messages) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Dave, This is the more technical response I promised. As suggested in the prior, procedural, note I think it deserves a response because I believe that a tunneling/embedding approach may be of great value in downgrading and hence should be better understood. But I don't see it as an alternative to the present proposals, only partially because of the reasons explained below. I've tried to respond below to a few questions and comments from Charles and Martin, since this seems to be the right context. --On Sunday, 11 December, 2005 10:12 -0800 Dave Crocker wrote: >... > PROBLEMS: > > The various threads that have explored different ways to make > IEE messages -- as distinct from 'legacy' messages -- seem to > have uncovered the usual problems of trying to run a > dual-stack service. In effect, IEE messages are not > compatible with the existing message-parsing infrastructure, > so we are trying to find a way to distinguish them, without > breaking anything. Well, it does more than that, although what it does depends on a number of assumptions about implementations and design. Whether those assumptions are reasonable or not is an analysis that will have to be part of this effort. One of those assumptions is that the typical implementation of i18n messages will simply be 8bit clean, and UTF-8 clean, internally with some adjustments to compensate for this protocol. If the result of this approach requires running what are essentially two different protocols over the same port and signaling path, as your comments about "dual-stack", etc., suggest, then we are in big trouble. We have looked briefly (again, more work needs to be done) at a few MUA and MTA implementations in UTF-8 operating environments, and implementation of the proposed protocol (absent downgrading and as of the time of the Vancouver IETF) appears to require: * Disabling the syntax check requiring that addresses be in ASCII * Disabling the syntax check requiring that headers be in ASCII * Adding the appropriate capability announcement to the EHLO response in the SMTP server. You will note the strong resemblance between this and most practical (and actual) implementations of 8BITMIME. That option (again, modulo downgrading) is really not "I have these special capabilities" or "I have dual-stack-like capability for handling that bizarre form" but "my code paths can accept this without problem". This is why I've been resistant to Charles's suggestions about changing the syntax of various header lines. I think that requires, not disabling a few tests, but recasting every MUA (or other module that deals with headers) to support a dual code path and turns implementing this into a much bigger deal. The answer to Martin's question in that regard is that I'm still unconvinced that a specific marker is needed except maybe after delivery. If folks want it, adding it is pretty painless as far as I can tell, but necessity is still, IMO, not demonstrated. > The SMTP option approach essentially checks for a safe path > between originator and recipient. There is a long-term appeal > to this approach, given that it provides the cleanest handling > of the new object itself. Unfortunately this approach has an > enormously high barrier to adoption, since it requires > changing much of the SMTP infrastructure before gaining much > utility. I am afraid, therefore, that this looks like a good > *adjunct* procedure, rather than an appealing first step. See above and my earlier note. From my standpoint, "gaining much utility" has to do with communities who need this and mutually consent to its use. It is simply not required that it be deployed everywhere on the Internet in order to gain utility, although such deployment would obviously be valuable and increase network effects as it occurs. What is key is that those who have not yet decided to play are protected from any ill side effects as the result of its use by those who are using it. That brings me back to another place where I think Charles and I have a disconnect. SMTP, [2]822, and MIME are an inherently strong-envelope environment, as evidenced by the fact that there is no requirement that any of the envelope addresses appear in the headers. Clearly, there are weak-envelope and no-envelope environments in the mail world. But the right way to deal with them, IMO, is to be sure that the right conversions can be done at gateways, that they have headers (or whatever they use) that can carry the information that strong-envelope environments carry in the envelope (assuming that information is relevant), and so on. The solution is not to try to force the strong envelope environment to turn into a weak envelope one or to create the sorts of redundancies between headers and envelope that have led to trouble over and over again. > Changing the message header, to add a single field -- as a > flag -- or multiple fields -- as alternate content -- makes > the header a mess to parse, creates dangers with > synchronization across headers, and otherwise looks like an > attempt to merge two, frankly incompatible formats. But, unless one wants to do that for other reasons, it is a classic strawman. If one adopted the principle that no downgrading would be done at all prior to MTA final delivery --that sending an i18n message to an MTA that couldn't handle it would result in a bounce (see the framework document and my earlier I-Ds for an analysis of why this wouldn't be quite as terrible as would appear on first glance)-- turns this into a message store and MUA issue, which is quite a different one from worrying about a very heterogeneous origination, transport, and delivery environment. > One almost wishes that email had an "envelope" header section, > as distinct from the "content" header. (In effect, this > serves to create an ordering between 2 sets of header fields.) > After all, the reason that Content-type works, in describing > alternate forms of data, is that it is guaranteed to occur > before the content it labels. Hence it does not impose a > 2-pass parsing model. Yes. Of course. FWIW, I explored this one in draft-klensin-email-envelope-00 almost two years ago. That version of the idea got all of the traction it deserved, i.e., about zero, but the point was that it is possible to make this change if we were really motivated. It stops a bit short of "new mail protocol", but not much. Of course, there is also a strong argument for a three-layer envelope, separating what we describe in Internet mail as the current (addressing and transport instructions) envelope, message trace and related information, and headers, ideally with all three forced into a canonical form rather than having the last two as randomly-ordered text fields. Hmm. I wonder if one could call those P1, P2, and P3? . But that discussion is, IMO fortunately, badly off topic -- see prior note about procedures. > TUNNELING: > > In looking for an approach that might be simple and > sufficient, it occurs to me that there is an easy way to > achieve a similar effect, that is entirely comfortable within > the current SMTP *and* Header processing environment: > > Content-type: message/iee > > The new form is entirely packaged as a body-part, within an > old-form message. There is no danger to existing parsers or > handlers. And there is explicit labeling of the new form. But it prevents the use of internationalized addresses _in the envelope_, which is the key goal of this process. In a 7bit transport environment, it also raises some issues with the double-encoding problem, although I imagine we could work those out. > Best of all, this is an approach that is quite similar to that > done in adopting MIME and ESMTP. That is, they have proved > complementary, with a low barrier to adoption and quite a bit > of benefit for early adopters. But the barriers are not low, since it requires that every MUA that is going to deal with these things contain unpacking logic. It also forces the user (or some very intelligent heuristics and conventions) to be able to decide whether replies are to go to the outer header address (and with those subject lines, in-reply-to fields, etc.) or to the ones contained in the body part. I suggest we have some experience with that exact type of "stacked header" situation and the associated user choices with message/digest and that the experience has not been a happy one ... the end user just needs a little too much understanding. > So, the legacy header is used as an envelope header, and the > header within message/iee is used as the "real" rfc2822bis > message header. Now, all of that said, I suspect that there may be a role for message encapsulation (along the lines of message/iee) for downgrading. If alternate (i.e., ASCII) addresses are available, it might be far more sensible to do downgrading along exactly the lines you suggest, thereby avoiding introducing an entire new header collection and syntax-set just to accommodate the downgrade cases. For a discussion of that theme that is incomplete --but a little more complete than your email message -- see draft-klensin-email-i18n-message-00 (2 Feb 2004). Of course, that approach still has the interpretation and unpacking problems identified above, but it is transitional --part of a temporary problem until more systems either get their configurations together or upgrade to be able to handle i18n mail properly-- not a permanent blot on the landscape and, worse, an impediment to using non-ASCII scripts on the Internet in the same fashion in which ASCII is used. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Dec 12 18:58:27 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 1ElxYp-0003cl-Hx; Mon, 12 Dec 2005 18:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElxYo-0003cI-4L for ima@megatron.ietf.org; Mon, 12 Dec 2005 18:58:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16609 for ; Mon, 12 Dec 2005 18:57:22 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElxZY-0003p0-Hh for ima@ietf.org; Mon, 12 Dec 2005 18:59:13 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ElxYa-000Cgj-Tn; Mon, 12 Dec 2005 18:58:12 -0500 Date: Mon, 12 Dec 2005 18:58:12 -0500 From: John C Klensin To: dcrocker@bbiw.net, Charles Lindsey Subject: Re: [IEE] Re: [IMA] URIs/IRIs Message-ID: <2EB5D130172236F3FFC01367@scan.jck.com> In-Reply-To: <439DB7C1.8020009@dcrocker.net> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> <439DB7C1.8020009@dcrocker.net> 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Monday, 12 December, 2005 09:47 -0800 Dave Crocker wrote: > I cited the MIME/ESMTP (8bitmime) example, too. > > I did that because it demonstrated an approach that worked > quite well, and achieved initial utility with the MIME > mechanism. Meaningful infrastructure change, to support the > 8bitmime ESMTP option took much longer. Actually, I don't think it did. My recollection of what happened was that the collection of MTAs that were (i) 8-bit clean and competent and (ii) came from authors who gave a d**n about standards started advertising the option as soon as they added any ESMTP code. The things that took longer were support for downgrading and support for 8BITMIME in MTAs that had internal 7-bit data paths. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 13 00:03:44 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 1Em2KG-0003Ec-Cv; Tue, 13 Dec 2005 00:03:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em2KF-0003EX-DC for ima@megatron.ietf.org; Tue, 13 Dec 2005 00:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27887 for ; Tue, 13 Dec 2005 00:02:45 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em2LA-0008Nh-CD for ima@ietf.org; Tue, 13 Dec 2005 00:04:41 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1Em2KC-000JON-JG; Tue, 13 Dec 2005 00:03:40 -0500 Date: Tue, 13 Dec 2005 00:03:40 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [IEE] Re: [IMA] URIs/IRIs Message-ID: In-Reply-To: References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> 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: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Monday, 12 December, 2005 14:47 +0000 Charles Lindsey wrote: >> This seems a rather onerous prerequisite. It places an >> enormous, ongoing barrier to use, given that email does not >> have any large-scale history with requiring prior knowledge >> about the recipient. Quite the opposite. > > Nevertheless, it is the prequisite implied by John's original > 'Framework' draft and by the draft charter of the proposed > WG, and it is the reason we are to be charged with producing > an Experimental ID, rather than a Proposed Standard. > Moreover, it was the prequisite for the 8BITMIME idea many > years back. More generally, Dave, it is the condition associated with every single use of the ESMTP mechanism. If the next-hop server does not advertise a capability, one can't use it. In those cases, it is not knowledge about the recipient that is required, but knowledge of the capabilities the next-hop server is willing to assert that it supports. And we certainly haven't found it an "enormous, ongoing barrier to use", at least judging from the number of implementations that support ESMTP and at least some options. > If you want to send a message to someone in Chinese, then it > is a good idea to be sure in advance that he understands > Chinese (and has software that will cope). Likewise, if you > want to send an IEE message with headers in UTF-8. Strictly speaking, the proposals only require that you be sure in advance that his systems, and the intermediate ones, can understand and accept Chinese characters (and/or UTF-8 headers) without trashing the information. While that might seem like an onerous and high-risk requirement (at least to Dave in the context above), the burden and risk is mitigated considerably by two things: * You would be either mildly confused or mildly insane to try to send i18n mail to a submission server that was incapable of handling it. Presumably, the first time you tried that, you would discover that it could not handle it (the ESMTP option would not be offered and your client would reject the message with a protest). And you would presumably either get over trying to use i18n mail (getting an all-ASCII address from your correspondent and using it) or would find a more competent submission server. * Your correspondent and her systems would need to be mildly confused or mildly insane to give you an i18n address as their contact information unless the receiving servers and any intermediate servers they configured via MX records were i18n-capable. Now there are cases, most of them involving mailing list redistributors, in which the situation gets much more complicated. How much more complicated is an open question which the WG will need to address. But, for simple interpersonal mail, and unless there are important cases we haven't been able to find, "onerous" and "enormous, ongoing barrier" feel much more like hyperbole than like real issues in this discussion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 13 02:52:35 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 1Em4xe-0004NF-OR; Tue, 13 Dec 2005 02:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em4xd-0004N6-BE for ima@megatron.ietf.org; Tue, 13 Dec 2005 02:52:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14065 for ; Tue, 13 Dec 2005 02:51:36 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em4yW-0004tR-BH for ima@ietf.org; Tue, 13 Dec 2005 02:53:32 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Em4w3-0005hb-O0 for ima@ietf.org; Tue, 13 Dec 2005 08:50:55 +0100 Received: from 1cust12.tnt8.hbg2.deu.da.uu.net ([149.225.138.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 08:50:55 +0100 Received: from nobody by 1cust12.tnt8.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 08:50:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 13 Dec 2005 07:43:45 +0100 Organization: Lines: 15 Message-ID: <439E6DA1.16F4@xyzzy.claranet.de> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust12.tnt8.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [IEE] Re: URIs/IRIs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org John C Klensin wrote: > * Your correspondent and her systems would need to be > mildly confused or mildly insane to give you an i18n > address as their contact information unless the > receiving servers and any intermediate servers they > configured via MX records were i18n-capable. Ordinary users don't know what an MX might be. That's not mildly insane or mildly confused, that's just as it is :-| There's some nice ABNF in RFC 4282 for your purposes here if you replace two FF by F4. Bye, Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 13 06:15:15 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 1Em87n-0005kE-1q; Tue, 13 Dec 2005 06:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em87l-0005k6-Ty for ima@megatron.ietf.org; Tue, 13 Dec 2005 06:15:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07085 for ; Tue, 13 Dec 2005 06:14:14 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em88h-0003LM-Fb for ima@ietf.org; Tue, 13 Dec 2005 06:16:13 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jBDBETd07138; Tue, 13 Dec 2005 20:14:29 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 746d_a11d33b6_6bc9_11da_9b7f_00304811fd80; Tue, 13 Dec 2005 20:14:28 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jBDBD0Wk010748; Tue, 13 Dec 2005 20:14:04 +0900 Message-Id: <6.0.0.20.2.20051213182104.06482420@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 13 Dec 2005 18:23:33 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [IEE] Re: URIs/IRIs In-Reply-To: <439E6DA1.16F4@xyzzy.claranet.de> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> <439E6DA1.16F4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org At 15:43 05/12/13, Frank Ellermann wrote: >John C Klensin wrote: > >> * Your correspondent and her systems would need to be >> mildly confused or mildly insane to give you an i18n >> address as their contact information unless the >> receiving servers and any intermediate servers they >> configured via MX records were i18n-capable. > >Ordinary users don't know what an MX might be. That's not >mildly insane or mildly confused, that's just as it is :-| Yes, of course. But John is speaking to a technical audience here. Translated for average users, that means the following: Your correspondent and her systems would need to be mildly confused or mildly insane to give you an i18n address as their contact information unless they are actually reachable at that address/unless that address actually works. That should be easy enough even for average people. It would also be easy (except for possible spam issues) to set up a Web page where you can test out that your address actually works (externally, not only internally). Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 13 06:18:24 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 1Em8Aq-00064r-Pp; Tue, 13 Dec 2005 06:18:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em8Ao-00064V-Uk for ima@megatron.ietf.org; Tue, 13 Dec 2005 06:18:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07465 for ; Tue, 13 Dec 2005 06:17:24 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em8Bm-0003Rv-2N for ima@ietf.org; Tue, 13 Dec 2005 06:19:23 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jBDBEGd07124; Tue, 13 Dec 2005 20:14:16 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 62be_996f2ee4_6bc9_11da_91a3_0030482533a1; Tue, 13 Dec 2005 20:14:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jBDBD0Wi010748; Tue, 13 Dec 2005 20:13:25 +0900 Message-Id: <6.0.0.20.2.20051212173521.07b91a70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 13 Dec 2005 18:18:03 +0900 To: dcrocker@bbiw.net, Charles Lindsey From: Martin Duerst Subject: Re: [IEE] Re: [IMA] URIs/IRIs In-Reply-To: <439C6799.3000607@dcrocker.net> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org At 02:53 05/12/12, Dave Crocker wrote: >Charles Lindsey wrote: >> One of the properties we are trying to achieve is that no IEE message is sent to another agent without first establishing (by looking at the capabilities advertised) that agent #2 is able to handle it (e.g. that its parser will accept the extended syntax without needing to look at the 'label' header first). > >This seems a rather onerous prerequisite. It places an enormous, ongoing barrier to use, given that email does not have any large-scale history with requiring prior knowledge about the recipient. Quite the opposite. I'm not sure about Charles, but what I meant is "hop-by-hop", i.e. for each single SMTP transaction, not end-to-end (i.e. sender to receiver). This should be covered by ESMTP options, no need for content negotiation. >That said, folks might want to look at RFC3297, "Content Negotiation for Messaging Services based on Email". Looking at it, it may be a way to deal with the case that an intermediate relay can't forward an IEE message anymore. An machine-readable, well-defined format would definitely be preferable to the simple textual "Undelivered Mail Returned to Sender" type of things used currently. At least that would allow matching of return messages to sent mail (and elimination of virus- and spam-related such messages that go to a pretended sender rather than to the real sender). There may be other benefits, but I haven't thought this through fully yet. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 13 07:24:44 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 1Em9D2-0005Ag-5k; Tue, 13 Dec 2005 07:24:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em9D0-0005Ab-Bg for ima@megatron.ietf.org; Tue, 13 Dec 2005 07:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15349 for ; Tue, 13 Dec 2005 07:23:43 -0500 (EST) Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em9Dy-0005sl-Dz for ima@ietf.org; Tue, 13 Dec 2005 07:25:43 -0500 Received: from host81-144-66-2.midband.mdip.bt.net ([81.144.66.2]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 439ebd7f.140e1.24 for ima@ietf.org; Tue, 13 Dec 2005 12:24:31 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id jBDBjwL28847 for ; Tue, 13 Dec 2005 11:45:58 GMT To: "ima@ietf.org" Subject: Re: [IEE] Tunneling and packaging (was: Re: Packaging IEE Messages) References: Message-ID: Date: Tue, 13 Dec 2005 11:45:51 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA15349 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Mon, 12 Dec 2005 20:17:20 -0000, John C Klensin wrot= e: > implementation of the proposed protocol (absent downgrading and > as of the time of the Vancouver IETF) appears to require: > > * Disabling the syntax check requiring that addresses be > in ASCII > =09 > * Disabling the syntax check requiring that headers be > in ASCII > =09 > * Adding the appropriate capability announcement to the > EHLO response in the SMTP server. All of which are pretty easy to do on an agent that is already 8-bit =20 clean, as many are. However, you have omitted one further requirement, =20 which may be a bit more tricky: * Deciding whether it is necessary to check the capabilities of th= e next agent in line with a view to bouncing/downgrading if the =20 required capabilities are not available (obviously, you don't want to do th= is =20 if the message in hand and its envelope are already pure ASCII). There are several ways to decide this that have been suggested: 1. Looking for clues in the RCPT or FROM of the incoming envelope. 2. Having a special parameter in the incoming envelope (as you recently =20 suggested). 3. Examining a 'label' header in the message provided for the purpose. 4. Scanning the headers to look for a bit-8 somewhere. There are pros and cons for all these. ......... > This is why I've been resistant to Charles's suggestions about > changing the syntax of various header lines. I think that > requires, not disabling a few tests, but recasting every MUA (or > other module that deals with headers) to support a dual code > path and turns implementing this into a much bigger deal. Sure. We want to avoid dual code. What I want to see is a single code tha= t =20 will support the NEW syntax, whilst still accepting the OLD as a special = =20 case of it. That might still let through some NEW syntax that got accidentally =20 contained within what was supposed to be an old-style message. That might= =20 well be a technical violation of our new protocol, but it might in fact =20 work perfectly sensibly and so hardly be worth the trouble of checking fo= r. For example, if there is a facility to specify an alternative address, =20 somebody might try to use it for something like (using my example notatio= n) To: where both addresses are in fact in ASCII (so it would not be noticed by = a =20 "check for bit-8" test). I don't think you can stop people trying to do =20 that. --=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 Tue Dec 13 07:25:49 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 1Em9E5-0005b0-N3; Tue, 13 Dec 2005 07:25:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em9E4-0005av-Pp for ima@megatron.ietf.org; Tue, 13 Dec 2005 07:25:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15450 for ; Tue, 13 Dec 2005 07:24:50 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em9F3-0005vG-La for ima@ietf.org; Tue, 13 Dec 2005 07:26:51 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1Em9Dv-000N8G-KH; Tue, 13 Dec 2005 07:25:39 -0500 Date: Tue, 13 Dec 2005 07:25:39 -0500 From: John C Klensin To: Martin Duerst , Frank Ellermann , ima@ietf.org Subject: Re: [IEE] Re: URIs/IRIs Message-ID: <0637BFB925688FCE6B1FDD34@scan.jck.com> In-Reply-To: <6.0.0.20.2.20051213182104.06482420@localhost> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> <439E6DA1.16F4@xyzzy.claranet.de> <6.0.0.20.2.20051213182104.06482420@localhost> 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Tuesday, 13 December, 2005 18:23 +0900 Martin Duerst wrote: > At 15:43 05/12/13, Frank Ellermann wrote: > >John C Klensin wrote: > > > >> * Your correspondent and her systems would need to be > >> mildly confused or mildly insane to give you an i18n > >> address as their contact information unless the > >> receiving servers and any intermediate servers they > >> configured via MX records were i18n-capable. > > > >Ordinary users don't know what an MX might be. That's not > >mildly insane or mildly confused, that's just as it is :-| > > Yes, of course. But John is speaking to a technical audience > here. Translated for average users, that means the following: > > Your correspondent and her systems would need to be > mildly confused or mildly insane to give you an i18n > address as their contact information unless they are > actually reachable at that address/unless that address > actually works. > > That should be easy enough even for average people. > It would also be easy (except for possible spam issues) > to set up a Web page where you can test out that your > address actually works (externally, not only internally). Yes, Martin, thanks. And the web page is a nice idea. There is one more twist to this in the receiving side, and it is an odd advantage of the addresses actually being in UTF-8 rather than some more or less idiosyncratic ACE: Email addresses just don't get created without the intervention of system administrators or templates or tools installed by system administrators. For a sysadmin to permit the creation of i18n addresses for which there is no server support for for which any MXs are not properly configured would also constitute either mildly confusion, mild insanity, or considerable incompetence. I can see some scenarios on the sending side that might result in at i18n address being sent to a non-upgraded server. For example, one might have an address that works perfectly well in my home environment but that gets me into trouble when used with a submission server provided as part of some meeting-related network. But I would figure out, quickly, that unless I don't use such networks and servers for sending mail, I had better have alternate addresses available. On the other hand, such meeting networks with their own SMTP servers provide some interesting technical or administrative challenges for a number of authentication techniques as well, so are not exactly an increasing trend. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 13 12:23:39 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 1EmDsJ-0007IQ-TY; Tue, 13 Dec 2005 12:23:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmDsH-0007EG-Qd for ima@megatron.ietf.org; Tue, 13 Dec 2005 12:23:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24224 for ; Tue, 13 Dec 2005 12:22:39 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmDtF-0000SR-6M for ima@ietf.org; Tue, 13 Dec 2005 12:24:41 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EmDpG-0003Di-MF for ima@ietf.org; Tue, 13 Dec 2005 18:20:30 +0100 Received: from c-180-161-151.hh.dial.de.ignite.net ([62.180.161.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 18:20:30 +0100 Received: from nobody by c-180-161-151.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 18:20:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 13 Dec 2005 18:15:08 +0100 Organization: Lines: 33 Message-ID: <439F019C.738C@xyzzy.claranet.de> References: <333920316.24007@cnnic.cn> <009e01c5fad4$ab43b880$1206e29f@cnnicyaojk> <439C6799.3000607@dcrocker.net> <439E6DA1.16F4@xyzzy.claranet.de> <6.0.0.20.2.20051213182104.06482420@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-151.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [IEE] Re: URIs/IRIs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > Your correspondent and her systems would need to be > mildly confused or mildly insane to give you an i18n > address as their contact information unless they are > actually reachable at that address/unless that address > actually works. My ISP gave me a "canonical address" and a rule how I can use this as "vanity host" xyzzy.claranet.de for arbitrary@xyzzy.claranet.de addresses (and Message-IDs). For the finer points like length <= 63 they expect that I find and read RFC 3696 > It would also be easy (except for possible spam issues) > to set up a Web page where you can test out that your > address actually works (externally, not only internally). Yes, at least one the infamous O* products has an autotest feature. With users you never know, they configure a MX somehow (for their own domain) and expect that this works. Worst I've seen in spf-help was a user with "v=spf1 mx -all" and his MX was 127.0.0.1, yeah. Asked why his mail causes FAIL results, IIRC. SPF might be not the only case where certain kinds of local parts might end up as domain labels. For a SOA you'd expect that a hostmaster knows what he's doing, but generally I'm pessimistic. Bye, Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 16 00:35:23 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 1En8FX-0005HR-2P; Fri, 16 Dec 2005 00:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En8FV-0005Fw-9P for ima@megatron.ietf.org; Fri, 16 Dec 2005 00:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06069 for ; Fri, 16 Dec 2005 00:34:21 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En8Gy-000867-4j for ima@ietf.org; Fri, 16 Dec 2005 00:36:56 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1En8De-00030x-Cy for ima@ietf.org; Fri, 16 Dec 2005 06:33:27 +0100 Received: from pd9fba932.dip0.t-ipconnect.de ([217.251.169.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Dec 2005 06:33:26 +0100 Received: from nobody by pd9fba932.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Dec 2005 06:33:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 16 Dec 2005 06:31:29 +0100 Organization: Lines: 12 Message-ID: <43A25131.7946@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba932.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [IEE] 3461/3464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Hi, you probably all know this, but I didn't: RfC 3461 defines an "xtext"-encoding of addresses. If I got this right it's VCHAR minus "+" / "=", allowing to encode any ASCII by "+" . Extending that to UTF-8 should be straight forward. RfC 3464 defines address-type "rfc822", you probably have to register a new address-type for your (proper subset of) UTF-8- addresses. Bye, Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 16 02:57:27 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 1EnAT1-0004ZQ-RV; Fri, 16 Dec 2005 02:57:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnAT1-0004ZL-48 for ima@megatron.ietf.org; Fri, 16 Dec 2005 02:57:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15584 for ; Fri, 16 Dec 2005 02:56:26 -0500 (EST) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EnAUT-0003TZ-DS for ima@ietf.org; Fri, 16 Dec 2005 02:59:04 -0500 Received: (eyou send program); Fri, 16 Dec 2005 15:56:46 +0800 Message-ID: <334719806.06037@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, 16 Dec 2005 15:56:46 +0800 Message-ID: <024601c60216$5b7554f0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Frank Ellermann" References: <334711406.21319@cnnic.cn> Subject: Re: [IEE] 3461/3464 Date: Fri, 16 Dec 2005 15:57:27 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0244981657==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0244981657== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkZyYW5rIEVsbGVybWFubiIg PG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogRnJp ZGF5LCBEZWNlbWJlciAxNiwgMjAwNSAxOjMxIFBNDQpTdWJqZWN0OiBbSUVFXSAzNDYxLzM0NjQN Cg0KDQo+IEhpLCB5b3UgcHJvYmFibHkgYWxsIGtub3cgdGhpcywgYnV0IEkgZGlkbid0Og0KPiAN Cj4gUmZDIDM0NjEgZGVmaW5lcyBhbiAieHRleHQiLWVuY29kaW5nIG9mIGFkZHJlc3Nlcy4gIElm IEkgZ290DQo+IHRoaXMgcmlnaHQgaXQncyBWQ0hBUiBtaW51cyAiKyIgLyAiPSIsIGFsbG93aW5n IHRvIGVuY29kZSBhbnkNCj4gQVNDSUkgYnkgICIrIiA8aGV4PiA8aGV4Pi4gIA0KDQphY2NvcmRp bmcgdG8gbXkgdW5kZXJzdGFuZGluZywgdGhpcyBwYXJ0IGluIFJGQzM0NjEgdGFsa3MgYWJvdXQg ZW5jb2Rpbmcgb2N0ZXQgc2VxdWVuY2Ugb3Igc29tZSBBU0NJSSBjaGFyYWN0ZXJzLg0KDQo+RXh0 ZW5kaW5nIHRoYXQgdG8gVVRGLTggc2hvdWxkIGJlDQo+IHN0cmFpZ2h0IGZvcndhcmQuDQoNCm1h eSBub3QuDQoNCj4gDQo+IFJmQyAzNDY0IGRlZmluZXMgYWRkcmVzcy10eXBlICJyZmM4MjIiLCB5 b3UgcHJvYmFibHkgaGF2ZSB0bw0KPiByZWdpc3RlciBhIG5ldyBhZGRyZXNzLXR5cGUgZm9yIHlv dXIgKHByb3BlciBzdWJzZXQgb2YpIFVURi04LQ0KPiBhZGRyZXNzZXMuDQoNCnllYWgsIGEgZ29v ZCBzdWdnZXN0aW9uLg0KDQoNCllhbyBKaWFua2FuZw0KQ05OSUMNCg0KDQo+IA0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBt YWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ltYQ0KPiA= --===============0244981657== 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 --===============0244981657==-- From ima-bounces@ietf.org Sat Dec 17 10:50:27 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 1EneKJ-00013U-84; Sat, 17 Dec 2005 10:50:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EneKF-00013G-GD for ima@megatron.ietf.org; Sat, 17 Dec 2005 10:50:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08033 for ; Sat, 17 Dec 2005 10:49:22 -0500 (EST) Received: from smtpauth09.mail.atl.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EneM4-0001kD-Ag for ima@ietf.org; Sat, 17 Dec 2005 10:52:17 -0500 Received: from [65.96.189.219] (helo=[192.168.1.106]) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EneJy-0000Rv-Ex; Sat, 17 Dec 2005 10:50:06 -0500 Date: Sat, 17 Dec 2005 10:50:01 -0500 From: John C Klensin To: iab-idn@lists.frobbit.se, ima@ietf.org Message-ID: <9189A916151951088562A978@7AD4D3FB4841A5E367CCF211> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ELNK-Trace: bba5e034140ec807d780f4a490ca69563f9fea00a6dd62bc3b9d3ea9c05123ef21b638a95fa21fe4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.96.189.219 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Subject: [IEE] Network outage X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Hi. A truck took out the line that provides my network connection on Thursday afternoon and, due to several of the problems that lead me to hate local-loop DSL providers in the US, current estimate to get it fixed is late Monday afternoon (US ET). After the sequence of "promise the customer anything, just get him off the phone" behavior I have gotten, I'm not counting on that either. Obviously, I'm able to get email out although it is painful. But anything sent to any jck.com address since around noon on Thursday (again, US ET) is probably stuck in a queue somewhere -- I probably have not received it, and, if I have, I have no practical way to answer it properly. Messages sent earlier have probably been received, but, again, are difficult or impossible to answer. sorry for any inconvenience and best wishes to all for the holidays and the new year. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima