From ima-bounces@ietf.org Sun Apr 02 14:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ6yz-000054-7h; Sun, 02 Apr 2006 14:07:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ6yx-00004q-Qs for ima@ietf.org; Sun, 02 Apr 2006 14:07:23 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ6yw-0002k7-5y for ima@ietf.org; Sun, 02 Apr 2006 14:07:23 -0400 Received: from [10.0.1.4] (bb-87-80-192-157.ukonline.co.uk [87.80.192.157]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 2 Apr 2006 19:07:17 +0100 Message-ID: <443012CD.7050008@isode.com> Date: Sun, 02 Apr 2006 19:07:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [EAI] Comments on draft-yao-ima-smtpext-02.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 Hi, I have a couple of comments on draft-yao-ima-smtpext-02.txt. (Please kindly point me to the archive if this was already discussed) 1) I think the document needs to describe its interaction with the DSN SMTP extension, for example, what should be put into ORCPT parameter on forwarding to a single recipient alias, when the next hop supports both the IEmail and the DSN SMTP extensions. I.e. should it be the downgraded address or the I18N address? 2). The WG should discuss if changes to Delivery Status Notification format are in scope for the WG, in particular extensions to allow for I18N addresses. This ties to John's comment about bounces containing addresses which are not meaningful for the sender. 3). (Ignoring for the moment the discussion about whether ATOMIC should be removed from the spec or not) Minor comment about the ATOMIC parameter name. I think "ATOMIC" as a parameter name is misleading, as it brings associations with [database] transaction atomicity, maybe something like "AUTODERIVED" would be better. Also, there are a couple of places where ATOMIC is misspelled as ATMOIC. Regards, Alexey _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Apr 02 16:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ8qA-0005EU-MG; Sun, 02 Apr 2006 16:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ8q8-00054b-Ro for ima@ietf.org; Sun, 02 Apr 2006 16:06:24 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ8q7-000727-Bb for ima@ietf.org; Sun, 02 Apr 2006 16:06:24 -0400 Received: from [10.0.1.4] (bb-87-80-192-157.ukonline.co.uk [87.80.192.157]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 2 Apr 2006 21:06:17 +0100 Message-ID: <44302EB4.7030603@isode.com> Date: Sun, 02 Apr 2006 21:06:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "ima@ietf.org" MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [EAI] Comments on draft-yoneya-ima-downgrade-01.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 Some detailed questions/comments on the draft below: >3.2. Mail Header Downgrading > > Target of downgrading elements in mail headers (SMTP data) are below: > > Originator address(es): IMA in From, Reply-To and Sender and their > Resent- headers MUST be target of downgrading. > Destination address(es): IMA in To and Cc and their Recent- headers > MUST be target of downgrading. Should Bcc header field be in this list as well (also elsewhere in the document)? What about various List-* header fields that can contain mailto URLs? > IDs: IDs such as Message-ID, In-Reply-To and Referenece typo: References > MUST NOT be target of downgrading. > other headers: UTF-8 in other headers such as Subject and Received > SHOULD be target of downgrading. Is there any reason why SHOULD is used here instead of the MUST? >3.3. Requirements [...] > 5. Downgrade and upgrade method MUST be defined clearly. I read this requirement as an obvious requirement on output of this WG. So I think the MUST keyword is not applicable here. Or is this sentence trying to say something else? >4. SMTP Downgrading > > Downgrading MUST be performed in each SMTP session. Target of > downgrading elements in SMTP envelope are below: > > o MAIL FROM: > o RCPT TO: I've already touched on the subject in my other message, but is there any interaction between downgrade and DSN SMTP extension? > Further, even if no downgrading is performed for envelope from/to, > MUA/MTA SHOULD downgrade headers including UTF-8. This is described > in next session. Why only SHOULD here and not MUST? I.e. what are the anticipated reasons for MUAs for violating the SHOULD? >5.1. Downgrading with MIME encapsulation > [...] > Upgrade/Decode > * If mail message contains only one MIME part and its Content- > Type is 'Message/EAI', it may be downgraded. To check if "may be upgraded". > downgraded, compare mail body's message-id and MIME part's > message-id. If message-ids are same, it is downgraded message. > Then, treat MIME part as entire mail message. >6.2. MDA Requirements [...] > 4. If MDA detects that SMTP recipient address is downgraded IMA, > then MDA MUST decode IMA and perform the same processing as if it > were IMA. MDA MAY normalize or canonicalize local-part before > processing it. It is not clear about what kind of normalization/canonicalization the draft is talking about and why it is needed at the receiving end. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 03 19:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYoZ-0000BZ-KZ; Mon, 03 Apr 2006 19:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYoZ-0000Ao-A4 for ima@ietf.org; Mon, 03 Apr 2006 19:50:31 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQYoX-0004cY-VE for ima@ietf.org; Mon, 03 Apr 2006 19:50:31 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C6E62596C7; Tue, 4 Apr 2006 01:50: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 04858-07; Tue, 4 Apr 2006 01:50:10 +0200 (CEST) Received: from [172.24.72.28] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6E8C2597E6; Tue, 4 Apr 2006 01:47:04 +0200 (CEST) Message-ID: <4430FFDF.6040603@alvestrand.no> Date: Mon, 03 Apr 2006 12:58:39 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) 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 Charles Lindsey wrote: > On Thu, 30 Mar 2006 08:32:23 +0100, Harald Alvestrand > wrote: > >> I think the discussion so far has proved just about conclusively that >> the standards cannot possibly require recipient systems to have email >> addresses that pass either the telephone number test or the fax test. > > Sure we cannot write rules telling people to say "zwo" rather than > "zwei", but we can avoid the grosser failures of the telephone and fax > tests (and especially the ones which will still confuse people even if > they take the greatest care over their pronunciation and handwriting) > by requiring some reaonable level of normalization of email addresses > (and of the local-part in particular). John's "Net-utf-8" document may > or may not be sufficient for the purpose, so I suggest we wait and see > what that covers before returning to this subject again. Charles, I do not think you heard me the first time. As far as I can tell, all participants except for you have said that the "fax test" and "telephone test" are NOT relevant to the EAI working group. Unless I hear differently from someone else, I'm going to note this as a closed issue for the WG. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 03 22:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQbZ2-0006QT-FK; Mon, 03 Apr 2006 22:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQbZ1-0006OE-C4 for ima@ietf.org; Mon, 03 Apr 2006 22:46:39 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQbYw-0004kb-Sq for ima@ietf.org; Mon, 03 Apr 2006 22:46:39 -0400 Received: (eyou send program); Tue, 04 Apr 2006 10:46:23 +0800 Message-ID: <344118783.17957@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.145 with SMTP; Tue, 04 Apr 2006 10:46:23 +0800 Message-ID: <000e01c65792$36c241a0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Alexey Melnikov" , References: <344001259.27214@cnnic.cn> Subject: Re: [EAI] Comments on draft-yao-ima-smtpext-02.txt Date: Tue, 4 Apr 2006 10:48:11 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.0 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0138657481==" Errors-To: ima-bounces@ietf.org --===============0138657481== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXhleSBNZWxuaWtvdiIg PGFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IE1v bmRheSwgQXByaWwgMDMsIDIwMDYgMjowNyBBTQ0KU3ViamVjdDogW0VBSV0gQ29tbWVudHMgb24g ZHJhZnQteWFvLWltYS1zbXRwZXh0LTAyLnR4dA0KDQoNCj4gSGksDQo+IEkgaGF2ZSBhIGNvdXBs ZSBvZiBjb21tZW50cyBvbiBkcmFmdC15YW8taW1hLXNtdHBleHQtMDIudHh0LiAoUGxlYXNlIA0K PiBraW5kbHkgcG9pbnQgbWUgdG8gdGhlIGFyY2hpdmUgaWYgdGhpcyB3YXMgYWxyZWFkeSBkaXNj dXNzZWQpDQoNCnRoYW5rcyBhIGxvdC4gY29tbWVudHMgYmVsb3cuDQo+IA0KPiAxKSBJIHRoaW5r IHRoZSBkb2N1bWVudCBuZWVkcyB0byBkZXNjcmliZSBpdHMgaW50ZXJhY3Rpb24gd2l0aCB0aGUg RFNOIA0KPiBTTVRQIGV4dGVuc2lvbiwgZm9yIGV4YW1wbGUsIHdoYXQgc2hvdWxkIGJlIHB1dCBp bnRvIE9SQ1BUIHBhcmFtZXRlciBvbiANCj4gZm9yd2FyZGluZyB0byBhIHNpbmdsZSByZWNpcGll bnQgYWxpYXMsIHdoZW4gdGhlIG5leHQgaG9wIHN1cHBvcnRzIGJvdGggDQoNCkkgaGF2ZSByZWFk IHRocm91Z2ggdGhlIFNNVFAgRFNOIGV4dGVuc2lvbnNbUkZDMzQ2MV0gaW4gZGV0YWlsLg0KSXQg c2VlbXMgdGhhdCAgSU1BIGFkZHJlc3Mgd2lsbCBoYXZlIGluZmx1ZW5jZSBvbiBtYW55IGVtYWls IHJlbGF0ZWQgUkZDIGRvY3VtZW50cy4NClJGQzM0NjEgaXMgb25lIG9mIHRoZW0uIGlzIGl0IGdv b2QgdGhhdCB0aGlzIHByb2JsZW0gaXMgZGVzY3JpYmVkIG9yIHNwZWNpZmllZCBpbiBvdGhlciBk b2N1bWVudHMuDQppbiBuZXh0IHZlcnNpb24gb2YgaW1hLXNtdHBleHQsIHdlIG1heSByZWZlciB0 aGlzIHByb2JsZW0uDQoNCj4gdGhlIElFbWFpbCBhbmQgdGhlIERTTiBTTVRQIGV4dGVuc2lvbnMu IEkuZS4gc2hvdWxkIGl0IGJlIHRoZSBkb3duZ3JhZGVkIA0KPiBhZGRyZXNzIG9yIHRoZSBJMThO IGFkZHJlc3M/DQoNCmZvciBJTUEgY2FwYWJsaWxpdHkgc210cCBzZXJ2ZXJzLCBzaG91bGQgdXNl IEkxOE4gYWRkcmVzcy4NCmZvciBub24tSU1BIGNhcGFiaWxpdHkgc210cCBzZXJ2ZXJzLCBtYXkg ZG93bmdyYWRlIGFkZHJlc3MuDQoNCg0KDQoNCj4gDQo+IDIpLiBUaGUgV0cgc2hvdWxkIGRpc2N1 c3MgaWYgY2hhbmdlcyB0byBEZWxpdmVyeSBTdGF0dXMgTm90aWZpY2F0aW9uIA0KPiBmb3JtYXQg YXJlIGluIHNjb3BlIGZvciB0aGUgV0csIGluIHBhcnRpY3VsYXIgZXh0ZW5zaW9ucyB0byBhbGxv dyBmb3IgDQo+IEkxOE4gYWRkcmVzc2VzLiBUaGlzIHRpZXMgdG8gSm9obidzIGNvbW1lbnQgYWJv dXQgYm91bmNlcyBjb250YWluaW5nIA0KPiBhZGRyZXNzZXMgd2hpY2ggYXJlIG5vdCBtZWFuaW5n ZnVsIGZvciB0aGUgc2VuZGVyLg0KDQp5ZXMsIG1heSBjb25zaWRlci4gYnV0IGN1cnJlbnRseSwg d2UgbWF5IGNvbnNpZHIgdGhlIG1haW4gcHJvYmxlbSBvZiB0aGlzIFdHIGZpcnN0Lg0KDQo+IA0K PiAzKS4gKElnbm9yaW5nIGZvciB0aGUgbW9tZW50IHRoZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRo ZXIgQVRPTUlDIHNob3VsZCANCj4gYmUgcmVtb3ZlZCBmcm9tIHRoZSBzcGVjIG9yIG5vdCkgTWlu b3IgY29tbWVudCBhYm91dCB0aGUgQVRPTUlDIA0KPiBwYXJhbWV0ZXIgbmFtZS4gSSB0aGluayAi QVRPTUlDIiBhcyBhIHBhcmFtZXRlciBuYW1lIGlzIG1pc2xlYWRpbmcsIGFzIA0KPiBpdCBicmlu Z3MgYXNzb2NpYXRpb25zIHdpdGggW2RhdGFiYXNlXSB0cmFuc2FjdGlvbiBhdG9taWNpdHksIG1h eWJlIA0KPiBzb21ldGhpbmcgbGlrZSAiQVVUT0RFUklWRUQiIHdvdWxkIGJlIGJldHRlci4NCg0K d2UgbWF5IGNvbnNpZGVyICJBVE9NSUMiIGFzIGZsYWcuIGlmICJBVE9NSUMiICBmbGFnIGlzIHNl dCwgaXQgbWVhbnMgdGhhdCBpdCBjYW4gYmUgZG93bmdyYWRlZC4gb3RoZXJ3aXNlLCBub3QuDQoN Cg0KPiANCj4gQWxzbywgdGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyB3aGVyZSBBVE9NSUMg aXMgbWlzc3BlbGxlZCBhcyBBVE1PSUMuDQoNCnRoYW5rcy4gd2Ugd2lsbCBjb3JyZWN0IGl0IGlu IHRoZSBuZXh0IHZlcnNpb24uDQoNCg0KPiANCj4gUmVnYXJkcywNCj4gQWxleGV5DQo+IA0KPiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiA= --===============0138657481== 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 --===============0138657481==-- From ima-bounces@ietf.org Wed Apr 05 13:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBpM-0002Sx-Kg; Wed, 05 Apr 2006 13:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBpL-0002Ss-Qp for ima@ietf.org; Wed, 05 Apr 2006 13:29:55 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRBpK-0000DV-LS for ima@ietf.org; Wed, 05 Apr 2006 13:29:55 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 5 Apr 2006 18:29:50 +0100 Message-ID: <4433FE8B.9080602@isode.com> Date: Wed, 05 Apr 2006 18:29:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Subject: [EAI] EAI meeting notes from the Dallas IETF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 let me know if the notes are accurate. =============== The EAI meeting has started with Harald Alvestrand (the WG chair) setting out the rules for the meeting: no arguments about whether the proposed approach (use UTF-8 email addresses) is Ok or not. Harald also added that the goal of the meeting is to try to resolve as many issues as possible. Ted Hardie, the responsible AD for the EAI mentioned that IESG will consider very seriously transition from the experimental phase of the EAI WG to the standard track phase (see the charter). 1) "EAI constraints" document. John Klensin has talked about his "EAI constraints" document, which talks about potential fragmentation issues among other things. The draft is describing John's personal opinion and thus doesn't have to become a WG document. John mentioned that the document is a set of tradeoffs and that it is not possible to satisfy all of them. John didn't talk in details his draft, assuming that everybody has read it and jumped to the Q&A right away. Q: Paul Hoffman has asked why this draft can't be an individual submission. A: John: processing for individual submissions takes long time, can be much slower than a WG document. 2). "EAI scenarios" document. Harald has presented his "EAI scenarios" draft next. He explained that he has tried to describe use cases in generic terms in order not to constraint the solution. All requirements which weren't 100% needed were removed. Paul Hoffman has suggested to fold this document into the framework document. John has replied that having too many informational documents is bad. Consensus of the room to make the draft a WG document, but keep it a separate draft. Consolidation can be done later on. 3). "EAI framework" document. John talked about the framework draft next. Q: Ted Hardie: the "problem statement" section says that major rework is needed on the document, what is planned? A: John: take out the text about major rework :-). Q: Lisa has asked if the WG is considering multiple solution or just one. A: John has replied that there is a single solution, multiple documents are needed mostly in order to spread the workload between multiple people. Q: Paul Hoffman: the document doesn't say which documents are mandatory to implement and which are optional. A: John: everything is mandatory, but we are not sure when to downgrade and under what conditions. Q: Ted: the document only allows downgrade or bounce? A: John: yes Q: Dave Crocker: DSN has very strict rules when to bounce a message, why this draft is not as strict? A: John: the intent was to make EAI it as strict as DSN rules. 4). "Internationalized Email Headers" document Jeff Yeh has presented "Internationalized Email Headers" draft (draft-yeh-ima-utf8headers-01.txt). He described changes since -00 first: - added new header field to signal that header fields are in UTF-8 - clarified that new format requires the IEmail SMTP extension ... Rules in RFC 2822 were not changed, in particular header names are still in ASCII. Message-ID were not changed, date-time were not changed except for the "comment" part. RFC 2822 "phrase" and "comment" non-terminals can contain UTF-8 now. Jeff has also talked about updated ABNF for RFC 2822 "mailbox". Q: Ted: what issues are anticipate for mailing lists? A: Jeff: mixture of i18n and ASCII addresses in a single message Q: Dave Crocker: References include text, why not I18N them? A: Pete Resnick has jumped to the microphone: References only allows for comments, which are addressed by general rule about comments. Dave Crocker noted that RFC 733? provided a syntax form multiple addresses for an entity and it might be nice to reuse it. Chris Newman noted that it was important to give an example of internationalized timezone in the date-time, i.e. Internationalized comment after the timezone offset. John Klensin replied to this that I18N time zone might be an issue with deployed mail clients. Pete Resnick suggested to restrict where UTF-8 can be used, not just say "everywhere where 'comment' is used". Paul Hoffman suggested that the document should give detailed instructions "do this, don't do that", so that other WG like DKIM and PKIX can see any interactions with EAI. Pete Resnick noted that there were some shared syntax between 2821 and 2822, so it would be better to abstract it out. But need to be explicit about which rules affect email message format and which affect SMTP. Q: Philip Guenther (remotely through jabber): do the changes to these rules also effectively change the rules for MIME part headers inside the body, e.g. Content-*: headers at the starts of a MIME part? A: John Klensin: Philip's issues is not addressed, will be added to todo list Chris Newman suggested to use SASLPrep for email address canonicalization. Philip Guenther noted that S/MIME at least had no canonicalization levels. 5). "EAI SMTP extension" document Jiankang Yao talked about EAI SMTP extension (draft-yao-ima-smtpext-02.txt). Changes since the last revision: - added mailbox address syntax - added the ATOMIC and ALT-ADDRESS optional parameters to MAIL FROM and RCPT TO commands. ALT-ADDRESS takes precedence. If not specified and ATOMIC=yes, the I18N address can automatically be converted to ASCII (using yet to be decided ASCII Compatible Encoding) Q: Is there any reason to permit both ATOMIC and ALT-ADDRESS on a single address? As written, ATOMIC is ignored if ALT-ADDRESS is present Q: Pete Resnick: why change the "atom" ABNF? Why not use ABNF for the quoted string? A: John: Quoted strings are nothing but troubles operationally (based on 20 years of experience), so the draft is trying to address this issue on purpose. Q: Philip: are spaces allowed in local part (they need to be quoted)? This is frequently used with user+mailbox addressing. Q: Paul Hoffman: we can't have UTF-8 examples in the document, as RFC format doesn't allow for UTF-8 :-(. Q: Ted: email address can be in either UTF-8 or punycode? A: Yes. Q: Pete Resnick: Why ATOMIC is needed, my guess is for subaddressing. Harald request to defer the question till downgrade draft 6). "Downgrade" document Yoshiro Yoneya talked about the downgrade draft (draft-yoneya-ima-downgrade-01.txt). Changes from -00: - added downgrade requirements section - separate description of SMTP and message format downgrading Downgrade requirements: - downgrade once, don't upgrade until delivered - downgrading must be easy - MUST preserve header information - should work with DKIM/SPF - an attempt to downgrade MUST be recorded ... Chris Newman noted that MUST is too strong for preserving all header information. Chris Newman commented that some requirements can't be met (e.g. charset info is lost on conversion). He suggested to use "best effort" Yoshiro talked about downgrade procedure in details (see the draft). The draft describes two ways to downgrade: MIME encapsulation and header-by-header conversion. Harald (as a participant) suggested to remove the text about upgrading and MIME encapsulation case, as there is no use case for them. The removal will make the whole model simpler (and thus will simplify the document). Chris Newman wanted to have upgrade in a different spec (or not at all). But he doesn't think upgrade can be avoided, as lack of upgrade makes writing IMAP client very difficult (2 different cases to handle in IMAP code). Lisa commented that encapsulation can be useful, as MUAs can be upgraded to support UTF-8 easier. Pete Resnick recommended to split upgrade (or downgrade) of SMTP and message format. John has commented that encapsulation preserved all information. Chris Newman commented that protocol level upgrade can only happen inside an Autonomous System (e.g. enterprise), no need to talk about this in the draft. Ted Hardie commented that header-by-header approach has advantage that only MUA needed to be updated, no changes to POP/IMAP servers. John raised an issue about downgrading headers that the MTA doesn't know about. He also commented that encapsulation and header-by-header are not necessarily mutually exclusive. Harald pointed out that encapsulation can produce a message that the recipient can't use (i.e. MUA doesn't recognize the format). No consensus in the room about encapsulation versa header-by-header, the discussion should continue on the mailing list. 7). "POP3 I18N extension" document Chris has talked about POP UTF8 extension draft. The basic approach was to add parallel command for each affected command, as there are not that many of them. I.e. the draft added RET8,LST8 in addition to RETR, LIST. It also added an optional parameter to the USER command and requires use of SASLPrep for USER/PASS/APOP use SASLPrep. The NO-RETR capability was added to say that the server can't support "old" 7bit mode. Chris has considered an alternative approach (a new command to do a "switch to UTF-8 mode", but decided against it). In particular Chris thought that the TOP command was evil and thus there is no TOP8 command. Up-conversion is required to make clients easier to implement. Q: Randy Gellens: TOP8 is useful in mail clients (to check if a message is to be downloaded). John Klensin wished that TOP has never existed. He commented that for libraries that support both IMAP and POP, TOP adds extra effort and requires specific mode of parsing message. No consensus for "not having TOP8" and Chris gave up on not adding TOP8. Q: Tony Hansen: how RETR works on UTF-8 mailstores? A: Chris Newman: downgrade. The behavior of RETR is not changed in any way. Pete Resnick commented that clients who wanted to download just headers would use RETR and drop the connection. So it is better to have TOP8. Q: why clients are using TOP? Because they have limited memory/bandwidth? They should be using LIST. Randy Gellens commented that clients use TOP both to look at headers and to peek at body. Chris asked the WG if a global switch is better than a parallel set of commands? Harald (as the WG chair) replied that this should be taken to the mailing list. 8). John talked about fragmentation of group of users due to EAI (see John Klensin's message on the mailing list). Barry Leiba commented that if there were partitioning, EAI would help to limit it by preventing deployment of multiple incompatible methods. Paul Hoffman added that there might be partitioning of people based on left-to-right versa right-to-left scripts. Cyrus Daboo added that there are other issues to be addressed like vCard, mailto URLs, etc. 9). The meeting has concluded. Authors of the documents need to republish their documents with WG names. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 06 13:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYSL-0000Ym-UB; Thu, 06 Apr 2006 13:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYSK-0000Yh-3M for ima@ietf.org; Thu, 06 Apr 2006 13:39:40 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRYSI-0000nx-MA for ima@ietf.org; Thu, 06 Apr 2006 13:39:40 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 6 Apr 2006 18:39:27 +0100 Message-ID: <4435524C.7010508@isode.com> Date: Thu, 06 Apr 2006 18:39:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: YAO Jiankang Subject: Re: [EAI] Comments on draft-yao-ima-smtpext-02.txt References: <344001259.27214@cnnic.cn> <344118783.17957@cnnic.cn> In-Reply-To: <344118783.17957@cnnic.cn> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 YAO Jiankang wrote: >>1) I think the document needs to describe its interaction with the DSN >>SMTP extension, for example, what should be put into ORCPT parameter on >>forwarding to a single recipient alias, when the next hop supports both >> >> >I have read through the SMTP DSN extensions[RFC3461] in detail. >It seems that IMA address will have influence on many email related RFC documents. >RFC3461 is one of them. is it good that this problem is described or specified in other documents. >in next version of ima-smtpext, we may refer this problem. > > Sounds good. A short sentence saying that this is a work to be done would suffice for now. >>the IEmail and the DSN SMTP extensions. I.e. should it be the downgraded >>address or the I18N address? >> >> >for IMA capablility smtp servers, should use I18N address. >for non-IMA capability smtp servers, may downgrade address. > > The document can't just say that it changes email addresses in all other SMTP extensions to be I18N. It needs to examine interaction with such SMTP extensions and update them. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 07 10:59:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQR-0001vb-Ah; Fri, 07 Apr 2006 10:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQP-0001sp-Py for ima@ietf.org; Fri, 07 Apr 2006 10:59:01 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsQO-0007p9-Gz for ima@ietf.org; Fri, 07 Apr 2006 10:59:01 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FRsQN-0002y3-Hn; Fri, 07 Apr 2006 16:58:59 +0200 To: ima@ietf.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Fri, 7 Apr 2006 16:58:58 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.04.2006 16:58:59, Serialize complete at 07.04.2006 16:58:59 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [EAI] Comments on IMA framework X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org All, these are my comments on draft-klensin-ima-framework-01. I haven't been following the last discussions in the list. If some of these issues (or any of those in my following mails) have already been dealt with, then just give me a pointer. * Section 1: "to embed them in the 'name phrases' of the relevant headers". Is hereby meant the "display-name" of 2822? Or in general all fields of type "phrase"? "Name phrase" is just not a concept for me. * Section 1.2: "written in a subset of a Roman-derived script". I think the correct term is "Latin script". * Section 3, 2nd bullet: "encoded in UTF-8 when the SMTP extension is used". That is not 100% correct: the update of the header field syntax should be independent of the transport extension. * Section 5.1: "translating the message into a different language". I don't know how that should be an effective measure of downgrade during submission to the effects of this spec. * Section 5.2: s/mechanism preserve/mechanism to preserve/ * Section 8.1: mailto is not to be modified in the IRI spec, but in RFC 2368 * Section 10: "does not work for email local parts since they are case-sensitive". I think it's fair mentioning that most of the implementations and users don't make this distinction. * Section 10: "IMA specifications do not, in general, raise any new security issues other than those associated with confusable characters". Well, there's the UTF-8 canonicalization exploit, cf Security Considerations of RFC 3629. Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 07 10:59:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQV-0002O3-LO; Fri, 07 Apr 2006 10:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQT-0002DO-Vl for ima@ietf.org; Fri, 07 Apr 2006 10:59:05 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsQT-0007pI-I0 for ima@ietf.org; Fri, 07 Apr 2006 10:59:05 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FRsQS-0002zS-Nb; Fri, 07 Apr 2006 16:59:04 +0200 To: ima@ietf.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Fri, 7 Apr 2006 16:59:03 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.04.2006 16:59:04, Serialize complete at 07.04.2006 16:59:04 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [EAI] Comments on SMTP extension X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org All, these are my comments on draft-yao-ima-smtpext-02. I haven't been following the last discussions in the list. If some of these issues (or any of those in my following mails) have already been dealt with, then just give me a pointer. * Section 1.1: RFC 1869 is obsolete, current is 2821 * Section 1.2: "Domain part of the email address may be internationalized through IDNA". It should rather be "..has been internationalized..". * Section 1.2: "Since older SMTP servers and the mail-reading clients [...] may not be prepared to handle these extended addresses, an SMTP extension is specified". This could be nitpicking, but I don't think that we are protecting those mail-reading clients with this SMTP extension. I would cross them out of that sentence. * Section 2.2: "DNS MUST be processed into punycode form as specified in IDNA". I don't think that punycode (concrete ACE encoding) is relevant at all here. Punycode is part of the internals of IDNA. I suggest modifying the sentence to "DNS MUST be processed as specified in IDNA by means of the ToASCII() operation". * Section 2.2: "and then MUST be compared as specified in IDNA". My experience is that people overlook this comparison definition, thus it would be practical to make an exact reference: Section 3.1.4 of RFC 3490 * Section 2.2: s/either punycode/either ACE/ * Section 2.2: "the original SMTP client SHOULD first verify that the string is valid for a domain name according to IDNA rules". Why and for which fields? And what if that fails? Reaction should probably depend on the exact field of failure appearance. That must be defined. * Section 2.2: s/it MUST not attempt to parse/it MUST NOT attempt to parse/ * Section 2.2: s/Client MUST not transmit/client MUST NOT transmit/ * Section 2.3: "Change the definition of 'Atom' to permit either the definition above or a UTF-8 string". This complete liberalization of the local part makes me feel very uneasy, not all characters are appropriate to become part of an identifier (cf the Unicode Standard Annex 31, Identifier and Pattern Syntax). * Section 2.3: RFC2234 is obsolete, current is 4234 * Section 2.3: Nitpicking "sub-domain = Let-dig [Ldh-str] / " The former are a subset of the latter, thus "sub-domain = " is enough for that informal purpose. * Section 2.4: s/may set by sender/may be set by the sender/ * Section 2.4: "are data or instructions embedded in the address that the ACE process would hide". That should be ellaborated a bit more. * Section 2.4: s/ATMOIC/ATOMIC/g * Section 2.4: "the sender SMTP server can apply some algorithmic transformation such as punycode". "Can"? "Should"? "SHOULD"? "MUST"? I am for the latter in this point. In anycase the sentence would better be "..apply some ASCII compatible encoding transformation". * Section 2.4: "IDNA may also be applied to the domain part". "may"? or "MUST"? * Section 2.4: I couldn't find an explanation in the algorithm for the case in which neither ALT-ADDRESS nor ATOMIC are present. I guess rejection is the correct thing, but then, why is ATOMIC optional at all? * Section 2.5: "the name should be in punycode form if its raw form is non-ASCII". "should" or "MUST"? Cf "may" two bullets ago. In any case, and since ToASCII(ascii)=ascii, the sentence should read "...always in ASCII encoded form". * Section 2.5: "8BITMIME should be advertised". If 8BITMIME is a requirement for IMA, as I think it is, then it should be "8BITMIME must be advertised". * Section 2.5.1: s/punycode form/ACE form/ * Section 2.5.2: "Internationalized domain names in Received fields should be transmitted in punycode form". "should"? "SHOULD"? Wouldn't it be better "MUST"? * Section 2.5.4: It is moot since the inclusion of the "i18n-mail" header Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 07 10:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQX-0002YA-Pu; Fri, 07 Apr 2006 10:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQW-0002T5-EC for ima@ietf.org; Fri, 07 Apr 2006 10:59:08 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsQW-0007pM-5q for ima@ietf.org; Fri, 07 Apr 2006 10:59:08 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FRsQV-00030I-GV; Fri, 07 Apr 2006 16:59:07 +0200 To: ima@ietf.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Fri, 7 Apr 2006 16:59:06 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.04.2006 16:59:07, Serialize complete at 07.04.2006 16:59:07 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [EAI] Comments on POP3 support X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org All, these are my comments on draft-newman-ima-pop-00. I haven't been following the last discussions in the list. If some of these issues (or any of those in my following mails) have already been dealt with, then just give me a pointer. * Abstract: "to support unencoded international characters". That is a bit bizarre of a formulation. What about: "to support non-ASCII characters without MIME-encoding" or something similar? * Section 3: "the exact octect counts returned by the RET8 command". If I got it right, what the RET8 (LST8) command(s) should return is not octect counts but characters, right? Otherwise what is the difference to the non-i18n-commands? * Section 4: "Any attempt to use any of these three commands will result in an error response. As this is an incompatible change to POP3, a clear warning is necessary". It just strikes to me the different words "error" and "warning" (for me clearly different category levels) meaning the same. * FWIW: I am for the inclusion of TOP8 in this standard, but as an optional command (argument). Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 07 10:59:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQT-000290-G0; Fri, 07 Apr 2006 10:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQS-00022A-HS for ima@ietf.org; Fri, 07 Apr 2006 10:59:04 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsQR-0007pC-2Q for ima@ietf.org; Fri, 07 Apr 2006 10:59:04 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FRsQQ-0002ym-CB; Fri, 07 Apr 2006 16:59:02 +0200 To: ima@ietf.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Fri, 7 Apr 2006 16:59:00 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.04.2006 16:59:02, Serialize complete at 07.04.2006 16:59:02 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [EAI] Comments on Internationalized Email Headers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org All, these are my comments on draft-yeh-ima-utf8headers-01. I haven't been following the last discussions in the list. If some of these issues (or any of those in my following mails) have already been dealt with, then just give me a pointer. * Abstract: "and to use international characters in envelope addresses". That's a bit unlucky formulation. What about "to use non-ASCII characters"? * Abstract: "the base form for Internet email header fields". For the sake of correctness I would find better "the base form for Internet email header field bodies". This correction should be made a couple of other times in the document. * Section 1.1: The UTF-8 issue is addressed here for the first time. Colour me purist, but I think that the actual encoding of the header field bodies should be a transport issue, and that this header document should only talk about "non-ASCII" or "Unicode characters" instead of "UTF-8 characters" (besides the fact, that ASCII are UTF-8 characters, too). * Section 2: "This protocol specifies UTF-8 as the encoding to represent email header messages". What is meant with "email header message"? Maybe "email header body"? * Section 2: The concept "IMA mailbox names" appears for the first time and is not introduced. * Section 2: "if other header fields (particularly trace header fields such as "Received:") contain non-ASCII character". It would be helpful to make a complete list (well, probably not here in the introduction) of which fields are those. I couldn't find it. But "Received" is defined in ima-smtp-ext-02 section 2.5.2 to preferably remain ASCII, so this is probably not a good example to mention. * Section 4: "Sending MUAs that follow this protocol MUST create.." is not 2119-coherent with the next sentence "MUAs MAY continue to use MIME..". * Section 5: s/identifiction/identification/ * Section 5: "Checking the presence of UTF-8 characters in the header". Such a thing is not possible: you will find two bytes with the highest bit set and won't be able to determine whether you are dealing with two Latin-1 chars or one UTF-8 char. * Section 5: s/the its/the/ * Section 5: "sending MUA should insert a new header". My opinion is that "sending MUA MUST insert a new header", otherwise there is no 100% reliability. * Section 5: "i18n-mail" is a bit strange nomenclature. "i18n" stands for "internationalization" and not for "internationalized" (which should be i15d). Besides, "i18n mail" just doesn't flow out of the tongue. Couldn't we think of something else? * Section 5: "There should be more useful information [that] can be place[d] in the new header field". Something concrete in mind? * Section 5, 1st bullet: "'i18n-mail' header field MUST be inserted by the originating MUA". Fine, but cf "should" three bullets in this mail ago. * Section 5: "..MUST be inserted by the final delivery MTA if not presented". I don't know if this is for robustness or what, but it should be unnecessary, provided that the sending MUA did. And which are the criteria for inserting it, if not present? Statistical mechanisms to determine the presence UTF-8 encoding? * Section 6: "the rules in RFC 2822 for header names are not changed". Just delete the sentence. It was stated one sentence ago. * Section 6: s/extensionextension/extension/ * Section 6: s/IEE smtp extension/IMA SMTP extension/ * Section 6: Where does the magic number 558 come from? I mean "55" stands for "permanent negative in the mail system", but the remaining 8? * Section 6: "any data or instructions embedded in the email address". This should be ellaborated a bit more, maybe with one example (we are talking about "+" encodings, aren't we?) * Section 6, ATOMIC bullet: " remains the same to RFC2822. The only difference..". It either remains the same or there is some difference. * Section 6, ATOMIC bullet: "The only difference is that the and of allows UTF-8 characters". This is not enough for a formal syntax definition. It must be clearly enumerated which characters are allowed and how many of them. The encoding (UTF-8) is not relevant for the syntax, though it could effect the max. number of characters fitting there. * Section 6, ALT-ADDRESS bullet: What is the need for supporting the "obs" formats? * Section 6, ALT-ADDRESS bullet: "new-addr-spec =/ addr-spec" Isn't that line in the BNF unnecessary? * Section 7.1: "MAY need to be updated". RFC 2119 language is not necessary here, and by now, we know the are being updated. * Section 8: "that user SHOULD have both addresses in the identity". That "SHOULD" shouldn't be normative, and I even think it should be "may". * Section 8: "Lines that are longer than 78 octects could possibly cause mail user agents to fail". I would recommend then to proceed with folding, if encodings are longer than 78 octects. Talking about folding: What do you think about updating the definition of folding points in RFC 2822? Something like allowing for folding at codepoints with the Zs-property, instead of only whitespaces. Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 07 10:59:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQc-0002fQ-Tm; Fri, 07 Apr 2006 10:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsQb-0002a7-Jo for ima@ietf.org; Fri, 07 Apr 2006 10:59:13 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsQb-0007pV-Aw for ima@ietf.org; Fri, 07 Apr 2006 10:59:13 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FRsQa-00030u-K0; Fri, 07 Apr 2006 16:59:12 +0200 To: ima@ietf.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Fri, 7 Apr 2006 16:59:11 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.04.2006 16:59:12, Serialize complete at 07.04.2006 16:59:12 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [EAI] Comments on Downgrading X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org All, these are my comments on draft-yoneya-ima-downgrade-01. I haven't been following the last discussions in the list. If some of these issues (or any of those in my other mails) have already been dealt with, then just give me a pointer. * Section 3.1: "SMTP client detects UTF-8 is included in SMTP envelope or mail headers". Haven't we introduced the i18n-header to avoid making this realtime, unreliable checks? And is it really meant "detects UTF-8" or it is rather meant "detects 8th bit set"? * Section 3.2: s/Recent- headers/Resent- headers/ * Section 3.2: s/Referenece/References/ * Section 3.3: s/receipient/recipient/g (this appears a couple of times more) * Section 4: "MUA of mail sender MUST append ALT-ADDR or ATOMIC". Aren't both parameters optional? Then why MUST? * Section 4: s/next session/next section/ * Section 4: "local-part: Punycode without normalization". I am sure this has been discussed before (I saw a Normalizing-thread in the list), but fwiw here it comes my vote against non-normalized identifiers. * Section 4: The IMA-Downgraded-From and -To headers should be defined in the Internationalized Email Headers draft, too, since that is the equivalent of updating RFC2822. * Section 4: s/delived/delivered/ * Section 5.1: s/new body contains one MIME part/new body contains one new MIME part/ * Section 5.2: s/headers which contains/headers which contain/ * Section 6.2: "if MDA knows MUA is IMA compliant". How should that knowledge be conveyed? * Section 7: I am missing a comment in the Security Considerations about whose responsibility is that the owners of the internationalized mailboxes match the owners of the alternative ASCII ones. * Section 8: s/MUST be differ/MUST differ/ Best regards, Marcos Sanz _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 07 18:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzkq-0005Fy-SK; Fri, 07 Apr 2006 18:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzkp-0005Ft-P1 for ima@ietf.org; Fri, 07 Apr 2006 18:48:35 -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 1FRzko-0000sS-9v for ima@ietf.org; Fri, 07 Apr 2006 18:48:35 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FRzkn-0008XT-8P; Fri, 07 Apr 2006 18:48:33 -0400 Date: Fri, 07 Apr 2006 13:45:11 -0400 From: John C Klensin To: "Marcos Sanz/Denic" , ima@ietf.org Subject: Re: [EAI] Comments on IMA framework Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Marcos, As has been pointed out earlier in the WG context, these documents and specifications cannot contain a tutorial on RFC 2821 or 2822 (or on the POP and IMAP specs, etc.). They are written on the assumption of reasonable knowledge of those specifications and the terminology typically used to discuss them. More below. --On Friday, April 07, 2006 16:58 +0200 "Marcos Sanz/Denic" wrote: > All, > > these are my comments on draft-klensin-ima-framework-01. I > haven't been following the last discussions in the list. If > some of these issues (or any of those in my following mails) > have already been dealt with, then just give me a pointer. > > * Section 1: "to embed them in the 'name phrases' of the > relevant headers". Is hereby meant the "display-name" of > 2822? Or in general all fields of type "phrase"? "Name > phrase" is just not a concept for me. Yes, the "display name" of RFC 2822. Many terms have been used for this particular phrase over the years. * Section 1.2: "written > in a subset of a Roman-derived script". I think the correct > term is "Latin script". No, actually, the correct term is "Roman script" or "Roman-derived script". "Latin" was introduced into what became the ISO character-coding community long ago -- back when it arguably referred to the actual Latin script plus a few extensions -- but is not used in the the linguistic or writing system communities except by back-adoption from the (now) ISO/IEC JTC1/SC2 usage. > * Section 3, 2nd bullet: "encoded in UTF-8 when the SMTP > extension is used". That is not 100% correct: the update of > the header field syntax should be independent of the > transport extension. While specifications in the future might do other things, UTF-8 headers are not permitted except with the protection of the SMTP transport option, so, unless I misunderstand your point, the statement is correct as written. > * Section 5.1: "translating the message into a different > language". I don't know how that should be an effective > measure of downgrade during submission to the effects of this > spec. I do not understand this comment. > * Section 5.2: s/mechanism preserve/mechanism to preserve/ Will try to remember to pick this up on the next iteration > * Section 8.1: mailto is not to be modified in the IRI spec, > but in RFC 2368 The advice we have gotten so far is that language in the IRI spec will need to be considered, potentially leading to either updating either it or replacing 2368. If you don't consider the current wording acceptable, suggest text. > * Section 10: "does not work for email local parts since they > are case-sensitive". I think it's fair mentioning that most > of the implementations and users don't make this distinction. "mentioning" to what end. Any SMTP implementation that takes advantage of that particular knowledge except for final delivery processing is in violation of RFC 2821 and, for that matter, of 821. If you think it worth mentioning, suggest text. > * Section 10: "IMA specifications do not, in general, raise > any new security issues other than those associated with > confusable characters". Well, there's the UTF-8 > canonicalization exploit, cf Security Considerations of RFC > 3629. Working on that in another context -- watch for I-D best regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 08 14:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSI9Y-0001Jq-4b; Sat, 08 Apr 2006 14:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSI9W-0001DI-L4 for ima@ietf.org; Sat, 08 Apr 2006 14:27:18 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSI9U-0005Pe-0e for ima@ietf.org; Sat, 08 Apr 2006 14:27:18 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k38IREmU021605 for ; Sat, 8 Apr 2006 12:27:15 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXE00I01Z4ONU00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Sat, 08 Apr 2006 12:27:14 -0600 (MDT) Received: from [10.0.1.2] (216-165-224-133.championbroadband.com [216.165.224.133]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXF005IL1X00910@mail-amer.sun.com>; Sat, 08 Apr 2006 12:27:14 -0600 (MDT) Date: Fri, 07 Apr 2006 23:09:42 -0700 From: Chris Newman Subject: Re: [EAI] Comments on POP3 support In-reply-to: To: Marcos Sanz/Denic , ima@ietf.org Message-id: <7A6A23B0C7F0E530C34DBBB5@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Marcos Sanz/Denic wrote on 4/7/06 16:59 +0200: > these are my comments on draft-newman-ima-pop-00. I haven't been following > the last discussions in the list. If some of these issues (or any of those > in my following mails) have already been dealt with, then just give me a > pointer. > > * Abstract: "to support unencoded international characters". That is a bit > bizarre of a formulation. What about: "to support non-ASCII characters > without MIME-encoding" or something similar? I'll attempt a re-wording. > * Section 3: "the exact octect counts returned by the RET8 command". If I > got it right, what the RET8 (LST8) command(s) should return is not octect > counts but characters, right? Otherwise what is the difference to the > non-i18n-commands? LST8 returns the exact number of octets that will be returned by the RET8 command. UTF-8 headers will have a different octet count from RFC 2047 encoded headers, so LST8 will often be different from LIST. Octet count is useful to prepare a buffer for data transfer (although checks are still necessary), or for canonical UTF-8 storage of the message. Character count would only be useful for a client which used UCS-4 internally. Most operating systems use UTF-16/UCS-2 or UTF-8 internally, so a character count (UCS-4) doesn't seem particularly useful. It could also be expensive to compute (require scanning the entire message). > * Section 4: "Any attempt to use any of these three commands will result > in an error response. As this is an incompatible change to POP3, a clear > warning is necessary". It just strikes to me the different words "error" > and "warning" (for me clearly different category levels) meaning the same. I'll attempt a re-wording. > * FWIW: I am for the inclusion of TOP8 in this standard, but as an > optional command (argument). I'm putting TOP8 in as optional. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 02:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpha-0001aV-TK; Mon, 10 Apr 2006 02:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgz-000109-0R for ima@ietf.org; Mon, 10 Apr 2006 02:16:05 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpbD-0000uy-RO for ima@ietf.org; Mon, 10 Apr 2006 02:10:10 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k3A62Ru26356; Mon, 10 Apr 2006 15:02:27 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 0993_96a75ea8_c857_11da_9cd0_0014221f2a2d; Mon, 10 Apr 2006 15:02:27 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k3A5w1QE029475; Mon, 10 Apr 2006 15:01:36 +0900 Message-Id: <6.0.0.20.2.20060404182318.0912a620@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 05 Apr 2006 14:16:03 +0900 To: Harald Alvestrand , Charles Lindsey From: Martin Duerst Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) In-Reply-To: <4430FFDF.6040603@alvestrand.no> References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> <4430FFDF.6040603@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Hello Harald, Charles, others, At 19:58 06/04/03, Harald Alvestrand wrote: >Charles Lindsey wrote: >> On Thu, 30 Mar 2006 08:32:23 +0100, Harald Alvestrand wrote: >> >>> I think the discussion so far has proved just about conclusively that the standards cannot possibly require recipient systems to have email addresses that pass either the telephone number test or the fax test. I agree with this in the sense that it is virtually impossible to create something that will pass these tests in all cases. However, I don't exactly like the quick-shot conclusion along the lines of "if we can't be absolutely perfect, we better do nothing at all". (That's at least one way, and my first way, of reading Harald's text above.) >> Sure we cannot write rules telling people to say "zwo" rather than "zwei", but we can avoid the grosser failures of the telephone and fax tests (and especially the ones which will still confuse people even if they take the greatest care over their pronunciation and handwriting) by requiring some reaonable level of normalization of email addresses (and of the local-part in particular). John's "Net-utf-8" document may or may not be sufficient for the purpose, so I suggest we wait and see what that covers before returning to this subject again. >Charles, > >I do not think you heard me the first time. > >As far as I can tell, all participants except for you have said that the "fax test" and "telephone test" are NOT relevant to the EAI working group. > >Unless I hear differently from someone else, I'm going to note this as a closed issue for the WG. Just for the record, you just heard differently from someone else. The fax test and the telephone test are relevant for the end users of our technology. We as providers of this technology need to make sure that they have a reasonable chance to create and use addresses that work well for them. So these test are not directly relevant, but they are indirectly very relevant. It may turn out that things will work out without us doing something, it may turn out that we only need to give some advice and direction, or it may turn out that we need some stick in the ground. As an example, it would be a bad thing if half of the email programs used in Norway would encode an email address containing an A-ring as precomposed, and the other half would encode it as decomposed, but receiving servers would just do binary comparison. Charles' starting point was IDNA. The main reason for why I think we will end up with something different from IDNA is that one of the main concerns in IDNA was conflicting registrations, or the need for multiple (potentially a high number) of registrations to avoid having a name being spoofed. This is considerably different for LHS. In most cases, LHS don't get handed out simply on a first-come-first-served-anything-goes basis. Where they do (webmail hosting,...), the organizations in charge should be large enough to be able to manage the problem. The other thing that we don't need to copy from IDNA, because it was probably a mistake (even though not really such an important one), is the use of NFKC. This came about because some people wanted half-width and full-width variants (as they appear in East Asian encodings) to be treated equivalently, the same way uppercase and lowercase are treated as equivalents in the DNS. This was only available in NFKC, but that brought in a host of other equivalences that were really not necessary. A good example is that in a fully IDNA-compliant application, you can use special numbers with circles around them in place of the usual ASCII digits, and get to the same place. On the LHS, uppercase and lowercase are (a priori) different, so we don't have to worry about half-width vs. full-width, so we should be fine without NFKC. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 06:31:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FStfr-000503-8c; Mon, 10 Apr 2006 06:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FStfp-0004zv-4k for ima@ietf.org; Mon, 10 Apr 2006 06:31:09 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FStfo-00026U-M2 for ima@ietf.org; Mon, 10 Apr 2006 06:31:09 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FStfn-0007mS-Kt; Mon, 10 Apr 2006 12:31:07 +0200 In-Reply-To: To: John C Klensin Subject: Re: [EAI] Comments on IMA framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Mon, 10 Apr 2006 12:31:05 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 10.04.2006 12:31:07, Serialize complete at 10.04.2006 12:31:07 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John, > As has been pointed out earlier in the WG context, these > documents and specifications cannot contain a tutorial on RFC > 2821 or 2822 100% agree.. > > * Section 1: "to embed them in the 'name phrases' of the > > relevant headers". Is hereby meant the "display-name" of > > 2822? Or in general all fields of type "phrase"? "Name > > phrase" is just not a concept for me. > > Yes, the "display name" of RFC 2822. Many terms have been used > for this particular phrase over the years. ..and exactly because of that, I would try to stick, whenever possible, to the 2822-nomenclature. > * Section 1.2: "written > > in a subset of a Roman-derived script". I think the correct > > term is "Latin script". > > No, actually, the correct term is "Roman script" or > "Roman-derived script". "Latin" was introduced into what became > the ISO character-coding community long ago -- back when it > arguably referred to the actual Latin script plus a few > extensions -- but is not used in the the linguistic or writing > system communities except by back-adoption from the (now) > ISO/IEC JTC1/SC2 usage. AFAICT the most common term at the moment for the script, based on ISO usage and Unicode nomenclature, is "Latin script", but that is not important as long as we agree on the meaning. > > * Section 3, 2nd bullet: "encoded in UTF-8 when the SMTP > > extension is used". That is not 100% correct: the update of > > the header field syntax should be independent of the > > transport extension. > > While specifications in the future might do other things, UTF-8 > headers are not permitted except with the protection of the SMTP > transport option, so, unless I misunderstand your point, the > statement is correct as written. Admittedly, maybe the point was not clear. In my comments to the Headers-document, I have tried to defend the position that the update to the internet mail format should be in terms of a syntax extension to support new *Unicode* characters, and not *UTF-8* characters. Ideally, the word "UTF-8" would not have a single appearance in the Headers-document, because it is just a matter of transport. I mean, I could store my mails in UTF-16, as long as I use UTF-8 to communicate with an SMTP server. Now the second bullet in section 3 in the framework document is labelled "Email headers in UTF-8" and makes a reference to the Headers-document. Ideally, we keep here clearly the separation between envelope an content, too, and avoid the UTF-8 use. > > * Section 5.1: "translating the message into a different > > language". I don't know how that should be an effective > > measure of downgrade during submission to the effects of this > > spec. > > I do not understand this comment. The section is about downgrading before or during submission by means of an off-the-band mechanism. I admit that is something that must be mentioned for the sake of completion. However, "translating the message" is not very effective, because sending the translated message to exactly same address that once didn't work, will not work either. Or am I missing your point? Were you talking of somehow "translating the address"? > > * Section 8.1: mailto is not to be modified in the IRI spec, > > but in RFC 2368 > > The advice we have gotten so far is that language in the IRI > spec will need to be considered, potentially leading to either > updating either it or replacing 2368. If you don't consider the > current wording acceptable, suggest text. "The mailto URL scheme [RFC3987] needs to be modified when IMA is standardized." > > * Section 10: "does not work for email local parts since they > > are case-sensitive". I think it's fair mentioning that most > > of the implementations and users don't make this distinction. > > "mentioning" to what end. Any SMTP implementation that takes > advantage of that particular knowledge except for final delivery > processing is in violation of RFC 2821 and, for that matter, of > 821. If you think it worth mentioning, suggest text. "..does not work for email local parts since they are case-sensitive. Admittedly many implementations and users don't make case distinctions for the local part, but any security mechanisms based on that particular knowledge except for final delivery processing are in violation of RFC 2821". How do you mean, btw, "except for final delivery processing"? > > * Section 10: "IMA specifications do not, in general, raise > > any new security issues other than those associated with > > confusable characters". Well, there's the UTF-8 > > canonicalization exploit, cf Security Considerations of RFC > > 3629. > > Working on that in another context -- watch for I-D Looking forward to that! Anyway I would not state here "do not raise any new security issues", if it is not 100% correct, and would include a reference to the Security Considerations section of RFC 3629. Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 07:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSv2m-0001jp-Fd; Mon, 10 Apr 2006 07:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSv2k-0001jk-NS for ima@ietf.org; Mon, 10 Apr 2006 07:58:54 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSv2j-000625-EE for ima@ietf.org; Mon, 10 Apr 2006 07:58:54 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FSv2i-0003uL-G6; Mon, 10 Apr 2006 13:58:52 +0200 In-Reply-To: <7A6A23B0C7F0E530C34DBBB5@446E7922C82D299DB29D899F> To: Chris Newman Subject: Re: [EAI] Comments on POP3 support MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Mon, 10 Apr 2006 13:58:49 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 10.04.2006 13:58:52, Serialize complete at 10.04.2006 13:58:52 Content-Type: text/plain; charset="US-ASCII" 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 Chris, > > * Section 3: "the exact octect counts returned by the RET8 command". If I > > got it right, what the RET8 (LST8) command(s) should return is not octect > > counts but characters, right? Otherwise what is the difference to the > > non-i18n-commands? > > LST8 returns the exact number of octets that will be returned by the RET8 > command. UTF-8 headers will have a different octet count from RFC 2047 encoded > headers, so LST8 will often be different from LIST. Thanks, now I get it. Then the following rationale strikes me: LST8 is optional to minimize the cost of deploying UTF-8 support on a legacy mail drop. The server load necessary to perform up-conversion on every message in the mail drop to determine the LST8 octet-counts would be prohibitively expensive when there's no way to cache those counts. As far as I can see the practical problem is a client issuing the command LST8 without arguments (since LST8 msg is not more of a burden than RETR8 msg). Naive question: wouldn't the immediate solution be to make "LST8 msg" a required command, and then, adding the optional argument would indicate support of raw "LST8" without args? Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 13:02:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSzm7-0001ro-Ft; Mon, 10 Apr 2006 13:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSzm6-0001re-GT for ima@ietf.org; Mon, 10 Apr 2006 13:02:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSzJI-0000DZ-If for ima@ietf.org; Mon, 10 Apr 2006 12:32:16 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FSz86-0003lU-7T for ima@ietf.org; Mon, 10 Apr 2006 12:20:43 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FSz7u-000EUs-Pq; Mon, 10 Apr 2006 12:20:31 -0400 Date: Mon, 10 Apr 2006 12:20:29 -0400 From: John C Klensin To: Martin Duerst , Harald Alvestrand , Charles Lindsey Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Message-ID: In-Reply-To: <6.0.0.20.2.20060404182318.0912a620@localhost> References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> <4430FFDF.6040603@alvestrand.no> <6.0.0.20.2.20060404182318.0912a620@localhost> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: -1.5 (-) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Martin, I don't know whether Harald and I are in agreement or not, but my perspective on this is a bit different from yours. I don't know if the differences are important, but I want to identify them. --On Wednesday, 05 April, 2006 14:16 +0900 Martin Duerst wrote: >>Unless I hear differently from someone else, I'm going to >> note this as a closed issue for the WG. >=20 > Just for the record, you just heard differently from someone > else. > The fax test and the telephone test are relevant for the end > users > of our technology. We as providers of this technology need to > make > sure that they have a reasonable chance to create and use > addresses > that work well for them. So these test are not directly > relevant, > but they are indirectly very relevant. >=20 > It may turn out that things will work out without us doing > something, > it may turn out that we only need to give some advice and > direction, > or it may turn out that we need some stick in the ground. >=20 > As an example, it would be a bad thing if half of the email > programs > used in Norway would encode an email address containing an > A-ring as > precomposed, and the other half would encode it as decomposed, > but > receiving servers would just do binary comparison. >=20 > Charles' starting point was IDNA. The main reason for why I > think > we will end up with something different from IDNA is that one > of > the main concerns in IDNA was conflicting registrations, or = the > need for multiple (potentially a high number) of registrations > to avoid having a name being spoofed.=20 Actually, those concerns were not discussed very much while IDNA was being formulated (although they were discussed). The original driving force was the combination between the DNS's extremely restrictive matching rules and the protocol requirement for case mapping (at least of ASCII characters). There was no way to change the DNS matching rules without making changes to the way the DNS itself worked. And keeping the spirit of case-matching required some considerable mapping effort. =20 By contrast, the SMTP protocol imposes a different mapping norm. Its matching rule is effectively bitstring identity --not for characters but for the entire LHS -- until one gets to the final delivery server, which can apply any matching (or aliasing) rules that it likes. =20 These differences are very much key to the design of the two protocols and are, arguably, the inevitable consequences of how those protocols were designed and evolved. > This is considerably different > for LHS. In most cases, LHS don't get handed out simply on a > first-come-first-served-anything-goes basis. Where they do > (webmail hosting,...), the organizations in charge should be > large enough to be able to manage the problem. Also true. > The other thing that we don't need to copy from IDNA, because > it was probably a mistake (even though not really such an > important one), > is the use of NFKC. This came about because some people wanted > half-width and full-width variants (as they appear in East > Asian > encodings) to be treated equivalently, the same way uppercase > and > lowercase are treated as equivalents in the DNS. This was only > available in NFKC, but that brought in a host of other > equivalences > that were really not necessary. A good example is that in a > fully IDNA-compliant application, you can use special numbers > with circles around them in place of the usual ASCII digits, > and get to the same place. On the LHS, uppercase and lowercase > are (a priori) different, so we don't have to worry about > half-width vs. full-width, so we should be fine without NFKC. Yes, both to the conclusion and to the concerns that NFKC may not have been a good idea for IDNA. I would suggest that its use in nameprep had another consequence, which is that some character blocks that should simply have been banned were permitted on the grounds that NFKC would take care of mapping them to something more satisfactory. In retrospect, that was almost certainly a mistake, independent of whether the use of NFKC was a mistake. But the more important issue here, to me, is that the tradition with email --both one the of causes of the "no one tries to interpret LHS addresses other than the delivery server" rule and its logical consequence. So there is no protocol requirement for ASCII case-matching. Instead, we say "the protocol permits you to enforce an exact, bitstring-identity, match but taking advantage of that is normally stupid" and then we suggest aggressive use of the robustness principle on the receiving side. =20 That leads, in practice, to matching rules that go far beyond anything supported by (even) NFKC. I'm on this list as "klensin@jck.com". It is up to the maintainer of the server, not only whether "KlEnSiN" is accepted in the LHS, but also as to whether "john.klensin", "john", "john/klensin", "jk", transliterations into several other languages, and even "donald-duck" are accepted and, if they are accepted, what happens to them (before people try, some of those examples will work, some won't, and not all of those that work will go to the same mailbox/folder). From the sender end, there is no right to assume that any variant will work other than the one that appears a Reply-To field or its equivalent, or to make assumptions about what happens to those variations. So, to come back to the A-ring example, I think that, in the general case, it would be insane behavior on the part of the receiving system to not have these match, just as I think it would be insane to not do ASCII case matching in the general case. Similarly, if I were you, I'd be pretty insistent that, on your delivery server, either "duerst" or "d=C3=BCrst", and = all of their case variations, worked and mapped to the same folder. Failure to do that would not only fail the telephone test, but would just be dumb and violating of the law of least astonishment. But trying to turn it into a network requirement rather than a delivery server convention (noting that particular mapping goes beyond even NFKC (for good reasons), just as mapping "klensin" -> "john.klensin" does, would be a really bad idea. Put differently, requiring the general case would violate many years of experience with email protocols: senders need to remain used to the fact that specifying an address other than exactly as given _may_ cause bounces or other bad behavior. And I say "remain" because it has been that way for 35 or more years now. Our addresses have never been guaranteed to pass what Charles refers to as the telephone number or fax tests, even in ASCII. When they do, it is purely on the basis of robustness and aliases in the delivery servers, not as a result of the protocols. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 21:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT82u-0004kV-IA; Mon, 10 Apr 2006 21:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT82s-0004dk-Gv for ima@ietf.org; Mon, 10 Apr 2006 21:51:54 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FT82p-0000dm-4S for ima@ietf.org; Mon, 10 Apr 2006 21:51:54 -0400 Received: (eyou send program); Tue, 11 Apr 2006 09:51:38 +0800 Message-ID: <344720298.17847@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.145 with SMTP; Tue, 11 Apr 2006 09:51:38 +0800 Message-ID: <00c001c65d0a$b817a010$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "Marcos Sanz/Denic" References: <344421947.03293@cnnic.cn> Subject: Re: [EAI] Comments on SMTP extension Date: Tue, 11 Apr 2006 09:53:24 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.2 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a 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="===============0182254776==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============0182254776== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01C65D4D.C62C8830" This is a multi-part message in MIME format. ------=_NextPart_000_00BD_01C65D4D.C62C8830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmNvcyBTYW56L0Rlbmlj IiA8c2FuekBkZW5pYy5kZT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBBcHJp bCAwNywgMjAwNiAxMDo1OSBQTQ0KU3ViamVjdDogW0VBSV0gQ29tbWVudHMgb24gU01UUCBleHRl bnNpb24NCg0KDQo+IEFsbCwNCj4gDQo+IHRoZXNlIGFyZSBteSBjb21tZW50cyBvbiBkcmFmdC15 YW8taW1hLXNtdHBleHQtMDIuIEkgaGF2ZW4ndCBiZWVuIA0KPiBmb2xsb3dpbmcgdGhlIGxhc3Qg ZGlzY3Vzc2lvbnMgaW4gdGhlIGxpc3QuIElmIHNvbWUgb2YgdGhlc2UgaXNzdWVzIChvciANCj4g YW55IG9mIHRob3NlIGluIG15IGZvbGxvd2luZyBtYWlscykgaGF2ZSBhbHJlYWR5IGJlZW4gZGVh bHQgd2l0aCwgdGhlbiANCj4ganVzdCBnaXZlIG1lIGEgcG9pbnRlci4NCj4gDQoNCnRoYW5rcyBh IGxvdCBmb3IgeW91ciBkZXRhaWxlZCBjb21tZW50cy4NCg0KPiAqIFNlY3Rpb24gMS4xOiBSRkMg MTg2OSBpcyBvYnNvbGV0ZSwgY3VycmVudCBpcyAyODIxDQoNCndpbGwgdXBkYXRlIGl0IGFjY29y ZGluZyB0byB5b3VyIGNvbW1lbnRzLg0KDQoNCj4gKiBTZWN0aW9uIDEuMjogIkRvbWFpbiBwYXJ0 IG9mIHRoZSBlbWFpbCBhZGRyZXNzIG1heSBiZSBpbnRlcm5hdGlvbmFsaXplZCANCj4gdGhyb3Vn aCBJRE5BIi4gSXQgc2hvdWxkIHJhdGhlciBiZSAiLi5oYXMgYmVlbiBpbnRlcm5hdGlvbmFsaXpl ZC4uIi4NCg0KaW4gb3VyIGluaXRpYWwgdmVyc2lvbiwgd2UgdXNlICAiLi5oYXMgYmVlbiBpbnRl cm5hdGlvbmFsaXplZC4uIi4gYnV0IHdoZW4gd2UgY29uc2lkZXINCnRoYXQgZG9tYWluIHBhcnQg b2YgZW1haWwgaXMgZGlmZmVyZW50IGZyb20gdGhlIG5vcm1hbCBkb21haW4gbmFtZSwgd2UgbWF5 IHVzZSBkaWZmZXJlbnQgaW50ZXJuYXRpb25hbGl6ZWQgbWV0aG9kIGZvciBkb21haW4gcGFydCBv ZiBlbWFpbCBhZGRyZXNzLiBzbyB3ZSB1c2UgIkRvbWFpbiBwYXJ0IG9mIHRoZSBlbWFpbCBhZGRy ZXNzIG1heSBiZSBpbnRlcm5hdGlvbmFsaXplZCB0aHJvdWdoIElETkEiLiBhZnRlciB3ZSBmaW5h bGl6ZSB0aGUgSU1BIG1ldGhvZCwgd2UgbWF5IHVzZSB0aGlzIGtpbmQgb2Ygc2VudGVuc2UgOiAi RG9tYWluIHBhcnQgb2YgdGhlIGVtYWlsIGFkZHJlc3MgaGFzIGJlZW4gaW50ZXJuYXRpb25hbGl6 ZWQgdGhyb3VnaCBJRE5BIi4NCg0KDQoNCj4gKiBTZWN0aW9uIDEuMjogIlNpbmNlIG9sZGVyIFNN VFAgc2VydmVycyBhbmQgdGhlIG1haWwtcmVhZGluZyBjbGllbnRzIA0KPiBbLi4uXSBtYXkgbm90 IGJlIHByZXBhcmVkIHRvIGhhbmRsZSB0aGVzZSBleHRlbmRlZCBhZGRyZXNzZXMsIGFuIFNNVFAg DQo+IGV4dGVuc2lvbiBpcyBzcGVjaWZpZWQiLiBUaGlzIGNvdWxkIGJlIG5pdHBpY2tpbmcsIGJ1 dCBJIGRvbid0IHRoaW5rIHRoYXQgDQo+IHdlIGFyZSBwcm90ZWN0aW5nIHRob3NlIG1haWwtcmVh ZGluZyBjbGllbnRzIHdpdGggdGhpcyBTTVRQIGV4dGVuc2lvbi4gSSANCj4gd291bGQgY3Jvc3Mg dGhlbSBvdXQgb2YgdGhhdCBzZW50ZW5jZS4NCg0KDQp3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcg dG8geW91ciBjb21tZW50cw0KDQoNCg0KPiAqIFNlY3Rpb24gMi4yOiAiRE5TIE1VU1QgYmUgcHJv Y2Vzc2VkIGludG8gcHVueWNvZGUgZm9ybSBhcyBzcGVjaWZpZWQgaW4gDQo+IElETkEiLiBJIGRv bid0IHRoaW5rIHRoYXQgcHVueWNvZGUgKGNvbmNyZXRlIEFDRSBlbmNvZGluZykgaXMgcmVsZXZh bnQgYXQgDQo+IGFsbCBoZXJlLiBQdW55Y29kZSBpcyBwYXJ0IG9mIHRoZSBpbnRlcm5hbHMgb2Yg SUROQS4gSSBzdWdnZXN0IG1vZGlmeWluZyANCj4gdGhlIHNlbnRlbmNlIHRvICJETlMgTVVTVCBi ZSBwcm9jZXNzZWQgYXMgc3BlY2lmaWVkIGluIElETkEgYnkgbWVhbnMgb2YgDQo+IHRoZSBUb0FT Q0lJKCkgb3BlcmF0aW9uIi4NCg0KDQp3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBj b21tZW50cy4NCg0KDQo+ICogU2VjdGlvbiAyLjI6ICJhbmQgdGhlbiBNVVNUIGJlIGNvbXBhcmVk IGFzIHNwZWNpZmllZCBpbiBJRE5BIi4gTXkgDQo+IGV4cGVyaWVuY2UgaXMgdGhhdCBwZW9wbGUg b3Zlcmxvb2sgdGhpcyBjb21wYXJpc29uIGRlZmluaXRpb24sIHRodXMgaXQgDQo+IHdvdWxkIGJl IHByYWN0aWNhbCB0byBtYWtlIGFuIGV4YWN0IHJlZmVyZW5jZTogU2VjdGlvbiAzLjEuNCBvZiBS RkMgMzQ5MA0KDQoNCndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLg0K DQoNCj4gKiBTZWN0aW9uIDIuMjogcy9laXRoZXIgcHVueWNvZGUvZWl0aGVyIEFDRS8NCg0Kd2ls bCB1cGRhdGUgaXQgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMuDQoNCg0KPiAqIFNlY3Rpb24g Mi4yOiAidGhlIG9yaWdpbmFsIFNNVFAgY2xpZW50IFNIT1VMRCBmaXJzdCB2ZXJpZnkgdGhhdCB0 aGUgDQo+IHN0cmluZyBpcyB2YWxpZCBmb3IgYSBkb21haW4gbmFtZSBhY2NvcmRpbmcgdG8gSURO QSBydWxlcyIuIFdoeSBhbmQgZm9yIA0KPiB3aGljaCBmaWVsZHM/IEFuZCB3aGF0IGlmIHRoYXQg ZmFpbHM/IFJlYWN0aW9uIHNob3VsZCBwcm9iYWJseSBkZXBlbmQgb24gDQo+IHRoZSBleGFjdCBm aWVsZCBvZiBmYWlsdXJlIGFwcGVhcmFuY2UuIFRoYXQgbXVzdCBiZSBkZWZpbmVkLg0KDQppdCBj aGVja3MgdGhlIHZhbGlkaXR5IG9mIGVtYWlsIGFkZHJlc3MuIGlmIHRoZSBjbGllbnQgZm91bmQg dGhhdCBkb21haW4gbmFtZSBpcyBub3QgdmFsaWQsIGl0IG1lYW5zIHRoYXQgdGhlIGVtYWlsIGFk ZHJlc3MgaXMgbm90IHZhbGlkLiBpdCB0aGUgYWRkcmVzcyBpcyBub3QgdmFsaWQsIGl0IHdpbGwg cmVmdXNlIHRvIHNlbmQgdGhlIGVtYWlsIG1lc3NhZ2UuDQoNCg0KPiAqIFNlY3Rpb24gMi4yOiBz L2l0IE1VU1Qgbm90IGF0dGVtcHQgdG8gcGFyc2UvaXQgTVVTVCBOT1QgYXR0ZW1wdCB0byANCj4g cGFyc2UvDQoNCndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLg0KDQo+ ICogU2VjdGlvbiAyLjI6IHMvQ2xpZW50IE1VU1Qgbm90IHRyYW5zbWl0L2NsaWVudCBNVVNUIE5P VCB0cmFuc21pdC8NCg0Kd2lsbCB1cGRhdGUgaXQgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMu DQoNCj4gKiBTZWN0aW9uIDIuMzogIkNoYW5nZSB0aGUgZGVmaW5pdGlvbiBvZiAnQXRvbScgdG8g cGVybWl0IGVpdGhlciB0aGUgDQo+IGRlZmluaXRpb24gYWJvdmUgb3IgYSBVVEYtOCBzdHJpbmci LiBUaGlzIGNvbXBsZXRlIGxpYmVyYWxpemF0aW9uIG9mIHRoZSANCj4gbG9jYWwgcGFydCBtYWtl cyBtZSBmZWVsIHZlcnkgdW5lYXN5LCBub3QgYWxsIGNoYXJhY3RlcnMgYXJlIGFwcHJvcHJpYXRl IA0KPiB0byBiZWNvbWUgcGFydCBvZiBhbiBpZGVudGlmaWVyIChjZiB0aGUgVW5pY29kZSBTdGFu ZGFyZCBBbm5leCAzMSwgDQo+IElkZW50aWZpZXIgYW5kIFBhdHRlcm4gU3ludGF4KS4NCg0KeWVz LCB3ZSBoYXZlIG5vdGljZWQgdGhpcyBwcm9ibGVtLiB3ZSB3aWxsIHJlZmluZSB0aGUgZGVmaW5p dGlvbi4NCg0KDQoNCj4gKiBTZWN0aW9uIDIuMzogUkZDMjIzNCBpcyBvYnNvbGV0ZSwgY3VycmVu dCBpcyA0MjM0DQoNCndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLg0K DQoNCg0KPiAqIFNlY3Rpb24gMi4zOiBOaXRwaWNraW5nICJzdWItZG9tYWluID0gTGV0LWRpZyBb TGRoLXN0cl0gLyA8YW55IA0KPiBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbGFiZWwgc3BlY2lm aWVkIGJ5IElETkE+IiBUaGUgZm9ybWVyIGFyZSBhIHN1YnNldCANCj4gb2YgdGhlIGxhdHRlciwg dGh1cyAic3ViLWRvbWFpbiA9IDxhbnkgaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIGxhYmVsIA0K PiBzcGVjaWZpZWQgYnkgSUROQT4iIGlzIGVub3VnaCBmb3IgdGhhdCBpbmZvcm1hbCBwdXJwb3Nl Lg0KDQp3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4NCg0KDQo+ICog U2VjdGlvbiAyLjQ6IHMvbWF5IHNldCBieSBzZW5kZXIvbWF5IGJlIHNldCBieSB0aGUgc2VuZGVy Lw0KDQp3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4NCg0KDQo+ICog U2VjdGlvbiAyLjQ6ICJhcmUgZGF0YSBvciBpbnN0cnVjdGlvbnMgZW1iZWRkZWQgaW4gdGhlIGFk ZHJlc3MgdGhhdCB0aGUgDQo+IEFDRSBwcm9jZXNzIHdvdWxkIGhpZGUiLiBUaGF0IHNob3VsZCBi ZSBlbGxhYm9yYXRlZCBhIGJpdCBtb3JlLg0KDQp3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8g eW91ciBjb21tZW50cy4NCg0KPiAqIFNlY3Rpb24gMi40OiBzL0FUTU9JQy9BVE9NSUMvZw0KDQp3 aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4NCg0KDQo+ICogU2VjdGlv biAyLjQ6ICJ0aGUgc2VuZGVyIFNNVFAgc2VydmVyIGNhbiBhcHBseSBzb21lIGFsZ29yaXRobWlj IA0KPiB0cmFuc2Zvcm1hdGlvbiBzdWNoIGFzIHB1bnljb2RlIi4gIkNhbiI/ICJTaG91bGQiPyAi U0hPVUxEIj8gIk1VU1QiPyBJIGFtIA0KPiBmb3IgdGhlIGxhdHRlciBpbiB0aGlzIHBvaW50LiBJ biBhbnljYXNlIHRoZSBzZW50ZW5jZSB3b3VsZCBiZXR0ZXIgYmUgDQo+ICIuLmFwcGx5IHNvbWUg QVNDSUkgY29tcGF0aWJsZSBlbmNvZGluZyB0cmFuc2Zvcm1hdGlvbiIuDQoNCmJlZm9yZSBJRVRG NjUgbWVldGluZywgd2Ugc3RpbGwgbm90IHN1cmUgd2hpY2ggYWxnb3JpdGhtaWMgDQp0cmFuc2Zv cm1hdGlvbiB3aWxsIGJlIGFwcGxpZWQuIG5vdyBpdCBzZWVtcyB0aGF0IG1vc3Qgb2YgdXMgYWdy ZWUgdG8gdXNlIHB1bnljb2RlLiBzbyB3ZSB3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91 ciBjb21tZW50cy4NCg0KPiAqIFNlY3Rpb24gMi40OiAiSUROQSBtYXkgYWxzbyBiZSBhcHBsaWVk IHRvIHRoZSBkb21haW4gcGFydCIuICJtYXkiPyBvciANCj4gIk1VU1QiPw0KDQpub3cgd2Ugd2ls bCB1c2UgIk1VU1QiDQoNCj4gKiBTZWN0aW9uIDIuNDogSSBjb3VsZG4ndCBmaW5kIGFuIGV4cGxh bmF0aW9uIGluIHRoZSBhbGdvcml0aG0gZm9yIHRoZSANCj4gY2FzZSBpbiB3aGljaCBuZWl0aGVy IEFMVC1BRERSRVNTIG5vciBBVE9NSUMgYXJlIHByZXNlbnQuIEkgZ3Vlc3MgDQo+IHJlamVjdGlv biBpcyB0aGUgY29ycmVjdCB0aGluZywgYnV0IHRoZW4sIHdoeSBpcyBBVE9NSUMgb3B0aW9uYWwg YXQgYWxsPw0KDQppdCBpcyB1cCB0byB0aGUgIGVtYWlsIHNlbmRlciB0byBkZWNpZGUgd2hldGhl ciBBVE9NSUMgaXMgc2V0LiBzb21lIG9mIHRoZW0gbWF5IHByZWZlciB0aGUgYm91bmNlIGlmIElN QSBjYXBhYmlsaXR5IGlzIG5vdCBzdXBwb3J0ZWQuDQoNCg0KPiAqIFNlY3Rpb24gMi41OiAidGhl IG5hbWUgc2hvdWxkIGJlIGluIHB1bnljb2RlIGZvcm0gaWYgaXRzIHJhdyBmb3JtIGlzIA0KPiBu b24tQVNDSUkiLiAic2hvdWxkIiBvciAiTVVTVCI/IENmICJtYXkiIHR3byBidWxsZXRzIGFnby4g SW4gYW55IGNhc2UsIGFuZCANCj4gc2luY2UgVG9BU0NJSShhc2NpaSk9YXNjaWksIHRoZSBzZW50 ZW5jZSBzaG91bGQgcmVhZCAiLi4uYWx3YXlzIGluIEFTQ0lJIA0KPiBlbmNvZGVkIGZvcm0iLg0K DQoNCndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLg0KDQoNCj4gKiBT ZWN0aW9uIDIuNTogIjhCSVRNSU1FIHNob3VsZCBiZSBhZHZlcnRpc2VkIi4gSWYgOEJJVE1JTUUg aXMgYSANCj4gcmVxdWlyZW1lbnQgZm9yIElNQSwgYXMgSSB0aGluayBpdCBpcywgdGhlbiBpdCBz aG91bGQgYmUgIjhCSVRNSU1FIG11c3QgYmUgDQo+IGFkdmVydGlzZWQiLg0KDQp3aWxsIHVwZGF0 ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4NCg0KDQoNCj4gKiBTZWN0aW9uIDIuNS4x OiBzL3B1bnljb2RlIGZvcm0vQUNFIGZvcm0vDQoNCndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0 byB5b3VyIGNvbW1lbnRzLg0KDQo+ICogU2VjdGlvbiAyLjUuMjogIkludGVybmF0aW9uYWxpemVk IGRvbWFpbiBuYW1lcyBpbiBSZWNlaXZlZCBmaWVsZHMgc2hvdWxkIA0KPiBiZSB0cmFuc21pdHRl ZCBpbiBwdW55Y29kZSBmb3JtIi4gInNob3VsZCI/ICJTSE9VTEQiPyBXb3VsZG4ndCBpdCBiZSAN Cj4gYmV0dGVyICJNVVNUIj8NCg0Kb2ssICJNVVNUIiB3aWxsIGJlIHVzZWQuDQoNCg0KPiAqIFNl Y3Rpb24gMi41LjQ6IEl0IGlzIG1vb3Qgc2luY2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgImkxOG4t bWFpbCIgaGVhZGVyDQoNCm9rLCBJIHdpbGwgcmVtb3ZlIGl0Lg0KDQoNCg0KDQpUaGFua3MgYSBs b3QgYWdhaW4gZm9yIHlvdXIgdmVyeSBkZXRhaWxlZCBjb21tZW50cy4NCg0KQmVzdCBSZWdhcmRz DQoNCllBTyBKaWFua2FuZw0KQ05OSUMNCg0KDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IE1hcmNv cw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+IA== ------=_NextPart_000_00BD_01C65D4D.C62C8830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNTI4IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRk9OVD4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5Gcm9tOiAiTWFyY29zIFNhbnovRGVu aWMiICZsdDs8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86c2FuekBkZW5pYy5kZSI+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5zYW56QGRlbmljLmRlPC9GT05UPjwvQT48Rk9OVCAN CmZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jmd0OzwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5UbzogJmx0OzwvRk9OVD48QSBocmVmPSJt YWlsdG86aW1hQGlldGYub3JnIj48Rk9OVCANCmZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ aW1hQGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0y PiZndDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+U2VudDogRnJpZGF5LCBBcHJpbCAwNywgMjAwNiAxMDo1OSBQTTwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5TdWJqZWN0OiBbRUFJXSBDb21t ZW50cyBvbiBTTVRQIA0KZXh0ZW5zaW9uPC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzs+PEJSPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZndDsgQWxsLDxCUj4m Z3Q7IDxCUj4mZ3Q7IHRoZXNlIGFyZSBteSBjb21tZW50cyBvbiANCmRyYWZ0LXlhby1pbWEtc210 cGV4dC0wMi4gSSBoYXZlbid0IGJlZW4gPEJSPiZndDsgZm9sbG93aW5nIHRoZSBsYXN0IGRpc2N1 c3Npb25zIA0KaW4gdGhlIGxpc3QuIElmIHNvbWUgb2YgdGhlc2UgaXNzdWVzIChvciA8QlI+Jmd0 OyBhbnkgb2YgdGhvc2UgaW4gbXkgZm9sbG93aW5nIA0KbWFpbHMpIGhhdmUgYWxyZWFkeSBiZWVu IGRlYWx0IHdpdGgsIHRoZW4gPEJSPiZndDsganVzdCBnaXZlIG1lIGEgDQpwb2ludGVyLjxCUj4m Z3Q7IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+dGhhbmtzIGEgbG90IGZvciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEJSPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jmd0OyAqIFNl Y3Rpb24gMS4xOiBSRkMgMTg2OSBpcyBvYnNvbGV0ZSwgY3VycmVudCANCmlzIDI4MjE8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPndpbGwg dXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIA0KY29tbWVudHMuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOzwvRElWPg0KPERJVj48 QlI+Jmd0OyAqIFNlY3Rpb24gMS4yOiAiRG9tYWluIHBhcnQgb2YgdGhlIGVtYWlsIGFkZHJlc3Mg bWF5IGJlIA0KaW50ZXJuYXRpb25hbGl6ZWQgPEJSPiZndDsgdGhyb3VnaCBJRE5BIi4gSXQgc2hv dWxkIHJhdGhlciBiZSAiLi5oYXMgYmVlbiANCmludGVybmF0aW9uYWxpemVkLi4iLjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+aW4gb3VyIGluaXRpYWwgdmVyc2lvbiwgd2UgdXNlJm5i c3A7Jm5ic3A7Ii4uaGFzIGJlZW4gaW50ZXJuYXRpb25hbGl6ZWQuLiIuIA0KYnV0IHdoZW4gd2Ug Y29uc2lkZXI8L0RJVj4NCjxESVY+dGhhdCBkb21haW4gcGFydCBvZiBlbWFpbCBpcyBkaWZmZXJl bnQgZnJvbSB0aGUgbm9ybWFsIGRvbWFpbiBuYW1lLCB3ZSBtYXkgDQp1c2UgZGlmZmVyZW50IGlu dGVybmF0aW9uYWxpemVkIG1ldGhvZCBmb3IgZG9tYWluIHBhcnQgb2YgZW1haWwgYWRkcmVzcy4g c28gd2UgDQp1c2UgIkRvbWFpbiBwYXJ0IG9mIHRoZSBlbWFpbCBhZGRyZXNzIG1heSBiZSBpbnRl cm5hdGlvbmFsaXplZCB0aHJvdWdoIElETkEiLiANCmFmdGVyIHdlIGZpbmFsaXplIHRoZSBJTUEg bWV0aG9kLCB3ZSBtYXkgdXNlIHRoaXMga2luZCBvZiBzZW50ZW5zZSA6ICJEb21haW4gDQpwYXJ0 IG9mIHRoZSBlbWFpbCBhZGRyZXNzJm5ic3A7aGFzIGJlZW4gaW50ZXJuYXRpb25hbGl6ZWQgdGhy b3VnaCBJRE5BIi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj48QlI+Jmd0OyAqIFNlY3Rpb24gMS4yOiAiU2luY2Ugb2xkZXIgU01UUCBzZXJ2ZXJzIGFu ZCB0aGUgbWFpbC1yZWFkaW5nIA0KY2xpZW50cyA8QlI+Jmd0OyBbLi4uXSBtYXkgbm90IGJlIHBy ZXBhcmVkIHRvIGhhbmRsZSB0aGVzZSBleHRlbmRlZCBhZGRyZXNzZXMsIA0KYW4gU01UUCA8QlI+ Jmd0OyBleHRlbnNpb24gaXMgc3BlY2lmaWVkIi4gVGhpcyBjb3VsZCBiZSBuaXRwaWNraW5nLCBi dXQgSSBkb24ndCANCnRoaW5rIHRoYXQgPEJSPiZndDsgd2UgYXJlIHByb3RlY3RpbmcgdGhvc2Ug bWFpbC1yZWFkaW5nIGNsaWVudHMgd2l0aCB0aGlzIFNNVFAgDQpleHRlbnNpb24uIEkgPEJSPiZn dDsgd291bGQgY3Jvc3MgdGhlbSBvdXQgb2YgdGhhdCBzZW50ZW5jZS48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj53aWxsIHVwZGF0ZSBpdCBhY2NvcmRp bmcgdG8geW91ciBjb21tZW50czwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlvbiAyLjI6ICJETlMgTVVTVCBiZSBwcm9jZXNz ZWQgaW50byBwdW55Y29kZSBmb3JtIGFzIA0Kc3BlY2lmaWVkIGluIDxCUj4mZ3Q7IElETkEiLiBJ IGRvbid0IHRoaW5rIHRoYXQgcHVueWNvZGUgKGNvbmNyZXRlIEFDRSBlbmNvZGluZykgDQppcyBy ZWxldmFudCBhdCA8QlI+Jmd0OyBhbGwgaGVyZS4gUHVueWNvZGUgaXMgcGFydCBvZiB0aGUgaW50 ZXJuYWxzIG9mIElETkEuIEkgDQpzdWdnZXN0IG1vZGlmeWluZyA8QlI+Jmd0OyB0aGUgc2VudGVu Y2UgdG8gIkROUyBNVVNUIGJlIHByb2Nlc3NlZCBhcyBzcGVjaWZpZWQgDQppbiBJRE5BIGJ5IG1l YW5zIG9mIDxCUj4mZ3Q7IHRoZSBUb0FTQ0lJKCkgb3BlcmF0aW9uIi48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj53aWxsIHVwZGF0ZSBpdCBhY2NvcmRp bmcgdG8geW91ciBjb21tZW50cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj4m Z3Q7ICogU2VjdGlvbiAyLjI6ICJhbmQgdGhlbiBNVVNUIGJlIGNvbXBhcmVkIGFzIHNwZWNpZmll ZCBpbiBJRE5BIi4gDQpNeSA8QlI+Jmd0OyBleHBlcmllbmNlIGlzIHRoYXQgcGVvcGxlIG92ZXJs b29rIHRoaXMgY29tcGFyaXNvbiBkZWZpbml0aW9uLCB0aHVzIA0KaXQgPEJSPiZndDsgd291bGQg YmUgcHJhY3RpY2FsIHRvIG1ha2UgYW4gZXhhY3QgcmVmZXJlbmNlOiBTZWN0aW9uIDMuMS40IG9m IFJGQyANCjM0OTA8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj53aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlvbiAyLjI6IHMvZWl0aGVyIHB1 bnljb2RlL2VpdGhlciBBQ0UvPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj53aWxsIHVw ZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlvbiAyLjI6ICJ0aGUgb3JpZ2luYWwgU01UUCBjbGll bnQgU0hPVUxEIGZpcnN0IHZlcmlmeSB0aGF0IA0KdGhlIDxCUj4mZ3Q7IHN0cmluZyBpcyB2YWxp ZCBmb3IgYSBkb21haW4gbmFtZSBhY2NvcmRpbmcgdG8gSUROQSBydWxlcyIuIFdoeSBhbmQgDQpm b3IgPEJSPiZndDsgd2hpY2ggZmllbGRzPyBBbmQgd2hhdCBpZiB0aGF0IGZhaWxzPyBSZWFjdGlv biBzaG91bGQgcHJvYmFibHkgDQpkZXBlbmQgb24gPEJSPiZndDsgdGhlIGV4YWN0IGZpZWxkIG9m IGZhaWx1cmUgYXBwZWFyYW5jZS4gVGhhdCBtdXN0IGJlIA0KZGVmaW5lZC48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPml0IGNoZWNrcyB0aGUgdmFsaWRpdHkgb2YgZW1haWwgYWRkcmVz cy4gaWYgdGhlIGNsaWVudCBmb3VuZCB0aGF0IGRvbWFpbiANCm5hbWUgaXMgbm90IHZhbGlkLCBp dCBtZWFucyB0aGF0IHRoZSBlbWFpbCBhZGRyZXNzIGlzIG5vdCB2YWxpZC4gaXQgdGhlIGFkZHJl c3MgDQppcyBub3QgdmFsaWQsIGl0IHdpbGwgcmVmdXNlIHRvIHNlbmQgdGhlIGVtYWlsIG1lc3Nh Z2UuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+Jmd0OyAqIFNlY3Rpb24gMi4y OiBzL2l0IE1VU1Qgbm90IGF0dGVtcHQgdG8gcGFyc2UvaXQgTVVTVCBOT1QgYXR0ZW1wdCANCnRv IDxCUj4mZ3Q7IHBhcnNlLzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+d2lsbCB1cGRh dGUgaXQgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMuPC9ESVY+DQo8RElWPjxCUj4mZ3Q7ICog U2VjdGlvbiAyLjI6IHMvQ2xpZW50IE1VU1Qgbm90IHRyYW5zbWl0L2NsaWVudCBNVVNUIE5PVCAN CnRyYW5zbWl0LzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+d2lsbCB1cGRhdGUgaXQg YWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMuPC9ESVY+DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlv biAyLjM6ICJDaGFuZ2UgdGhlIGRlZmluaXRpb24gb2YgJ0F0b20nIHRvIHBlcm1pdCBlaXRoZXIg DQp0aGUgPEJSPiZndDsgZGVmaW5pdGlvbiBhYm92ZSBvciBhIFVURi04IHN0cmluZyIuIFRoaXMg Y29tcGxldGUgbGliZXJhbGl6YXRpb24gDQpvZiB0aGUgPEJSPiZndDsgbG9jYWwgcGFydCBtYWtl cyBtZSBmZWVsIHZlcnkgdW5lYXN5LCBub3QgYWxsIGNoYXJhY3RlcnMgYXJlIA0KYXBwcm9wcmlh dGUgPEJSPiZndDsgdG8gYmVjb21lIHBhcnQgb2YgYW4gaWRlbnRpZmllciAoY2YgdGhlIFVuaWNv ZGUgU3RhbmRhcmQgDQpBbm5leCAzMSwgPEJSPiZndDsgSWRlbnRpZmllciBhbmQgUGF0dGVybiBT eW50YXgpLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+eWVzLCB3ZSBoYXZlIG5vdGlj ZWQgdGhpcyBwcm9ibGVtLiB3ZSB3aWxsIHJlZmluZSB0aGUgZGVmaW5pdGlvbi48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+Jmd0OyAqIFNlY3Rp b24gMi4zOiBSRkMyMjM0IGlzIG9ic29sZXRlLCBjdXJyZW50IGlzIDQyMzQ8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1l bnRzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxC Uj4mZ3Q7ICogU2VjdGlvbiAyLjM6IE5pdHBpY2tpbmcgInN1Yi1kb21haW4gPSBMZXQtZGlnIFtM ZGgtc3RyXSAvIA0KJmx0O2FueSA8QlI+Jmd0OyBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbGFi ZWwgc3BlY2lmaWVkIGJ5IElETkEmZ3Q7IiBUaGUgDQpmb3JtZXIgYXJlIGEgc3Vic2V0IDxCUj4m Z3Q7IG9mIHRoZSBsYXR0ZXIsIHRodXMgInN1Yi1kb21haW4gPSAmbHQ7YW55IA0KaW50ZXJuYXRp b25hbGl6ZWQgZG9tYWluIGxhYmVsIDxCUj4mZ3Q7IHNwZWNpZmllZCBieSBJRE5BJmd0OyIgaXMg ZW5vdWdoIGZvciANCnRoYXQgaW5mb3JtYWwgcHVycG9zZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPndpbGwgdXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPiZndDsgKiBTZWN0aW9uIDIuNDogcy9tYXkg c2V0IGJ5IHNlbmRlci9tYXkgYmUgc2V0IGJ5IHRoZSBzZW5kZXIvPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj53aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlvbiAyLjQ6ICJh cmUgZGF0YSBvciBpbnN0cnVjdGlvbnMgZW1iZWRkZWQgaW4gdGhlIGFkZHJlc3MgDQp0aGF0IHRo ZSA8QlI+Jmd0OyBBQ0UgcHJvY2VzcyB3b3VsZCBoaWRlIi4gVGhhdCBzaG91bGQgYmUgZWxsYWJv cmF0ZWQgYSBiaXQgDQptb3JlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+d2lsbCB1 cGRhdGUgaXQgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMuPC9ESVY+DQo8RElWPjxCUj4mZ3Q7 ICogU2VjdGlvbiAyLjQ6IHMvQVRNT0lDL0FUT01JQy9nPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj53aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlvbiAyLjQ6ICJ0aGUgc2Vu ZGVyIFNNVFAgc2VydmVyIGNhbiBhcHBseSBzb21lIGFsZ29yaXRobWljIA0KPEJSPiZndDsgdHJh bnNmb3JtYXRpb24gc3VjaCBhcyBwdW55Y29kZSIuICJDYW4iPyAiU2hvdWxkIj8gIlNIT1VMRCI/ ICJNVVNUIj8gSSANCmFtIDxCUj4mZ3Q7IGZvciB0aGUgbGF0dGVyIGluIHRoaXMgcG9pbnQuIElu IGFueWNhc2UgdGhlIHNlbnRlbmNlIHdvdWxkIGJldHRlciANCmJlIDxCUj4mZ3Q7ICIuLmFwcGx5 IHNvbWUgQVNDSUkgY29tcGF0aWJsZSBlbmNvZGluZyB0cmFuc2Zvcm1hdGlvbiIuPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5iZWZvcmUgSUVURjY1IG1lZXRpbmcsJm5ic3A7d2Ugc3Rp bGwgbm90IHN1cmUgd2hpY2ggYWxnb3JpdGhtaWMgDQo8QlI+dHJhbnNmb3JtYXRpb24gd2lsbCBi ZSBhcHBsaWVkLiBub3cgaXQgc2VlbXMgdGhhdCBtb3N0IG9mIHVzIGFncmVlIHRvIHVzZSANCnB1 bnljb2RlLiBzbyB3ZSB3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy48 L0RJVj4NCjxESVY+PEJSPiZndDsgKiBTZWN0aW9uIDIuNDogIklETkEgbWF5IGFsc28gYmUgYXBw bGllZCB0byB0aGUgZG9tYWluIHBhcnQiLiANCiJtYXkiPyBvciA8QlI+Jmd0OyAiTVVTVCI/PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5ub3cgd2Ugd2lsbCB1c2UgIk1VU1QiPC9ESVY+ DQo8RElWPjxCUj4mZ3Q7ICogU2VjdGlvbiAyLjQ6IEkgY291bGRuJ3QgZmluZCBhbiBleHBsYW5h dGlvbiBpbiB0aGUgYWxnb3JpdGhtIGZvciANCnRoZSA8QlI+Jmd0OyBjYXNlIGluIHdoaWNoIG5l aXRoZXIgQUxULUFERFJFU1Mgbm9yIEFUT01JQyBhcmUgcHJlc2VudC4gSSBndWVzcyANCjxCUj4m Z3Q7IHJlamVjdGlvbiBpcyB0aGUgY29ycmVjdCB0aGluZywgYnV0IHRoZW4sIHdoeSBpcyBBVE9N SUMgb3B0aW9uYWwgYXQgDQphbGw/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5pdCBp cyB1cCB0byZuYnNwO3RoZSAmbmJzcDtlbWFpbCBzZW5kZXIgdG8gZGVjaWRlIHdoZXRoZXIgQVRP TUlDIGlzIHNldC4gDQpzb21lIG9mIHRoZW0gbWF5IHByZWZlciB0aGUgYm91bmNlIGlmIElNQSBj YXBhYmlsaXR5IGlzIG5vdCBzdXBwb3J0ZWQuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48QlI+Jmd0OyAqIFNlY3Rpb24gMi41OiAidGhlIG5hbWUgc2hvdWxkIGJlIGluIHB1bnljb2Rl IGZvcm0gaWYgaXRzIHJhdyANCmZvcm0gaXMgPEJSPiZndDsgbm9uLUFTQ0lJIi4gInNob3VsZCIg b3IgIk1VU1QiPyBDZiAibWF5IiB0d28gYnVsbGV0cyBhZ28uIEluIA0KYW55IGNhc2UsIGFuZCA8 QlI+Jmd0OyBzaW5jZSBUb0FTQ0lJKGFzY2lpKT1hc2NpaSwgdGhlIHNlbnRlbmNlIHNob3VsZCBy ZWFkIA0KIi4uLmFsd2F5cyBpbiBBU0NJSSA8QlI+Jmd0OyBlbmNvZGVkIGZvcm0iLjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPndpbGwgdXBkYXRlIGl0 IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEJSPiZndDsgKiBTZWN0aW9uIDIuNTogIjhCSVRNSU1FIHNob3VsZCBiZSBhZHZlcnRpc2Vk Ii4gSWYgOEJJVE1JTUUgaXMgYSANCjxCUj4mZ3Q7IHJlcXVpcmVtZW50IGZvciBJTUEsIGFzIEkg dGhpbmsgaXQgaXMsIHRoZW4gaXQgc2hvdWxkIGJlICI4QklUTUlNRSBtdXN0IA0KYmUgPEJSPiZn dDsgYWR2ZXJ0aXNlZCIuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj53aWxsIHVwZGF0 ZSBpdCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+Jmd0OyAqIFNlY3Rpb24gMi41LjE6IHMvcHVu eWNvZGUgZm9ybS9BQ0UgZm9ybS88L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPndpbGwg dXBkYXRlIGl0IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLjwvRElWPg0KPERJVj48QlI+Jmd0 OyAqIFNlY3Rpb24gMi41LjI6ICJJbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFtZXMgaW4gUmVj ZWl2ZWQgDQpmaWVsZHMgc2hvdWxkIDxCUj4mZ3Q7IGJlIHRyYW5zbWl0dGVkIGluIHB1bnljb2Rl IGZvcm0iLiAic2hvdWxkIj8gIlNIT1VMRCI/IA0KV291bGRuJ3QgaXQgYmUgPEJSPiZndDsgYmV0 dGVyICJNVVNUIj88L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPm9rLCAiTVVTVCIgd2ls bCBiZSB1c2VkLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPiZndDsgKiBTZWN0 aW9uIDIuNS40OiBJdCBpcyBtb290IHNpbmNlIHRoZSBpbmNsdXNpb24gb2YgdGhlICJpMThuLW1h aWwiIA0KaGVhZGVyPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5vaywgSSB3aWxsIHJl bW92ZSBpdC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBhIGxvdCBhZ2Fp biBmb3IgeW91ciB2ZXJ5IGRldGFpbGVkIGNvbW1lbnRzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+QmVzdCBSZWdhcmRzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5ZQU8g Smlhbmthbmc8L0RJVj4NCjxESVY+Q05OSUM8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxCUj4mZ3Q7IDxCUj4mZ3Q7IEJlc3QgcmVnYXJkcyw8QlI+Jmd0OyBNYXJjb3M8QlI+Jmd0OyA8 QlI+Jmd0OyANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PEJSPiZndDsgSU1BIG1haWxpbmcgbGlzdDxCUj4mZ3Q7IA0KPC9GT05UPjxBIGhyZWY9Im1haWx0 bzpJTUFAaWV0Zi5vcmciPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj5JTUFA aWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0y PiZndDsgPC9GT05UPjxBIA0KaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaW1hIj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+aHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hPC9GT05UPjwvQT48QlI+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6ZT0yPiZndDsgPC9GT05UPjwvRElWPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_00BD_01C65D4D.C62C8830-- --===============0182254776== 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 --===============0182254776==-- From ima-bounces@ietf.org Mon Apr 10 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UP-0005xt-Kr; Mon, 10 Apr 2006 22:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UO-0005xi-8u for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8UL-0001dQ-Ji for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from host81-144-64-156.midband.mdip.bt.net ([81.144.64.156]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 443b125e.15d31.aab for ima@ietf.org; Tue, 11 Apr 2006 03:20:14 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3AKfu418058 for ; Mon, 10 Apr 2006 21:41:57 +0100 (BST) To: "ima@ietf.org" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> <4430FFDF.6040603@alvestrand.no> <6.0.0.20.2.20060404182318.0912a620@localhost> Message-ID: Date: Mon, 10 Apr 2006 21:41:46 +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: <6.0.0.20.2.20060404182318.0912a620@localhost> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, 05 Apr 2006 06:16:03 +0100, Martin Duerst wrote: > >As far as I can tell, all participants except for you have said that > the "fax test" and "telephone test" are NOT relevant to the EAI working > group. > > > >Unless I hear differently from someone else, I'm going to note this as > a closed issue for the WG. > > Just for the record, you just heard differently from someone else. Thank you. > Charles' starting point was IDNA. The main reason for why I think > we will end up with something different from IDNA is that one of > the main concerns in IDNA was conflicting registrations, or the > need for multiple (potentially a high number) of registrations to > avoid having a name being spoofed. This is considerably different > for LHS. In most cases, LHS don't get handed out simply on a > first-come-first-served-anything-goes basis. Where they do > (webmail hosting,...), the organizations in charge should be > large enough to be able to manage the problem. > > The other thing that we don't need to copy from IDNA, because it > was probably a mistake (even though not really such an important one), > is the use of NFKC. This came about because some people wanted > half-width and full-width variants (as they appear in East Asian > encodings) to be treated equivalently, the same way uppercase and > lowercase are treated as equivalents in the DNS. You surprise me. But we have many East Asians on this list, so we need to hear from them. It seems to me that local-parts with characters of the "wrong" width would easily fail the telephone test. It it usual in those languages to convey information (as opposed to style) in the widths of the characters that are used? > This was only > available in NFKC, but that brought in a host of other equivalences > that were really not necessary. A good example is that in a > fully IDNA-compliant application, you can use special numbers > with circles around them in place of the usual ASCII digits, > and get to the same place. So would we want it otherwise? Admittedly those would pass both the telephone and the fax tests, but it still strikes me as very bad practice, and if we lose those just because we wanted to keep it to "all of NFKC or none of it", it would not cause me any grief. Anyway, these are all issues we need to coinsider at some time. The first step is to see and discuss what John is currently writing. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UP-0005xo-I8; Mon, 10 Apr 2006 22:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UO-0005xe-89 for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8UL-0001dO-Ji for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from host81-144-64-156.midband.mdip.bt.net ([81.144.64.156]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 443b125d.15d31.aaa for ima@ietf.org; Tue, 11 Apr 2006 03:20:13 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3AKVE417956 for ; Mon, 10 Apr 2006 21:31:15 +0100 (BST) Date: Mon, 10 Apr 2006 21:30:58 +0100 To: "ima@ietf.org" Subject: Re: [EAI] Comments on IMA framework References: 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: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 10 Apr 2006 11:31:05 +0100, Marcos Sanz/Denic wrote: > Admittedly, maybe the point was not clear. In my comments to the > Headers-document, I have tried to defend the position that the update to > the internet mail format should be in terms of a syntax extension to > support new *Unicode* characters, and not *UTF-8* characters. Ideally, > the > word "UTF-8" would not have a single appearance in the Headers-document, > because it is just a matter of transport. I mean, I could store my mails > in UTF-16, as long as I use UTF-8 to communicate with an SMTP server. Yes, but the tradition within the IETF is always to define the format of objects as they will appear "on the wire". I.e., if I am going to send you (by some transport mechanism) a document conforming to our standard (and if we have no prior arrangement otherwise), then it had better have its headers in UTF-8 and not in UTF-16. If you choose to convert it for storage, and display, then that is up to you. Likewise, it is well known that Unix systems invariably store line endings with a single 'LF' character. Nevertheless, the standards always specify CRLF, because that is the form in which it should be passed from one application to another (private arrangements excepted). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UP-0005xt-Kr; Mon, 10 Apr 2006 22:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UO-0005xi-8u for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8UL-0001dQ-Ji for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from host81-144-64-156.midband.mdip.bt.net ([81.144.64.156]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 443b125e.15d31.aab for ima@ietf.org; Tue, 11 Apr 2006 03:20:14 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3AKfu418058 for ; Mon, 10 Apr 2006 21:41:57 +0100 (BST) To: "ima@ietf.org" Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> <4430FFDF.6040603@alvestrand.no> <6.0.0.20.2.20060404182318.0912a620@localhost> Message-ID: Date: Mon, 10 Apr 2006 21:41:46 +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: <6.0.0.20.2.20060404182318.0912a620@localhost> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, 05 Apr 2006 06:16:03 +0100, Martin Duerst wrote: > >As far as I can tell, all participants except for you have said that > the "fax test" and "telephone test" are NOT relevant to the EAI working > group. > > > >Unless I hear differently from someone else, I'm going to note this as > a closed issue for the WG. > > Just for the record, you just heard differently from someone else. Thank you. > Charles' starting point was IDNA. The main reason for why I think > we will end up with something different from IDNA is that one of > the main concerns in IDNA was conflicting registrations, or the > need for multiple (potentially a high number) of registrations to > avoid having a name being spoofed. This is considerably different > for LHS. In most cases, LHS don't get handed out simply on a > first-come-first-served-anything-goes basis. Where they do > (webmail hosting,...), the organizations in charge should be > large enough to be able to manage the problem. > > The other thing that we don't need to copy from IDNA, because it > was probably a mistake (even though not really such an important one), > is the use of NFKC. This came about because some people wanted > half-width and full-width variants (as they appear in East Asian > encodings) to be treated equivalently, the same way uppercase and > lowercase are treated as equivalents in the DNS. You surprise me. But we have many East Asians on this list, so we need to hear from them. It seems to me that local-parts with characters of the "wrong" width would easily fail the telephone test. It it usual in those languages to convey information (as opposed to style) in the widths of the characters that are used? > This was only > available in NFKC, but that brought in a host of other equivalences > that were really not necessary. A good example is that in a > fully IDNA-compliant application, you can use special numbers > with circles around them in place of the usual ASCII digits, > and get to the same place. So would we want it otherwise? Admittedly those would pass both the telephone and the fax tests, but it still strikes me as very bad practice, and if we lose those just because we wanted to keep it to "all of NFKC or none of it", it would not cause me any grief. Anyway, these are all issues we need to coinsider at some time. The first step is to see and discuss what John is currently writing. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Apr 10 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UP-0005xo-I8; Mon, 10 Apr 2006 22:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8UO-0005xe-89 for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8UL-0001dO-Ji for ima@ietf.org; Mon, 10 Apr 2006 22:20:20 -0400 Received: from host81-144-64-156.midband.mdip.bt.net ([81.144.64.156]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 443b125d.15d31.aaa for ima@ietf.org; Tue, 11 Apr 2006 03:20:13 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3AKVE417956 for ; Mon, 10 Apr 2006 21:31:15 +0100 (BST) Date: Mon, 10 Apr 2006 21:30:58 +0100 To: "ima@ietf.org" Subject: Re: [EAI] Comments on IMA framework References: 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: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 10 Apr 2006 11:31:05 +0100, Marcos Sanz/Denic wrote: > Admittedly, maybe the point was not clear. In my comments to the > Headers-document, I have tried to defend the position that the update to > the internet mail format should be in terms of a syntax extension to > support new *Unicode* characters, and not *UTF-8* characters. Ideally, > the > word "UTF-8" would not have a single appearance in the Headers-document, > because it is just a matter of transport. I mean, I could store my mails > in UTF-16, as long as I use UTF-8 to communicate with an SMTP server. Yes, but the tradition within the IETF is always to define the format of objects as they will appear "on the wire". I.e., if I am going to send you (by some transport mechanism) a document conforming to our standard (and if we have no prior arrangement otherwise), then it had better have its headers in UTF-8 and not in UTF-16. If you choose to convert it for storage, and display, then that is up to you. Likewise, it is well known that Unix systems invariably store line endings with a single 'LF' character. Nevertheless, the standards always specify CRLF, because that is the form in which it should be passed from one application to another (private arrangements excepted). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 02:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCVB-0004e1-0t; Tue, 11 Apr 2006 02:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCV5-0004dK-H0 for ima@ietf.org; Tue, 11 Apr 2006 02:37:19 -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 1FTCV4-00030z-2q for ima@ietf.org; Tue, 11 Apr 2006 02:37:19 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FTCV2-000FpI-TU; Tue, 11 Apr 2006 02:37:17 -0400 Date: Tue, 11 Apr 2006 02:37:16 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Message-ID: <5EDD3FC5C03680A241ACCC97@p3.JCK.COM> In-Reply-To: References: <4422D0FF.5070008@alvestrand.no> <4423FB74.7050203@alvestrand.no> <6.0.0.20.2.20060329141320.086d2680@localhost> <7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org> <442B8987.1080707@alvestrand.no> <4430FFDF.6040603@alvestrand.no> <6.0.0.20.2.20060404182318.0912a620@localhost> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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, 10 April, 2006 21:41 +0100 Charles Lindsey wrote: >> The other thing that we don't need to copy from IDNA, because >> it was probably a mistake (even though not really such an >> important one), is the use of NFKC. This came about because >> some people wanted half-width and full-width variants (as >> they appear in East Asian encodings) to be treated >> equivalently, the same way uppercase and lowercase are >> treated as equivalents in the DNS. > > You surprise me. But we have many East Asians on this list, so > we need to hear from them. It seems to me that local-parts > with characters of the "wrong" width would easily fail the > telephone test. It it usual in those languages to convey > information (as opposed to style) in the widths of the > characters that are used? Charles, Please see my recent response to some of these issues. If I were running an email receiving system for which half-width and full-width variations were considered important, the robustness principle would certainly argue for accepting them as equivalent. But it is neither necessary nor desirable to try to write rules like this into the protocol. >> This was only >> available in NFKC, but that brought in a host of other >> equivalences that were really not necessary. A good example >> is that in a fully IDNA-compliant application, you can use >> special numbers with circles around them in place of the >> usual ASCII digits, and get to the same place. > > So would we want it otherwise? Admittedly those would pass > both the telephone and the fax tests, but it still strikes me > as very bad practice, and if we lose those just because we > wanted to keep it to "all of NFKC or none of it", it would > not cause me any grief. > > Anyway, these are all issues we need to coinsider at some > time. The first step is to see and discuss what John is > currently writing. What John is currently writing in this area will be, for addresses, strictly conformant with the traditional email norm that acceptability and matching are entirely the province of the delivery MTA. What I'll have to say about canonicalization of headers (still waiting for one of my collaborators) will be what Martin and the (other) Unicode folks have recommended, which is NFC and only NFC -- unless someone can demonstrate that it is either overkill or insufficient. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 02:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCoN-00036g-Ir; Tue, 11 Apr 2006 02:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCoL-00036a-HN for ima@ietf.org; Tue, 11 Apr 2006 02:57:13 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTCoJ-0003HR-DE for ima@ietf.org; Tue, 11 Apr 2006 02:57:13 -0400 Received: (eyou send program); Tue, 11 Apr 2006 14:56:58 +0800 Message-ID: <344738618.17360@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.145 with SMTP; Tue, 11 Apr 2006 14:56:58 +0800 Message-ID: <01d701c65d35$5fc3dfc0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "Charles Lindsey" References: <4422D0FF.5070008@alvestrand.no><4423FB74.7050203@alvestrand.no><6.0.0.20.2.20060329141320.086d2680@localhost><7.0.1.0.0.20060329094742.03652e50@OpenLDAP.org><442B8987.1080707@alvestrand.no><4430FFDF.6040603@alvestrand.no><6.0.0.20.2.20060404182318.0912a620@localhost> <344722033.12567@cnnic.cn> Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label) Date: Tue, 11 Apr 2006 14:58:44 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.0 (+) X-Scan-Signature: 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: , Content-Type: multipart/mixed; boundary="===============0520452847==" Errors-To: ima-bounces@ietf.org --===============0520452847== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAxMSwgMjAwNiA0OjQxIEFNDQpTdWJqZWN0OiBSZTogTm9ybWFsaXppbmcgVW5pY29k ZSAoUmU6IFtFQUldIHNpbGx5IHN0YXRlcyBhbmQgaGVhZGVyIGxhYmVsKQ0KDQoNCj4gT24gV2Vk LCAwNSBBcHIgMjAwNiAwNjoxNjowMyArMDEwMCwgTWFydGluIER1ZXJzdCA8ZHVlcnN0QGl0LmFv eWFtYS5hYy5qcD4gIA0KPiB3cm90ZToNCj4gDQo+IA0KPiA+ICA+QXMgZmFyIGFzIEkgY2FuIHRl bGwsIGFsbCBwYXJ0aWNpcGFudHMgZXhjZXB0IGZvciB5b3UgaGF2ZSBzYWlkIHRoYXQgIA0KPiA+ IHRoZSAiZmF4IHRlc3QiIGFuZCAidGVsZXBob25lIHRlc3QiIGFyZSBOT1QgcmVsZXZhbnQgdG8g dGhlIEVBSSB3b3JraW5nICANCj4gPiBncm91cC4NCj4gPiAgPg0KPiA+ICA+VW5sZXNzIEkgaGVh ciBkaWZmZXJlbnRseSBmcm9tIHNvbWVvbmUgZWxzZSwgSSdtIGdvaW5nIHRvIG5vdGUgdGhpcyBh cyAgDQo+ID4gYSBjbG9zZWQgaXNzdWUgZm9yIHRoZSBXRy4NCj4gPg0KPiA+IEp1c3QgZm9yIHRo ZSByZWNvcmQsIHlvdSBqdXN0IGhlYXJkIGRpZmZlcmVudGx5IGZyb20gc29tZW9uZSBlbHNlLg0K PiANCj4gVGhhbmsgeW91Lg0KPiANCj4gDQo+ID4gQ2hhcmxlcycgc3RhcnRpbmcgcG9pbnQgd2Fz IElETkEuIFRoZSBtYWluIHJlYXNvbiBmb3Igd2h5IEkgdGhpbmsNCj4gPiB3ZSB3aWxsIGVuZCB1 cCB3aXRoIHNvbWV0aGluZyBkaWZmZXJlbnQgZnJvbSBJRE5BIGlzIHRoYXQgb25lIG9mDQo+ID4g dGhlIG1haW4gY29uY2VybnMgaW4gSUROQSB3YXMgY29uZmxpY3RpbmcgcmVnaXN0cmF0aW9ucywg b3IgdGhlDQo+ID4gbmVlZCBmb3IgbXVsdGlwbGUgKHBvdGVudGlhbGx5IGEgaGlnaCBudW1iZXIp IG9mIHJlZ2lzdHJhdGlvbnMgdG8NCj4gPiBhdm9pZCBoYXZpbmcgYSBuYW1lIGJlaW5nIHNwb29m ZWQuIFRoaXMgaXMgY29uc2lkZXJhYmx5IGRpZmZlcmVudA0KPiA+IGZvciBMSFMuIEluIG1vc3Qg Y2FzZXMsIExIUyBkb24ndCBnZXQgaGFuZGVkIG91dCBzaW1wbHkgb24gYQ0KPiA+IGZpcnN0LWNv bWUtZmlyc3Qtc2VydmVkLWFueXRoaW5nLWdvZXMgYmFzaXMuIFdoZXJlIHRoZXkgZG8NCj4gPiAo d2VibWFpbCBob3N0aW5nLC4uLiksIHRoZSBvcmdhbml6YXRpb25zIGluIGNoYXJnZSBzaG91bGQg YmUNCj4gPiBsYXJnZSBlbm91Z2ggdG8gYmUgYWJsZSB0byBtYW5hZ2UgdGhlIHByb2JsZW0uDQo+ ID4NCj4gPiBUaGUgb3RoZXIgdGhpbmcgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIGNvcHkgZnJvbSBJ RE5BLCBiZWNhdXNlIGl0DQo+ID4gd2FzIHByb2JhYmx5IGEgbWlzdGFrZSAoZXZlbiB0aG91Z2gg bm90IHJlYWxseSBzdWNoIGFuIGltcG9ydGFudCBvbmUpLA0KPiA+IGlzIHRoZSB1c2Ugb2YgTkZL Qy4gVGhpcyBjYW1lIGFib3V0IGJlY2F1c2Ugc29tZSBwZW9wbGUgd2FudGVkDQo+ID4gaGFsZi13 aWR0aCBhbmQgZnVsbC13aWR0aCB2YXJpYW50cyAoYXMgdGhleSBhcHBlYXIgaW4gRWFzdCBBc2lh bg0KPiA+IGVuY29kaW5ncykgdG8gYmUgdHJlYXRlZCBlcXVpdmFsZW50bHksIHRoZSBzYW1lIHdh eSB1cHBlcmNhc2UgYW5kDQo+ID4gbG93ZXJjYXNlIGFyZSB0cmVhdGVkIGFzIGVxdWl2YWxlbnRz IGluIHRoZSBETlMuDQo+IA0KPiBZb3Ugc3VycHJpc2UgbWUuIEJ1dCB3ZSBoYXZlIG1hbnkgRWFz dCBBc2lhbnMgb24gdGhpcyBsaXN0LCBzbyB3ZSBuZWVkIHRvICANCj4gaGVhciBmcm9tIHRoZW0u IEl0IHNlZW1zIHRvIG1lIHRoYXQgbG9jYWwtcGFydHMgd2l0aCBjaGFyYWN0ZXJzIG9mIHRoZSAg DQo+ICJ3cm9uZyIgd2lkdGggd291bGQgZWFzaWx5IGZhaWwgdGhlIHRlbGVwaG9uZSB0ZXN0LiBJ dCBpdCB1c3VhbCBpbiB0aG9zZSAgDQo+IGxhbmd1YWdlcyB0byBjb252ZXkgaW5mb3JtYXRpb24g KGFzIG9wcG9zZWQgdG8gc3R5bGUpIGluIHRoZSB3aWR0aHMgb2YgdGhlICANCj4gY2hhcmFjdGVy cyB0aGF0IGFyZSB1c2VkPw0KPiANCkRlYXIgQ2hhcmxlcywNCg0KICAgIGl0IGlzIHRydWUgdGhh dCBzb21lIHBlb3BsZSB3YW50ZWQgIGhhbGYtd2lkdGggYW5kIGZ1bGwtd2lkdGggdmFyaWFudHMg KGFzIHRoZXkgYXBwZWFyIGluIEVhc3QgQXNpYW4NCiBlbmNvZGluZ3MpIHRvIGJlIHRyZWF0ZWQg ZXF1aXZhbGVudGx5LiBmb3IgZXhhbXBsZSwgaW4gQ2hpbmEsIGZldyBlbWFpbCB1c2VycyBrb253 IHdoYXQgaXMgaGFsZi13aWR0aCB2YXJpYW50cyBhbmQgIHdoYXQgaXMgZnVsbC13aWR0aCB2YXJp YW50czsgZXZlbiBtYW55IHVuaXZlcnNpdHkgc3R1ZGVudHMgd2hvc2UgbWFqb3IgaXMgY29tcHV0 ZXIgc2NpZW5jZSBkb24ndCBrb253LCBhcyBmYXIgYXMgSSBrbm93LiBzbyBpdCBpcyBhbG1vc3Qg aW1wb3NzaWJsZSB0byByZWNvZ25pemUgd2hhdCBpcyBoYWxmLXdpZHRoIHZhcmlhbnRzIGFuZCAg d2hhdCBpcyBmdWxsLXdpZHRoIHZhcmlhbnRzIGZvciBzb21lIHVzZXJzLg0KU28gYXMgYW4gQWlz YW4sIEkgcHJlZmVyIHRoYXQgaGFsZi13aWR0aCBhbmQgZnVsbC13aWR0aCB2YXJpYW50cyB0byBi ZSB0cmVhdGVkIGVxdWl2YWxlbnRseSwgdGhlIHNhbWUgd2F5IHVwcGVyY2FzZSBhbmQgbG93ZXJj YXNlIGFyZSB0cmVhdGVkIGFzIGVxdWl2YWxlbnRzIGluIHRoZSBETlMuDQoNCg0KWWFvIEppYW5r YW5nDQpDTk5JQw0KDQoNCg== --===============0520452847== 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 --===============0520452847==-- From ima-bounces@ietf.org Tue Apr 11 03:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDKx-0007Ww-Jp; Tue, 11 Apr 2006 03:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDKq-0007Tz-W1 for ima@ietf.org; Tue, 11 Apr 2006 03:30:48 -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 1FTDKl-0004ao-Mr for ima@ietf.org; Tue, 11 Apr 2006 03:30:48 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FTDKj-000Fys-Qm; Tue, 11 Apr 2006 03:30:42 -0400 Date: Tue, 11 Apr 2006 03:30:40 -0400 From: John C Klensin To: YAO Jiankang , ima@ietf.org, "Marcos Sanz/Denic" Subject: Re: [EAI] Comments on SMTP extension Message-ID: In-Reply-To: <344720298.17847@cnnic.cn>, <00c001c65d0a$b817a010$1206e29f@cnnicyaojk> References: <344421947.03293@cnnic.cn> <344720298.17847@cnnic.cn>, <00c001c65d0a$b817a010$1206e29f@cnnicyaojk> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd 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 Yao, You will note below that there are several cases below in which I have either disagreed with Marcos or agreed about the problem but disagreed about the proposed fix. My beliefs are not inherently more valid than his: my only possible claim to authority is that I've been thinking about some of these issues for longer than either of you, and that is not a very strong claim. But, where there is controversy, you, Yao, need to go to the WG list with specific questions and then make changes in response to whatever consensus emerges, not to simply change things based on the remarks of the last person who sent you comments. If you can't get resolution and consensus before you are ready to produce -03, it is perfectly reasonable to insert notes in the draft that indicate the section or paragraph is still under discussion and what the issues are. Then it becomes Harald's problem to try to pose questions and get consensus. Much more below. --On Tuesday, 11 April, 2006 09:53 +0800 YAO Jiankang wrote: > > ----- Original Message ----- > From: "Marcos Sanz/Denic" > To: > Sent: Friday, April 07, 2006 10:59 PM > Subject: [EAI] Comments on SMTP extension >... >> * Section 1.1: RFC 1869 is obsolete, current is 2821 > > will update it according to your comments. Please be careful about context here. My recollection is that 1869 was referenced in the document you drew from in creating the SMTP extension draft because it contains a certain amount of rationale and explanation that is not present in 2821. Knowing that 2821 obsoletes 1869 for standards-reference purposes does not imply that 2821 contains all of the same text and explanations that 1869 does. Please note that I am _not_ asking you to avoid making this change, only that you do the work to figure out what the reference is pointing to and, on that basis, decide whether the change is appropriate. My guess, without rereading the two, is that it might be better to reference both documents rather than simply dropping the 1869 reference in favor of the 2821 one. >> * Section 1.2: "Domain part of the email address may be >> internationalized through IDNA". It should rather be "..has >> been internationalized..". > > in our initial version, we use "..has been > internationalized..". but when we consider that domain part of > email is different from the normal domain name, we may use > different internationalized method for domain part of email > address. so we use "Domain part of the email address may be > internationalized through IDNA". after we finalize the IMA > method, we may use this kind of sentense : "Domain part of the > email address has been internationalized through IDNA". As far as I can tell, those two sentences are identical. More important, the domain part of email is a normal domain name -- nothing I know of makes it any different. Please explain. >> * Section 1.2: "Since older SMTP servers and the mail-reading >> clients [...] may not be prepared to handle these extended >> addresses, an SMTP extension is specified". This could be >> nitpicking, but I don't think that we are protecting those >> mail-reading clients with this SMTP extension. I would cross >> them out of that sentence. > > will update it according to your comments Please do not do so without further discussion. I have explained, in an earlier note, why the existing claim may be appropriate. >... >> * Section 2.2: s/either punycode/either ACE/ > > will update it according to your comments. While I agree on avoiding specific references to punycode, rather than IDNA processing, where feasible (see above), it is not clear to me that there is any advantage to substituting the generic "ACE" for the specific "punycode" and I can see some arguments for not doing so, e.g., appearing to permit local variations on the encoding used. Marcos, could you explain better why you think this change would be an advantage? >> * Section 2.2: "the original SMTP client SHOULD first verify >> that the string is valid for a domain name according to IDNA >> rules". Why and for which fields? And what if that fails? >> Reaction should probably depend on the exact field of >> failure appearance. That must be defined. > > it checks the validity of email address. if the client found > that domain name is not valid, it means that the email address > is not valid. it the address is not valid, it will refuse to > send the email message. First, I don't think you are responding to Marcos's comment. The response would be, I think, to specify that this test is being applied to the domain-part, not the entire email address. Second, there is the appearance of an extra step here, and it is not clear to me that step is necessary. The proper procedure is to apply IDNA (ToASCII() or ToASCII(ToUnicode()) ) as appropriate and then look the thing up in the DNS. If it isn't found, it isn't found and that is the end of processing since without a valid domain, you can't open an SMTP connection. >... >> * Section 2.3: "Change the definition of 'Atom' to permit >> either the definition above or a UTF-8 string". This >> complete liberalization of the local part makes me feel very >> uneasy, not all characters are appropriate to become part of >> an identifier (cf the Unicode Standard Annex 31, Identifier >> and Pattern Syntax). > > yes, we have noticed this problem. we will refine the > definition. Be very careful here. The IETF has not signed up for Unicode Standard Annex 31 (that would take an update to RFC 2277) and it is not clear that it should apply to either email addresses or to all of the ABNF "Atom"s that might appear in the relevant contexts. >... >> * Section 2.3: Nitpicking "sub-domain = Let-dig [Ldh-str] / >> " The >> former are a subset of the latter, thus "sub-domain = > internationalized domain label specified by IDNA>" is enough >> for that informal purpose. > > will update it according to your comments. Doesn't this imply a restriction on non-i18nAddresses? If so, is that restriction appropriate? For example "abc--def" is a valid 2821 and 2822 domain label, but is certainly not an IDNA-compliant internationalized label. >... >> * Section 2.4: "are data or instructions embedded in the >> address that the ACE process would hide". That should be >> ellaborated a bit more. > > will update it according to your comments. This should really be left as much as possible to the framework document, IMO. Send text. >... >> * Section 2.4: "the sender SMTP server can apply some >> algorithmic transformation such as punycode". "Can"? >> "Should"? "SHOULD"? "MUST"? I am for the latter in this >> point. In anycase the sentence would better be "..apply some >> ASCII compatible encoding transformation". > > before IETF65 meeting, we still not sure which algorithmic > transformation will be applied. now it seems that most of us > agree to use punycode. so we will update it according to your > comments. Huh? I seem to have not been there when punycode was agreed to. There are two difficulties. First, while Adam has made some interesting suggestions about a case-preserving version of punycode, the only punycode we have today is the one defined in RFC 3492. That one is closely tried to IDNA. It assumes NFKC and, while I don't know if any of NFKCs other mappings are important to it, the fact that it is not case-preserving --and there are non-Roman scripts that do have case distinctions-- is a disaster for email use. It seems to me that would be a showstopper for the use of punycode. Second, IDNA imposes a number of other restrictions that are inappropriate for email local-parts. It is not clear, as a result, that punycode can be used to code the entire range of local parts without modification. In any event, please just refer to the downgrade document for what is done with ATOMIC... and then make sure that, as a member of the WG, it is satisfactorily addressed there. >> * Section 2.4: "IDNA may also be applied to the domain part". >> "may"? or "MUST"? > > now we will use "MUST" See above. Just reference the downgrade document for the details of how ATOMIC is used. We really don't want this type of information in two places. Having it in two places is an invitation to getting things seriously wrong. >> * Section 2.4: I couldn't find an explanation in the >> algorithm for the case in which neither ALT-ADDRESS nor >> ATOMIC are present. I guess rejection is the correct thing, >> but then, why is ATOMIC optional at all? > > it is up to the email sender to decide whether ATOMIC is set. > some of them may prefer the bounce if IMA capability is not > supported. This should probably be covered better in the framework document as well. >> * Section 2.5: "the name should be in punycode form if its >> raw form is non-ASCII". "should" or "MUST"? Cf "may" two >> bullets ago. In any case, and since ToASCII(ascii)=ascii, >> the sentence should read "...always in ASCII encoded form". > > will update it according to your comments. No. The sentence is an explanation of how the rules are to developed, not a normative statement. Note that it starts "In general, the rule is that,..." and the "should" is intentionally in lower case. The next paragraph starts out "the following subsections list and discuss all of the relevant cases". It is in those subsections that the normative statements occur and they must be very clear about what is expected. >> * Section 2.5: "8BITMIME should be advertised". If 8BITMIME >> is a requirement for IMA, as I think it is, then it should >> be "8BITMIME must be advertised". > will update it according to your comments. Actually, it should be "8BITMIME MUST be advertised" >> * Section 2.5.1: s/punycode form/ACE form/ > > will update it according to your comments. See above about the difference between the generic "ACE" and the specific "punycode". Please do not change this unless you have a satisfactory explanation, which you are prepared to explain to the rest of the WG, as to why the generic (and less specific) form would be better. The "must" in the last two lines of that paragraph should be "MUST". >... >> * Section 2.5.4: It is moot since the inclusion of the >> "i18n-mail" header > > ok, I will remove it. Please mark it as requiring ongoing review and keep it for the time being. I think we need to move significantly further with analysis of the role of that header to know whether this discussion can be completely removed. On the other hand, even if it is retained, it probably should be placed in the framework document, not here. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 06:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTFl8-0001Rd-Eu; Tue, 11 Apr 2006 06:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTFl7-0001RY-6y for ima@ietf.org; Tue, 11 Apr 2006 06:06:05 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTFl4-0002I1-TY for ima@ietf.org; Tue, 11 Apr 2006 06:06:05 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTFl4-0003ff-52; Tue, 11 Apr 2006 12:06:02 +0200 In-Reply-To: To: "ima@ietf.org" Subject: Re: [EAI] Comments on IMA framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Tue, 11 Apr 2006 12:06:00 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 11.04.2006 12:06:02, Serialize complete at 11.04.2006 12:06:02 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.5 (/) 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 > > Admittedly, maybe the point was not clear. In my comments to the > > Headers-document, I have tried to defend the position that the update to > > the internet mail format should be in terms of a syntax extension to > > support new *Unicode* characters, and not *UTF-8* characters. Ideally, > > the > > word "UTF-8" would not have a single appearance in the Headers-document, > > because it is just a matter of transport. I mean, I could store my mails > > in UTF-16, as long as I use UTF-8 to communicate with an SMTP server. > > Yes, but the tradition within the IETF is always to define the format of > objects as they will appear "on the wire". I.e., if I am going to send you > (by some transport mechanism) a document conforming to our standard (and > if we have no prior arrangement otherwise), then it had better have its > headers in UTF-8 and not in UTF-16. If you choose to convert it for > storage, and display, then that is up to you. Absolutely. My point is that the definition "on the wire" should appear in the STMP extensions document, and not in the header extensions document. The header extensions document should be format-neutral, so that if in the future e.g. we introduce a "SMTP extensions #2" with transport via UTF-16, the Internet Mail Format must not be updated again. Regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 06:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGUB-0000mC-1H; Tue, 11 Apr 2006 06:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGUA-0000m7-9X for ima@ietf.org; Tue, 11 Apr 2006 06:52:38 -0400 Received: from biosoft.kaist.ac.kr ([143.248.30.166] helo=biosoft.kasit.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTGU8-00040W-BM for ima@ietf.org; Tue, 11 Apr 2006 06:52:38 -0400 Received: from [143.248.30.178] (balrog.kaist.ac.kr [143.248.30.178]) by biosoft.kasit.ac.kr (8.13.4/8.13.4) with ESMTP id k3BAqOxM011522; Tue, 11 Apr 2006 19:52:25 +0900 Message-ID: <443B8A66.20104@i18nl10n.com> Date: Tue, 11 Apr 2006 19:52:22 +0900 From: Jungshik Shin User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Marcos Sanz/Denic Subject: Re: [EAI] Comments on IMA framework References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Marcos Sanz/Denic wrote: >>> Admittedly, maybe the point was not clear. In my comments to the >> if we have no prior arrangement otherwise), then it had better have its >> headers in UTF-8 and not in UTF-16. If you choose to convert it for >> storage, and display, then that is up to you. > > Absolutely. My point is that the definition "on the wire" should appear in > the STMP extensions document, and not in the header extensions document. > The header extensions document should be format-neutral, so that if in the > future e.g. we introduce a "SMTP extensions #2" with transport via UTF-16, > the Internet Mail Format must not be updated again. I bet such an extension will never be introduced given that RFC (2)822 is not "format-neutral". either. My understanding is that the Internet Mail Format on the wire 'must be' upward compatible with ASCII, which UTF-16/32 is not. Jungshik _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 07:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTH5e-0005QE-NY; Tue, 11 Apr 2006 07:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTH5c-0005Q9-St for ima@ietf.org; Tue, 11 Apr 2006 07:31:20 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTH5Z-0005ZU-Ji for ima@ietf.org; Tue, 11 Apr 2006 07:31:20 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTH5Y-0005On-9S; Tue, 11 Apr 2006 13:31:16 +0200 In-Reply-To: <443B8A66.20104@i18nl10n.com> To: "ima@ietf.org" Subject: Format neutrality (was Re: [EAI] Comments on IMA framework) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Tue, 11 Apr 2006 13:31:13 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 11.04.2006 13:31:16, Serialize complete at 11.04.2006 13:31:16 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > > Absolutely. My point is that the definition "on the wire" should appear in > > the STMP extensions document, and not in the header extensions document. > > The header extensions document should be format-neutral, so that if in the > > future e.g. we introduce a "SMTP extensions #2" with transport via UTF-16, > > the Internet Mail Format must not be updated again. > > I bet such an extension will never be introduced given that RFC (2)822 > is not "format-neutral". either. My understanding is that the Internet > Mail Format on the wire 'must be' upward compatible with ASCII, which > UTF-16/32 is not. Even if that were true, the new header extensions document should be format-on-the-wire neutral. SoC: Separation of Concerns. Regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 08:45:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIFT-0008TL-KT; Tue, 11 Apr 2006 08:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIFS-0008TG-8C for ima@ietf.org; Tue, 11 Apr 2006 08:45:34 -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 1FTIFR-0008MR-Pb for ima@ietf.org; Tue, 11 Apr 2006 08:45:34 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FTIFR-000GLv-1z; Tue, 11 Apr 2006 08:45:33 -0400 Date: Tue, 11 Apr 2006 08:45:32 -0400 From: John C Klensin To: "Marcos Sanz/Denic" , ima@ietf.org Subject: Re: [EAI] Comments on IMA framework Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Tuesday, 11 April, 2006 12:06 +0200 "Marcos Sanz/Denic" wrote: >... >> > the >> > word "UTF-8" would not have a single appearance in the > Headers-document, >> > because it is just a matter of transport. I mean, I could >> > store my > mails >> > in UTF-16, as long as I use UTF-8 to communicate with an >> > SMTP server. >> >> Yes, but the tradition within the IETF is always to define >> the format of > >> objects as they will appear "on the wire". I.e., if I am >> going to send > you >> (by some transport mechanism) a document conforming to our >> standard (and > >> if we have no prior arrangement otherwise), then it had >> better have its headers in UTF-8 and not in UTF-16. If you >> choose to convert it for storage, and display, then that is >> up to you. > > Absolutely. My point is that the definition "on the wire" > should appear in the STMP extensions document, and not in the > header extensions document. The header extensions document > should be format-neutral, so that if in the future e.g. we > introduce a "SMTP extensions #2" with transport via UTF-16, > the Internet Mail Format must not be updated again. If we had a cleaner header-envelope distinction, that might work. But the reality is that the transport needs to know the encoding of the message body. There are several important reasons for this, but three stand out: (1) The MTA must insert trace fields into the top of the message body (i.e., the headers). Those trace fields are differentiated from other headers only by their names, so various things need to be able to understand those names. (2) The end of message indicator must be understood by MTAs in order to figure out when to close out a message and start reading commands again. That indicator is strictly defined, in the transport spec, as _ASCII_ CRLF.CRLF. UTF-8 works because of the forward compatibility with ASCII; arbitrary codings do not. (3) At an implementation level, rather than a theoretical-specification one, we are heavily dependent on those ASCII CRLF sequences to denote logical line termination, something that impacts the way transport is defined, as well as the way at least one POP3 command and several extensions have been defined. For whatever it is worth, the possibility of multiple header encodings, especially header encodings that change the definition of CR and LF and the spelling of header field names in transport, make the work of designing a gateway to a different mail environment vastly more difficult as well. More generally, to state more badly what others have stated well, much of our experience with Internet protocols is that they are successful to the extent to which we can keep the complexity that arises from multiple options to a minimum. Unless you can show extremely strong benefit for permitting different message header encodings in transport -- not merely the hypothetical possibility of some future change -- I think this is better specified as UTF-8 as it is now. If someone later develops a reason for a different encoding, issuing a new or updated header specification will be the least of their worries, since all of the boundary and transition issues will need to be sorted out and documented. Similar reasoning argues for specifying the most specific ACE possible, not the generic term. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 11:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKNL-0001Sc-MQ; Tue, 11 Apr 2006 11:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKNK-0001SX-Pt for ima@ietf.org; Tue, 11 Apr 2006 11:01:50 -0400 Received: from sov-mail-b0013.gradwell.net ([193.84.87.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKNJ-00050h-68 for ima@ietf.org; Tue, 11 Apr 2006 11:01:50 -0400 Received: from host81-144-64-16.midband.mdip.bt.net ([81.144.64.16]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 443bc4b2.3afc.2079 for ima@ietf.org; Tue, 11 Apr 2006 16:01:06 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3BDdo429245 for ; Tue, 11 Apr 2006 14:39:51 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] Comments on IMA framework References: Message-ID: Date: Tue, 11 Apr 2006 14:39: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: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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 Tue, 11 Apr 2006 11:06:00 +0100, Marcos Sanz/Denic wrote: >> if we have no prior arrangement otherwise), then it had better have its >> headers in UTF-8 and not in UTF-16. If you choose to convert it for >> storage, and display, then that is up to you. > > Absolutely. My point is that the definition "on the wire" should appear > in > the STMP extensions document, and not in the header extensions document. > The header extensions document should be format-neutral, so that if in > the > future e.g. we introduce a "SMTP extensions #2" with transport via > UTF-16, > the Internet Mail Format must not be updated again. No, the header extensions document is in fact an extension to RFC 2822, and RFC 2822 in fact defines a format to be used "on the wire" (as that term is usually understoof by the IETF). The actual wording un 2822 is: This standard specifies a syntax for text messages that are sent between computer users, .. and unless those users have some private agreement, the "wire" between them must carry whatever 2822 says. RFC 2821 (and our proposed extensions to it) is just one of many protocols that might be used between those "computer users"; RFC 2822 (and our extensions) are meant to aply to them all. Essentially we are saying that the only standard form for *any* interchange of messages MUST use UTF-8 in the headers (unless the parties have privately agreed to use something else). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 12:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLNZ-0005Lo-77; Tue, 11 Apr 2006 12:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLNY-0005Iu-Jc for ima@ietf.org; Tue, 11 Apr 2006 12:06:08 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLNY-0007ma-AO for ima@ietf.org; Tue, 11 Apr 2006 12:06:08 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTLNX-00076U-I2; Tue, 11 Apr 2006 18:06:07 +0200 In-Reply-To: To: John C Klensin Subject: Re: [EAI] Comments on IMA framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Tue, 11 Apr 2006 18:06:06 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 11.04.2006 18:06:07, Serialize complete at 11.04.2006 18:06:07 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John, > > Absolutely. My point is that the definition "on the wire" > > should appear in the STMP extensions document, and not in the > > header extensions document. The header extensions document > > should be format-neutral, so that if in the future e.g. we > > introduce a "SMTP extensions #2" with transport via UTF-16, > > the Internet Mail Format must not be updated again. > > If we had a cleaner header-envelope distinction, that might > work. But the reality is that the transport needs to know the > encoding of the message body. I am not so naive that I am claiming "the transport does not need to know about the content". Situations have already been mentioned in the list, as you just did, where this is not the case. This is not what I am discussing about. Our particular specification of the transport, the one with the extension identifier "IEmail", defines the content is UTF-8 encoded, and can act accordingly when inserting new fields, parsing them, rendering them, whatever... But to my eyes, the definition of the content, must be transport-independent, so that the same content can be delivered via diferent transport-dependent formats. SoC: Separation of Concerns. > More generally, to state more badly what others have stated > well, much of our experience with Internet protocols is that > they are successful to the extent to which we can keep the > complexity that arises from multiple options to a minimum. To keep complexity to a minimum, issue modular definitions and specifications, following rules of high internal coherence and low external coupling. > Unless you can show extremely strong benefit for permitting > different message header encodings in transport -- not merely > the hypothetical possibility of some future change -- I think > this is better specified as UTF-8 as it is now. Again, the specification as UTF-8 should remain, but in the transport document. Again, I am not trying to prove the necessity of a new message header encoding in transport. It's about SoC. Are you all for monolithic specifications? Then we should quit dealing with six different working group drafts and put it all together in one doc. And the lower the number of different sections in that doc, the better. Regards, MArcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 12:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLTq-0008HZ-D0; Tue, 11 Apr 2006 12:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLTo-0008HR-W4 for ima@ietf.org; Tue, 11 Apr 2006 12:12:36 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLTo-0007xh-Nm for ima@ietf.org; Tue, 11 Apr 2006 12:12:36 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTLTo-0000Bp-54; Tue, 11 Apr 2006 18:12:36 +0200 In-Reply-To: To: "Charles Lindsey" Subject: Re: [EAI] Comments on IMA framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Tue, 11 Apr 2006 18:12:34 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 11.04.2006 18:12:36, Serialize complete at 11.04.2006 18:12:36 Content-Type: text/plain; charset="US-ASCII" 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 > No, the header extensions document is in fact an extension to RFC 2822, > and RFC 2822 in fact defines a format to be used "on the wire" (as that > term is usually understoof by the IETF). The actual wording un 2822 is: > > This standard specifies a syntax for text messages that are sent > between computer users, .. > > and unless those users have some private agreement, the "wire" between > them must carry whatever 2822 says. Likewise from 2822 In addition, this standard does not specify an encoding of the characters for either transport or storage; that is, it does not specify the number of bits used or how those bits are specifically transferred over the wire or stored on disk. Regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 12:40:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLuc-00038G-MI; Tue, 11 Apr 2006 12:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLub-00038B-6f for ima@ietf.org; Tue, 11 Apr 2006 12:40:17 -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 1FTLua-0000c8-Mf for ima@ietf.org; Tue, 11 Apr 2006 12:40:17 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FTLua-000GdG-4w; Tue, 11 Apr 2006 12:40:16 -0400 Date: Tue, 11 Apr 2006 12:40:15 -0400 From: John C Klensin To: "Marcos Sanz/Denic" Subject: Re: [EAI] Comments on IMA framework Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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, 11 April, 2006 18:06 +0200 "Marcos Sanz/Denic" wrote: > John, > >> > Absolutely. My point is that the definition "on the wire" >> > should appear in the STMP extensions document, and not in >> > the header extensions document. The header extensions >> > document should be format-neutral, so that if in the >> > future e.g. we introduce a "SMTP extensions #2" with >> > transport via UTF-16, the Internet Mail Format must not be >> > updated again. >> >> If we had a cleaner header-envelope distinction, that might >> work. But the reality is that the transport needs to know the >> encoding of the message body. > > I am not so naive that I am claiming "the transport does not > need to know about the content". Situations have already been > mentioned in the list, as you just did, where this is not the > case. This is not what I am discussing about. > > Our particular specification of the transport, the one with > the extension identifier "IEmail", defines the content is > UTF-8 encoded, and can act accordingly when inserting new > fields, parsing them, rendering them, whatever... > > But to my eyes, the definition of the content, must be > transport-independent, so that the same content can be > delivered via diferent transport-dependent formats. SoC: > Separation of Concerns. > >> More generally, to state more badly what others have stated >> well, much of our experience with Internet protocols is that >> they are successful to the extent to which we can keep the >> complexity that arises from multiple options to a minimum. > > To keep complexity to a minimum, issue modular definitions and > specifications, following rules of high internal coherence and > low external coupling. > >> Unless you can show extremely strong benefit for permitting >> different message header encodings in transport -- not >> merely the hypothetical possibility of some future change -- >> I think this is better specified as UTF-8 as it is now. > > Again, the specification as UTF-8 should remain, but in the > transport document. > Again, I am not trying to prove the necessity of a new message > header encoding in transport. > > It's about SoC. Are you all for monolithic specifications? > Then we should quit dealing with six different working group > drafts and put it all together in one doc. And the lower the > number of different sections in that doc, the better. Marcos, you can quote "SoC" as a principle as often as you like. The IETF experience has been that, in practice, having these things be exactly specified where people are likely to look (or explicitly and normatively cross-referenced in those places) saves a large number of problems. That doesn't mean "monolithic specifications" -- there are reasons for separating many of these, just as there are reasons for separating MIME into multiple parts and, indeed, separating [2]821 from [2]822, etc. FWIW, these specifications were not separated due to grand theories about modularization. They were separated for two completely pragmatic reasons: (i) With the specifications separated, the editorial burden can be spread among several people, rather than being concentrated and hence larger. (ii) Our educated guess --but it is no more than a guess-- is that some of the specifications may be easier to finish than others and more stable thereafter. For example, if we can move the explanations, overview, and theory into the framework document and everything else out of it, it probably will not need to change even as the other documents evolve. At the other extreme, the downgrade document and the as-yet-unstarted operational advice one are likely to evolve considerably, and require revision as a result, as experience accumulates. If the document mix is wrong, the WG can, of course, change it. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 11 21:48:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTUSq-0006Wv-CH; Tue, 11 Apr 2006 21:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTUSo-0006Wm-RQ for ima@ietf.org; Tue, 11 Apr 2006 21:48:10 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTUSn-0007RS-EO for ima@ietf.org; Tue, 11 Apr 2006 21:48:10 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3C1m83d000889 for ; Tue, 11 Apr 2006 19:48:08 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXL0080153BF500@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 11 Apr 2006 19:48:08 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXL00A7P6C6HW10@mail-amer.sun.com>; Tue, 11 Apr 2006 19:48:08 -0600 (MDT) Date: Tue, 11 Apr 2006 18:50:44 -0700 From: Chris Newman Subject: Re: [EAI] Comments on IMA framework In-reply-to: To: Marcos Sanz/Denic , 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Marcos Sanz/Denic wrote on 4/11/06 12:06 +0200: > Absolutely. My point is that the definition "on the wire" should appear in > the STMP extensions document, and not in the header extensions document. > The header extensions document should be format-neutral, so that if in the > future e.g. we introduce a "SMTP extensions #2" with transport via UTF-16, > the Internet Mail Format must not be updated again. I strongly disagree. Standards exist to promote interoperability and fewer options increases the chances of interoperability. The fact is that the multiple variants of UTF-16 are less likely to interoperate in practice than the two different variants of TIFF (which have demonstrated interop problems). If we're doing our job right, we should specify UTF-8 and only UTF-8 as the wire format. The principle of reducing options to improve interoperability completely trumps your "Separation of Concerns" principle in this case. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 12 04:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaVp-0003ZE-40; Wed, 12 Apr 2006 04:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaVo-0003Z9-Ad for ima@ietf.org; Wed, 12 Apr 2006 04:15:40 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTaVn-0003w5-1Q for ima@ietf.org; Wed, 12 Apr 2006 04:15:40 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTaVm-0002ne-BN; Wed, 12 Apr 2006 10:15:38 +0200 In-Reply-To: To: ima@ietf.org Subject: Re: [EAI] Comments on IMA framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Wed, 12 Apr 2006 10:15:37 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 12.04.2006 10:15:38, Serialize complete at 12.04.2006 10:15:38 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear all, My position is for keeping the on-the-wire format in the SMTP extensions document and keeping the pure mail syntax definition in the header extensions document. Arguments against this have been so far: * "But the transport must know about the encoding of the content anyway". This is somehow a bogus reasoning: the transport definition will bound the content to the particular on-the-wire format, and thus implicitly know the encoding of the material being transported. * "RFC 2822 makes an on-the-wire definition already, and thus can we". Actually not true, RFC 2822 explicitly does not make any storage or on-the-wire encoding definition. * John's "having these things be exactly specified where people are likely to look". A very weak non-technical argument. Documents can be cross-referenced and readers will be expected to follow the links. * Chris' interoperability argument "we should specify UTF-8 and only UTF-8 as the wire format". I don't necessarily disagree, but you can achieve that by cross-requiring the documents. I am somehow surprised that I am the only proponent of this conceptual separation and that, apparently, all participants are actively or passively (consenting silence) against it. Next time I will take the blue pill :-) Best regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 12 10:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTg1A-0006Z6-Kh; Wed, 12 Apr 2006 10:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTg19-0006Yy-BX for ima@ietf.org; Wed, 12 Apr 2006 10:08:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTf51-0004vp-Jh for ima@ietf.org; Wed, 12 Apr 2006 09:08:19 -0400 Received: from smtp.denic.de ([81.91.161.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTeuU-0002Xf-7A for ima@ietf.org; Wed, 12 Apr 2006 08:57:27 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTeuS-0003rE-Pc; Wed, 12 Apr 2006 14:57:24 +0200 In-Reply-To: To: John C Klensin Subject: Re: [EAI] Comments on SMTP extension MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Wed, 12 Apr 2006 14:57:22 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 12.04.2006 14:57:24, Serialize complete at 12.04.2006 14:57:24 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -2.6 (--) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John, > >> * Section 1.1: RFC 1869 is obsolete, current is 2821 > > > > will update it according to your comments. > > Please be careful about context here. My recollection is that > 1869 was referenced in the document you drew from in creating > the SMTP extension draft because it contains a certain amount of > rationale and explanation that is not present in 2821. It is certainly true that the fact that 2821 obsoletes 1869 for standards-reference purposes does not mean that the text of 1869 is a subset of the text of 2821. But Yao's and Lee's document goes: "This document specifies an element of that work, specifically the definition of an SMTP extension [RFC1869] for IMA transport delivery" This looks for me like a pretty banal (no pun intended) reference in the introductory part of the document, without any deeper meaning based on a certain rationale present in 1869 and not present in 2821. If it were the case that this specific, relevant rationale in 1869 exists, it would be helpful to make a more concrete reference (section X, paragraph Y of 1869) to be able to understand it in the context. Otherwise -and I don't want to give this more importance than it deserves- it would be better to reference the current specification that defines SMTP extensions, that is 2821. > >> * Section 1.2: "Domain part of the email address may be > >> internationalized through IDNA". It should rather be "..has > >> been internationalized..". > > > > in our initial version, we use "..has been > > internationalized..". but when we consider that domain part of > > email is different from the normal domain name, we may use > > different internationalized method for domain part of email > > address. so we use "Domain part of the email address may be > > internationalized through IDNA". after we finalize the IMA > > method, we may use this kind of sentense : "Domain part of the > > email address has been internationalized through IDNA". > > As far as I can tell, those two sentences are identical. More > important, the domain part of email is a normal domain name -- > nothing I know of makes it any different. Please explain. Certainly, I cannot follow Yao's comment here either. > >> * Section 1.2: "Since older SMTP servers and the mail-reading > >> clients [...] may not be prepared to handle these extended > >> addresses, an SMTP extension is specified". This could be > >> nitpicking, but I don't think that we are protecting those > >> mail-reading clients with this SMTP extension. I would cross > >> them out of that sentence. > > > > will update it according to your comments > > Please do not do so without further discussion. I have > explained, in an earlier note, why the existing claim may be > appropriate. Would you mind sending a pointer to that earlier note? > >> * Section 2.2: s/either punycode/either ACE/ > > > > will update it according to your comments. > > While I agree on avoiding specific references to punycode, > rather than IDNA processing, where feasible (see above), it is > not clear to me that there is any advantage to substituting the > generic "ACE" for the specific "punycode" and I can see some > arguments for not doing so, e.g., appearing to permit local > variations on the encoding used. Marcos, could you explain > better why you think this change would be an advantage? Sure: I hate to say this, but it's about separation of concerns. The exact method of ASCII compatible encoding should be described somewhere else (downgrading-draft? separate draft?), and for the efects of the SMTP extension specification, the concrete method (here punycode) is irrelevant. I am not claiming we should or shouldn't use punycode (that should be a different thread), I am only claiming it's not relevant at this exact place. > >> * Section 2.2: "the original SMTP client SHOULD first verify > >> that the string is valid for a domain name according to IDNA > >> rules". Why and for which fields? And what if that fails? > >> Reaction should probably depend on the exact field of > >> failure appearance. That must be defined. > > > > it checks the validity of email address. if the client found > > that domain name is not valid, it means that the email address > > is not valid. it the address is not valid, it will refuse to > > send the email message. > > First, I don't think you are responding to Marcos's comment. > The response would be, I think, to specify that this test is > being applied to the domain-part, not the entire email address. Agreed. > Second, there is the appearance of an extra step here, and it is > not clear to me that step is necessary. The proper procedure > is to apply IDNA (ToASCII() or ToASCII(ToUnicode()) ) as > appropriate and then look the thing up in the DNS. If it isn't > found, it isn't found and that is the end of processing since > without a valid domain, you can't open an SMTP connection. This dovetails with my sentence "reaction should probably depend on the exact field of appearance". If the normal transport processing does not require making a DNS lookup on the, e.g. MAIL FROM mailbox domain part, then we don't *need* to artificially introduce a new DNS lookup or a new test "ToASCII(mailbox) doesn't fail" (ToUnicode() is defined to never fail, so it's not necessary here). OTOH, the most inmediate way of checking the valid syntax of that domain part is applying ToASCII()... > >> * Section 2.3: "Change the definition of 'Atom' to permit > >> either the definition above or a UTF-8 string". This > >> complete liberalization of the local part makes me feel very > >> uneasy, not all characters are appropriate to become part of > >> an identifier (cf the Unicode Standard Annex 31, Identifier > >> and Pattern Syntax). > > > > yes, we have noticed this problem. we will refine the > > definition. > > Be very careful here. The IETF has not signed up for Unicode > Standard Annex 31 I haven't claimed that we've signed up. I am only pointing out that: a) As of now we have a complete liberal definition of the local part b) Not all characters are appropriate to be in an identifier or in a certain position within an identifier c) We are using Unicode d) There is a part of the Unicode standard that deals with that issue If Yao claims that they are refining the definition, I'd like to know on the basis of what. > >> * Section 2.3: Nitpicking "sub-domain = Let-dig [Ldh-str] / > >> " The > >> former are a subset of the latter, thus "sub-domain = >> internationalized domain label specified by IDNA>" is enough > >> for that informal purpose. > > Doesn't this imply a restriction on non-i18nAddresses? If so, > is that restriction appropriate? For example "abc--def" is a > valid 2821 and 2822 domain label, but is certainly not an > IDNA-compliant internationalized label. It's not a restriciton. You are addressing domain names with a hyphen in third and fourth position (e.g. "ab--cdef"), is that right? Those ASCII domain labels are still valid after the advent of IDNA and are valid *internationalized* domain labels. ToASCII("ab--cdef") = "ab--cdef" and ToUnicode("ab--cdef") = "ab--cdef". ASCII domain labels are (part of) valid IDNs. I agree that "" is not a formal definition anyway, but the ABNF in the current form is redundant at best, misleading at worst. > >> * Section 2.4: "are data or instructions embedded in the > >> address that the ACE process would hide". That should be > >> ellaborated a bit more. > > > > will update it according to your comments. > > This should really be left as much as possible to the framework > document, IMO. Send text. I cannot send text because I don't have enough background on the problem. It has been addressed in the list before, but all I could read where vague references like "netnews experience", "bang-paths", "%-hacks", "imbedded commands, subaddresses, and so on". I think it could be helpful for the reader to document the problem, or alternatively, include a reference to a place where the problem has been documented. To place that explanation/reference in the framework document is fine by me. > >> * Section 2.4: "the sender SMTP server can apply some > >> algorithmic transformation such as punycode". "Can"? > >> "Should"? "SHOULD"? "MUST"? I am for the latter in this > >> point. In anycase the sentence would better be "..apply some > >> ASCII compatible encoding transformation". > > > > before IETF65 meeting, we still not sure which algorithmic > > transformation will be applied. now it seems that most of us > > agree to use punycode. so we will update it according to your > > comments. > > Huh? I seem to have not been there when punycode was agreed to. Neither me. > There are two difficulties. First, while Adam has made some > interesting suggestions about a case-preserving version of > punycode, the only punycode we have today is the one defined in > RFC 3492. That one is closely tried to IDNA. It assumes NFKC Punycode is not NFKC/Nameprep dependent and does not assume it. > and, while I don't know if any of NFKCs other mappings are > important to it, the fact that it is not case-preserving Punycode does preserve case. > In any event, please just refer to the downgrade document for > what is done with ATOMIC... Correct. It is exactly my suggestion that the concrete ACE encoding is not relevant in the SMTP document and must be addressed separately. > >> * Section 2.4: "IDNA may also be applied to the domain part". > >> "may"? or "MUST"? > > > > now we will use "MUST" > > See above. Just reference the downgrade document for the > details of how ATOMIC is used. We really don't want this type > of information in two places. Having it in two places is an > invitation to getting things seriously wrong. I thought you always have to write all things in all possible places where the reader could expect to find them :-) *scnr* > >> * Section 2.4: I couldn't find an explanation in the > >> algorithm for the case in which neither ALT-ADDRESS nor > >> ATOMIC are present. I guess rejection is the correct thing, > >> but then, why is ATOMIC optional at all? > > > > it is up to the email sender to decide whether ATOMIC is set. > > some of them may prefer the bounce if IMA capability is not > > supported. > > This should probably be covered better in the framework document > as well. Disagree. The SMTP algorithm must be completely defined in the SMTP extension document and cover the case there in which neither ALT-ADDRESS nor ATOMIC are present. > >> * Section 2.5: "the name should be in punycode form if its > >> raw form is non-ASCII". "should" or "MUST"? Cf "may" two > >> bullets ago. In any case, and since ToASCII(ascii)=ascii, > >> the sentence should read "...always in ASCII encoded form". > > > > will update it according to your comments. > > No. The sentence is an explanation of how the rules are to > developed, not a normative statement. Note that it starts "In > general, the rule is that,..." and the "should" is intentionally > in lower case. The next paragraph starts out "the following > subsections list and discuss all of the relevant cases". It is > in those subsections that the normative statements occur and > they must be very clear about what is expected. It's not about 2119 language here, but about internal coherence. The sentence at stake is: "the name should be in punycode form if its raw form is non-ASCII" In its current form.. a) ..it collides with the sentence "IDNA may also be applied to the domain part" in the Section 2.4. "may" or "should"? I am not defending either option now (though I like "must" best), I am only pointing out an incoherence. b) ..it mentions punycode, which is wrong, since punycode is only a part of IDNA, which does not include Nameprep and does not include ACE prefix prepending. c) ..it includes a misleading condition ("if its raw form is non-ASCII..."), since ToASCII("ASCii")="ASCii" Again, my suggestion for the reformulation is: "the name should/may/must be ACE encoded as of IDNA [RFC3490]" > >> * Section 2.5: "8BITMIME should be advertised". If 8BITMIME > >> is a requirement for IMA, as I think it is, then it should > >> be "8BITMIME must be advertised". > > > will update it according to your comments. > > Actually, it should be "8BITMIME MUST be advertised" Agreed. > >> * Section 2.5.1: s/punycode form/ACE form/ > > > > will update it according to your comments. > > See above about the difference between the generic "ACE" and the > specific "punycode". Please do not change this unless you have > a satisfactory explanation, I have (hopefully) given that, see above. But for me, it looks like you are contradicting yourself. > >> * Section 2.5.4: It is moot since the inclusion of the > >> "i18n-mail" header > > > > ok, I will remove it. > > Please mark it as requiring ongoing review and keep it for the > time being. That is fine by me, too. I just wanted to have the documents in sync. Regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 12 13:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjaL-0005QI-Ns; Wed, 12 Apr 2006 13:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjaL-0005Nd-0e for ima@ietf.org; Wed, 12 Apr 2006 13:56:57 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTjaK-0006uN-Hg for ima@ietf.org; Wed, 12 Apr 2006 13:56:56 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6800259766; Wed, 12 Apr 2006 19:56:38 +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 19151-10; Wed, 12 Apr 2006 19:56:34 +0200 (CEST) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id A54E8259761; Wed, 12 Apr 2006 19:56:34 +0200 (CEST) Message-ID: <443D3F63.6070806@alvestrand.no> Date: Wed, 12 Apr 2006 19:56:51 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marcos Sanz/Denic Subject: Re: [EAI] Comments on IMA framework References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Marcos, I think you are seeing the result of lots of bad history..... in multiple cases there have been standards people have had to fight with where some aspect was not specified (X.500 GeneralText, BMPstring and other bizarreness; SQL error messages, the undefined transport mappings of CORBA, endian definitions in various places). The result has been that the IETF has grown an extremely strong aversion to protocols where one can assume, even by implication, that some aspect that is essential for communication is an "implementation choice", or may "depend on the transport mapping". We may have become too fond of overspecifying our implementation choices. But it's served us well so far. In this case, I think we're all agreed that the set of documents describes an experiment where the only permitted transport charset for headings is UTF-8. No alternates. So the change you're looking for will not cause any effect on the wire. It MAY cause more ease of descibing incompatible experiments at a later time; I don't know if that is a Good Thing or not. More understanding? Marcos Sanz/Denic wrote: > Dear all, > > My position is for keeping the on-the-wire format in the SMTP extensions > document and keeping the pure mail syntax definition in the header > extensions document. Arguments against this have been so far: > * "But the transport must know about the encoding of the content anyway". > This is somehow a bogus reasoning: the transport definition will bound the > content to the particular on-the-wire format, and thus implicitly know the > encoding of the material being transported. > * "RFC 2822 makes an on-the-wire definition already, and thus can we". > Actually not true, RFC 2822 explicitly does not make any storage or > on-the-wire encoding definition. > * John's "having these things be exactly specified where people are likely > to look". A very weak non-technical argument. Documents can be > cross-referenced and readers will be expected to follow the links. > * Chris' interoperability argument "we should specify UTF-8 and only UTF-8 > as the wire format". I don't necessarily disagree, but you can achieve > that by cross-requiring the documents. > I am somehow surprised that I am the only proponent of this conceptual > separation and that, apparently, all participants are actively or > passively (consenting silence) against it. Next time I will take the blue > pill :-) > > Best regards, > Marcos > > _______________________________________________ > 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 13 02:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvR0-0004uR-KK; Thu, 13 Apr 2006 02:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvQz-0004uJ-KW for ima@ietf.org; Thu, 13 Apr 2006 02:36:05 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTvQy-0000Ca-BL for ima@ietf.org; Thu, 13 Apr 2006 02:36:05 -0400 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FTvQx-0004j9-Jv; Thu, 13 Apr 2006 08:36:03 +0200 In-Reply-To: <443D3F63.6070806@alvestrand.no> To: Harald Alvestrand Subject: Re: [EAI] Comments on IMA framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Marcos Sanz/Denic Message-ID: Date: Thu, 13 Apr 2006 08:36:01 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 13.04.2006 08:36:03, Serialize complete at 13.04.2006 08:36:03 Content-Type: text/plain; charset="US-ASCII" 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 Harald, > So the change you're looking for will not cause any effect on the wire. > It MAY cause more ease of descibing incompatible experiments at a later > time; I don't know if that is a Good Thing or not. > > More understanding? Thanks for your explanation. Like everybody else, I have read specifications in the past which were bizarre and incomplete, thus I have *lots* of understanding for allergic reactions against badly written docs. The change I am proposing is not aiming at leaving implementation choices or describing incompatible experiments at a later time, no. It's exactly yet another allergic reaction against badly written docs. It's about stopping spreading details all over the text at places which are not relevant or even misleading (cf the punycode-itis I mentioned in my comments to the SMTP extension), it's about putting some structure and making ease to read for those people that will have to implement it, it's about delivering good quality docs even if we are "only making an experiment". I don't have *any* understanding for excuses against that. I don't want to consume too many resources at this point, though. Apparently, not so important. Regards, Marcos _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 25 06:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYL0E-0007wc-Tf; Tue, 25 Apr 2006 06:42:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYL0D-0007wX-CT for ima@ietf.org; Tue, 25 Apr 2006 06:42:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYK0z-0005fb-B9 for ima@ietf.org; Tue, 25 Apr 2006 05:39:25 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYJbG-0006m8-9i for ima@ietf.org; Tue, 25 Apr 2006 05:12:53 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B629259713; Tue, 25 Apr 2006 11:12:23 +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 22920-10; Tue, 25 Apr 2006 11:12:17 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E90725970D; Tue, 25 Apr 2006 11:12:17 +0200 (CEST) Message-ID: <444DE80B.1020808@alvestrand.no> Date: Tue, 25 Apr 2006 11:12:43 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcos Sanz/Denic Subject: Re: [EAI] Comments on Downgrading References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -1.9 (-) 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 This seems to have generated no response.... I'll try to provoke.... Marcos Sanz/Denic wrote: >All, > >these are my comments on draft-yoneya-ima-downgrade-01. I haven't been >following the last discussions in the list. If some of these issues (or >any of those in my other mails) have already been dealt with, then just >give me a pointer. > >* Section 3.1: "SMTP client detects UTF-8 is included in SMTP envelope or >mail headers". Haven't we introduced the i18n-header to avoid making this >realtime, unreliable checks? And is it really meant "detects UTF-8" or it >is rather meant "detects 8th bit set"? > > There are just-send-8859-1 mailers out there in the wild. UTF-8 can be detected with fair reliability. >* Section 3.2: s/Recent- headers/Resent- headers/ >* Section 3.2: s/Referenece/References/ >* Section 3.3: s/receipient/recipient/g (this appears a couple of times >more) >* Section 4: "MUA of mail sender MUST append ALT-ADDR or ATOMIC". Aren't >both parameters optional? Then why MUST? >* Section 4: s/next session/next section/ >* Section 4: "local-part: Punycode without normalization". I am sure this >has been discussed before (I saw a Normalizing-thread in the list), but >fwiw here it comes my vote against non-normalized identifiers. > > the question is more what normalization, I think.... >* Section 4: The IMA-Downgraded-From and -To headers should be defined in >the Internationalized Email Headers draft, too, since that is the >equivalent of updating RFC2822. >* Section 4: s/delived/delivered/ >* Section 5.1: s/new body contains one MIME part/new body contains one new >MIME part/ >* Section 5.2: s/headers which contains/headers which contain/ >* Section 6.2: "if MDA knows MUA is IMA compliant". How should that >knowledge be conveyed? > > Is this a matter that can safely be left to local consideration? >* Section 7: I am missing a comment in the Security Considerations about >whose responsibility is that the owners of the internationalized mailboxes >match the owners of the alternative ASCII ones. > > I think the transport system should not care - there may be use cases where there's no entity apart from the end user who can tell that they have the same owner. (Think of someone running ASCII mail on yahoo! and internationalized mail on Gmail, for instance). >* Section 8: s/MUST be differ/MUST differ/ > >Best regards, >Marcos Sanz > >_______________________________________________ >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 25 07:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLUe-00086e-QZ; Tue, 25 Apr 2006 07:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLUe-00086R-95 for ima@ietf.org; Tue, 25 Apr 2006 07:14:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYK11-0005fb-HC for ima@ietf.org; Tue, 25 Apr 2006 05:39:27 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYJak-0006lc-9O for ima@ietf.org; Tue, 25 Apr 2006 05:12:19 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9AC0259713 for ; Tue, 25 Apr 2006 11:11:50 +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 23086-03 for ; Tue, 25 Apr 2006 11:11:46 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E284525970D for ; Tue, 25 Apr 2006 11:11:46 +0200 (CEST) Message-ID: <444DE7EC.8050807@alvestrand.no> Date: Tue, 25 Apr 2006 11:12:12 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -1.3 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [EAI] Open issues on the EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Here's a rough list of what I think are open issues on the EAI documents. It's based on a list that Pete Resnick recorded at the Dallas meeting (thanks, Pete!) I've attempted to add clarifications, and to add some issues from the list. Please remind me what I missed/forgot! Framework document: Issue: Paul: Mandatory to implement should be clarified Issue: Dave: Clarify that MUST bounce if the next hop doesn't support, and address can't be converted 822-headers (Yeh document): Issue: Dave/Chris: Comma in address fields as an alternative to separate parameter? Issue: Chris: Internationalized comment, especially after date, needed Issue: Paul: Canonicalization issues (PKIX/DKIM) Issue: Pete: Clean separation (or explanation) of what is message format and what is SMTP Issue: Phil: UTF-8 in MIME Content-* fields Issue: Marcos: remove "UTF-8" from this document - just say "unicode characters"? SMTP extension (Yao document): Issue: Pete: Do we allow UTF-8 in quoted-string? Downgrade document: Issue: Chris: MUST is too strong for preserving all info - "gateways lose information" Issue: Harald/Chris/Paul: Use case for upgrade needs to be added to scenarios doc, or "upgrade" should be removed from this document Issue: Pete: Split upgrade between SMTP upgrades and content upgrades Possible consensus: No upgrading of content in the transport system - may upgrade on recipient system Issue: Need for/syntax of ATOMIC (ATOMIC=NO seems an important signal to send) POP Document: Issue: Randy: TOP8 command (I believe consensus is that it should be added) Issue: Chris: Maybe just have an 8-bit switch, instead of separate commands (I believe consensus is "no") Issue: Paul: Right-to-left issues should be looked at _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Apr 25 22:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZYu-00087f-9s; Tue, 25 Apr 2006 22:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZYs-000854-PP for ima@ietf.org; Tue, 25 Apr 2006 22:15:26 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYZYr-0000gB-0v for ima@ietf.org; Tue, 25 Apr 2006 22:15:26 -0400 Received: from host81-144-64-56.midband.mdip.bt.net ([81.144.64.56]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444ed7bb.c208.2062 for ima@ietf.org; Wed, 26 Apr 2006 03:15:23 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3PGrke20762 for ; Tue, 25 Apr 2006 17:53:46 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Comments on Downgrading References: <444DE80B.1020808@alvestrand.no> Message-ID: Date: Tue, 25 Apr 2006 17:53: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: <444DE80B.1020808@alvestrand.no> 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 Tue, 25 Apr 2006 10:12:43 +0100, Harald Alvestrand wrote: > Marcos Sanz/Denic wrote: >> * Section 6.2: "if MDA knows MUA is IMA compliant". How should that >> knowledge be conveyed? >> > Is this a matter that can safely be left to local consideration? Not entirely. General purpose MTAs (Exim, Sendmail and the like) often serve communities some of whose members use POP3/IMAP/Good ol' mbox/whatever-else, and will presently be faced with the problem that some members of their communities will be IMA-compliant and some not. So such an MTA has two possibilities: 1. Decide, when it sees the RCPT header and after consulting its tables of which of its recipients can do IMA, whether or not to bounce (or downgrade) the message at that stage. 2. Accept the message anyway, with the possibility that it may have to bounce (or otherwise deal with) it later on when it tries to do its internal delivery. Our problem is that the IETF has always considered the interface between the MTA and the storage agents to be an internal matter, since no "wire" is involved, and has therefore never tried to standardize it in any way. I have a feeling that this was a mistake, and that we really need some understanding of that process before we can complete our task. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 26 09:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkCy-0001We-3C; Wed, 26 Apr 2006 09:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkCw-0001WZ-IS for ima@ietf.org; Wed, 26 Apr 2006 09:37:30 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkCv-0004oQ-VI for ima@ietf.org; Wed, 26 Apr 2006 09:37:30 -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 k3QDavR9028619; Wed, 26 Apr 2006 22:36:58 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006042622365607684 ; Wed, 26 Apr 2006 22:36:56 +0900 Date: Wed, 26 Apr 2006 22:36:56 +0900 (JST) Message-Id: <20060426.223656.26286654.fujiwara@jprs.co.jp> To: harald@alvestrand.no Subject: Re: [EAI] Comments on Downgrading From: fujiwara@jprs.co.jp In-Reply-To: <444DE80B.1020808@alvestrand.no> References: <444DE80B.1020808@alvestrand.no> X-Mailer: Mew version 5.0.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: 32b73d73e8047ed17386f9799119ce43 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 too late my response and thanks a lot for comments. I will update it according to your comments. > From: Harald Alvestrand > This seems to have generated no response.... I'll try to provoke.... > > Marcos Sanz/Denic wrote: > > >All, > > > >these are my comments on draft-yoneya-ima-downgrade-01. I haven't been > >following the last discussions in the list. If some of these issues (or > >any of those in my other mails) have already been dealt with, then just > >give me a pointer. > > > >* Section 3.1: "SMTP client detects UTF-8 is included in SMTP envelope or > >mail headers". Haven't we introduced the i18n-header to avoid making this > >realtime, unreliable checks? And is it really meant "detects UTF-8" or it > >is rather meant "detects 8th bit set"? Considering implementation costs, I want to use detecting 8th bit set instead of UTF-8 check. > There are just-send-8859-1 mailers out there in the wild. > UTF-8 can be detected with fair reliability. Are ISO-8859-1 characters (not in US-ASCII) allowed in mail headers? > >* Section 3.2: s/Recent- headers/Resent- headers/ > >* Section 3.2: s/Referenece/References/ > >* Section 3.3: s/receipient/recipient/g (this appears a couple of times > >more) > >* Section 4: "MUA of mail sender MUST append ALT-ADDR or ATOMIC". Aren't > >both parameters optional? Then why MUST? I will rewrite this part such as: "If downgrade is expected, mail sender MUA MUST append ALT-ADDR or ATOMIC" > >* Section 4: s/next session/next section/ > >* Section 4: "local-part: Punycode without normalization". I am sure this > >has been discussed before (I saw a Normalizing-thread in the list), but > >fwiw here it comes my vote against non-normalized identifiers. > > > > > the question is more what normalization, I think.... # I think endpoint MDA only knows normalization method. > >* Section 4: The IMA-Downgraded-From and -To headers should be defined in > >the Internationalized Email Headers draft, too, since that is the > >equivalent of updating RFC2822. agree (or maybe.) > >* Section 4: s/delived/delivered/ > >* Section 5.1: s/new body contains one MIME part/new body contains one new > >MIME part/ > >* Section 5.2: s/headers which contains/headers which contain/ > >* Section 6.2: "if MDA knows MUA is IMA compliant". How should that > >knowledge be conveyed? > > > > > Is this a matter that can safely be left to local consideration? Yes, I think so. In some cases, downgrading is necessary while spooling. # I'm happy if pop server support EAI. > >* Section 7: I am missing a comment in the Security Considerations about > >whose responsibility is that the owners of the internationalized mailboxes > >match the owners of the alternative ASCII ones. > > > > > I think the transport system should not care - there may be use cases > where there's no entity apart from the end user who can tell that they > have the same owner. (Think of someone running ASCII mail on yahoo! and > internationalized mail on Gmail, for instance). I agree. But SPF and DKIM support needs careful considerations. > >* Section 8: s/MUST be differ/MUST differ/ > > > >Best regards, > >Marcos Sanz -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 26 09:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkHV-0002cP-4s; Wed, 26 Apr 2006 09:42:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkHT-0002cJ-UU for ima@ietf.org; Wed, 26 Apr 2006 09:42:11 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkHT-00058h-CG for ima@ietf.org; Wed, 26 Apr 2006 09:42:11 -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 k3QDg4RF028628; Wed, 26 Apr 2006 22:42:10 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006042622420907690 ; Wed, 26 Apr 2006 22:42:09 +0900 Date: Wed, 26 Apr 2006 22:42:09 +0900 (JST) Message-Id: <20060426.224209.116364074.fujiwara@jprs.co.jp> To: alexey.melnikov@isode.com Subject: Re: [EAI] Comments on draft-yoneya-ima-downgrade-01.txt From: fujiwara@jprs.co.jp In-Reply-To: <44302EB4.7030603@isode.com> References: <44302EB4.7030603@isode.com> X-Mailer: Mew version 5.0.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: e1b0e72ff1bbd457ceef31828f216a86 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 too late my response and thanks a lot for your comments. > From: Alexey Melnikov > Some detailed questions/comments on the draft below: > > >3.2. Mail Header Downgrading > > > > Target of downgrading elements in mail headers (SMTP data) are below: > > > > Originator address(es): IMA in From, Reply-To and Sender and their > > Resent- headers MUST be target of downgrading. > > Destination address(es): IMA in To and Cc and their Recent- headers > > MUST be target of downgrading. > > Should Bcc header field be in this list as well (also elsewhere in the > document)? I will add Bcc. (I will also re-check RFC 4021). > What about various List-* header fields that can contain mailto URLs? In my opinion, List-* and X-* header fields are contained in 'other fields'. > > IDs: IDs such as Message-ID, In-Reply-To and Referenece > > typo: References > > > MUST NOT be target of downgrading. > > other headers: UTF-8 in other headers such as Subject and Received > > SHOULD be target of downgrading. > > Is there any reason why SHOULD is used here instead of the MUST? Yes, I'll rewrite to 'MUST'. > >3.3. Requirements > [...] > > 5. Downgrade and upgrade method MUST be defined clearly. > > I read this requirement as an obvious requirement on output of this WG. > So I think the MUST keyword is not applicable here. > Or is this sentence trying to say something else? Downgrading requirements part will be rewritten. > >4. SMTP Downgrading > > > > Downgrading MUST be performed in each SMTP session. Target of > > downgrading elements in SMTP envelope are below: > > > > o MAIL FROM: > > o RCPT TO: > > I've already touched on the subject in my other message, but is there > any interaction between downgrade and DSN SMTP extension? DSN SMTP extension should be considered. "ORCPT" parameter may need to be extended to specify IMA and ALT-ADDR or ATOMIC. (But I don't like to consider now.) > > Further, even if no downgrading is performed for envelope from/to, > > MUA/MTA SHOULD downgrade headers including UTF-8. This is described > > in next session. > > Why only SHOULD here and not MUST? I.e. what are the anticipated reasons > for MUAs for violating the SHOULD? I will rewrite it as "MUST downgrade ... or bounce". > >5.1. Downgrading with MIME encapsulation > > > [...] > > Upgrade/Decode > > * If mail message contains only one MIME part and its Content- > > Type is 'Message/EAI', it may be downgraded. To check if > > "may be upgraded". "it may be a downgraded message." > > downgraded, compare mail body's message-id and MIME part's > > message-id. If message-ids are same, it is downgraded message. > > Then, treat MIME part as entire mail message. > > >6.2. MDA Requirements > [...] > > 4. If MDA detects that SMTP recipient address is downgraded IMA, > > then MDA MUST decode IMA and perform the same processing as if it > > were IMA. MDA MAY normalize or canonicalize local-part before > > processing it. > > It is not clear about what kind of normalization/canonicalization the > draft is talking about and why it is needed at the receiving end. The receiving end administrates mail addresses which belongs to the receiving end domainname. Only it knows how to normalize/canonicalize in its domainname. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 26 14:28:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYokC-0007Jk-I8; Wed, 26 Apr 2006 14:28:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYokB-0007HE-8f for ima@ietf.org; Wed, 26 Apr 2006 14:28:07 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYok8-0003Yt-A1 for ima@ietf.org; Wed, 26 Apr 2006 14:28:07 -0400 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3QIS08x001672 for ; Wed, 26 Apr 2006 12:28:01 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYC00901DWUW500@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 26 Apr 2006 12:28:00 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYC009IFDYLWK40@mail-amer.sun.com>; Wed, 26 Apr 2006 12:27:59 -0600 (MDT) Date: Wed, 26 Apr 2006 11:31:00 -0700 From: Chris Newman Subject: Re: [EAI] Comments on Downgrading In-reply-to: To: Charles Lindsey , ima@ietf.org Message-id: <72454368C01F0DB7C0D1933E@[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: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 4/25/06 17:53 +0100: > On Tue, 25 Apr 2006 10:12:43 +0100, Harald Alvestrand > wrote: > > >> Marcos Sanz/Denic wrote: > >>> * Section 6.2: "if MDA knows MUA is IMA compliant". How should that >>> knowledge be conveyed? >>> >> Is this a matter that can safely be left to local consideration? > > Not entirely. General purpose MTAs (Exim, Sendmail and the like) often serve > communities some of whose members use POP3/IMAP/Good ol' mbox/whatever-else, > and will presently be faced with the problem that some members of their > communities will be IMA-compliant and some not. > > So such an MTA has two possibilities: > 1. Decide, when it sees the RCPT header and after consulting its tables > of which of its recipients can do IMA, whether or not to bounce (or > downgrade) the message at that stage. > 2. Accept the message anyway, with the possibility that it may have to > bounce (or otherwise deal with) it later on when it tries to do its internal > delivery. I'm not fond of the statement "if MDA knows MUA is IMA compliant" simply because the MDA can not have that knowledge in the general case. The choice of MUA can occur (or change) after the MDA has completed its task. I'd say there are three scenarios: 1. The mailbox storage supports native UTF-8 headers and access is limited to mechanisms (extended POP/IMAP) that support down-conversion for legacy MUAs. In this case the MDA should not down-convert and may up-convert. 2. The mailbox storage supports native UTF-8 headers, but some MUAs that directly access the storage do not. In this case the MDA must provide a mechanism for the user to specify a preference for down-conversion (e.g. a Sieve extension for down-conversion) and if the user does so than the MDA must down-convert; otherwise it should not down-convert. The type of people who use MUAs that directly access network mail stores tend to be quite capable of configuration twiddling to make their stuff work. 3. The mailbox storage does not support native UTF-8 headers. In this case, the MDA must down-convert. Regardless, this is in the realm of advice and not wire standards (except that defining a Sieve down-convert extension is helpful for scenario 2). > Our problem is that the IETF has always considered the interface between the > MTA and the storage agents to be an internal matter, since no "wire" is > involved, and has therefore never tried to standardize it in any way. Incorrect. See RFC 2033. > I have a feeling that this was a mistake, and that we really need some > understanding of that process before we can complete our task. We have people with that understanding reviewing our specifications. That's more than sufficient for an experimental specification. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Apr 26 22:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYwc6-0006AM-JP; Wed, 26 Apr 2006 22:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYwc5-0006AH-TW for ima@ietf.org; Wed, 26 Apr 2006 22:52:17 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYwc1-0001qU-6s for ima@ietf.org; Wed, 26 Apr 2006 22:52:17 -0400 Received: (eyou send program); Thu, 27 Apr 2006 10:51:55 +0800 Message-ID: <346106315.28966@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.146 with SMTP; Thu, 27 Apr 2006 10:51:55 +0800 Message-ID: <018301c669a5$87fbe330$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Harald Alvestrand" , References: <345963662.15948@cnnic.cn> Subject: Re: [EAI] Open issues on the EAI documents:allow UTF-8 in quoted-string? Date: Thu, 27 Apr 2006 10:51:36 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.8 (/) 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: , Content-Type: multipart/mixed; boundary="===============1758081601==" Errors-To: ima-bounces@ietf.org --===============1758081601== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBBbHZlc3RyYW5k IiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNk YXksIEFwcmlsIDI1LCAyMDA2IDU6MTIgUE0NClN1YmplY3Q6IFtFQUldIE9wZW4gaXNzdWVzIG9u IHRoZSBFQUkgZG9jdW1lbnRzDQo+IA0KPiBTTVRQIGV4dGVuc2lvbiAoWWFvIGRvY3VtZW50KToN Cj4gSXNzdWU6IFBldGU6IERvIHdlIGFsbG93IFVURi04IGluIHF1b3RlZC1zdHJpbmc/DQo+IA0K DQphY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gb3IgZGVzY3JpcGl0b24gb2YgUkZDIDI4MjIg YmVsb3cgDQoNCiIgICAgIFNvbWUgY2hhcmFjdGVycyBhcmUgcmVzZXJ2ZWQgZm9yIHNwZWNpYWwg aW50ZXJwcmV0YXRpb24sIHN1Y2ggYXMNCiAgIGRlbGltaXRpbmcgbGV4aWNhbCB0b2tlbnMuICBU byBwZXJtaXQgdXNlIG9mIHRoZXNlIGNoYXJhY3RlcnMgYXMNCiAgIHVuaW50ZXJwcmV0ZWQgZGF0 YSwgYSBxdW90aW5nIG1lY2hhbmlzbSBpcyBwcm92aWRlZC4gIEEgcXVvdGVkLXN0cmluZyBpcyB0 cmVhdGVkIGFzIGEgdW5pdC4gIFRoYXQgaXMsIHF1b3RlZC1zdHJpbmcgaXMgIGlkZW50aWNhbCB0 byBhdG9tLCBzZW1hbnRpY2FsbHkuICAiDQoNCkkgc3VnZ2VzdCB0aGF0IHdlIHN0aWxsIGFsbG93 IFVURi04IGluIHF1b3RlZC1zdHJpbmcgKEFTQ0lJIGlzIGFsc28gYSBraW5kIG9mIFVURi04KSBz byB0aGF0IFNvbWUgY2hhcmFjdGVycyBhcmUgcmVzZXJ2ZWQgZm9yIHNwZWNpYWwgaW50ZXJwcmV0 YXRpb24gLg0KDQphbnkgY29tbWVudHM/DQoNCg== --===============1758081601== 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 --===============1758081601==-- From ima-bounces@ietf.org Thu Apr 27 05:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2yp-0007Ng-QH; Thu, 27 Apr 2006 05:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2yp-0007Nb-B7 for ima@ietf.org; Thu, 27 Apr 2006 05:40:11 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ2yo-0000F2-1x for ima@ietf.org; Thu, 27 Apr 2006 05:40:11 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBBB8259736 for ; Thu, 27 Apr 2006 11:39:41 +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 06209-05 for ; Thu, 27 Apr 2006 11:39:38 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F87B259734 for ; Thu, 27 Apr 2006 11:39:38 +0200 (CEST) Message-ID: <44509176.9070509@alvestrand.no> Date: Thu, 27 Apr 2006 11:40:06 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] Please welcome Sheldon Lee as IMA co-chair X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 welcome Xiaodong (Sheldon) Lee, of CNNIC, as co-chair of the EAI working group. Sheldon will be chairing the WG meeting in Montreal, since I won't be there. Sheldon, thanks for taking this on! Harald Alvestrand _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 05:51:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ39s-0006BC-T3; Thu, 27 Apr 2006 05:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ39r-00065t-II for ima@ietf.org; Thu, 27 Apr 2006 05:51:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ1i4-00030H-Qj for ima@ietf.org; Thu, 27 Apr 2006 04:18:48 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZ1OV-000158-IS for ima@ietf.org; Thu, 27 Apr 2006 03:58:36 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 89F0425973A; Thu, 27 Apr 2006 09:58:04 +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 03748-05; Thu, 27 Apr 2006 09:58:00 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98738259739; Thu, 27 Apr 2006 09:58:00 +0200 (CEST) Message-ID: <445079A4.3030401@alvestrand.no> Date: Thu, 27 Apr 2006 09:58:28 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fujiwara@jprs.co.jp Subject: Re: [EAI] Comments on Downgrading References: <444DE80B.1020808@alvestrand.no> <20060426.223656.26286654.fujiwara@jprs.co.jp> In-Reply-To: <20060426.223656.26286654.fujiwara@jprs.co.jp> 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: -2.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 fujiwara@jprs.co.jp wrote: >Sorry too late my response and thanks a lot for comments. > >I will update it according to your comments. > > > >>From: Harald Alvestrand >>This seems to have generated no response.... I'll try to provoke.... >> >>Marcos Sanz/Denic wrote: >> >> >> >>>All, >>> >>>these are my comments on draft-yoneya-ima-downgrade-01. I haven't been >>>following the last discussions in the list. If some of these issues (or >>>any of those in my other mails) have already been dealt with, then just >>>give me a pointer. >>> >>>* Section 3.1: "SMTP client detects UTF-8 is included in SMTP envelope or >>>mail headers". Haven't we introduced the i18n-header to avoid making this >>>realtime, unreliable checks? And is it really meant "detects UTF-8" or it >>>is rather meant "detects 8th bit set"? >>> >>> > >Considering implementation costs, I want to use detecting 8th bit set >instead of UTF-8 check. > > The implementation cost for a proper UTF-8 detector is rather small (you check for the non-presence of the 13 forbidden bytes, and that sequences are properly formed - all that can be done in a fairly small finite state machine in one pass, and you still don't have to look at any byte more than oce), and the cost of accepting ISO 8859-1 into processing stages that expect properly formatted UTF-8 is that you have to do the error checking for that condition *everywhere*. If we want to have heuristic UTF-8 detection, I think we should recommend UTF-8 detection, not the 8th bit check. But if we go with the flag (i18n-header or otherwise), we have moved heuristic UTF-8 detection into the realm of "handling nonconformant data", which our standards leave out a lot of the time anyway. > > >>There are just-send-8859-1 mailers out there in the wild. >>UTF-8 can be detected with fair reliability. >> >> > >Are ISO-8859-1 characters (not in US-ASCII) allowed in mail headers? > > No, they're forbidden. There are mailers that send them anyway. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 08:25:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5Yg-0005Im-Lj; Thu, 27 Apr 2006 08:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5Yf-0005Ih-Nj for ima@ietf.org; Thu, 27 Apr 2006 08:25:21 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZ5Yc-0000md-BB for ima@ietf.org; Thu, 27 Apr 2006 08:25:21 -0400 Received: (snipe 23127 invoked by uid 0); 27 Apr 2006 21:24:57 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.740038 secs); Received: from unknown (HELO ?220.69.185.9?) (Z???own@220.69.185.9) by unknown with SMTP; 27 Apr 2006 21:24:56 +0900 X-RCPTTO: harald@alvestrand.no, ima@ietf.org Message-ID: <4450B816.7070304@icu.ac.kr> Date: Thu, 27 Apr 2006 21:24:54 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [EAI] Please welcome Sheldon Lee as IMA co-chair References: <44509176.9070509@alvestrand.no> In-Reply-To: <44509176.9070509@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Dear Xiadong, Congratulation. I wish you could lead the WG fairly well so that we can have a really nicely working solution to this important issue. Harald Alvestrand wrote: > > Please welcome Xiaodong (Sheldon) Lee, of CNNIC, as co-chair of the > EAI working group. > > Sheldon will be chairing the WG meeting in Montreal, since I won't be > there. > > Sheldon, thanks for taking this on! > > Harald Alvestrand > > > _______________________________________________ > 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 27 09:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6gb-0008Bi-4N; Thu, 27 Apr 2006 09:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6gZ-00082R-6C for ima@ietf.org; Thu, 27 Apr 2006 09:37:35 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZ6gX-0005QE-4Q for ima@ietf.org; Thu, 27 Apr 2006 09:37:35 -0400 Received: (eyou send program); Thu, 27 Apr 2006 21:37:08 +0800 Message-ID: <346145028.09605@cnnic.cn> Received: from 127.0.0.1 by mail.cnnic.cn with HTTP; Thu, 27 Apr 2006 21:37:08 +0800 X-WebMAIL-MUA: [127.0.0.1] From: "" To: newcat@icu.ac.kr, harald@alvestrand.no Date: Thu, 27 Apr 2006 21:37:08 +0800 X-Priority: 3 Subject: Re: [EAI] Please welcome Sheldon Lee as IMA co-chair Content-Type: text/plain X-Spam-Score: 1.4 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Thanks, Harald, and thank you all. I am not a newcomer of IETF, but a newcomer of chair. I will try my best to get this important issue well done. Regards! Xiaodong In your mail: >From: Yangwoo Ko >Reply-To: >To: Harald Alvestrand >Subject: Re: [EAI] Please welcome Sheldon Lee as IMA co-chair >Date:Thu, 27 Apr 2006 21:24:54 +0900 > > > Dear Xiadong > Congratulation. I wish you could lead the WG fairly well so thatwe can have a really nicely working solution to this importaissu > Harald Alvestrand wrote:> > > Please welcome Xiaodong (Sheldon) Lee, of CNNIC, as co-chair of th> EAI working group.> > > Sheldon will be chairing the WG meeting in Montreal, since I won't be > there.> > > Sheldon, thanks for taking this on> > > Harald Alvestrand >> > > > > ______________________________________________> IMA mailing li> IMA@ietf.o> https://www1.ietf.org/mailman/listinfo/ima> > > > > > _______________________________________________ >IMA mailing listIMA@ietf.orghttps://www1.ietf.org/mailman/listinfo/ _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 10:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Bl-00031a-FV; Thu, 27 Apr 2006 10:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Bj-00031B-Q1 for ima@ietf.org; Thu, 27 Apr 2006 10:09:47 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZ7Bh-00078n-4M for ima@ietf.org; Thu, 27 Apr 2006 10:09:47 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-8.tower-124.messagelabs.com!1146146983!9350099!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30444 invoked from network); 27 Apr 2006 14:09:43 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-8.tower-124.messagelabs.com with SMTP; 27 Apr 2006 14:09:43 -0000 Received: from [135.70.115.123] (unknown[135.70.115.123](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060427140942gw100100s1e> (Authid: tony); Thu, 27 Apr 2006 14:09:43 +0000 Message-ID: <4450D0A4.1030505@att.com> Date: Thu, 27 Apr 2006 10:09:40 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Comments on Downgrading References: <444DE80B.1020808@alvestrand.no> <20060426.223656.26286654.fujiwara@jprs.co.jp> <445079A4.3030401@alvestrand.no> In-Reply-To: <445079A4.3030401@alvestrand.no> 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: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > fujiwara@jprs.co.jp wrote: > >>> From: Harald Alvestrand >>> This seems to have generated no response.... I'll try to provoke.... >>> >>> Marcos Sanz/Denic wrote: >>> >>>> * Section 3.1: "SMTP client detects UTF-8 is included in SMTP >>>> envelope or mail headers". Haven't we introduced the i18n-header to >>>> avoid making this realtime, unreliable checks? And is it really >>>> meant "detects UTF-8" or it is rather meant "detects 8th bit set"? >> >> Considering implementation costs, I want to use detecting 8th bit set >> instead of UTF-8 check. >> > The implementation cost for a proper UTF-8 detector is rather small (you > check for the non-presence of the 13 forbidden bytes, and that sequences > are properly formed - all that can be done in a fairly small finite > state machine in one pass, and you still don't have to look at any byte > more than oce), and the cost of accepting ISO 8859-1 into processing > stages that expect properly formatted UTF-8 is that you have to do the > error checking for that condition *everywhere*. > > If we want to have heuristic UTF-8 detection, I think we should > recommend UTF-8 detection, not the 8th bit check. Agreed: if we want UTF-8 detection, we should do a utf-8 check, and not a "just 8-bit check". Tony Hansen tony@att.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 12:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ98P-0003G7-Df; Thu, 27 Apr 2006 12:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ98O-0003G2-L6 for ima@ietf.org; Thu, 27 Apr 2006 12:14:28 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ98J-0000Mq-Vp for ima@ietf.org; Thu, 27 Apr 2006 12:14:28 -0400 Received: from host81-144-67-196.midband.mdip.bt.net ([81.144.67.196]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4450eddd.209.14b for ima@ietf.org; Thu, 27 Apr 2006 17:14:21 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k3RBcTe15413 for ; Thu, 27 Apr 2006 12:38:29 +0100 (BST) Date: Thu, 27 Apr 2006 12:38:28 +0100 To: ima@ietf.org Subject: Re: [EAI] Comments on Downgrading References: <72454368C01F0DB7C0D1933E@[10.1.110.5]> 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: <72454368C01F0DB7C0D1933E@[10.1.110.5]> 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 Wed, 26 Apr 2006 19:31:00 +0100, Chris Newman wrote: > Charles Lindsey wrote on 4/25/06 17:53 +0100: > > Regardless, this is in the realm of advice and not wire standards > (except that defining a Sieve down-convert extension is helpful for > scenario 2). Maybe. We need to be sure that viable implementations are possible in all the scenarios that might arise, and writing down the "advice" somewhere is a good discipline to make sure all cases have been covered. Whether "somehere" turns out to be one of our standards, or the overview document, or some other informational document is a separate issue. > >> Our problem is that the IETF has always considered the interface >> between the >> MTA and the storage agents to be an internal matter, since no "wire" is >> involved, and has therefore never tried to standardize it in any way. > > Incorrect. See RFC 2033. Not so. LMTP is still describing a protocol to be used on a "wire", even though that wire is expected to be a part of a LAN. But that does raise the interesting question as to whether our SMTP draft needs to make mention that it also defines an extension to RFC 2033, and whether there are any special considerations that it needs to mention which apply to LMTP. For example, if a message has arrived at its final destination site (for some definition of "site"), and the site includes various IMAP and/or POP storage agents (each of which might or might not be IMA-capable), it is usual to use LMTP to distribute the message to those various storage agents? If so, then I would expect the LMTP machinery to be handling the bouncing/downgrading for each agent. Does out draft already cover that situation (I expect it does, but someone needs to check). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 17:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDfY-0003TK-FJ; Thu, 27 Apr 2006 17:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDfX-0003TF-CA for ima@ietf.org; Thu, 27 Apr 2006 17:04:59 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZDfT-0002hL-E3 for ima@ietf.org; Thu, 27 Apr 2006 17:04:59 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3RL4saN011615 for ; Thu, 27 Apr 2006 15:04:55 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYE00701FBL1600@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 27 Apr 2006 15:04:54 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYE00FIHFW3BE60@mail-amer.sun.com>; Thu, 27 Apr 2006 15:04:53 -0600 (MDT) Date: Thu, 27 Apr 2006 14:07:56 -0700 From: Chris Newman Subject: Re: [EAI] Comments on Downgrading In-reply-to: To: Charles Lindsey , ima@ietf.org Message-id: <8C5DA9F3874511F7BEF15851@[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: <72454368C01F0DB7C0D1933E@[10.1.110.5]> 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 Charles Lindsey wrote on 4/27/06 12:38 +0100: > But that does raise the interesting question as to whether our SMTP draft > needs to make mention that it also defines an extension to RFC 2033, and > whether there are any special considerations that it needs to mention which > apply to LMTP. > > For example, if a message has arrived at its final destination site (for > some definition of "site"), and the site includes various IMAP and/or POP > storage agents (each of which might or might not be IMA-capable), it is > usual to use LMTP to distribute the message to those various storage agents? > If so, then I would expect the LMTP machinery to be handling the > bouncing/downgrading for each agent. Does out draft already cover that > situation (I expect it does, but someone needs to check). That is a good point. Our extension document should mention that (a) the UTF-8 headers extension may be used with LMTP and (b) We need an error code that applies to both SMTP and LMTP which means "this recipient doesn't accept UTF-8 header material". That error code is important because the final MTA may be capable of down-conversion but should only do it if the specific recipient requires it. Regardless, LMTP (RFC 2033) should be an informative reference; I see no need to make it a normative reference. Note that (a) is important because a revision of the LMTP specification should explicitly state that SMTP extensions do not apply to LMTP unless otherwise stated. Some SMTP extensions (e.g. DSNs) make no sense in LMTP. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 22:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZJ6f-0002aP-0H; Thu, 27 Apr 2006 22:53:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZJ6d-0002aK-SH for ima@ietf.org; Thu, 27 Apr 2006 22:53:19 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZJ6c-0006Hm-B1 for ima@ietf.org; Thu, 27 Apr 2006 22:53:19 -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 k3S2rCR9015802 for ; Fri, 28 Apr 2006 11:53:12 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006042811531116314 for ; Fri, 28 Apr 2006 11:53:11 +0900 Date: Fri, 28 Apr 2006 11:53:11 +0900 (JST) Message-Id: <20060428.115311.27793033.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.0.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: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] RFC 4409 Message Submission X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org MUA uses Submission protocol to send mail to its first MTA. So, RFC 2476 also needs to be updated with smtpext. This is written in framework ID without reference to RFC 2476. Does 'smtpext' document need to describe Submission ? Does 'downgrade' document need to describe Submission ? -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Apr 27 23:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZJRX-0000qM-OO; Thu, 27 Apr 2006 23:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZJRW-0000qH-JS for ima@ietf.org; Thu, 27 Apr 2006 23:14:54 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZJRQ-0008Eg-I7 for ima@ietf.org; Thu, 27 Apr 2006 23:14:54 -0400 Received: (eyou send program); Fri, 28 Apr 2006 11:14:29 +0800 Message-ID: <346194069.12586@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.146 with SMTP; Fri, 28 Apr 2006 11:14:29 +0800 Message-ID: <006401c66a71$e35f2530$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: Date: Fri, 28 Apr 2006 11:14:40 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [EAI] help to define Ucharacter and sub-domain by ABNF X-BeenThere: ima@ietf.org 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="===============1077447860==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============1077447860== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C66AB4.F1682670" This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C66AB4.F1682670 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQogICANCiAgICBDb3VsZCBzb21lIGtpbmQgZXhwZXJ0cyBoZWxwIHRvIHJlZmlu ZSB0aGUgYmVsb3cgZGVmaW5pdGlvbiBvZiBVY2hhcmFjdGVyIGFuZCBzdWItZG9tYWluIGJ5IEFC TkYgaW4gdGhlIElNQSBTTVRQIGV4dGVuc2lvbiBkb2N1bWVudD8NCiAgIEl0IHNlZW1zICBub3Qg ZWFzeSB0byBmaW5kIGEgdmVyeSBnb29kIGFwcHJvcHJpYXRlIGRlZmluaXRpb24uDQoNCiAgdGhh bmtzIGEgbG90Lg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICANCg0KIEFjY29yZGluZyB0byB0aGUg ZGVzY3JpcHRpb24gYWJvdmUsIGRlZmluZSB0aGUgc3ludGF4IG9mIGFuIElNQQ0KICAgbWFpbGJv eCB3aXRoIEFCTkYgW1JGQzQyMzRdIGFzDQoNCg0KICAgICAgICAgTWFpbGJveCA9IExvY2FsLXBh cnQgIkAiIERvbWFpbg0KDQogICAgICAgICBMb2NhbC1wYXJ0ID0gRG90LXN0cmluZyAvIFF1b3Rl ZC1zdHJpbmcNCiAgICAgICAgICAgICAgIDsgTUFZIGJlIGNhc2Utc2Vuc2l0aXZlDQoNCiAgICAg ICAgIERvdC1zdHJpbmcgPSBBdG9tICooIi4iIEF0b20pDQoNCiAgICAgICAgIEF0b20gPSAxKlVj aGFyYWN0ZXINCiAgICAgICAgIFVjaGFyYWN0ZXIgPSA8YW55IFVOSUNPREUgY2hhcmFjdGVyLA0K ICAgICAgICAgICAgIGV4Y2VwdCBBU0NJSSBjaGFyYWN0ZXJzIHRoYXQgYXJlIG5vdCBwZXJtaXR0 ZWQgaW4gImF0ZXh0IiBhbmQgY2hhcmFjdGVycyB0aGF0IGNhbiBub3QgcGFzcyBTdHJpbmdwcmVw Pg0KDQogICAgICAgICBRdW90ZWQtc3RyaW5nID0gRFFVT1RFICpxY29udGVudCBEUVVPVEUNCg0K ICAgICAgICAgRG9tYWluID0gKHN1Yi1kb21haW4gMSooIi4iIHN1Yi1kb21haW4pKSAvIGFkZHJl c3MtbGl0ZXJhbA0KICAgICAgICAgc3ViLWRvbWFpbiA9IExldC1kaWcgW0xkaC1zdHJdIC8NCiAg ICAgICAgICAgICA8YW55IGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBsYWJlbCBzcGVjaWZpZWQg YnkgSUROQT4NCg0KDQpZQU8gSmlhbmthbmcNCkJlc3QgUmVnYXJkcw0KVGVsOjg2LTEwLTU4ODEz MDA3DQpGYXg6ODYtMTAtNjI1NTk4OTINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpDaGluYSBJbnRlcm5ldCBOZXR3b3JrIEluZm9ybWF0aW9uIENl bnRlciAoQ05OSUMpDQo0LCBTb3V0aCA0dGggU3RyZWV0LCBaaG9uZ2d1YW5jdW4sDQpIYWlkaWFu IGRpc3RyaWN0LA0KQmVpamluZyAxMDAwODAsIENoaW5hDQpQT0I6IEJlaWppbmcgMzQ5LCBCcmFu Y2ggNg0KaHR0cDovL3d3dy5jbm5pYy5jbg0KRW1haWw6IHlhb2prQGNubmljLmNuDQpoZWFsdGh5 YW9AMTYzLmNvbQ0K ------=_NextPart_000_0061_01C66AB4.F1682670 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE1NDMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIGFsbCw8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb3VsZCBzb21lIGtp bmQgZXhwZXJ0cyBoZWxwJm5ic3A7dG8gDQpyZWZpbmUgdGhlIGJlbG93IGRlZmluaXRpb24gb2Yg VWNoYXJhY3RlciBhbmQgc3ViLWRvbWFpbiBieSBBQk5GIGluIHRoZSBJTUEgU01UUCANCmV4dGVu c2lvbiBkb2N1bWVudD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJz cDsgSXQgc2VlbXMmbmJzcDsgbm90IGVhc3kgdG8gZmluZCBhIHZlcnkgZ29vZCANCmFwcHJvcHJp YXRlIGRlZmluaXRpb24uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7IHRoYW5rcyBhIGxvdC48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJm5ic3A7Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7QWNjb3JkaW5nIHRvIHRo ZSBkZXNjcmlwdGlvbiBhYm92ZSwgZGVmaW5lIHRoZSBzeW50YXggb2YgDQphbiBJTUE8QlI+Jm5i c3A7Jm5ic3A7IG1haWxib3ggd2l0aCBBQk5GIFtSRkM0MjM0XSBhczwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1haWxib3ggPSBMb2NhbC1wYXJ0IA0KIkAi IERvbWFpbjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExvY2FsLXBhcnQgPSBEb3Qtc3RyaW5nIC8g DQpRdW90ZWQtc3RyaW5nPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjsgTUFZIGJl IGNhc2Utc2Vuc2l0aXZlPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRG90LXN0cmluZyA9IEF0b20g KigiLiIgDQpBdG9tKTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF0b20gPSANCjEqVWNoYXJhY3Rl cjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVWNo YXJhY3RlciA9IA0KJmx0O2FueSBVTklDT0RFIA0KY2hhcmFjdGVyLDxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpleGNlcHQgQVNDSUkgY2hhcmFjdGVycyB0aGF0IGFyZSBub3QgcGVybWl0dGVkIGluICJh dGV4dCIgYW5kIGNoYXJhY3RlcnMgdGhhdCANCmNhbiBub3QgcGFzcyBTdHJpbmdwcmVwJmd0Ozwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFF1b3RlZC1zdHJpbmcgPSBEUVVPVEUgDQoqcWNvbnRlbnQg RFFVT1RFPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRG9tYWluID0gKHN1Yi1kb21haW4gDQoxKigi LiIgc3ViLWRvbWFpbikpIC8gDQphZGRyZXNzLWxpdGVyYWw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Yi1kb21haW4gPSANCkxldC1kaWcgW0xk aC1zdHJdIA0KLzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQombHQ7YW55IGludGVybmF0aW9uYWxpemVk IGRvbWFpbiBsYWJlbCBzcGVjaWZpZWQgYnkgSUROQSZndDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5ZQU8gSmlhbmthbmc8QlI+QmVzdCANClJl Z2FyZHM8QlI+VGVsOjg2LTEwLTU4ODEzMDA3PEJSPkZheDo4Ni0xMC02MjU1OTg5MjxCUj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5DaGluYSAN CkludGVybmV0IE5ldHdvcmsgSW5mb3JtYXRpb24gQ2VudGVyIChDTk5JQyk8QlI+NCwgU291dGgg NHRoIFN0cmVldCwgDQpaaG9uZ2d1YW5jdW4sPEJSPkhhaWRpYW4gZGlzdHJpY3QsPEJSPkJlaWpp bmcgMTAwMDgwLCBDaGluYTxCUj5QT0I6IEJlaWppbmcgMzQ5LCANCkJyYW5jaCA2PEJSPjxBIGhy ZWY9Imh0dHA6Ly93d3cuY25uaWMuY24iPmh0dHA6Ly93d3cuY25uaWMuY248L0E+PEJSPkVtYWls OiA8QSANCmhyZWY9Im1haWx0bzp5YW9qa0Bjbm5pYy5jbiI+eWFvamtAY25uaWMuY248L0E+PEJS PjxBIA0KaHJlZj0ibWFpbHRvOmhlYWx0aHlhb0AxNjMuY29tIj5oZWFsdGh5YW9AMTYzLmNvbTwv QT48QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0061_01C66AB4.F1682670-- --===============1077447860== 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 --===============1077447860==-- From ima-bounces@ietf.org Fri Apr 28 01:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZLZH-0004r5-W1; Fri, 28 Apr 2006 01:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZLZG-0004r0-To for ima@ietf.org; Fri, 28 Apr 2006 01:31:02 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZLZD-0008Vf-1E for ima@ietf.org; Fri, 28 Apr 2006 01:31:02 -0400 Received: from jeffnb (pc094.twnic.net.tw [211.72.211.94]) by twnic.net.tw (8.13.6/8.13.5) with ESMTP id k3S5Unke014747; Fri, 28 Apr 2006 13:30:50 +0800 Message-Id: <200604280530.k3S5Unke014747@twnic.net.tw> From: "Jeff Yeh" To: "'YAO Jiankang'" , Subject: RE: [EAI] help to define Ucharacter and sub-domain by ABNF Date: Fri, 28 Apr 2006 13:39:08 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <346194069.12586@cnnic.cn> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 thread-index: AcZqcfKPPXyg7Ud6TTmgskfklgocWQACQCKA X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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="===============0860172054==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============0860172054== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C66AC9.2092A510" This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C66AC9.2092A510 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Frank Ellermann had reference some nice ABNF in RFC 4282 in earlier post http://www1.ietf.org/mail-archive/web/ima/current/msg00129.html. Maybe we can start from that. Jeff _____ From: YAO Jiankang [mailto:yaojk@cnnic.cn] Sent: Friday, April 28, 2006 11:15 AM To: ima@ietf.org Subject: [EAI] help to define Ucharacter and sub-domain by ABNF Dear all, Could some kind experts help to refine the below definition of Ucharacter and sub-domain by ABNF in the IMA SMTP extension document? It seems not easy to find a very good appropriate definition. thanks a lot. -------------------------------------------------------------------------- According to the description above, define the syntax of an IMA mailbox with ABNF [RFC4234] as Mailbox = Local-part "@" Domain Local-part = Dot-string / Quoted-string ; MAY be case-sensitive Dot-string = Atom *("." Atom) Atom = 1*Ucharacter Ucharacter = Quoted-string = DQUOTE *qcontent DQUOTE Domain = (sub-domain 1*("." sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] / YAO Jiankang Best Regards Tel:86-10-58813007 Fax:86-10-62559892 -------------------------------------------------- China Internet Network Information Center (CNNIC) 4, South 4th Street, Zhongguancun, Haidian district, Beijing 100080, China POB: Beijing 349, Branch 6 http://www.cnnic.cn Email: yaojk@cnnic.cn healthyao@163.com ------=_NextPart_000_0040_01C66AC9.2092A510 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Frank = Ellermann had reference some=20 nice ABNF in RFC 4282 in earlier post = http://www1.ietf.org/mail-archive/web/ima/current/msg00129.html.
Maybe we = can start from=20 that. 

Jeff

From: YAO Jiankang = [mailto:yaojk@cnnic.cn]=20
Sent: Friday, April 28, 2006 11:15 AM
To:=20 ima@ietf.org
Subject: [EAI] help to define Ucharacter and = sub-domain=20 by ABNF

Dear all,
   
    Could some kind experts = help to=20 refine the below definition of Ucharacter and sub-domain by ABNF in = the IMA=20 SMTP extension document?
   It seems  not easy to find a = very good=20 appropriate definition.
 
  thanks a lot.
 
 
----------------------------------------------------------------= ----------  
 
 According to the description above, define = the syntax=20 of an IMA
   mailbox with ABNF [RFC4234] as
 

         Mailbox =3D = Local-part=20 "@" Domain
 
         Local-part =3D = Dot-string=20 /=20 = Quoted-string
         &n= bsp;    =20 ; MAY be case-sensitive
 
         Dot-string =3D = Atom *("."=20 Atom)
 
         Atom =3D=20 1*Ucharacter
         = Ucharacter =3D=20 <any UNICODE=20 = character,
          = ;  =20 except ASCII characters that are not permitted in "atext" and = characters that=20 can not pass Stringprep>
 
         Quoted-string = =3D DQUOTE=20 *qcontent DQUOTE
 
         Domain =3D = (sub-domain=20 1*("." sub-domain)) /=20 address-literal
         = sub-domain=20 =3D Let-dig [Ldh-str]=20 = /
           &n= bsp;=20 <any internationalized domain label specified by = IDNA>
 
 
YAO Jiankang
Best=20 = Regards
Tel:86-10-58813007
Fax:86-10-62559892
------------------= --------------------------------
China=20 Internet Network Information Center (CNNIC)
4, South 4th Street,=20 Zhongguancun,
Haidian district,
Beijing 100080, China
POB: = Beijing=20 349, Branch 6
http://www.cnnic.cn
Email: yaojk@cnnic.cn
healthyao@163.com
<= /BLOCKQUOTE> ------=_NextPart_000_0040_01C66AC9.2092A510-- --===============0860172054== 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 --===============0860172054==-- From ima-bounces@ietf.org Fri Apr 28 02:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZMRz-0002zP-5K; Fri, 28 Apr 2006 02:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZMRx-0002yq-UU for ima@ietf.org; Fri, 28 Apr 2006 02:27:33 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZMQe-0001wy-MW for ima@ietf.org; Fri, 28 Apr 2006 02:26:17 -0400 Received: (eyou send program); Fri, 28 Apr 2006 14:25:57 +0800 Message-ID: <346205557.22007@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.146 with SMTP; Fri, 28 Apr 2006 14:25:57 +0800 Message-ID: <00c401c66a8c$a2b9a940$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: References: <346192808.12365@cnnic.cn> Subject: Re: [EAI] RFC 4409 Message Submission Date: Fri, 28 Apr 2006 14:26:08 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 1.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: , Content-Type: multipart/mixed; boundary="===============1213575351==" Errors-To: ima-bounces@ietf.org --===============1213575351== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGZ1aml3YXJhQGpwcnMuY28u anA+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgQXByaWwgMjgsIDIwMDYgMTA6 NTMgQU0NClN1YmplY3Q6IFtFQUldIFJGQyA0NDA5IE1lc3NhZ2UgU3VibWlzc2lvbg0KDQoNCj4g TVVBIHVzZXMgU3VibWlzc2lvbiBwcm90b2NvbCB0byBzZW5kIG1haWwgdG8gaXRzIGZpcnN0IE1U QS4NCj4gU28sIFJGQyAyNDc2IGFsc28gbmVlZHMgdG8gYmUgdXBkYXRlZCB3aXRoIHNtdHBleHQu DQo+IA0KPiBUaGlzIGlzIHdyaXR0ZW4gaW4gZnJhbWV3b3JrIElEIHdpdGhvdXQgcmVmZXJlbmNl IHRvIFJGQyAyNDc2Lg0KPiANCj4gRG9lcyAnc210cGV4dCcgZG9jdW1lbnQgbmVlZCB0byBkZXNj cmliZSBTdWJtaXNzaW9uID8NCg0KU01UUCB3YXMgZGVmaW5lZCBhcyBhIG1lc3NhZ2UgKnRyYW5z ZmVyKiBwcm90b2NvbCwgdGhhdCBpcywgYSBtZWFucw0KICAgdG8gcm91dGUgKGlmIG5lZWRlZCkg YW5kIGRlbGl2ZXIgZmluaXNoZWQgKGNvbXBsZXRlKSBtZXNzYWdlcy4NClJGQyAyNDc2IGlzIHRv IGRlYWwgd2l0aCBob3cgdG8gc3VtYml0IHRoZSBtZXNzYWdlIHRvIHRoZSBzZXJ2ZXIuIA0KSU1P LCBubyBuZWVkIHRvIGRlc2NyaWJlIHRoZSBpc3N1ZXMgcmVsYXRlZCB3aXRoIFJGQyAyNDc2IGlu ICdzbXRwZXh0JyBkb2N1bWVudCANCmJlY2F1c2UgJ3NtdHBleHQnIGRvY3VtZW50IGZvY3VzIG9u IHRoZSBtZXNzYWdlIHRyYW5mc2VyLCBub3Qgc3VibWl0aW9uLg0KDQoNCg0KPiANCj4gRG9lcyAn ZG93bmdyYWRlJyBkb2N1bWVudCBuZWVkIHRvIGRlc2NyaWJlIFN1Ym1pc3Npb24gPw0KPiANCj4g LS0NCj4gS2F6dW5vcmkgRnVqaXdhcmEsIEpQUlMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiA= --===============1213575351== 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 --===============1213575351==-- From ima-bounces@ietf.org Fri Apr 28 05:34:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZPN3-0007Rh-AQ; Fri, 28 Apr 2006 05:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZPN2-0007Rc-0V for ima@ietf.org; Fri, 28 Apr 2006 05:34:40 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPMz-0005x0-3q for ima@ietf.org; Fri, 28 Apr 2006 05:34:39 -0400 Received: from jeffnb (pc094.twnic.net.tw [211.72.211.94]) by twnic.net.tw (8.13.6/8.13.5) with ESMTP id k3S9YNsl015230 for ; Fri, 28 Apr 2006 17:34:31 +0800 Message-Id: <200604280934.k3S9YNsl015230@twnic.net.tw> From: "Jeff Yeh" To: Subject: RE: [EAI] Comments on Internationalized Email Headers Date: Fri, 28 Apr 2006 17:42:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 thread-index: AcZaU9gKgGzzgoexSMa2vVTbvVVH5QQFvrUQ X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 that I failed to catch up with the mailing list. Feel free to correct me if I miss anything. My response embedded. Thank you for your comment and attention. Jeff Yeh > -----Original Message----- > From: Marcos Sanz/Denic [mailto:sanz@denic.de] > Sent: Friday, April 07, 2006 10:59 PM > To: ima@ietf.org > Subject: [EAI] Comments on Internationalized Email Headers > > All, > > these are my comments on draft-yeh-ima-utf8headers-01. I haven't been > following the last discussions in the list. If some of these > issues (or > any of those in my following mails) have already been dealt > with, then > just give me a pointer. > > * Abstract: "and to use international characters in envelope > addresses". > That's a bit unlucky formulation. What about "to use non-ASCII > characters"? OK. Will update in next version. > * Abstract: "the base form for Internet email header fields". > For the sake > of correctness I would find better "the base form for Internet email > header field bodies". This correction should be made a couple > of other > times in the document. Will update in next version. > * Section 1.1: The UTF-8 issue is addressed here for the first time. > Colour me purist, but I think that the actual encoding of the > header field > bodies should be a transport issue, and that this header > document should > only talk about "non-ASCII" or "Unicode characters" instead of "UTF-8 > characters" (besides the fact, that ASCII are UTF-8 characters, too). Yes, but we're trying to limit the unicode usage in only UTF-8 format. And also avoid the necessary of having a characterset tag. > * Section 2: "This protocol specifies UTF-8 as the encoding > to represent > email header messages". What is meant with "email header > message"? Maybe > "email header body"? Will update in next version. > * Section 2: The concept "IMA mailbox names" appears for the > first time > and is not introduced. Will change to "internationalized email addresses". > * Section 2: "if other header fields (particularly trace > header fields > such as "Received:") contain non-ASCII character". It would > be helpful to > make a complete list (well, probably not here in the introduction) of > which fields are those. I couldn't find it. But "Received" is > defined in > ima-smtp-ext-02 section 2.5.2 to preferably remain ASCII, so this is > probably not a good example to mention. I'll add the list about trace fields in the next version. IMO, the final MTA acts no different. If one support IMA, the trace field can be handled in non-ASCII. If one couldn't, he will get the message in downgraded form (or not to receive). What they do is put the original form into trace field. > * Section 4: "Sending MUAs that follow this protocol MUST > create.." is not > 2119-coherent with the next sentence "MUAs MAY continue to > use MIME..". Ok. I'll remove the "MUAs MAY continue to use MIME part" It preferred not to use MIME in this spec, though we couldn't force people to do that. > * Section 5: s/identifiction/identification/ Thanks. > * Section 5: "Checking the presence of UTF-8 characters in > the header". > Such a thing is not possible: you will find two bytes with > the highest bit > set and won't be able to determine whether you are dealing with two > Latin-1 chars or one UTF-8 char. Actually it does. You can find Chris' thread on http://www1.ietf.org/mail-archive/web/ima/current/msg00188.html > * Section 5: s/the its/the/ Thanks. > * Section 5: "sending MUA should insert a new header". My > opinion is that > "sending MUA MUST insert a new header", otherwise there is no 100% > reliability. Agree to change should to MUST, will update in next version. However, it still can not 100% sure the header goes to the final MTA. Because some MTA do filter/block those header they don't know. (I can't recall, but I'm sure this was being discussed) > * Section 5: "i18n-mail" is a bit strange nomenclature. > "i18n" stands for > "internationalization" and not for "internationalized" (which > should be > i15d). Besides, "i18n mail" just doesn't flow out of the > tongue. Couldn't > we think of something else? Maybe use "I-Email" will be better. Since there's no other concern about the new header name. > * Section 5: "There should be more useful information [that] can be > place[d] in the new header field". Something concrete in mind? Since we're going to invent new header, it good to make more use of this slot. I have no idea yet, but maybe downgrading information could take advantage of this new header. This was being discuss on the list about invent new header or not. To invent a new header like "i18n-mail: 1.0" seems to fall into the experience of "MIME-Version: 1.0". As a spec level, I prefer to have a header to identify i18n-email to traditional email. Where implementers check it or not, is nothing we can control at all. > * Section 5, 1st bullet: "'i18n-mail' header field MUST be > inserted by the > originating MUA". Fine, but cf "should" three bullets in this > mail ago. Thanks. > * Section 5: "..MUST be inserted by the final delivery MTA if not > presented". I don't know if this is for robustness or what, > but it should > be unnecessary, provided that the sending MUA did. And which are the > criteria for inserting it, if not present? Statistical mechanisms to > determine the presence UTF-8 encoding? Response in the previous questions. > * Section 6: "the rules in RFC 2822 for header names are not > changed". > Just delete the sentence. It was stated one sentence ago. > * Section 6: s/extensionextension/extension/ > * Section 6: s/IEE smtp extension/IMA SMTP extension/ Thanks, will update in next version. > * Section 6: Where does the magic number 558 come from? I > mean "55" stands > for "permanent negative in the mail system", but the remaining 8? Sorry, will change to 550. > * Section 6: "any data or instructions embedded in the email > address". > This should be ellaborated a bit more, maybe with one example (we are > talking about "+" encodings, aren't we?) Good idea, will put some in next version. > * Section 6, ATOMIC bullet: " remains the same to > RFC2822. The > only difference..". It either remains the same or there is some > difference. I'll change the text more clear, thanks. > * Section 6, ATOMIC bullet: "The only difference is that the > > and of allows UTF-8 characters". This is > not enough > for a formal syntax definition. It must be clearly enumerated which > characters are allowed and how many of them. The encoding > (UTF-8) is not > relevant for the syntax, though it could effect the max. number of > characters fitting there. Detail ABNF will be prepared. > * Section 6, ALT-ADDRESS bullet: What is the need for > supporting the "obs" > formats? Since ALT-ADDRESS is a ASCII address, defined the same in RFC 2822. I don't see what need to support. Or I reading your question wrong? > * Section 6, ALT-ADDRESS bullet: "new-addr-spec =/ addr-spec" > Isn't that > line in the BNF unnecessary? > * Section 7.1: "MAY need to be updated". RFC 2119 language is not > necessary here, and by now, we know the are being updated. Yes, will remove. > * Section 8: "that user SHOULD have both addresses in the > identity". That > "SHOULD" shouldn't be normative, and I even think it should be "may". Agree to put in MAY. > * Section 8: "Lines that are longer than 78 octects could > possibly cause > mail user agents to fail". I would recommend then to proceed > with folding, > if encodings are longer than 78 octects. Talking about > folding: What do > you think about updating the definition of folding points in > RFC 2822? > Something like allowing for folding at codepoints with the > Zs-property, > instead of only whitespaces. I think white space folding is just enough. What is "Zs-property" by the way? > > Best regards, > Marcos > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 28 08:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZS14-0003SK-Au; Fri, 28 Apr 2006 08:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZS13-0003SF-5y for ima@ietf.org; Fri, 28 Apr 2006 08:24:09 -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 1FZS12-0006nW-Mt for ima@ietf.org; Fri, 28 Apr 2006 08:24:09 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FZS11-0003HJ-GS; Fri, 28 Apr 2006 08:24:07 -0400 Date: Fri, 28 Apr 2006 08:24:06 -0400 From: John C Klensin To: fujiwara@jprs.co.jp, ima@ietf.org Subject: Re: [EAI] RFC 4409 Message Submission Message-ID: In-Reply-To: <20060428.115311.27793033.fujiwara@jprs.co.jp> References: <20060428.115311.27793033.fujiwara@jprs.co.jp> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Friday, 28 April, 2006 11:53 +0900 fujiwara@jprs.co.jp wrote: > MUA uses Submission protocol to send mail to its first MTA. > So, RFC 2476 also needs to be updated with smtpext. RFC 2476 was replaced by RFC 4409, a Draft Standard. Having just gotten 4409 finished after many delays, I suspect that the authors of that document would be reluctant to open it again, especially with a change that would return it to Proposed (I can't speak for the main author, but...). So we need to think about either a stand-alone document that updates 2476 or of attaching some changes to 2476 to some other document. We could even break that in two: (i) a comment about submission with the i18n extension turned on (which really does not require a modification to 4409, just a note in the smtpext document -- see below). (ii) A discussion of downgrading, and possibly even upgrading, at the submission point, a topic that was discussed briefly in Dallas. Volunteers? > This is written in framework ID without reference to RFC 2476. Yes, and that should be corrected. I'll try to put some draft text into a possible revision of that document. > Does 'smtpext' document need to describe Submission ? Either it or some other document. If it doesn't describe Submission, it should probably explicitly note that it does not and point to whatever document does. In either case, it should (I believe must) note that the extension can be used with Message Submission (see section 7 of RFC 4409). > Does 'downgrade' document need to describe Submission ? Something needs to describe Submission-time downgrading (and maybe upgrading, again following the Dallas discussions). Again based on Dallas discussions, I think we need to clearly separate (i) Downgrading and maybe upgrading at submission time (ii) Downgrading during SMTP transport/ relaying (iii) Downgrading and maybe upgrading after final delivery. For the first, which is what is at issue here, it seems to me that we might want to discuss the issues without specifying particular behavior. If that is the case, the discussion could be placed in the framework document (to avoid yet more documents), but suggested text would be appreciated. If, on the other hand, there is specific behavior to be specified, the text should go either into the downgrade document or yet another additional document. A question that might clarify whether we want to specify behavior or not: At present, a 4409 server would be expected to reject a message that contained UTF-8 headers on the principle that one of the jobs of a message submission server is to be forward only SMTP-valid messages into the SMTP environment (see the last paragraph of Section 8, which, in retrospect, might have been a little more carefully written with regard to this extension). Would we like to give explicit permission for a 4409 server to do an explicit UTF-8 check and, if UTF-8 is found, invoke the extension, add extra headers as needed, etc.? Since that check is still heuristic and since, even with the extension, UTF-8 in some header locations would still violate RFC 2822, don't answer without thinking about it first -- my first reaction was "of course", but I'm no longer sure. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Apr 28 22:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZfC9-0007Sg-6b; Fri, 28 Apr 2006 22:28:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZfC8-0007Sb-LR for ima@ietf.org; Fri, 28 Apr 2006 22:28:28 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZfC0-0005MR-Ge for ima@ietf.org; Fri, 28 Apr 2006 22:28:28 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3T2SEaN027675 for ; Fri, 28 Apr 2006 20:28:20 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYG00D01N5B3B00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 28 Apr 2006 20:28:14 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYG00IEFPJ0YZ00@mail-amer.sun.com>; Fri, 28 Apr 2006 20:28:14 -0600 (MDT) Date: Fri, 28 Apr 2006 19:31:18 -0700 From: Chris Newman Subject: Re: [EAI] help to define Ucharacter and sub-domain by ABNF In-reply-to: <006401c66a71$e35f2530$1206e29f@cnnicyaojk> To: YAO Jiankang , 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: <006401c66a71$e35f2530$1206e29f@cnnicyaojk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 This ABNF should work: Ucharacter = atext / UTF8-2 / UTF8-3 / UTF8-4 Where "atext" is defined in RFC 2822 and UTF8-2, UTF8-3, UTF8-4 are defined in RFC 3629. - Chris YAO Jiankang wrote on 4/28/06 11:14 +0800: > > Dear all, > > Could some kind experts help to refine the below definition of Ucharacter > and sub-domain by ABNF in the IMA SMTP extension document? > It seems not easy to find a very good appropriate definition. > > thanks a lot. > > > -------------------------------------------------------------------------- > > According to the description above, define the syntax of an IMA > mailbox with ABNF [RFC4234] as > > > Mailbox = Local-part "@" Domain > > Local-part = Dot-string / Quoted-string > ; MAY be case-sensitive > > Dot-string = Atom *("." Atom) > > Atom = 1*Ucharacter > Ucharacter = except ASCII characters that are not permitted in "atext" and > characters that can not pass Stringprep> > > Quoted-string = DQUOTE *qcontent DQUOTE > > Domain = (sub-domain 1*("." sub-domain)) / address-literal > sub-domain = Let-dig [Ldh-str] / > > > > YAO Jiankang > Best Regards > Tel:86-10-58813007 > Fax:86-10-62559892 > -------------------------------------------------- > China Internet Network Information Center (CNNIC) > 4, South 4th Street, Zhongguancun, > Haidian district, > Beijing 100080, China > POB: Beijing 349, Branch 6 > http://www.cnnic.cn > Email: yaojk@cnnic.cn > healthyao@163.com > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Apr 29 12:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZsZI-0000hG-En; Sat, 29 Apr 2006 12:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZsZH-0000h5-3p for ima@ietf.org; Sat, 29 Apr 2006 12:45:15 -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 1FZsZG-0007Jo-KE for ima@ietf.org; Sat, 29 Apr 2006 12:45:15 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FZsZF-0006cv-Ui; Sat, 29 Apr 2006 12:45:14 -0400 Date: Sat, 29 Apr 2006 12:45:12 -0400 From: John C Klensin To: Harald Alvestrand Subject: Re: [EAI] Open issues on the EAI documents Message-ID: <976F69667025635CBE910437@p3.JCK.COM> In-Reply-To: <444DE7EC.8050807@alvestrand.no> References: <444DE7EC.8050807@alvestrand.no> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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, In the hope of reaching some closure, I've tried to annotate your list, ask some additional questions, and request that we see if we can get some of these issues closed. --On Tuesday, 25 April, 2006 11:12 +0200 Harald Alvestrand wrote: > Here's a rough list of what I think are open issues on the EAI > documents. > It's based on a list that Pete Resnick recorded at the Dallas > meeting > (thanks, Pete!) > I've attempted to add clarifications, and to add some issues > from the list. > > Please remind me what I missed/forgot! -------------------------------- > Framework document: > Issue: Paul: Mandatory to implement should be clarified > Issue: Dave: Clarify that MUST bounce if the next hop doesn't > support, and address can't be converted Both incorporated into the working version of draft-ietf-eai-framework-00 that I am sending within the next few minutes to YangWoo. I'm not positive that this is the right thing to do for the longer term, but it was easy to add text to see if we can agree on what we are talking about and then decide whether to include it. A good deal of terminology in the framework doc also needed cleaning up; I hope at least most of that has been done. --------------------------------- > 822-headers (Yeh document): > Issue: Dave/Chris: Comma in address fields as an alternative > to separate parameter? Can we initiate some specific discussion on this and get it settled? My impression was that we had dropped it due to other interactions, but I could easily be confused. > Issue: Chris: Internationalized comment, especially after > date, needed > Issue: Paul: Canonicalization issues (PKIX/DKIM) > Issue: Pete: Clean separation (or explanation) of what is > message format and what is SMTP Pete, could you explain this further? The problem has plagued us since we started putting transport trace information into the headers, if not longer. Do you expect to settle it here? Or was this a plea to not make it worse, with which I clearly agree. > Issue: Phil: UTF-8 in MIME Content-* fields > Issue: Marcos: remove "UTF-8" from this document - just say > "unicode characters"? I think this is a dead issue. Does anyone other than Marcos want to make a strong case for it? -------------------------------- > SMTP extension (Yao document): > Issue: Pete: Do we allow UTF-8 in quoted-string? > Downgrade document: > Issue: Chris: MUST is too strong for preserving all info - > "gateways lose information" > Issue: Harald/Chris/Paul: Use case for upgrade needs to be > added to scenarios doc, or "upgrade" should be removed from this > document > Issue: Pete: Split upgrade between SMTP upgrades and content > upgrades > Possible consensus: No upgrading of content in the transport > system - may upgrade on recipient system And, drawing from some recent mailing list discussion, in the submission system (where that includes both the sending MUA and any mail submission server that might be involved). I hope this is correct because the framework doc has been tentatively changed to say it. > Issue: Need for/syntax of ATOMIC (ATOMIC=NO seems an important > signal to send) -------------------------------- > POP Document: > Issue: Randy: TOP8 command (I believe consensus is that it > should be added) That is my understanding. Could you issue a call and formalize that understanding? > Issue: Chris: Maybe just have an 8-bit switch, instead of > separate commands (I believe consensus is "no") > Issue: Paul: Right-to-left issues should be looked at -------------------------------- We still need an IMAP document and several other things that the framework document refers to (or those should be removed). Volunteers should start stepping forward. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima