From ima-bounces@ietf.org Mon Apr 02 07:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKbw-0002yh-AT; Mon, 02 Apr 2007 07:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKbu-0002v1-QV for ima@ietf.org; Mon, 02 Apr 2007 07:22:06 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYKbn-0001H2-7P for ima@ietf.org; Mon, 02 Apr 2007 07:22:06 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew*man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4610e74b.1423c.383 for ima@ietf.org; Mon, 2 Apr 2007 12:21:47 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l32BLklE007686 for ; Mon, 2 Apr 2007 12:21:47 +0100 (BST) Date: Mon, 02 Apr 2007 12:21:45 +0100 To: IMA Subject: Re: [EAI] draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <456D537952C19761F6F51F49@[172.26.93.60]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <456D537952C19761F6F51F49@[172.26.93.60]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 30 Mar 2007 18:51:56 +0100, Harald Tveit Alvestrand wrote: > --On 29. mars 2007 11:49 +0100 Charles Lindsey > wrote: >> Firstly, the term defined is "UTF-8 header", not "UTF-8 header field". >> >> The definition is: >> >> In this document, header fields are "UTF-8 headers" if the bodies of >> those headers contain UTF-8 characters. >> > > Charles, we went over this in USEFOR. > > According to RFC 2822, a "header field" is a single (possibly folded) > line - consisting of a header field name and a header field value. No! No! "UTF-8 header" is the term that Jeff Yeh currently defines in Utf8headers (actual text quoted above). It is him you should be complaining to. I agree it ought to be changed. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 02 07:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKr3-0002jU-6M; Mon, 02 Apr 2007 07:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKr2-0002jO-GI for ima@ietf.org; Mon, 02 Apr 2007 07:37:44 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYKr0-0005ZH-Vo for ima@ietf.org; Mon, 02 Apr 2007 07:37:44 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew^man*ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4610eb05.a7f9.536 for ima@ietf.org; Mon, 2 Apr 2007 12:37:41 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l32BbcS2008638 for ; Mon, 2 Apr 2007 12:37:38 +0100 (BST) To: IMA Subject: Re: [EAI] Re: draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <325112866.20070329155022@pobox.com> <1158577433.20070330094455@pobox.com> <460E3AE2.7F36@xyzzy.claranet.de> Message-ID: Date: Mon, 02 Apr 2007 12:37:37 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <460E3AE2.7F36@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 31 Mar 2007 11:41:38 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > >> That all depends whether we are going to define message/utf8 or not. >> All suggested definitions of that type so far are EXPRESSLY FORBIDDEN >> by RFC 2045. > > It's "only" a SHOULD, and necessarily EAI is an excuse to violate it. RFC 2119 does not define the term "EXPRESSLY FORBIDDEN", but I would imagine its meaning is at least as strong as "MUST NOT", and probably stronger. > >> Personally, I want to allow UTF8 messages to be sent as message/rfc822 > > That gives you MIME 1.0 as is with RFC 2049 as is, and the whole EAI > effort should IMNSHO never survive something like an IETF Last Call. -1 -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 02 07:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLBi-0002Pc-20; Mon, 02 Apr 2007 07:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLBg-0002PX-Sq for ima@ietf.org; Mon, 02 Apr 2007 07:59:04 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYLBf-0003Uz-9x for ima@ietf.org; Mon, 02 Apr 2007 07:59:04 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew#man$ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4610f005.17fae.4a for ima@ietf.org; Mon, 2 Apr 2007 12:59:01 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l32BwqjV009917 for ; Mon, 2 Apr 2007 12:58:54 +0100 (BST) To: IMA Subject: Re: [EAI] Re: Discussion of draft-ietf-eai-downgrade-03.txt References: <46098893.2BB4@xyzzy.claranet.de> <460BF5D7.5CC1@xyzzy.claranet.de> <460E472C.46F3@xyzzy.claranet.de> Message-ID: Date: Mon, 02 Apr 2007 12:58:52 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <460E472C.46F3@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 31 Mar 2007 12:34:04 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > >>>> Content-Disposition: attachment; filename="mañana" > Are you talking about what I see, a Latin-1 ñ ? > Or was it meant to be an UTF-8 ñ ? Since my MUA is configured to use IS) 8859-1, what you saw was a Latin-1 ñ, but what the line >>>> Content-Disposition: attachment; filename="mañana" was intended to illustrate was a header containing a UTF-8 ñ, since that is what the Utf8headers document proposes to allow; hence its RFC 2231 encoding would be >> Content-Disposition: inline; filename*=utf-8''ma%C3%B1ana > I tried to 2231 encode the undeclared F1 octet. Your example > didn't state that it's a new MIME version allowing raw UTF-8 > in Content-* header fields. It is what the current Utf8headers draft proposes to allow, without any change in the MIME version. >>> Doesn't it ? My 2231-attempt was intended for 7BIT, why >>> does 8BITMIME care about 8bit crap in MIME part headers ? > >> Because there is no way to downgrade them to 7bit for a further MTA >> which does not advertise 8BITMIME. So you need to downgrade it to >> filename*=utf-8''ma%C3%B1ana before it leaves the UTF8SMTP universe. > > Maybe start with a new example where it's clear what you're talking > about. MIME 1.0 with an unknown %xF1 garbage is very different > from "MIME 2.0" with UTF-8 %xC3.B1. In both cases I don't see > why 8BITMIME should care about 8bit stuff in the body, it has a > parameter BODY=8BITMIME. The definition in RFC 1652 says: And indeed, RFC 1652 requires it to be transported correctly to other systems supporting 8BITMIME. But RFC 1652 also requires it to be downgraded before it is passed to a Non-8BITMIME MTA, and there is no way to do that downgrade within a MIME part header, because such headers do not come withn the scope of any Content-Transfer-Encoding header. > > | The value associated with the BODY parameter indicates whether the > | content body which will be passed using the DATA command consists of > | a MIME message containing some arbitrary octet-aligned material > | ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). > > IMO "some arbitrary octet-aligned material" does _not_ imply that > servers are supposed to check the MIME syntax, let alone version. They have no choice but to check the MIME syntax, and in fact that is precisely what they do. We have already discused this in connection with the source code of Sendmail, which indeed does a full MIME recursive descent in order to find bodies of MIME subparts and contained message/rfc822 objects where is can then change the C-T-E. But if it encounters a MIME part header, or a header in a message/rfc822, that contains 8bit stuff, then it is stuck (because such headers are not allowed to exist in the present universe). >> How about >> subject: =?utf-8*de?Qtest_?= ?utf-8?Q?%C3%BC?= =?utf-8*en?Q?_this?= > > I think that's perfect. You could also add the spaces to the second > word, leaving the adjacent words alone -- for cases where you have no > clue what charset / language / encoding it might be - but there can't > be any encoding different from "Q" or "B", or can it ?. RFC 2047 includes provision for new encodings to be invented in the future, hence my suggestion for an "I" encoding: >> Subject: =?utf-8*es?I?mañana=? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 02 08:45:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLu4-0000x3-QL; Mon, 02 Apr 2007 08:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLu3-0000wv-AL for ima@ietf.org; Mon, 02 Apr 2007 08:44:55 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYLtk-0007B2-W7 for ima@ietf.org; Mon, 02 Apr 2007 08:44:55 -0400 Received: (eyou send program); Mon, 02 Apr 2007 20:37:34 +0800 Message-ID: <375517454.19122@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 02 Apr 2007 20:37:34 +0800 Message-ID: <02e901c77523$b14e1ca0$096ff1da@cnnicyao> From: "YAO Jiankang" To: "IMA" , "Charles Lindsey" References: <200703201920.l2KJKenc011667@clerew.man.ac.uk><374486935.15865@cnnic.cn> <025e01c76ee9$cfb799e0$0301a8c0@YaoJK> <374921692.14294@cnnic.cn> Subject: Re: [EAI] Discussion of draft-ietf-eai-smtpext-04 Date: Mon, 2 Apr 2007 20:37:25 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913596327==" Errors-To: ima-bounces@ietf.org --===============0913596327== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86ICJJTUEiIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBN b25kYXksIE1hcmNoIDI2LCAyMDA3IDExOjA3IFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gRGlzY3Vz c2lvbiBvZiBkcmFmdC1pZXRmLWVhaS1zbXRwZXh0LTA0DQoNCg0KPiANCj4+PiAyLjYuICBCb2R5 IFBhcnRzIGFuZCBTTVRQIEV4dGVuc2lvbnMNCj4+Pg0KPj4+ICAgIEFzc3VtaW5nIHRoYXQgdGhl IHNlcnZlciBhZHZlcnRpc2VzIFVURjhTTVRQIGFuZCA4QklUTUlNRSwgYW5kIGF0DQo+Pj4gICAg bGVhc3Qgb25lIG5vbi1BU0NJSSBhZGRyZXNzLCB3aXRoIG9yIHdpdGhvdXQgQUxULUFERFJFU1Ms IHRoZSBwcmVjaXNlDQo+Pj4gICAgaW50ZXJwcmV0YXRpb24gb2YgdGhlc2UgcGFyYW1ldGVycyBv biB0aGUgTUFJTCBjb21tYW5kIGlzOg0KPj4+DQo+Pj4gICAgMS4gIEhlYWRlcnMgYXJlIGluIFVU Ri04LCBib2R5IHBhcnRzIGFyZSBpbiBBU0NJSS4NCj4+PiAgICAyLiAgSGVhZGVycyBhcmUgaW4g VVRGLTgsIHNvbWUgb3IgYWxsIGJvZHkgcGFydHMgY29udGFpbiA4LWJpdCBsaW5lLQ0KPj4+ICAg ICAgICBvcmllbnRlZCBkYXRhLg0KPj4+ICAgIDMuICBIZWFkZXJzIGFyZSBpbiBVVEYtOCwgc29t ZSBvciBhbGwgYm9keSBwYXJ0cyBjb250YWluIGJpbmFyeSBkYXRhDQo+Pj4gICAgICAgIHdpdGhv dXQgcmVzdHJpY3Rpb24gYXMgdG8gbGluZSBsZW5ndGhzIG9yIGRlbGltaXRlcnMuDQo+Pj4NCj4+ PiBJIGRvIG5vdCB1bmRlcnN0YW5kIGhvdyB0aG9zZSB0aHJlZSBudW1iZXJlZCBpdGVtcyBhcmUg c3VwcG9zZWQgdG8gIA0KPj4+IHJlbGF0ZQ0KPj4+IHRvIGFueSBwYXJhbWV0ZXJzIGluIGEgTUFJ TCBjb21tYW5kLg0KPj4NCj4+IGl0IGlzIHJlbGF0ZWQgZm9yIERBVEEgY29tbWFuZHMgd2hlbiBi b3RoIFVURjhTTVRQIGFuZCA4QklUTUlNRSBhcmUgIA0KPj4gYWR2ZXJ0aXNlZC4gV2UgcHV0IHRo ZSB0ZXh0IGhlcmUgZm9yIGNsYXJpZmljYXRpb24gcmVhc29uDQo+PiBiZWNhdXNlIHNvbWUgcmVh ZGVycyBkb2VzIG5vdCBjbGVhcmx5IGtub3cgYm9keSBwYXJ0cyBhcmUgVVRGLTggb3IgIA0KPj4g YmluYXJ5IGRhdGEgd2hlbiBoZWFkZXJzIGFyZSBVVEYtOC4NCj4gDQo+IFllcywgYnV0IHRoYXQg c2VlbXMgdG8gYmUgbm90aGluZyB0byBkbyB3aXRoIHRoZSBNQUlMIGNvbW1hbmQgb3IgaXRzICAN Cj4gcGFyYW1ldGVycywgc28gdGhlIHdvcmRpbmcgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLg0KPj4N Cg0KDQpJIGNoZWNoIFJGQyAxNjUyLCB0aGVyZSBpcyBhIE1haWwgY29tbWFuZCB1c2FnZSBhYm91 dCBib2R5LThiaXRtaW1lIGluIHNlY3Rpb24gNDoNCg0KICAgQzogTUFJTCBGUk9NOjxuZWRAeW1p ci5jbGFyZW1vbnQuZWR1PiBCT0RZPThCSVRNSU1FDQogICBTOiAyNTAgPG5lZEB5bWlyLmNsYXJl bW9udC5lZHU+Li4uIFNlbmRlciBhbmQgOEJJVE1JTUUgb2sNCiAgIEM6IFJDUFQgVE86PG1yb3Nl QGRiYy5tdHZpZXcuY2EudXM+DQoNCg== --===============0913596327== 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 --===============0913596327==-- From ima-bounces@ietf.org Mon Apr 02 08:52:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYM1h-0006YP-5W; Mon, 02 Apr 2007 08:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYM1f-0006Tg-Uv for ima@ietf.org; Mon, 02 Apr 2007 08:52:47 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYM1d-00013u-TG for ima@ietf.org; Mon, 02 Apr 2007 08:52:47 -0400 Received: (eyou send program); Mon, 02 Apr 2007 20:52:30 +0800 Message-ID: <375518350.19889@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 02 Apr 2007 20:52:30 +0800 Message-ID: <035101c77525$c723a430$096ff1da@cnnicyao> From: "YAO Jiankang" To: "YAO Jiankang" , "IMA" , "Charles Lindsey" References: <200703201920.l2KJKenc011667@clerew.man.ac.uk><374486935.15865@cnnic.cn><025e01c76ee9$cfb799e0$0301a8c0@YaoJK> <374921692.14294@cnnic.cn> <375517961.17232@cnnic.cn> Subject: Re: [EAI] Discussion of draft-ietf-eai-smtpext-04 Date: Mon, 2 Apr 2007 20:51:56 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0659724193==" Errors-To: ima-bounces@ietf.org --===============0659724193== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIllBTyBKaWFua2FuZyIgPHlh b2prQGNubmljLmNuPg0KVG86ICJJTUEiIDxpbWFAaWV0Zi5vcmc+OyAiQ2hhcmxlcyBMaW5kc2V5 IiA8Y2hsQGNsZXJldy5tYW4uYWMudWs+DQpTZW50OiBNb25kYXksIEFwcmlsIDAyLCAyMDA3IDg6 MzcgUE0NClN1YmplY3Q6IFJlOiBbRUFJXSBEaXNjdXNzaW9uIG9mIGRyYWZ0LWlldGYtZWFpLXNt dHBleHQtMDQNCg0KDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9t OiAiQ2hhcmxlcyBMaW5kc2V5IiA8Y2hsQGNsZXJldy5tYW4uYWMudWs+DQo+IFRvOiAiSU1BIiA8 aW1hQGlldGYub3JnPg0KPiBTZW50OiBNb25kYXksIE1hcmNoIDI2LCAyMDA3IDExOjA3IFBNDQo+ IFN1YmplY3Q6IFJlOiBbRUFJXSBEaXNjdXNzaW9uIG9mIGRyYWZ0LWlldGYtZWFpLXNtdHBleHQt MDQNCj4gDQo+IA0KPj4gDQo+Pj4+IDIuNi4gIEJvZHkgUGFydHMgYW5kIFNNVFAgRXh0ZW5zaW9u cw0KPj4+Pg0KPj4+PiAgICBBc3N1bWluZyB0aGF0IHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcyBVVEY4 U01UUCBhbmQgOEJJVE1JTUUsIGFuZCBhdA0KPj4+PiAgICBsZWFzdCBvbmUgbm9uLUFTQ0lJIGFk ZHJlc3MsIHdpdGggb3Igd2l0aG91dCBBTFQtQUREUkVTUywgdGhlIHByZWNpc2UNCj4+Pj4gICAg aW50ZXJwcmV0YXRpb24gb2YgdGhlc2UgcGFyYW1ldGVycyBvbiB0aGUgTUFJTCBjb21tYW5kIGlz Og0KPj4+Pg0KPj4+PiAgICAxLiAgSGVhZGVycyBhcmUgaW4gVVRGLTgsIGJvZHkgcGFydHMgYXJl IGluIEFTQ0lJLg0KPj4+PiAgICAyLiAgSGVhZGVycyBhcmUgaW4gVVRGLTgsIHNvbWUgb3IgYWxs IGJvZHkgcGFydHMgY29udGFpbiA4LWJpdCBsaW5lLQ0KPj4+PiAgICAgICAgb3JpZW50ZWQgZGF0 YS4NCj4+Pj4gICAgMy4gIEhlYWRlcnMgYXJlIGluIFVURi04LCBzb21lIG9yIGFsbCBib2R5IHBh cnRzIGNvbnRhaW4gYmluYXJ5IGRhdGENCj4+Pj4gICAgICAgIHdpdGhvdXQgcmVzdHJpY3Rpb24g YXMgdG8gbGluZSBsZW5ndGhzIG9yIGRlbGltaXRlcnMuDQo+Pj4+DQo+Pj4+IEkgZG8gbm90IHVu ZGVyc3RhbmQgaG93IHRob3NlIHRocmVlIG51bWJlcmVkIGl0ZW1zIGFyZSBzdXBwb3NlZCB0byAg DQo+Pj4+IHJlbGF0ZQ0KPj4+PiB0byBhbnkgcGFyYW1ldGVycyBpbiBhIE1BSUwgY29tbWFuZC4N Cj4+Pg0KPj4+IGl0IGlzIHJlbGF0ZWQgZm9yIERBVEEgY29tbWFuZHMgd2hlbiBib3RoIFVURjhT TVRQIGFuZCA4QklUTUlNRSBhcmUgIA0KPj4+IGFkdmVydGlzZWQuIFdlIHB1dCB0aGUgdGV4dCBo ZXJlIGZvciBjbGFyaWZpY2F0aW9uIHJlYXNvbg0KPj4+IGJlY2F1c2Ugc29tZSByZWFkZXJzIGRv ZXMgbm90IGNsZWFybHkga25vdyBib2R5IHBhcnRzIGFyZSBVVEYtOCBvciAgDQo+Pj4gYmluYXJ5 IGRhdGEgd2hlbiBoZWFkZXJzIGFyZSBVVEYtOC4NCj4+IA0KPj4gWWVzLCBidXQgdGhhdCBzZWVt cyB0byBiZSBub3RoaW5nIHRvIGRvIHdpdGggdGhlIE1BSUwgY29tbWFuZCBvciBpdHMgIA0KPj4g cGFyYW1ldGVycywgc28gdGhlIHdvcmRpbmcgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLg0KPj4+DQo+ IA0KPiANCj4gSSBjaGVjaCBSRkMgMTY1MiwgdGhlcmUgaXMgYSBNYWlsIGNvbW1hbmQgdXNhZ2Ug YWJvdXQgYm9keS04Yml0bWltZSBpbiBzZWN0aW9uIDQ6DQo+IA0KPiAgIEM6IE1BSUwgRlJPTTo8 bmVkQHltaXIuY2xhcmVtb250LmVkdT4gQk9EWT04QklUTUlNRQ0KPiAgIFM6IDI1MCA8bmVkQHlt aXIuY2xhcmVtb250LmVkdT4uLi4gU2VuZGVyIGFuZCA4QklUTUlNRSBvaw0KPiAgIEM6IFJDUFQg VE86PG1yb3NlQGRiYy5tdHZpZXcuY2EudXM+DQo+IA0KPg0KDQoNClRoaXMgc2VjdGlvbiB3aWxs IGJlIHVwZGF0ZWQgdG8gdGhlIGZvbGxvdyB0ZXh0Og0KDQoNCjIuNi4gIEJvZHkgUGFydHMgYW5k IFNNVFAgRXh0ZW5zaW9ucw0KDQogICBUaGVyZSBpcyBubyBFU01UUCBwYXJhbWV0ZXIgd2hpY2gg dGVsbCB3aGV0aGVyIGh0ZSBtZXNzYWdlIGlzDQogICBVVEY4U01UUCBtZXNzYWdlLCBTTVRQIHNl cnZlciBuZWVkcyBwYXJzZSBhbGwgbWVzc2FnZSBoZWFkZXIgZmllbGRzDQogICAoaW5jbHVkaW5n IGhlYWRlciBmaWVsZHMgZnJvbSBNSU1FIGJvZHkgcGFydHMpIHRvIGRpc2NvdmVyIHdoaWNoDQog ICBtZXNzYWdlcyBhcmUgVVRGOFNNVFAuICBXaGlsZSB0aGlzIHNwZWNpZmljYXRpb24gcmVxdWly ZXMgdGhhdA0KICAgc2VydmVycyBzdXBwb3J0IHRoZSA4QklUTUlNRSBleHRlbnNpb24gW1JGQzE2 NTJdIHRvIGVuc3VyZSB0aGF0DQogICBzZXJ2ZXJzIGhhdmUgYWRlcXVhdGUgaGFuZGxpbmcgY2Fw YWJpbGl0eSBmb3IgOC1iaXQgZGF0YSBhbmQgdG8gYXZvaWQNCiAgIGEgbnVtYmVyIG9mIGNvbXBs ZXggZW5jb2RpbmcgcHJvYmxlbXMsIHRoZSB1c2Ugb2YgaW50ZXJuYXRpb25hbGl6ZWQNCiAgIGFk ZHJlc3NlcyBvYnZpb3VzbHkgZG9lcyBub3QgcmVxdWlyZSBub24tQVNDSUkgYm9keSBwYXJ0cyBp biB0aGUgTUlNRQ0KICAgbWVzc2FnZS4gIFRoZSBVVEY4U01UUCBleHRlbnNpb24gTUFZIGJlIHVz ZWQgd2l0aCB0aGUgQk9EWT04QklUTUlNRQ0KICAgcGFyYW1ldGVyIGlmIHRoYXQgaXMgYXBwcm9w cmlhdGUgZ2l2ZW4gdGhlIGJvZHkgY29udGVudCBvciwgaWYgdGhlDQogICBzZXJ2ZXIgYWR2ZXJ0 aXNlcyBpdCBhbmQgaXQgaXMgYXBwcm9wcmlhdGUsIHdpdGggdGhlIEJPRFk9QklOQVJZTUlNRQ0K ICAgcGFyYW1ldGVyIHNwZWNpZmllZCBpbiBbUkZDMzAzMF0uDQoNCiAgIEFzc3VtaW5nIHRoYXQg dGhlIHNlcnZlciBhZHZlcnRpc2VzIFVURjhTTVRQIGFuZCA4QklUTUlNRSwgYW5kIGF0DQogICBs ZWFzdCBvbmUgbm9uLUFTQ0lJIGFkZHJlc3MsIHdpdGggb3Igd2l0aG91dCBBTFQtQUREUkVTUywg dGhlIHByZWNpc2UNCiAgIGludGVycHJldGF0aW9uIG9mIHRoZXNlIHBhcmFtZXRlcnMgb2YgIk5v ICJCb2R5IiBwYXJhbWV0ZXIiIiwgIkJPRFk9DQogICA4QklUTUlNRSIsIGFuZCAiQk9EWT0gQklO QVJZIiBvbiB0aGUgTUFJTCBjb21tYW5kIGlzOg0KICAgMS4gIEZvciBObyAiQm9keSIgcGFyYW1l dGVyLCBoZWFkZXJzIGFyZSBpbiBVVEYtOCwgYm9keSBwYXJ0cyBhcmUgaW4NCiAgICAgICBBU0NJ SS4NCiAgIDIuICBGb3IgQk9EWT04QklUTUlNRSBwYXJhbWV0ZXIsIGhlYWRlcnMgYXJlIGluIFVU Ri04LCBzb21lIG9yIGFsbA0KICAgICAgIGJvZHkgcGFydHMgY29udGFpbiA4LWJpdCBsaW5lLW9y aWVudGVkIGRhdGEuDQogICAzLiAgRm9yIEJPRFk9QklOQVJZTUlNRSBwYXJhbWV0ZXIsIGhlYWRl cnMgYXJlIGluIFVURi04LCBzb21lIG9yIGFsbA0KICAgICAgIGJvZHkgcGFydHMgY29udGFpbiBi aW5hcnkgZGF0YSB3aXRob3V0IHJlc3RyaWN0aW9uIGFzIHRvIGxpbmUNCiAgICAgICBsZW5ndGhz IG9yIGRlbGltaXRlcnMuDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBt YWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ltYQ0KPg== --===============0659724193== 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 --===============0659724193==-- From ima-bounces@ietf.org Mon Apr 02 09:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMFg-0000aF-8b; Mon, 02 Apr 2007 09:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMFf-0000XV-AX for ima@ietf.org; Mon, 02 Apr 2007 09:07:15 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMFa-0005fJ-PN for ima@ietf.org; Mon, 02 Apr 2007 09:07:15 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew$man#ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4610fffd.8c6e.d6 for ima@ietf.org; Mon, 2 Apr 2007 14:07:09 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l32D77on014034 for ; Mon, 2 Apr 2007 14:07:09 +0100 (BST) To: IMA Subject: Re: [EAI] Terminology "UTF8SMTP messages" References: <45AF04455CA54DF27B250DBC@[172.26.93.60]> Message-ID: Date: Mon, 02 Apr 2007 14:07:07 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45AF04455CA54DF27B250DBC@[172.26.93.60]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 30 Mar 2007 19:00:47 +0100, Harald Tveit Alvestrand wrote: > Please note the following text from -framework: > By symmetry, the term "UTF8SMTP message" should be reserved for the set > of messages that encompasses both RFC 2822 compatible messages and > messages which make use of the extensions defined in the memos we are > discussing). However, we still need to define a term to describe that class of objects which are "UTF8SMTP" messages, but which are nevertheless not RFC 2822/2045 objects, because that class is exactly what needs special attention when passed to a Non-UTF8SMTP system. Following the framework document, we might call those "non-ASCII messages", or "internationalized messages", but those terms would be misleading because we already have messages with Non-ASCII body parts using Content-Transfer-Encodings Q-P and Base64, and we don't want any suggestion that those are to be covered by our definition. So what term should be use? "Strict UTF8SMTP messages" is how mathematicians would describe them, but that is a bit of a mouthful. > > Unless people want to reopen the -framework document and change this > terminology, I'm declaring the issue of the term "UTF8SMTP message" a > closed one. Well I don't rule that out, but let us see what else gets suggested. > For the headers, talking about "ASCII header" and "non-ASCII header" > makes sense, but for the whole message, it seems to be a bad fit, given > the wide range of non-ASCII stuff that goes into message bodies. Exactly. That is the problem we face. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 02 16:25:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT5y-0000Gx-Np; Mon, 02 Apr 2007 16:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT5x-0000Gs-BX for ima@ietf.org; Mon, 02 Apr 2007 16:25:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT5r-00082h-Lw for ima@ietf.org; Mon, 02 Apr 2007 16:25:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HYT5a-00029z-51 for ima@ietf.org; Mon, 02 Apr 2007 22:25:18 +0200 Received: from d247224.dialin.hansenet.de ([80.171.247.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Apr 2007 22:25:18 +0200 Received: from nobody by d247224.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Apr 2007 22:25:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Mon, 02 Apr 2007 22:24:05 +0200 Organization: Lines: 23 Message-ID: <46116665.A90@xyzzy.claranet.de> References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <325112866.20070329155022@pobox.com> <1158577433.20070330094455@pobox.com> <460E3AE2.7F36@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: d247224.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] Re: draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: >>> That all depends whether we are going to define message/utf8 or not. >>> All suggested definitions of that type so far are EXPRESSLY FORBIDDEN >>> by RFC 2045. >> It's "only" a SHOULD, and necessarily EAI is an excuse to violate it. > RFC 2119 does not define the term "EXPRESSLY FORBIDDEN", but I would > imagine its meaning is at least as strong as "MUST NOT", and probably > stronger. The EXPRESSLY FORBIDDEN is about CTEs different from 8bit, 7bit, or binary for composite types (multipart/* or message/* at the moment), it's on line 926 of RFC 2045. The "SHOULD" is actually only a "should" about using 7bit for message/* subtypes in section 5.2.4 in RFC 2046. In other words a message/utf-8 using 8bit does not violate an upper case SHOULD, and it also doesn't come into any conflicts with the EXPRESSLY FORBIDDEN in RFC 2045. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 02 18:10:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUjA-0003xE-5p; Mon, 02 Apr 2007 18:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUj8-0003x8-BQ for ima@ietf.org; Mon, 02 Apr 2007 18:10:14 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUj6-0007gr-SL for ima@ietf.org; Mon, 02 Apr 2007 18:10:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HYUej-0005BM-Q9 for ima@ietf.org; Tue, 03 Apr 2007 00:05:42 +0200 Received: from d247224.dialin.hansenet.de ([80.171.247.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2007 00:05:41 +0200 Received: from nobody by d247224.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2007 00:05:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Mon, 02 Apr 2007 23:51:40 +0200 Organization: Lines: 102 Message-ID: <46117AEC.61E7@xyzzy.claranet.de> References: <46098893.2BB4@xyzzy.claranet.de> <460BF5D7.5CC1@xyzzy.claranet.de> <460E472C.46F3@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: d247224.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [EAI] Re: Discussion of draft-ietf-eai-downgrade-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: >> I tried to 2231 encode the undeclared F1 octet. Your example >> didn't state that it's a new MIME version allowing raw UTF-8 >> in Content-* header fields. > It is what the current Utf8headers draft proposes to allow, > without any change in the MIME version. It has to be fixed, creating its own MIME version explicitly, or in some obscure way, where an implicitly identified message/utf-8 implicitly also redefines MIME. One "implicit" too many for my tastes, I stick to version 1.0 as specified: | The "multipart" boundary delimiters and header fields are always | represented as 7bit US-ASCII in any case (though the header | fields may encode non-US-ASCII header as per RFC 2047) [2046 5.1] | However, in no event are headers (either message headers or body | part headers) allowed to contain anything other than US-ASCII | characters. [2046 5.1.1] | The message header fields are always US-ASCII in any case, and | data within the body can still be encoded, in which case the | Content-Transfer-Encoding header field in the encapsulated | message will reflect this. Non-US-ASCII text in the headers of | an encapsulated message can be specified using the mechanisms | described in RFC 2047. [2046 5.2.1] | MIME-Version: 1.0 | | The presence of this header field is an assertion that the message | has been composed in compliance with this document. [2045 4] | Using the MIME-Version, Content-Type, and Content-Transfer-Encoding | header fields, it is possible to include, in a standardized way, | arbitrary types of data with RFC 822 conformant mail messages. No | restrictions imposed by either RFC 821 or RFC 822 are violated, and | care has been taken to avoid problems caused by additional | restrictions imposed by the characteristics of some Internet mail | transport mechanisms (see RFC 2049). [2045 10] And then there was this series of four MUST in 2047 which should have told us that any attempt to 2047-encode header field bodies already containing encoded words to get a "downgrading" effect is moot... :-( Tough, back to the drawing board. [8BITMIME] > RFC 1652 also requires it to be downgraded before it is passed to a > Non-8BITMIME MTA, and there is no way to do that downgrade within a > MIME part header, because such headers do not come withn the scope > of any Content-Transfer-Encoding header. 8BITMIME to 7BIT is the job of those gatewys, not of UTF8SMTP. If they can't do this they're forced to reject the mail. Of course I fail to see any problems with 8bit in MIME part headers because I don't intend to allow this in the first place (for MIME 1.0 as quoted above). >> IMO "some arbitrary octet-aligned material" does _not_ imply that >> servers are supposed to check the MIME syntax, let alone version. > They have no choice but to check the MIME syntax, and in fact that > is precisely what they do. If any decent 8BITMIME server receiving BODY=8BITMIME from a client, and relaying it (as is) to another 8BITMIME mailer, ever looks for 8bit characters in MIME part headers in the body, I'd really wish to know *why*. What's it supposed to do with it, reject the mail as unsuited for 7bit conversions in a pure 8BITMIME environment ? > We have already discused this in connection with the source code > of Sendmail, which indeed does a full MIME recursive descent That was an 8BITMIME-to-7BIT gateway, not an 8BITMIME-to-8BITMIME relay. I assume that UTF8SMTP-to-7BIT is functionally equivalent to UTF8SMT-to-8BITMIME followed by 8BITMIME-to-7BIT. If that's the case EAI only needs to solve UTF8SMTP-to-8BITMIME. If the 2nd step (to 7BIT) doesn't work for any reasons, then doing it in one instead of two steps also won't work. And of course I'm talking about "MIME version 1.0" as quoted above. > if it encounters a MIME part header, or a header in a message/rfc822, > that contains 8bit stuff, then it is stuck (because such headers are > not allowed to exist in the present universe). It's not stuck, it rejects the garbage mail, it's invalid. Or as the similar EAI problem description puts it: | Reject the message or, if necessary, return a non-delivery | notification message, so that the sender can make another plan. If in doubt reject, most likely it was anyway spam. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 03 03:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdHV-0006KC-B7; Tue, 03 Apr 2007 03:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdHU-0006K3-4r for ima@ietf.org; Tue, 03 Apr 2007 03:18:16 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYdHS-0004cN-GN for ima@ietf.org; Tue, 03 Apr 2007 03:18:16 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l337HvR9028446; Tue, 3 Apr 2007 16:17:58 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007040316175730877 ; Tue, 03 Apr 2007 16:17:57 +0900 Date: Tue, 03 Apr 2007 16:17:57 +0900 (JST) Message-Id: <20070403.161757.08327158.fujiwara@jprs.co.jp> To: hurtta+gmane@siilo.fmi.fi Subject: Re: [EAI] Re: "6. Email header Downgrading" From: fujiwara@jprs.co.jp In-Reply-To: <5dbqj2numv.fsf@Hurtta06k.keh.iki.fi> References: <5dodn33t5a.fsf@Hurtta06k.keh.iki.fi> <5dbqj2numv.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Sorry for my too late responses. > From: Kari Hurtta > > > | other headers: > > > | All other headers which contains UTF-8 characters are preserved in > > > | Downgraded: header and removed. > > > > > > Removing of MIME's Content-Type -header field produces incorrect result. > > > > > > Basically mime-type part (type/subtype) of that header-field must be > > > preserved. > > > Also following mime paramaters need to be preserved: charset and boundary > > > These parameter values should be ASCII -only. Also type/subtype value > > > should be ASCII -only. > > > > Which just leaves possible s with UTF-8 in theor > > s. We should define that these are to be downgraded using RFC > > 2231. I'll fix this part after utf8header document fix. If all MIME headers are allowed to contain raw UTF-8 string, all MIME headers in both mail header fields and MIME bory part headers (at least outer-most MIME structure) MUST be downgraded using RFC 2231. Downgrading process MUST parse whole body part if the mail has the multipart MIME structure. > And do not forget comments. > > draft-ietf-eai-utf8headers-03.txt: > > | comment = "(" *([FWS] utf8-ccontent) [FWS] ")" > | > | word = utf8-atom / utf8-quoted-string > | > | This means that all the RFC 2822 constructs that build upon these > | will permit UTF-8 characters, including comments and quoted strings. It is written in section 6 and 6.1. But it needs detailed description. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 03 05:11:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYf2Z-0006pk-OF; Tue, 03 Apr 2007 05:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYf2Z-0006pf-8K for ima@ietf.org; Tue, 03 Apr 2007 05:10:59 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYf2T-0000nJ-LT for ima@ietf.org; Tue, 03 Apr 2007 05:10:59 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew^man^ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46121a1c.ee1.6d2 for ima@ietf.org; Tue, 3 Apr 2007 10:10:52 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l339ATRb022423 for ; Tue, 3 Apr 2007 10:10:30 +0100 (BST) To: IMA Subject: Re: [EAI] Re: draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <325112866.20070329155022@pobox.com> <1158577433.20070330094455@pobox.com> <460E3AE2.7F36@xyzzy.claranet.de> <46116665.A90@xyzzy.claranet.de> Message-ID: Date: Tue, 03 Apr 2007 10:10:29 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46116665.A90@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 02 Apr 2007 21:24:05 +0100, Frank Ellermann wrote: > The EXPRESSLY FORBIDDEN is about CTEs different from 8bit, 7bit, or > binary for composite types (multipart/* or message/* at the moment), > it's on line 926 of RFC 2045. > > The "SHOULD" is actually only a "should" about using 7bit for message/* > subtypes in section 5.2.4 in RFC 2046. In other words a message/utf-8 > using 8bit does not violate an upper case SHOULD, and it also doesn't > come into any conflicts with the EXPRESSLY FORBIDDEN in RFC 2045. But it would conflict with that EXPRESSLY FORBIDDEN if you tried to downgrade it as envisaged in the current DSN draft. So how would you propose to downgrade it? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 03 05:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfDI-0006tz-1A; Tue, 03 Apr 2007 05:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfDH-0006tl-G8 for ima@ietf.org; Tue, 03 Apr 2007 05:22:03 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfDF-0003iQ-TU for ima@ietf.org; Tue, 03 Apr 2007 05:22:03 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew$man^ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46121cb8.10918.1bd for ima@ietf.org; Tue, 3 Apr 2007 10:22:00 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l339LnpJ023106 for ; Tue, 3 Apr 2007 10:21:50 +0100 (BST) To: IMA Subject: Re: [EAI] Re: Discussion of draft-ietf-eai-downgrade-03.txt References: <46098893.2BB4@xyzzy.claranet.de> <460BF5D7.5CC1@xyzzy.claranet.de> <460E472C.46F3@xyzzy.claranet.de> <46117AEC.61E7@xyzzy.claranet.de> Message-ID: Date: Tue, 03 Apr 2007 10:21:48 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46117AEC.61E7@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 02 Apr 2007 22:51:40 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > [8BITMIME] >> RFC 1652 also requires it to be downgraded before it is passed to a >> Non-8BITMIME MTA, and there is no way to do that downgrade within a >> MIME part header, because such headers do not come withn the scope >> of any Content-Transfer-Encoding header. > > 8BITMIME to 7BIT is the job of those gatewys, not of UTF8SMTP. If they > can't do this they're forced to reject the mail. Of course I fail to > see any problems with 8bit in MIME part headers because I don't intend > to allow this in the first place (for MIME 1.0 as quoted above). > >>> IMO "some arbitrary octet-aligned material" does _not_ imply that >>> servers are supposed to check the MIME syntax, let alone version. > >> They have no choice but to check the MIME syntax, and in fact that >> is precisely what they do. > > If any decent 8BITMIME server receiving BODY=8BITMIME from a client, > and relaying it (as is) to another 8BITMIME mailer, ever looks for > 8bit characters in MIME part headers in the body, I'd really wish to > know *why*. Nobody has suggested that would be necessary. It is only required when downgrading to Non-8BITMIME. >> We have already discused this in connection with the source code >> of Sendmail, which indeed does a full MIME recursive descent > > That was an 8BITMIME-to-7BIT gateway, not an 8BITMIME-to-8BITMIME > relay. I assume that UTF8SMTP-to-7BIT is functionally equivalent > to UTF8SMT-to-8BITMIME followed by 8BITMIME-to-7BIT. If that's the > case EAI only needs to solve UTF8SMTP-to-8BITMIME. Exactly. Which means that if MIME body part headers contain UTF-8 (whether as an extension to MIME 1.0, or as some new-angled MIME 2.0 makes no difference), then they have to be downgraded (in a 2231 manner) as soon as they leave the UTF8SMTP unoiverse, even if they are still remaining in the 8BITMIME universe, because the 8BITMIME universe does not othersise know how to downgrade them to Non-8BITMIME. > If the 2nd step > (to 7BIT) doesn't work for any reasons, then doing it in one instead > of two steps also won't work. Exactly, which is why the problem has to be fixed in the first step. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 03 13:18:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmdM-0000FX-Na; Tue, 03 Apr 2007 13:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmdL-0000FS-Sn for ima@ietf.org; Tue, 03 Apr 2007 13:17:27 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmdI-0000di-3O for ima@ietf.org; Tue, 03 Apr 2007 13:17:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HYmd6-0002yB-Tl for ima@ietf.org; Tue, 03 Apr 2007 19:17:12 +0200 Received: from d253195.dialin.hansenet.de ([80.171.253.195]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2007 19:17:12 +0200 Received: from nobody by d253195.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2007 19:17:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 03 Apr 2007 19:08:00 +0200 Organization: Lines: 70 Message-ID: <461289F0.1AF1@xyzzy.claranet.de> References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <325112866.20070329155022@pobox.com> <1158577433.20070330094455@pobox.com> <460E3AE2.7F36@xyzzy.claranet.de> <46116665.A90@xyzzy.claranet.de> Mime-Version: 1.0 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253195.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [EAI] Re: draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: >> The "SHOULD" is actually only a "should" about using 7bit for message/* >> subtypes in section 5.2.4 in RFC 2046. In other words a message/utf-8 >> using 8bit does not violate an upper case SHOULD, and it also doesn't >> come into any conflicts with the EXPRESSLY FORBIDDEN in RFC 2045. > But it would conflict with that EXPRESSLY FORBIDDEN if you tried to > downgrade it as envisaged in the current DSN draft. The DSN draft is at -00, it's far from ready, it captures the basic ideas and most issues that have to be addressed in the next rounds of this I-D. > So how would you propose to downgrade it? Downgrading a message/utf-8 will be explained in the "downgrading" I-D for 8BITMIME-to-7BIT gateways knowing what a message/utf-8 is. If they don't know this they can either give up, or use a radical approach like application/message. We're talking about DSNs concerning messages originally sent from an MSA supporting UTF8SMTP. The forward route somehow reached a hop triggering a DSN, e.g. an ordinary non-delivery report ("bounce"). Now that DSN is returned to the originator "as indicated in the reverse- path". There's no problem if the event triggering the DSN was at a 7BIT mailer, somehow the original message/utf-8 was already "downgraded" to a 7BIT message/rfc822 on the forward route in this case. Similarly the message was already 8BITMIME if the event triggering a DSN was at an 8BITMIME mailer, the message/utf-8 was already "downgraded" to an 8BITMIME message/rfc822 on the forward route in this case. Therefore we only need to worry about the original message/utf-8 at an UTF8SMTP capable relay triggering a DSN (e.g. if there's no way forward for UTF8SMTP, and no way to downgrade the message). This UTF8SMTP mailer will then be forced to send an UTF8SMTP DSN to an UTF8SMTP originator. Unfortunately with 2821-SMTP it's possible that the reverse route is very different from the forward route, and it can hit a hop that does not support UTF8SMTP. If that hop still supports 8BITMIME we're fine, the message/utf-8 part in the DSN can be downgraded as specified in the "downgrading" I-D (not yet ready, but no showstopper in sight). The one and only _bad_ situation is a 7BIT relay on the reverse path. But we still know that "something" (the MSA and likely the MUA) on the side of the originator did support UTF8SMTP. Therefore the DSN only has to be "tunneled" through this (IMO very unlikely) 7bit hop on the reverse route. For that a new MIME type like application/message can be used to encapsulate any 8bit message/* subtype, not limited to the message/utf-8 part in the DSN. If that fails the DSN is rejected (= lost), tough. UTF8SMTP senders should make sure that they don't employ 7BIT relays on any routes associated with their reverse path. It's no unheard of situation, senders will learn to get this right. Last but not least the (IMO unlikely) 7BIT hop in the reverse path can be on the side of the receiver. In that case it's an error of the receiver, they accepted mail in a form that they can't reliably return if necessary. They shouldn't do this, like they shouldn't accept SPF FAIL / mail worms / spam / ... As you said elsewhere 7bit hops are supposed to die out really soon now, especially on routes somehow associated with UTF8SMTP routes. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 03:19:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYzln-0008JC-PV; Wed, 04 Apr 2007 03:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYzlm-0008Hc-HW for ima@ietf.org; Wed, 04 Apr 2007 03:19:02 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYzlk-0003pr-NK for ima@ietf.org; Wed, 04 Apr 2007 03:19:02 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3B802597B4 for ; Wed, 4 Apr 2007 09:18:58 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31741-10 for ; Wed, 4 Apr 2007 09:18:54 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7FD82597B3 for ; Wed, 4 Apr 2007 09:18:53 +0200 (CEST) Message-ID: <4613515D.7010806@alvestrand.no> Date: Wed, 04 Apr 2007 09:18:53 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] Reminder: EAI will not fix basic issues with the way SMTP currently works X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Reminder: This WG is concerned ONLY with making a mail system based on SMTP that works for internationalized mail. Basic issues that are contentious in SMTP, such as sender verification, message signing and the use of returned messages, will NOT be addressed by EAI, and technical arguments that basically say "you should do this because SMTP needs to be changed in this way anyway", where the change is not already in an IETF-approved document, will not be considered. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 06:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ2O9-000711-LF; Wed, 04 Apr 2007 06:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ2O3-0006wt-Om for ima@ietf.org; Wed, 04 Apr 2007 06:06:43 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ2K2-0003De-L4 for ima@ietf.org; Wed, 04 Apr 2007 06:02:44 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3#clerew#man&ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461377b8.f120.27c for ima@ietf.org; Wed, 4 Apr 2007 11:02:32 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l34A2VUq000786 for ; Wed, 4 Apr 2007 11:02:32 +0100 (BST) Date: Wed, 04 Apr 2007 11:02:31 +0100 To: IMA Subject: Re: [EAI] Re: draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <325112866.20070329155022@pobox.com> <1158577433.20070330094455@pobox.com> <460E3AE2.7F36@xyzzy.claranet.de> <46116665.A90@xyzzy.claranet.de> <461289F0.1AF1@xyzzy.claranet.de> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <461289F0.1AF1@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 03 Apr 2007 18:08:00 +0100, Frank Ellermann wrote: > Therefore we only need to worry about the original message/utf-8 at an > UTF8SMTP capable relay triggering a DSN (e.g. if there's no way forward > for UTF8SMTP, and no way to downgrade the message). Yes, that is the interesting case from a DSN POV. I already commented ion it in my earlier response to that DSN draft (Comments on the DSN draft (draft-ietf-eai-dsn-00.txt on March 7th). > > This UTF8SMTP mailer will then be forced to send an UTF8SMTP DSN to an > UTF8SMTP originator. Unfortunately with 2821-SMTP it's possible that > the reverse route is very different from the forward route, and it can > hit a hop that does not support UTF8SMTP. > > If that hop still supports 8BITMIME we're fine, the message/utf-8 part > in the DSN can be downgraded as specified in the "downgrading" I-D (not > yet ready, but no showstopper in sight). No we're not fine, because the hop after that might be to Non-8BITMIME. > > The one and only _bad_ situation is a 7BIT relay on the reverse path. > But we still know that "something" (the MSA and likely the MUA) on the > side of the originator did support UTF8SMTP. Therefore the DSN only > has to be "tunneled" through this (IMO very unlikely) 7bit hop on the > reverse route. It's unlikely, but that does not make it impossible. The easiest solution AFAICS is to send the returned message as a message/rfc822 (UTF8SMTP-universe version). We are gong to need a downgrade mechanism for that beast in any case (essentially, you recursively descend through it and downgrade such UTF8SMTP headers, or whatever we decide to call them, as they are found). If you are just returning headers, then they are sent as a text/utf-8-headers (or maybe even the existing text/rfc822-headers if you can get away with adding a charset parameter to it). Text/* types are already downgradable by current 8BITMIME downgraders. And for the delivery status itself you need a message/utf8-delivery-status (or rather an application/utf8-delivery-status because it is easier to write a downgrade for it) or maybe an extended version of the existing message/delivery-status (but that extension might be tricky). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 07:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3uU-0004yT-1V; Wed, 04 Apr 2007 07:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3uT-0004yE-8n for ima@ietf.org; Wed, 04 Apr 2007 07:44:17 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ3uR-000341-VH for ima@ietf.org; Wed, 04 Apr 2007 07:44:17 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33D992597B7 for ; Wed, 4 Apr 2007 13:44:15 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06341-07 for ; Wed, 4 Apr 2007 13:44:09 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 397802597B6 for ; Wed, 4 Apr 2007 13:44:09 +0200 (CEST) Message-ID: <46138F89.30104@alvestrand.no> Date: Wed, 04 Apr 2007 13:44:09 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [EAI] Number of senders to the mailing list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I did a count for all "my" WGs today on who's sent how much mail over the last 2 weeks. Here are the results for EAI: msgs since 21-Mar-2007 1 53 27.04 Frank Ellermann 2 52 53.57 Kari Hurtta 3 29 68.37 "Charles Lindsey" 4 10 73.47 "YAO Jiankang" 5 8 77.55 Harald Alvestrand 6 7 81.12 "Yao Jiankang" 7 7 84.69 Harald Tveit Alvestrand 8 6 87.76 "abel" 9 6 90.82 Kari Hurtta 10 5 93.37 John C Klensin 11 4 95.41 Bill McQuillan 12 2 96.43 Yangwoo Ko 13 2 97.45 Chris Newman 14 1 97.96 Martin Duerst 15 1 98.47 fujiwara@jprs.co.jp 16 1 98.98 Ted Hardie 17 1 99.49 "Kari Hurtta" 18 1 100.00 Arnt Gulbrandsen _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 10:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6Eg-0001BP-1X; Wed, 04 Apr 2007 10:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6Ee-0001B2-PU for ima@ietf.org; Wed, 04 Apr 2007 10:13:16 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6Ed-0007ND-0H for ima@ietf.org; Wed, 04 Apr 2007 10:13:16 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26A542597C2 for ; Wed, 4 Apr 2007 16:13:14 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10960-02 for ; Wed, 4 Apr 2007 16:13:02 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB2492597C1 for ; Wed, 4 Apr 2007 16:13:01 +0200 (CEST) Message-ID: <4613B26D.20609@alvestrand.no> Date: Wed, 04 Apr 2007 16:13:01 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [EAI] POLL: HDR= extension on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As of this moment, I believe the current alternatives are on the table: A - New SMTP argument to MAIL FROM: HDR=, with defined value HDR=UTF8 This indicates that the message being sent contains UTF-8 data in MAIL FROM, RCPT TO or headers (including inner body headers), which means that it needs downgrading before it can be passed to an ASCII-only recipient. Advantage: In the case where the recieving MTA knows which recipients can handle UTF8SMTP mail, and the MTA does not have downgrade capability, it can reject recipients by replying to the RCPT TO command with an appropriate error code. (It will still have to do downgrade-or-bounce if it discovers the final destination after accepting the RCPT TO command.) Advantage: The MTA can decide on whether downgrading is required based on the SMTP argument, and can treat any 8-bit character in the headers as a protocol error if the flag is not given. B - No new SMTP argument. Advantage: Less complexity. No need for an MTA to consider whether or not to apply downgrading based on the error code it got back; any recipients rejected with a 5XX code can be considered rejected immediately. Advantage: Less cruft for the UTF8SMTP case - cleaner end state. There are other opinions on the relative merits of the two alternatives, but I believe those are the most important ones If you have an opinion on this issue, please send a note to the mailing list with ONE of the following statements: A - I support HDR=UTF8 B - I support NOT adding HDR=UTF8 C - I have an opinion different from the 2 alternatives given, which is.... This poll closes in 7 days, on April 9, 2007. Harald, for the chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 10:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6L5-0005u4-PL; Wed, 04 Apr 2007 10:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6L4-0005ts-BK for ima@ietf.org; Wed, 04 Apr 2007 10:19:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6Ko-0002Xj-3K for ima@ietf.org; Wed, 04 Apr 2007 10:19:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZ6Ki-0001Km-W5 for ima@ietf.org; Wed, 04 Apr 2007 16:19:33 +0200 Received: from d252030.dialin.hansenet.de ([80.171.252.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2007 16:19:32 +0200 Received: from nobody by d252030.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2007 16:19:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 04 Apr 2007 16:18:51 +0200 Organization: Lines: 2 Message-ID: <4613B3CB.129F@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252030.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [EAI] Re: POLL: HDR= extension on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A - I support HDR=UTF8 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 11:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7Pg-0002oR-Qh; Wed, 04 Apr 2007 11:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7Pf-0002oM-IX for ima@ietf.org; Wed, 04 Apr 2007 11:28:43 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7Pa-0004UD-P0 for ima@ietf.org; Wed, 04 Apr 2007 11:28:43 -0400 Received: (snipe 27790 invoked by uid 0); 5 Apr 2007 00:29:04 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.559766 secs); Received: from unknown (HELO ?192.168.10.249?) (Z???own@218.36.241.202) by unknown with SMTP; 5 Apr 2007 00:29:03 +0900 X-SNIPER-SENDERIP: 218.36.241.202 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: ima@ietf.org, yangwooko@gmail.com Message-ID: <4613C419.7070607@icu.ac.kr> Date: Thu, 05 Apr 2007 00:28:25 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: EAI WG Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM References: <4613B26D.20609@alvestrand.no> In-Reply-To: <4613B26D.20609@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > B - I support NOT adding HDR=UTF8 Support B. This will (hopefully) result in a more cleanly internationalized email environment. (Next generation email developers will wonder why we should ALWAYS put HDR=UTF8 if we go for A) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 12:12:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ85m-0001aV-Hx; Wed, 04 Apr 2007 12:12:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ85l-0001XA-Rq for ima@ietf.org; Wed, 04 Apr 2007 12:12:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ85g-0004gM-6C for ima@ietf.org; Wed, 04 Apr 2007 12:12:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZ85d-0001JD-Tw for ima@ietf.org; Wed, 04 Apr 2007 18:12:05 +0200 Received: from d252030.dialin.hansenet.de ([80.171.252.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2007 18:12:05 +0200 Received: from nobody by d252030.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2007 18:12:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 04 Apr 2007 18:07:57 +0200 Organization: Lines: 51 Message-ID: <4613CD5D.15DC@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <4613C419.7070607@icu.ac.kr> 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: d252030.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [EAI] HDR=UTF8 (was: POLL: HDR= extension on MAIL FROM) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: > Next generation email developers will wonder why we should > ALWAYS put HDR=UTF8 if we go for A That's IMO not the case, it's possible to have this scenario: envelope: MAIL FROM: RCPT TO: RCPT TO:<2nd@ascii.example> DATA From:me@ascii.example To:2nd@ascii.example ... An ordinary message/rfc822 from an ASCII-address, to a second ASCII address, with a blind carbon copy to your UTF-8 address. If the 2nd address is a rfc822 mailbox the mail can be accepted as is for 2nd@ascii (no message/utf-8, no downgrading required). Another slightly more tricky scenario without HDR=UTF-8: envelope: MAIL FROM: ALT-ADDRESS=you@ascii.example RCPT TO: DATA From:you@ascii.example To:me@ascii.example ... You used your default envelope sender address including an ASCII alternative. Knowing that the mail is to me you did not send a message/utf-8, but an ordinary message/rfc822. The receiving SMTP might try to record the Return-Path incl. your UTF8SMTP address, thereby modifying the message/rfc822 into a message/utf-8. But if it knows that my mailbox can't handle message/utf-8 that would be a bad move, and accepting the mail as is with an ASCII Return-Path: will work. Without a HDR=UTF-8 the mailer can assume that the DATA is an ordinary 8BITMIME message/rfc822 (with an ASCII header), and reject it after DATA if that turns out to be a lie. Frank P.S.: I've omitted BODY=8BITMIME in the example envelopes _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 15:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZB7e-0007Lp-4Z; Wed, 04 Apr 2007 15:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZB7d-0007Lf-0a for ima@ietf.org; Wed, 04 Apr 2007 15:26:21 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZB7Y-0004mA-F0 for ima@ietf.org; Wed, 04 Apr 2007 15:26:20 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZB7W-000CSc-0J; Wed, 04 Apr 2007 15:26:14 -0400 Date: Wed, 04 Apr 2007 15:26:13 -0400 From: John C Klensin To: Harald Alvestrand , EAI WG Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: In-Reply-To: <4613B26D.20609@alvestrand.no> References: <4613B26D.20609@alvestrand.no> X-Mailer: Mulberry/4.0.7 (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: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 04 April, 2007 16:13 +0200 Harald Alvestrand wrote: > If you have an opinion on this issue, please send a note to > the mailing list with ONE of the following statements: > > A - I support HDR=UTF8 > B - I support NOT adding HDR=UTF8 > C - I have an opinion different from the 2 alternatives given, > which is.... I support B -- NOT adding an additional parameter. My reasoning is a trifle different from your summary so, for whatever it is worth... (i) We know this parameter is not strictly necessary, even if it might be a convenience in some cases. (ii) Every additional parameter we add that isn't strictly orthogonal to all the others creates an additional opportunity for silly states. That, in term, requires that we understand, and probably specify actions for, the error conditions, and increases the risks of interoperability problems and bugs. >From a syntax standpoint, if we add HDR=UTF8, a mail transaction can contain any combination of zero or more of HDR, BODY, and ALT-ADDR. So, for example... Are all of those combinations meaningful? If they are not, and some of the inconsistent ones are specified, what do we expect to have happen? In particular, do we treat HDR=UTF8 as implying BODY=8BITMIME strongly enough that the latter can be omitted? Could that cause other problems? Or, if we don't make that type of rule, could HDR without BODY take us back down the path of "Just Send "? While I think that, given time and energy, we could answer those questions, produce firm specifications, and expect that most (but not all) implementations would understand and follow the instructions well enough to get things right, it seems to me to be a high cost and high risk for something that is not absolutely necessary. And... (iii) If our target and expectation are a long-term mail environment in which substantially everyone supports UTF8SMTP and those who do not understand that they are running crippled and obsolete systems, then this parameter becomes long-term clutter with no value. The same could be said about 8BITMIME today and perhaps, long-term, about ALT-ADDR itself. But the existence of two of them is, IMO, a strong reason to not add a third, not a justification for it. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 15:34:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBFh-00088g-VI; Wed, 04 Apr 2007 15:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBFg-00088Y-VH for ima@ietf.org; Wed, 04 Apr 2007 15:34:40 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBFc-0006AL-D0 for ima@ietf.org; Wed, 04 Apr 2007 15:34:40 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew*man*ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4613fdc9.12421.34 for ima@ietf.org; Wed, 4 Apr 2007 20:34:33 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l34JYV8i014013 for ; Wed, 4 Apr 2007 20:34:33 +0100 (BST) Subject: Re: [EAI] Re: draft-ietf-eai-utf8headers-04.txt (#3) new chapter + possible draft-ietf-eai-smtpext-04.txt: (#15) update References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dmz1xtgcv.fsf@Hurtta06k.keh.iki.fi> <325112866.20070329155022@pobox.com> <1158577433.20070330094455@pobox.com> <460E3AE2.7F36@xyzzy.claranet.de> <46116665.A90@xyzzy.claranet.de> <461289F0.1AF1@xyzzy.claranet.de> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 04 Apr 2007 20:34:31 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 03 Apr 2007 18:08:00 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > The DSN draft is at -00, it's far from ready, it captures the basic ideas > and most issues that have to be addressed in the next rounds of this I-D. > >> So how would you propose to downgrade it? > > Downgrading a message/utf-8 will be explained in the "downgrading" I-D > for 8BITMIME-to-7BIT gateways knowing what a message/utf-8 is. If they > don't know this they can either give up, or use a radical approach like > application/message. Yes, you keep saying that it will be downgraded, as if this were a solved problem. I have repeatedly asked you to state plainly what you mean by a "message/utf-8" and exactly how you would propose to downgrade it. It is no use continuing to discuss it unless you are willing to do that. At present, it is just vapourware. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 20:16:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFdo-0005uj-Cm; Wed, 04 Apr 2007 20:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFdn-0005pi-70 for ima@ietf.org; Wed, 04 Apr 2007 20:15:51 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFdl-0008NB-KA for ima@ietf.org; Wed, 04 Apr 2007 20:15:51 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l350FaJ5028234; Thu, 5 Apr 2007 09:15:36 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l350FZHh028233; Thu, 5 Apr 2007 09:15:35 +0900 Date: Thu, 5 Apr 2007 09:15:35 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <20070405001535.GB17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Apr 04, 2007 at 03:26:13PM -0400, John C Klensin wrote: > > (iii) If our target and expectation are a long-term mail > environment in which substantially everyone supports UTF8SMTP > and those who do not understand that they are running crippled > and obsolete systems, then this parameter becomes long-term > clutter with no value. The same could be said about 8BITMIME > today and perhaps, long-term, about ALT-ADDR itself. But the > existence of two of them is, IMO, a strong reason to not add a > third, not a justification for it. UTF8 is one of ASCII compatible encodings of full Unicode characters. KSC5601,BIG5 etc are all ASCII compatible encodings for subsets of Unicode characters. Some mail vendors want to use "HDR=KSC5601" for regional needs. Moreover, we can't assume there won't come any other ASCII compatible encoding UTF?? (other than UTF8) of full Unicode characters in the future. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 20:42:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZG3D-00008s-Dc; Wed, 04 Apr 2007 20:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZG3C-00008l-6E for ima@ietf.org; Wed, 04 Apr 2007 20:42:06 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZG3A-0006Ur-Iu for ima@ietf.org; Wed, 04 Apr 2007 20:42:06 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l350fwJ5032215; Thu, 5 Apr 2007 09:41:58 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l350fwMt032214; Thu, 5 Apr 2007 09:41:58 +0900 Date: Thu, 5 Apr 2007 09:41:58 +0900 From: Soobok Lee To: Harald Alvestrand Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <20070405004158.GC17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4613B26D.20609@alvestrand.no> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Apr 04, 2007 at 04:13:01PM +0200, Harald Alvestrand wrote: > > A - I support HDR=UTF8 > B - I support NOT adding HDR=UTF8 > C - I have an opinion different from the 2 alternatives given, which is.... C) HDR= is newly defined parameter. But HDR=UTF8 is optional and may be omitted. Mail servers may assume HDR=UTF8 if HDR= parameter is not prenet in SMTP session. This is for making room for other encoding than UTF8 in HDR=. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 04 22:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHYn-0006HX-GS; Wed, 04 Apr 2007 22:18:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHYk-0006EF-6O for ima@ietf.org; Wed, 04 Apr 2007 22:18:47 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZHYg-0003Px-Uh for ima@ietf.org; Wed, 04 Apr 2007 22:18:46 -0400 Received: (eyou send program); Thu, 05 Apr 2007 10:18:14 +0800 Message-ID: <375739494.11757@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Thu, 05 Apr 2007 10:18:14 +0800 Message-ID: <024701c77728$a8d02940$096ff1da@cnnicyao> From: "YAO Jiankang" To: "Harald Alvestrand" , "EAI WG" References: <375696043.17551@cnnic.cn> Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Date: Thu, 5 Apr 2007 10:17:36 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577469988==" Errors-To: ima-bounces@ietf.org --===============0577469988== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBBbHZlc3RyYW5k IiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpUbzogIkVBSSBXRyIgPGltYUBpZXRmLm9yZz4NClNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMDQsIDIwMDcgMTA6MTMgUE0NClN1YmplY3Q6IFtFQUldIFBP TEw6IEhEUj0gZXh0ZW5zaW9uIG9uIE1BSUwgRlJPTQ0KDQo+IEIgLSBJIHN1cHBvcnQgTk9UIGFk ZGluZyBIRFI9VVRGOA0KDQpCIGlzIG9rIGZvciBtZS4NCg0KWUFPIEppYW5rYW5nDQpDTk5JQw== --===============0577469988== 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 --===============0577469988==-- From ima-bounces@ietf.org Thu Apr 05 01:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKKt-0004lb-NT; Thu, 05 Apr 2007 01:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKKs-0004lO-39 for ima@ietf.org; Thu, 05 Apr 2007 01:16:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKKn-0004x0-M3 for ima@ietf.org; Thu, 05 Apr 2007 01:16:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZKKb-0001hx-T7 for ima@ietf.org; Thu, 05 Apr 2007 07:16:21 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 07:16:21 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 07:16:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 05 Apr 2007 08:16:15 +0300 Lines: 19 Message-ID: <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> References: <4613B26D.20609@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Kari Hurtta Subject: [EAI] Re: POLL: HDR= extension on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A - I support HDR=UTF8 (however not very strongly) Paramater value should NOT look like charset name, therefore HDR=UTF8SMTP is better value for HDR. ( otherwise there is danger for invention of HDR=KSC560 as Soobok Lee mentions) ( I think that in somewhere on Header-Type: label thread I mentioned that I prefer ESMTP parameter. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 01:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKex-0004Ow-Di; Thu, 05 Apr 2007 01:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKew-0004Or-6D for ima@ietf.org; Thu, 05 Apr 2007 01:37:22 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKer-0005k3-GS for ima@ietf.org; Thu, 05 Apr 2007 01:37:22 -0400 Received: (snipe 28912 invoked by uid 0); 5 Apr 2007 14:37:42 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.803645 secs); Received: from unknown (HELO ?210.107.139.204?) (Z???own@210.107.139.204) by unknown with SMTP; 5 Apr 2007 14:37:41 +0900 X-SNIPER-SENDERIP: 210.107.139.204 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org, yangwooko@gmail.com Message-ID: <46148B01.1010202@icu.ac.kr> Date: Thu, 05 Apr 2007 14:37:05 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] HDR=UTF8 References: <4613B26D.20609@alvestrand.no> <4613C419.7070607@icu.ac.kr> <4613CD5D.15DC@xyzzy.claranet.de> In-Reply-To: <4613CD5D.15DC@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Really sorry for making you confused. Please blame my poor English rather than me :-( . My gut feeling said that IF we are very successful (i.e. new clean UTF8SMTP world), lazy developers will always put HDR=UTF8 regardless of whether it is really needed or not because; (1) it is harmless if there is no UTF8SMTP-incapable server en route, which will be very often the case. (2) it doesn't need to implement and run codes to check whether this option should be added or not. Frank Ellermann wrote: > Yangwoo Ko wrote: > >> Next generation email developers will wonder why we should >> ALWAYS put HDR=UTF8 if we go for A > > That's IMO not the case, it's possible to have this scenario: > > envelope: > MAIL FROM: > RCPT TO: > RCPT TO:<2nd@ascii.example> > DATA > From:me@ascii.example > To:2nd@ascii.example > ... > > An ordinary message/rfc822 from an ASCII-address, to a second > ASCII address, with a blind carbon copy to your UTF-8 address. > > If the 2nd address is a rfc822 mailbox the mail can be accepted > as is for 2nd@ascii (no message/utf-8, no downgrading required). > > Another slightly more tricky scenario without HDR=UTF-8: > > envelope: > MAIL FROM: ALT-ADDRESS=you@ascii.example > RCPT TO: > DATA > From:you@ascii.example > To:me@ascii.example > ... > > You used your default envelope sender address including an > ASCII alternative. Knowing that the mail is to me you did > not send a message/utf-8, but an ordinary message/rfc822. > > The receiving SMTP might try to record the Return-Path incl. > your UTF8SMTP address, thereby modifying the message/rfc822 > into a message/utf-8. But if it knows that my mailbox can't > handle message/utf-8 that would be a bad move, and accepting > the mail as is with an ASCII Return-Path: > will work. > > Without a HDR=UTF-8 the mailer can assume that the DATA is > an ordinary 8BITMIME message/rfc822 (with an ASCII header), > and reject it after DATA if that turns out to be a lie. > > Frank > > P.S.: I've omitted BODY=8BITMIME in the example envelopes > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 02:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZLZs-0008LB-8U; Thu, 05 Apr 2007 02:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZLZr-0008Kn-K1 for ima@ietf.org; Thu, 05 Apr 2007 02:36:11 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZLZq-0003NY-1a for ima@ietf.org; Thu, 05 Apr 2007 02:36:11 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l356a3J5028654; Thu, 5 Apr 2007 15:36:03 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l356a2oG028648; Thu, 5 Apr 2007 15:36:02 +0900 Date: Thu, 5 Apr 2007 15:36:02 +0900 From: Soobok Lee To: Kari Hurtta Subject: Re: [EAI] Re: POLL: HDR= extension on MAIL FROM Message-ID: <20070405063602.GD17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Apr 05, 2007 at 08:16:15AM +0300, Kari Hurtta wrote: > > A - I support HDR=UTF8 > > (however not very strongly) > > Paramater value should NOT look like charset name, therefore > > HDR=UTF8SMTP > > is better value for HDR. > I agree with you that UTF8SMTP is better and clearer. This is somewhat off the topic, but, I am not UTF8 partisan. Some proprietary solutions may introduce HDR=KSC5601SMTP for internal or regional use for their own *risk*/benefit. many email portals are using local charset encoding for both header and *body* in 8-bit clean format of single message file for storage/transfer efficiency. We don't need to try to standardize such non-standard way of SMTP here. Defining some "HDR=" parameter values is enough. Let them extend parameter values for their own risk /benefits in interoperable ways. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 07:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQ0G-0007ja-EO; Thu, 05 Apr 2007 07:19:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQ0F-0007j1-7a for ima@ietf.org; Thu, 05 Apr 2007 07:19:43 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZQ08-0003nX-MH for ima@ietf.org; Thu, 05 Apr 2007 07:19:43 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew^man&ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4614db38.fd2b.139 for ima@ietf.org; Thu, 5 Apr 2007 12:19:20 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l35BJKQl029532 for ; Thu, 5 Apr 2007 12:19:21 +0100 (BST) Date: Thu, 05 Apr 2007 12:19:19 +0100 To: IMA Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM References: <4613B26D.20609@alvestrand.no> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4613B26D.20609@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 04 Apr 2007 15:13:01 +0100, Harald Alvestrand wrote: > As of this moment, I believe the current alternatives are on the table: > > A - New SMTP argument to MAIL FROM: HDR=, with defined value HDR=UTF8 > > This indicates that the message being sent contains UTF-8 data in MAIL > FROM, RCPT TO or headers (including inner body headers), which means > that it needs downgrading before it can be passed to an ASCII-only > recipient. Not sure that is quite right. Frank has raised the possibility that there might be a MAIL FROM or a RCPT TO with utf-8 address (possibly + Alt-address) but a body that was 100% pure ASCII. It is arguable that case does not need HDR=UTF8 because the MAIL FROM or RCPT TO commands already show the extent to which UTF8SMTP is required for the next hop. > Advantage: The MTA can decide on whether downgrading is required based > on the SMTP argument, and can treat any 8-bit character in the headers > as a protocol error if the flag is not given. Ans that is the argument that was given for the Header-Type header, but it did not carry thew day then. So I suppose that makes me C, because I don't think the definition is quite right. But between A and B I am more or less neutral - perhaps marginally in favour of B, on the grounds that even if HDR-UTF-8 is not given, you can't be sure until you actually look at the body (though that means you can only tell after DATA, which might make you decide to reject rather than do a last-minute downgrade). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 11:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTrF-0004Yj-V9; Thu, 05 Apr 2007 11:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTrE-0004Ya-Ma for ima@ietf.org; Thu, 05 Apr 2007 11:26:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTr9-0006ky-9X for ima@ietf.org; Thu, 05 Apr 2007 11:26:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZTqh-0006vl-7h for ima@ietf.org; Thu, 05 Apr 2007 17:26:07 +0200 Received: from d255087.dialin.hansenet.de ([80.171.255.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 17:26:07 +0200 Received: from nobody by d255087.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 17:26:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 05 Apr 2007 17:25:02 +0200 Organization: Lines: 29 Message-ID: <461514CE.7D24@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <4613C419.7070607@icu.ac.kr> <4613CD5D.15DC@xyzzy.claranet.de> <46148B01.1010202@icu.ac.kr> 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: d255087.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [EAI] Re: HDR=UTF8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: > My gut feeling said that IF we are very successful (i.e. new clean > UTF8SMTP world), lazy developers will always put HDR=UTF8 regardless > of whether it is really needed or not because; > (1) it is harmless if there is no UTF8SMTP-incapable server en route, > which will be very often the case. > (2) it doesn't need to implement and run codes to check whether this > option should be added or not. Yes, that's a plausible scenario. OTOH if receivers reject HDR=UTF8 -- or as Kari said HDR=UTF8SMTP -- for mailboxes not accepting this type of message ("strict" message/utf-8 or "lazy developer" message/rfc822) the senders getting unnecessary bounces would submit bug reports... :-) The parameter makes it easier to "opt-in" to EAI for the parts of the world where it's not very relevant (Latin-1 languages close to ASCII), and where users will keep their "legacy" mailboxes for some decades. Without the parameter well-behaved MXs without "downgrade" capability will have to reject any UTF8SMTP message after DATA as soon as there's a single "legacy" mailbox. Ordinary users do not upgrade unless it's very important, or they install a new operating system. Or mybe it's only me (= lazy user). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 12:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUgH-00076I-HW; Thu, 05 Apr 2007 12:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUgF-00072i-To for ima@ietf.org; Thu, 05 Apr 2007 12:19:23 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZUgB-0005DK-KQ for ima@ietf.org; Thu, 05 Apr 2007 12:19:23 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35472) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HZUc3-00082N-1n (Exim 4.63) (return-path ); Thu, 05 Apr 2007 17:15:03 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HZUc3-0007kV-Gw (Exim 4.54) (return-path ); Thu, 05 Apr 2007 17:15:03 +0100 Date: Thu, 5 Apr 2007 17:15:03 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM In-Reply-To: Message-ID: References: <4613B26D.20609@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I don't have any particular opinion, but I wonder why the BODY= parameter was deemed necessary if we now think a HDR= parameter is not. Tony. -- f.a.n.finch http://dotat.at/ NORTH FAIR ISLE: NORTHEAST 4 OR 5, BACKING NORTHWEST 3 OR 4. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE THEN FAIR. MODERATE OR POOR BECOMING GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 12:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZV6Y-0000Fz-94; Thu, 05 Apr 2007 12:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZV6X-0000Fu-7j for ima@ietf.org; Thu, 05 Apr 2007 12:46:33 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZV6R-000119-C3 for ima@ietf.org; Thu, 05 Apr 2007 12:46:33 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZV6O-000MLm-8h; Thu, 05 Apr 2007 12:46:24 -0400 Date: Thu, 05 Apr 2007 12:46:23 -0400 From: John C Klensin To: Tony Finch Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <762108E6AE3BB1F0D5DFF78C@p3.JCK.COM> In-Reply-To: References: <4613B26D.20609@alvestrand.no> X-Mailer: Mulberry/4.0.7 (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: ea4ac80f790299f943f0a53be7e1a21a Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 05 April, 2007 17:15 +0100 Tony Finch wrote: > I don't have any particular opinion, but I wonder why the > BODY= parameter was deemed necessary if we now think a HDR= > parameter is not. You'd need to ask Ned -- he may remember the discussion, if there was one. But, if I needed to guess, I would say that we were (i) more optimistic about the ability to believe parameter values than we are now (ii) more optimistic about the ability to delay in-depth message examination and the importance of doing so than we are now (iii) justifiably concerned about the implications of the Just-send-8 trend and a need to construct a wall around it. If your question is really about whether we would require that parameter if we were doing 8BITMIME for the first time today, I would share your doubts. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 13:23:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVgN-0001J9-Eb; Thu, 05 Apr 2007 13:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVgM-0001J2-4M for ima@ietf.org; Thu, 05 Apr 2007 13:23:34 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZVgK-0005de-RJ for ima@ietf.org; Thu, 05 Apr 2007 13:23:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZVgI-0004SD-0E for ima@ietf.org; Thu, 05 Apr 2007 19:23:30 +0200 Received: from d255087.dialin.hansenet.de ([80.171.255.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 19:23:29 +0200 Received: from nobody by d255087.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 19:23:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 05 Apr 2007 19:20:59 +0200 Organization: Lines: 32 Message-ID: <46152FFB.698F@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255087.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: >> HDR=UTF8SMTP >> is better value for HDR. > I agree with you that UTF8SMTP is better and clearer. +1, as for BODY=8BITMIME, using the name of the extension. > This is somewhat off the topic, but, I am not UTF8 partisan. We could start a club of "legacy charset dinosaurs"... :-) But in practice UTF-8 will be the "new ASCII", with those partisans claiming that it already is for at least 7 years. > Some proprietary solutions may introduce HDR=KSC5601SMTP No, they won't, not on port 25, it's a horrible idea. I like pc-multilingual-850+euro, but not in a header. In you wrote: | Moreover, we can't assume there won't come any other ASCII | compatible encoding UTF?? (other than UTF8) of full Unicode | characters in the future. It's theoretically impossible to design an "ASCII compatible" UTF "better" than UTF-8 -- i.e. without giving up one or more essential features of UTF-8. Ignoring all draft-terrell-* :-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 13:52:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZW7k-0000Qs-Fv; Thu, 05 Apr 2007 13:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZW7j-0000PX-79 for ima@ietf.org; Thu, 05 Apr 2007 13:51:51 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZW7h-0001VQ-OI for ima@ietf.org; Thu, 05 Apr 2007 13:51:51 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZW7h-000MnR-6w; Thu, 05 Apr 2007 13:51:49 -0400 Date: Thu, 05 Apr 2007 13:51:48 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: <73A82DA479F0AAE42871CAD3@p3.JCK.COM> In-Reply-To: <46152FFB.698F@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (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: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 05 April, 2007 19:20 +0200 Frank Ellermann wrote: > Soobok Lee wrote: > >>> HDR=UTF8SMTP >>> is better value for HDR. > >> I agree with you that UTF8SMTP is better and clearer. > > +1, as for BODY=8BITMIME, using the name of the extension. > >> This is somewhat off the topic, but, I am not UTF8 partisan. > > We could start a club of "legacy charset dinosaurs"... :-) > > But in practice UTF-8 will be the "new ASCII", with those > partisans claiming that it already is for at least 7 years. I have to agree with this. And anyone who considers me a UTF-8 partisan, or Unicode partisan more generally, should consult the UTC. But, for international use, the choices are between Unicode (in some coding), local character sets with universal labeling and great potential for an N**2 problem, or going off and inventing a new UCS. Fortunately or unfortunately, there is absolutely no evidence of energy for the third and little evidence that, faced with similar constraints, a new effort would produce a significantly better overall result than Unicode. So it behooves us to accept Unicode (and, for many purposes, UTF-8), mostly stop complaining about it, and try to make it work. >... > In you wrote: > | Moreover, we can't assume there won't come any other ASCII > | compatible encoding UTF?? (other than UTF8) of full Unicode > | characters in the future. > > It's theoretically impossible to design an "ASCII compatible" > UTF "better" than UTF-8 -- i.e. without giving up one or more > essential features of UTF-8. Ignoring all draft-terrell-* :-) Well, I think that depends on one's objectives. Put differently, some of the "essential features" of UTF-8 are pathological in some contexts. Punycode points to a family of block encodings that are better for some purposes: ignoring the specifics of the IDNA application, they use an offset into Unicode followed by coding that is dependent on the block/region starting with that offset. It has much better properties than UTF-8 if one is concerned about characters that are "high" in the BMP or even higher. Similarly, an essential property of UTF-8 is that ASCII characters are coded as themselves. Even taking that as a given, it then marches up the Unicode spec, with the next blocks of codes being encoded into two octets and the strings getting longer as one goes up. In principle, one could design a code that would preserve this ASCII property but subtract the value of every character above U+007F from 0xFFFF, yielding a signed integer that was negative in the rest of the BMP and positive otherwise. If one then applied a UTF-8-like coding to that integer, one would end up with a code that maintained the essential ASCII-as-ASCII property, but was much more friendly to non-European scripts than to European ones. All of that said, I don't see any strong movement away from UTF-8 and, even if there were, would see immense interoperability advantages to converting to UTF-8 before putting something onto or pulling it off of, the proverbial wire. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 14:29:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWiP-0005ub-7M; Thu, 05 Apr 2007 14:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWiO-0005uW-5x for ima@ietf.org; Thu, 05 Apr 2007 14:29:44 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWiM-0007j7-Ow for ima@ietf.org; Thu, 05 Apr 2007 14:29:44 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZWiK-000N5C-04; Thu, 05 Apr 2007 14:29:40 -0400 Date: Thu, 05 Apr 2007 14:29:39 -0400 From: John C Klensin To: Soobok Lee , Kari Hurtta Subject: Re: [EAI] Re: POLL: HDR= extension on MAIL FROM Message-ID: <0C684BFFEC78917519C7D76A@p3.JCK.COM> In-Reply-To: <20070405063602.GD17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (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: c0bedb65cce30976f0bf60a0a39edea4 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 05 April, 2007 15:36 +0900 Soobok Lee wrote: > On Thu, Apr 05, 2007 at 08:16:15AM +0300, Kari Hurtta wrote: >> >> A - I support HDR=UTF8 >> >> (however not very strongly) >> >> Paramater value should NOT look like charset name, >> therefore >> >> HDR=UTF8SMTP >> >> is better value for HDR. >> > > I agree with you that UTF8SMTP is better and clearer. > > This is somewhat off the topic, but, I am not UTF8 partisan. > > Some proprietary solutions may introduce HDR=KSC5601SMTP > for internal or regional use for their own *risk*/benefit. > many email portals are using local charset encoding for > both header and *body* in 8-bit clean format of single message > file for storage/transfer efficiency. > > We don't need to try to standardize such non-standard > way of SMTP here. Defining some "HDR=" parameter values is > enough. Let them extend parameter values for their own risk > /benefits in interoperable ways. Hmm. A few observations, partially as free advice for those contemplating doing this... First, one thing we keep learning, over and over again, is that things leak. There is almost no such thing as "internal or regional use" that doesn't end up showing up somewhere else and causing greater or lesser problems when it does. This is a strong argument for localizing all one wants to but, when something is actually transmitted, using the global/standardized forms and then, if necessary, re-localizing at the far end. Second, if one is going to invent locally-coded header forms and put them on the wire, contrary to the advice above, there are many reasons why it is probably better to do that with a switch --e.g., advertising a EHLO option of X-Korean-special-Mail and using MAIL FROM: X-Korean-special-Mail-- that to fuss around with fine-tuning the argument values to standard parameters and hoping that the right thing will happen. Experience indicates that, if the only valid arguments to HDR= are "UTF8" or "ASCII" (or some alternate spelling of those), then an implementation that treats everything as UTF-8 may simply ignore the parameter, getting into trouble if KSC5601 is specified instead. In any event, this is not an argument for a HDR= parameter. If anything, it is an argument against such a parameter because, if one wants to make a local extension that violates the standard, interoperability considerations suggest that it be as clear and distinctive as possible. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 16:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYb3-0007wu-Ew; Thu, 05 Apr 2007 16:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYb2-0007wp-KC for ima@ietf.org; Thu, 05 Apr 2007 16:30:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZYb0-0004HI-BB for ima@ietf.org; Thu, 05 Apr 2007 16:30:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZYas-0001lE-FA for ima@ietf.org; Thu, 05 Apr 2007 22:30:06 +0200 Received: from d255087.dialin.hansenet.de ([80.171.255.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 22:30:06 +0200 Received: from nobody by d255087.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 22:30:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 05 Apr 2007 22:24:29 +0200 Organization: Lines: 62 Message-ID: <46155AFD.3870@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> 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: d255087.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.4 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [EAI] OT: HDR=KSC5601SMTP X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> It's theoretically impossible to design an "ASCII compatible" >> UTF "better" than UTF-8 -- i.e. without giving up one or more >> essential features of UTF-8. Ignoring all draft-terrell-* :-) > Well, I think that depends on one's objectives. Put > differently, some of the "essential features" of UTF-8 are > pathological in some contexts. The essential features I've in mind are: 1: anywhere in a stream of octets it's always clear where you are, at an ASCII character, at the begin of a multi-octet UTF-8, or in the tail of a multi-octet UTF-8 encoding. 2: each Unicode point has only one corresponding "canonical" UTF-8 encoding. 3: flipping a single bit destroys precisely one character. 4: the lead octet determines the length of the encoding. 5: if an octet appears to be ASCII it really is ASCII. Encoding is (almost) straight forward modulo 64. STD 63 decoding is minimally harder, but still trivial. > Punycode points to a family of block encodings that are better > for some purposes: ignoring the specifics of the IDNA application, > they use an offset into Unicode followed by coding that is > dependent on the block/region starting with that offset. Yes, but AFAIK it can't encode Unicode strings of arbitrary length, please correct me if that's wrong, the one thing I know for sure about punycode is that it's *not* trivial... :-) BOCU-1 could be an alternative, but it doesn't have property (3), flipping a bit could destroy a complete line. > In principle, one could design a code that would preserve this > ASCII property but subtract the value of every character above > U+007F from 0xFFFF, yielding a signed integer that was negative > in the rest of the BMP and positive otherwise. If one then > applied a UTF-8-like coding to that integer, one would end up > with a code that maintained the essential ASCII-as-ASCII > property, but was much more friendly to non-European scripts > than to European ones. FRom u+0080 up to u+7FFF you'd still have to encode 16 bits, an "UTF-8 like coding" would then need three 10xx xxxx tail octets, and one 1110 0001 lead byte. It starts to get friendlier with u+8000 ff., but the upper part of the BMP contains lots of code points never used in ordinary texts (like surrogates and 34 non- characters). I don't think that that's really "better", it's a kind of permutation. I'm not sure what your algorithm does with code points in planes 1 to 15, maybe just use the original UTF-8. > I don't see any strong movement away from UTF-8 I don't see any movement away from UTF-8 at all. BOCU-1 didn't make it so far, and SCSU isn't MIME compatible. And "UTF-4" is only a theoretical construct imitating all features of UTF-8, replacing "ASCII" by "ASCII or u+00A0 up to u+00FF" (Latin-1). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 17:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZSM-0003qb-2H; Thu, 05 Apr 2007 17:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZSL-0003qW-4K for ima@ietf.org; Thu, 05 Apr 2007 17:25:21 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZZSJ-00053C-Rj for ima@ietf.org; Thu, 05 Apr 2007 17:25:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZZSI-0001nS-MF for ima@ietf.org; Thu, 05 Apr 2007 23:25:18 +0200 Received: from d255087.dialin.hansenet.de ([80.171.255.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 23:25:18 +0200 Received: from nobody by d255087.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2007 23:25:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 05 Apr 2007 23:24:28 +0200 Organization: Lines: 13 Message-ID: <4615690C.75B0@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@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: d255087.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.0 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] OT: HDR=KSC5601SMTP X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann confused five and six bits: > FRom u+0080 up to u+7FFF you'd still have to encode 16 bits, an > "UTF-8 like coding" would then need three 10xx xxxx tail octets, Correction: It would use 1110 xxxx 10xx xxxx 10xx xxxx (3 octets) And with 110x xxxx 10xx xxxx it can encode 11 bits in 2 octets, for John's algorithm that boundary is at u+F800. For most code points in the BMP it would need three octets just like UTF-8. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 21:14:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZd1O-0007Ny-2v; Thu, 05 Apr 2007 21:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZd1M-0007JM-93 for ima@ietf.org; Thu, 05 Apr 2007 21:13:44 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZd1J-00006N-LN for ima@ietf.org; Thu, 05 Apr 2007 21:13:44 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l361DXJ5014748; Fri, 6 Apr 2007 10:13:33 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l361DWYN014747; Fri, 6 Apr 2007 10:13:32 +0900 Date: Fri, 6 Apr 2007 10:13:32 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: <20070406011332.GF17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73A82DA479F0AAE42871CAD3@p3.JCK.COM> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Apr 05, 2007 at 01:51:48PM -0400, John C Klensin wrote: > > It's theoretically impossible to design an "ASCII compatible" > > UTF "better" than UTF-8 -- i.e. without giving up one or more > > essential features of UTF-8. Ignoring all draft-terrell-* :-) > > Similarly, an essential property of UTF-8 is that ASCII > characters are coded as themselves. Even taking that as a > given, it then marches up the Unicode spec, with the next blocks > of codes being encoded into two octets and the strings getting > longer as one goes up. In principle, one could design a code > that would preserve this ASCII property but subtract the value > of every character above U+007F from 0xFFFF, yielding a signed > integer that was negative in the rest of the BMP and positive > otherwise. If one then applied a UTF-8-like coding to that > integer, one would end up with a code that maintained the > essential ASCII-as-ASCII property, but was much more friendly to > non-European scripts than to European ones. Thanks for your interesting comment. Yes. There is much room for improvement or adjustment in future UTF8-variant encodings for non-western-european characters. UTF8 multiplies length of strings by 50%~200%, compared with local charset encodings. Cyrillic/Greek/Hebrew/Arabic strings : 200 % ( 1->3 octets) Chinese/Japanese/Korean strings (DBCS): 50 % ( 2->3 octets) UTF8 is still not in overwhelming use in email messages worldwide, even though it was born 7~8 years ago. Main use of utf8 encoding in email is a fallback encoding to encode non-local-charset characters in headers or body. If you consult gmail/yahoo/hotmail personels, they will reply to you that they welcome local charset encodings as currently most favored encodings over utf8 for email messages. My position is this : Let's go with UTF8 now, but let's leave rooms for other encodings for future needs. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 21:29:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdH0-0008IT-KU; Thu, 05 Apr 2007 21:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdGy-0008IO-QO for ima@ietf.org; Thu, 05 Apr 2007 21:29:52 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdGx-0003v3-5d for ima@ietf.org; Thu, 05 Apr 2007 21:29:52 -0400 Received: (snipe 16102 invoked by uid 0); 6 Apr 2007 10:30:08 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 1.304347 secs); Received: from unknown (HELO ?210.107.139.204?) (Z???own@210.107.139.204) by unknown with SMTP; 6 Apr 2007 10:30:07 +0900 X-SNIPER-SENDERIP: 210.107.139.204 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: lsb@lsb.org, klensin@jck.com, nobody@xyzzy.claranet.de, ima@ietf.org, yangwooko@gmail.com Message-ID: <4615A27A.3040508@icu.ac.kr> Date: Fri, 06 Apr 2007 10:29:30 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] OT: HDR=KSC5601SMTP References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> In-Reply-To: <20070406011332.GF17458@ns5.lsb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > On Thu, Apr 05, 2007 at 01:51:48PM -0400, John C Klensin wrote: >>> It's theoretically impossible to design an "ASCII compatible" >>> UTF "better" than UTF-8 -- i.e. without giving up one or more >>> essential features of UTF-8. Ignoring all draft-terrell-* :-) >> Similarly, an essential property of UTF-8 is that ASCII >> characters are coded as themselves. Even taking that as a >> given, it then marches up the Unicode spec, with the next blocks >> of codes being encoded into two octets and the strings getting >> longer as one goes up. In principle, one could design a code >> that would preserve this ASCII property but subtract the value >> of every character above U+007F from 0xFFFF, yielding a signed >> integer that was negative in the rest of the BMP and positive >> otherwise. If one then applied a UTF-8-like coding to that >> integer, one would end up with a code that maintained the >> essential ASCII-as-ASCII property, but was much more friendly to >> non-European scripts than to European ones. > > > Thanks for your interesting comment. Yes. There is much room > for improvement or adjustment in future UTF8-variant encodings > for non-western-european characters. > > UTF8 multiplies length of strings by 50%~200%, compared with local charset > encodings. > > Cyrillic/Greek/Hebrew/Arabic strings : 200 % ( 1->3 octets) > Chinese/Japanese/Korean strings (DBCS): 50 % ( 2->3 octets) > > UTF8 is still not in overwhelming use in email messages worldwide, > even though it was born 7~8 years ago. > Main use of utf8 encoding in email is a fallback encoding to encode > non-local-charset characters in headers or body. > > If you consult gmail/yahoo/hotmail personels, they will reply to you that > they welcome local charset encodings as currently most favored encodings > over utf8 for email messages. > > > > My position is this : Let's go with UTF8 now, but let's leave rooms for > other encodings for future needs. Significant increase of network throughput and even faster drop of storage prices make me little impressed by the fact that UTF-8 is not the best solution for some languages (including ours :-) ). In addition to this, as far as my mail experiences are concerned, majority of bits transmitted over email messages are from big attachments such as PDFs, PPTs, and ZIPs, which are not that relevant to character encoding issues. > > > Soobok > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 21:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdOJ-0003Dm-0a; Thu, 05 Apr 2007 21:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdOI-0003Df-5n for ima@ietf.org; Thu, 05 Apr 2007 21:37:26 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdOG-0005al-H8 for ima@ietf.org; Thu, 05 Apr 2007 21:37:26 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l361bLJ5018667; Fri, 6 Apr 2007 10:37:21 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l361bLpV018665; Fri, 6 Apr 2007 10:37:21 +0900 Date: Fri, 6 Apr 2007 10:37:21 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] Re: POLL: HDR= extension on MAIL FROM Message-ID: <20070406013721.GG17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <0C684BFFEC78917519C7D76A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C684BFFEC78917519C7D76A@p3.JCK.COM> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Apr 05, 2007 at 02:29:39PM -0400, John C Klensin wrote: > > First, one thing we keep learning, over and over again, is that > things leak. There is almost no such thing as "internal or > regional use" that doesn't end up showing up somewhere else and > causing greater or lesser problems when it does. This is a > strong argument for localizing all one wants to but, when > something is actually transmitted, using the global/standardized > forms and then, if necessary, re-localizing at the far end. > > Second, if one is going to invent locally-coded header forms > and put them on the wire, contrary to the advice above, there > are many reasons why it is probably better to do that with a > switch --e.g., advertising a EHLO option of > X-Korean-special-Mail and using MAIL FROM: > X-Korean-special-Mail-- that to fuss around with fine-tuning the > argument values to standard parameters and hoping that the right > thing will happen. Yes. For this case, HDR= alone is not enough, and local EHLO option like above is needed, as you point out. > Experience indicates that, if the only > valid arguments to HDR= are "UTF8" or "ASCII" (or some alternate > spelling of those), then an implementation that treats > everything as UTF-8 may simply ignore the parameter, getting > into trouble if KSC5601 is specified instead. > > In any event, this is not an argument for a HDR= parameter. If > anything, it is an argument against such a parameter because, if > one wants to make a local extension that violates the standard, > interoperability considerations suggest that it be as clear and > distinctive as possible. Thank you for your advice. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 21:53:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdeG-0005bv-17; Thu, 05 Apr 2007 21:53:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdeE-0005bq-Gh for ima@ietf.org; Thu, 05 Apr 2007 21:53:54 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZdeC-0001LS-Mw for ima@ietf.org; Thu, 05 Apr 2007 21:53:54 -0400 Received: (eyou send program); Fri, 06 Apr 2007 09:53:21 +0800 Message-ID: <375824401.29203@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Fri, 06 Apr 2007 09:53:21 +0800 Message-ID: <0a3901c777ee$595430c0$096ff1da@cnnicyao> From: "YAO Jiankang" To: "Soobok Lee" , "John C Klensin" References: <4613B26D.20609@alvestrand.no><5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi><20070405063602.GD17458@ns5.lsb.org><46152FFB.698F@xyzzy.claranet.de><73A82DA479F0AAE42871CAD3@p3.JCK.COM> <375822126.30518@cnnic.cn> Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Date: Fri, 6 Apr 2007 09:52:53 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1009624655==" Errors-To: ima-bounces@ietf.org --===============1009624655== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNvb2JvayBMZWUiIDxsc2JA bHNiLm9yZz4NClRvOiAiSm9obiBDIEtsZW5zaW4iIDxrbGVuc2luQGpjay5jb20+DQpDYzogIkZy YW5rIEVsbGVybWFubiIgPG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT47IDxpbWFAaWV0Zi5vcmc+ DQpTZW50OiBGcmlkYXksIEFwcmlsIDA2LCAyMDA3IDk6MTMgQU0NClN1YmplY3Q6IFJlOiBbRUFJ XSBPVDogSERSPUtTQzU2MDFTTVRQICh3YXM6IFBPTEw6IEhEUj0gZXh0ZW5zaW9uIG9uIE1BSUwg RlJPTSkNCg0KDQo+IE9uIFRodSwgQXByIDA1LCAyMDA3IGF0IDAxOjUxOjQ4UE0gLTA0MDAsIEpv aG4gQyBLbGVuc2luIHdyb3RlOg0KPj4gPiBJdCdzIHRoZW9yZXRpY2FsbHkgaW1wb3NzaWJsZSB0 byBkZXNpZ24gYW4gIkFTQ0lJIGNvbXBhdGlibGUiDQo+PiA+IFVURiAiYmV0dGVyIiB0aGFuIFVU Ri04IC0tIGkuZS4gd2l0aG91dCBnaXZpbmcgdXAgb25lIG9yIG1vcmUNCj4+ID4gZXNzZW50aWFs IGZlYXR1cmVzIG9mIFVURi04LiAgSWdub3JpbmcgYWxsIGRyYWZ0LXRlcnJlbGwtKiA6LSkNCj4+ IA0KPj4gU2ltaWxhcmx5LCBhbiBlc3NlbnRpYWwgcHJvcGVydHkgb2YgVVRGLTggaXMgdGhhdCBB U0NJSQ0KPj4gY2hhcmFjdGVycyBhcmUgY29kZWQgYXMgdGhlbXNlbHZlcy4gIEV2ZW4gdGFraW5n IHRoYXQgYXMgYQ0KPj4gZ2l2ZW4sIGl0IHRoZW4gbWFyY2hlcyB1cCB0aGUgVW5pY29kZSBzcGVj LCB3aXRoIHRoZSBuZXh0IGJsb2Nrcw0KPj4gb2YgY29kZXMgYmVpbmcgZW5jb2RlZCBpbnRvIHR3 byBvY3RldHMgYW5kIHRoZSBzdHJpbmdzIGdldHRpbmcNCj4+IGxvbmdlciBhcyBvbmUgZ29lcyB1 cC4gIEluIHByaW5jaXBsZSwgb25lIGNvdWxkIGRlc2lnbiBhIGNvZGUNCj4+IHRoYXQgd291bGQg cHJlc2VydmUgdGhpcyBBU0NJSSBwcm9wZXJ0eSBidXQgc3VidHJhY3QgdGhlIHZhbHVlDQo+PiBv ZiBldmVyeSBjaGFyYWN0ZXIgYWJvdmUgVSswMDdGIGZyb20gMHhGRkZGLCB5aWVsZGluZyBhIHNp Z25lZA0KPj4gaW50ZWdlciB0aGF0IHdhcyBuZWdhdGl2ZSBpbiB0aGUgcmVzdCBvZiB0aGUgQk1Q IGFuZCBwb3NpdGl2ZQ0KPj4gb3RoZXJ3aXNlLiAgSWYgb25lIHRoZW4gYXBwbGllZCBhIFVURi04 LWxpa2UgY29kaW5nIHRvIHRoYXQNCj4+IGludGVnZXIsIG9uZSB3b3VsZCBlbmQgdXAgd2l0aCBh IGNvZGUgdGhhdCBtYWludGFpbmVkIHRoZQ0KPj4gZXNzZW50aWFsIEFTQ0lJLWFzLUFTQ0lJIHBy b3BlcnR5LCBidXQgd2FzIG11Y2ggbW9yZSBmcmllbmRseSB0bw0KPj4gbm9uLUV1cm9wZWFuIHNj cmlwdHMgdGhhbiB0byBFdXJvcGVhbiBvbmVzLg0KPiANCj4gPE9UPg0KPiBUaGFua3MgZm9yIHlv dXIgaW50ZXJlc3RpbmcgY29tbWVudC4gWWVzLiBUaGVyZSBpcyBtdWNoIHJvb20NCj4gZm9yIGlt cHJvdmVtZW50IG9yIGFkanVzdG1lbnQgaW4gZnV0dXJlIFVURjgtdmFyaWFudCAgZW5jb2Rpbmdz IA0KPiBmb3Igbm9uLXdlc3Rlcm4tZXVyb3BlYW4gY2hhcmFjdGVycy4gDQo+IA0KPiBVVEY4IG11 bHRpcGxpZXMgbGVuZ3RoIG9mIHN0cmluZ3MgYnkgNTAlfjIwMCUsIGNvbXBhcmVkIHdpdGggbG9j YWwgY2hhcnNldA0KPiBlbmNvZGluZ3MuDQo+IA0KPiBDeXJpbGxpYy9HcmVlay9IZWJyZXcvQXJh YmljIHN0cmluZ3MgOiAyMDAgJSAoIDEtPjMgb2N0ZXRzKQ0KPiBDaGluZXNlL0phcGFuZXNlL0tv cmVhbiBzdHJpbmdzIChEQkNTKTogNTAgJSAoIDItPjMgb2N0ZXRzKQ0KPiANCj4gVVRGOCBpcyBz dGlsbCBub3QgaW4gb3ZlcndoZWxtaW5nIHVzZSBpbiBlbWFpbCBtZXNzYWdlcyB3b3JsZHdpZGUs IA0KPiBldmVuIHRob3VnaCBpdCB3YXMgYm9ybiA3fjggeWVhcnMgYWdvLg0KPiBNYWluIHVzZSBv ZiB1dGY4IGVuY29kaW5nIGluIGVtYWlsIGlzIGEgZmFsbGJhY2sgZW5jb2RpbmcgdG8gZW5jb2Rl IA0KPiBub24tbG9jYWwtY2hhcnNldCBjaGFyYWN0ZXJzIGluIGhlYWRlcnMgb3IgYm9keS4NCj4g DQo+IElmIHlvdSBjb25zdWx0IGdtYWlsL3lhaG9vL2hvdG1haWwgcGVyc29uZWxzLCB0aGV5IHdp bGwgcmVwbHkgdG8geW91ICB0aGF0DQo+IHRoZXkgd2VsY29tZSBsb2NhbCBjaGFyc2V0IGVuY29k aW5ncyBhcyBjdXJyZW50bHkgbW9zdCBmYXZvcmVkIGVuY29kaW5ncw0KPiBvdmVyIHV0ZjggZm9y IGVtYWlsIG1lc3NhZ2VzLg0KPiANCj4gPC9PVD4NCj4gDQo+IE15IHBvc2l0aW9uIGlzIHRoaXMg OiBMZXQncyBnbyB3aXRoIFVURjggbm93LCANCg0KeWVzLiB3ZSBzaG91bGQgZ28gd2l0aCBVVEY4 IG5vdy4NCg0KPmJ1dCBsZXQncyBsZWF2ZSByb29tcyBmb3INCj4gb3RoZXIgZW5jb2RpbmdzIGZv ciBmdXR1cmUgbmVlZHMuDQoNCmlmICB0b28gbWFueSBlbmNvZGluZyBhcmUgdXNlZCwgIGV2ZXJ5 IHN5c3RlbSBoYXZlIHRvIG5lZWQgYSBsb3Qgb2YgZW5jb2RpbmcgdG8gY29tbXVuaWNhdGUgd2l0 aCBvdGhlciBtYWNoaW5lcy4NCnRoYXQgaXMgYSBiYWQgdGhpbmdzLiB0aGlzIGlzIGEgb2JzdGFj bGUgdG8gY29tbXVuaWNhdGlvbi4gDQpzbyBJIGRvIG5vdCBsaWtlIEhEUj0gZXh0ZW5zaW9uLg0K DQppbiB5b3VyIGV4YW1wbGVzIGFib3V0IGdtYWlsL3lhaG9vL2hvdG1haWwgLCB0aGV5IHdlbGNv bWUgbG9jYWwgZW5jb2RpbmdzLg0KYWN0dWFsbHksIHRoZXkgd2VsY29tZSB0aGUgZGlzcGxheSBv ZiB0aGUgbWVzYWdlIHdpdGggdGhlIGxvY2FsIGNoYXJhY3RlcnMgaW4gc3BpdGUgb2Ygd2hpY2gg Y29kaW5nIGlzIHVzZWQsIHRoaXMgaXMgY29udmllbnQgdG8gbG9jYWwgdXNlcnMuIHRoaXMgZG9l cyBub3QgbWVhbiB0aGV5IHdlbGNvbWUgdGhlIGxvY2FsIGVuY29kaW5nLg0KDQpzbyBVVEYtOChV TklDT0RFKSBpcyB0aGUgYmVzdCB0b29sIHRvICBnbWFpbC95YWhvby9ob3RtYWlsICwgd2hpY2gg Y2FuIGNvbW11bmljYXRlIHdpdGggYW55IG1hY2hpbmUgaW4gdGhlIHdvcmxkLCBidXQgY2FuIGRp c3BsYXkgdGhlIG1lc3NhZ2Ugd2l0aCB0aGUgZnJpZW5kbHkgbG9jYWwgY2hhcmFjdGVycy4NCg0K WUFPIEppYW5rYW5nDQpDTk5JQw0KDQoNCg0KPiANCj4gDQo+IFNvb2Jvaw0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcg bGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaW1h --===============1009624655== 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 --===============1009624655==-- From ima-bounces@ietf.org Thu Apr 05 21:55:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdg5-0005wY-0f; Thu, 05 Apr 2007 21:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdg3-0005wL-Qo for ima@ietf.org; Thu, 05 Apr 2007 21:55:47 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdg2-0001pa-8N for ima@ietf.org; Thu, 05 Apr 2007 21:55:47 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l361thJ5022250; Fri, 6 Apr 2007 10:55:43 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l361thWj022249; Fri, 6 Apr 2007 10:55:43 +0900 Date: Fri, 6 Apr 2007 10:55:43 +0900 From: Soobok Lee To: John C Klensin Subject: (correction)Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: <20070406015543.GH17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406011332.GF17458@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 06, 2007 at 10:13:32AM +0900, Soobok Lee wrote: > > UTF8 multiplies length of strings by 50%~200%, compared with local charset > encodings. > > Cyrillic/Greek/Hebrew/Arabic strings : 200 % ( 1->3 octets) Correction: > Cyrillic/Greek/Hebrew/Arabic strings : 100 % ( 1->2 octets) ( < U+0800) Addition: Devanagari : 200 % ( 1->3 octets) ( >= U+0900) > Chinese/Japanese/Korean strings (DBCS): 50 % ( 2->3 octets) > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 22:08:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdsT-0004vv-G4; Thu, 05 Apr 2007 22:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdsR-0004vm-Hh for ima@ietf.org; Thu, 05 Apr 2007 22:08:35 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdsP-0004Yu-VQ for ima@ietf.org; Thu, 05 Apr 2007 22:08:35 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l3627pJ5024167; Fri, 6 Apr 2007 11:07:51 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l3627mco024137; Fri, 6 Apr 2007 11:07:48 +0900 Date: Fri, 6 Apr 2007 11:07:48 +0900 From: Soobok Lee To: YAO Jiankang Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: <20070406020748.GI17458@ns5.lsb.org> References: <375822126.30518@cnnic.cn> <0a3901c777ee$595430c0$096ff1da@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a3901c777ee$595430c0$096ff1da@cnnicyao> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 06, 2007 at 09:52:53AM +0800, YAO Jiankang wrote: > > >but let's leave rooms for > > other encodings for future needs. > > if too many encoding are used, every system I am talking about proprietary local/internal/regional *extensions* of UTF8SMTP. Such systems should be able to talk with UTF8SMTP-only system. So UTF8SMTP-only system have no problem with communicating such extended systems. Burdens of converting/back-converting from/to UTF8 message fall only onto the extended system side. Think about the smooth operation bewteen non-UTF8SMTP-aware and UTF8SMTP-aware systems mediated by UTF8SMTP EHLO option. It's similar in above extension. > have to need a lot of encoding to communicate with other machines. > that is a bad things. this is a obstacle to communication. > so I do not like HDR= extension. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 22:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZe5W-0005Hj-Mk; Thu, 05 Apr 2007 22:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZe5W-0005HJ-99 for ima@ietf.org; Thu, 05 Apr 2007 22:22:06 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZe5U-00078u-NA for ima@ietf.org; Thu, 05 Apr 2007 22:22:06 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l362LsJ5026470; Fri, 6 Apr 2007 11:21:55 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l362Ls3m026468; Fri, 6 Apr 2007 11:21:54 +0900 Date: Fri, 6 Apr 2007 11:21:54 +0900 From: Soobok Lee To: Yangwoo Ko Subject: Re: [EAI] OT: HDR=KSC5601SMTP Message-ID: <20070406022154.GJ17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> <4615A27A.3040508@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4615A27A.3040508@icu.ac.kr> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 06, 2007 at 10:29:30AM +0900, Yangwoo Ko wrote: > > Significant increase of network throughput and even faster drop of > storage prices make me little impressed by the fact that UTF-8 is not > the best solution for some languages (including ours :-) ). Email portals compete with one another and always under pressure for cost cut to make profits. If you can, try to ask portal personels about how much they pay for netowrk/storage in a month and about whether they welcome 50~200% increase of network/storage needs and about why they still stick to local charset encodings in message format even now after utf8 is born 7~8 years ago. They will make best answers than me. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 22:49:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVn-000613-D3; Thu, 05 Apr 2007 22:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVl-00060t-TH for ima@ietf.org; Thu, 05 Apr 2007 22:49:13 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZeVi-0003VP-Oq for ima@ietf.org; Thu, 05 Apr 2007 22:49:13 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l362n71k005787 for ; Fri, 6 Apr 2007 11:49:07 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2fca_6399529c_e3e9_11db_91b4_0014221f2a2d; Fri, 06 Apr 2007 11:49:06 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37945) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 6 Apr 2007 11:47:57 +0900 Message-Id: <6.0.0.20.2.20070406112124.0aa6c870@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 06 Apr 2007 11:34:01 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP In-Reply-To: <4615690C.75B0@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <4615690C.75B0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yes. I agree with John's feeling, but the 'negative instead of positive' doesn't really help much. First, between U+FFFF and U+F800, it's all compatibility dead bodies, and we definitely do NOT want to code them shorter. Similarly, the stuff outside the BMP is there for a very good reason: it's used extremely rarely, and therefore doesn't really need much compression. What could in theory be done, but would require more complex operations (or a redesign of the code table, and I guess we all agree we don't want to go there) is to move the various Latin blocks out of the area below U+0800, and move in some other frequently used scripts, starting with Devanagari. The reason for this is that once you have basic Latin (=ASCII) with one byte per character, paying three bytes per character for characters with diacritics isn't too bad; even in languages that use diacritics heavily (Vietnamese, Polish,...), you'd most probably still stay below 2 bytes per character on average. You could press along this route and move out non-basic Arabic and Syriac and open up space for a script or two more below the U+0800 boundary, and so on, but whatever you do, there will still be too little space to fit the currently used alphabetic scripts all into that space. Not that I'm proposing to do any of this, of course! Regards, Martin. At 06:24 07/04/06, Frank Ellermann wrote: >Frank Ellermann confused five and six bits: > >> FRom u+0080 up to u+7FFF you'd still have to encode 16 bits, an >> "UTF-8 like coding" would then need three 10xx xxxx tail octets, > >CorrectFrom ima-bounces@ietf.org Thu Apr 05 22:49:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVn-000613-D3; Thu, 05 Apr 2007 22:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVl-00060t-TH for ima@ietf.org; Thu, 05 Apr 2007 22:49:13 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZeVi-0003VP-Oq for ima@ietf.org; Thu, 05 Apr 2007 22:49:13 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l362n71k005787 for ; Fri, 6 Apr 2007 11:49:07 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2fca_6399529c_e3e9_11db_91b4_0014221f2a2d; Fri, 06 Apr 2007 11:49:06 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37945) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 6 Apr 2007 11:47:57 +0900 Message-Id: <6.0.0.20.2.20070406112124.0aa6c870@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 06 Apr 2007 11:34:01 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP In-Reply-To: <4615690C.75B0@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <4615690C.75B0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yes. I agree with John's feeling, but the 'negative instead of positive' doesn't really help much. First, between U+FFFF and U+F800, it's all compatibility dead bodies, and we definitely do NOT want to code them shorter. Similarly, the stuff outside the BMP is there for a very good reason: it's used extremely rarely, and therefore doesn't really need much compression. What could in theory be done, but would require more complex operations (or a redesign of the code table, and I guess we all agree we don't want to go there) is to move the various Latin blocks out of the area below U+0800, and move in some other frequently used scripts, starting with Devanagari. The reason for this is that once you have basic Latin (=ASCII) with one byte per character, paying three bytes per character for characters with diacritics isn't too bad; even in languages that use diacritics heavily (Vietnamese, Polish,...), you'd most probably still stay below 2 bytes per character on average. You could press along this route and move out non-basic Arabic and Syriac and open up space for a script or two more below the U+0800 boundary, and so on, but whatever you do, there will still be too little space to fit the currently used alphabetic scripts all into that space. Not that I'm proposing to do any of this, of course! Regards, Martin. At 06:24 07/04/06, Frank Ellermann wrote: >Frank Ellermann confused five and six bits: > >> FRom u+0080 up to u+7FFF you'd still have to encode 16 bits, an >> "UTF-8 like coding" would then need three 10xx xxxx tail octets, > >Correction: It would use 1110 xxxx 10xx xxxx 10xx xxxx (3 octets) > >And with 110x xxxx 10xx xxxx it can encode 11 bits in 2 octets, >for John's algorithm that boundary is at u+F800. For most code >points in the BMP it would need three octets just like UTF-8. > >Frank > > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 22:49:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVo-000619-Hl; Thu, 05 Apr 2007 22:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVm-00060y-RY for ima@ietf.org; Thu, 05 Apr 2007 22:49:14 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZeVi-0003VX-Or for ima@ietf.org; Thu, 05 Apr 2007 22:49:14 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l362n9eg005798 for ; Fri, 6 Apr 2007 11:49:09 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2fea_64ad91e8_e3e9_11db_8b0e_0014221f2a2d; Fri, 06 Apr 2007 11:49:08 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37945) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 6 Apr 2007 11:48:00 +0900 Message-Id: <6.0.0.20.2.20070406113617.0aa72a10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 06 Apr 2007 11:48:43 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP In-Reply-To: <46155AFD.3870@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 05:24 07/04/06, Frank Ellermann wrote: >John C Klensin wrote: >> Punycode... >Yes, but AFAIK it can't encode Unicode strings of arbitrary length, >please correct me if that's wrong, I haven't checked the actual spec, which may use some limitations, but in theory, there is no problem with encoding strings of arbitrary length. However, in practice, there are two big showstoppers: - Decompression requires actual string insertion, which is inefficient. - For most compression methods, the longer the string, the better the compression. Not so for punycode-type compressions; the compression ratio is bound to be about the same after a certain point, and much lower than the usual compression methods (LZ(W), block sorting) which are based on encoding symbol sequences rather than single symbols. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp ion: It would use 1110 xxxx 10xx xxxx 10xx xxxx (3 octets) > >And with 110x xxxx 10xx xxxx it can encode 11 bits in 2 octets, >for John's algorithm that boundary is at u+F800. For most code >points in the BMP it would need three octets just like UTF-8. > >Frank > > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 22:49:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVo-000619-Hl; Thu, 05 Apr 2007 22:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeVm-00060y-RY for ima@ietf.org; Thu, 05 Apr 2007 22:49:14 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZeVi-0003VX-Or for ima@ietf.org; Thu, 05 Apr 2007 22:49:14 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l362n9eg005798 for ; Fri, 6 Apr 2007 11:49:09 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2fea_64ad91e8_e3e9_11db_8b0e_0014221f2a2d; Fri, 06 Apr 2007 11:49:08 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37945) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 6 Apr 2007 11:48:00 +0900 Message-Id: <6.0.0.20.2.20070406113617.0aa72a10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 06 Apr 2007 11:48:43 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP In-Reply-To: <46155AFD.3870@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 05:24 07/04/06, Frank Ellermann wrote: >John C Klensin wrote: >> Punycode... >Yes, but AFAIK it can't encode Unicode strings of arbitrary length, >please correct me if that's wrong, I haven't checked the actual spec, which may use some limitations, but in theory, there is no problem with encoding strings of arbitrary length. However, in practice, there are two big showstoppers: - Decompression requires actual string insertion, which is inefficient. - For most compression methods, the longer the string, the better the compression. Not so for punycode-type compressions; the compression ratio is bound to be about the same after a certain point, and much lower than the usual compression methods (LZ(W), block sorting) which are based on encoding symbol sequences rather than single symbols. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 23:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZel4-0007GM-9a; Thu, 05 Apr 2007 23:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZel2-0007G2-Gf for ima@ietf.org; Thu, 05 Apr 2007 23:05:00 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZel0-0006o8-Jx for ima@ietf.org; Thu, 05 Apr 2007 23:05:00 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l3634v7P008902 for ; Fri, 6 Apr 2007 12:04:57 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2f65_99b0928a_e3eb_11db_9284_0014221f2a2d; Fri, 06 Apr 2007 12:04:57 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49219) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 6 Apr 2007 12:03:48 +0900 Message-Id: <6.0.0.20.2.20070406115322.0a7480d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 06 Apr 2007 11:55:46 +0900 To: Soobok Lee , John C Klensin From: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) In-Reply-To: <20070406011332.GF17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 10:13 07/04/06, Soobok Lee wrote: > >UTF8 multiplies length of strings by 50%~200%, compared with local charset >encodings. > > >My position is this : Let's go with UTF8 now, but let's leave rooms for >other encodings for future needs. As far as I understand, we are not at all requiring UTF-8 for the body of text messages. So we are talking about an overhead applied to just a relatively small part of the message. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 05 23:29:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZf8N-0004IV-BV; Thu, 05 Apr 2007 23:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZf8K-0004I0-K0 for ima@ietf.org; Thu, 05 Apr 2007 23:29:04 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZf8J-00023C-1C for ima@ietf.org; Thu, 05 Apr 2007 23:29:04 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l363T0J5004683; Fri, 6 Apr 2007 12:29:00 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l363SxOY004678; Fri, 6 Apr 2007 12:28:59 +0900 Date: Fri, 6 Apr 2007 12:28:59 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: <20070406032859.GK17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> <6.0.0.20.2.20070406115322.0a7480d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070406115322.0a7480d0@localhost> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 06, 2007 at 11:55:46AM +0900, Martin Duerst wrote: > At 10:13 07/04/06, Soobok Lee wrote: > > > > > >UTF8 multiplies length of strings by 50%~200%, compared with local charset > >encodings. > > > > > > >My position is this : Let's go with UTF8 now, but let's leave rooms for > >other encodings for future needs. > > As far as I understand, we are not at all requiring UTF-8 for > the body of text messages. > So we are talking about an overhead > applied to just a relatively small part of the message. Yes, only with header parts. The body part still may contain base64-encoded local-charset-encoded texts even with UTF8SMTP headers. But, conventionally many webmail portals have avoided base64(and QP) encoding of body parts to save storage/network bandwidth (i.e.: send/store in 8bit clean ). They store header and body part even in a single message file. Either adoptin of UTF8 or base64 encoding results in increase of network/storage need. Some portals may be okay with this overhead, and other may not. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 01:26:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZgy7-0008Lx-AL; Fri, 06 Apr 2007 01:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZgy5-0008Lo-QB for ima@ietf.org; Fri, 06 Apr 2007 01:26:37 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZgy4-0007pC-7c for ima@ietf.org; Fri, 06 Apr 2007 01:26:37 -0400 Received: from [10.201.0.14] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l365T24h015178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 22:29:07 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l365T24h015178 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1175837350; bh=WhNIQckVdYBkJBzeKLpAl17LXbY=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=to414g2p6j7BxuWk ks0zc6ZVAtf8SS3j/e0YxhbeNb2dYEHSQp1TJmHIV54FDnkCy2Sr9BpZCaxf+01elUd onn9UkjWe8RcM4bNftKLTFj0uS6KB4/qG6Buyiy7E3+Xi7X7FUwwUyb4LZ5AUaQ1eqZ xeLqwcnvhfkQv+PScwsZI= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l365T24h015178 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=Lg4XnWSTZtBpZHBCZX0qACQ6CdMqELihmbASpZfkPw2CyamCRkv9464MjJArPIaSi CDsN8U3N1wekiXWdiaSlJ0xe/HKHf2m2MhsBnD2zSVrX7MAC08WZN4155YMyccYlJRg QRQs6idWaQiBfxD+Fz8f5d3iNNxgqfPMZ/f1TP4= Date: Thu, 5 Apr 2007 23:26:13 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Soobok Lee Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) In-Reply-To: <20070406032859.GK17458@ns5.lsb.org> Message-ID: References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> <6.0.0.20.2.20070406115322.0a7480d0@localhost> <20070406032859.GK17458@ns5.lsb.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 6 Apr 2007, Soobok Lee wrote: > On Fri, Apr 06, 2007 at 11:55:46AM +0900, Martin Duerst wrote: ... >> As far as I understand, we are not at all requiring UTF-8 for >> the body of text messages. >> So we are talking about an overhead >> applied to just a relatively small part of the message. > > Yes, only with header parts. > The body part still may contain base64-encoded local-charset-encoded texts > even with UTF8SMTP headers. Why would they need to be base64-encoded? Isn't the point of the existing 8BITMIME extension to avoid that? Indeed you then say: > But, conventionally many webmail portals have avoided base64(and QP) > encoding of body parts to save storage/network bandwidth (i.e.: > send/store in 8bit clean ). Why would use of UTF8SMTP suddenly prevent those systems from treating the body as they currently do? UTF8SMTP doesn't ban the use of other charsets in the body part(s). > They store header and body part even in a single message file. Either > adoptin of UTF8 or base64 encoding results in increase of > network/storage need. So don't do that. I don't recall any suggestions of banning the use charsets other than UTF-8 in the body of messages with headers of envelope addresses in the non-ASCII part of UTF-8. Using different charsets in the different parts of a message is an already deployed feature of base MIME and is not going away with UTF8SMTP, so I don't understand why you're implying that use of UTF-8 in headers implies use of UTF-8 in bodies. Philip Guenther guenther@sendmail.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 01:48:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhJU-0004xk-Cd; Fri, 06 Apr 2007 01:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhJS-0004xf-Ub for ima@ietf.org; Fri, 06 Apr 2007 01:48:42 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZhJR-0007bo-AL for ima@ietf.org; Fri, 06 Apr 2007 01:48:42 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZhJQ-0001tC-G0; Fri, 06 Apr 2007 01:48:40 -0400 Date: Fri, 06 Apr 2007 01:48:39 -0400 From: John C Klensin To: Soobok Lee Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: In-Reply-To: <20070406011332.GF17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 06 April, 2007 10:13 +0900 Soobok Lee wrote: > On Thu, Apr 05, 2007 at 01:51:48PM -0400, John C Klensin wrote: >> > It's theoretically impossible to design an "ASCII >> > compatible" UTF "better" than UTF-8 -- i.e. without giving >> > up one or more essential features of UTF-8. Ignoring all >> > draft-terrell-* :-) >> >> Similarly, an essential property of UTF-8 is that ASCII >> characters are coded as themselves. Even taking that as a >> given, it then marches up the Unicode spec, with the next >> blocks of codes being encoded into two octets and the strings >> getting longer as one goes up. In principle, one could >> design a code that would preserve this ASCII property but >> subtract the value of every character above U+007F from >> 0xFFFF, yielding a signed integer that was negative in the >> rest of the BMP and positive otherwise. If one then applied >> a UTF-8-like coding to that integer, one would end up with a >> code that maintained the essential ASCII-as-ASCII property, >> but was much more friendly to non-European scripts than to >> European ones. > > > Thanks for your interesting comment. Yes. There is much room > for improvement or adjustment in future UTF8-variant > encodings for non-western-european characters. > > UTF8 multiplies length of strings by 50%~200%, compared with > local charset encodings. > > Cyrillic/Greek/Hebrew/Arabic strings : 200 % ( 1->3 octets) > Chinese/Japanese/Korean strings (DBCS): 50 % ( 2->3 octets) Well... (i) As long as those strings entirely use characters in the BMP. If, for example, one needs characters in the U+20000 - U+2FA1D range, UTF-8 takes us to four octets. Now, of course, some of those character don't appear in an DBCS character coding, so the comparison is odd. But it is important to remember that the result is not always three UTF-8 octets for CJK. (ii) While DBCS is one option, the other traditional option, especially in Japan, has been to use code table designators which result, as I understand it, in single byte characters plus switching overhead. If the latter occurs infrequently, there may be a significant advantage even over DBCS and an even more significant advantage over UTF-8. > UTF8 is still not in overwhelming use in email messages > worldwide, even though it was born 7~8 years ago. > Main use of utf8 encoding in email is a fallback encoding to > encode non-local-charset characters in headers or body. I think this is really not a comment about UTF-8, but about Unicode itself. For the record, while you believe that to be true, and I do too, several of the people in the Unicode Technical Committee firmly believe that the use of Unicode is nearly ubiquitous on the network. > If you consult gmail/yahoo/hotmail personels, they will reply > to you that they welcome local charset encodings as currently > most favored encodings over utf8 for email messages. I think there is a different conclusion to be drawn from this, with the understanding that it is just my opinion. With email and with the web, we really have two separate elements of the transmission to consider: the transport-related material needed to get the material to its destination and the payload --the material itself. For the first -- email addresses, URLs, and so on -- there is a rather strong case to be made that considerations of interoperability, and specifically, making sure that things can be delivered to or reached at the intended definition, should dominate all other decision criteria. That makes absolute standardization of what goes on the wire important, important enough that local variations become a significant threat to a globally-interoperable network. In the case of URLs, email addresses, and domain names, that principle has caused some people to argue that we should just stick with ASCII. I don't believe that we need to go that far (or restrict ourselves that much), but I do think we need to understand their point of view. In any event, for those strings, the disadvantages of UTF-8 relative to other possible codings seem to be far outweighed by the advantages of having _one_ agreed-upon coding rather than local choices. For the second element, the content, local character sets have been permitted, and methods for identifying them provided, since the dawn of MIME. It seems to me that is most of where the local variations are important: the body of the text may be large enough that octets-per-character issues make a difference, it may be important to transmit something closer to what is used locally, it may be possible to know (or assume) that the systems at both ends of a transmission are compatible (and, in general, only the ends are affected, not the transport path), and so on. So I just don't see the issue here. > > > My position is this : Let's go with UTF8 now, but let's leave > rooms for other encodings for future needs. For the envelopes, headers, and transmission negotiations, allowing for another coding form just creates more complexity without any significant payoff unless you expect Unicode itself to be replaced in the near future. For the content, body parts, and payload, provisions already exist for other encodings, so it is a non-issue. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 02:01:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhVN-0003Ss-I7; Fri, 06 Apr 2007 02:01:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZhVM-0003Sg-Gq for ima@ietf.org; Fri, 06 Apr 2007 02:01:00 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZhVL-0003vW-3d for ima@ietf.org; Fri, 06 Apr 2007 02:01:00 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZhVJ-00022S-P2; Fri, 06 Apr 2007 02:00:58 -0400 Date: Fri, 06 Apr 2007 02:00:57 -0400 From: John C Klensin To: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP Message-ID: In-Reply-To: <6.0.0.20.2.20070406113617.0aa72a10@localhost> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <6.0.0.20.2.20070406113617.0aa72a10@localhost> X-Mailer: Mulberry/4.0.7 (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: 0a7aa2e6e558383d84476dc338324fab Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 06 April, 2007 11:48 +0900 Martin Duerst wrote: > At 05:24 07/04/06, Frank Ellermann wrote: >> John C Klensin wrote: > >>> Punycode... > >> Yes, but AFAIK it can't encode Unicode strings of arbitrary >> length, please correct me if that's wrong, > > I haven't checked the actual spec, which may use some > limitations, but in theory, there is no problem with encoding > strings of arbitrary length. The reason I tried to talk about the punycode family of methods (bootstring encodings, I think Adam called them), was precisely to dodge that issue. Whether punycode is overoptimized to a particular application or not is irrelevant. > However, in practice, there are > two big showstoppers: - Decompression requires actual string > insertion, which is inefficient. - For most compression > methods, the longer the string, the better the compression. > Not so for punycode-type compressions; the compression ratio > is bound to be about the same after a certain point, and > much lower than the usual compression methods (LZ(W), block > sorting) which are based on encoding symbol sequences rather > than single symbols. I don't think one should really compare punycode to a compression metnod because it isn't. To a first order approximation, it is a character-by-character, variable length encoding, just like UTF-8. The differences are (i) that its output is an ACE (which need not be true for other members of the family and (ii) while UTF-8 bases the encoding of every character on the distance from 0x0000, the bootstring family base the encoding of characters on an offset to the beginning of a range. For fairly large blocks of text (much larger than a domain name or email address), I'd expect that starting with UTF-32 (UCS-4) and applying a standard compression method would typically produce output of shorter length and less sensitivity to placement in the tables than any of the variable length, discrete character encoding methods. And, of course, what makes this discussion odd is that it would be perfectly rational to apply one of those compression methods to message content in either transmission or storage if the costs of compressing and decompressing where significantly lower than the costs of transmission or storage respectively. And nothing in the existing standards prohibits doing either. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 02:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZi5u-0003nG-1I; Fri, 06 Apr 2007 02:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZi5t-0003mU-2a for ima@ietf.org; Fri, 06 Apr 2007 02:38:45 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZi5q-0006uv-2Q for ima@ietf.org; Fri, 06 Apr 2007 02:38:45 -0400 Received: (eyou send program); Fri, 06 Apr 2007 14:37:56 +0800 Message-ID: <375841476.20437@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Fri, 06 Apr 2007 14:37:56 +0800 Message-ID: <101801c77816$1afd73e0$096ff1da@cnnicyao> From: "YAO Jiankang" To: , References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <374717169.17156@cnnic.cn> Subject: Re: [EAI] draft-ietf-eai-smtpext-04.txt: (#2): 2.1. Framework for theInternationalization Extension Date: Fri, 6 Apr 2007 14:37:38 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282360332==" Errors-To: ima-bounces@ietf.org --===============1282360332== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkthcmkgSHVydHRhIiA8aHVy dHRhK2dtYW5lQHNpaWxvLmZtaS5maT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogU2F0dXJk YXksIE1hcmNoIDI0LCAyMDA3IDI6MTcgUE0NClN1YmplY3Q6IFtFQUldIGRyYWZ0LWlldGYtZWFp LXNtdHBleHQtMDQudHh0OiAoIzIpOiAyLjEuIEZyYW1ld29yayBmb3IgdGhlSW50ZXJuYXRpb25h bGl6YXRpb24gRXh0ZW5zaW9uDQoNCg0KDQo+ICg3KSB0aGUgbWF4aW11bSBsZW5ndGggb2YgYSBN QUlMIEZST00gYW5kIFJDUFQgVE8gY29tbWFuZCBsaW5lIGlzIA0KPiAgICAgaW5jcmVhc2VkIGJ5 IDI2OCBjaGFyYWN0ZXJzIGJ5IHRoZSBwb3NzaWJsZSBhZGRpdGlvbiBvZiB0aGUgDQo+ICAgICBB TFQtQUREUkVTUyBrZXl3b3JkIGFuZCB2YWx1ZQ0KDQoNCmFjY29yZGluZyB0byBSRkMgMjgyMSwN Cg0KICBsb2NhbC1wYXJ0DQogICAgICBUaGUgbWF4aW11bSB0b3RhbCBsZW5ndGggb2YgYSB1c2Vy IG5hbWUgb3Igb3RoZXIgbG9jYWwtcGFydCBpcyA2NA0KICAgICAgY2hhcmFjdGVycy4NCg0KICAg ZG9tYWluDQogICAgICBUaGUgbWF4aW11bSB0b3RhbCBsZW5ndGggb2YgYSBkb21haW4gbmFtZSBv ciBudW1iZXIgaXMgMjU1DQogICAgICBjaGFyYWN0ZXJzLg0KDQogICBjb21tYW5kIGxpbmUNCiAg ICAgIFRoZSBtYXhpbXVtIHRvdGFsIGxlbmd0aCBvZiBhIGNvbW1hbmQgbGluZSBpbmNsdWRpbmcg dGhlIGNvbW1hbmQNCiAgICAgIHdvcmQgYW5kIHRoZSA8Q1JMRj4gaXMgNTEyIGNoYXJhY3RlcnMu ICBTTVRQIGV4dGVuc2lvbnMgbWF5IGJlDQogICAgICB1c2VkIHRvIGluY3JlYXNlIHRoaXMgbGlt aXQuDQoNCg0KZm9yIGV4YW1wbGUsICBtYWlsIGZyb20gOiA8dXRmOEB1dGY4PiBhbHQtYWRkcmVz cz14dGV4dChsb2NhbCBwYXJ0ICtAK2RvbWFpbiBwYXJ0KQ0KdGhlIHBvc3NpYmxlIGxlbmdodCBp bmNyZWFzZSBtYXkgYmUgDQogNjQqMisxKzI1Nj00ODUNCg0KaXMgaXQgb2s/DQoNCg0KDQpZQU8g SmlhbmthbmcNCkNOTklDDQogDQoNCiAgICANCg0KDQo= --===============1282360332== 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 --===============1282360332==-- From ima-bounces@ietf.org Fri Apr 06 02:50:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZiHV-0002Te-9s; Fri, 06 Apr 2007 02:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZiHU-0002TW-Gr for ima@ietf.org; Fri, 06 Apr 2007 02:50:44 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZiHP-0002Bv-EK for ima@ietf.org; Fri, 06 Apr 2007 02:50:44 -0400 Received: (eyou send program); Fri, 06 Apr 2007 14:50:31 +0800 Message-ID: <375842231.21788@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Fri, 06 Apr 2007 14:50:31 +0800 Message-ID: <105501c77817$dcbe7a00$096ff1da@cnnicyao> From: "YAO Jiankang" To: , References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com><374717169.17156@cnnic.cn> <375841670.22735@cnnic.cn> Subject: Correction Re: [EAI] draft-ietf-eai-smtpext-04.txt: (#2): 2.1. Framework fortheInternationalization Extension Date: Fri, 6 Apr 2007 14:50:13 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1823923745==" Errors-To: ima-bounces@ietf.org --===============1823923745== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIllBTyBKaWFua2FuZyIgPHlh b2prQGNubmljLmNuPg0KVG86IDxpbWFAaWV0Zi5vcmc+OyA8aHVydHRhQHNpaWxvLmZtaS5maT4N ClNlbnQ6IEZyaWRheSwgQXByaWwgMDYsIDIwMDcgMjozNyBQTQ0KU3ViamVjdDogUmU6IFtFQUld IGRyYWZ0LWlldGYtZWFpLXNtdHBleHQtMDQudHh0OiAoIzIpOiAyLjEuIEZyYW1ld29yayBmb3J0 aGVJbnRlcm5hdGlvbmFsaXphdGlvbiBFeHRlbnNpb24NCg0KDQo+IA0KPiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiS2FyaSBIdXJ0dGEiIDxodXJ0dGErZ21hbmVAc2lp bG8uZm1pLmZpPg0KPiBUbzogPGltYUBpZXRmLm9yZz4NCj4gU2VudDogU2F0dXJkYXksIE1hcmNo IDI0LCAyMDA3IDI6MTcgUE0NCj4gU3ViamVjdDogW0VBSV0gZHJhZnQtaWV0Zi1lYWktc210cGV4 dC0wNC50eHQ6ICgjMik6IDIuMS4gRnJhbWV3b3JrIGZvciB0aGVJbnRlcm5hdGlvbmFsaXphdGlv biBFeHRlbnNpb24NCj4gDQo+IA0KPiANCj4+ICg3KSB0aGUgbWF4aW11bSBsZW5ndGggb2YgYSBN QUlMIEZST00gYW5kIFJDUFQgVE8gY29tbWFuZCBsaW5lIGlzIA0KPj4gICAgIGluY3JlYXNlZCBi eSAyNjggY2hhcmFjdGVycyBieSB0aGUgcG9zc2libGUgYWRkaXRpb24gb2YgdGhlIA0KPj4gICAg IEFMVC1BRERSRVNTIGtleXdvcmQgYW5kIHZhbHVlDQo+IA0KPiANCj4gYWNjb3JkaW5nIHRvIFJG QyAyODIxLA0KPiANCj4gIGxvY2FsLXBhcnQNCj4gICAgICBUaGUgbWF4aW11bSB0b3RhbCBsZW5n dGggb2YgYSB1c2VyIG5hbWUgb3Igb3RoZXIgbG9jYWwtcGFydCBpcyA2NA0KPiAgICAgIGNoYXJh Y3RlcnMuDQo+IA0KPiAgIGRvbWFpbg0KPiAgICAgIFRoZSBtYXhpbXVtIHRvdGFsIGxlbmd0aCBv ZiBhIGRvbWFpbiBuYW1lIG9yIG51bWJlciBpcyAyNTUNCj4gICAgICBjaGFyYWN0ZXJzLg0KPiAN Cj4gICBjb21tYW5kIGxpbmUNCj4gICAgICBUaGUgbWF4aW11bSB0b3RhbCBsZW5ndGggb2YgYSBj b21tYW5kIGxpbmUgaW5jbHVkaW5nIHRoZSBjb21tYW5kDQo+ICAgICAgd29yZCBhbmQgdGhlIDxD UkxGPiBpcyA1MTIgY2hhcmFjdGVycy4gIFNNVFAgZXh0ZW5zaW9ucyBtYXkgYmUNCj4gICAgICB1 c2VkIHRvIGluY3JlYXNlIHRoaXMgbGltaXQuDQo+IA0KPiANCj4gZm9yIGV4YW1wbGUsICBtYWls IGZyb20gOiA8dXRmOEB1dGY4PiBhbHQtYWRkcmVzcz14dGV4dChsb2NhbCBwYXJ0ICtAK2RvbWFp biBwYXJ0KQ0KPiB0aGUgcG9zc2libGUgbGVuZ2h0IGluY3JlYXNlIG1heSBiZSANCj4gNjQqMisx KzI1Nj00ODUNCj4gDQo+IGlzIGl0IG9rPw0KY29ycmVjdGlvbiwgDQpzaG91bGQgYWRkIGFsdC1h ZGRyZXNzIGxlbmd0aCAxMg0KDQpzbyB0aGUgdG90YWwgaXMgICAgImxvY2FsUGFydCIqMisiQCIr ImRvbWFpblBhcnQrYWx0LWFkZHJlc3M9IiAgIGVxdWFsZSA2NCoyKzErMjU1KzEyPTM5Ng0KDQpZ QU8gSmlhbmthbmcNCiBDTk5JQw0KPiANCj4gDQo+ICAgIA0KPiANCj4gDQo+DQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPg== --===============1823923745== 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 --===============1823923745==-- From ima-bounces@ietf.org Fri Apr 06 03:42:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZj5N-00017r-Vg; Fri, 06 Apr 2007 03:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZj1Q-0007JX-Tf for ima@ietf.org; Fri, 06 Apr 2007 03:38:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZj1P-0003SE-OK for ima@ietf.org; Fri, 06 Apr 2007 03:38:12 -0400 Received: by wr-out-0506.google.com with SMTP id i20so998869wra for ; Fri, 06 Apr 2007 00:38:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cOwlkGbN106qHU7rUpSf66X6gc0GkSluTE+PPJYX/RCFjNL1xVJ1h9Fowk2uio5j9YCNotnPdEqlQp6FVOPNX4OYMn1hl9XZ4zrRYDcb+kvFYTaRKUKwLmcl5npoBNl19eUKKj8aRDIuSDVF47OKmyxJSOOi5RA+QZCZ68VGWLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q9ydBIPZ5FLYliA6PHih8ZxcKWlo8eWOdmcQ88RxeOkRzVZusV5YQDmTftonLTxW4WlEfuO69nicQNrZOsMQkjH9Kzs7UneBMQd7iBrckg5bLAFhXaEf8si3BQNj5T897QUVygpsCXU3RHNSP9FZD+eHz32auMMrjXC6WespVww= Received: by 10.114.111.1 with SMTP id j1mr1148341wac.1175845090981; Fri, 06 Apr 2007 00:38:10 -0700 (PDT) Received: by 10.114.14.17 with HTTP; Fri, 6 Apr 2007 00:38:10 -0700 (PDT) Message-ID: <75f4cc5a0704060038j15a7c8fbnaa0c22daeb33f784@mail.gmail.com> Date: Fri, 6 Apr 2007 15:38:10 +0800 From: "Jeff Yeh" To: "Harald Alvestrand" Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM In-Reply-To: <4613B26D.20609@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4613B26D.20609@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-Mailman-Approved-At: Fri, 06 Apr 2007 03:42:16 -0400 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > B - I support NOT adding HDR=UTF8 Jeff Yeh _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 06:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZlNK-0003pl-Kz; Fri, 06 Apr 2007 06:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZlNJ-0003pd-1y for ima@ietf.org; Fri, 06 Apr 2007 06:08:57 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZlNG-0000VJ-En for ima@ietf.org; Fri, 06 Apr 2007 06:08:57 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l36A8pJ5005389; Fri, 6 Apr 2007 19:08:51 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l36A8oFZ005388; Fri, 6 Apr 2007 19:08:50 +0900 Date: Fri, 6 Apr 2007 19:08:50 +0900 From: Soobok Lee To: Philip Guenther Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: <20070406100850.GL17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> <6.0.0.20.2.20070406115322.0a7480d0@localhost> <20070406032859.GK17458@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Apr 05, 2007 at 11:26:13PM -0600, Philip Guenther wrote: > > >They store header and body part even in a single message file. Either > >adoptin of UTF8 or base64 encoding results in increase of > >network/storage need. > > So don't do that. I don't recall any suggestions of banning the use > charsets other than UTF-8 in the body of messages with headers of envelope > addresses in the non-ASCII part of UTF-8. Using different charsets in the > different parts of a message is an already deployed feature of base MIME > and is not going away with UTF8SMTP, so I don't understand why you're > implying that use of UTF-8 in headers implies use of UTF-8 in bodies. Right. Body parts can contain even raw binary octets streams (of even pdf/word file). But, many webmail portals provide end users with "view-source" or "print source" feature (display the content of raw message file as it is) for verification purpose. If two different charset encodings are used in the single message, they will be shown as broken texts at some header or body parts. If message/rfc822 type file should be strictly regardded as a stream of binary octets, we can ignore this need as non-technical one( aestheticaly one), we have no issue about this problem. But, there is a tendency among users and developers (like me) that message/rfc822 type had better be in a human readable and verifiable form. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 06:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZlNO-0003qL-6l; Fri, 06 Apr 2007 06:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZlNM-0003pz-Lz for ima@ietf.org; Fri, 06 Apr 2007 06:09:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZlNL-0000Ur-2r for ima@ietf.org; Fri, 06 Apr 2007 06:09:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZlMw-00062q-UF for ima@ietf.org; Fri, 06 Apr 2007 12:08:34 +0200 Received: from 212.82.251.103 ([212.82.251.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Apr 2007 12:08:34 +0200 Received: from nobody by 212.82.251.103 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Apr 2007 12:08:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 06 Apr 2007 12:05:49 +0200 Organization: Lines: 35 Message-ID: <46161B7D.11E9@xyzzy.claranet.de> References: <375822126.30518@cnnic.cn> <0a3901c777ee$595430c0$096ff1da@cnnicyao> <20070406020748.GI17458@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.103 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 2.0 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [EAI] OT: HDR=KSC5601SMTP X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > I am talking about proprietary local/internal/regional *extensions* > of UTF8SMTP. Such systems should be able to talk with UTF8SMTP-only > system. In theory you could say that anything happening between MUA and MSA on the sending side, or final delivery MTA and MUA on the receiving side, is the local business of these sides. They could still use UTF8SMTP "over the wire" (for a short wire from MSA to final delivery MTA), and proprietary formats on their sides. But in practice users have more than one email service provider, and they'd try to use the format they got from ESP A with ESP B, where ESP B might be a provider not supporting proprietary format A. It would be a similar mess as with those misguided users sending or receiving a variant of the Internet Message format with a popular calendar software, using TNEF or other proprietary inventions. > Burdens of converting/back-converting from/to UTF8 message fall > only onto the extended system side. I doubt that. It's the unlucky end users who will pay the price in the form of expedited unsubscriptions or killfiling say "TNEF". Or needing hours to configure their software towards a format remotely related to what's generally accepted as Internet Message. Or bothering an admin because they want to install a decent mail program in addition to the builtin calendar software. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 08:13:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnJa-0000B7-4W; Fri, 06 Apr 2007 08:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnJY-0000Aq-GM for ima@ietf.org; Fri, 06 Apr 2007 08:13:12 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZnJW-0004VZ-Sq for ima@ietf.org; Fri, 06 Apr 2007 08:13:12 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l36CD7J5018475; Fri, 6 Apr 2007 21:13:07 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l36CD74u018474; Fri, 6 Apr 2007 21:13:07 +0900 Date: Fri, 6 Apr 2007 21:13:07 +0900 From: Soobok Lee To: Frank Ellermann Subject: Re: [EAI] OT: HDR=KSC5601SMTP Message-ID: <20070406121307.GM17458@ns5.lsb.org> References: <375822126.30518@cnnic.cn> <0a3901c777ee$595430c0$096ff1da@cnnicyao> <20070406020748.GI17458@ns5.lsb.org> <46161B7D.11E9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46161B7D.11E9@xyzzy.claranet.de> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 06, 2007 at 12:05:49PM +0200, Frank Ellermann wrote: > Soobok Lee wrote: > > > I am talking about proprietary local/internal/regional *extensions* > > of UTF8SMTP. Such systems should be able to talk with UTF8SMTP-only > > system. > > In theory you could say that anything happening between MUA and MSA > on the sending side, or final delivery MTA and MUA on the receiving > side, is the local business of these sides. > > They could still use UTF8SMTP "over the wire" (for a short wire from > MSA to final delivery MTA), and proprietary formats on their sides. > > But in practice users have more than one email service provider, and > they'd try to use the format they got from ESP A with ESP B, where > ESP B might be a provider not supporting proprietary format A. In this case, MUA should switch message format to UTF8SMTP one to talk with ESP B which doesn't EHLO KSC5601SMTP option. > > It would be a similar mess as with those misguided users sending or > receiving a variant of the Internet Message format with a popular > calendar software, using TNEF or other proprietary inventions. MUA should *export* the message in UTF8SMTP form for inputs to such non-KSC5601SMTP-aware external applications. > > > Burdens of converting/back-converting from/to UTF8 message fall > > only onto the extended system side. > > I doubt that. It's the unlucky end users who will pay the price > in the form of expedited unsubscriptions or killfiling say "TNEF". > > Or needing hours to configure their software towards a format > remotely related to what's generally accepted as Internet Message. > > Or bothering an admin because they want to install a decent mail > program in addition to the builtin calendar software. In some cases, KSC5601SMTP may be burdensome. But, not without benefits. For example, you can telnet to 25 port and send SMTP command from KSC5601-based x-terminal directly, no need for utf8 conversion which will be done by server side. Unix "mail" command or non-EAI-capable MUA or PERL SMTP library may be tuned to work with KSC5601SMTP with minimal cost, even without any utf8 related coding work in some cases. Server side will take all the hassles under local assumption of KSC5601 use. KSC5601SMTP concept may be a transitional/complementry solution for UTF8SMTP. Programmers in Korea seldom use UTF8 in his editing/coding work, rather,in most case, use KSC5601 (or CP949). In Server Administration environment as well. (This thread went too far off the topic). Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 08:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnNN-0003js-15; Fri, 06 Apr 2007 08:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnNL-0003jn-7g for ima@ietf.org; Fri, 06 Apr 2007 08:17:07 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZnNJ-00052A-PA for ima@ietf.org; Fri, 06 Apr 2007 08:17:07 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HZnNJ-0005J3-CQ; Fri, 06 Apr 2007 08:17:05 -0400 Date: Fri, 06 Apr 2007 08:17:04 -0400 From: John C Klensin To: Soobok Lee Subject: Re: [EAI] OT: HDR=KSC5601SMTP (was: POLL: HDR= extension on MAIL FROM) Message-ID: In-Reply-To: <20070406100850.GL17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> <6.0.0.20.2.20070406115322.0a7480d0@localhost> <20070406032859.GK17458@ns5.lsb.org> <20070406100850.GL17458@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 06 April, 2007 19:08 +0900 Soobok Lee wrote: > On Thu, Apr 05, 2007 at 11:26:13PM -0600, Philip Guenther > wrote: >> >> > They store header and body part even in a single message >> > file. Either adoptin of UTF8 or base64 encoding results in >> > increase of network/storage need. >> >> So don't do that. I don't recall any suggestions of banning >> the use charsets other than UTF-8 in the body of messages >> with headers of envelope addresses in the non-ASCII part of >> UTF-8. Using different charsets in the different parts of a >> message is an already deployed feature of base MIME and is >> not going away with UTF8SMTP, so I don't understand why >> you're implying that use of UTF-8 in headers implies use of >> UTF-8 in bodies. > > Right. Body parts can contain even raw binary octets streams > (of even pdf/word file). > > But, many webmail portals provide end users with "view-source" > or "print source" feature (display the content of raw message > file as it is) for verification purpose. If two different > charset encodings are used in the single message, they will be > shown as broken texts at some header or body parts. > > If message/rfc822 type file should be strictly regardded as a > stream of binary octets, we can ignore this need as > non-technical one( aestheticaly one), we have no issue about > this problem. But, there is a tendency among users and > developers (like me) that message/rfc822 type had better be in > a human readable and verifiable form. Then the relevant developers need to re-read and understand the MIME spec because there has never been any guarantee that either "human readable form" or "display all body parts using the same decoders (charset, codec, etc.). First, remember that MIME supports multimedia. Nothing is going to make a music or video file "human readable and verifiable" by visual inspection. Application/octet-stream can contain anything at all. And there has never been a requirement that, if a message contains multiple textual parts, the different body parts use the same character encoding. Indeed, while it has not often been used for what we originally assumed would be one of its more interesting applications, multipart/alternative was designed to permit several different ways to express the same content: different scripts, different languages, and, yes, different encodings. And message/rfc822 can encapsulate any of these. Under the principle that the EAI WG is not permitted to, and doesn't need to, reopen fundamental design principles of MIME and the SMTP Extension model unless they are directly and uniquely associated with internationalization, this has become seriously off-topic. I suggest you take it to the 822 list if you still believe that there is a protocol problem. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 13:08:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrvJ-0006px-JQ; Fri, 06 Apr 2007 13:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrvI-0006ps-MH for ima@ietf.org; Fri, 06 Apr 2007 13:08:28 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZrvD-0002cr-DB for ima@ietf.org; Fri, 06 Apr 2007 13:08:28 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1175878903!19431698!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16687 invoked from network); 6 Apr 2007 17:01:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 6 Apr 2007 17:01:43 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l36H1gWj029270 for ; Fri, 6 Apr 2007 13:01:42 -0400 (EDT) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l36H1a7M029230 for ; Fri, 6 Apr 2007 13:01:36 -0400 (EDT) Received: from [135.210.32.52] (unknown[135.210.32.52](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070406170131gw10010g4je> (Authid: tony); Fri, 6 Apr 2007 17:01:34 +0000 Message-ID: <461674C9.8080009@att.com> Date: Fri, 06 Apr 2007 12:26:49 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] OT: HDR=KSC5601SMTP References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > --On Friday, 06 April, 2007 10:13 +0900 Soobok Lee > wrote: >> My position is this : Let's go with UTF8 now, but let's leave >> rooms for other encodings for future needs. > > For the envelopes, headers, and transmission negotiations, > allowing for another coding form just creates more complexity > without any significant payoff unless you expect Unicode itself > to be replaced in the near future. For the content, body parts, > and payload, provisions already exist for other encodings, so it > is a non-issue. +1 Tony Hansen tony@att.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 21:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZzoP-0002Ag-Vo; Fri, 06 Apr 2007 21:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZzoO-0002Ab-GD for ima@ietf.org; Fri, 06 Apr 2007 21:33:52 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZzoM-0004Pb-TY for ima@ietf.org; Fri, 06 Apr 2007 21:33:52 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l371XdJ5008446; Sat, 7 Apr 2007 10:33:39 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l371XbwC008439; Sat, 7 Apr 2007 10:33:37 +0900 Date: Sat, 7 Apr 2007 10:33:37 +0900 From: Soobok Lee To: Martin Duerst Subject: Re: [EAI] OT: HDR=KSC5601SMTP Message-ID: <20070407013337.GN17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <4615690C.75B0@xyzzy.claranet.de> <6.0.0.20.2.20070406112124.0aa6c870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070406112124.0aa6c870@localhost> User-Agent: Mutt/1.4i X-Spam-Score: 0.6 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 06, 2007 at 11:34:01AM +0900, Martin Duerst wrote: > You could press along this route and move out non-basic Arabic > and Syriac and open up space for a script or two more below the > U+0800 boundary, and so on, but whatever you do, there will still > be too little space to fit the currently used alphabetic scripts > all into that space. This is a compression-flavored idea: Let's call it UTF-8E(astern) Top frequently used 1024 CJK Han Ideo chars : cover 90% or more usage Top frequently used 512 Hangeul Syllable chars : cover 99% or more usage fullset of Devanagari etc and Hiragana/Katakana : below 412 chars These eastern characters can be mapped into the range 0x80~0x07ff. For this, 65536 length of forward/reverse code mapping table is needed . Then, UTF-8E can encode most frequently used eastern asia characters as two octets while extended latin/arabic/cyrillic/gree will be encoded in three octets. UTF-8E will share the same property of UTF-8. Soobok > > Not that I'm proposing to do any of this, of course! > > Regards, Martin. > > > At 06:24 07/04/06, Frank Ellermann wrote: > >Frank Ellermann confused five and six bits: > > > >> FRom u+0080 up to u+7FFF you'd still have to encode 16 bits, an > >> "UTF-8 like coding" would then need three 10xx xxxx tail octets, > > > >Correction: It would use 1110 xxxx 10xx xxxx 10xx xxxx (3 octets) > > > >And with 110x xxxx 10xx xxxx it can encode 11 bits in 2 octets, > >for John's algorithm that boundary is at u+F800. For most code > >points in the BMP it would need three octets just like UTF-8. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 06 22:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha0Vk-0004XG-Lt; Fri, 06 Apr 2007 22:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha0Vj-0004X8-KQ for ima@ietf.org; Fri, 06 Apr 2007 22:18:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha0Vg-0002g7-An for ima@ietf.org; Fri, 06 Apr 2007 22:18:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ha0UM-0002qn-1m for ima@ietf.org; Sat, 07 Apr 2007 04:17:14 +0200 Received: from 212.82.251.103 ([212.82.251.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Apr 2007 04:17:14 +0200 Received: from nobody by 212.82.251.103 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Apr 2007 04:17:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 07 Apr 2007 04:15:00 +0200 Organization: Lines: 14 Message-ID: <4616FEA4.4806@xyzzy.claranet.de> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <4615690C.75B0@xyzzy.claranet.de> <6.0.0.20.2.20070406112124.0aa6c870@localhost> <20070407013337.GN17458@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.103 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 2.0 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAI] OT: HDR=KSC5601SMTP X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > These eastern characters can be mapped into the range 0x80~0x07ff. [...] > UTF-8E will share the same property of UTF-8. If you're serious about this idea I propose to - continue the discussion on the Unicode list - leave u+0080 up to u+009F alone, e.g. for the XML 1.1 "NEL" - submit the I-D as "independent draft", don't let the Unicode or IETF folks touch it, I think they'd kill it for various reasons. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 07 01:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3P4-0004P5-H8; Sat, 07 Apr 2007 01:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3P2-0004Ou-M5 for ima@ietf.org; Sat, 07 Apr 2007 01:23:56 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha3P1-0003m4-2L for ima@ietf.org; Sat, 07 Apr 2007 01:23:56 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l375NpJ5005250; Sat, 7 Apr 2007 14:23:51 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l375Noil005249; Sat, 7 Apr 2007 14:23:50 +0900 Date: Sat, 7 Apr 2007 14:23:50 +0900 From: Soobok Lee To: Frank Ellermann Subject: Re: [EAI] OT: HDR=KSC5601SMTP Message-ID: <20070407052350.GO17458@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <4615690C.75B0@xyzzy.claranet.de> <6.0.0.20.2.20070406112124.0aa6c870@localhost> <20070407013337.GN17458@ns5.lsb.org> <4616FEA4.4806@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4616FEA4.4806@xyzzy.claranet.de> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, Apr 07, 2007 at 04:15:00AM +0200, Frank Ellermann wrote: > Soobok Lee wrote: > > > These eastern characters can be mapped into the range 0x80~0x07ff. > [...] > > UTF-8E will share the same property of UTF-8. > > If you're serious about this idea I propose to > - continue the discussion on the Unicode list Thanks for your encouragement. This "UTF-8E" has different binary-sort ordering than UTF-8 and UTF-32. So if it ever come out, it won't be general use for protocol strings, but, rather mainly for efficient encoding of unicode texts, as replacement for local charsets and their encodings. Anyway, it will help promote Unicode/ISO 10646 character set in eastern asia. I'v done brief research for fun about how to design "UTF-8E". See attached draft excerpts. Under the following schemes, even greek/cyrillic/arabic/latin don't lose so much in encoding efficiency. If anyone have further interests, reply to me personally, not into this list. Soobok -------------------------------------------------------------------------- Appendix A. Preserved Code Ranges in U+0080~U+07FF 2048 (0x800) - 128 (0x80) = 1920 U+0080 ~ U+009F : (32) C1 control U+00DF ~ U+00FF : (33) Small Latin Supp-1 Letters U+03AC ~ U+03CE : (35) Basic Greek Small U+0430 ~ U+044F : (32) Basic Russian Small U+05D0 ~ U+05F4 : (36) Hebrew based on ISO 8859-8 U+0621 ~ U+064A : (42) Arabic based on ISO 8859-6 (Capital Letters removed from Latin/Gree/Cyrillic) Sub-total : 210 characters 1920 - 210 = 1710 characters Appendix B. To be moved into U+0080~U+07FF from High Area in BMP Devanagari : U+0904 ~ U+0939 : (54) Hiragana: U+3041 ~ U+3096 : (86) Katakana: U+30A1 ~ U+30FF : (95) Thai : U+E01 ~ U+0E4F ( 79 ) Sub-Total : 315 Top frequenctly used Hangeul Syllables : 395 characters Top frequenctly used CJK Han Ideographs : 1000 characters from UNIHAN (each set would cover top 90% of frequently used characters ) 1710 characters ------------------------------------------------------------------------- _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 07 07:16:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha8uF-0005O7-27; Sat, 07 Apr 2007 07:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha8uC-0005KP-Kk for ima@ietf.org; Sat, 07 Apr 2007 07:16:28 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha8uB-0008Tk-B7 for ima@ietf.org; Sat, 07 Apr 2007 07:16:28 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7033C259752 for ; Sat, 7 Apr 2007 13:16:20 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28569-08 for ; Sat, 7 Apr 2007 13:16:15 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id B4C3925974F for ; Sat, 7 Apr 2007 13:16:15 +0200 (CEST) Message-ID: <46177D7C.7050802@alvestrand.no> Date: Sat, 07 Apr 2007 13:16:12 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [EAI] ADMIN: Changing Unicode is out of scope for this WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org If anyone had any doubt.... Proposing changes to Unicode, or the standardization of new character sets that follow down the path of GB-18030 by proposing slight rearrangments of Unicode, is off-topic for this WG. Please take it elsewhere. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 07 07:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha92e-0000Ob-Uq; Sat, 07 Apr 2007 07:25:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha92d-0000Kl-Jw for ima@ietf.org; Sat, 07 Apr 2007 07:25:11 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha92c-0001sj-AA for ima@ietf.org; Sat, 07 Apr 2007 07:25:11 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADFEE259752; Sat, 7 Apr 2007 13:25:09 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29101-02; Sat, 7 Apr 2007 13:25:04 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9186C25974F; Sat, 7 Apr 2007 13:25:04 +0200 (CEST) Message-ID: <46177F8E.50103@alvestrand.no> Date: Sat, 07 Apr 2007 13:25:02 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Soobok Lee Subject: Re: [EAI] OT: HDR=KSC5601SMTP References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <20070406011332.GF17458@ns5.lsb.org> <4615A27A.3040508@icu.ac.kr> <20070406022154.GJ17458@ns5.lsb.org> In-Reply-To: <20070406022154.GJ17458@ns5.lsb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > On Fri, Apr 06, 2007 at 10:29:30AM +0900, Yangwoo Ko wrote: > >> Significant increase of network throughput and even faster drop of >> storage prices make me little impressed by the fact that UTF-8 is not >> the best solution for some languages (including ours :-) ). >> > > Email portals compete with one another and always under pressure > for cost cut to make profits. If you can, try to ask portal personels > about how much they pay for netowrk/storage in a month and about > whether they welcome 50~200% increase of network/storage needs and > about why they still stick to local charset encodings in message format > even now after utf8 is born 7~8 years ago. > > They will make best answers than me. From http://www.gmail.com/ (login page): * *Don't throw anything away.* Over 2837.433624 megabytes (and counting) of free storage so you'll never need to delete another message. 'nuff said. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 07 11:51:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaDCa-0003KU-FV; Sat, 07 Apr 2007 11:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaDCY-0003KL-9j for ima@ietf.org; Sat, 07 Apr 2007 11:51:43 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaDCT-0007QO-Tl for ima@ietf.org; Sat, 07 Apr 2007 11:51:42 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CC62E4AC23; Sat, 7 Apr 2007 17:51:34 +0200 (CEST) Message-Id: Date: Sat, 7 Apr 2007 17:50:06 +0200 From: Arnt Gulbrandsen To: ima@ietf.org Subject: Re: [EAI] OT: HDR=KSC5601SMTP References: <4613B26D.20609@alvestrand.no> <5dzm5nbduo.fsf@Hurtta06k.keh.iki.fi> <20070405063602.GD17458@ns5.lsb.org> <46152FFB.698F@xyzzy.claranet.de> <73A82DA479F0AAE42871CAD3@p3.JCK.COM> <46155AFD.3870@xyzzy.claranet.de> <6.0.0.20.2.20070406113617.0aa72a10@localhost> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Isn't this basically a rehash of http://unicode.org/reports/tr6/? TR6 seems to be entirely unused. My unscientific guess is that most implementers actually prefer the simplicity of UTF-8, no matter what they say they prefer. Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 07 14:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaFhE-00060l-Nn; Sat, 07 Apr 2007 14:31:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaFhD-00060g-EL for ima@ietf.org; Sat, 07 Apr 2007 14:31:31 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaFhB-00034U-Mp for ima@ietf.org; Sat, 07 Apr 2007 14:31:31 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20070214) with ESMTP id l37IUkUu009553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Apr 2007 21:30:46 +0300 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id l37IUkYN021777 ; Sat, 7 Apr 2007 21:30:46 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l37IUj9m020002 ; Sat, 7 Apr 2007 21:30:45 +0300 Received: by siilo.fmi.fi id l37IUhHY019999; Sat, 7 Apr 2007 21:30:43 +0300 Message-Id: <200704071830.l37IUhHY019999@siilo.fmi.fi> In-Reply-To: <06D440266C77CEFEEA0C7726@[192.168.1.108]> To: Harald Tveit Alvestrand Date: Sat, 7 Apr 2007 21:30:43 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123f (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ELM1175970643-19852-0_" X-Filter: smtp1gate: 3 received headers rewritten with id 20070407/25802/01 X-Filter: smtp1gate: ID 25800/01, 2 parts scanned for known viruses X-Filter: torkku: ID 9808/01, 2 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp1gate.fmi.fi [193.166.223.31]); Sat, 07 Apr 2007 21:30:46 +0300 (EEST) X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 25800/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: Kari Hurtta , Kari Hurtta , ima@ietf.org, Wei MAO Subject: [EAI] UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --ELM1175970643-19852-0_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp1gate.fmi.fi id l37IUkUu009553 >>> Harald Tveit Alvestrand > There hasn't been any suggestion that the HDR=3D8BIT (or 7BIT, or its=20 > absence) say anything in general about what the client is able to suppp= ort. >=20 > If you want to have response strings with UTF-8 in them, better go push= the=20 > LANG command extension that Alexey has been mumbling about for half a d= ozen=20 > years. >=20 > Harald I think that you misunderstand my comment. Issue was about reply codes, which may include UTF8SMTP mailboxes on reply (and specically when SMTP c= omand argument was ASCII only.) See YAO Jiankang' answer (message is included). He answered that UTF8SMTP= =20 mailboxes are allowed on replies. One example is EXPN root 250 2.1.5 Ville Ker=E4nen when SMTP cleint is not used any argument which indicates that it support= s UTF8SMTP. Another one, which can include UTF8SMTP mailbox on reply, is VRFY command. All reply strings are still on default language (english?) on these scena= rios. Another one are 251 and 551 response codes which include mailbox. EHLO xxx 250-mail.example.com 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250-UTF8SMTP 250 HELP MAIL FROM: 250 OK RCPT TO: 251 is new address, will forward ( client crashes ?) And another case MAIL FROM: 250 OK RCPT TO: 551 is new address, please resend ( SMTP client failes to generate proper DSN for that response. ) On both cases client is sending non-UTF8SMTP message to server=20 (and client does not know about UTF8SMTP) > --On 6. april 2007 08:40 +0300 Kari Hurtta =20 > wrote: >=20 > > Soobok Lee writes: > > > >> C) HDR=3D is newly defined parameter. But HDR=3DUTF8 is optional an= d may be > >> omitted. > >> > >> Mail servers may assume HDR=3DUTF8 if HDR=3D parameter is not pr= enet in > >> SMTP session. > > > > Get I this correctly? > > > > HDR=3DUTF8 implicates that SMTP _client_ supports UTF8SMTP > > > > So if HDR=3DUTF8 assumed, it means that SMTP server assumes that a= ll > > smtp clients supports UTF8SMTP > > > > ( Of course _presence_ of HDR=3D7BIT parameter also means that smt= p > > clients supports UTF8SMTP ) > > > > > > And if SMTP client supports UTF8SMTP, smtp server may use UTF-8 on > > it's SMTP reply strings. > > > > So with these assumtions, smtp server may use UTF-8 always on it's re= ply > > strings even when SMTP client knows nothing about UTF8SMTP. > > > > (hmm. Perhaps actually it is EXPN where that need arise without that > > argument of command itself use UTF-8. ) > > > > That is not very critical. It is unlikely that smtp client reply pars= er > > failes to parse reponse even if there is some UTF8SMTP addresses on > > response. (this is guess.) / Kari Hurtta --ELM1175970643-19852-0_ Content-Type: message/rfc822 Return-path: Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) by siilo.fmi.fi (8.12.11.20060308/8.12.11) with ESMTP id l367VrXl018726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Apr 2007 10:31:53 +0300 Received: from smtp2gate.fmi.fi (smtp2gate.fmi.fi [193.166.223.32]) (envelope-from yaojk@cnnic.cn) by torkku.fmi.fi (8.12.11.20060308/8.12.11/mail-20061107/torkku) with ESMTP id l367VrUn027823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Apr 2007 10:31:53 +0300 Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) (envelope-from yaojk@cnnic.cn) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20070214) with SMTP id l367Vpv7004767 for ; Fri, 6 Apr 2007 10:31:52 +0300 Received: (eyou send program); Fri, 06 Apr 2007 15:31:39 +0800 Message-ID: <375844699.22719@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Fri, 06 Apr 2007 15:31:39 +0800 Message-ID: <127501c7781d$9bb40740$096ff1da@cnnicyao> From: "YAO Jiankang" To: "Kari Hurtta" cc: "Wei MAO" References: <375843783.21793@cnnic.cn> Subject: Re: draft-ietf-eai-smtpext-04.txt: EXPN, VRFY Date: Fri, 6 Apr 2007 15:31:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-3.0 (smtp2gate.fmi.fi [193.166.223.32]); Fri, 06 Apr 2007 10:31:53 +0300 (EEST) X-Spam-Flag: NO X-Spam-Status: False, hits=-0.5 required=5 (smtp2gate: ID 20257/01) report=BAYES_00, MIME_BASE64_NO_NAME, MIME_BASE64_TEXT, MSGID_FROM_MTA_HEADER X-Filter: torkku: ID 8850/01, 1 parts scanned for known viruses X-Filter: smtp2gate: ID 20257/01, 1 parts scanned for known viruses X-MIME-Autoconverted: from base64 to 8bit by siilo.fmi.fi id l367VrXl018726 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp1gate.fmi.fi id l37IUkUu009553 ----- Original Message -----=20 From: "Kari Hurtta" To: "YAO Jiankang" Cc: "Wei MAO" ; "Kari Hurtta" Sent: Friday, April 06, 2007 3:16 PM Subject: Re: draft-ietf-eai-smtpext-04.txt: EXPN, VRFY >>>> YAO Jiankang >>=20 >> ----- Original Message -----=20 >> From: "Kari Hurtta" >> To: "Yao Jiankang" >> Cc: ; "Wei MAO" >> Sent: Thursday, April 05, 2007 2:25 PM >> Subject: Re: draft-ietf-eai-smtpext-04.txt: EXPN, VRFY >>=20 >>=20 >> >=20 >> > Another question: On which point server may use UTF-8 >> > on it's reply strings. (or should this asked on list? >> > If it is, you are free to forward that to list. ) >>=20 >> actually, only EAI capability MUA can deliver the UTF-8 stuff to SMTP = server normally. >> If MUA can send the UTF-8 stuff , it means that MUA has the EAI abilit= y. >>=20 >> So, IMO, in general, if SMTP server receives the UTF-8 stuff, it can = return it to original sender. >=20 > I think that you msissed my question. See my example. >=20 >> >=20 >> > That that server announces UTF8SMTP not yet mean that >> > client supports UTF8SMTP. Specially that is issue >> > for EXPN command, I think. (paramater of EXPN >> > may be ASCII, but expansion may include UTF-8 -- so >> > what server does? ) >>=20 >> since paramater of EXPN will include UTF-8, the server should be updat= ed to it. >> John's RFC2821bis may be updated to include it. >> currently, many email system normally deny this command due to securit= y reason. >> EXPN is not the key command of SMTP and it may be not necessary to hav= e a specific text or session to emphasize it. >=20 > No. EXPN is expand .. it may and will list another mailbox than what = is as argument >=20 > hurtta@Hurtta06k:~$ telnet localhost smtp > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 Hurtta06k.keh.iki.fi ESMTP Sendmail 8.13.4/8.13.4/Debian-3ubuntu0.1= ; Fri, 6 Apr 2007 10:06:02 +0300; (No UCE/UBE) logging access from: local= host(OK)-localhost [127.0.0.1] > EHLO xxx > 250-Hurtta06k.keh.iki.fi Hello localhost [127.0.0.1], pleased to meet y= ou > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-EXPN > 250-VERB > 250-8BITMIME > 250-SIZE > 250-DSN > 250-ETRN > 250-AUTH DIGEST-MD5 CRAM-MD5 > 250-DELIVERBY > 250 HELP > EXPN root > 250 2.1.5 Kari Hurtta > QUIT > 221 2.0.0 Hurtta06k.keh.iki.fi closing connection > Connection closed by foreign host. > hurtta@Hurtta06k:~$ =20 >=20 > Is following allowed: >=20 > EHLO xxx > 250-Hurtta06k.keh.iki.fi Hello localhost [127.0.0.1], pleased to meet y= ou > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-EXPN > 250-VERB > 250-8BITMIME > 250-SIZE > 250-DSN > 250-ETRN > 250-AUTH DIGEST-MD5 CRAM-MD5 > 250-DELIVERBY > 250-UTF8SMTP > 250 HELP > EXPN root > 250 2.1.5 Ville Ker=E4nen >=20 >=20 > Assume that these are UTF-8 characters (this mail > may use actually IS-8859-1 I think) very good example. yes, allow it. IMO, may also allow the below comand: EXPN UTF-8 250 2.1.5 utf-8 Thanks. YAO Jiankang CNNIC >=20 >=20 >> Thanks you for your kind comments. >> YAO Jiankang >> CNNIC >>=20 >> >=20 >> > There is no explicit method to enable UTF-8 for replies. >=20 > / Kari Hurtta --ELM1175970643-19852-0_ 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 --ELM1175970643-19852-0_-- From ima-bounces@ietf.org Sat Apr 07 16:25:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHTF-0006um-Si; Sat, 07 Apr 2007 16:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHTE-0006ug-9V for ima@ietf.org; Sat, 07 Apr 2007 16:25:12 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaHTC-0000Gm-JW for ima@ietf.org; Sat, 07 Apr 2007 16:25:12 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HaHT8-000Kiy-L3; Sat, 07 Apr 2007 16:25:07 -0400 Date: Sat, 07 Apr 2007 16:25:05 -0400 From: John C Klensin To: Kari Hurtta , Harald Tveit Alvestrand Subject: Re: [EAI] UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) Message-ID: In-Reply-To: <200704071830.l37IUhHY019999@siilo.fmi.fi> References: <200704071830.l37IUhHY019999@siilo.fmi.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Wei MAO , ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Saturday, April 07, 2007 9:30 PM +0300 Kari Hurtta=20 wrote: >>>> Harald Tveit Alvestrand >> There hasn't been any suggestion that the HDR=3D8BIT (or = 7BIT, >> or its absence) say anything in general about what the >> client is able to suppport. >> >> If you want to have response strings with UTF-8 in them, >> better go push the LANG command extension that Alexey has >> been mumbling about for half a dozen years. >> >> Harald > > I think that you misunderstand my comment. Issue was about > reply codes, which may include UTF8SMTP mailboxes on reply > (and specically when SMTP comand argument was ASCII only.) Unless the client has already done something to clearly indicate = that it is UTF8SMTP-capable (and, no, I don't think this=20 justifies a HDR parameter or anything else), replies had=20 probably best not contain non-ASCII information. > See YAO Jiankang' answer (message is included). He answered > that UTF8SMTP mailboxes are allowed on replies. I think that is wrong in general. See the examples in 2821,=20 which rarely include a mailbox name. > One example is > > EXPN root > 250 2.1.5 Ville Ker=C3=A4nen = One could, in principle, do this. But I note that it is=20 independent of the UTF8SMTP work. It would presumably require a = separate extension, or at least something that the client would=20 need to ask for/ authorize. While I think the specifics of=20 Alexey's "lang" proposal are a bad idea, what is needed here is=20 much closer to that than to what is being suggested above. > when SMTP cleint is not used any argument which indicates that > it supports UTF8SMTP. Unless something has been explicitly extended in this area, a=20 non-ASCII reply (or a reply containing any non-ASCII character)=20 violates 2821. The situation is, IMO, much more like the DSN=20 one that a situation in which a non-ASCII address can be=20 arbitrarily returned. > Another one, which can include UTF8SMTP mailbox on reply, is > VRFY command. > > All reply strings are still on default language (english?) on > these scenarios. > > Another one are 251 and 551 response codes which include > mailbox. > > EHLO xxx > 250-mail.example.com > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-EXPN > 250-VERB > 250-8BITMIME > 250-SIZE > 250-DSN > 250-ETRN > 250-AUTH DIGEST-MD5 CRAM-MD5 > 250-DELIVERBY > 250-UTF8SMTP > 250 HELP > MAIL FROM: > 250 OK > RCPT TO: > 251 is new address, = will forward > > ( client crashes ?) > > And another case > > MAIL FROM: > 250 OK > RCPT TO: > 551 is new address, = please resend > > ( SMTP client failes to generate proper DSN for that response. > ) > > On both cases client is sending non-UTF8SMTP message to server > (and client does not know about UTF8SMTP) And in both cases, either a separate extension is needed or the=20 client needs to report that the only available address is=20 non-ASCII and then, if appropriate, escape it and indicate that=20 is being done. I agree that the SMTPEXT document should probably mention these=20 cases. Briefly. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 06:09:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haqne-0002x3-G0; Mon, 09 Apr 2007 06:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haqne-0002wy-08 for ima@ietf.org; Mon, 09 Apr 2007 06:08:38 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Haqnc-00060b-Ec for ima@ietf.org; Mon, 09 Apr 2007 06:08:37 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l39A8PR9003347; Mon, 9 Apr 2007 19:08:26 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007040919082529267 ; Mon, 09 Apr 2007 19:08:25 +0900 Date: Mon, 09 Apr 2007 19:08:24 +0900 (JST) Message-Id: <20070409.190824.71089572.fujiwara@jprs.co.jp> To: harald@alvestrand.no Subject: Re: [EAI] Message-ID From: fujiwara@jprs.co.jp In-Reply-To: <1217C81951E4B7769D116DA3@[192.168.1.108]> References: <5dfy8enuqw.fsf@Hurtta06k.keh.iki.fi> <1217C81951E4B7769D116DA3@[192.168.1.108]> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ima@ietf.org, hurtta+gmane@siilo.fmi.fi X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: Harald Tveit Alvestrand > I suggest that this is best addressed by adding "except in comments". > Having two kinds of comments in UTF8SMTP headers is asking for even more > trouble than UTF8SMTP is currently asking for. I will add this and add donwgrading method for headers which may contain UTF-8 comments in downgrade-04. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 09:23:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatqN-0006DC-2i; Mon, 09 Apr 2007 09:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatqL-0006D6-Q0 for ima@ietf.org; Mon, 09 Apr 2007 09:23:37 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatqK-0004bI-Es for ima@ietf.org; Mon, 09 Apr 2007 09:23:37 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CBA3259753 for ; Mon, 9 Apr 2007 15:23:32 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25980-04 for ; Mon, 9 Apr 2007 15:23:27 +0200 (CEST) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id D324225974F for ; Mon, 9 Apr 2007 15:23:26 +0200 (CEST) Date: Mon, 09 Apr 2007 15:23:11 +0200 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <4915C28133EC69A74FC3CF59@[192.168.1.108]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As of this moment (early on April 9), I have the following responses to the opinion poll announced on April 4. A - I support HDR=UTF8 - Frank Ellermann - Kari Hurtta (prefers HDR=UTF8SMTP if added) B - I support NOT adding HDR=UTF8 - Yangwoo Ko - John Klensin - Yao Jiankang - Jeff Yeh - Martin Duerst - Harald Alvestrand C - I have an opinion different from the 2 alternatives given, which is.... - Soobok Lee (missing HDR parameter interpreted as HDR=UTF8) - Charles Lindsey (disagrees with definition) That gives a grand total of 10 people with an opinion on this matter, unless I've missed some. I'll let the poll remain open for the rest of today. Please notify me of any errors, misunderstandings or missed opinions. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 09:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haty5-0001gX-94; Mon, 09 Apr 2007 09:31:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haty3-0001ep-Fd for ima@ietf.org; Mon, 09 Apr 2007 09:31:35 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Haty1-0006Ax-U8 for ima@ietf.org; Mon, 09 Apr 2007 09:31:35 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BBDB25974C; Mon, 9 Apr 2007 15:31:33 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26276-04; Mon, 9 Apr 2007 15:31:27 +0200 (CEST) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id D49B8259720; Mon, 9 Apr 2007 15:31:27 +0200 (CEST) Date: Mon, 09 Apr 2007 15:31:12 +0200 From: Harald Tveit Alvestrand To: Kari Hurtta Message-ID: In-Reply-To: <200704071830.l37IUhHY019999@siilo.fmi.fi> References: <200704071830.l37IUhHY019999@siilo.fmi.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ima@ietf.org Subject: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 7. april 2007 21:30 +0300 Kari Hurtta wrote: >>>> Harald Tveit Alvestrand >> There hasn't been any suggestion that the HDR=8BIT (or 7BIT, or its >> absence) say anything in general about what the client is able to >> suppport. >> >> If you want to have response strings with UTF-8 in them, better go push >> the LANG command extension that Alexey has been mumbling about for half >> a dozen years. >> >> Harald > > I think that you misunderstand my comment. Issue was about reply codes, > which may include UTF8SMTP mailboxes on reply (and specically when SMTP > comand argument was ASCII only.) Thanks for the clarification. On rereading, I stand by the words of my response, but it was not a response to what you were suggesting. The problem you cite is general, and troubling. Lots of SMTP responses have embedded mailbox names in them (in practice; whether they are necessary or not is beyond this particular question). I see at least 3 different ways to address that issue in an UTF8SMTP context: - Brutally suppress UTF8 mailbox names in responses (which will make VRFY kind of pointless) - Always return mailboxes in some kind of encoded form (walks straight into all the issues with "automatic ACE" that we've debated and discarded so many times) - Have some kind of command from the client to the server saying "I am willing to accept UTF8 in responses". I do not think "using an UTF8 command" is a good pick for the last one; the idea of having a dialogue that goes -> EHLO <- 250-UTF8SMTP -> VRFY <- 550 Can't return an UTF8 mailbox -> MAIL FROM: .... <- 250 OK -> VRFY <- 200 is fine with me strikes me as a downright bad design. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 09:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hau77-0008U0-B8; Mon, 09 Apr 2007 09:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hau76-0008Tv-Ln for ima@ietf.org; Mon, 09 Apr 2007 09:40:56 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hau75-0007WZ-Fh for ima@ietf.org; Mon, 09 Apr 2007 09:40:56 -0400 Received: from andrew-vpn.int.libertyrms.com ([10.1.7.6] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Hau6u-0006Vt-1Z for ima@ietf.org; Mon, 09 Apr 2007 09:40:44 -0400 Received: by trilby.local (Postfix, from userid 1019) id 463272E815D; Mon, 9 Apr 2007 09:41:17 -0400 (EDT) Date: Mon, 9 Apr 2007 09:41:17 -0400 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM Message-ID: <20070409134116.GA20311@afilias.info> References: <4915C28133EC69A74FC3CF59@[192.168.1.108]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4915C28133EC69A74FC3CF59@[192.168.1.108]> User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, Apr 09, 2007 at 03:23:11PM +0200, Harald Tveit Alvestrand wrote: > As of this moment (early on April 9), I have the following responses to the > opinion poll announced on April 4. > B - I support NOT adding HDR=UTF8 I support this option too (and have read the relevant drafts, even though I'm mostly silent here). A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 12:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawPu-0006jJ-AD; Mon, 09 Apr 2007 12:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawPt-0006j9-3E for ima@ietf.org; Mon, 09 Apr 2007 12:08:29 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HawPW-0004Ur-Ol for ima@ietf.org; Mon, 09 Apr 2007 12:08:29 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HawPT-000CRw-Ca; Mon, 09 Apr 2007 12:08:03 -0400 Date: Mon, 09 Apr 2007 12:08:02 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Kari Hurtta Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) Message-ID: <10910F8FFF2303D633A96AFD@[192.168.1.110]> In-Reply-To: References: <200704071830.l37IUhHY019999@siilo.fmi.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Just on comment on your three options... --On Monday, April 09, 2007 3:31 PM +0200 Harald Tveit Alvestrand wrote: > I see at least 3 different ways to address that issue in an > UTF8SMTP context: > > - Brutally suppress UTF8 mailbox names in responses (which > will make VRFY kind of pointless) > - Always return mailboxes in some kind of encoded form (walks > straight into all the issues with "automatic ACE" that we've > debated and discarded so many times) I don't know if we want to take advantage of it, but there is a difference. Since the reply text is intended for people, and is free-form rather than standardized, one could have (leaving out the extended codes for clarity) <- 250-UTF8SMTP -> VRFY <- 550 No mailbox - Do note that there is essentially no information in the response here that wasn't already known to the client, so simply suppressing the address would not lose any information, contrary to your assertion above. and also have <- 250-UTF8SMTP -> VRFY <- 250 Address is actually ## this and situations like it are the worst case, ## because there actually is new information in the ## reply -> VRFY <- 250-Address is a UTF8SMTP mailbox, encoded <- 250 according to RFC9999 as Also consider the third, even more difficult, case <- VRFY <- 250-Address is a UTF8SMTP mailbox, encoded <- 250 according to RFC9999 as This is not wildly attractive, but it is not rocket science and does not cross the line into the discussions we have repeatedly had about encoded forms. Otherwise, I see little option other than either an explicit assertion from the client that UTF8SMTP stuff is in use. That probably is not the controversial HDR argument, since the headers might not affected at all (note that EHLO VRFY QUIT is a perfectly valid sequence) But might take us toward VRF8 and EXP8. I'd rather not try to do the latter in this WG if we can avoid it, but only because VRFY and EXPN, more than any other SMTP command that has not been deprecated completely, are in need of a modernizing redesign: to create new commands without doing that would be a shame. Of course, one could also have VRFY You-can-send-back-utf8-replies-if-you-want-to (probably spelled in a more reasonable way) and optionally apply that argument to any of MAIL, RCPT, VRFY, or EXPN, possibly using it to set a flag so it didn't need to be invoked more than once. I'd rather avoid it, but it seems a _much_ better solution than something whose semantics get involved with what goes on in the message. > - Have some kind of command from the client to the server > saying "I am willing to accept UTF8 in responses". The last suggestions above sort of start down that path, of course. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 14:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haylf-0005Mf-I7; Mon, 09 Apr 2007 14:39:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hayle-0005MX-4Z for ima@ietf.org; Mon, 09 Apr 2007 14:39:06 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Haylb-0005LL-Eu for ima@ietf.org; Mon, 09 Apr 2007 14:39:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hayl4-000491-QD for ima@ietf.org; Mon, 09 Apr 2007 20:38:30 +0200 Received: from du-001-241.access.de.clara.net ([212.82.227.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Apr 2007 20:38:30 +0200 Received: from nobody by du-001-241.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Apr 2007 20:38:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Mon, 09 Apr 2007 20:37:44 +0200 Organization: Lines: 38 Message-ID: <461A87F8.73D4@xyzzy.claranet.de> References: <200704071830.l37IUhHY019999@siilo.fmi.fi> <10910F8FFF2303D633A96AFD@[192.168.1.110]> 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: du-001-241.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [EAI] Re: UTF8SMTP mailbox on SMTP reply X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > I see little option other than either an explicit assertion > from the client that UTF8SMTP stuff is in use. That > probably is not the controversial HDR argument, since the > headers might not affected at all (note that > EHLO > VRFY > QUIT > is a perfectly valid sequence) > But might take us toward VRF8 and EXP8. I'd rather not try to > do the latter in this WG if we can avoid it, but only because > VRFY and EXPN, more than any other SMTP command that has not > been deprecated completely, are in need of a modernizing > redesign: to create new commands without doing that would be a > shame. Okay, but the UTF8SMTP draft has to mention this or any similar choice somewhere. VRF8 and EXP8 would be really ugly. Maybe the 2821bis crowd can deprecate EXPN while they're at it, I'm not sure what 2821bis-01 3.5.2 actually means wrt EXPN. Is it some kind of "SHOULD implement and immediately disable it" ? Maybe we could add a command USE8 enabling UTF8SMTP addresses in responses, valid until the next EHLO, HELO, or RSET ? >> - Have some kind of command from the client to the server >> saying "I am willing to accept UTF8 in responses". > The last suggestions above sort of start down that path, of > course. What's the alternative for say 251 + 551, new response codes in the direction of "I'd like to tell you more but can't" ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 15:01:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haz6w-0000pg-Al; Mon, 09 Apr 2007 15:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haz6v-0000oO-2s for ima@ietf.org; Mon, 09 Apr 2007 15:01:05 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Haz6t-0002Y7-G4 for ima@ietf.org; Mon, 09 Apr 2007 15:01:05 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39J1238020723 for ; Mon, 9 Apr 2007 19:01:02 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JG800201VE94B00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 09 Apr 2007 13:01:02 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JG80064DVHNZF20@mail-amer.sun.com>; Mon, 09 Apr 2007 13:01:02 -0600 (MDT) Date: Mon, 09 Apr 2007 12:01:13 -0700 From: Chris Newman Subject: Re: MIME message/utf8smtp vs application/utf8smtp (Re: [EAI] Re: MIME questions) In-reply-to: To: Charles Lindsey , IMA Message-id: <04A5DA16AC7BF928D71F7CAF@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <6D61E50E631C519346FE9B0B@htat43p-no.corp.google.com> <5dhcs92rei.fsf@Hurtta06k.keh.iki.fi> <46072326.15CF@xyzzy.claranet.de> <5dlkhk632m.fsf@Hurtta06k.keh.iki.fi> <46074629.2EB2@xyzzy.claranet.de> <5dd52w5zg7.fsf@Hurtta06k.keh.iki.fi> <46079C77.7010700@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 3/26/07 14:52 +0100: > We have already been through this once, and Crhis Newman agreed, On Feb 16th: > > "Ok, I've been convinced application/utf-8-message is a safer label for > the type." While that statement remains true. I'll also observe that an experiment need not choose the safer course. Regardless, I have passed primary editing responsibility to Alexey and I plan to recuse myself during IESG evaluation of this document. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 15:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazH7-0007Tz-6n; Mon, 09 Apr 2007 15:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazH6-0007Nl-4T for ima@ietf.org; Mon, 09 Apr 2007 15:11:36 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HazH3-0004tE-Nj for ima@ietf.org; Mon, 09 Apr 2007 15:11:36 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39JBXEE025226 for ; Mon, 9 Apr 2007 19:11:33 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JG800D01VSHZD00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 09 Apr 2007 13:11:33 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JG8007NFVZ2HFC0@mail-amer.sun.com>; Mon, 09 Apr 2007 13:11:30 -0600 (MDT) Date: Mon, 09 Apr 2007 12:11:40 -0700 From: Chris Newman Subject: Re: [EAI] How to prevent up-conversion (Re: Respawn "Messages on original form" (Re: I-D ACTION:draft-ietf-eai-imap-utf8-01.txt)) In-reply-to: To: Charles Lindsey , IMA Message-id: <9B92A69247A11F9091D8F9AD@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <5dzm6phryr.fsf@Hurtta06k.keh.iki.fi> <5dps73kck6.fsf_-_@Hurtta06k.keh.iki.fi> <92B1D989CE9BC3531A8384AC@dhcp-1572.ietf68.org> <47922D99787EA425873C8670@as-s2n.ietf68.org> <34CE20B037B1DB6BE54F39CE@htat43p-no.corp.google.com> <4605063D.4050209@alvestrand.no> <9DFCAF338495CF923A3FE937@p3.JCK.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 3/27/07 14:49 +0100: > Let us take an example. A message body was in Q-P on the wire. Is the IMAP > implementation entitled to store it in only its decoded (8bit) form? Suppose > the message was in fact signed by DKIM or PGP-mime (both of which are > supposed to sign the Q-P form - a bad design decision, but there it is). The > recipient (or his MUA) finds that the signature is broken. So the recipient > requests to see the original form of the message so that he can check for > himself exactly why the signature did not work (maybe some trailing empty > line had got lost, and by manually restoring it he can make the signature > work). Mail gateways in general are not required to preserve signatures beyond a best-effort to preserve multipart/signed content. Final delivery to a mail store that may or may not be native RFC 2822 would count as a gateway. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 18:16:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb29P-0000wA-HS; Mon, 09 Apr 2007 18:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb29O-0000fs-0E for ima@ietf.org; Mon, 09 Apr 2007 18:15:50 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb29J-0001ER-Rn for ima@ietf.org; Mon, 09 Apr 2007 18:15:49 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39MFjG9003851 for ; Mon, 9 Apr 2007 22:15:45 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JG9006014AQU600@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 09 Apr 2007 16:15:45 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JG900G1Z4I6BN20@mail-amer.sun.com>; Mon, 09 Apr 2007 16:15:45 -0600 (MDT) Date: Mon, 09 Apr 2007 15:15:56 -0700 From: Chris Newman Subject: Re: [EAI] #1481 HDR=UTF8 argument - status, and request for input In-reply-to: <46080217.90407@alvestrand.no> To: Harald Alvestrand , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <46080217.90407@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As a technical participant, I find the ability to bounce at RCPT TO for servers without down-convert capability a significant but not compelling benefit for HDR=UTF8. The added complexity of another SMTP parameter combined with the delay it will cost in word smithing to get the text right for the precise meaning of the parameter makes me lean slightly towards not having the parameter. - Chris Harald Alvestrand wrote on 3/26/07 19:25 +0200: > Hello, > > as I see the current status with HDR=UTF8, we have: > > - The WG meeting in Prague discussed it, and found no particular advantage in > using it, for the same reason as with the header marker: The recipient, in > order to be certain about the format of a message, has to parse the message > anyway, so the flag will at best be a warning, and at worst it can generate > silly states when it is wrong. > > - After the WG meeting, the argument was raised (or, at least, I did not > understand it until after the meeting) that IF an MTA does NOT implement > downconversion, BUT handles mail for some recipients that are able to receive > UTF8SMTP mail, AND some recipients that are not so capable, the HDR=UTF8 flag > will give the MTA the ability to reject the recipients for which it cannot > handle the message, and accept the recipients for which it assumes that > UTF8SMTP delivery will succeed. > > There are two other alternatives: > - Say that an MTA MUST implement either conversion or return of an error > message, after delivery > - Say that an MTA can return a 5xx reply to the DATA command, rejecting the > message for all recipients. > > So far, we have heard from Kari, Charles and Frank on this issue. > > I would like the other participants in the WG to weigh in with opinions; I > have created #1481 to make it easy to keep track of this one separate from > other issues. > > Harald > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 18:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2TG-00071j-Lm; Mon, 09 Apr 2007 18:36:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2TF-00070k-0c for ima@ietf.org; Mon, 09 Apr 2007 18:36:21 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2TC-0006Bd-OF for ima@ietf.org; Mon, 09 Apr 2007 18:36:20 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39MaIQb022488 for ; Mon, 9 Apr 2007 22:36:18 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JG90050155SW500@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 09 Apr 2007 16:36:18 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JG9007T55GFY000@mail-amer.sun.com>; Mon, 09 Apr 2007 16:36:18 -0600 (MDT) Date: Mon, 09 Apr 2007 15:36:29 -0700 From: Chris Newman Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM In-reply-to: <4613B26D.20609@alvestrand.no> To: Harald Alvestrand , EAI WG Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <4613B26D.20609@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org B - I support NOT adding HDR=UTF8 - Chris Harald Alvestrand wrote on 4/4/07 16:13 +0200: > As of this moment, I believe the current alternatives are on the table: > > A - New SMTP argument to MAIL FROM: HDR=, with defined value HDR=UTF8 > > This indicates that the message being sent contains UTF-8 data in MAIL FROM, > RCPT TO or headers (including inner body headers), which means that it needs > downgrading before it can be passed to an ASCII-only recipient. > > Advantage: In the case where the recieving MTA knows which recipients can > handle UTF8SMTP mail, and the MTA does not have downgrade capability, it can > reject recipients by replying to the RCPT TO command with an appropriate > error code. > (It will still have to do downgrade-or-bounce if it discovers the final > destination after accepting the RCPT TO command.) > > Advantage: The MTA can decide on whether downgrading is required based on the > SMTP argument, and can treat any 8-bit character in the headers as a protocol > error if the flag is not given. > > B - No new SMTP argument. > > Advantage: Less complexity. No need for an MTA to consider whether or not to > apply downgrading based on the error code it got back; any recipients > rejected with a 5XX code can be considered rejected immediately. > > Advantage: Less cruft for the UTF8SMTP case - cleaner end state. > > There are other opinions on the relative merits of the two alternatives, but > I believe those are the most important ones > > If you have an opinion on this issue, please send a note to the mailing list > with ONE of the following statements: > > A - I support HDR=UTF8 > B - I support NOT adding HDR=UTF8 > C - I have an opinion different from the 2 alternatives given, which is.... > > This poll closes in 7 days, on April 9, 2007. > > Harald, for the chairs > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 19:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2zP-0004le-Ia; Mon, 09 Apr 2007 19:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2zN-0004jz-SS for ima@ietf.org; Mon, 09 Apr 2007 19:09:33 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2zM-0007bN-7W for ima@ietf.org; Mon, 09 Apr 2007 19:09:33 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l39N9V7a026793 for ; Mon, 9 Apr 2007 23:09:31 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JG900D016S5AN00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 09 Apr 2007 17:09:31 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JG900G1P6ZTBN30@mail-amer.sun.com>; Mon, 09 Apr 2007 17:09:31 -0600 (MDT) Date: Mon, 09 Apr 2007 16:09:43 -0700 From: Chris Newman Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) In-reply-to: To: Harald Tveit Alvestrand , Kari Hurtta Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200704071830.l37IUhHY019999@siilo.fmi.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote on 4/9/07 15:31 +0200: > I see at least 3 different ways to address that issue in an UTF8SMTP context: > > - Brutally suppress UTF8 mailbox names in responses (which will make VRFY > kind of pointless) > - Always return mailboxes in some kind of encoded form (walks straight into > all the issues with "automatic ACE" that we've debated and discarded so many > times) > - Have some kind of command from the client to the server saying "I am > willing to accept UTF8 in responses". Another option is to defer the issue of SMTP status response encoding to: If the client negotiates the LANG extension, then the server is free to provide utf8@utf8 in the status text. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 19:40:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3TF-0006bC-97; Mon, 09 Apr 2007 19:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3TE-0006b5-Dg for ima@ietf.org; Mon, 09 Apr 2007 19:40:24 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb3TD-0002IF-3e for ima@ietf.org; Mon, 09 Apr 2007 19:40:24 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hb3T8-000FXd-ET; Mon, 09 Apr 2007 19:40:18 -0400 Date: Mon, 09 Apr 2007 19:40:17 -0400 From: John C Klensin To: Chris Newman , Harald Tveit Alvestrand , Kari Hurtta Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) Message-ID: <9221C014418195E6239CF6CF@p3.JCK.COM> In-Reply-To: References: <200704071830.l37IUhHY019999@siilo.fmi.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 09 April, 2007 16:09 -0700 Chris Newman wrote: > Another option is to defer the issue of SMTP status response > encoding to: > > > 06.txt> > > If the client negotiates the LANG extension, then the server > is free to provide utf8@utf8 in the status text. Except that the non-ASCII SMTP status problem needs to be solved and at least a few of us believe that Alexey's draft violates a fundamental architectural principle of the Internet. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 09 20:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4Qb-0000jZ-6h; Mon, 09 Apr 2007 20:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4QQ-0000dk-8z for ima@ietf.org; Mon, 09 Apr 2007 20:41:34 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4P3-0005Zp-At for ima@ietf.org; Mon, 09 Apr 2007 20:40:16 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38253) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Hb4Oc-0006cH-PV (Exim 4.63) (return-path ); Tue, 10 Apr 2007 01:39:44 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hb4Oc-0006FQ-QH (Exim 4.54) (return-path ); Tue, 10 Apr 2007 01:39:42 +0100 Date: Tue, 10 Apr 2007 01:39:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) In-Reply-To: <9221C014418195E6239CF6CF@p3.JCK.COM> Message-ID: References: <200704071830.l37IUhHY019999@siilo.fmi.fi> <9221C014418195E6239CF6CF@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Kari Hurtta , Chris Newman , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 9 Apr 2007, John C Klensin wrote: > > Except that the non-ASCII SMTP status problem needs to be solved > and at least a few of us believe that Alexey's draft violates a > fundamental architectural principle of the Internet. If you are referring to the RFC 2277 protocol/text distinction, then I think it is very difficult to argue that the textual parts of SMTP replies are protocol not intended to be read by humans - since everyone uses them for human readable text. Enhanced Status Codes do not provide an adequate foundation for internationalization since they do not cover the complete range of possible reasons for rejection and the range they do cover is not covered in enough detail. These inadequacies cannot be fixed since new ESCs for existing parts of the protocol are not interoperable - older software won't have textual explanations for them - and anti-spam tactics mean there's a never-ending supply of new reasons for rejecting email. Therefore the ESC registry is only useful for co-ordinating ESC allocations for new protocol extensions. In practice I usually configure my systems to produce a brief error message and a URL, such as a DNS blacklist lookup URL, or a link to further documentation. In principle HTTP can then do some of the i18n heavy lifting - though this is not a solution for UTF8 in SMTP replies. Alexey's draft has the same architectural model as the LANG command in FTP (RFC 2640) and proposed for POP and IMAP. Tony. -- f.a.n.finch http://dotat.at/ SOLE: NORTH OR NORTHEAST 2 OR 3, OCCASIONALLY 4. SLIGHT OR MODERATE. FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 06:19:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbDQf-0005hK-9x; Tue, 10 Apr 2007 06:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbDQe-0005h4-Hg for ima@ietf.org; Tue, 10 Apr 2007 06:18:24 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbDQd-0004Oq-OT for ima@ietf.org; Tue, 10 Apr 2007 06:18:24 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l3AAI3R9016823; Tue, 10 Apr 2007 19:18:04 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007041019180203223 ; Tue, 10 Apr 2007 19:18:02 +0900 Date: Tue, 10 Apr 2007 19:18:03 +0900 (JST) Message-Id: <20070410.191803.48510446.fujiwara@jprs.co.jp> To: chl@clerew.man.ac.uk Subject: Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Thank you very much for your many comments. I'm updating downgrade document. > From: "Charles Lindsey" > As compared to the Utf8headers and Smtpext drafts, this one still seems a > long way from completion. > > 1. Introduction > > Downgrading in UTF8SMTP consists from following two parts: > ^^^^ > of the fixed > This document assumes that MIME headers are not extended to use UTF-8 > characters because it is not clearly defined in > [I-D.ietf-eai-utf8headers]. > > On the contrary, [I-D.ietf-eai-utf8headers] now makes it very clear that > those MIME headers are to be extended, and the downgrading of those > headers now needs to be addressed. > > 3.1. Timing and conditions of downgrading > > Conditions: SMTP client detects that non-ASCII characters are > included in the SMTP envelope or mail header fields in the SMTP > DATA. > > That needs to include mail header fields at any level within the MINE > structure. changed to: or mail header fields and MIME body part headers in the SMTP DATA. > 3.2. Requirements > > 4. Downgrading and upgrading should be easy and lightweight as it is > possible to do with MTA like 8BITMIME encapsulation. > > But even downgrading 8BITMIME is not "easy and lightweight" if down > properly (e.g. as sendmail does it). Granted that the machinery for doing > 8BITMIME downgrading can easily be adapted to do header downgrading. removed this requirement. > 4. Downgraded header > > downgraded = "Downgraded:" [CFWS] field-name ":" dvalue CRLF > field-name = 1*ftext > ftext = %d33-57 / %d59-126 ; printable ASCII except ":" > dvalue = 1*any-ascii > any-ascii = %d32-126 > > No, the proper syntax there is > > downgraded = "Downgraded:" [CFWS] field-name ":" unstructured CRLF > > Since is essentially what RFC 2047 is defined to work upon. > And I am not sure whether you want that "[CFWS]" there. Shouldn't it be > "[FWS]", because this header is always automatically generated, so there > will never be any comments in it? Or do you want downgrading > implementations to be able to add comments in there to cover unanticipated > situations (just like Received headers have acquired comments in such > ways). "[CFWS]" is changed to "[FWS]". > 3. You change the syntax to > > downgraded = "Downgraded:" [CFWS] field-name ":" encoded CRLF > encoded = *([FWS] (utext / encoded-word) [FWS] > > where is the strict RFC 2822 version, and comes > from RFC 2047. Rewrited ABNF as 3. > To preserve SMTP envelope downgraded information, another new header > is required, and it is specified as "Envelope-Downgraded". Details > are described in Section 5. The header field syntax is specified as > follows: > > fields =/ edowngraded > edowngraded = "Envelope-Downgraded:" [CFWS] field-name ":" value CRLF > field-name = "From" / "To" > value = CFWS "<" uPath ">" CFWS "<" Mailbox ">" CFWS > > Several problems here: > > 1. Same question about whether CFWS rather than FWS is appropriate in a > machine-generated header. changed to FWS. > 2. Please don't use as an ABNF name. Too much risk of confusion > with as used in MIME parameters changed to "edowngraded-value" > 3. Would it be better to have a notation (e.g. using some 'arrow' like > "->") which immediately suggested which of the two addresses was the > original and which was the downgraded? I think two angle-addrs are enough. > 4. Since this header will itself inevitably have to be downgraded, > wouldn't it be simpler to do it all in one step by providing for the > to be encoded (e.g. by RFC 2047). All you would need would be a > syntax like > > value = CFWS "<" encoded-word ">" CFWS "<" Mailbox ">" CFWS changed to this line and add some comments. > 5. SMTP Downgrading > > One SMTP session may contain multiple recipients. Downgrading SHOULD > be performed for each SMTP recipient address individually. First, > split a multiple recipients session to each sessions. If the > recipient address is downgradable, the SMTP session to the recipient > is downgradable. > > It is not clear what you mean by the term "session" here. Is it defined > anywhere? Removed lines which contains "session". > Also note that by appending "Envelope-Downgraded:" headers, MUA/MTA > MUST perform Email header Downgrading described in Section 6. > > And that is the unnecessary step I want to avoid by defining the > Envelope-Downgraded header to be already pure ASCII. I agreed and replaced. > ESMTP ORCPT parameter is used for Delivery Status Notifications > (DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After > extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT > parameter downgrading should be defined here. > > Then please do it, or agree with Chris that it is to be defined in the DSN > document, and cross-reference it from here (but I think it would be better > to do it here, and I think we are agreed that it has to be done by %hex > encoding of the UTF-8). > > 6. Email header Downgrading > > This section defines conversion method to US-ASCII for each header > which may contain Non-ASCII characters. If the whole mail header > does not contain Non-ASCII characters, email header downgrading is > not required. > > You need to add that headers in MIME body parts and in contained > message/rfc822 objects also need to be examined. > > Otherwise, email header downgrading checks each header > whether it contains UTF-8 characters or not. > ^^^^^^^^^^^^^^^^ > s > {or whatever they are eventually called} Changed to 'non-ASCII' which is defined in framework document. > .......... If the header contains > UTF-8 characters, convert the header in a suitable method for of each > header. Each header's downgrading method is described below: > > This section defines conversion method to US-ASCII for each header > which may contain Non-ASCII characters. If the whole mail header > does not contain Non-ASCII characters, email header downgrading is > not required. Otherwise, email header downgrading checks each header > whether it contains UTF-8 characters or not. If the header contains > UTF-8 characters, convert the header in a suitable method for of each > header. Each header's downgrading method is described below: > > From, To, CC, Reply-To, Return-Path: > > You need to add the Sender header, and also say that it applies to any > other header that might be defined to use a . Added Sender and Resent-{From,To,CC}, removed Return-Path. > And please s/header/header field/ in all places where it is not already > done. > > The header field body is composed of single or multiple angle- > addr/addr-spec fields defined in [I-D.ietf-eai-utf8headers]. > ^^^^^^^^^ > utf8-addr-spec > If the header has no 'angle-addr' or 'utf8-addr-spec' which > contains UTF-8 characters, only "display-name" part contains UTF-8 > ^^^^^^^^^^^^^^^^ ^^^^^ > s > s > characters, encode the header by [RFC2047] with UTF-8 tag and > ^^^^^^^^^^ ^^^^^^^^^^ > that > replace it. fixed. > Generally speaking, when refering to objects defined by ABNF, it is better > to enclose them within <.....> as recommended in RFC 4234, than to enclose > them within '.........'. Ok, I will change. > ... When > this address header downgrading fails, this downgrading fails and > the mail MUST be bounced. > > For some reason, we decided to use "rejected", rather than "bounced". fixed. > Subject: > Encode the header by [RFC2047] with UTF-8 tag and replace it. > > There are other headers where this would be the proper treatment. E.g. > Keywords, and header defined as by other standards (e.g. > the Summary header in Netnews), and all X-headers. added. > You also need to mention Envelope-Downgraded in this list, unless you have > adopted my suggestion to make it already all-ASCII when it is generated. > > Downgraded headers should be inserted or replaced at the same > position of the original header. > > Yes, I think that is correct, although it might be argued that they are > "Trace" headers. > > 6.1. Downgrading address headers > > This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return- > Path:" headers which contains Originator/Destination address(es). > > You need to add Sender: to that list. Even Bcc:, though it should not > really be there. But it would also apply to any other header that might be > defined in future with a in it (it should be permitted for > agents that recognixe it, though we cannot REQUIRE it for headers newly > invented after our document is published). agreed and added Bcc and Sender. > And somewhere around here (section 6.2 maybe) you have to describe the > downgrading of MIME s, which are allowed to contain UTF-8 according > to Utf8headers. The downgrade should, of course, use RFC 2231, and a > Downgraded header should be provided as well. I will write this. > You also need at least a placeholder for downgrading List-* headers, > although discussion of these in ongoing in a separate thread. And maybe a > placeholder for any downgrading that may sries from the DSN draft. I will add List-* headers. > 7. Upgrading downgraded header Upgrading is moved to appendix and I will rewrite. > 8. Implementation consideration > MUA MAY encode UTF-8 in Subject header with the same encoding of body > part while downgrading. > > That also applies to other unstructured headers, and to display-names, > etc. It is essentially the point I made earlier about upgrading possibly > undoing more than the earlier downgrading did. > > UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show > Non-ASCII mail addresses on display. > > s/MUST/SHOULD/ (twice). There is no interoperability - just confusion :-( . > This part is removed. > 10. IANA Considerations > > IANA is requested to add the "Envelope-Downgraded:", and > "Downgraded:" new headers to the registry with the entries pointing > to this specification for its definition. > > You need to provede proper templates for these, as required by RFC 3864. OK, added. > Appendix A. Examples > > A.1. Downgrading example 1 > > In this example, there are two sessions, one is To:, the other is > CC:. Both sessions are downgradable. Figure 4 shows To: session > downgrading. > > > I don't think "sessions" is the right word here. There is only one SMTP > "session", which lasts from the EHLO until the connection is broken. What > you are talking about here is just a part of the processing of one > message, namely that which applies to a single RCPT. Perhaps someone else > can suggest a better word here, but "session" is definitely wrong. changed "session" to "recipient". > Result of the header downgrading. > > > Downgraded: Envelope-Downgraded: From: > MIME() > Downgraded: Envelope-Downgraded: To: > MIME() > > s/MIME/RFC2047/ (or some other word, e.g. "DECODE") changed to RFC2047 > And at the end of this downgraded example, please show how a Return-Path > (derived from the MAIL FROM) would look. And how would you show an > in it? Is it accompanied somehow by a Downgraded: > Return-Path: ... . I don't think we ever discussed how that would work. added. Return-Path: will be downgraded . Decoding Envelope-Downgraded header may restore it as non-ASCII address, but it is not target of this document. > A.2. Upgrading example > > And somehow you have to show how a Return-Path got upgraded (if at all) > here. > > Figure 10: Downgraded header upgraded message > > As a result, in this simple example, all headers are preserved. > ^ > the original fixed. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 07:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbE9N-0002Ph-A7; Tue, 10 Apr 2007 07:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbE9L-0002PK-Nn for ima@ietf.org; Tue, 10 Apr 2007 07:04:35 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbE9K-0005rg-Cz for ima@ietf.org; Tue, 10 Apr 2007 07:04:35 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8385F259761 for ; Tue, 10 Apr 2007 13:04:31 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30685-03 for ; Tue, 10 Apr 2007 13:04:26 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80ED725975E for ; Tue, 10 Apr 2007 13:04:26 +0200 (CEST) Message-ID: <461B6F3A.6020602@alvestrand.no> Date: Tue, 10 Apr 2007 13:04:26 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: ima@ietf.org Subject: [EAI] POLL RESULT: HDR= extension on MAIL FROM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As of this moment, I beleve that April 9 is over just about everywhere. I have the following responses to the opinion poll announced on April 4, one more than the preliminary: A - I support HDR=UTF8 - Frank Ellermann - Kari Hurtta (prefers HDR=UTF8SMTP if added) B - I support NOT adding HDR=UTF8 - Yangwoo Ko - John Klensin - Yao Jiankang - Jeff Yeh - Martin Duerst - Harald Alvestrand - Chris Newman C - I have an opinion different from the 2 alternatives given, which is.... - Soobok Lee (missing HDR parameter interpreted as HDR=UTF8) - Charles Lindsey (disagrees with definition) That gives a grand total of 11 people with an opinion on this matter, unless I've missed some. Based on this poll, it seems reasonable to instruct the editors of the SMTPEXT document *not* to add anything about a HDR= parameter. Please notify me of any errors, misunderstandings or missed opinions. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 07:30:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYT-0006b7-Qh; Tue, 10 Apr 2007 07:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYS-0006ak-H2 for ima@ietf.org; Tue, 10 Apr 2007 07:30:32 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEYL-0002v0-T3 for ima@ietf.org; Tue, 10 Apr 2007 07:30:32 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew$man$ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461b73a0.e3e1.10 for ima@ietf.org; Tue, 10 Apr 2007 12:23:12 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3ABNBLO014700 for ; Tue, 10 Apr 2007 12:23:12 +0100 (BST) Date: Tue, 10 Apr 2007 12:23:11 +0100 To: IMA Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) References: <200704071830.l37IUhHY019999@siilo.fmi.fi> <10910F8FFF2303D633A96AFD@[192.168.1.110]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <10910F8FFF2303D633A96AFD@[192.168.1.110]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 09 Apr 2007 17:08:02 +0100, John C Klensin wrote: > Also consider the third, even more difficult, case > > <- VRFY > <- 250-Address is a UTF8SMTP mailbox, encoded > <- 250 according to RFC9999 as And that situation is even more likely to arise with the EXPN command. {Slightly off topic, but can someone please explain to me why VRFY and EXPN are so often deprecated?} However, there is a crude but possibly adequate solution to this problem, and that is that the server should "just send 8bit (i.e. UTF-8)". This will often make more sense to the client than a message saying, in ASCII, "sorry, I cannot answer because I am not allowed to use 8bit". Even if the client is reading in ISO-8859-X, UTF-8 will show up as obviously garbled characters, which the user will interpret as "seems to be some charset inknown to me". And most likely the same effect if the text gets truncated to 7bit. Eitherway, what is conveyed to the client is "it is possible that you are not going to be able to read this". BTW, RFC3977 (the latest NNTP draft) officially specified UTF-8 as the default charset, not that it is expected to occur much unless and until Netnews adopts EAI or something like it. However, that does mean that NNTP servers are now allowed to send UTF-8 responses, and older NNTP clients will have to do the best they can with such responses - essentially as I have indicated above. Alternatively, if we really must have a means for a client to say "I will accept UTF-8 responses", then Alexey's LANG command (even without parameters) would be a good way to indicate that - even if sent to a system that did not advertixe LANGUAGE it would do little harm, and make things no worse than any other solution. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 07:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEyk-0003Rn-Vq; Tue, 10 Apr 2007 07:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEyi-0003RK-Ko for ima@ietf.org; Tue, 10 Apr 2007 07:57:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEyh-0002Gj-AS for ima@ietf.org; Tue, 10 Apr 2007 07:57:40 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HbEyc-000Krc-Rp; Tue, 10 Apr 2007 07:57:35 -0400 Date: Tue, 10 Apr 2007 07:57:34 -0400 From: John C Klensin To: fujiwara@jprs.co.jp, chl@clerew.man.ac.uk Subject: Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Message-ID: In-Reply-To: <20070410.191803.48510446.fujiwara@jprs.co.jp> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> X-Mailer: Mulberry/4.0.7 (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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 10 April, 2007 19:18 +0900 fujiwara@jprs.co.jp wrote: >... >> ... When >> this address header downgrading fails, this >> downgrading fails and the mail MUST be bounced. >> >> For some reason, we decided to use "rejected", rather than >> "bounced". > > fixed. Please be careful about this so as to not introduce new problems. "rejected" is intended to imply "detected during the receiving function of the SMTP system and handled by sending a reply code back to the would-be sender". Unless the downgrade machinery is invoked before the connection from the sender is closed, any notification to the sender that downgrading is not possible will have to be sent as a DSN, not a provided in a "reject" context. While it would be possible to do so in at least some cases, in general trying to keep that incoming connection open until it is determined whether successful downgrading can be accomplished would not be a good idea. >> There are other headers where this would be the proper >> treatment. E.g. Keywords, and header defined as >> by other standards (e.g. the Summary header >> in Netnews), and all X-headers. > > added. Certainly not for "all X-headers" since one has no idea what is in them. This strikes me as dangerous and I would prefer that we be very conservative about it. >... regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 09:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGNZ-0002FU-Ra; Tue, 10 Apr 2007 09:27:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGNY-0002FO-Gc for ima@ietf.org; Tue, 10 Apr 2007 09:27:24 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbGNX-0000ax-2o for ima@ietf.org; Tue, 10 Apr 2007 09:27:24 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HbGNV-000LTm-Hs; Tue, 10 Apr 2007 09:27:21 -0400 Date: Tue, 10 Apr 2007 09:27:18 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply Message-ID: In-Reply-To: <461A87F8.73D4@xyzzy.claranet.de> References: <200704071830.l37IUhHY019999@siilo.fmi.fi> <10910F8FFF2303D633A96AFD@[192.168.1.110]> <461A87F8.73D4@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (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: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 09 April, 2007 20:37 +0200 Frank Ellermann wrote: > John C Klensin wrote: > >> I see little option other than either an explicit assertion >> from the client that UTF8SMTP stuff is in use. That >> probably is not the controversial HDR argument, since the >> headers might not affected at all (note that >> EHLO >> VRFY >> QUIT >> is a perfectly valid sequence) > >> But might take us toward VRF8 and EXP8. I'd rather not try to >> do the latter in this WG if we can avoid it, but only because >> VRFY and EXPN, more than any other SMTP command that has not >> been deprecated completely, are in need of a modernizing >> redesign: to create new commands without doing that would be a >> shame. > > Okay, but the UTF8SMTP draft has to mention this or any similar > choice somewhere. VRF8 and EXP8 would be really ugly. Maybe > the 2821bis crowd can deprecate EXPN while they're at it, I'm > not sure what 2821bis-01 3.5.2 actually means wrt EXPN. Is it > some kind of "SHOULD implement and immediately disable it" ? Closer to "while EXPN is often bad news in the general case, there may be exceptions in which it is very useful In particular, if the user or system making the EXPN request is known an authenticated via some mechanism, the considerations may be quite different from those if that is not the case.". If you think 2821bis needs text to make that more explicit, please suggest it on that list and provide the text. > Maybe we could add a command USE8 enabling UTF8SMTP addresses > in responses, valid until the next EHLO, HELO, or RSET ? That would be one approach. >>> - Have some kind of command from the client to the server >>> saying "I am willing to accept UTF8 in responses". > >> The last suggestions above sort of start down that path, of >> course. > > What's the alternative for say 251 + 551, new response codes > in the direction of "I'd like to tell you more but can't" ? For reasons that I hope 2821 explains adequately, including the simple observation that alias and forwarding processing are rarely done these days until long after the message has been accepted, 251 and 551 have not been widely supported for many, many years. I believe I argued during the DRUMS period that they should be deprecated entirely but, if I did, I lost the argument. Again, there may be special circumstances but, speaking personally, it will be hard to convince me to lose sleep over message syntax associated with those codes. But, if one wanted to do it, some appropriate text, followed by an escaped form of the address (see my other note on this subject) would presumably be an alternative. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 09:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGaT-0005uv-Na; Tue, 10 Apr 2007 09:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGaS-0005uq-Lt for ima@ietf.org; Tue, 10 Apr 2007 09:40:44 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbGaR-00040m-6p for ima@ietf.org; Tue, 10 Apr 2007 09:40:44 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HbGaN-000Li0-T3; Tue, 10 Apr 2007 09:40:40 -0400 Date: Tue, 10 Apr 2007 09:40:39 -0400 From: John C Klensin To: Tony Finch Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) Message-ID: <1851D11802DEE96CAFDAAAD0@p3.JCK.COM> In-Reply-To: References: <200704071830.l37IUhHY019999@siilo.fmi.fi> <9221C014418195E6239CF6CF@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (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 Cc: Kari Hurtta , Chris Newman , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 10 April, 2007 01:39 +0100 Tony Finch wrote: > On Mon, 9 Apr 2007, John C Klensin wrote: >> >> Except that the non-ASCII SMTP status problem needs to be >> solved and at least a few of us believe that Alexey's draft >> violates a fundamental architectural principle of the >> Internet. > > If you are referring to the RFC 2277 protocol/text > distinction, I was not. I was referring to the much older idea that we should establish single "line" format and forms and let systems at the end points convert to and from them rather than creating the N**2 problem of everyone being expected to understand everyone else's forms (or, in this case, languages and character sets). >... > Enhanced Status Codes do not provide an adequate > foundation for internationalization since they do not cover > the complete range of possible reasons for rejection and the > range they do cover is not covered in enough detail. These > inadequacies cannot be fixed since new ESCs for existing parts > of the protocol are not interoperable - older software won't > have textual explanations for them - and anti-spam tactics > mean there's a never-ending supply of new reasons for > rejecting email. Therefore the ESC registry is only useful for > co-ordinating ESC allocations for new protocol extensions. If you are correct, then enhanced status codes are a failure and should be pulled of the standards track and junked: providing the adequate foundation to which you refer was a large part of the justification for doing those codes in the first place. Note, in that regard, the second sentence of Section 2 of RFC 1893: "These status codes are intended to be used for media and language independent status reporting." So I await the proposal to deprecate the things and, ideally, to replace them with something that will accomplish that goal. > In practice I usually configure my systems to produce a brief > error message and a URL, such as a DNS blacklist lookup URL, > or a link to further documentation. In principle HTTP can then > do some of the i18n heavy lifting - though this is not a > solution for UTF8 in SMTP replies. > > Alexey's draft has the same architectural model as the LANG > command in FTP (RFC 2640) and proposed for POP and IMAP. IMO, 2640 is badly broken for other reasons. Trying to write that up and fix it generated a collection of prerequisite work. And I have almost the same objections to the POP and IMAP proposals that I do to the SMTP one. However, SMTP is more difficult for the usual other reason: FTP, POP, and IMAP all require a direct client-server connection (in FTP's case, for the command channel) to operate. Consequently, any negotiations about replies are between the client and the server that will produce them. Because of the relay issues, an SMTP negotiation about the language and form of responses is much more tentative and tenuous. Certainly it will work sometimes, but the other cases a problematic. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 14:34:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLB9-0001Jm-Jy; Tue, 10 Apr 2007 14:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLB7-0001Jg-N9 for ima@ietf.org; Tue, 10 Apr 2007 14:34:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbLB6-0001Sz-DM for ima@ietf.org; Tue, 10 Apr 2007 14:34:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbLAy-0004xl-25 for ima@ietf.org; Tue, 10 Apr 2007 20:34:44 +0200 Received: from d253189.dialin.hansenet.de ([80.171.253.189]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 20:34:44 +0200 Received: from nobody by d253189.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 20:34:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 10 Apr 2007 20:33:32 +0200 Organization: Lines: 22 Message-ID: <461BD87C.D6B@xyzzy.claranet.de> References: <200704071830.l37IUhHY019999@siilo.fmi.fi> <9221C014418195E6239CF6CF@p3.JCK.COM> 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: d253189.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [EAI] Re: UTF8SMTP mailbox on SMTP reply X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote: > In practice I usually configure my systems to produce a brief error > message and a URL, such as a DNS blacklist lookup URL, or a link to > further documentation. In principle HTTP can then do some of the i18n > heavy lifting - though this is not a solution for UTF8 in SMTP replies. In a nutshell one of the reasons why there are no I18N considerations in RFC 4408: A http-URL is much better, or at least good enough. > Alexey's draft has the same architectural model as the LANG command > in FTP (RFC 2640) and proposed for POP and IMAP. FTP etc. replies aren't copied verbatim into a DSN. The DSN has its own charset, and the mailer creating a DSN has no idea which charset an I18N reply code might use. If Alexey manages to specify that it MUST be UTF-8 if it's not ASCII, then it's still in a language I don't know (as original sender, in no direct relationship with the mailer forced to create the DSN). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 10 22:23:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbSTr-00042b-UI; Tue, 10 Apr 2007 22:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbSTp-00042R-S8 for ima@ietf.org; Tue, 10 Apr 2007 22:22:41 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbSTo-0001m9-BJ for ima@ietf.org; Tue, 10 Apr 2007 22:22:41 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l3B2M5RD022616; Wed, 11 Apr 2007 11:22:11 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007041111221105991 ; Wed, 11 Apr 2007 11:22:11 +0900 Date: Wed, 11 Apr 2007 11:22:10 +0900 (JST) Message-Id: <20070411.112210.74734503.fujiwara@jprs.co.jp> To: klensin@jck.com Subject: Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt From: fujiwara@jprs.co.jp In-Reply-To: References: <20070410.191803.48510446.fujiwara@jprs.co.jp> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: chl@clerew.man.ac.uk, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: John C Klensin > >> For some reason, we decided to use "rejected", rather than > >> "bounced". > > > > fixed. > > Please be careful about this so as to not introduce new > problems. "rejected" is intended to imply "detected during the > receiving function of the SMTP system and handled by sending a > reply code back to the would-be sender". Unless the downgrade > machinery is invoked before the connection from the sender is > closed, any notification to the sender that downgrading is not > possible will have to be sent as a DSN, not a provided in a > "reject" context. While it would be possible to do so in at > least some cases, in general trying to keep that incoming > connection open until it is determined whether successful > downgrading can be accomplished would not be a good idea. I understand. I deleted "rejected" and rewrited as "Downgrading fails". After failed downgrading, the message will be bounced but it is written in smtpext document. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 01:08:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbV4F-0003Tt-Am; Wed, 11 Apr 2007 01:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbV4D-0003Ql-KC for ima@ietf.org; Wed, 11 Apr 2007 01:08:25 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbV49-00079t-LB for ima@ietf.org; Wed, 11 Apr 2007 01:08:25 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HbV3a-0002D6-AK; Wed, 11 Apr 2007 01:07:48 -0400 Date: Wed, 11 Apr 2007 01:07:28 -0400 From: John C Klensin To: fujiwara@jprs.co.jp Subject: Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Message-ID: <064CF73F297811D452D92B71@p3.JCK.COM> In-Reply-To: <20070411.112210.74734503.fujiwara@jprs.co.jp> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.112210.74734503.fujiwara@jprs.co.jp> X-Mailer: Mulberry/4.0.7 (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: 97adf591118a232206bdb5a27b217034 Cc: chl@clerew.man.ac.uk, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 11 April, 2007 11:22 +0900 fujiwara@jprs.co.jp wrote: >> From: John C Klensin >> >> For some reason, we decided to use "rejected", rather than >> >> "bounced". >> > >> > fixed. >> >> Please be careful about this so as to not introduce new >> problems. "rejected" is intended to imply "detected during >> the receiving function of the SMTP system and handled by >> sending a reply code back to the would-be sender". Unless >> the downgrade machinery is invoked before the connection from >> the sender is closed, any notification to the sender that >> downgrading is not possible will have to be sent as a DSN, >> not a provided in a "reject" context. While it would be >> possible to do so in at least some cases, in general trying >> to keep that incoming connection open until it is determined >> whether successful downgrading can be accomplished would not >> be a good idea. > > I understand. > > I deleted "rejected" and rewrited as "Downgrading fails". > After failed downgrading, the message will be bounced but it is > written in smtpext document. That is, I think, an excellent solution. thanks, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 02:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWDN-0005GE-Pn; Wed, 11 Apr 2007 02:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWDN-0005G9-6Y for ima@ietf.org; Wed, 11 Apr 2007 02:21:57 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbWDK-0004vJ-QM for ima@ietf.org; Wed, 11 Apr 2007 02:21:57 -0400 Received: (eyou send program); Wed, 11 Apr 2007 14:20:59 +0800 Message-ID: <376272459.28148@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (218.241.111.9) by 159.226.7.146 with SMTP; Wed, 11 Apr 2007 14:20:59 +0800 Message-ID: <05a801c77c01$903bd400$096ff1da@cnnicyao> From: "YAO Jiankang" To: Subject: Fw: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Date: Wed, 11 Apr 2007 14:20:55 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540232427==" Errors-To: ima-bounces@ietf.org --===============0540232427== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 Zm9yd2FyZGVkIGl0IGFzIGl0IGlzLg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy b206ICJZdXJpIEluZ2xpa292IiA8WXVyaS5JbmdsaWtvdkBtaWNyb3NvZnQuY29tPg0KVG86IDxm dWppd2FyYUBqcHJzLmNvLmpwPjsgPGtsZW5zaW5AamNrLmNvbT4NCkNjOiA8Y2hsQGNsZXJldy5t YW4uYWMudWs+OyA8aW1hQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAw NyAxOjU2IFBNDQpTdWJqZWN0OiBSRTogW0VBSV0gRGlzY3Vzc2lvbiBvZiBkcmFmdC1pZXRmLWVh aS1kb3duZ3JhZGUtMDMudHh0DQoNCg0KSSBhbSB0cnlpbmcgdG8gY2F0Y2ggdXAgb24gdGhlIHBy b2dyZXNzIG9mIHRoaXMgV0cgYW5kIHdvbmRlcmluZyBpZiB0aGUgZm9sbG93aW5nIHdhcyBldmVy IGRlYmF0ZWQgb3Igbm90LiBUaGUgZG93bmdyYWRpbmcgd2l0aCBEb3duZ3JhZGVkOiBhbmQgRW52 ZWxvcGUtRG93bmdyYWRlZCBoZWFkZXIgZmllbGRzIGFwcGFyZW50bHkgaGFzIHRoZSBmb2xsb3dp bmcgaXNzdWVzOg0KDQoxLiBBZGRyZXNzIGhlYWRlciBmaWVsZHMgKHN1Y2ggYXMgVG8sIENjLC4u LikgZ29pbmcgb3V0IG9mIHN5bmMgd2l0aCBjb3JyZXNwb25kaW5nIERvd25ncmFkZWQ6IGhlYWRl ciBmaWVsZHMuIFRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgd2hpY2ggbW9kaWZ5IGFkZHJlc3MgaGVh ZGVyIGZpZWxkcywgc3VjaCBhcyBhZGRyZXNzIHJld3JpdGluZyBhZ2VudHMgb3Igd29ya2Zsb3cg YXBwbGljYXRpb25zLiBUaGlzIG1lYW5zIHRoYXQgdXBncmFkZSBvZiBhZGRyZXNzIGhlYWRlciBm aWVsZCBtYXkgbm90IGFsd2F5cyBiZSBwb3NzaWJsZS4gSSB0aGluayB0aGF0IHRoZSBtZXRob2Qg d2hpY2ggaXMgYmFzZWQgb24gaW50cm9kdWNpbmcgdW5zdHJ1Y3R1cmVkIHJlZHVuZGFudCBpbmZv cm1hdGlvbiBsaWtlIHRoaXMgaXMgZmxhd2VkLiBNeSBwcmVmZXJlbmNlLCBpZiB3ZSBuZWVkIHRv IGtlZXAgYSBwYXRoIHRvIHVwZ3JhZGUgaGVhZGVyIGZpZWxkcywgd291bGQgYmUgdG8gZG8gdGhp cyBvbiBhIHBlci1yZWNpcGllbnQgYmFzaXMgYW5kIGp1c3QgZHJvcCB0aGUgRG93bmdyYWRlZDog aW5mb3JtYXRpb24gaWYgY29ycmVzcG9uZGluZyByZWNpcGllbnQgbm90IGZvdW5kIGluIGFueSBh ZGRyZXNzIGhlYWRlci4gQWxzbyB3ZSBzaG91bGQgaW50cm9kdWNlIGFzIGxpdHRsZSByZWR1bmRh bmN5IGFzIHBvc3NpYmxlLCBlLmcuIHRoZXJlIGlzIG5vIG5lZWQgdG8gZHVwbGljYXRlIGRpc3Bs YXkgbmFtZXMgaW4gRG93bmdyYWRlZDogaGVhZGVyIGFzIGRpc3BsYXkgbmFtZSBjYW4gYmUgc2Fm ZWx5IDIwNDctZW5jb2RkZWQgd2l0aG91dCBkYXRhIGxvc3MuDQoNCjIuIFNvbWUgTVVBIHBvdGVu dGlhbGx5IGNhbiBwcmVzZXJ2ZSB0aGUgRG93bmdyYWRlZDogaGVhZGVyIGZpZWxkcyBpbiByZXBs aWVzIGFuZCBlc3BlY2lhbGx5IGluIGZvcndhcmRlZCBtZXNzYWdlcy4gV2hpbGUgdGhpcyBtYXkg bm90IGJlIGEgcHJvYmxlbSBmb3IgUkZDMjgyMiBvciBNSU1FIGhlYWRlciBmaWVsZHMgKGl0IGlz IG5vdCB3b3JzZSB0aGFuIG9yaWdpbmFsIGhlYWRlciBmaWVsZCBiZWluZyBwcmVzZXJ2ZWQpLCB0 aGUgbmV0IHJlc3VsdCBpcyB0aGF0IHN1Y2ggRG93bmdyYWRlZDogaGVhZGVycyBjYW4gYXBwZWFy IGluIGEgd3JvbmcgbWVzc2FnZSwgaS5lLiBub3QgdGhlIG9uZSB3aGljaCB3YXMgb3JpZ2luYWxs eSBkb3duZ3JhZGVkLiBUaGlzLCBvbiB0aGUgZmlyc3QgZ2xhbmNlLCBjYW4gYmUgYSByZWFsIHBy b2JsZW0gZm9yIEVudmVsb3BlLURvd25ncmFkZWQgaGVhZGVycywgZS5nLiBNQUlMIEZST00gYWRk cmVzcywgaXMgaXQ/IEUuZy4gY291bGQgaXQgY2F1c2UgUDEgc2VuZGVyIG9mIGEgbWVzc2FnZSBi ZWluZyByZXBsYWNlZCB3aXRoIG9yaWdpbmFsIHNlbmRlciB3aGlsZSB1cGdyYWRpbmcgdGhlIGVu dmVsb3BlIGluZm9ybWF0aW9uPyBJcyB0aGVyZSBzdWNoIHRoaW5nIGFzIGVudmVsb3BlIGluZm9y bWF0aW9uIHVwZ3JhZGU/IElmIG5vdCwgdGhlbiB3aHkgYm90aGVyIHByZXNlcnZpbmcgc3VjaCBp bmZvcm1hdGlvbiAob3RoZXIgdGhhbiBhcyBhbm90aGVyIHRyYWNlIGZpZWxkKT8NCg0KSSBwZXJz b25hbGx5IHRoaW5rIHRoYXQgaXQgY2FuIGJlIGFjY2VwdGFibGUgdG8gZGVmaW5lIHRoZSBkb3du Z3JhZGUgcHJvY2VzcyBhcyBub3QgcmV2ZXJzaWJsZSwgZS5nLiB0aGF0IGRvd25ncmFkZSBjYW4g anVzdCBkcm9wIHRoZSBVVEY4IGFkZHJlc3MgYW5kIHVzZSBhbHQtYWRkcmVzc2VzIGluc3RlYWQu IFRoZXJlIHNob3VsZCBiZSBubyBzdWNoIHRoaW5nIGFzIHVwZ3JhZGUsIHRoZSBkb3duZ3JhZGVk IG1lc3NhZ2Ugc2hvdWxkIGJlIGhhbmRsZWQgYXMgbm9ybWFsIHByZS1FQUkgbWVzc2FnZSB3aXRo IGFwcHJvcHJpYXRlIGluZm9ybWF0aW9uIGVuY29kZWQgaW4gYSBiYWNrd2FyZHMtY29tcGF0aWJs ZSBmYXNoaW9uLiBXaGF0IGFyZSBkaXNhZHZhbnRhZ2VzIG9mIHRoaXMgYXBwcm9hY2g/IEkgYXNz dW1lIHdlIHdhbnQgdGhlIGRvd25ncmFkZSBtZWNoYW5pc20gdG8gYmUgbGVzcyBhbmQgbGVzcyBu ZWNlc3Nhcnkgb3ZlciB0aW1lIHdoZW4gZXZlcnlib2R5IHVwZ3JhZGVzIHRvIHN1cHBvcnQgRUFJ Lg0KDQpNeSBhbm90aGVyIGZlZWxpbmcgaXMgdGhhdCB1bmtub3duIGhlYWRlciBmaWVsZHMgZG93 bmdyYWRlIGNhbiBqdXN0IHVzZSBSRkMyMDQ3IGVuY29kaW5nIGJ5IGRlZmF1bHQuIFRoZSByZWFz b25pbmcgaXMgdGhhdCBubyBoZWFkZXIgZmllbGRzIGRlZmluZWQgYmVmb3JlIEVBSSBhcmUgc3Vw cG9zZWQgdG8gY29udGFpbiBVVEYtOCBhbmQgbm8gZG93bmdyYWRlIHNob3VsZCBiZSBuZWNlc3Nh cnkgZm9yIHN1Y2ggaGVhZGVyIGZpZWxkcywgZXhjZXB0IHRob3NlIHNwZWNpZmljYWxseSBzdXBw b3J0ZWQgYnkgRUFJIChzdWNoIGFzIFN1YmplY3QsIGFkZHJlc3MgaGVhZGVyIGZpZWxkcykuIE9m IGNvdXJzZSBuZXcgaGVhZGVyIGZpZWxkcyBjYW4gYmUgZGVmaW5lZCBhZnRlciBFQUkgaXMgaW50 cm9kdWNlZCB3aGljaCBtYXkgd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZiBVVEY4LiBJbiBzdWNo IGNhc2UgdGhleSBlaXRoZXIgc2hvdWxkIGJlIGRlZmluZWQgYXMgdW5zdHJ1Y3R1cmVkIGhlYWRl cnMgZm9yIHdoaWNoIGRlZmF1bHQgZG93bmdyYWRlIG1lY2hhbmlzbSAoUkZDMjA0NykgaXMgc3Vm ZmljaWVudCwgb3IgdGhvc2UgYXJlIG5ldyBzdHJ1Y3R1cmVkIGhlYWRlcnMuIEZvciBuZXcgc3Ry dWN0dXJlZCBoZWFkZXJzIEVBSSBjb3VsZCBkZWZpbmUgYSB3YXkgdG8gaWRlbnRpZnkgc3VjaCBo ZWFkZXIgZm9yIEVBSSBkb3duZ3JhZGUgcHVycG9zZXMgYW5kIGEgY29tbW9uIG9wZW4gZm9ybWF0 IChsaWtlIHRoZSBvbmUgZGVmaW5lZCBmb3IgYSBDb250ZW50LURpc3Bvc2l0aW9uIGhlYWRlciB3 aXRoIHBhcmFtZXRlcnMpIHdpdGggcHJvdmlzaW9ucyBob3cgdG8gaWRlbnRpZnkgcGFydHMgd2hp Y2ggcG90ZW50aWFsbHkgY2FuIGNvbnRhaW4gVVRGOCBhbmQgaG93IHRvIGRvd25ncmFkZSB0aGVt IChSRkMyMjMxPykuDQoNCkkuZS4gdGhlbiBkb3duZ3JhZGUgcHJvY2VzcyBjb3VsZCBiZSBkZWZp bmVkIGFzIGRyb3BwaW5nIHJlZHVuZGFudCBpbmZvcm1hdGlvbiAoVVRGOCBhZGRyZXNzZXMpIGFu ZCBvcmRlcmx5IGVuY29kaW5nIG9mIHJlbWFpbmluZyBVVEY4IGluZm9ybWF0aW9uLiBObyB1cGdy YWRlIHByb2Nlc3Mgc2hvdWxkIGJlIGRlZmluZWQuDQoNClNvcnJ5IGlmIEkgYW0gYnJpbmdpbmcg YmFjayBzb21ldGhpbmcgd2hpY2ggd2FzIGFscmVhZHkgZGViYXRlZCBhbmQgcmVqZWN0ZWQsIEkg c3RpbGwgaGF2ZSBhIGxvdCB0byBjYXRjaCB1cC4NCg0KVGhhbmtzLA0KWXVyaQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZnVqaXdhcmFAanBycy5jby5qcCBbbWFpbHRvOmZ1 aml3YXJhQGpwcnMuY28uanBdDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAwNyA3OjIyIFBN DQpUbzoga2xlbnNpbkBqY2suY29tDQpDYzogY2hsQGNsZXJldy5tYW4uYWMudWs7IGltYUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtFQUldIERpc2N1c3Npb24gb2YgZHJhZnQtaWV0Zi1lYWktZG93 bmdyYWRlLTAzLnR4dA0KDQo+IEZyb206IEpvaG4gQyBLbGVuc2luIDxrbGVuc2luQGpjay5jb20+ DQo+ID4+IEZvciBzb21lIHJlYXNvbiwgd2UgZGVjaWRlZCB0byB1c2UgInJlamVjdGVkIiwgcmF0 aGVyIHRoYW4NCj4gPj4gImJvdW5jZWQiLg0KPiA+DQo+ID4gZml4ZWQuDQo+DQo+IFBsZWFzZSBi ZSBjYXJlZnVsIGFib3V0IHRoaXMgc28gYXMgdG8gbm90IGludHJvZHVjZSBuZXcNCj4gcHJvYmxl bXMuICAicmVqZWN0ZWQiIGlzIGludGVuZGVkIHRvIGltcGx5ICJkZXRlY3RlZCBkdXJpbmcgdGhl DQo+IHJlY2VpdmluZyBmdW5jdGlvbiBvZiB0aGUgU01UUCBzeXN0ZW0gYW5kIGhhbmRsZWQgYnkg c2VuZGluZyBhDQo+IHJlcGx5IGNvZGUgYmFjayB0byB0aGUgd291bGQtYmUgc2VuZGVyIi4gICBV bmxlc3MgdGhlIGRvd25ncmFkZQ0KPiBtYWNoaW5lcnkgaXMgaW52b2tlZCBiZWZvcmUgdGhlIGNv bm5lY3Rpb24gZnJvbSB0aGUgc2VuZGVyIGlzDQo+IGNsb3NlZCwgYW55IG5vdGlmaWNhdGlvbiB0 byB0aGUgc2VuZGVyIHRoYXQgZG93bmdyYWRpbmcgaXMgbm90DQo+IHBvc3NpYmxlIHdpbGwgaGF2 ZSB0byBiZSBzZW50IGFzIGEgRFNOLCBub3QgYSBwcm92aWRlZCBpbiBhDQo+ICJyZWplY3QiIGNv bnRleHQuICBXaGlsZSBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBkbyBzbyBpbiBhdA0KPiBsZWFz dCBzb21lIGNhc2VzLCBpbiBnZW5lcmFsIHRyeWluZyB0byBrZWVwIHRoYXQgaW5jb21pbmcNCj4g Y29ubmVjdGlvbiBvcGVuIHVudGlsIGl0IGlzIGRldGVybWluZWQgd2hldGhlciBzdWNjZXNzZnVs DQo+IGRvd25ncmFkaW5nIGNhbiBiZSBhY2NvbXBsaXNoZWQgd291bGQgbm90IGJlIGEgZ29vZCBp ZGVhLg0KDQpJIHVuZGVyc3RhbmQuDQoNCkkgZGVsZXRlZCAicmVqZWN0ZWQiIGFuZCByZXdyaXRl ZCBhcyAiRG93bmdyYWRpbmcgZmFpbHMiLg0KQWZ0ZXIgZmFpbGVkIGRvd25ncmFkaW5nLCB0aGUg bWVzc2FnZSB3aWxsIGJlIGJvdW5jZWQgYnV0IGl0IGlzDQp3cml0dGVuIGluIHNtdHBleHQgZG9j dW1lbnQuDQoNCi0tDQpLYXp1bm9yaSBGdWppd2FyYSwgSlBSUw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSU1BIG1haWxpbmcgbGlzdA0KSU1BQGll dGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCg0K --===============0540232427== 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 --===============0540232427==-- From ima-bounces@ietf.org Wed Apr 11 02:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWRi-0003lI-Am; Wed, 11 Apr 2007 02:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWRg-0003l2-T2 for ima@ietf.org; Wed, 11 Apr 2007 02:36:44 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbWRf-0000hy-Bh for ima@ietf.org; Wed, 11 Apr 2007 02:36:44 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l3B6aXR9026880; Wed, 11 Apr 2007 15:36:33 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007041115363308071 ; Wed, 11 Apr 2007 15:36:33 +0900 Date: Wed, 11 Apr 2007 15:36:32 +0900 (JST) Message-Id: <20070411.153632.71104159.fujiwara@jprs.co.jp> To: klensin@jck.com Subject: downgrading target header list (Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt) From: fujiwara@jprs.co.jp In-Reply-To: References: <20070410.191803.48510446.fujiwara@jprs.co.jp> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: chl@clerew.man.ac.uk, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: John C Klensin > >> There are other headers where this would be the proper > >> treatment. E.g. Keywords, and header defined as > >> by other standards (e.g. the Summary header > >> in Netnews), and all X-headers. > > > > added. > > Certainly not for "all X-headers" since one has no idea what is > in them. This strikes me as dangerous and I would prefer that > we be very conservative about it. Encapsulating undefined headers (including all X-headers) is reasonable? I listed headers from RFC 4021. (There may be some omission.) Then, I categorized 7 rewriting header methods. Please check the list of downgrading target headers below. And then, I have a question about Content-* header downgrading. Content-* header appears in RFC 2045 section 5. Which downgrading method is suitable for Unknown Content-* header, (7)Encapsulating into Downgraded or (5)RFC 2231 ? - List of downgrading target headers 1. Originator and destination addresses headers -> preserve original header into Downgraded: header and rewrite utf8-addr-spec as alt-addr (comment encoded by 2047) From: Sender: Reply-To: To: Cc: Bcc: Resent-From: Resent-Sender: Resent-To: Resent-Cc: Resent-Reply-To: Disposition-Notification-To: 2. ASCII only value with non-ascii comment -> encode by RFC 2047 Date: Message-ID: In-Reply-To: References: Resent-Date: Resent-Message-ID: MIME-Version: Content-ID: 3. text header -> encode by RFC 2047 Subject: Comments: Keywords: 4. trace header -> Remove uFor clause Received: 5. MIME headers (with UTF-8 string) -> encode by RFC 2231 Content-Type: Content-Transfer-Encoding: Content-Description: 6. URI headers -> encode by RFC 3987 List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 7. Unknown/Undefined headers -> encapsulate into Downgraded header X-headers: other unstructured headers: other structured headers: --- Regards, -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 02:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWUh-0004tv-Eb; Wed, 11 Apr 2007 02:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWUg-0004s2-DR for ima@ietf.org; Wed, 11 Apr 2007 02:39:50 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbWUb-00019e-Hq for ima@ietf.org; Wed, 11 Apr 2007 02:39:50 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HbWUS-0002kM-DJ; Wed, 11 Apr 2007 02:39:38 -0400 Date: Wed, 11 Apr 2007 02:39:21 -0400 From: John C Klensin To: Yuri Inglikov Subject: RE: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Message-ID: <27976DE0DDBDFCAD4DACB7B7@p3.JCK.COM> In-Reply-To: References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.112210.74734503.fujiwara@jprs.co.jp> X-Mailer: Mulberry/4.0.7 (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: 29dc808194f5fb921c09d0040806d6eb Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yuri, This is a personal perspective. I hope that the authors of the downgrade draft, and others, will respond to you also. I think you have captured the key issues here. I believe that there are three, philosophically different, ways to look at the problem for which the downgrade draft is a proposed solution. Each one has implications for, e.g.., likely rate of deployment and quality of interworking during the transition period. There is not complete agreement about what those implications might be, i.e., different people have different theories about which approach is most likely to lead to rapid deployment of the EAI features. These are listed in order of increasing complexity, not preference. (1) No downgrading at all. An address is an address. Addresses being unreachable are old news and, while I might want to tell a correspondent to use a hotmail address if my normal one doesn't seem to be working, I do that in the body of the message and allow the sending user to deal with it, rather than requiring additional syntax to express the alternatives. In this model, if a UTF-8 address cannot be reached, the message just gets rejected or returned. Problems arise when the UTF-8 address is backward-pointing (so there is no place for an ASCII-only system to send a reply or delivery status notification) or if the envelope is all-ASCII but the message headers contain UTF-8 material. For the second of these cases, the worst-case problem is only constructing a DSN, which is inherently less general than the problem of constructing a machine-intelligible downgraded message. (2) Downgrading only. Here, the downgrading operation is treated as a one-way gateway transformation, with the target being to create as near an approximation to the original message as possible in all-ASCII form. Other than trace information that would indicate that the transformation occurred, there would be no serious attempt to preserve pre-downgrade information that couldn't be cleanly expressed in encoded words, no attempt to preserve digital signatures, etc. Probably there would be no new headers, eliminating the problems you identify. However, an internationalized client sitting behind an ASCII-only system or relay would see only the ASCII addresses and have no mechanism to generate a reply to the UTF-8 address (unless there were comments in the body text), even if it has a UTF8SMTP-capable path in the reverse direction. (3) Downgrading with upgrade capability at the endpoints. If one thinks it is important to permit a UTF8SMTP-capable mail reader or MUA at the receiving end to see an approximation of the original message, headers, and addresses, despite downgrading on the path to it, then one needs to, somehow, preserve most of the original information -- much more information than is required by (2). How far one wants to go, and how far one can go, is so far still an unresolved question, with trying to preserve or restore the integrity of envelope information and of digital signatures over header fields as the most stringent possible targets. Clearly, the downgrade document reflects the third view. If one were to adopt one of the other views instead, the specifications would be quite different. regards, john (2) --On Tuesday, 10 April, 2007 22:56 -0700 Yuri Inglikov wrote: > I am trying to catch up on the progress of this WG and > wondering if the following was ever debated or not. The > downgrading with Downgraded: and Envelope-Downgraded header > fields apparently has the following issues: > > 1. Address header fields (such as To, Cc,...) going out of > sync with corresponding Downgraded: header fields. There are > applications which modify address header fields, such as > address rewriting agents or workflow applications. This means > that upgrade of address header field may not always be > possible. I think that the method which is based on > introducing unstructured redundant information like this is > flawed. My preference, if we need to keep a path to upgrade > header fields, would be to do this on a per-recipient basis > and just drop the Downgraded: information if corresponding > recipient not found in any address header. Also we should > introduce as little redundancy as possible, e.g. there is no > need to duplicate display names in Downgraded: header as > display name can be safely 2047-encodded without data loss. > > 2. Some MUA potentially can preserve the Downgraded: header > fields in replies and especially in forwarded messages. While > this may not be a problem for RFC2822 or MIME header fields > (it is not worse than original header field being preserved), > the net result is that such Downgraded: headers can appear in > a wrong message, i.e. not the one which was originally > downgraded. This, on the first glance, can be a real problem > for Envelope-Downgraded headers, e.g. MAIL FROM address, is > it? E.g. could it cause P1 sender of a message being replaced > with original sender while upgrading the envelope information? > Is there such thing as envelope information upgrade? If not, > then why bother preserving such information (other than as > another trace field)? > > I personally think that it can be acceptable to define the > downgrade process as not reversible, e.g. that downgrade can > just drop the UTF8 address and use alt-addresses instead. > There should be no such thing as upgrade, the downgraded > message should be handled as normal pre-EAI message with > appropriate information encoded in a backwards-compatible > fashion. What are disadvantages of this approach? I assume we > want the downgrade mechanism to be less and less necessary > over time when everybody upgrades to support EAI. > > My another feeling is that unknown header fields downgrade can > just use RFC2047 encoding by default. The reasoning is that no > header fields defined before EAI are supposed to contain UTF-8 > and no downgrade should be necessary for such header fields, > except those specifically supported by EAI (such as Subject, > address header fields). Of course new header fields can be > defined after EAI is introduced which may want to take > advantage of UTF8. In such case they either should be defined > as unstructured headers for which default downgrade mechanism > (RFC2047) is sufficient, or those are new structured headers. > For new structured headers EAI could define a way to identify > such header for EAI downgrade purposes and a common open > format (like the one defined for a Content-Disposition header > with parameters) with provisions how to identify parts which > potentially can contain UTF8 and how to downgrade them > (RFC2231?). > > I.e. then downgrade process could be defined as dropping > redundant information (UTF8 addresses) and orderly encoding of > remaining UTF8 information. No upgrade process should be > defined. > > Sorry if I am bringing back something which was already > debated and rejected, I still have a lot to catch up. > > Thanks, > Yuri _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 04:24:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7N-0006WL-6n; Wed, 11 Apr 2007 04:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7L-0006OW-82 for ima@ietf.org; Wed, 11 Apr 2007 04:23:52 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbY7J-0008SN-G5 for ima@ietf.org; Wed, 11 Apr 2007 04:23:51 -0400 Received: (eyou send program); Wed, 11 Apr 2007 16:23:16 +0800 Message-ID: <376279796.01367@cnnic.cn> Received: from 218.241.111.9 by mail.cnnic.cn with HTTP; Wed, 11 Apr 2007 16:23:16 +0800 X-WebMAIL-MUA: [218.241.111.9] From: "MAO Wei" To: Harald@cnnic.cn, Tveit@cnnic.cn, Alvestrand@cnnic.cn, harald@alvestrand.no, ima@ietf.org, ima@ietf.org Date: Wed, 11 Apr 2007 16:23:16 +0800 X-Priority: 3 Subject: Re: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM Content-Type: text/plain X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: MAO Wei List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Harald Tveit Alvestrand" To: Sent: Monday, April 09, 2007 9:23 PM Subject: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM > > B - I support NOT adding HDR=UTF8 > - Yangwoo Ko > - John Klensin > - Yao Jiankang > - Jeff Yeh > - Martin Duerst > - Harald Alvestrand +1 count me. MAO Wei _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 04:24:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7N-0006WB-3L; Wed, 11 Apr 2007 04:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7L-0006OV-7x for ima@ietf.org; Wed, 11 Apr 2007 04:23:52 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbY7J-0008SO-G5 for ima@ietf.org; Wed, 11 Apr 2007 04:23:51 -0400 Received: (eyou send program); Wed, 11 Apr 2007 16:23:16 +0800 Message-ID: <376279796.01367@cnnic.cn> Received: from 218.241.111.9 by mail.cnnic.cn with HTTP; Wed, 11 Apr 2007 16:23:16 +0800 X-WebMAIL-MUA: [218.241.111.9] From: "MAO Wei" To: Harald@cnnic.cn, Tveit@cnnic.cn, Alvestrand@cnnic.cn, harald@alvestrand.no, ima@ietf.org, ima@ietf.org Date: Wed, 11 Apr 2007 16:23:16 +0800 X-Priority: 3 Subject: Re: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM Content-Type: text/plain X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: MAO Wei List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Harald Tveit From ima-bounces@ietf.org Wed Apr 11 04:24:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7N-0006WL-6n; Wed, 11 Apr 2007 04:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7L-0006OW-82 for ima@ietf.org; Wed, 11 Apr 2007 04:23:52 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbY7J-0008SN-G5 for ima@ietf.org; Wed, 11 Apr 2007 04:23:51 -0400 Received: (eyou send program); Wed, 11 Apr 2007 16:23:16 +0800 Message-ID: <376279796.01367@cnnic.cn> Received: from 218.241.111.9 by mail.cnnic.cn with HTTP; Wed, 11 Apr 2007 16:23:16 +0800 X-WebMAIL-MUA: [218.241.111.9] From: "MAO Wei" To: Harald@cnnic.cn, Tveit@cnnic.cn, Alvestrand@cnnic.cn, harald@alvestrand.no, ima@ietf.org, ima@ietf.org Date: Wed, 11 Apr 2007 16:23:16 +0800 X-Priority: 3 Subject: Re: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM Content-Type: text/plain X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: MAO Wei List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Harald Tveit Alvestrand" To: Sent: Monday, April 09, 2007 9:23 PM Subject: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM > > B - I support NOT adding HDR=UTF8 > - Yangwoo Ko > - John Klensin > - Yao Jiankang > - Jeff Yeh > - Martin Duerst > - Harald Alvestrand +1 count me. MAO Wei _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 04:24:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7N-0006WB-3L; Wed, 11 Apr 2007 04:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7L-0006OV-7x for ima@ietf.org; Wed, 11 Apr 2007 04:23:52 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbY7J-0008SO-G5 for ima@ietf.org; Wed, 11 Apr 2007 04:23:51 -0400 Received: (eyou send program); Wed, 11 Apr 2007 16:23:16 +0800 Message-ID: <376279796.01367@cnnic.cn> Received: from 218.241.111.9 by mail.cnnic.cn with HTTP; Wed, 11 Apr 2007 16:23:16 +0800 X-WebMAIL-MUA: [218.241.111.9] From: "MAO Wei" To: Harald@cnnic.cn, Tveit@cnnic.cn, Alvestrand@cnnic.cn, harald@alvestrand.no, ima@ietf.org, ima@ietf.org Date: Wed, 11 Apr 2007 16:23:16 +0800 X-Priority: 3 Subject: Re: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM Content-Type: text/plain X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: MAO Wei List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Harald Tveit Alvestrand" To: Sent: Monday, April 09, 2007 9:23 PM Subject: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM > > B - I support NOT adding HDR=UTF8 > - Yangwoo Ko > - John Klensin > - Yao Jiankang > - Jeff Yeh > - Martin Duerst > - Harald Alvestrand +1 count me. MAO Wei _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima Alvestrand" To: Sent: Monday, April 09, 2007 9:23 PM Subject: [EAI] POLL RESULT (preliminary): HDR= extension on MAIL FROM > > B - I support NOT adding HDR=UTF8 > - Yangwoo Ko > - John Klensin > - Yao Jiankang > - Jeff Yeh > - Martin Duerst > - Harald Alvestrand +1 count me. MAO Wei _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 13:03:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbgE9-0001br-Eq; Wed, 11 Apr 2007 13:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbgE8-0001bk-0v for ima@ietf.org; Wed, 11 Apr 2007 13:03:24 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbgE6-0003di-FE for ima@ietf.org; Wed, 11 Apr 2007 13:03:24 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbgDx-0005p9-2N for ima@ietf.org; Wed, 11 Apr 2007 19:03:13 +0200 Received: from d254077.dialin.hansenet.de ([80.171.254.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2007 19:03:13 +0200 Received: from nobody by d254077.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2007 19:03:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 11 Apr 2007 19:00:19 +0200 Organization: Lines: 87 Message-ID: <461D1423.3956@xyzzy.claranet.de> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> 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: d254077.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [EAI] Re: downgrading target header list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org fujiwara@jprs.co.jp wrote: > Encapsulating undefined headers (including all X-headers) is > reasonable? As long as you don't use 2047 / 2231 on "words", because you don't know what a "word" is without knowing the structure, as in the ... xxx: (=?ascii*fr?Q?no?= encoded =?ascii*en?Q?words?=) ...example, if xxx header field bodies are unstructured (or allow no comments). > Which downgrading method is suitable for Unknown Content-* > header, (7) Encapsulating into Downgraded or (5) RFC 2231 ? None, Content-* MUST be ASCII for MIME Version 1.0, and the old pre-MIME Content-Type was also ASCII. > From: Sender: Reply-To: To: Cc: Bcc: Bcc should be empty... > Resent-From: Resent-Sender: Resent-To: Resent-Cc: ...or add Resent-Bcc: (what crap, sigh). > Resent-Reply-To: Strike that, it doesn't exist. > Disposition-Notification-To: Can somebody _please_ start the next "decruft experiment" ? > 3. text header > -> encode by RFC 2047 > Subject: > Comments: > Keywords: Keywords isn't unstructured, can have a comment, see above. > 4. trace header > -> Remove uFor clause > Received: Received-SPF, DKIM-Signature. > 5. MIME headers (with UTF-8 string) Reject as bogus, or encode as unstructured garbage (like subject). > 6. URI headers > -> encode by RFC 3987 > List-Archive: > List-Help: > List-Owner: > List-Post: > List-Subscribe: > List-Unsubscribe: Archived-At (will be an RFC before Downgrade, I hope). I think there can be comments in List-*. Add "List-Id:" to your second section. > 7. Unknown/Undefined headers > -> encapsulate into Downgraded header > X-headers: > other unstructured headers: > other structured headers: IMO that kills it, structured and unstructured MUST NOT be in the same group. For X-anything you can say "who cares, let's assume it's unstructured like a subject", but unknown + structured is a showstopper for any "2047-encode 'words'" strategy, because you can't tell what a 'word' is. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 14:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbhRQ-0006lq-Js; Wed, 11 Apr 2007 14:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbhRK-0006ZW-96 for ima@ietf.org; Wed, 11 Apr 2007 14:21:09 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbhRF-0001ql-P9 for ima@ietf.org; Wed, 11 Apr 2007 14:21:06 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 11 Apr 2007 11:21:01 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi; Wed, 11 Apr 2007 11:21:00 -0700 From: Yuri Inglikov To: 'John C Klensin' Date: Wed, 11 Apr 2007 11:20:27 -0700 Subject: RE: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Thread-Topic: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Thread-Index: Acd8BDaIx0rigvVLQpy2D4GuHnxXKQAA3OFg Message-ID: References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.112210.74734503.fujiwara@jprs.co.jp> <27976DE0DDBDFCAD4DACB7B7@p3.JCK.COM> In-Reply-To: <27976DE0DDBDFCAD4DACB7B7@p3.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {B6E39A0C-02C8-4240-BE99-1CC61DCE5DD4} x-cr-hashedpuzzle: CmQ/ Ep79 FOpX F7eb Ggob KWUA MERY NEgG PK0d Ptjl P3Qw Qhqk RdWn TJiu TQg2 UEWD; 2; aQBtAGEAQABpAGUAdABmAC4AbwByAGcAOwBrAGwAZQBuAHMAaQBuAEAAagBjAGsALgBjAG8AbQA=; Sosha1_v1; 7; {B6E39A0C-02C8-4240-BE99-1CC61DCE5DD4}; eQB1AHIAaQAuAGkAbgBnAGwAaQBrAG8AdgBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A; Wed, 11 Apr 2007 18:20:27 GMT; UgBFADoAIABbAEUAQQBJAF0AIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBmACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGUAYQBpAC0AZABvAHcAbgBnAHIAYQBkAGUALQAwADMALgB0AHgAdAA= acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Thank you. I think that even if WG decides to standardize the most complex solution #3= , which seems to be the direction, then #2 and #1 could still be left legal= and the choice left to implementers. BTW apparently #1 is very close (in sense of the effect to end user) to a "= failure to downgrade", i.e. bouncing the message when there is no alt-addre= ss to downgrade to - some addresses are just effectively unreachable. Logic= al extension to that is a "failure to downgrade" when MTA decides to not im= plement downgrade. As for #2, somebody can probably decide that the name "gateway" versus "MTA= " is not a big deal and implement this solution anyway? Yuri -----Original Message----- From: John C Klensin [mailto:klensin@jck.com] Sent: Tuesday, April 10, 2007 11:39 PM To: Yuri Inglikov Cc: ima@ietf.org Subject: RE: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt Yuri, This is a personal perspective. I hope that the authors of the downgrade draft, and others, will respond to you also. I think you have captured the key issues here. I believe that there are three, philosophically different, ways to look at the problem for which the downgrade draft is a proposed solution. Each one has implications for, e.g.., likely rate of deployment and quality of interworking during the transition period. There is not complete agreement about what those implications might be, i.e., different people have different theories about which approach is most likely to lead to rapid deployment of the EAI features. These are listed in order of increasing complexity, not preference. (1) No downgrading at all. An address is an address. Addresses being unreachable are old news and, while I might want to tell a correspondent to use a hotmail address if my normal one doesn't seem to be working, I do that in the body of the message and allow the sending user to deal with it, rather than requiring additional syntax to express the alternatives. In this model, if a UTF-8 address cannot be reached, the message just gets rejected or returned. Problems arise when the UTF-8 address is backward-pointing (so there is no place for an ASCII-only system to send a reply or delivery status notification) or if the envelope is all-ASCII but the message headers contain UTF-8 material. For the second of these cases, the worst-case problem is only constructing a DSN, which is inherently less general than the problem of constructing a machine-intelligible downgraded message. (2) Downgrading only. Here, the downgrading operation is treated as a one-way gateway transformation, with the target being to create as near an approximation to the original message as possible in all-ASCII form. Other than trace information that would indicate that the transformation occurred, there would be no serious attempt to preserve pre-downgrade information that couldn't be cleanly expressed in encoded words, no attempt to preserve digital signatures, etc. Probably there would be no new headers, eliminating the problems you identify. However, an internationalized client sitting behind an ASCII-only system or relay would see only the ASCII addresses and have no mechanism to generate a reply to the UTF-8 address (unless there were comments in the body text), even if it has a UTF8SMTP-capable path in the reverse direction. (3) Downgrading with upgrade capability at the endpoints. If one thinks it is important to permit a UTF8SMTP-capable mail reader or MUA at the receiving end to see an approximation of the original message, headers, and addresses, despite downgrading on the path to it, then one needs to, somehow, preserve most of the original information -- much more information than is required by (2). How far one wants to go, and how far one can go, is so far still an unresolved question, with trying to preserve or restore the integrity of envelope information and of digital signatures over header fields as the most stringent possible targets. Clearly, the downgrade document reflects the third view. If one were to adopt one of the other views instead, the specifications would be quite different. regards, john (2) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 15:19:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbiLJ-0002eK-FZ; Wed, 11 Apr 2007 15:18:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbiLH-0002e7-0l for ima@ietf.org; Wed, 11 Apr 2007 15:18:55 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbiLC-0000cD-D1 for ima@ietf.org; Wed, 11 Apr 2007 15:18:54 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3*clerew&man^ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461d3497.43d.4 for ima@ietf.org; Wed, 11 Apr 2007 20:18:47 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3BJIjpG019376 for ; Wed, 11 Apr 2007 20:18:46 +0100 (BST) To: IMA Subject: Re: downgrading target header list (Re: [EAI] Discussion of draft-ietf-eai-downgrade-03.txt) References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> Message-ID: Date: Wed, 11 Apr 2007 20:18:45 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20070411.153632.71104159.fujiwara@jprs.co.jp> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 11 Apr 2007 07:36:32 +0100, wrote: >> From: John C Klensin >> Certainly not for "all X-headers" since one has no idea what is >> in them. This strikes me as dangerous and I would prefer that >> we be very conservative about it. > > Encapsulating undefined headers (including all X-headers) is reasonable? The general opinion is that X-headers are to be considered 'unstructured'. Certainly, RFC 2047 gives Carte Blanche to encode them, so we might as well follow that lead. Of course, unrecognised headers are quite a different thing (and RFC 2047 signally fails to deal with them). If you could find the RFC that defines them, you might well find that they had a structure, and that structure might even have places where UTF-8 might be sensible. But all that software that does not recognize them can do is to use a Downgraded header, and hope that whoever eventually upgrades them can do something useful with them. > > I listed headers from RFC 4021. (There may be some omission.) > Then, I categorized 7 rewriting header methods. Yes, I think your list is more or less correct. > 1. Originator and destination addresses headers > -> preserve original header into Downgraded: header > and rewrite utf8-addr-spec as alt-addr > (comment encoded by 2047) And you could add to your list that it is acceptable to use the same technique on any header that might be defined in the future and that involves es, even though some software might only be able to use the default Downgraded header on them. > 3. text header > -> encode by RFC 2047 Again, add a general permission for any header that is defined as "unstructured" (the Netnews Summary and Organization headers, for example). > 5. MIME headers (with UTF-8 string) > -> encode by RFC 2231 > > Content-Type: > Content-Transfer-Encoding: > Content-Description: AFAIK, all the currently defined Content-* headers are safe under this (i.e. they either have s, or UTF-8 is inappropriate within them (apart from any s). Furtunately, many existing MUAs which have already implemented 2231 will upgrade them as appropriate. But note also that many newer RFCs are begining to use s in other situations (e.g. the new Injection-Info in Netnews). But AFAICS it is always safe to use 2231 on them. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 11 15:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbipy-0000Ct-FE; Wed, 11 Apr 2007 15:50:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbipt-00006J-4R; Wed, 11 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hbips-0005tJ-OZ; Wed, 11 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id ABD8F2ACBC; Wed, 11 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HbipO-0000Nj-FH; Wed, 11 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-05.txt Pages : 19 Date : 2007-4-11 This document specifies the use of SMTP extension for internationalized email address delivery. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-11111431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-11111431.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Wed Apr 11 19:52:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbmbu-00085Q-DD; Wed, 11 Apr 2007 19:52:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbmbt-00085I-EO for ima@ietf.org; Wed, 11 Apr 2007 19:52:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hbmbs-0001QS-01 for ima@ietf.org; Wed, 11 Apr 2007 19:52:21 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3BNqFnL020733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 16:52:16 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-212.qualcomm.com [10.50.16.212]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3BNqEYY029827; Wed, 11 Apr 2007 16:52:15 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 11 Apr 2007 16:51:54 -0700 To: "Charles Lindsey" , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] Discussion of draft-ietf-eai-utf8headers-03/04 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org [[ sorry for the late reply, I just noticed that this message has been in my Out mailbox for some time and was never sent ]] At 4:00 PM +0000 3/20/07, Charles Lindsey wrote: > You also need an example such as > non-ASCII@non-ASCII > since we agreed that a pure without "<...>" would > still be allowed, and your syntax shows it. Did we? I don't recall this. Can you remind me when we did so? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is always an easy solution to every human problem -- neat, plausible, and wrong. --H.L. Mencken _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 12 00:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbqes-00045e-Dj; Thu, 12 Apr 2007 00:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbqeq-00045Y-Si for ima@ietf.org; Thu, 12 Apr 2007 00:11:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbqen-0006tS-Bs for ima@ietf.org; Thu, 12 Apr 2007 00:11:40 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hbqek-000FNv-7Z; Thu, 12 Apr 2007 00:11:34 -0400 Date: Thu, 12 Apr 2007 00:10:18 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: downgrading target header list Message-ID: <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> In-Reply-To: <461D1423.3956@xyzzy.claranet.de> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (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: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Some small possible disagreements... --On Wednesday, 11 April, 2007 19:00 +0200 Frank Ellermann wrote: > fujiwara@jprs.co.jp wrote: > >> Encapsulating undefined headers (including all X-headers) is >> reasonable? > > As long as you don't use 2047 / 2231 on "words", because you > don't know what a "word" is without knowing the structure, as > in the ... > > xxx: (=?ascii*fr?Q?no?= encoded =?ascii*en?Q?words?=) > > ...example, if xxx header field bodies are unstructured (or > allow no comments). Right. The good news is that we've made other requirements that anything that would need to be downgraded must be Unicode encoded in UTF-8. So, if it is absolutely clear in the text of the I-D how a "Downgraded" header is structured, you could use one of the techniques discussed in draft-klensin-unicode-escapes without much (or any) risk. >> Which downgrading method is suitable for Unknown Content-* >> header, (7) Encapsulating into Downgraded or (5) RFC 2231 ? > > None, Content-* MUST be ASCII for MIME Version 1.0, and the > old pre-MIME Content-Type was also ASCII. Almost true. The only MIME headers that can have non-ASCII strings in them are those that can contain non-ASCII text if our "utf8-headers" document says so. For example, consider local system pathnames on a Unicode-based file system, specified in a "name=" parameter, which might well be in UTF-8. My personal ruthless instinct is that it is better to drop these things than to encode them and risk fouling them up, but there is as good a case for a Downgraded header for them as for just about anything else. >... >> Disposition-Notification-To: > > Can somebody _please_ start the next "decruft experiment" ? Please raise this in the context of RFC2822bis (assuming that draft ever gets posted). >> 4. trace header >> -> Remove uFor clause > >> Received: > > Received-SPF, DKIM-Signature. Apologies for being rigid about this, but I'm unaware of any published RFCs that specify non-ASCII header material for either of these. If the header lines contain only ASCII text, they don't need to be downgraded. >> 5. MIME headers (with UTF-8 string) > > Reject as bogus, or encode as unstructured garbage (like > subject). See discussion of Content-* above. >... > Archived-At (will be an RFC before Downgrade, I hope). I think > there can be comments in List-*. Add "List-Id:" to your second > section. This identifies a problem with "downgrade" that we at least need to identify. New headers are added and standardized from time to time. We are going to need a general theory about how to deal with them. That theory might be expressed as a requirement on standardization of new headers, or their registrations, that they specify how they should be downgraded. I don't think it is necessary to work this out in a comprehensive way for this round of experimental RFCs, but there should at least be a placeholder noting the issue. >> 7. Unknown/Undefined headers >> -> encapsulate into Downgraded header > >> X-headers: >> other unstructured headers: >> other structured headers: > > IMO that kills it, structured and unstructured MUST NOT be in > the same group. For X-anything you can say "who cares, let's > assume it's unstructured like a subject", but unknown + > structured is a showstopper for any "2047-encode 'words'" > strategy, because you can't tell what a 'word' is. Yes, I think that is correct. See comments above about the possibility of simply using escaped Unicode. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 12 07:36:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbxbf-0002j1-GR; Thu, 12 Apr 2007 07:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbxbd-0002ir-PC for ima@ietf.org; Thu, 12 Apr 2007 07:36:49 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbxbc-0001Tv-72 for ima@ietf.org; Thu, 12 Apr 2007 07:36:49 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3*clerew$man*ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461e19ce.1804f.1e for ima@ietf.org; Thu, 12 Apr 2007 12:36:46 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3CBakKY000346 for ; Thu, 12 Apr 2007 12:36:47 +0100 (BST) Subject: Fwd: Re: [EAI] Discussion of draft-ietf-eai-utf8headers-03/04 References: Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 12 Apr 2007 12:36:45 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 12 Apr 2007 00:51:54 +0100, Randall Gellens wrote: > [[ sorry for the late reply, I just noticed that this message has been > in my Out mailbox for some time and was never sent ]] > > At 4:00 PM +0000 3/20/07, Charles Lindsey wrote: > >> You also need an example such as >> non-ASCII@non-ASCII >> since we agreed that a pure without "<...>" would >> still be allowed, and your syntax shows it. > > Did we? I don't recall this. Can you remind me when we did so? There was a very long thread entitled "[EAI] other thought about >" which started on 29th January, and went all around this subject. There were some possible ambiguities exhibited which were shown to be safe if the syntax of RFC 2822 was followed (though a few agents parsed them wrongly). There was also a bug identified in the ABNF of Utf8headers which has since been fixed. And there were various other Red Herrings that got discussed. But my interpretation of the outcome was that the consensus was to allow To: non-ASCII@non-ASCII Only yourself (and possibly Soobok) appeared to be against. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 12 09:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbzC0-0007A1-Su; Thu, 12 Apr 2007 09:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbzC0-00079v-D8 for ima@ietf.org; Thu, 12 Apr 2007 09:18:28 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbzBz-00059K-GK for ima@ietf.org; Thu, 12 Apr 2007 09:18:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbzBo-0003DL-PC for ima@ietf.org; Thu, 12 Apr 2007 15:18:16 +0200 Received: from d253245.dialin.hansenet.de ([80.171.253.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Apr 2007 15:18:16 +0200 Received: from nobody by d253245.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Apr 2007 15:18:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 12 Apr 2007 15:09:33 +0200 Organization: Lines: 159 Message-ID: <461E2F8D.4C1B@xyzzy.claranet.de> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253245.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [EAI] Re: downgrading target header list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > The good news is that we've made other requirements that > anything that would need to be downgraded must be Unicode > encoded in UTF-8. So, if it is absolutely clear in the > text of the I-D how a "Downgraded" header is structured, > you could use one of the techniques discussed in > draft-klensin-unicode-escapes without much (or any) risk. I'm not sure, it could run into similar problems like 2047- encoding something that already is (in parts) 2047-encoded. One of the techniques discussed in your I-D is to use NCRs. I know that you don't like them, but they're handy for a quick example (using Latin-1 instead of UTF-8 here): | Subject:   ist f=FCr bl=F6de Brwser besser als   Downgrading the UTF-8 version of this subject with NCRs would result in an ASCII string like this: |   ist für blöde Browser besser als   When that's "upgraded" later the literal   would be replaced by UTF-8 for u+00A0, while the   survives as is, the "upgraded" subject would be displayed as: | Subject:   ist f=FCr bl=F6de Browser besser als =A0 IMO we need a new technique that can completely ignore the structure or not of the header field, and the existence of anything within the header field using a similar technique. Or we say (for the same hex. NCR example) that any original "&" has to be encoded as & This would result in: | &#160; ist für blöde Browser besser als &#xA0; As you said we'd be in a hopeless situation if there are any non-ASCII octets not belonging to a valid UTF-8. For that case we'd need a technique encoding "raw" octets, or in other words B64-encode the complete header field body, no matter if it's proper UTF-8 or not, structured or not, or folded or not. We'd have to introduce our own folding of course, 1000 B64-characters per folded line or similar. > Almost true. The only MIME headers that can have non-ASCII > strings in them are those that can contain non-ASCII text > if our "utf8-headers" document says so. IMO it can't. What about a multipart Content-Type with a weird UTF-8 comment, would that result in the following raw example ? -- good boundary Downgraded: Content-Type: Base-64(UTF-8 header field body) -- lost boundary =2E.. -- lost boundary -- -- good boundary -- The "lost boundary" would be hidden within whatever the Downgrade mechanism did. The former multipart would be a single part without MIME header fields. Maybe a smart Downgrade mechanism could fix that somehow, preserving a copy of the old Content-Type without its UTF-8 comment. > For example, consider local system pathnames on a > Unicode-based file system, specified in a > "name=3D" parameter, which might well be in UTF-8. Yes, I know why Charles wants it. IMO adding "MIME 2.0" (explicitly or implicitly) to the EAI experiment is too much, email addresses (as the name EAI says) are already complex enough for the moment. If some folks really "must" have UTF-8 in filenames and comments of Content-* they can manage this with RFC 2231, at least until we know how the EAI core works without this additional feature. This MIME 2.0 idea scares me. It's about as attractive as integrating 4408 into 2821bis, or Bruce's great plan to integrate MIME into 2822bis. > My personal ruthless instinct is that it is better to > drop these things than to encode them and risk fouling > them up, but there is as good a case for a Downgraded > header for them as for just about anything else. My instinct is to leave MIME 1.0 Content-* alone. All these "look into the body and parse its MIME structure" concepts make me nervous. I'd prefer to ignore all 7BIT routes as irrelevant for the purposes of EAI. We should just assume that 8BITMIME is the norm, and where reality disagrees it's an 8BITMIME problem, not a job for EAI. >>> Disposition-Notification-To: >> Can somebody _please_ start the next "decruft experiment" ? > Please raise this in the context of RFC2822bis Diposition-Notification-To would be 3798bis, also used in 4356. The new Jabber-ID header field is also interesting, it's in essence an IRI in URI format, like Archived-At. Jabber-ID is also no RFC yet, but it might be ready soon. >>> Received: >> Received-SPF, DKIM-Signature. > Apologies for being rigid about this, but I'm unaware of > any published RFCs that specify non-ASCII header material > for either of these. Charles wants UTF-8 comments everywhere. For Received-SPF there will be an update to allow a new UTF8SMTP MAIL FROM address, and in theory also a message/utf-8 PRA if somebody cares to update 4405 and 4406. > If the header lines contain only ASCII text, they don't > need to be downgraded. These trace header fields are added in transit, of course only ASCII on 8BITMIME routes. But for UTF8SMTP routes they will have to support UTF8SMTP addresses, and a mailer trying to downgrade them has then to know how. One of the reasons why I prefer a downgrade mechanism that can ignore the syntax of obscure header fields. > This identifies a problem with "downgrade" that we at least > need to identify. New headers are added and standardized > from time to time. We are going to need a general theory > about how to deal with them. Yes, my theory is a "syntax agnostic downgrade mechanism". > That theory might be expressed as a requirement on = > standardization of new headers, or their registrations, > that they specify how they should be downgraded. Possible, but too late for already existing header fields, or for the two "ready for IRI" candidates mentioned above. Maybe we could mix it: For some well-known header fields offer a "smart" downgrade mechanism, like 3987-IRI-to-URI in the case of Archived-At (only an example, of course it's not important enough to get a non-default handling). And for most header fields a "B64-everything" mechanism. > there should at least be a placeholder noting the issue. Yes. We could start with "B64-everything" and then add the most important exceptions when they are identified. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 12 10:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbzqo-0006Ar-BX; Thu, 12 Apr 2007 10:00:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbzqm-0006Am-Nm for ima@ietf.org; Thu, 12 Apr 2007 10:00:36 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hbzqj-0004N0-Mx for ima@ietf.org; Thu, 12 Apr 2007 10:00:36 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hbzqi-000LSB-9K; Thu, 12 Apr 2007 10:00:32 -0400 Date: Thu, 12 Apr 2007 10:00:30 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: downgrading target header list Message-ID: In-Reply-To: <461E2F8D.4C1B@xyzzy.claranet.de> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (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: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 12 April, 2007 15:09 +0200 Frank Ellermann wrote: > John C Klensin wrote: >=20 >> The good news is that we've made other requirements that >> anything that would need to be downgraded must be Unicode >> encoded in UTF-8. So, if it is absolutely clear in the >> text of the I-D how a "Downgraded" header is structured, >> you could use one of the techniques discussed in >> draft-klensin-unicode-escapes without much (or any) risk. >=20 > I'm not sure, it could run into similar problems like 2047- > encoding something that already is (in parts) 2047-encoded. >=20 > One of the techniques discussed in your I-D is to use NCRs. > I know that you don't like them, but they're handy for a > quick example (using Latin-1 instead of UTF-8 here): >=20 > | Subject:   ist f=C3=BCr bl=C3=B6de Brwser besser als =   >=20 > Downgrading the UTF-8 version of this subject with NCRs > would result in an ASCII string like this: >=20 > |   ist für blöde Browser besser als   >=20 > When that's "upgraded" later the literal   would be > replaced by UTF-8 for u+00A0, while the   survives > as is, the "upgraded" subject would be displayed as: >=20 > | Subject:   ist f=C3=BCr bl=C3=B6de Browser besser als = =C2=A0 >=20 > IMO we need a new technique that can completely ignore the > structure or not of the header field, and the existence of > anything within the header field using a similar technique. I agree. Unfortunately, we have so many different ways of encoding things floating around that there is a great deal of reluctance (at least by me) for creating a new one. Worse, we have to optimize for two different types of MUA endpoints. One is a legacy MUA that has no knowledge at all of this stuff. It is going to have to display the escaped form and hope that users can make sense of it. It was concern for those sorts of MUAs that brought us Quoted-Printable which many of us consider to have been largely a failure. The other is an MUA that knows all about the internationalized forms but that is on the far side of something that had to downgrade. It probably will want to decode (or "upgrade") later. My comment about knowing things are in UTF-8 was addressed largely toward the latter, but it suggests that probably a downgrade procedure that encounters a coded-word that was coded in terms of ISO 8859-1 should convert it to a coded-word (or some other encoding) based on Unicode. But, in the general case, that is impossible because it means that the downgrading MTA has to have conversion tables from Just About Everything to Unicode.=20 I think that means that the downgrading procedure needs a way to clearly distinguish between things that were already encoded but that it does not know how to encode/recode and things that it encodes. There are lots of ways to do that, but they tend to require some knowledge of what is/was going on and to be ugly enough, or clearly encodings enough, to be very hard on those legacy systems and their users. For example, if our main interest was in upgradability and we didn't care about much of anything else, the value of a Downgraded header field would be a Base64 string that contains, in encoded form, _exactly_ what appeared in the original header. That would permit unambiguous restoration, but would turn the original header information to trash for anyone who didn't have an upgraded receiving MUA. =20 > Or we say (for the same hex. NCR example) that any original > "&" has to be encoded as & This would result in: >=20 > | &#160; ist für blöde Browser besser als > &#xA0; You are moving closer to the above, i.e., making the string completely unintelligible in the interests of accurate coding and decoding.=20 > As you said we'd be in a hopeless situation if there are > any non-ASCII octets not belonging to a valid UTF-8. For > that case we'd need a technique encoding "raw" octets, or > in other words B64-encode the complete header field body, > no matter if it's proper UTF-8 or not, structured or not, > or folded or not. We'd have to introduce our own folding > of course, 1000 B64-characters per folded line or similar. Right. =20 >> Almost true. The only MIME headers that can have non-ASCII >> strings in them are those that can contain non-ASCII text >> if our "utf8-headers" document says so. >=20 > IMO it can't. What about a multipart Content-Type with a > weird UTF-8 comment, would that result in the following raw > example ? >=20 > -- good boundary > Downgraded: Content-Type: Base-64(UTF-8 header field body) >=20 > -- lost boundary > ... > -- lost boundary -- > -- good boundary -- >=20 > The "lost boundary" would be hidden within whatever the > Downgrade mechanism did. The former multipart would be > a single part without MIME header fields. Maybe a smart > Downgrade mechanism could fix that somehow, preserving a > copy of the old Content-Type without its UTF-8 comment. Right. Very good example. >> For example, consider local system pathnames on a >> Unicode-based file system, specified in a >> "name=3D" parameter, which might well be in UTF-8. >=20 > Yes, I know why Charles wants it. IMO adding "MIME 2.0" > (explicitly or implicitly) to the EAI experiment is too > much, email addresses (as the name EAI says) are already > complex enough for the moment. I agree, fwiw. But that leaves me without knowing quite what to do with those file names other than drop them. I would happily do that since I've believe the parameter was a bad idea from the beginning, but I know I'm in a tiny minority about that. > If some folks really "must" have UTF-8 in filenames and > comments of Content-* they can manage this with RFC 2231, > at least until we know how the EAI core works without > this additional feature. Makes sense to me, but see above. > This MIME 2.0 idea scares me. It's about as attractive > as integrating 4408 into 2821bis, or Bruce's great plan > to integrate MIME into 2822bis. When I suggested it, I intended it as a discussion-stopper. Most of the people who understand its implications got that, in one form or another. For those who are surprised by my saying that (a list that almost certainly does not include you, Frank), the problem is that the "MIME-version" header has become noise because we had no theory about how versioning mechanism would work going forward. So we have systems that don't check for its presence at all, systems that check for its presence and then ignore it, and systems that might actually notice if the version number had changed. Of the latter, some would assume that 2.0 was at least upward compatible with 1.0 and others would assume that it meant the message was completely incompatible, i.e., that they couldn't even interpret Content-type headers unless they had 2.0 support. FWIW, that experience, and a few similar ones, are the reason I get so resistant when people propose parameters to support future extensions that they don't understand and can't predict and specify. >> My personal ruthless instinct is that it is better to >> drop these things than to encode them and risk fouling >> them up, but there is as good a case for a Downgraded >> header for them as for just about anything else. >=20 > My instinct is to leave MIME 1.0 Content-* alone. All > these "look into the body and parse its MIME structure" > concepts make me nervous. I'd prefer to ignore all 7BIT > routes as irrelevant for the purposes of EAI. We should > just assume that 8BITMIME is the norm, and where reality > disagrees it's an 8BITMIME problem, not a job for EAI. And that takes you down the slippery slope toward "if the address is not deliverable, or relay-able, exactly as written, the message should be rejected" with no more "downgrade" or "alternate address" plan than we have for non-deliverable mail with all-ASCII address and headers. While I will continue to try to figure out how to make downgrading work, you might find me waiting for you at the bottom of that slope. >>>> Disposition-Notification-To: >>> Can somebody _please_ start the next "decruft experiment" ? >=20 >> Please raise this in the context of RFC2822bis >=20 > Diposition-Notification-To would be 3798bis, also used in > 4356. The new Jabber-ID header field is also interesting, > it's in essence an IRI in URI format, like Archived-At. > Jabber-ID is also no RFC yet, but it might be ready soon. Ack. =20 >>>> Received: >>> Received-SPF, DKIM-Signature. >=20 >> Apologies for being rigid about this, but I'm unaware of >> any published RFCs that specify non-ASCII header material >> for either of these. >=20 > Charles wants UTF-8 comments everywhere. For Received-SPF > there will be an update to allow a new UTF8SMTP MAIL FROM > address, and in theory also a message/utf-8 PRA if somebody > cares to update 4405 and 4406. Well, first, I don't see how we can write specifications against an update that hasn't been written yet (or at least hasn't been reviewed by the wider community yet). Let me address the rest of this in a separate note. =20 >... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 12 17:33:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6ui-0005MW-Ck; Thu, 12 Apr 2007 17:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6ug-0005MR-MT for ima@ietf.org; Thu, 12 Apr 2007 17:33:06 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc6uf-0001Uk-Cj for ima@ietf.org; Thu, 12 Apr 2007 17:33:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hc6uU-0006ki-8B for ima@ietf.org; Thu, 12 Apr 2007 23:32:54 +0200 Received: from d253245.dialin.hansenet.de ([80.171.253.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Apr 2007 23:32:54 +0200 Received: from nobody by d253245.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Apr 2007 23:32:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 12 Apr 2007 23:31:24 +0200 Organization: Lines: 16 Message-ID: <461EA52C.1FCB@xyzzy.claranet.de> References: 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: d253245.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] Re: Fwd: Re: Discussion of draft-ietf-eai-utf8headers-03/04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > But my interpretation of the outcome was that the consensus was to allow > To: non-ASCII@non-ASCII > Only yourself (and possibly Soobok) appeared to be against. | (a) Any Mailbox or uMailbox (in the strict definitions | of 2821 and eai-smtpext, respectively) that contains | any non-ASCII character(s) MUST appear in brackets. Trying to reconstruct this I think Soobok said that it's not good enough, and I said that it's better than nothing. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 01:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEJd-0003xK-VC; Fri, 13 Apr 2007 01:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEJc-0003x6-Gj for ima@ietf.org; Fri, 13 Apr 2007 01:27:20 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEJZ-0001OR-1V for ima@ietf.org; Fri, 13 Apr 2007 01:27:20 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E3DAB259710; Fri, 13 Apr 2007 07:27:15 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00977-04; Fri, 13 Apr 2007 07:27:05 +0200 (CEST) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4336F259706; Fri, 13 Apr 2007 07:27:05 +0200 (CEST) Date: Thu, 12 Apr 2007 22:57:02 +0200 From: Harald Tveit Alvestrand To: John C Klensin , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: downgrading target header list Message-ID: <8A1A84C608F8BA12ABDA26B6@B50854F0A9192E8EC6CDA126> In-Reply-To: References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 12. april 2007 10:00 -0400 John C Klensin wrote: >> IMO we need a new technique that can completely ignore the >> structure or not of the header field, and the existence of >> anything within the header field using a similar technique. > > I agree. Unfortunately, we have so many different ways of > encoding things floating around that there is a great deal of > reluctance (at least by me) for creating a new one. Worse, we > have to optimize for two different types of MUA endpoints. One > is a legacy MUA that has no knowledge at all of this stuff. It > is going to have to display the escaped form and hope that users > can make sense of it. It was concern for those sorts of MUAs > that brought us Quoted-Printable which many of us consider to > have been largely a failure. The other is an MUA that knows > all about the internationalized forms but that is on the far > side of something that had to downgrade. It probably will want > to decode (or "upgrade") later. The work in "scenarios" has singularly failed to establish convincing more-than-transient scenarios where this functionality is needed. So (my personal technical opinion) we have very strong reasons to optimize for the first case. That means that the *result* of the transformation needs to either be ignorable or decodable by MUAs that don't support UTF8SMTP. In practice, I think that leaves us with "remove or encoded-word". Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 07:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKAt-0002oU-B1; Fri, 13 Apr 2007 07:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKAr-0002oH-NV for ima@ietf.org; Fri, 13 Apr 2007 07:42:41 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKAr-0008WS-AW for ima@ietf.org; Fri, 13 Apr 2007 07:42:41 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HcKAo-0009WS-UD; Fri, 13 Apr 2007 07:42:39 -0400 Date: Fri, 13 Apr 2007 07:36:23 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: downgrading target header list Message-ID: <3170C7418145783C264D7F18@p3.JCK.COM> In-Reply-To: <8A1A84C608F8BA12ABDA26B6@B50854F0A9192E8EC6CDA126> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> <8A1A84C608F8BA12ABDA26B6@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.7 (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 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 12 April, 2007 22:57 +0200 Harald Tveit Alvestrand wrote: > > > --On 12. april 2007 10:00 -0400 John C Klensin > wrote: > >>> IMO we need a new technique that can completely ignore the >>> structure or not of the header field, and the existence of >>> anything within the header field using a similar technique. >> >> I agree. Unfortunately, we have so many different ways of >> encoding things floating around that there is a great deal of >> reluctance (at least by me) for creating a new one. Worse, we >> have to optimize for two different types of MUA endpoints. >> One is a legacy MUA that has no knowledge at all of this >> stuff. It is going to have to display the escaped form and >> hope that users can make sense of it. It was concern for >> those sorts of MUAs that brought us Quoted-Printable which >> many of us consider to have been largely a failure. The >> other is an MUA that knows all about the internationalized >> forms but that is on the far side of something that had to >> downgrade. It probably will want to decode (or "upgrade") >> later. > > The work in "scenarios" has singularly failed to establish > convincing more-than-transient scenarios where this > functionality is needed. So (my personal technical opinion) we > have very strong reasons to optimize for the first case. > > That means that the *result* of the transformation needs to > either be ignorable or decodable by MUAs that don't support > UTF8SMTP. > > In practice, I think that leaves us with "remove or > encoded-word". Sadly, I agree. "Sadly", because I think it really implies that, if a downgrading system doesn't understand --explicitly recognize-- a header that contains non-ASCII information-- it probably needs to drop it. Anything else gets us involved with guessing what the information there is actually about and about what the receiving MUA may or may not know. A different way to look at this is that, while losing information is unattractive, it is better than risking changing material in a way that appears to retain information but actually alters it. If we try to preserve every possible bit in the expectation of later upgrading, we are likely to increase the number of situations in which messages are rejected or returned rather than downgraded. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 07:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKAt-0002ob-ED; Fri, 13 Apr 2007 07:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKAs-0002oP-Go for ima@ietf.org; Fri, 13 Apr 2007 07:42:42 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKAr-0008WQ-48 for ima@ietf.org; Fri, 13 Apr 2007 07:42:42 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HcKAo-0009WS-BR; Fri, 13 Apr 2007 07:42:38 -0400 Date: Fri, 13 Apr 2007 07:42:37 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: downgrading target header list Message-ID: <142931FE8D59C5F484183419@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (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 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 12 April, 2007 22:57 +0200 Harald Tveit Alvestrand wrote: > > > --On 12. april 2007 10:00 -0400 John C Klensin > wrote: > >>> IMO we need a new technique that can completely ignore the >>> structure or not of the header field, and the existence of >>> anything within the header field using a similar technique. >> >> I agree. Unfortunately, we have so many different ways of >> encoding things floating around that there is a great deal of >> reluctance (at least by me) for creating a new one. Worse, we >> have to optimize for two different types of MUA endpoints. >> One is a legacy MUA that has no knowledge at all of this >> stuff. It is going to have to display the escaped form and >> hope that users can make sense of it. It was concern for >> those sorts of MUAs that brought us Quoted-Printable which >> many of us consider to have been largely a failure. The >> other is an MUA that knows all about the internationalized >> forms but that is on the far side of something that had to >> downgrade. It probably will want to decode (or "upgrade") >> later. > > The work in "scenarios" has singularly failed to establish > convincing more-than-transient scenarios where this > functionality is needed. So (my personal technical opinion) we > have very strong reasons to optimize for the first case. > > That means that the *result* of the transformation needs to > either be ignorable or decodable by MUAs that don't support > UTF8SMTP. > > In practice, I think that leaves us with "remove or > encoded-word". Sadly, I agree. "Sadly", because I think it really implies that, if a downgrading system doesn't understand --explicitly recognize-- a header that contains non-ASCII information-- it probably needs to drop it. Anything else gets us involved with guessing what the information there is actually about and about what the receiving MUA may or may not know. A different way to look at this is that, while losing information is unattractive, it is better than risking changing material in a way that appears to retain information but actually alters it. If we try to preserve every possible bit in the expectation of later upgrading, we are likely to increase the number of situations in which messages are rejected or returned rather than downgraded. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 07:50:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKHw-0006xI-Ub; Fri, 13 Apr 2007 07:50:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKHv-0006x7-Qf for ima@ietf.org; Fri, 13 Apr 2007 07:49:59 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKHt-0002UH-4g for ima@ietf.org; Fri, 13 Apr 2007 07:49:59 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew^man#ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461f6e63.131d7.501 for ima@ietf.org; Fri, 13 Apr 2007 12:49:55 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3DBnsPD006166 for ; Fri, 13 Apr 2007 12:49:55 +0100 (BST) Date: Fri, 13 Apr 2007 12:49:53 +0100 To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <461E2F8D.4C1B@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 12 Apr 2007 14:09:33 +0100, Frank Ellermann wrote: > I'm not sure, it could run into similar problems like 2047- > encoding something that already is (in parts) 2047-encoded. > The proper thing to do in that case is for the downgrader to leave the already-encoded bits alone and to encode any UTF-8 bits in between them. You have to be careful with SPs where they occur, and we recemntly discussed some examples and it seems they could be managed by inserting "_"s at suitable places within the new encoded-words. But the downgrade document should probably include warnings about this. If you read RFC 2047 carefully, you should always be able to discover at least one valid way of doing it. > One of the techniques discussed in your I-D is to use NCRs. > I know that you don't like them, but they're handy for a > quick example (using Latin-1 instead of UTF-8 here): What is an NCR? If they are anything like the examples you give, then we are better off without them :-( . > IMO we need a new technique that can completely ignore the > structure or not of the header field, and the existence of > anything within the header field using a similar technique. That is what the Downgraded header is supposed to do. > As you said we'd be in a hopeless situation if there are > any non-ASCII octets not belonging to a valid UTF-8. Not supposed to happen, so Garbage-in Garbage-out. Actually, most systems will probably not notice them, and will simply encode the octets as if they were UTF-8, leaving the man at the other end to sort out the mess (as he would have had to do anyway even if it had not been downgraded). >> Almost true. The only MIME headers that can have non-ASCII >> strings in them are those that can contain non-ASCII text >> if our "utf8-headers" document says so. > > IMO it can't. What about a multipart Content-Type with a > weird UTF-8 comment, would that result in the following raw > example ? > > -- good boundary > Downgraded: Content-Type: Base-64(UTF-8 header field body) > > -- lost boundary > ... > -- lost boundary -- > -- good boundary -- If you want to give examples, then please give examples that are valid MIME, otherwise it is impossible to see what you are getting at. There is no such Content-Type as "Base-64". The only things that need to be considered with a Content-Type that occurs in front of some part of a Multipart are the following: -- good boundary Content-Type: text/plain; name="mañana" (mañana is Spanish) {Note, I am writing in Latin-1 here, but assume that UTF-8 was intended} That will downgrade to Content-Type: text/plain; name*=utf-8''ma%C3%B1ana (=?utf-8?Q?ma=C3=B1ana?= is Spanish) The was encoded according to RFC 2231, and the was encoded accoerding to RFC 2047. There was NO need to a Downgraded header. There is no possibility of any "--lost boundary". All existing agents should handle that header correctly, and existing MUAs should be able to display it in upgraded form if they implement 2231 and 2047 correctly and have the capability to display utf-8 (not that they are usually called upon to display body mime part headers). So it you think there is some other problem with Content-* headers, then please produce a valid example. >> That theory might be expressed as a requirement on >> standardization of new headers, or their registrations, >> that they specify how they should be downgraded. If anybody standardizes a new header, they are welcome to define a special downgrade mechanism for it (which may or may not include creating a Downgraded header as well). However, already written UTF8SMTP-capable agents will not instantly be able to use that downgrade mechanism, and will just replace it by a Downgraded header, so people had better not invent new headers where such existing agents would cause problems. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 08:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKeM-0004YB-3M; Fri, 13 Apr 2007 08:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKeL-0004Xy-Q0 for ima@ietf.org; Fri, 13 Apr 2007 08:13:09 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKeK-0001Ht-Gt for ima@ietf.org; Fri, 13 Apr 2007 08:13:09 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcKe3-0005uy-4a for ima@ietf.org; Fri, 13 Apr 2007 14:12:51 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 14:12:51 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 14:12:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 14:12:22 +0200 Organization: Lines: 8 Message-ID: <461F73A6.4AED@xyzzy.claranet.de> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> <8A1A84C608F8BA12ABDA26B6@B50854F0A9192E8EC6CDA126> 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: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] Re: downgrading target header list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > In practice, I think that leaves us with "remove or encoded-word". The point of my articles was that "2047 encoded word" is impossible. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 09:10:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLY5-0006sv-3M; Fri, 13 Apr 2007 09:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLY2-0006si-Id for ima@ietf.org; Fri, 13 Apr 2007 09:10:42 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLXz-0003NH-Ot for ima@ietf.org; Fri, 13 Apr 2007 09:10:42 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew*man^ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461f814e.176ff.73 for ima@ietf.org; Fri, 13 Apr 2007 14:10:38 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3DDAYTQ011028 for ; Fri, 13 Apr 2007 14:10:35 +0100 (BST) Subject: Re: [EAI] Re: downgrading target header list References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 13 Apr 2007 14:10:33 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 12 Apr 2007 15:00:30 +0100, John C Klensin wrote: > > My comment about knowing things are in UTF-8 was addressed > largely toward the latter, but it suggests that probably a > downgrade procedure that encounters a coded-word that was coded > in terms of ISO 8859-1 should convert it to a coded-word (or > some other encoding) based on Unicode. But, in the general > case, that is impossible because it means that the downgrading > MTA has to have conversion tables from Just About Everything to > Unicode. If an UTF8SMTP-comploiant MUA generates some headers with RFC 2047 encoding in is0-8859-* and some headers in raw UTF-8 (or even both in the same header), then that is rather stupid even if it is legitimate. However, I think it safest for a subsequent downgrading agent to leave it that way and just encode the raw utf-8 bits (see my reply to Frank). Not that re-encoding everything in UTF-8 would not necessarily be wrong, but it would probably lead to even more complications. > > I think that means that the downgrading procedure needs a way to > clearly distinguish between things that were already encoded but > that it does not know how to encode/recode and things that it > encodes. There are lots of ways to do that, but they tend to > require some knowledge of what is/was going on and to be ugly > enough, or clearly encodings enough, to be very hard on those > legacy systems and their users. For example, if our main > interest was in upgradability and we didn't care about much of > anything else, the value of a Downgraded header field would be a > Base64 string that contains, in encoded form, _exactly_ what > appeared in the original header. That would permit unambiguous > restoration, but would turn the original header information to > trash for anyone who didn't have an upgraded receiving MUA. I think we have to accept that it will not be possible for an upgrader to distinguish between stuff that was encoded by the originating MUA and stuff that was encoded by an intermediate downgrader. I am not sure that this matters, except possibly when some DKIM-like signatures were involved (and even those are probably solvable by some special canonicalization mechanism, but not until this WG has completed its primary tasks). And making the Downgraded header encode _exactly_ what was in the original header will lead to double encodings, which can be hideously difficult to disentangle, and so are better avoided. >> IMO it can't. What about a multipart Content-Type with a >> weird UTF-8 comment, would that result in the following raw >> example ? >> >> -- good boundary >> Downgraded: Content-Type: Base-64(UTF-8 header field body) >> >> -- lost boundary >> ... >> -- lost boundary -- >> -- good boundary -- >> >> The "lost boundary" would be hidden within whatever the >> Downgrade mechanism did. The former multipart would be >> a single part without MIME header fields. Maybe a smart >> Downgrade mechanism could fix that somehow, preserving a >> copy of the old Content-Type without its UTF-8 comment. > > Right. Very good example. Actually no. A very bad example. See my reply to Frank. > >>> For example, consider local system pathnames on a >>> Unicode-based file system, specified in a >>> "name=" parameter, which might well be in UTF-8. >> >> Yes, I know why Charles wants it. IMO adding "MIME 2.0" >> (explicitly or implicitly) to the EAI experiment is too >> much, email addresses (as the name EAI says) are already >> complex enough for the moment. > > I agree, fwiw. But that leaves me without knowing quite what > to do with those file names other than drop them. I would > happily do that since I've believe the parameter was a bad idea > from the beginning, but I know I'm in a tiny minority about > that. You are seeing problems where none exist. RFC 2231 (assuming it is implemented at the receving end - and if it isn't it will have problems even without UTF8SMTP) is a complete solution, and is still valid within MIME 1.0. >> This MIME 2.0 idea scares me. It's about as attractive >> as integrating 4408 into 2821bis, or Bruce's great plan >> to integrate MIME into 2822bis. > > When I suggested it, I intended it as a discussion-stopper. > Most of the people who understand its implications got that, in > one form or another. For those who are surprised by my saying > that (a list that almost certainly does not include you, Frank), > the problem is that the "MIME-version" header has become noise > because we had no theory about how versioning mechanism would > work going forward. So we have systems that don't check for its > presence at all, systems that check for its presence and then > ignore it, and systems that might actually notice if the version > number had changed. Of the latter, some would assume that 2.0 > was at least upward compatible with 1.0 and others would assume > that it meant the message was completely incompatible, i.e., > that they couldn't even interpret Content-type headers unless > they had 2.0 support. Yes, that is why I don't want to invent MIME 2.0, and just to allow extensions to MIME 1.0 that are only allowed to be seen within the UTF8SMTP universe, and can be downgraded to things that are then strict-current-MIME-1.0. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 09:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLj7-00069k-Bb; Fri, 13 Apr 2007 09:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLj6-00069f-ID for ima@ietf.org; Fri, 13 Apr 2007 09:22:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLj6-0002rS-49 for ima@ietf.org; Fri, 13 Apr 2007 09:22:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcLip-0003k0-UU for ima@ietf.org; Fri, 13 Apr 2007 15:21:53 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 15:21:51 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 15:21:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 15:08:29 +0200 Organization: Lines: 74 Message-ID: <461F80CD.2410@xyzzy.claranet.de> References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [EAI] Re: downgrading target header list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > If you read RFC 2047 carefully, you should always be > able to discover at least one valid way of doing it. NAK, only if you know the structure. Modifying one of my torture examples (read raw Latin-1 as raw UTF-8): | xxx: (=3D?utf-8*nds?q?=E4?=3D =F6 =3D?utf-8*de?q?=3DFC?=3D) In an unstructured field that's no comment, and there are no encoded words. In a structured field it might be a comment (not necessarily, it could be a part of a quoted string, or a field not allowing comments, etc.) Let's assume that it's a structured comment, then it contains one encoded word =3D?utf-8*de?q?=3DFC?=3D A 2047-downgrade mechanism would have to pick either =3D?utf-8?q?=3DF6_?=3D or =3D?utf-8?q?=3DF6?=3D to preserve the space to its right. (Or equivalent 'B' encodings) It must not start with _=3DF6, as that would insert a space to its left (in addition to the one SP that's already there). Last but not least I don't trust that any downgrade mechanism based on 2047 gets the non-encoded "word" (=3D?utf-8*nds?q?=E4?=3D right. It's just too tricky, even if we'd decree "treat all UTF-8 header fields as unstructured for the purpose of 2047-downgrading" it's still too tricky. And hopeless for raw non-UTF-8 octets. Downgrade needs its own mechanism, hex. NCRs after protecting all input "&" is an idea. Or the perl mechanism mentioned in John's "escape" I-D, but in that case I don't know the proper way to protect input using this style. > What is an NCR? A numerical character refeence like   for u+00A0. NCRs are quite popular because they're supported in XML (and FWIW in HTML) and almost all browsers. The last browser insisting on decimal instead of hexadecimal NCRs is under my firm control. NCRs (or the perl-style) won't help us with non-UTF-8 octets, but we could use a mixed downgrade strategy: If possible (valid UTF-8) use hex. NCRs, otherwise use "B64 everything". [non-UTF-8] > simply encode the octets as if they were UTF-8 You're kidding. You'd have to use UNKNOWN-8BIT. > please produce a valid example. It was an example showing why a "B64 everything" strategy won't fly for MIME part headers (Content-*). Anything Downgraded: Content-[...] is impossible in a MIME part header. The real error is the attempt to touch any bit in the body. 8-to-7 bits magic is no job for EAI. Good 8-to-7 bits magic should be on standards track, or deserves its own experiment. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 09:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLk4-0007Hu-T4; Fri, 13 Apr 2007 09:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLk2-0007Hb-FK for ima@ietf.org; Fri, 13 Apr 2007 09:23:06 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLk2-00032e-2y for ima@ietf.org; Fri, 13 Apr 2007 09:23:06 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew$man*ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461f8439.944.c2 for ima@ietf.org; Fri, 13 Apr 2007 14:23:05 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3DDN4kc011780 for ; Fri, 13 Apr 2007 14:23:05 +0100 (BST) To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> <8A1A84C608F8BA12ABDA26B6@B50854F0A9192E8EC6CDA126> Message-ID: Date: Fri, 13 Apr 2007 14:23:04 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <8A1A84C608F8BA12ABDA26B6@B50854F0A9192E8EC6CDA126> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 12 Apr 2007 21:57:02 +0100, Harald Tveit Alvestrand wrote: > > That means that the *result* of the transformation needs to either be > ignorable or decodable by MUAs that don't support UTF8SMTP. However, using downgrades via 2231 or 2047 should be acceptqable to existing MUAs. Moreover, most existing MUAs, when faced with a header they do not recognize but observing apparent s within them will try to decode them before display, so hopefully even a Downgraded header will be displayed in a readable form. > > In practice, I think that leaves us with "remove or encoded-word". I disagree. Encoded-words in places where they are expected will surely work. In places where they might not be expected (as in the Downgraded header) they will probably work. Stuff encoded via 2231 should be handled correctly (if the MUA has bothered to implement it). So I see no situation where "remove" would be needed. In the worst case, the reader will see the encoded-form and will have to decide whether the header in question is important enough for him to bother trying to disentangle it (to which the usual answer will be "no, it isn't"). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 09:42:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcM2w-0003cl-Gw; Fri, 13 Apr 2007 09:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcM2v-0003bP-9J for ima@ietf.org; Fri, 13 Apr 2007 09:42:37 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcM2t-00022t-Vn for ima@ietf.org; Fri, 13 Apr 2007 09:42:37 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HcM2t-000Ats-Bf; Fri, 13 Apr 2007 09:42:35 -0400 Date: Fri, 13 Apr 2007 09:42:34 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Re: downgrading target header list Message-ID: <54133D9B68BB897A64278195@p3.JCK.COM> In-Reply-To: References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (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: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 13 April, 2007 14:10 +0100 Charles Lindsey wrote: >... > Yes, that is why I don't want to invent MIME 2.0, and just to > allow > extensions to MIME 1.0 that are only allowed to be seen within > the > UTF8SMTP universe, and can be downgraded to things that are > then > strict-current-MIME-1.0. But, if they are used and appear --even in encoded form-- on the other side of a downgrade process, they are no longer "in the UTF8SMTP universe" but in a universe in which they may not have a clear and unambiguous interpretation. Please see Harald's recent note. And, FWIW, I don't share your optimism about putting things that look like encoded words into fields that the receiving system may not understand and assuming that the right things will happen. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 10:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMai-0001U6-UF; Fri, 13 Apr 2007 10:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMag-0001TM-Pl for ima@ietf.org; Fri, 13 Apr 2007 10:17:31 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMag-0005xU-8u for ima@ietf.org; Fri, 13 Apr 2007 10:17:30 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2204D25972F; Fri, 13 Apr 2007 16:17:29 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14317-10; Fri, 13 Apr 2007 16:17:23 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB64325972E; Fri, 13 Apr 2007 16:17:23 +0200 (CEST) Message-ID: <461F90F3.6030803@alvestrand.no> Date: Fri, 13 Apr 2007 16:17:23 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Re: downgrading target header list References: <142931FE8D59C5F484183419@p3.JCK.COM> In-Reply-To: <142931FE8D59C5F484183419@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> In practice, I think that leaves us with "remove or >> encoded-word". >> > > Sadly, I agree. "Sadly", because I think it really implies > that, if a downgrading system doesn't understand --explicitly > recognize-- a header that contains non-ASCII information-- it > probably needs to drop it. Anything else gets us involved with > guessing what the information there is actually about and about > what the receiving MUA may or may not know. > > A different way to look at this is that, while losing > information is unattractive, it is better than risking changing > material in a way that appears to retain information but > actually alters it. If we try to preserve every possible bit in > the expectation of later upgrading, we are likely to increase > the number of situations in which messages are rejected or > returned rather than downgraded. > Another theory, which may be suitable for an experiment, even though we would be hesitant to deploy such a thing in the running Internet: Assume that any legal UTF-8 character in an unknown header is placed there in accordance to this specification. Assume further that this specification says that you can ONLY place UTF-8 characters in places where either encoded-words or RFC 2231 encoded quoted-strings are allowed. (Question: Can we manage to say that?) If those two things are both true, we can safely use the encoded-word and RFC 2231 technique on strings containing such characters - on the naivistic theory that anything else is a protocol error, so they deserve what they get. Then we run the experiment, and observe one of three outcomes: - Our assumptions are true all the time (not likely) - Our assumptions are false, and false so often that we need to reconsider - Our assumptions are occasionally false, but the pain this causes is tolerable We MIGHT get lucky.... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 11:56:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcO8e-0000Gs-CN; Fri, 13 Apr 2007 11:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcO8d-0000Ga-3Y for ima@ietf.org; Fri, 13 Apr 2007 11:56:39 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcO8b-0001Db-JH for ima@ietf.org; Fri, 13 Apr 2007 11:56:39 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HcO8Y-000CBa-KQ; Fri, 13 Apr 2007 11:56:34 -0400 Date: Fri, 13 Apr 2007 11:55:08 -0400 From: John C Klensin To: Harald Alvestrand Subject: Re: [EAI] Re: downgrading target header list Message-ID: In-Reply-To: <461F90F3.6030803@alvestrand.no> References: <142931FE8D59C5F484183419@p3.JCK.COM> <461F90F3.6030803@alvestrand.no> X-Mailer: Mulberry/4.0.7 (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: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 13 April, 2007 16:17 +0200 Harald Alvestrand wrote: >... > Another theory, which may be suitable for an experiment, even > though we would be hesitant to deploy such a thing in the > running Internet: I'd rather keep our "experiment" plausible, i.e., confine ourselves to things we think we would be willing to deploy barring surprises or other empirical corrections. For your suggestion, I fear that, even if we "get lucky", actually incorporating the idea into a real specification and deploying it widely would, modulo one observation below, require proving a universal negative. My reason for that belief is that, just as we had to deploy the SMTP extension model and MIME against a backdrop of "just send 8" implementations, I think there is every reason to believe that there are implementations out there that use non-ASCII characters in locally-defined header fields and, worse, that those non-ASCII characters are (as Soobok and others have suggested in a different context), going to be coded in local/national character sets rather than Unicode/UTF-8 in many cases. > Assume that any legal UTF-8 character in an unknown header is > placed there in accordance to this specification. > > Assume further that this specification says that you can ONLY > place UTF-8 characters in places where either encoded-words or > RFC 2231 encoded quoted-strings are allowed. (Question: Can we > manage to say that?) > > If those two things are both true, we can safely use the > encoded-word and RFC 2231 technique on strings containing such > characters - on the naivistic theory that anything else is a > protocol error, so they deserve what they get. Let me suggest a different model that we could use if you wanted to go down this path. Today (i.e., under 2821/2822), the appearance of any non-ASCII character -- anything else with the high bit turned on or any seven-bit (leading zero bit) object intended to be interpreted as other than ASCII-- in a header is a protocol violation. If we take the position that anyone who violates those base protocols deserves whatever bad things happen to them and so do any senders or receivers who are victims of their software, then we might be able to make a clean downgrading model by specifying, in the UTF8Headers document, _exactly_ what headers can contain such characters and where. That description would need to either forbid UTF8 information in any header not listed or would need to describe very precise rules for unknown headers (where "unknown" == "not listed"). If we were going to do that, the distinction between "structured" and "unstructured" headers probably isn't good enough. We would either need to confine ourselves --and permission to include 8bit information in headers-- to things that we could enumerate or we would need to get very clever. And hand waving, such as assuming that things in parentheses in unknown headers were comments, would not be nearly good enough. Whether it is worth the effort or not is an open question, but it would at least constitute the basis for a clean experiment that we could use. And part of the experimental question would be "which header fields did we not list that really need UTF8 data"? > Then we run the experiment, and observe one of three outcomes: > > - Our assumptions are true all the time (not likely) > - Our assumptions are false, and false so often that we need > to reconsider > - Our assumptions are occasionally false, but the pain this > causes is tolerable You will almost certainly not be able to competently evaluate the last case without an _exhaustive_ test. And exhaustive tests are essentially impossible. > We MIGHT get lucky.... We are more likely to delude ourselves into believing that we have gotten lucky in the absence of sufficient counterexamples, which would be very dangerous indeed. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 20:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWLf-0003nv-8d; Fri, 13 Apr 2007 20:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWLe-0003np-6J for ima@ietf.org; Fri, 13 Apr 2007 20:42:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcWLc-0004aI-RJ for ima@ietf.org; Fri, 13 Apr 2007 20:42:38 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3E0gVLd032213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Apr 2007 17:42:32 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3E0gUIt024852; Fri, 13 Apr 2007 17:42:31 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4613B26D.20609@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 13 Apr 2007 17:39:53 -0700 To: John C Klensin , Harald Alvestrand , EAI WG From: Randall Gellens Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 3:26 PM -0400 4/4/07, John C Klensin wrote: > While I think that, given time and energy, we could answer those > questions, produce firm specifications, and expect that most > (but not all) implementations would understand and follow the > instructions well enough to get things right, it seems to me to > be a high cost and high risk for something that is not > absolutely necessary. And... Yes, I agree. > > (iii) If our target and expectation are a long-term mail > environment in which substantially everyone supports UTF8SMTP > and those who do not understand that they are running crippled > and obsolete systems, then this parameter becomes long-term > clutter with no value. The same could be said about 8BITMIME > today and perhaps, long-term, about ALT-ADDR itself. But the > existence of two of them is, IMO, a strong reason to not add a > third, not a justification for it. In an environment in which most systems have upgraded to support UTF8SMTP, then ALT-ADDRESS nicely goes away. The same can't be said for HDR=UTF8 (although, in fairness, if you said that the server advertising UTF8SMTP means that all messages are assumed to require such support unless either the recipient server has scanned it and determined it is all ascii, or the sender specifies something like MSG=ALL-ASCII, and there is no other MSG= value, especially, there is no value which means UTF8 (just the absence of the parameter) then this parameter could also go away). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I was gratified to be able to answer promptly, and I did. I said I didn't know." --Mark Twain _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 22:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXj1-0004gC-GB; Fri, 13 Apr 2007 22:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXj0-0004g4-66 for ima@ietf.org; Fri, 13 Apr 2007 22:10:50 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcXiy-0007z4-Jd for ima@ietf.org; Fri, 13 Apr 2007 22:10:50 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l3E2AeJ5010539; Sat, 14 Apr 2007 11:10:40 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l3E2AdTN010536; Sat, 14 Apr 2007 11:10:39 +0900 Date: Sat, 14 Apr 2007 11:10:39 +0900 From: Soobok Lee To: Randall Gellens , f@ns5.lsb.org Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <20070414021039.GA8148@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 13, 2007 at 05:39:53PM -0700, Randall Gellens wrote: > > In an environment in which most systems have upgraded to support > UTF8SMTP, then ALT-ADDRESS nicely goes away. The same can't be said > for HDR=UTF8 I agree on this last sentence from different viewpoint. See this. MAIL FROM: ascii1@ascii.com HDR=UTF8 RCPT TO: ascii2@world.com RCPT TO: utf8-1@asia.com DATA From: "display_name" TO: ascii2@world.com, utf8-1@asia.com Subject: utf8-subject bodytext goes here . The utf8smtp server tries to fork another outgoing smtp session in order to relay to ascii2@world.com as follows. MAIL FROM: ascii1@ascii.com HDR=UTF8 RCPT TO: ascii2@world.com DATA From: "display_name" TO: ascii2@world.com, utf8-1@asia.com Subject: utf8-subject bodytext goes here . If @world.com has UTF8SMTP EHLO option (no downgrade attempted), and the envelope addresses are all in 7BIT ASCII, the only sign of UTF8SMTP header presence in this SMTP session is "HDR=UTF8" . Without this parameter, the server should parse message headers to determine that. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 13 22:11:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXjE-0004i2-LX; Fri, 13 Apr 2007 22:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXjD-0004hw-FZ for ima@ietf.org; Fri, 13 Apr 2007 22:11:03 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcXjB-00080Y-RO for ima@ietf.org; Fri, 13 Apr 2007 22:11:03 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l3E2AsJ5010558; Sat, 14 Apr 2007 11:10:54 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l3E2Asr7010557; Sat, 14 Apr 2007 11:10:54 +0900 Date: Sat, 14 Apr 2007 11:10:54 +0900 From: Soobok Lee To: Randall Gellens Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <20070414021039.GA8148@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Apr 13, 2007 at 05:39:53PM -0700, Randall Gellens wrote: > > In an environment in which most systems have upgraded to support > UTF8SMTP, then ALT-ADDRESS nicely goes away. The same can't be said > for HDR=UTF8 I agree on this last sentence from different viewpoint. See this. MAIL FROM: ascii1@ascii.com HDR=UTF8 RCPT TO: ascii2@world.com RCPT TO: utf8-1@asia.com DATA From: "display_name" TO: ascii2@world.com, utf8-1@asia.com Subject: utf8-subject bodytext goes here . The utf8smtp server tries to fork another outgoing smtp session in order to relay to ascii2@world.com as follows. MAIL FROM: ascii1@ascii.com HDR=UTF8 RCPT TO: ascii2@world.com DATA From: "display_name" TO: ascii2@world.com, utf8-1@asia.com Subject: utf8-subject bodytext goes here . If @world.com has UTF8SMTP EHLO option (no downgrade attempted), and the envelope addresses are all in 7BIT ASCII, the only sign of UTF8SMTP header presence in this SMTP session is "HDR=UTF8" . Without this parameter, the server should parse message headers to determine that. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 14 07:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcgKQ-000276-D9; Sat, 14 Apr 2007 07:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcgKO-00026k-TB for ima@ietf.org; Sat, 14 Apr 2007 07:22:00 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcgKN-0006y1-Ag for ima@ietf.org; Sat, 14 Apr 2007 07:22:00 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HcgK8-000PMR-R2; Sat, 14 Apr 2007 07:21:45 -0400 Date: Sat, 14 Apr 2007 07:19:59 -0400 From: John C Klensin To: Randall Gellens , Harald Alvestrand , EAI WG Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: In-Reply-To: References: <4613B26D.20609@alvestrand.no> X-Mailer: Mulberry/4.0.7 (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: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 13 April, 2007 17:39 -0700 Randall Gellens wrote: > > At 3:26 PM -0400 4/4/07, John C Klensin wrote: > >> While I think that, given time and energy, we could answer >> those questions, produce firm specifications, and expect >> that most (but not all) implementations would understand and >> follow the instructions well enough to get things right, it >> seems to me to be a high cost and high risk for something >> that is not absolutely necessary. And... > > Yes, I agree. > >> >> (iii) If our target and expectation are a long-term mail >> environment in which substantially everyone supports UTF8SMTP >> and those who do not understand that they are running >> crippled and obsolete systems, then this parameter becomes >> long-term clutter with no value. The same could be said >> about 8BITMIME today and perhaps, long-term, about ALT-ADDR >> itself. But the existence of two of them is, IMO, a strong >> reason to not add a third, not a justification for it. > > In an environment in which most systems have upgraded to > support UTF8SMTP, then ALT-ADDRESS nicely goes away. The same > can't be said for HDR=UTF8 (although, in fairness, if you said > that the server advertising UTF8SMTP means that all messages > are assumed to require such support unless either the > recipient server has scanned it and determined it is all > ascii, or the sender specifies something like MSG=ALL-ASCII, > and there is no other MSG= value, especially, there is no > value which means UTF8 (just the absence of the parameter) > then this parameter could also go away). Yes, if one were to do this at all, an assertion of "all-ASCII" would be better than one of "utf8", as you suggest. One would probably have to be prepared to have that assertion violated -- just as one has to have some way to deal with "high bit on" situations in the legacy environment -- so I am still not convinced it is worth the extra effort. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 14 09:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HciEL-0001o5-2k; Sat, 14 Apr 2007 09:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HciEJ-0001nw-TK for ima@ietf.org; Sat, 14 Apr 2007 09:23:51 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HciEI-000600-Iq for ima@ietf.org; Sat, 14 Apr 2007 09:23:51 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E26E22597B1; Sat, 14 Apr 2007 15:23:49 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24842-10; Sat, 14 Apr 2007 15:23:42 +0200 (CEST) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B2E32597B4; Sat, 14 Apr 2007 15:23:33 +0200 (CEST) Date: Sat, 14 Apr 2007 15:23:17 +0200 From: Harald Tveit Alvestrand To: John C Klensin , Randall Gellens , EAI WG Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: In-Reply-To: References: <4613B26D.20609@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 14. april 2007 07:19 -0400 John C Klensin wrote: >> In an environment in which most systems have upgraded to >> support UTF8SMTP, then ALT-ADDRESS nicely goes away. The same >> can't be said for HDR=UTF8 (although, in fairness, if you said >> that the server advertising UTF8SMTP means that all messages >> are assumed to require such support unless either the >> recipient server has scanned it and determined it is all >> ascii, or the sender specifies something like MSG=ALL-ASCII, >> and there is no other MSG= value, especially, there is no >> value which means UTF8 (just the absence of the parameter) >> then this parameter could also go away). > > Yes, if one were to do this at all, an assertion of "all-ASCII" > would be better than one of "utf8", as you suggest. One would > probably have to be prepared to have that assertion violated -- > just as one has to have some way to deal with "high bit on" > situations in the legacy environment -- so I am still not > convinced it is worth the extra effort. Note that changing the default doesn't lessen the complexity of implementing the parameter one iota; in both cases, there are 2 codepaths to maintain, forever. The only thing that is improved by changing the default is the optics of the final state. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 14 14:44:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnEv-0003Kc-KH; Sat, 14 Apr 2007 14:44:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnEt-0003KQ-R8 for ima@ietf.org; Sat, 14 Apr 2007 14:44:47 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcnEr-0003yg-3L for ima@ietf.org; Sat, 14 Apr 2007 14:44:47 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HcnEi-0004G7-Qo; Sat, 14 Apr 2007 14:44:37 -0400 Date: Sat, 14 Apr 2007 14:44:35 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Randall Gellens , EAI WG Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <5221A84C2FCDBCEF8AA5859F@[192.168.1.110]> In-Reply-To: References: <4613B26D.20609@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Saturday, April 14, 2007 3:23 PM +0200 Harald Tveit Alvestrand wrote: > > > --On 14. april 2007 07:19 -0400 John C Klensin > wrote: > >>> In an environment in which most systems have upgraded to >>> support UTF8SMTP, then ALT-ADDRESS nicely goes away. The >>> same can't be said for HDR=UTF8 (although, in fairness, if >>> you said that the server advertising UTF8SMTP means that all >>> messages are assumed to require such support unless either >>> the recipient server has scanned it and determined it is all >>> ascii, or the sender specifies something like MSG=ALL-ASCII, >>> and there is no other MSG= value, especially, there is no >>> value which means UTF8 (just the absence of the parameter) >>> then this parameter could also go away). >> >> Yes, if one were to do this at all, an assertion of >> "all-ASCII" would be better than one of "utf8", as you >> suggest. One would probably have to be prepared to have that >> assertion violated -- just as one has to have some way to >> deal with "high bit on" situations in the legacy environment >> -- so I am still not convinced it is worth the extra effort. > > Note that changing the default doesn't lessen the complexity > of implementing the parameter one iota; in both cases, there > are 2 codepaths to maintain, forever. The only thing that is > improved by changing the default is the optics of the final > state. Exactly. And that is the reason I remain opposed to doing this at all. If we decided to do it anyway, then the optics become relevant. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 14 17:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcppF-00082V-51; Sat, 14 Apr 2007 17:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcppD-00082I-9Z for ima@ietf.org; Sat, 14 Apr 2007 17:30:27 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcppB-00079D-4V for ima@ietf.org; Sat, 14 Apr 2007 17:30:27 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3ELUOfL019356 for ; Sat, 14 Apr 2007 21:30:24 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGI00G01BKF9R00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Sat, 14 Apr 2007 15:30:24 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGI00G02BQBG800@mail-amer.sun.com>; Sat, 14 Apr 2007 15:30:24 -0600 (MDT) Date: Fri, 13 Apr 2007 20:09:26 -0700 From: Chris Newman Subject: Re: [EAI] Re: UTF8SMTP mailbox on SMTP reply (Re: POLL: HDR= extension on MAIL FROM) To: John C Klensin , Tony Finch Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Kari Hurtta , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote on 4/10/07 9:40 -0400: > I was not. I was referring to the much older idea that we > should establish single "line" format and forms and let systems > at the end points convert to and from them rather than creating > the N**2 problem of everyone being expected to understand > everyone else's forms (or, in this case, languages and character > sets). Quality user interfaces are a non-deterministic problem because they raise all the issues about human communication and culture. This makes engineers who want precise answers unhappy for obvious reasons. Attempting standardize every possible error condition that might merit a slightly different user interface is a fool's errand and results in a cumbersome infrastructure that can't adapt easily. The problem with enumerating conditions for localization is it requires full standards quality interoperability at both ends. Adding a new diagnostic condition requires updates to software on both ends. Furthermore, good user diagnostics generally include references to names, identifiers, who to contact for further help, etc. Trying to create a machine readable syntax for a diagnostic code and useful ancillary arguments makes the problem sufficiently complex that I don't think it's worth solving. At the other extreme, we've learned from POP that simple success/fail diagnostics are not adequate -- we need machine readable diagnostics for cases which merit different software behavior (RFC 3206). The correct answer is a solid middle ground. We enumerate diagnostic codes for common cases (indeed as many cases as the industry has energy to enumerate in standards and/or a registry), but we also transport human readable text to handle the less common cases, provide a simple way to embed OS/platform/software specific diagnostic codes and identifiers and provide a more agile and user friendly experience (because diagnostics can be improved by just a server update). This requires language negotiation which is messy (particularly in the SMTP case), but has been implemented and used in deployed SMTP software at least for localization of the first part of a DSN/MDN. > If you are correct, then enhanced status codes are a failure and > should be pulled of the standards track and junked: providing > the adequate foundation to which you refer was a large part of > the justification for doing those codes in the first place. The problem we had with the base SMTP codes was that they were too aggressively overloaded and too much deployed software didn't treat them in an extensible fashion -- basically they fell on the base POP3 side of the necessary middle ground. When software has to start keying off the human readable content of the status code to determine what to do, then the protocol is broken and needs a patch. Enhanced status codes provided that patch and the fact new enhanced codes are being defined and deployed is a sign they are useful and successful. While I've never seen an MUA with a catalog to convert SMTP status codes to localized human text, it would be a nice feature for an MUA to have. But the fact that feature hasn't deployed doesn't make the mechanism a failure as the mechanism has other purposes (log categorization, automated DSN handling, etc). > IMO, 2640 is badly broken for other reasons. Trying to write > that up and fix it generated a collection of prerequisite work. > And I have almost the same objections to the POP and IMAP > proposals that I do to the SMTP one. However, SMTP is more > difficult for the usual other reason: FTP, POP, and IMAP all > require a direct client-server connection (in FTP's case, for > the command channel) to operate. Consequently, any negotiations > about replies are between the client and the server that will > produce them. Because of the relay issues, an SMTP negotiation > about the language and form of responses is much more tentative > and tenuous. Certainly it will work sometimes, but the other > cases a problematic. Yes, SMTP LANG is a much trickier case than simple client-server protocols. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 16 02:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKMZ-0001Fb-OB; Mon, 16 Apr 2007 02:06:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKMW-00019S-S2 for ima@ietf.org; Mon, 16 Apr 2007 02:06:52 -0400 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdKMU-0001U2-19 for ima@ietf.org; Mon, 16 Apr 2007 02:06:52 -0400 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l3G66jJ5026709; Mon, 16 Apr 2007 15:06:45 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l3G66ieX026707; Mon, 16 Apr 2007 15:06:44 +0900 Date: Mon, 16 Apr 2007 15:06:44 +0900 From: Soobok Lee To: Randall Gellens Subject: Re: [EAI] POLL: HDR= extension on MAIL FROM Message-ID: <20070416060644.GB8148@ns5.lsb.org> References: <4613B26D.20609@alvestrand.no> <20070414021039.GA8148@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070414021039.GA8148@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, Apr 14, 2007 at 11:10:54AM +0900, Soobok Lee wrote: > The utf8smtp server tries to fork another > outgoing smtp session in order to relay to ascii2@world.com > as follows. > > > MAIL FROM: ascii1@ascii.com HDR=UTF8 > RCPT TO: ascii2@world.com > > DATA > From: "display_name" > TO: ascii2@world.com, utf8-1@asia.com > Subject: utf8-subject > > bodytext goes here > . > > > > > If @world.com has UTF8SMTP EHLO option (no downgrade attempted), > and the envelope addresses are all in 7BIT ASCII, the only > sign of UTF8SMTP header presence in this SMTP session > is "HDR=UTF8" . Without this parameter, the server > should parse message headers to determine that. $s/parse message headers/parse EVERY message header it receives/; Moreover,as we havn't touched DKIM/SMIME related header definition and header normalization requirement here, we can't exclude future "UTF8SMTPv2" which may introduce more headers or more restrictions or more normalization requirement. In that case, even "HDR=UTF8" is not enough, rather, as Kari suggested, "HDR=UTF8SMTP" and "HDR=UTFSMTPv2" may become better and necessary. "UTF8SMTPv2" EHLO options as well. "HDR=UTF8SMTP" is so clear that it not only specifies the headers are in UTF8 encoding, but also specifies that the header section abides by the UTF8SMTPv1 restrictions and requirements. "HDR=UTF8SMTPv2" may indicate that the headers keep the new rules imposed by UTF8SMTP version 2. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 16 16:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXvG-0002LM-0s; Mon, 16 Apr 2007 16:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXvE-0002LF-Pu for ima@ietf.org; Mon, 16 Apr 2007 16:35:37 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXvB-0002GK-Uk for ima@ietf.org; Mon, 16 Apr 2007 16:35:36 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew*man^ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4623de14.d71b.18e for ima@ietf.org; Mon, 16 Apr 2007 21:35:32 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3GKZU8v002176 for ; Mon, 16 Apr 2007 21:35:31 +0100 (BST) Date: Mon, 16 Apr 2007 21:35:29 +0100 To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> <461F80CD.2410@xyzzy.claranet.de> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <461F80CD.2410@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 13 Apr 2007 14:08:29 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > >> If you read RFC 2047 carefully, you should always be >> able to discover at least one valid way of doing it. > > NAK, only if you know the structure. Modifying one of > my torture examples (read raw Latin-1 as raw UTF-8): > > | xxx: (=?utf-8*nds?q?ä?= ö =?utf-8*de?q?=FC?=) > > In an unstructured field that's no comment, and there > are no encoded words. Yes, for two reasons: 1. The '(' and ')' should have been inside the (alleged) encoded-words; 2. One of the (alleged) encoded-words contains a non-ASCII character. So a really Bloody-Minded downgrader, when it saw that in a Subject, would say to itself "there are no encoded-words there, so obviously the sender wanted his Subject to contain all those "=?" and "?=" and "utf-8"s to be rendered just as you see them above, so it would downgrade them to {Note that, although I am nominally downgrading from utf-8, I am actually showing hex for the Latin-1 characters, just as you did, because it is too much hassle to look up the utf-8 encodings.} Subject: =?utf-8?q?(=3D=3Futf-8*nds=3Fq=3F=e4=3F=3D_=F6_?= =?utf-8?q?=3D=3Futf-8*de=3Fq=3F=3DFC=3F=3D)?= However, it is more than likely that the sender (or rather his broken software) really did intend those to be encoded words, and most MUAs take a more liberal view and attempt to decode anything that looks remotely like an encoded-word. For sure, they ignore reason #1, and quite likely reason #2 (certainly, upon offering your original example, and many variations on it, in a Subject to my own MUA caused it to display "(ä ö ü)". So I would not care overmuch if a downgrader tried to be as liberal as typical MUAs are and produced something like Subject: =?utf-8*nds?q?(=e4?= =?utf-8?q?_=f6_?= =?utf-8*de?q?=FC)?= > Let's assume that it's a structured comment, then it > contains one encoded word =?utf-8*de?q?=FC?= > > A 2047-downgrade mechanism would have to pick either > =?utf-8?q?=F6_?= or =?utf-8?q?=F6?= to preserve the > space to its right. (Or equivalent 'B' encodings) No it wouldn't, because it would try to get both the ä and the ö within the same encoded-word. So a Bloody-Minded downgrader would produce (?utf-8?q?=3D=3Futf-8*nds=3Fq=3F=e4=3F=3D_=F6_?= =?utf-8*de?q?=FC?=) And a more liberal one would do much the same as my liberal Subject version. As I said before, I would not be particularly upset it downgraders did pedantically incorrect things which most typical MUAs regularly do anyway, hence making it more likely that any final and liberal upgrader would show what liberal MUAs already regularly show. So, essentially, I still claim that a Bloody-Minded downgrader can still always find a pedantically correct way to encode any utf-8 stuff whilst leaving genuine pre-existing encoded-words untouched, and a liberal upgrader (much easier to write) can still get things at least as correct as the average MUA gets them. > Last but not least I don't trust that any downgrade > mechanism based on 2047 gets the non-encoded "word" > (=?utf-8*nds?q?ä?= right. That may well be the case but, as I have said, they will get it as right as typical MUAs are likely to get it. > > It's just too tricky, even if we'd decree "treat all > UTF-8 header fields as unstructured for the purpose > of 2047-downgrading" it's still too tricky. Well we aren't proposing that. If some downgrader genuinely knows which headers are unstructured and which not, then good luck to it. But if it doesn't, then we should also realise that most MUAs don't know that either, and so not to worry if it takes similar shortcute as typical MUAs already do. > > And hopeless for raw non-UTF-8 octets. Downgrade > needs its own mechanism, hex. NCRs after protecting > all input "&" is an idea... > >> What is an NCR? > > A numerical character refeence like   for u+00A0. > > NCRs are quite popular because they're supported in XML > (and FWIW in HTML) and almost all browsers. But not by MUAs I hope. But even if some MUAs do implement them, UTF8SMTP should take no special action on them. If some MUAs now happen to do the "right thing" with some UTF-8 encoded that way, then good luck to them, but let us not get involved. > [non-UTF-8] >> simply encode the octets as if they were UTF-8 > > You're kidding. You'd have to use UNKNOWN-8BIT. Pedantically, they should do as you say, but in the Real World that is unlikely to happen (since we can have no control over what is done with inadmissable input). > >> please produce a valid example. > > It was an example showing why a "B64 everything" > strategy won't fly for MIME part headers (Content-*). It was not a valid example that could actually happen. Therefor it proved nothing. > > Anything Downgraded: Content-[...] is impossible in > a MIME part header. But there is never any necessity, with any proposal currently before us, for a Downgraded header to appear in a MIME part header. All such headers are supposed to start with Content-*, and all known Content-* headers can be downgraded withour creating a Downgraded header. So no problem. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 16 17:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYLr-00066t-Vg; Mon, 16 Apr 2007 17:03:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYLq-00066o-EB for ima@ietf.org; Mon, 16 Apr 2007 17:03:06 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYLo-0006jw-S2 for ima@ietf.org; Mon, 16 Apr 2007 17:03:06 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew^man$ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4623e487.d71b.196 for ima@ietf.org; Mon, 16 Apr 2007 22:03:03 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3GL32FM003827 for ; Mon, 16 Apr 2007 22:03:03 +0100 (BST) To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <142931FE8D59C5F484183419@p3.JCK.COM> Message-ID: Date: Mon, 16 Apr 2007 22:03:01 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <142931FE8D59C5F484183419@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 13 Apr 2007 12:42:37 +0100, John C Klensin wrote: > Sadly, I agree. "Sadly", because I think it really implies > that, if a downgrading system doesn't understand --explicitly > recognize-- a header that contains non-ASCII information-- it > probably needs to drop it. Anything else gets us involved with > guessing what the information there is actually about and about > what the receiving MUA may or may not know. Do you really mean "drop it"? I thought our whole strategy was that you always downgraded, and if that was not possible you bounced/rejected. I don't think you can get away with omitting a part of some message that was probably put there for good reason. So if it eventually arrives at some recipient then every header that was present in the original should be present in some form in what he receives, even if not upgraded/upgradeable with 100% perfection. > > A different way to look at this is that, while losing > information is unattractive, it is better than risking changing > material in a way that appears to retain information but > actually alters it. We would only care if the alteration made it semantically different. It is already accepted that changes of content transfer encoding and changes of folding have no semantic effect (except maybe to DKIN signings). Likewise, different but equivalent ways of doing RFC 2047 encoding do not change the semantics (which is always the sequence of encoded characters as restored to and displayed in their original charsets). And it is also considered acceptable to display the encoded form if the required charsets cannot be displayed locally. Within those limitations, the Downgraded header, as currently proposed, meets the requirements of conveying the original semantic meaning. The worst that can happen is that some legacy agent which was supposed to take some specific action upon seeing that header will not take it when presented with an equivalent Downgraded header. But we have taken care of what to do in the case of all presently known headers, and as regards headers not yet invented the world has to accept that there will always be older agents around that will not instigate whatever action that new header was supposed to bring about. Humans will always see such Downgraded headers properly displayed, if they care to look, which is all you can ever assume will happen with any newly-invented header. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 16 17:12:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYUR-0001ob-3F; Mon, 16 Apr 2007 17:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYUP-0001oF-9q for ima@ietf.org; Mon, 16 Apr 2007 17:11:57 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYUM-0000q6-OL for ima@ietf.org; Mon, 16 Apr 2007 17:11:57 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew^man$ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4623e696.e5cc.166 for ima@ietf.org; Mon, 16 Apr 2007 22:11:50 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3GLBiKY004350 for ; Mon, 16 Apr 2007 22:11:45 +0100 (BST) To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <142931FE8D59C5F484183419@p3.JCK.COM> <461F90F3.6030803@alvestrand.no> Message-ID: Date: Mon, 16 Apr 2007 22:11:43 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <461F90F3.6030803@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 13 Apr 2007 15:17:23 +0100, Harald Alvestrand wrote: > Assume that any legal UTF-8 character in an unknown header is placed > there in accordance to this specification. > > Assume further that this specification says that you can ONLY place > UTF-8 characters in places where either encoded-words or RFC 2231 > encoded quoted-strings are allowed. (Question: Can we manage to say > that?) Sadly, we can't say that. It may work for RFC 2231, but RFC 2047 provides no way to say it even for the present ASCII headers. Which is why cuurent MUAs routinely take shortcuts, such as treating all unrecognized headers (and even many recognized ones) as "unstructured". It works well enough that nobody really notices the odd technical glitch, and if we can get downgrading to work as well as that, we will have little to complain about. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 16 17:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYzF-0007dX-HX; Mon, 16 Apr 2007 17:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYzE-0007dR-RG for ima@ietf.org; Mon, 16 Apr 2007 17:43:48 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYzC-0007aX-7g for ima@ietf.org; Mon, 16 Apr 2007 17:43:48 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3*clerew#man&ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4623ee10.3c03.ae for ima@ietf.org; Mon, 16 Apr 2007 22:43:44 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3GLhh5q006269 for ; Mon, 16 Apr 2007 22:43:44 +0100 (BST) To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <20070410.191803.48510446.fujiwara@jprs.co.jp> <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <3C8E0ECDBF209745EF7AF684@p3.JCK.COM> <461E2F8D.4C1B@xyzzy.claranet.de> <54133D9B68BB897A64278195@p3.JCK.COM> Message-ID: Date: Mon, 16 Apr 2007 22:43:42 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <54133D9B68BB897A64278195@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 13 Apr 2007 14:42:34 +0100, John C Klensin wrote: > --On Friday, 13 April, 2007 14:10 +0100 Charles Lindsey > wrote: > >> ... >> Yes, that is why I don't want to invent MIME 2.0, and just to >> allow >> extensions to MIME 1.0 that are only allowed to be seen within >> the >> UTF8SMTP universe, and can be downgraded to things that are >> then >> strict-current-MIME-1.0. > > But, if they are used and appear --even in encoded form-- on the > other side of a downgrade process, they are no longer "in the > UTF8SMTP universe" but in a universe in which they may not have > a clear and unambiguous interpretation. Please see Harald's > recent note. Not so. The only downgrades that can arise on Content-* headers are if the header contains a comment (they never do, of course), or if they contain a of the form filename="mañana". There is never any need to generate a Downgraded header as well. In the one case we then get an RFC2047-encoded , and in the other case an RFC 2231-encoded , and existing software is supposed to be able to handle both of those situations without problem. The only other situation where we would allow things not envisaged by current MIME 1.0 is if we permit UTF8SMTP messages to appear with a message/rfc822 (but only within the UTF8SMTP universe). In that case, the downgrade process needs to descend through the complete MIME structure (which it will have to do in any case if we do not have that HRD=UTF8 parameter in order to ensure that no MIME body part headers have any UTF8 in them). Whenever it encounters a message/rfc822 it will then downgrade it, and so on recursively. So, in the non-UTF8SMTP universe you will then see message/rfc822 objects that are in fact downgraded from UTF8SMTP. But then you already expect to see messages of that sort in the non-UTF8SMTP universe anyway, so what's new? > > And, FWIW, I don't share your optimism about putting things that > look like encoded words into fields that the receiving system > may not understand and assuming that the right things will > happen. It is no worse than what happens in the present ASCII universe when encoded-words turn up in header fields that we invented after the piece of software was written (nearly all current software is liberal enough to do the "right thing" in those cases). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 17 08:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdmnl-0003Jx-Q6; Tue, 17 Apr 2007 08:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdmnk-0003Jn-Kd for ima@ietf.org; Tue, 17 Apr 2007 08:28:52 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdmnj-0002kM-2B for ima@ietf.org; Tue, 17 Apr 2007 08:28:52 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l3HCSfwI023940; Tue, 17 Apr 2007 21:28:48 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007041721284225500 ; Tue, 17 Apr 2007 21:28:42 +0900 Date: Tue, 17 Apr 2007 21:28:41 +0900 (JST) Message-Id: <20070417.212841.78701675.fujiwara@jprs.co.jp> To: nobody@xyzzy.claranet.de Subject: Re: [EAI] Re: downgrading target header list From: fujiwara@jprs.co.jp In-Reply-To: <461D1423.3956@xyzzy.claranet.de> References: <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: Frank Ellermann > > Encapsulating undefined headers (including all X-headers) is > > reasonable? > > As long as you don't use 2047 / 2231 on "words", because you > don't know what a "word" is without knowing the structure, as > in the ... > > xxx: (=?ascii*fr?Q?no?= encoded =?ascii*en?Q?words?=) > > ...example, if xxx header field bodies are unstructured (or > allow no comments). I changed the Downgraded header definition in my local downgrade-04 text. downgraded = "Downgraded:" [FWS] field-name ":" unstructured CRLF And added as 'this header will be encoded by RFC 2047.' > > Which downgrading method is suitable for Unknown Content-* > > header, (7) Encapsulating into Downgraded or (5) RFC 2231 ? > > None, Content-* MUST be ASCII for MIME Version 1.0, and the > old pre-MIME Content-Type was also ASCII. Adding UTF-8 capable MIME header list to utf8header document is one idea. > > From: Sender: Reply-To: To: Cc: Bcc: > > Bcc should be empty... agree. > > Resent-From: Resent-Sender: Resent-To: Resent-Cc: > > ...or add Resent-Bcc: (what crap, sigh). > > > Resent-Reply-To: > > Strike that, it doesn't exist. Ok, I checked RFC 2822 Appendix B 26. > > Disposition-Notification-To: > > Can somebody _please_ start the next "decruft experiment" ? > > > 3. text header > > -> encode by RFC 2047 > > > Subject: > > Comments: > > Keywords: > > Keywords isn't unstructured, can have a comment, > see above. Encapsulating Keywords in Downgraded header is reasonable? -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 17 12:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqPn-0002f8-5s; Tue, 17 Apr 2007 12:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqPm-0002dO-Al for ima@ietf.org; Tue, 17 Apr 2007 12:20:22 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdqPi-0006o3-TD for ima@ietf.org; Tue, 17 Apr 2007 12:20:22 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 73C3B20E; Tue, 17 Apr 2007 12:20:40 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 0953B42BFE; Tue, 17 Apr 2007 12:20:38 -0400 (EDT) Date: Tue, 17 Apr 2007 09:20:15 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1885815561.20070417092015@pobox.com> To: IMA Discussion Subject: Re: [EAI] Re: downgrading target header list In-Reply-To: <20070417.212841.78701675.fujiwara@jprs.co.jp> References: <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <20070417.212841.78701675.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 2007-04-17, fujiwara@jprs.co.jp wrote: >> Bcc should be empty... > agree. Disagree! RFC 2822 - 3.6.3 states that the "BCC:" field may be used in several ways, including sending each blind recipient a copy of the message with only his/her address in the "BCC:" field or possibly sending only to the blind recipients a copy of the message with a "BCC:" field containing all of the blind recipients' addresses. -- Bill McQuillan _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 17 13:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrT6-00038F-9B; Tue, 17 Apr 2007 13:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrT5-000389-0s for ima@ietf.org; Tue, 17 Apr 2007 13:27:51 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrT3-0005hP-EQ for ima@ietf.org; Tue, 17 Apr 2007 13:27:50 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l3HHRcwG025039; Wed, 18 Apr 2007 02:27:43 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007041802273625930 ; Wed, 18 Apr 2007 02:27:36 +0900 Date: Wed, 18 Apr 2007 02:27:36 +0900 (JST) Message-Id: <20070418.022736.112627265.fujiwara@jprs.co.jp> To: McQuilWP@pobox.com Subject: Re: [EAI] Re: downgrading target header list From: fujiwara@jprs.co.jp In-Reply-To: <1885815561.20070417092015@pobox.com> References: <461D1423.3956@xyzzy.claranet.de> <20070417.212841.78701675.fujiwara@jprs.co.jp> <1885815561.20070417092015@pobox.com> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: Bill McQuillan > > On Tue, 2007-04-17, fujiwara@jprs.co.jp wrote: > >> Bcc should be empty... > > > agree. > > Disagree! My 'agree.' is not good... In many cases, Bcc: header is removed by MUA. > RFC 2822 - 3.6.3 states that the "BCC:" field may be used in several ways, > including sending each blind recipient a copy of the message with only > his/her address in the "BCC:" field or possibly sending only to the blind > recipients a copy of the message with a "BCC:" field containing all of the > blind recipients' addresses. and more, RFC 2822 ABNF says: bcc = "Bcc:" (address-list / [CFWS]) CRLF empty Bcc: value is allowed... I considered Bcc is not exist or have some value. Thank you. -- Kazunori Fujiwara, JPRS > -- > Bill McQuillan > > > _______________________________________________ > 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 Apr 17 17:09:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hduvu-0000YJ-HD; Tue, 17 Apr 2007 17:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hduvs-0000VD-UY for ima@ietf.org; Tue, 17 Apr 2007 17:09:48 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hduvq-000363-2n for ima@ietf.org; Tue, 17 Apr 2007 17:09:48 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HdutC-0005eb-Kr for ima@ietf.org; Tue, 17 Apr 2007 23:07:02 +0200 Received: from d255054.dialin.hansenet.de ([80.171.255.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 23:07:02 +0200 Received: from nobody by d255054.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 23:07:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Apr 2007 22:37:16 +0200 Organization: Lines: 31 Message-ID: <46252FFC.4B17@xyzzy.claranet.de> References: <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <20070417.212841.78701675.fujiwara@jprs.co.jp> <1885815561.20070417092015@pobox.com> 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: d255054.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Re: downgrading target header list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Bill McQuillan wrote: >>> Bcc should be empty... >> agree. > Disagree! When downgrading gateways see it it should be empty, RFC 2821 says: | Each recipient address from a TO, CC, or BCC header field SHOULD | be copied to a RCPT command (generating multiple message copies if | that is required for queuing or delivery). This includes any | addresses listed in a RFC 822 "group". Any BCC fields SHOULD then | be removed from the headers. Once this process is completed, the | remaining headers SHOULD be checked to verify that at least one | To:, Cc:, or Bcc: header remains. If none do, then a bcc: header | with no additional information SHOULD be inserted as specified in [RFC 2822]. | Addresses that do not appear in the message headers may appear in the | RCPT commands to an SMTP server for a number of reasons. The two | most common involve the use of a mailing address as a "list exploder" | (a single address that resolves into multiple addresses) and the | appearance of "blind copies". Admittedly RFC 822 and 2822 mention a problematic case, where the Bcc is either kept as is (only in the blind carbon copies), or trimmed to one corresponding address per blind carbon copy. The RFC 2821 recipe appears to be more robust. Frank (waiting how long it takes the "headers" police to find 2821bis) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 18 06:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7Gl-0002jG-8c; Wed, 18 Apr 2007 06:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7Gj-0002iz-Gv for ima@ietf.org; Wed, 18 Apr 2007 06:20:09 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He7Gh-0001QP-Us for ima@ietf.org; Wed, 18 Apr 2007 06:20:09 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew#man#ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4625f0d5.13fcc.2c5 for ima@ietf.org; Wed, 18 Apr 2007 11:20:05 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3IAK4Fx002797 for ; Wed, 18 Apr 2007 11:20:05 +0100 (BST) To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <20070417.212841.78701675.fujiwara@jprs.co.jp> <1885815561.20070417092015@pobox.com> <46252FFC.4B17@xyzzy.claranet.de> Message-ID: Date: Wed, 18 Apr 2007 11:20:03 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46252FFC.4B17@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 17 Apr 2007 21:37:16 +0100, Frank Ellermann wrote: > Bill McQuillan wrote: > >>>> Bcc should be empty... >>> agree. >> Disagree! > > When downgrading gateways see it it should be empty, RFC 2821 says: I think the safest thing to say is the a Bcc is downgradable, just to cover the occasional circumstance where it turns up, but point out that there will rarely be anything there to downgrade. > > | Each recipient address from a TO, CC, or BCC header field SHOULD > | be copied to a RCPT command (generating multiple message copies if > | that is required for queuing or delivery). But it may be the case, for example, that a MUA that finds itself talking to a non-UTF8SMTP MTA will do the downgrade operation _before_ it sets about generating RCPT commands for the MTA. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 18 06:25:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7MI-0005cv-P8; Wed, 18 Apr 2007 06:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7MH-0005cn-Kg for ima@ietf.org; Wed, 18 Apr 2007 06:25:53 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He7MG-0001yx-49 for ima@ietf.org; Wed, 18 Apr 2007 06:25:53 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3*clerew&man^ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4625f22f.2e02.53 for ima@ietf.org; Wed, 18 Apr 2007 11:25:51 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3IAPoHc003153 for ; Wed, 18 Apr 2007 11:25:51 +0100 (BST) To: IMA Subject: Re: [EAI] Re: downgrading target header list References: <20070411.153632.71104159.fujiwara@jprs.co.jp> <461D1423.3956@xyzzy.claranet.de> <20070417.212841.78701675.fujiwara@jprs.co.jp> Message-ID: Date: Wed, 18 Apr 2007 11:25:49 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20070417.212841.78701675.fujiwara@jprs.co.jp> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 17 Apr 2007 13:28:41 +0100, wrote: >> Can somebody _please_ start the next "decruft experiment" ? >> >> > 3. text header >> > -> encode by RFC 2047 >> >> > Subject: >> > Comments: >> > Keywords: >> >> Keywords isn't unstructured, can have a comment, >> see above. > > Encapsulating Keywords in Downgraded header is reasonable? keywords = "Keywords:" phrase *("," phrase) CRLF It should be allowed to downgrade a anywhere that it occurs using RFC 2047, and without any need for an additional Downgraded header. We already do that for s, which are the only other place where s get used according to RFC 2822. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 20 16:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf02m-0001Uc-Uj; Fri, 20 Apr 2007 16:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf02l-0001UJ-PA for ima@ietf.org; Fri, 20 Apr 2007 16:49:23 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf02k-0007qJ-FZ for ima@ietf.org; Fri, 20 Apr 2007 16:49:23 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B8174259757 for ; Fri, 20 Apr 2007 22:49:21 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20722-06 for ; Fri, 20 Apr 2007 22:49:15 +0200 (CEST) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD953259754 for ; Fri, 20 Apr 2007 22:49:15 +0200 (CEST) Date: Fri, 20 Apr 2007 22:48:57 +0200 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========12E106F0142C221FEA65==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Subject: [EAI] Minutes from Prague X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --==========12E106F0142C221FEA65========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Due to my inattention, I have let this slip right until the submission deadline. So the attached file has been submitted as minutes without review from the WG. My apologies. Harald Alvestrand --==========12E106F0142C221FEA65========== Content-Type: text/plain; charset=utf-8; name="EAI minutes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="EAI minutes.txt"; size=6381 EAI Minutes IETF 68 - Prague, Czech Republic 20 March 2007 =20 Eric Burger, Scribe =20 =20 Framework Document ------------------ Issue: Some uncomfortable with wording of MTA / Message Store split. Resolution: Current wording is acceptable to the work group. The document is finished. =20 =20 SMTP Extensions draft-ietf-eai-smtpext-04 ------------------------- Issue: Should a UTF8 server send UTF8 to non-UTF8 hosts? Resolution: Let editors work out and propose to group =20 Issue: Do we need an explicit tag per message indicating the message is = UTF8 (HDR=3DUTF8SMTP)? Discussion: Either transaction states UTF8 is present or the MTA figures it out. On the philosophy (Dave Crocker), "Is it cheap and is it safe?" John Klensin pointed out that every header is expensive, and a few people mentioned that one had to trust all of the next hops. Resolution: VERY ROUGH consensus that we do not need the parameter. Some holdouts to keep the parameter. Will take to list. =20 =20 UTF8 Headers draft-ietf-eai-utf8headers-03 ----------------------------- A few nits in the document, but no substantial issues. New -04 draft to come out which should be ready for WGLC. =20 =20 DSN draft-ietf-eai-dsn-00 --------------------- Issue: Cannot use xtext, because DSN requires the removal of 8-bit characters when going to 7-bit SMTP servers. Already have to encode 5 reserved ASCII characters; today hex-encode Unicode; it should be UTF8 Options: 1. Use xtext for ASCII and something else for UTF-8 2. use %xx encoding of UTF8 or \uxx encoding of Unicode Point: desire to not do double-encoding (although Pete pointed out that there already is double encoding for IRI's) Resolution: NONE (3-3 vote). Take to list =20 Note: Alexey will be the new editor =20 Issue: Should message encoding be application/utf8smtp or message/utf8smtp Discussion: MIME allows 8-bit types, but explicitly prohibits 8-bit message types for message/* Argument in favor of message/utf8smtp: the object is a message. Argument against message/utf8smtp: may break 7-bit implementations Argument for application/utf8smtp: will work with everything, since application/ is supposed to be treated as application/octet-stream Argument against application/utf8smtp: automated DSN processors might barf on 8-bit content Argument against (soft) message/utf8smtp: the use will leak out, e.g., multipart/digest Resolution: do message/utf8smtp; fix broken implementations (if any) =20 Issue: what about utf8headers? Should it be text/utf8header or message/utf8header? Resolution: NONE. Slight preference for message/utf8header, but nowhere = near consensus. Take to list. =20 =20 Downgrade draft-ietf-eai-downgrade-03 --------------------------- Issue: Is upgrading important Discussion: Useful, as we can get rid of RFC 2047 encodings as close to the client as possible. Consideration, however, that this is more of an access protocol (POP, IMAP) issue than SMTP issue. Upgrades break DKIM. Upgrades in the network are likely to be buggy. Upgrades likely to break = signatures. Why would servers, which get graded on speed, spend time doing conversions? =20 Hum called on whether to have no upgrades; upgrade at MTA in network, upgrade at "recipient system" for display, reply address, and checking signature; or upgrade for display and reply address and NOT for checking signature. =20 Resolution: Strong consensus on upgrading at the "recipient system" for display and reply address and NOT for checking signature. =20 At this point, Dave Crocker agrees with John Klensin. John shudders. =20 =20 IMAP draft-ietf-eai-imap-utf8-01 --------------------------- Issue: How to enable UTF8 in IMAP data elements? Modally or with new, UTF8-enabled, commands? Discussion: RFC 3501 states 7-bit only unless explicit charset specified. Proposal: allow all fields to be UTF8 unless otherwise specified Problem: IMAP capabilities model is server advertises capabilities, but server only deduces client capabilities from what the client requests. Proposal: use explicit ENABLE command Discussion: IMAP-EXT and LEMONADE like approach. Resolution: Consensus to use ENABLE command to enter "UTF8 mode" To do: Fix LOGIN command to allow UTF8 (editors) To do: verify ENABLE command OK with IMAP community (Pete Resnick) =20 =20 POP draft-ietf-eai-pop-01 --------------------- Since very few commands, and easy to get modality wrong, consensus is to create new, UTF-enabled, commands. =20 =20 Mailing Lists draft-ietf-eai-mailinglist-01 ----------------------------- Issue: Can we infer that a mailing list that happens to have only ASCII addresses is not a UTF8 mail list? Discussion: No - The recipient's address does not define their = capabilities. Moreover, no hints from a subscription e-mail, as it might be in ASCII or, more likely, the subscription happened over the web. Resolution: Just describe the issues in the text. =20 Issue: What to do with list-* headers: only use ASCII; use UTF8; use IRI's; use multi-valued (ASCII, UTF8) addresses, which is already allowed; use = new, UTF8-specific, headers/ Discussion: The mailto: scheme needs to deal with UTF8 and IRI's Resolution: list-* takes URI's; mailto: is a URI scheme; when mailto: takes IRI's or UTF-8 in the future, this just will work To do: warn developers today list-*'s may be 8-bit today =20 Issue: Should Return-path be ASCII or UTF8SMTP (envelope return path, not list reply address)? Should it always be ASCII, as that will work with everything? Alt-address does not have syntax today. Discussion: For automatically generated messages, e.g., NDN's. Proposal: Provide ASCII and Alt-Address so that it is possible to downgrade the response Resolution: Too early to decide; try some experiments. =20 =20 Scenarios Document draft-ietf-eai-scenarios ------------------------ Issue: Publish, hold, or let draft lapse? Resolution: Hold the document =20 =20 Downgrade draft-ietf-eai-downgrade-03 --------------------------- Issue: What to do about uFor in Received: header? Discussion: Current text says to delete it. Problem is total loss of traceability. Proposal: Encourage gateways to insert additional Received: headers and put the original information in comments, e.g., Received: by ME for ME ; describe what happened To do: John Klensin to write text --==========12E106F0142C221FEA65========== 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 --==========12E106F0142C221FEA65==========-- From ima-bounces@ietf.org Tue Apr 24 05:48:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHdP-0005ud-0d; Tue, 24 Apr 2007 05:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHdN-0005uS-Vi for ima@ietf.org; Tue, 24 Apr 2007 05:48:29 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgHdL-0006Bu-C0 for ima@ietf.org; Tue, 24 Apr 2007 05:48:29 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew&man&ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 462dd269.34b8.31f for ima@ietf.org; Tue, 24 Apr 2007 10:48:25 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3O9mOpg014062 for ; Tue, 24 Apr 2007 10:48:25 +0100 (BST) Subject: Fwd: Re: [EAI] Minutes from Prague References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 24 Apr 2007 10:48:23 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Seems I sent this just to Harald, and not the list, which explains why he replied to me only :-( . ------- Forwarded message ------- From: "Charles Lindsey" To: "Harald Tveit Alvestrand" Subject: Re: [EAI] Minutes from Prague Date: Mon, 23 Apr 2007 11:34:50 +0100 On Fri, 20 Apr 2007 21:48:57 +0100, Harald Tveit Alvestrand wrote: > Due to my inattention, I have let this slip right until the submission > deadline. > So the attached file has been submitted as minutes without review from > the > WG. And from the minutes: .................. DSN draft-ietf-eai-dsn-00 --------------------- Issue: Should message encoding be application/utf8smtp or message/utf8smtp Discussion: MIME allows 8-bit types, but explicitly prohibits 8-bit message types for message/* Argument in favor of message/utf8smtp: the object is a message. Argument against message/utf8smtp: may break 7-bit implementations Argument for application/utf8smtp: will work with everything, since application/ is supposed to be treated as application/octet-stream Argument against application/utf8smtp: automated DSN processors might barf on 8-bit content Argument against (soft) message/utf8smtp: the use will leak out, e.g., multipart/digest Resolution: do message/utf8smtp; fix broken implementations (if any) ................... I don't understand the proposed resolution here. It violates a very explicit "EXPRESSLY FORBIDDEN" in RFC 2045, so you can hardly describe an implementation that does not expect to see 8bit where 8bit is expressly forbidden as "broken" and "to be fixed". So what am I missing? And the dicussion completely failed to consider the third possibility of using message/rfc822, downgraded as necessary before it is allowed to be seen in the non-UTF8SMTP universe (but presumably upgraded again for display by recipients so capable). Moreover, since we seemed to have abandoned any HDR=UFT8SMTP parameter in SMTP, downgraders are going to have to recognize and deal with any 8bit headers contained within a message/rfc822, just as they are going to have to recognize and deal with them within mime body headerts within any multipart. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 24 10:01:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLaJ-00012b-36; Tue, 24 Apr 2007 10:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLaH-00012R-Kq for ima@ietf.org; Tue, 24 Apr 2007 10:01:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgLaG-00080i-3Y for ima@ietf.org; Tue, 24 Apr 2007 10:01:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HgLa9-000130-GU for ima@ietf.org; Tue, 24 Apr 2007 16:01:25 +0200 Received: from 1cust218.tnt5.hbg2.deu.da.uu.net ([149.225.16.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Apr 2007 16:01:25 +0200 Received: from nobody by 1cust218.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Apr 2007 16:01:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 24 Apr 2007 15:51:03 +0200 Organization: Lines: 38 Message-ID: <462E0B47.6564@xyzzy.claranet.de> References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> 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: 1cust218.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [EAI] Re: Fwd: Re: Minutes from Prague X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > downgraders are going to have to recognize and deal with any 8bit > headers contained within a message/rfc822 By definition there are no 8bit header fields in a message/rfc822, downgraders and others would look for UTF-8 in header field bodies if they need or wish to identify a superset of the message/rfc822 format dubbed as message/utf-8. And John apparently wants to limit this to some precisely defined places in known header fields, instead of taking the simpler "any UTF-8 can be fine for message/utf-8, nobody cares about the syntax in transit" approach. What you're talking about is apparently the UNKNOWN-8BIT seen in "some" (syntactically invalid) message/rfc822 today, without EAI. We've to solve the first problem, valid message/utf-8. We're not forced to solve the second problem, UNKNOWN-8BIT in a header of something that's certainly syntactically invalid, with or without EAI. Implementation details, a harsh recipe is "reject", but it might be the best solution. A really *odd* recipe would be "just turn off the 8th bit", IMO that deserves a MUST NOT. And a very sophisticated downgrade implementation might try to preseve any UNKNOWN-8BIT somehow, for critical header fields where it knows the structure (otherwise using RFC 2047 could fail miserably). > just as they are going to have to recognize and deal with them > within mime body headerts within any multipart. There is no UNKNOWN-8BIT in valid MIME part headers. There are also no addresses in MIME part headers, or rather I'm not aware of any addresses in any Content-* header field, unless you'd put them in a comment. So why is this a topic for this WG (= EAI) ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 26 15:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9zB-0007QG-MV; Thu, 26 Apr 2007 15:50:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9z7-0007ME-1Y; Thu, 26 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hh9z6-0003y9-Nl; Thu, 26 Apr 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A4D7F2ACA6; Thu, 26 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hh9yc-00069f-E8; Thu, 26 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-05.txt Pages : 15 Date : 2007-4-26 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-26123826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-26123826.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Apr 26 17:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhB7H-00019J-MW; Thu, 26 Apr 2007 17:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhB7F-00018W-F0 for ima@ietf.org; Thu, 26 Apr 2007 17:03:01 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhB7E-0004sx-4n for ima@ietf.org; Thu, 26 Apr 2007 17:03:01 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3386C25975A; Thu, 26 Apr 2007 23:02:59 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22851-06; Thu, 26 Apr 2007 23:02:54 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43DF8259742; Thu, 26 Apr 2007 23:02:54 +0200 (CEST) Date: Thu, 26 Apr 2007 23:02:42 +0200 From: Harald Tveit Alvestrand To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: Fwd: Re: Minutes from Prague Message-ID: <0589C738F42DFA3B1AE828DE@[192.168.1.119]> In-Reply-To: <462E0B47.6564@xyzzy.claranet.de> References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 24. april 2007 15:51 +0200 Frank Ellermann wrote: > We've to solve the first problem, valid message/utf-8. We're not > forced to solve the second problem, UNKNOWN-8BIT in a header of > something that's certainly syntactically invalid, with or without > EAI. Implementation details, a harsh recipe is "reject", but it > might be the best solution. A really *odd* recipe would be "just > turn off the 8th bit", IMO that deserves a MUST NOT. And a very > sophisticated downgrade implementation might try to preseve any > UNKNOWN-8BIT somehow, for critical header fields where it knows > the structure (otherwise using RFC 2047 could fail miserably). I believe that both PP and Exim defaulted to "strip the 8th bit" for quite a while. I'm not sure what current mailers default to. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 26 17:18:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBMN-0002DS-93; Thu, 26 Apr 2007 17:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBML-0002DN-16 for ima@ietf.org; Thu, 26 Apr 2007 17:18:37 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBMJ-00009o-HX for ima@ietf.org; Thu, 26 Apr 2007 17:18:37 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFDD525975A for ; Thu, 26 Apr 2007 23:18:34 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23285-05 for ; Thu, 26 Apr 2007 23:18:29 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id C540D259742 for ; Thu, 26 Apr 2007 23:18:29 +0200 (CEST) Date: Thu, 26 Apr 2007 23:18:18 +0200 From: Harald Tveit Alvestrand To: ima@ietf.org Subject: Re: [EAI] Minutes from Prague (fwd) Message-ID: <69DEB4ACF63843407008496D@[192.168.1.119]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Since Charles forwarded his comment to the list, I'm assuming that he did not consider my comment below convincing. Harald ------------ Forwarded Message ------------ Date: 23. april 2007 12:47 +0200 From: Harald Alvestrand To: Charles Lindsey Subject: Re: [EAI] Minutes from Prague Charles Lindsey wrote: > On Fri, 20 Apr 2007 21:48:57 +0100, Harald Tveit Alvestrand > wrote: > >> Due to my inattention, I have let this slip right until the submission >> deadline. >> So the attached file has been submitted as minutes without review >> from the >> WG. > > And from the minutes: > > .................. > DSN > draft-ietf-eai-dsn-00 > --------------------- > > Issue: Should message encoding be application/utf8smtp or > message/utf8smtp > Discussion: MIME allows 8-bit types, but explicitly prohibits 8-bit > message > types for message/* > Argument in favor of message/utf8smtp: the object is a message. > Argument against message/utf8smtp: may break 7-bit implementations > Argument for application/utf8smtp: will work with everything, since > application/ is supposed to be treated as > application/octet-stream > Argument against application/utf8smtp: automated DSN processors might > barf > on 8-bit content > Argument against (soft) message/utf8smtp: the use will leak out, e.g., > multipart/digest > Resolution: do message/utf8smtp; fix broken implementations (if any) > ................... > > I don't understand the proposed resolution here. It violates a very > explicit "EXPRESSLY FORBIDDEN" in RFC 2045, so you can hardly describe > an implementation that does not expect to see 8bit where 8bit is > expressly forbidden as "broken" and "to be fixed". So what am I missing? The fact that some of us considered the prohibition from RFC 2045 stupid? > > And the dicussion completely failed to consider the third possibility > of using message/rfc822, downgraded as necessary before it is allowed > to be seen in the non-UTF8SMTP universe (but presumably upgraded again > for display by recipients so capable). Yes, it failed to consider this possibility. Rather, there was nobody in the room who had taken leave of his senses enough to seriously want to advance such a suggestion. Your suggestion has NOT seen any support on the list. And for good reason. > > Moreover, since we seemed to have abandoned any HDR=UFT8SMTP parameter > in SMTP, downgraders are going to have to recognize and deal with any > 8bit headers contained within a message/rfc822, just as they are going > to have to recognize and deal with them within mime body headerts > within any multipart. I don't see a connection here. ---------- End Forwarded Message ---------- _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 27 01:14:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhIn3-00039L-Gf; Fri, 27 Apr 2007 01:14:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhIYU-0006X0-VJ; Fri, 27 Apr 2007 00:59:38 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhIYT-0000Tn-K6; Fri, 27 Apr 2007 00:59:38 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Thu, 26 Apr 2007 23:59:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Thu, 26 Apr 2007 23:59:37 -0500 To: IETF-POP3EXT:;, IETF-IMAPEXT:;, IETF-SMTP:;, LEMONADE:;, IMA:; From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Fri, 27 Apr 2007 01:14:40 -0400 Subject: [EAI] Fwd: draft-resnick-2822upd-01 posted X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. Also: To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 27 09:00:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQ3V-0001RL-FR; Fri, 27 Apr 2007 09:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQ3Q-0001KB-OP for ima@ietf.org; Fri, 27 Apr 2007 09:00:05 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQ3N-0001ed-0d for ima@ietf.org; Fri, 27 Apr 2007 09:00:04 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew#man#ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4631f3cf.13c62.51 for ima@ietf.org; Fri, 27 Apr 2007 13:59:59 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3RCxvOw010338 for ; Fri, 27 Apr 2007 13:59:59 +0100 (BST) Date: Fri, 27 Apr 2007 13:59:57 +0100 To: IMA Subject: Re: [EAI] Minutes from Prague (fwd) References: <69DEB4ACF63843407008496D@[192.168.1.119]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <69DEB4ACF63843407008496D@[192.168.1.119]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 26 Apr 2007 22:18:18 +0100, Harald Tveit Alvestrand wrote: > Since Charles forwarded his comment to the list, I'm assuming that he > did not consider my comment below convincing. > ------------ Forwarded Message ------------ > Date: 23. april 2007 12:47 +0200 > From: Harald Alvestrand > To: Charles Lindsey > Subject: Re: [EAI] Minutes from Prague > > Charles Lindsey wrote: >> On Fri, 20 Apr 2007 21:48:57 +0100, Harald Tveit Alvestrand >> wrote: >> And from the minutes: >> >> .................. >> DSN >> draft-ietf-eai-dsn-00 >> --------------------- >> >> Issue: Should message encoding be application/utf8smtp or >> message/utf8smtp >> Discussion: MIME allows 8-bit types, but explicitly prohibits 8-bit >> message >> types for message/* >> Argument in favor of message/utf8smtp: the object is a message. >> Argument against message/utf8smtp: may break 7-bit implementations >> Argument for application/utf8smtp: will work with everything, since >> application/ is supposed to be treated as >> application/octet-stream >> Argument against application/utf8smtp: automated DSN processors might >> barf >> on 8-bit content >> Argument against (soft) message/utf8smtp: the use will leak out, e.g., >> multipart/digest >> Resolution: do message/utf8smtp; fix broken implementations (if any) >> ................... >> >> I don't understand the proposed resolution here. It violates a very >> explicit "EXPRESSLY FORBIDDEN" in RFC 2045, so you can hardly describe >> an implementation that does not expect to see 8bit where 8bit is >> expressly forbidden as "broken" and "to be fixed". So what am I missing? > The fact that some of us considered the prohibition from RFC 2045 stupid? Yes, we all agree that it is stupid, but RFC 2045 is a Draft Standard; that is what it says, so you cannot complain if that is what people have implemented. The scenario we are considering is where a UTF8SMTP-aware MTA has generated a DSN which includes the whole of the original message, and it finds that it has to send it via some non-UTF8SMTP server. Moreover, the next hop beyond that one may not even support 8BITMIME. Now I can only speak for sendmail, because I have studied its relevant source code. It the DSN includes a message/utf8smtp with C_T_E: 8bit (which is allowed) and the next hop does not do 8BITMIME, then sendmail WILL NOT attempt to change it to C_T_E: Q-P (or Base64) - it will just send the 8bits and hope for the best. I don't know what other servers do, but it would not surprise me if they behaved similarly. But, in any case, sendmail is a significant part of the currently installed server-base, and it was my understanding that EAI is intended to interoperate with that existing base. OTOH if the returned message in the DSN is sent as an application/utf8smtp, or as a properly downgraded message/rfc822, then sendmail (and I presume all other servers) will then downgrade it correctly if asked to forward it to a non-8BITMIME system. Now you might well be able to persuade the implementors of sendmail that it is "broken" and should be "fixed". But even then there would still be a large installed base of earlier implemenations. The efforts of the sendmail implementors would be better spent on doing a decent implementation of full UTF8SMTP. >> >> And the dicussion completely failed to consider the third possibility >> of using message/rfc822, downgraded ... > > Your suggestion has NOT seen any support on the list. And for good > reason. Such as "it would actually work"? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 27 09:14:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQHm-0001G2-Da; Fri, 27 Apr 2007 09:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQHl-0001Fw-VM for ima@ietf.org; Fri, 27 Apr 2007 09:14:53 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQHk-00068X-DD for ima@ietf.org; Fri, 27 Apr 2007 09:14:53 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew$man$ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4631f74b.14583.3f3 for ima@ietf.org; Fri, 27 Apr 2007 14:14:51 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3RDEoqW011236 for ; Fri, 27 Apr 2007 14:14:51 +0100 (BST) To: IMA Subject: Re: [EAI] Re: Fwd: Re: Minutes from Prague References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> Message-ID: Date: Fri, 27 Apr 2007 14:14:50 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <462E0B47.6564@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 24 Apr 2007 14:51:03 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > >> downgraders are going to have to recognize and deal with any 8bit >> headers contained within a message/rfc822 > > By definition there are no 8bit header fields in a message/rfc822, > downgraders and others would look for UTF-8 in header field bodies > if they need or wish to identify a superset of the message/rfc822 > format dubbed as message/utf-8. No existing 8BITMIME downgrader is going to "look for UTF-8 in header field bodies" whether it is dubbed as message/utf-8 or as message/anything-else, so such things must never be seen outside the UTF8SMTP universe. > > And John apparently wants to limit this to some precisely defined > places in known header fields, instead of taking the simpler "any > UTF-8 can be fine for message/utf-8, nobody cares about the syntax > in transit" approach. I think you would have to accept whatever our utf8headers document allows - no more and no less, so that excludes any UNKNOWN-8BIT (so garbage-in -> garbage-out would apply, since detecting that case is more trouble than any expected benefit). > There is no UNKNOWN-8BIT in valid MIME part headers. There are > also no addresses in MIME part headers, or rather I'm not aware > of any addresses in any Content-* header field, unless you'd put > them in a comment. So why is this a topic for this WG (= EAI) ? Indeed. The only things currently proposed to be allowed in Content-* headers are UTF-8 in s (rare, but possible) and UTF-8 on the RHS of s (for which RFC 2231 can be used). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 27 14:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVaD-0002us-2U; Fri, 27 Apr 2007 14:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVaA-0002uj-LT for ima@ietf.org; Fri, 27 Apr 2007 14:54:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVa8-0005SH-Q2 for ima@ietf.org; Fri, 27 Apr 2007 14:54:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HhVZw-0002ow-OH for ima@ietf.org; Fri, 27 Apr 2007 20:54:00 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Apr 2007 20:54:00 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Apr 2007 20:54:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 27 Apr 2007 21:53:50 +0300 Lines: 71 Message-ID: <5dvefhwsw1.fsf@Hurtta06k.keh.iki.fi> References: <69DEB4ACF63843407008496D@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Charles Lindsey , Kari Hurtta Subject: [EAI] Re: Minutes from Prague (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > Since Charles forwarded his comment to the list, I'm assuming that he > did not consider my comment below convincing. > > > And the dicussion completely failed to consider the third possibility > > of using message/rfc822, downgraded as necessary before it is allowed > > to be seen in the non-UTF8SMTP universe (but presumably upgraded again > > for display by recipients so capable). > Yes, it failed to consider this possibility. Rather, there was nobody in > the room who had taken leave of his senses enough to seriously want to > advance such a suggestion. > > Your suggestion has NOT seen any support on the list. And for good reason. Well at least I have mentioned that possibility: "message/utf-8 can be downgraded to message/rfc822 or converted to multipart/utf8-encapsulated." So I do not think that your claim is completely true. ( There is perhaps some other messages, but that I least found. ) / Kari Hurtta -------------------------------------------------------------------- From: Kari Hurtta Subject: Re: [EAI] Re: 8to7 downgrade and message/* Newsgroups: gmane.ietf.ima To: ima@ietf.org Date: 03 Feb 2007 23:42:01 +0200 Frank Ellermann writes in gmane.ietf.ima: > > Effectively gateways are required bounce unknown message/* types > > if they include 8-bit. > > Okay, so we should offer a better solution for message/utf-8 and > family for the purpose of 8BITMIME to 7bit gateways - nobody else > needs this. While we're at it let's support any message subtype, > including invalid message/rfc822 headers with UNKNOWN-8BIT octets. Yes. Note that providers of that solution are UTF8SMTP to rfc(2)822 gateways. They must do that munging so that there is not these message/utf-8, message/utf-8-headers and so on types. > How about an application/message-munged with a mandatory parameter > indicating the original message subtype ? Where "munged" could be > defined as a very radical procedure: Take the complete unknown > message part (or a complete invalid message/rfc822 part), gzip it, > B64 it, ready. Maybe gzip is overkill. message/utf-8 can be downgraded to message/rfc822 or converted to multipart/utf8-encapsulated. message/utf-8-headers is better replaced with text/utf8-header Then there is left message/utf-8-delivery-status and message/utf-8-disposition-notification There is some details which need to be figured out. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 28 02:33:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhgUL-0007C0-Ei; Sat, 28 Apr 2007 02:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhgUK-0007Ao-1G for ima@ietf.org; Sat, 28 Apr 2007 02:32:56 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhgUJ-0000yn-8q for ima@ietf.org; Sat, 28 Apr 2007 02:32:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HhgUE-0003DA-Hv for ima@ietf.org; Sat, 28 Apr 2007 08:32:50 +0200 Received: from 212.82.251.84 ([212.82.251.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Apr 2007 08:32:50 +0200 Received: from nobody by 212.82.251.84 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Apr 2007 08:32:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 28 Apr 2007 08:26:24 +0200 Organization: Lines: 78 Message-ID: <4632E910.723@xyzzy.claranet.de> References: <69DEB4ACF63843407008496D@[192.168.1.119]> 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: 212.82.251.84 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [EAI] MIME prohibition stupid vs. brilliant (was: Minutes from Prague (fwd)) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: >> I don't understand the proposed resolution here. It violates a very >> explicit "EXPRESSLY FORBIDDEN" in RFC 2045, so you can hardly describe >> an implementation that does not expect to see 8bit where 8bit is >> expressly forbidden as "broken" and "to be fixed". So what am I missing? > The fact that some of us considered the prohibition from RFC 2045 stupid? Now I'm confused. It's no stupid prohibition. It's based on three assumptions: (1) Messages consist of an ASCII header and a body. (2) The body can be structured and/or encoded as specified in the header of the message. (3) Eveybody knows how a message/rfc822 is structured, and how it specifies the encoding of its body, because the message/rfc822 structure is what MIME and RFC 2045 are about. So if you put a message/rfc822 as part (or as part of a part, etc.) into a MIME message, which is by definition also a message/rfc822, then it makes no sense to specify a CTE like base64 for this part, it would encode the complete message, header, body, any parts the embedded message has, all. However a CTE like 8bit in the MIME part header of the embedded message protects the visible message structure, its ASCII header is still directly visible, its ASCII MIME part headers (if it's also structured) are still directly visible, and any part of the embedded message that is neither a message nor a multipart has its own header that can use its own CTE (including base64 or QP). You can also put the 8BITMIME message into a 7bit message: Keep its ASCII header and its ASCII MIME part headers as they are, and flip any CTE 8bit (or binary, but my example is 8bit) you find in non-composite parts of this message to base64. And of course encode those parts using B64. The complete structure is still visible, any embedded parts that were already 7bit are directly readable for MIME unaware user agents. And actually you do that recursively depth first, flip CTE to B64 or QP as needed for non-composite parts, keep the MIME structure including all MIME part headers as is, and replace any composite 8bit CTE by 7bit for this procedure. A message containing among other parts a message, the embedded message containing among other parts a message, no problem, you can freely flip them from 8bit to 7bit while still preserving their visible ASCII structure + all visible ASCII parts, And of course all ASCII message and MIME part headers are visible. Without that prohibition parts of the MIME structure (complete messages or complete multiparts) would be "hidden" in the form of base64 garbage, that's not nice to MIME-unaware user agents. MIME has builtin maximum backwards compatibility, that's not stupid, it's brilliant. I'd wish all protocols were designed that way. Of course we now have a "minor" problem here for EAI, one of the three assumptions mentioned above is wrong, and conclusions based on these three assumptions are suddenly utter dubious. But that doesn't force us to violate the EXPRESSLY FORBIDDEN rule. If we can't have CTE b64 for message subtypes, we just roll our own application/message where we can use B64 as it pleases us. After all it's just a name, the "desired" effect of completely encoding an embedded 8bit message/xyz (thereby hiding its header + structure for MIME unaware UAs) is the same, no matter if we say "application/message" following the rules, or if we force B64 at a place where it's not allowed. And IMO all these 8bit to 7bit considerations are not really the job of EAI. We can do that based on Kari's draft, or on a hypothetical draft defining application/message, but it's not required for the EAI experiment: As far as UTF8SMTP is concerned the whole world uses 8BITMIME. If somebody still uses 7bit his 8BITMIME to 7bit problems are no EAI problems. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 28 03:48:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhhf3-0003lU-58; Sat, 28 Apr 2007 03:48:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhhf2-0003lJ-Ac for ima@ietf.org; Sat, 28 Apr 2007 03:48:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhhf0-0002dM-Iz for ima@ietf.org; Sat, 28 Apr 2007 03:48:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hhhes-000445-Bm for ima@ietf.org; Sat, 28 Apr 2007 09:47:54 +0200 Received: from 212.82.251.84 ([212.82.251.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Apr 2007 09:47:54 +0200 Received: from nobody by 212.82.251.84 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Apr 2007 09:47:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 28 Apr 2007 09:45:51 +0200 Organization: Lines: 61 Message-ID: <4632FBAF.5966@xyzzy.claranet.de> References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> 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: 212.82.251.84 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [EAI] Strip 8th bit (was: Fwd: Re: Minutes from Prague) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > I believe that both PP and Exim defaulted to "strip the 8th bit" > for quite a while. I'm not sure what current mailers default to. Yesterday I saw that it's a MAY in RFC 2821, may strip MSB, or may reject the message as FUBAR. For my application/message idea I thought about how that could be done by a an 8to7-script: The input is an 8BITMIME message/rfc822. The algorithm 8to7( x ) would work something like this: 1: Split x into header and body 2: Strip 8th bit in the header (it's supposed to be ASCII) 3: Check if content-type is multipart/* (5) or message/* (6) 4: non-composite part 4.1: For no CTE: strip 8th bit in the part, return 4.2: For CTE 7bit: strip 8th bit in the part, return 4.3: For CTE B64: strip 8th bit in the part, return 4.4: For CTE QP: strip 8th bit in the part, return 4.5: For CTE 8bit replace CTE B64, encode and return 4.6: For CTE binary or unknown CTEs abort with error 5: multipart/* 5.1: For CTE binary or unknown CTEs abort with error 5.2: For CTE B64 or QP abort with error <= EXPRESSLY FORBIDDEN 5.3: For CTE 7bit: strip 8th bit in the part, return 5.4: For CTE 8bit replace CTE 7bit 5.4.1: strip 8th bit in the MIME part header 5.4.2: For each part do 5.4.2.1: for a multipart use the procedure in step 5, iterate 5.4.2.2: for message/rfc822 use procedure for step 1, iterate 5.4.2.3: if it's a non-composite part (no message/*) 5.4.2.3.1: strip 8th bit in the MIME part header 5.4.2.3.2: use procedure in step 4, iterate (next part at 5.4.2) 5.4.2.4: convert message/* to an application/message, iterate 5.5: No more parts in the multipart/* at 5.4.2, return 6: message/* 6.1: For CTE binary or unknown CTEs abort with error 6.2: For CTE B64 or QP abort with error <= EXPRESSLY FORBIDDEN 6.3: For CTE 7bit: strip 8th bit in the part, return 6.4: for a message/rfc822 use the procedure in step 1, return 6.5: convert message/* to an application/message, return The "conversion" to application/message could be to grab all lines between the boundaries, B64 encode them as is, insert a MIME part header Content-Type: application/message, CTE B64, no parameter, no other Content-*, no UTF-8 comments ;-), keep the encoded original message as "body" of this part, ready. If minimal MIME conformance requires to support message/partial and/or message/external-body add the missing steps. Shall we try this application/message idea as special EAI contribution to the existing solutions for "8BITMIME to 7bit" gateways ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 30 06:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTaB-0000Nt-6b; Mon, 30 Apr 2007 06:58:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTa9-0000Nl-Ow for ima@ietf.org; Mon, 30 Apr 2007 06:58:13 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HiTa6-0000Kx-LA for ima@ietf.org; Mon, 30 Apr 2007 06:58:13 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3*clerew^man#ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4635cbc0.1087a.2fa for ima@ietf.org; Mon, 30 Apr 2007 11:58:08 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3UAw7gr003429 for ; Mon, 30 Apr 2007 11:58:08 +0100 (BST) To: IMA Subject: Re: [EAI] Strip 8th bit (was: Fwd: Re: Minutes from Prague) References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> <4632FBAF.5966@xyzzy.claranet.de> Message-ID: Date: Mon, 30 Apr 2007 11:58:07 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4632FBAF.5966@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 28 Apr 2007 08:45:51 +0100, Frank Ellermann wrote: > Harald Tveit Alvestrand wrote: > >> I believe that both PP and Exim defaulted to "strip the 8th bit" >> for quite a while. I'm not sure what current mailers default to. > > Yesterday I saw that it's a MAY in RFC 2821, may strip MSB, or may > reject the message as FUBAR. Clearly, bouncing the message as FUBAR is always the safe option. But I think it better, if you are determined to try to continue with delivery, just to send the 8bits regardless rather than to strip the MSB (this is what sendmail does AFAICT). Stripping the MSB clearly damages the message, certainly creating garbage of what may or may not have been garbage in the first place. Sending the 8bits regardless may well result in garbage at the far end (the far end might even truncate the MSB). But the garbage seen in this case will certainly be no worse than the garbage seen in the strip-MSB case (it may even show up as the same garbage). But there still remains a (small) possibility that it will show up as something sensible, or at least something that a determined recipient can disentangle manually. So it is a choice between being definitely worse off and probably/possibly being worse off. And it is strictly of-topic for this group, though possibly interesting for understanding the environment in which we have to operate. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 30 10:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWhJ-0006JO-Tc; Mon, 30 Apr 2007 10:17:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWhI-0006JD-Ig for ima@ietf.org; Mon, 30 Apr 2007 10:17:48 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWhH-0005Ro-8n for ima@ietf.org; Mon, 30 Apr 2007 10:17:48 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 513202596D6; Mon, 30 Apr 2007 16:17:46 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28319-02; Mon, 30 Apr 2007 16:17:41 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3663B2596CB; Mon, 30 Apr 2007 16:17:41 +0200 (CEST) Message-ID: <4635FA85.7020104@alvestrand.no> Date: Mon, 30 Apr 2007 16:17:41 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] MIME prohibition stupid vs. brilliant References: <69DEB4ACF63843407008496D@[192.168.1.119]> <4632E910.723@xyzzy.claranet.de> In-Reply-To: <4632E910.723@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: > Harald Tveit Alvestrand wrote: > > >>> I don't understand the proposed resolution here. It violates a very >>> explicit "EXPRESSLY FORBIDDEN" in RFC 2045, so you can hardly describe >>> an implementation that does not expect to see 8bit where 8bit is >>> expressly forbidden as "broken" and "to be fixed". So what am I missing? >>> > > >> The fact that some of us considered the prohibition from RFC 2045 stupid? >> > > Now I'm confused. It's no stupid prohibition. It's based on three > assumptions: (1) Messages consist of an ASCII header and a body. > (2) The body can be structured and/or encoded as specified in the > header of the message. (3) Eveybody knows how a message/rfc822 is > structured, and how it specifies the encoding of its body, because > the message/rfc822 structure is what MIME and RFC 2045 are about. > The thing that is (possibly) stupid is extending this restriction across every future MIME type that starts with the letters "message/". See RFC 2046 section 5.2.2 for the rather specific restrictions on encoding for message/partial. The content of a message/partial doesn't consist of an ASCII header and a body, so I lost you at (1). Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 30 10:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWlm-0008LN-63; Mon, 30 Apr 2007 10:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWlk-0008KO-VN for ima@ietf.org; Mon, 30 Apr 2007 10:22:24 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWlj-0006D3-8C for ima@ietf.org; Mon, 30 Apr 2007 10:22:24 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A82C82596D6; Mon, 30 Apr 2007 16:22:22 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28319-06; Mon, 30 Apr 2007 16:22:14 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C1182596CB; Mon, 30 Apr 2007 16:22:14 +0200 (CEST) Message-ID: <4635FB95.3020900@alvestrand.no> Date: Mon, 30 Apr 2007 16:22:13 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] Re: Minutes from Prague (fwd) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <5dvefhwsw1.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5dvefhwsw1.fsf@Hurtta06k.keh.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Harald Tveit Alvestrand writes in gmane.ietf.ima: > > >> Since Charles forwarded his comment to the list, I'm assuming that he >> did not consider my comment below convincing. >> >> > > >>> And the dicussion completely failed to consider the third possibility >>> of using message/rfc822, downgraded as necessary before it is allowed >>> to be seen in the non-UTF8SMTP universe (but presumably upgraded again >>> for display by recipients so capable). >>> >> Yes, it failed to consider this possibility. Rather, there was nobody in >> the room who had taken leave of his senses enough to seriously want to >> advance such a suggestion. >> >> Your suggestion has NOT seen any support on the list. And for good reason. >> > > Well at least I have mentioned that possibility: > "message/utf-8 can be downgraded to message/rfc822 or converted to > multipart/utf8-encapsulated." > > So I do not think that your claim is completely true. > > Downgrading to message/rfc822 is not completely beyond the realm of the reasonable (imho). The "unsupported" I was pointing out was the idea of transporting UTF8SMTP messages inside the UTF8SMTP cloud with a MIME type of message/rfc822. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 30 14:35:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiaii-0004RK-6Y; Mon, 30 Apr 2007 14:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiaih-0004RD-0a for ima@ietf.org; Mon, 30 Apr 2007 14:35:31 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiaif-0006C1-BB for ima@ietf.org; Mon, 30 Apr 2007 14:35:30 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hiaie-000PsZ-Dr; Mon, 30 Apr 2007 14:35:28 -0400 Date: Mon, 30 Apr 2007 14:35:27 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Strip 8th bit (was: Fwd: Re: Minutes from Prague) Message-ID: <2FA402DB7D855174A6072E72@p3.JCK.COM> In-Reply-To: References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> <4632FBAF.5966@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (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: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 30 April, 2007 11:58 +0100 Charles Lindsey wrote: > On Sat, 28 Apr 2007 08:45:51 +0100, Frank Ellermann > wrote: > >> Harald Tveit Alvestrand wrote: >> >>> I believe that both PP and Exim defaulted to "strip the 8th >>> bit" for quite a while. I'm not sure what current mailers >>> default to. >> >> Yesterday I saw that it's a MAY in RFC 2821, may strip MSB, >> or may reject the message as FUBAR. > > Clearly, bouncing the message as FUBAR is always the safe > option. > > But I think it better, if you are determined to try to > continue with delivery, just to send the 8bits regardless > rather than to strip the MSB (this is what sendmail does > AFAICT). But this is exactly the "just-send-8" option that was rejected during the original MIME work, rejected again when MIME advanced to Draft, and rejected again by DRUMS (and maybe a few other times). Even if you were right, it would be too late. >.... > And it is strictly of-topic for this group, though possibly > interesting for understanding the environment in which we have > to operate. So, why are you bringing it up here? And why am bothering to respond to it, rather than considering it an indication that I should start filtering your mail out as frequently containing off-topic discussions? (You can, and probably should, treat both questions as rhetorical.) john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima