From ima-bounces@ietf.org Mon Nov 12 12:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcfO-0005xc-1w; Mon, 12 Nov 2007 12:01:42 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IrcfN-0005tr-2y for ima-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 12:01:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcfM-0005tC-E6 for ima@ietf.org; Mon, 12 Nov 2007 12:01:40 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrcfL-0000GZ-Qu for ima@ietf.org; Mon, 12 Nov 2007 12:01:40 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0B43259733 for ; Mon, 12 Nov 2007 18:01:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19398-02 for ; Mon, 12 Nov 2007 18:01:33 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4EC55259719 for ; Mon, 12 Nov 2007 18:01:33 +0100 (CET) Message-ID: <47388714.4050402@alvestrand.no> Date: Mon, 12 Nov 2007 18:02:12 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: EAI WG X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------020508090609000504050402" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [EAI] [Fwd: EAI - Requested session has been scheduled for IETF 70] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------020508090609000504050402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Rescheduled for Wednesday. Harald --------------020508090609000504050402 Content-Type: message/rfc822; name="EAI - Requested session has been scheduled for IETF 70" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="EAI - Requested session has been scheduled for IETF 70" Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Mon, 12 Nov 2007 17:56:59 +0100 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A4A0259733 for ; Mon, 12 Nov 2007 17:56:59 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19125-08 for ; Mon, 12 Nov 2007 17:56:50 +0100 (CET) X-Greylist: domain auto-whitelisted by SQLgrey-1.6.7 Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AFB7259719 for ; Mon, 12 Nov 2007 17:56:50 +0100 (CET) Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id BE102175A5; Mon, 12 Nov 2007 16:56:48 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Ircae-0006ej-9X; Mon, 12 Nov 2007 11:56:48 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: harald@alvestrand.no Cc: lee@cnnic.cn, chris.newman@sun.com, lisa@osafoundation.org, session-request@ietf.org From: IETF Secretariat Subject: EAI - Requested session has been scheduled for IETF 70 Message-Id: Date: Mon, 12 Nov 2007 11:56:48 -0500 X-Virus-Scanned: by amavisd-new at alvestrand.no Dear Harald Alvestrand, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. EAI Session 1 (2 hours) Wednesday, Morning Session I 0900-1130 Room Name: Salon 3 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: eai Area Name: Applications Area Session Requester: Harald Alvestrand Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 60 Conflicts to Avoid: First Priority: imapext lemonade apparea ipr lemonade ltru dkim sieve sasl dnsop ipr smime krb-wg enum usefor tls httpbis Second Priority: dnsext crisp BOF or IRTF Session: please avoid conflict with BOFs of APP area, Special Requests: --------------------------------------------------------- --------------020508090609000504050402 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 --------------020508090609000504050402-- From ima-bounces@ietf.org Mon Nov 12 14:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfBv-0007gx-J4; Mon, 12 Nov 2007 14:43:27 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IrfBu-0007gs-OH for ima-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 14:43:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfBu-0007gj-DN for ima@ietf.org; Mon, 12 Nov 2007 14:43:26 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrfBt-0007KP-IT for ima@ietf.org; Mon, 12 Nov 2007 14:43:26 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 14-md50000000231.tmp for ; Mon, 12 Nov 2007 11:06:04 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Mon, 12 Nov 2007 11:06:04 -0700 Date: Mon, 12 Nov 2007 11:06:04 -0700 From: "Chris Walker" To: "eai list" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Mon, 12 Nov 2007 11:06:04 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [EAI] The need for an ASCII Compatible Encoding (ACE) standard for email address internationalization outside of email protocols X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org -The need for an ASCII Compatible Encoding (ACE) standard for email address internationalization outside of email protocols- Continuation of existing interoperability between entities that exchange email addresses drives the need for a standard ACE for internationalized email addresses outside of the domain of email protocols. Email addresses are currently stored, used, analyzed, and communicated over numerous ASCII based systems including but not limited to databases, fixed codepage legacy platforms such as mainframes, and text based batch processing. The number of ASCII based systems that still exist to this day are so numerous that calculating their number is not likely possible. -Side effects of EAI and unintended consequences- Internationalized Domain Names took an approach that applied an ACE, specifically punycode, to internationalized domain names. RFC 3490 states Applications can use IDNA to support internationalized domain names anywhere that ASCII domain names are already supported, including DNS master files and resolver interfaces. As a result, ASCII systems had a built-in and unambiguous method for handling internationalized domain names. EAI on the other hand is taking a different approach, specifically UFT8 end to end, and as a result EAI does not provide ASCII systems a standard methodology for handling the local part of internationalized email addresses. -Protocol owner responsibility- As expressed in the IETF mission statement (RFC 3935): Protocol ownership - when the IETF takes ownership of a protocol or function, it accepts the responsibility for all aspects of the protocol, even though some aspects may rarely or never be seen on the Internet. -Corporate systems are part of the internet- Drawing from the IETF mission statement: The Internet: A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both the "core Internet" (ISP networks) and "edge Internet" (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices). -Making the Internet work better- Again drawing from the IETF mission statement: The goal of the IETF is to make the Internet work better. The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds. The efforts of the EAI working group certainly will make the Internet work better in regards to sending and receiving internationalized email; however without setting a standard for the ACE representation of the local part of an internationalized email address they will make other parts of the Internet work worse than they do today. This burden could itself prevent the adoption of email address internationalization from occurring as rapidly as might be possible if the burden did not exist or was reduced. ________________________________________________________________________ I therefore strenuously argue that providing a standard for the ACE representation of the local part of an internationalized email address for use OUTSIDE OF UTF8SMTP, SMTP, POP, and IMAP is within the scope, the responsibility of, and in the best interest of the EAI working group. ________________________________________________________________________ Since the domain name part already has an ACE, only local part needs an ACE. It is desirable to only provide a method for encoding the local part, as opposed to encoding the entire email address, to allow non email based systems to parse the domain part from the entire email address without having to decode the entire email address to access the domain part. This will also prevent systems from having to handle cases where the domain part is encoded multiple times. Since code that implements the internationalized domain name ACE, the RFC 3490 ToASCII operation, uses nameprep and punycode, it would be sensible to consider using punycode as an ACE for the local part to eliminate the need for additional code that implements a second ACE for these systems. The simplest non destructive, non lossy, method for conversion from a UTF8 local part to an ACE representation of the local part, and back again to the UTF8 representation, that maintains all the case, quoting, escaping, and specials characters of the original is desirable. As the name suggests: ASCII Compatible Encoding is just that, encoding, I am not suggesting that any functionality other than faithfully representing whatever may be encountered in the local part in an ASCII form. There is no intent that there is any check for the local part being valid or well formed. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 12 15:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfh6-0007fh-Hb; Mon, 12 Nov 2007 15:15:40 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Irfh5-0007e2-EL for ima-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 15:15:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfh5-0007di-2F for ima@ietf.org; Mon, 12 Nov 2007 15:15:39 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Irfh3-0000P9-86 for ima@ietf.org; Mon, 12 Nov 2007 15:15:38 -0500 Received: (eyou send program); Tue, 13 Nov 2007 04:15:30 +0800 Message-ID: <394898530.22522@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 13 Nov 2007 04:15:30 +0800 Message-ID: <070001c82568$c6983730$7fd5bc79@yaojk> From: "YAO Jiankang" To: "Chris Walker" , "eai list" References: <394896619.22526@cnnic.cn> Subject: Re: [EAI] The need for an ASCII Compatible Encoding (ACE) standard foremail address internationalization outside of email protocols Date: Tue, 13 Nov 2007 04:15:25 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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="===============0601226869==" Errors-To: ima-bounces@ietf.org --===============0601226869== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBDaHJpcyBXYWxrZXIsDQogICAgIElmIHlvdSBmbGxvdyBvdXIgRUFJIGRpc2N1c3Npb24g dGhyb3VnaHRseSwgeW91IG1heSBub3RpY2UgdGhhdCB0aGlzIGlzc3VlIGhhcyBiZWVuIHJhaXNl ZCBhbmQgZGlzY3Vzc2VkIG1hbnkgdGltZXMgYW5kIGhhcyBiZWVuIHNvbHZlZCBieSB0aGUgRUFJ IFdHLiBBcyBFQUkgbWFpbGluZyBsaXN0LCBJIG5vdGljZWQgdGhhdCB5b3UganVzdCBqb2luIHRo aXMgbWFpbGluZyBsaXN0LiBDb3VsZCBJIHN1Z2dlc3QgeW91IHRvIHJlYWQgbW9yZSBkaXNjdXNz aW9ucyBhYm91dCBFQUkgaW4gaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9p bWEvY3VycmVudC9pbmRleC5odG1sIC4NCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGtpbmQgcXVl c3Rpb25zLg0KDQpZQU8gSmlhbmthbmcNCiAgICAgDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KRnJvbTogIkNocmlzIFdhbGtlciIgPGN3LWVhaS1pZXRmQGllc3ByZXNpby5jb20+DQpU bzogImVhaSBsaXN0IiA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTMs IDIwMDcgMjowNiBBTQ0KU3ViamVjdDogW0VBSV0gVGhlIG5lZWQgZm9yIGFuIEFTQ0lJIENvbXBh dGlibGUgRW5jb2RpbmcgKEFDRSkgc3RhbmRhcmQgZm9yZW1haWwgYWRkcmVzcyBpbnRlcm5hdGlv bmFsaXphdGlvbiBvdXRzaWRlIG9mIGVtYWlsIHByb3RvY29scw0KDQoNCj4gLVRoZSBuZWVkIGZv ciBhbiBBU0NJSSBDb21wYXRpYmxlIEVuY29kaW5nIChBQ0UpIHN0YW5kYXJkIGZvciBlbWFpbCAN Cj4gYWRkcmVzcyBpbnRlcm5hdGlvbmFsaXphdGlvbiBvdXRzaWRlIG9mIGVtYWlsIHByb3RvY29s cy0NCj4gDQo+IENvbnRpbnVhdGlvbiBvZiBleGlzdGluZyBpbnRlcm9wZXJhYmlsaXR5IGJldHdl ZW4gZW50aXRpZXMgdGhhdCBleGNoYW5nZSANCj4gZW1haWwgYWRkcmVzc2VzIGRyaXZlcyB0aGUg bmVlZCBmb3IgYSBzdGFuZGFyZCBBQ0UgZm9yIGludGVybmF0aW9uYWxpemVkIA0KPiBlbWFpbCBh ZGRyZXNzZXMgb3V0c2lkZSBvZiB0aGUgZG9tYWluIG9mIGVtYWlsIHByb3RvY29scy4gRW1haWwg DQo+IGFkZHJlc3NlcyBhcmUgY3VycmVudGx5IHN0b3JlZCwgdXNlZCwgYW5hbHl6ZWQsIGFuZCBj b21tdW5pY2F0ZWQgb3ZlciANCj4gbnVtZXJvdXMgQVNDSUkgYmFzZWQgc3lzdGVtcyBpbmNsdWRp bmcgYnV0IG5vdCBsaW1pdGVkIHRvIGRhdGFiYXNlcywgDQo+IGZpeGVkIGNvZGVwYWdlIGxlZ2Fj eSBwbGF0Zm9ybXMgc3VjaCBhcyBtYWluZnJhbWVzLCBhbmQgdGV4dCBiYXNlZCBiYXRjaCANCj4g cHJvY2Vzc2luZy4gVGhlIG51bWJlciBvZiBBU0NJSSBiYXNlZCBzeXN0ZW1zIHRoYXQgc3RpbGwg ZXhpc3QgdG8gdGhpcyANCj4gZGF5IGFyZSBzbyBudW1lcm91cyB0aGF0IGNhbGN1bGF0aW5nIHRo ZWlyIG51bWJlciBpcyBub3QgbGlrZWx5IHBvc3NpYmxlLg0KPiANCj4gLVNpZGUgZWZmZWN0cyBv ZiBFQUkgYW5kIHVuaW50ZW5kZWQgY29uc2VxdWVuY2VzLQ0KPiANCj4gSW50ZXJuYXRpb25hbGl6 ZWQgRG9tYWluIE5hbWVzIHRvb2sgYW4gYXBwcm9hY2ggdGhhdCBhcHBsaWVkIGFuIEFDRSwgDQo+ IHNwZWNpZmljYWxseSBwdW55Y29kZSwgdG8gaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIG5hbWVz LiAgUkZDIDM0OTAgDQo+IHN0YXRlcyAiQXBwbGljYXRpb25zIGNhbiB1c2UgSUROQSB0byBzdXBw b3J0IGludGVybmF0aW9uYWxpemVkIGRvbWFpbiANCj4gbmFtZXMgIGFueXdoZXJlIHRoYXQgQVND SUkgZG9tYWluIG5hbWVzIGFyZSBhbHJlYWR5IHN1cHBvcnRlZCwgaW5jbHVkaW5nIA0KPiBETlMg bWFzdGVyIGZpbGVzIGFuZCByZXNvbHZlciBpbnRlcmZhY2VzLiIgIEFzIGEgcmVzdWx0LCBBU0NJ SSBzeXN0ZW1zIA0KPiBoYWQgYSBidWlsdC1pbiBhbmQgdW5hbWJpZ3VvdXMgbWV0aG9kIGZvciBo YW5kbGluZyBpbnRlcm5hdGlvbmFsaXplZCANCj4gZG9tYWluIG5hbWVzLiAgRUFJIG9uIHRoZSBv dGhlciBoYW5kIGlzIHRha2luZyBhIGRpZmZlcmVudCBhcHByb2FjaCwgDQo+IHNwZWNpZmljYWxs eSBVRlQ4IGVuZCB0byBlbmQsIGFuZCBhcyBhIHJlc3VsdCBFQUkgZG9lcyBub3QgcHJvdmlkZSBB U0NJSSANCj4gc3lzdGVtcyBhIHN0YW5kYXJkIG1ldGhvZG9sb2d5IGZvciBoYW5kbGluZyB0aGUg bG9jYWwgcGFydCBvZiANCj4gaW50ZXJuYXRpb25hbGl6ZWQgZW1haWwgYWRkcmVzc2VzLg0KPiAN Cj4gLVByb3RvY29sIG93bmVyIHJlc3BvbnNpYmlsaXR5LQ0KPiANCj4gQXMgZXhwcmVzc2VkIGlu IHRoZSBJRVRGIG1pc3Npb24gc3RhdGVtZW50IChSRkMgMzkzNSk6ICJQcm90b2NvbCANCj4gb3du ZXJzaGlwIC0gd2hlbiB0aGUgSUVURiB0YWtlcyBvd25lcnNoaXAgb2YgYSBwcm90b2NvbCBvciBm dW5jdGlvbiwgaXQgDQo+IGFjY2VwdHMgdGhlIHJlc3BvbnNpYmlsaXR5IGZvciBhbGwgYXNwZWN0 cyBvZiB0aGUgcHJvdG9jb2wsIGV2ZW4gdGhvdWdoIA0KPiBzb21lIGFzcGVjdHMgbWF5IHJhcmVs eSBvciBuZXZlciBiZSBzZWVuIG9uIHRoZSBJbnRlcm5ldC4iDQo+IA0KPiAtQ29ycG9yYXRlIHN5 c3RlbXMgYXJlIHBhcnQgb2YgdGhlIGludGVybmV0LQ0KPiANCj4gRHJhd2luZyBmcm9tIHRoZSBJ RVRGIG1pc3Npb24gc3RhdGVtZW50OiAiVGhlIEludGVybmV0OiBBIGxhcmdlLCANCj4gaGV0ZXJv Z2VuZW91cyBjb2xsZWN0aW9uIG9mIGludGVyY29ubmVjdGVkIHN5c3RlbXMgdGhhdCBjYW4gYmUg dXNlZCBmb3IgDQo+IGNvbW11bmljYXRpb24gb2YgbWFueSBkaWZmZXJlbnQgdHlwZXMgYmV0d2Vl biBhbnkgaW50ZXJlc3RlZCBwYXJ0aWVzIA0KPiBjb25uZWN0ZWQgdG8gaXQuICBUaGUgdGVybSBp bmNsdWRlcyBib3RoIHRoZSAiY29yZSBJbnRlcm5ldCIgKElTUCANCj4gbmV0d29ya3MpIGFuZCAi ZWRnZSBJbnRlcm5ldCIgKGNvcnBvcmF0ZSBhbmQgcHJpdmF0ZSBuZXR3b3Jrcywgb2Z0ZW4gDQo+ IGNvbm5lY3RlZCB2aWEgZmlyZXdhbGxzLCBOQVQgYm94ZXMsIGFwcGxpY2F0aW9uIGxheWVyIGdh dGV3YXlzIGFuZCANCj4gc2ltaWxhciBkZXZpY2VzKS4iDQo+IA0KPiAtTWFraW5nIHRoZSBJbnRl cm5ldCB3b3JrIGJldHRlci0NCj4gDQo+IEFnYWluIGRyYXdpbmcgZnJvbSB0aGUgSUVURiBtaXNz aW9uIHN0YXRlbWVudDogICJUaGUgZ29hbCBvZiB0aGUgSUVURiBpcyANCj4gdG8gbWFrZSB0aGUg SW50ZXJuZXQgd29yayBiZXR0ZXIuIFRoZSBtaXNzaW9uIG9mIHRoZSBJRVRGIGlzIHRvIHByb2R1 Y2UgDQo+IGhpZ2ggcXVhbGl0eSwgcmVsZXZhbnQgdGVjaG5pY2FsIGFuZCBlbmdpbmVlcmluZyBk b2N1bWVudHMgdGhhdCANCj4gaW5mbHVlbmNlIHRoZSB3YXkgcGVvcGxlIGRlc2lnbiwgdXNlLCBh bmQgbWFuYWdlIHRoZSBJbnRlcm5ldCBpbiBzdWNoIGEgDQo+IHdheSBhcyB0byBtYWtlIHRoZSBJ bnRlcm5ldCB3b3JrIGJldHRlci4gIFRoZXNlIGRvY3VtZW50cyBpbmNsdWRlIA0KPiBwcm90b2Nv bCBzdGFuZGFyZHMsIGJlc3QgY3VycmVudCBwcmFjdGljZXMsIGFuZCBpbmZvcm1hdGlvbmFsIGRv Y3VtZW50cyANCj4gb2YgdmFyaW91cyBraW5kcy4iDQo+IA0KPiBUaGUgZWZmb3J0cyBvZiB0aGUg RUFJIHdvcmtpbmcgZ3JvdXAgY2VydGFpbmx5IHdpbGwgbWFrZSB0aGUgSW50ZXJuZXQgDQo+IHdv cmsgYmV0dGVyIGluIHJlZ2FyZHMgdG8gc2VuZGluZyBhbmQgcmVjZWl2aW5nIGludGVybmF0aW9u YWxpemVkIGVtYWlsOyANCj4gaG93ZXZlciB3aXRob3V0IHNldHRpbmcgYSBzdGFuZGFyZCBmb3Ig dGhlIEFDRSByZXByZXNlbnRhdGlvbiBvZiB0aGUgDQo+IGxvY2FsIHBhcnQgb2YgYW4gaW50ZXJu YXRpb25hbGl6ZWQgZW1haWwgYWRkcmVzcyB0aGV5IHdpbGwgbWFrZSBvdGhlciANCj4gcGFydHMg b2YgdGhlIEludGVybmV0IHdvcmsgd29yc2UgdGhhbiB0aGV5IGRvIHRvZGF5LiBUaGlzIGJ1cmRl biBjb3VsZCANCj4gaXRzZWxmIHByZXZlbnQgdGhlIGFkb3B0aW9uIG9mIGVtYWlsIGFkZHJlc3Mg aW50ZXJuYXRpb25hbGl6YXRpb24gZnJvbSANCj4gb2NjdXJyaW5nIGFzIHJhcGlkbHkgYXMgbWln aHQgYmUgcG9zc2libGUgaWYgdGhlIGJ1cmRlbiBkaWQgbm90IGV4aXN0IG9yIA0KPiB3YXMgcmVk dWNlZC4NCj4gDQo+IA0KPiAgICAgICAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gICAgICAg SSB0aGVyZWZvcmUgc3RyZW51b3VzbHkgYXJndWUgdGhhdCBwcm92aWRpbmcgYSBzdGFuZGFyZCBm b3IgdGhlDQo+ICAgICAgIEFDRSByZXByZXNlbnRhdGlvbiBvZiB0aGUgbG9jYWwgcGFydCBvZiBh biBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbA0KPiAgICAgICBhZGRyZXNzIGZvciB1c2UgT1VUU0lE RSBPRiBVVEY4U01UUCwgU01UUCwgUE9QLCBhbmQgSU1BUCANCj4gICAgICAgaXMgd2l0aGluIHRo ZSBzY29wZSwgdGhlIHJlc3BvbnNpYmlsaXR5IG9mLCBhbmQgaW4gdGhlIGJlc3QNCj4gICAgICAg aW50ZXJlc3Qgb2YgdGhlIEVBSSB3b3JraW5nIGdyb3VwLg0KPiAgICAgICAgDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiANCj4gDQo+IFNpbmNlIHRoZSBkb21haW4gbmFtZSBwYXJ0IGFscmVhZHkgaGFz IGFuIEFDRSwgb25seSBsb2NhbCBwYXJ0IG5lZWRzIGFuIA0KPiBBQ0UuDQo+IA0KPiBJdCBpcyBk ZXNpcmFibGUgdG8gb25seSBwcm92aWRlIGEgbWV0aG9kIGZvciBlbmNvZGluZyB0aGUgbG9jYWwg cGFydCwgYXMgDQo+IG9wcG9zZWQgdG8gZW5jb2RpbmcgdGhlIGVudGlyZSBlbWFpbCBhZGRyZXNz LCB0byBhbGxvdyBub24gZW1haWwgYmFzZWQgDQo+IHN5c3RlbXMgdG8gcGFyc2UgdGhlIGRvbWFp biBwYXJ0IGZyb20gdGhlIGVudGlyZSBlbWFpbCBhZGRyZXNzIHdpdGhvdXQgDQo+IGhhdmluZyB0 byBkZWNvZGUgdGhlIGVudGlyZSBlbWFpbCBhZGRyZXNzIHRvIGFjY2VzcyB0aGUgZG9tYWluIHBh cnQuIA0KPiBUaGlzIHdpbGwgYWxzbyBwcmV2ZW50IHN5c3RlbXMgZnJvbSBoYXZpbmcgdG8gaGFu ZGxlIGNhc2VzIHdoZXJlIHRoZSANCj4gZG9tYWluIHBhcnQgaXMgZW5jb2RlZCBtdWx0aXBsZSB0 aW1lcy4NCj4gDQo+IFNpbmNlIGNvZGUgdGhhdCBpbXBsZW1lbnRzIHRoZSBpbnRlcm5hdGlvbmFs aXplZCBkb21haW4gbmFtZSBBQ0UsIHRoZSANCj4gUkZDIDM0OTAgVG9BU0NJSSBvcGVyYXRpb24s IHVzZXMgbmFtZXByZXAgYW5kIHB1bnljb2RlLCBpdCB3b3VsZCBiZSANCj4gc2Vuc2libGUgdG8g Y29uc2lkZXIgdXNpbmcgcHVueWNvZGUgYXMgYW4gQUNFIGZvciB0aGUgbG9jYWwgcGFydCB0byAN Cj4gZWxpbWluYXRlIHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIGNvZGUgdGhhdCBpbXBsZW1lbnRz IGEgc2Vjb25kIEFDRSBmb3IgDQo+IHRoZXNlIHN5c3RlbXMuDQo+IA0KPiBUaGUgc2ltcGxlc3Qg bm9uIGRlc3RydWN0aXZlLCBub24gbG9zc3ksIG1ldGhvZCBmb3IgY29udmVyc2lvbiBmcm9tIGEg DQo+IFVURjggbG9jYWwgcGFydCB0byBhbiBBQ0UgcmVwcmVzZW50YXRpb24gb2YgdGhlIGxvY2Fs IHBhcnQsIGFuZCBiYWNrIA0KPiBhZ2FpbiB0byB0aGUgVVRGOCByZXByZXNlbnRhdGlvbiwgdGhh dCBtYWludGFpbnMgYWxsIHRoZSBjYXNlLCBxdW90aW5nLCANCj4gZXNjYXBpbmcsIGFuZCBzcGVj aWFscyBjaGFyYWN0ZXJzIG9mIHRoZSBvcmlnaW5hbCBpcyBkZXNpcmFibGUuIEFzIHRoZSANCj4g bmFtZSBzdWdnZXN0czogQVNDSUkgQ29tcGF0aWJsZSBFbmNvZGluZyBpcyBqdXN0IHRoYXQsIGVu Y29kaW5nLCBJIGFtIA0KPiBub3Qgc3VnZ2VzdGluZyB0aGF0IGFueSBmdW5jdGlvbmFsaXR5IG90 aGVyIHRoYW4gZmFpdGhmdWxseSByZXByZXNlbnRpbmcgDQo+IHdoYXRldmVyIG1heSBiZSBlbmNv dW50ZXJlZCBpbiB0aGUgbG9jYWwgcGFydCBpbiBhbiBBU0NJSSBmb3JtLiBUaGVyZSBpcyANCj4g bm8gaW50ZW50IHRoYXQgdGhlcmUgaXMgYW55IGNoZWNrIGZvciB0aGUgbG9jYWwgcGFydCBiZWlu ZyB2YWxpZCBvciB3ZWxsIA0KPiBmb3JtZWQuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4g SU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lt YQ0KPg== --===============0601226869== 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 --===============0601226869==-- From ima-bounces@ietf.org Mon Nov 12 20:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkN4-0000KK-H6; Mon, 12 Nov 2007 20:15:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IrkN3-0000K9-2O for ima-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 20:15:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkN2-0000HA-Md for ima@ietf.org; Mon, 12 Nov 2007 20:15:16 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrkMz-0005ZJ-3q for ima@ietf.org; Mon, 12 Nov 2007 20:15:16 -0500 Received: (snipe 7920 invoked by uid 0); 13 Nov 2007 10:15:27 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.582406 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 13 Nov 2007 10:15:26 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: cw-eai-ietf@iespresio.com, ima@ietf.org, yangwooko@gmail.com Message-ID: <4738FAB1.4000801@icu.ac.kr> Date: Tue, 13 Nov 2007 10:15:29 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chris Walker Subject: Re: [EAI] The need for an ASCII Compatible Encoding (ACE) standard for email address internationalization outside of email protocols References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Walker wrote: > (snip) > I therefore strenuously argue that providing a standard for the > ACE representation of the local part of an internationalized email > address for use OUTSIDE OF UTF8SMTP, SMTP, POP, and IMAP > is within the scope, the responsibility of, and in the best > interest of the EAI working group. > (snip) Let me understand your proposal more closely. What IETF RFCs are concerned with the usage of local parts "OUTSIDE OF UTF8SMTP, SMTP, POP, and IMAP"? I guess that this (or very similar) question was raised at apparea (or somewhere else) meeting during IETF 6?. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 11:55:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz3A-0004PB-Sq; Tue, 13 Nov 2007 11:55:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Irz39-0004OS-FB for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 11:55:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz39-0004OF-1T for ima@ietf.org; Tue, 13 Nov 2007 11:55:43 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irz38-00062K-74 for ima@ietf.org; Tue, 13 Nov 2007 11:55:42 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 42-md50000000008.tmp for ; Tue, 13 Nov 2007 09:58:08 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Tue, 13 Nov 2007 09:58:08 -0700 Date: Tue, 13 Nov 2007 09:58:08 -0700 From: "Chris Walker" To: "eai list" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Tue, 13 Nov 2007 09:58:08 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [EAI] Additional Clarification re: Need of an ACE for EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Additional Clarification re: Need of an ACE for EAI. Having read the EAI working groups drafts, the Internet Mail Consortiums draft (prior to its dissolution in this process) and the EAI working groups message archive going back to summer of 2006 There were at several points in time in the past, where there were proposals to use ACE representation of the local part as a MEANS for implementing internationalized email addresses. That is, encode Unicode to ASCII at or very near to the user interface level, and transmit the ACE over SMTP then convert the ACE back to Unicode at or near the recipients user interface. This method for IMPLEMENTING the transmission of email has died, among the earliest and loudest arguments that this is not acceptable are: The ACE representations will leak, as RFC 4952 now states QUOTE If non-obvious encodings, such as protocol-specific ASCII- Compatible Encoding (ACE) variants, are used, the user will inevitably, if only occasionally, see them rather than "native" characters and will find that discomfiting or astonishing. ENDQUOTE And the argument that interpreting the local part was only in the domain of the system(s) in the domain part of the email address, also from RFC 4952 referencing RFC 2821 et al. QUOTE This is the SMTP server that controls the format of the local parts of addresses and is permitted to inspect and interpret them. ENDQUOTE So instead of using an ACE, UTF8 Unicode email address are being proposed to be sent end to end, STMP obviously does not support that and that is the reason for the UTF8SMTP extension. ------------------------------------------------------------------------ I am not arguing that any of the decisions of the EAI working group that comprise the transmission of emails over email protocols need to support encoded local parts. ------------------------------------------------------------------------ What I am arguing is that as a result of not taking an ASCII encoding route, and by taking the UTF8 over the wire route, the following is the result of that decision. There is no STANDARD for systems outside of email protocols that cannot support Unicode to use for the encoding of internationalized email addresses. If ACEing of the local part was used as the method for email transmission, then (as in the case of IDNA) the ACE representation would be an obvious choice for use in ASCII systems. However there is no ACEing of the local part, so there is no obvious standard for ASCII systems. ------------------------------------------------------------------------ Consider the following scenario, your company and another company that is your business partner exchange information using text files as part of some business processes. Lets say for the sake of this scenario that the company that sends the file takes a customer order for some product, and your company fills the order and ships it. Part of this data is the customers email address. When internationalized domain names came along, if there was an email address for a customer that had an internationalized domain name, no problem, the punycode ACE version of the domain part is sent in the text file. Now along comes internationalized email addresses, now you have a customer with Unicode in the local part of their email address, how do you put that into your ASCII text file? Is there a standard for doing that? You scratch your head for a while and decide to see what the IETF says, well they dont say anything on the issue. Hmmm, now what? I guess you and your business partner can come up with some encoding of your own. Things are working again. What is wrong with the above scenario? Since there is no standard defined, the two companies came up with their own encoding method. Every set of companies that fit into the above scenario can do the same, lots and lots of companies all deciding different ways to represent internationalized email addresses in ASCII. Companies A and B decide on using base64, companies C and D decide on using punycode, companies E and F decide on using escaped octets. Compaies G an H decide on punycode except they use nameprep. Companies I and J encode the entire email address, Companies K and L encode only the local part and use ACE punycode on the domain part. Some companies have different business units that each came up with their own encoding, these companies can't even exchange meaningful email address within their own company. There is now NO STANDARD, none of these sets of companies can communicate internationalized email addresses effectively, numerous encoding methods are applied to email addresses where systems interact, such as in databases, with no indication of what encoding system was used for any particular email address. How on earth did this happen, who is responsible for this mess? If the IETF EAI working group cannot spend a couple paragraphs to describe some standard, ANY standard for encoding internationalized email addresses in ASCII, they will be. If you do not think that providing some informational standard ACE for the local part is in the domain of the EAI working group, then I ask: Which working group do you think is more closely related to this issue and should provide the Internet community guidance on this matter? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 12:09:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrzGH-0003hK-9p; Tue, 13 Nov 2007 12:09:17 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IrzGG-0003h1-FD for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 12:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrzGG-0003gs-5a for ima@ietf.org; Tue, 13 Nov 2007 12:09:16 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrzGD-0004Hx-Qe for ima@ietf.org; Tue, 13 Nov 2007 12:09:16 -0500 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IrzGD-0005bF-FZ for ima@ietf.org; Tue, 13 Nov 2007 12:09:13 -0500 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id CB7E83AC19C; Tue, 13 Nov 2007 12:11:02 -0500 (EST) Date: Tue, 13 Nov 2007 12:11:02 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071113171102.GF8030@afilias.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Nov 13, 2007 at 09:58:08AM -0700, Chris Walker wrote: > There is no STANDARD for systems outside of email protocols that cannot > support Unicode to use for the encoding of internationalized email > addresses. In my opinion, to the extent that is true (and I note there is in fact a fallback mechanism proposed -- see below), it's a feature. In my experience, the ability of non-IDNA-aware user agents (not to mention users!) to see the "Punycode" version of the domain turns out to be a giant problem for the non-geek set. Some of them would rather the domain _not work_ than that people get a possibly confusing bunch of ASCII. Explanations of why this backward compatibility was a good thing have tended to elicit blank stares or else angry denunciations about how computer geeks don't care about "real usability" in "the real world". > Now along comes internationalized email addresses, now you have a > customer with Unicode in the local part of their email address, how do > you put that into your ASCII text file? Is there a standard for doing Isn't this what the ALT-ADDRESS is for? A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 13:11:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0Eq-0008ON-Dg; Tue, 13 Nov 2007 13:11:52 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Is0Eo-0008Hq-7E for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 13:11:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0En-0008Fk-Qv for ima@ietf.org; Tue, 13 Nov 2007 13:11:49 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is0En-0000ww-DT for ima@ietf.org; Tue, 13 Nov 2007 13:11:49 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C68B259709; Tue, 13 Nov 2007 19:11:48 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29319-06; Tue, 13 Nov 2007 19:11:43 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D26B02580D3; Tue, 13 Nov 2007 19:11:42 +0100 (CET) Message-ID: <4739E8DE.7020207@alvestrand.no> Date: Tue, 13 Nov 2007 19:11:42 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Chris Walker Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > > What I am arguing is that as a result of not taking an ASCII encoding=20 > route, and by taking the UTF8 over the wire route, the following is the= =20 > result of that decision. > > There is no STANDARD for systems outside of email protocols that cannot= =20 > support Unicode to use for the encoding of internationalized email=20 > addresses.=20 > =20 > If ACE=92ing of the local part was used as the method for email=20 > transmission, then (as in the case of IDNA) the ACE representation woul= d=20 > be an obvious choice for use in ASCII systems. However there is no=20 > ACE=92ing of the local part, so there is no obvious standard for ASCII = > systems. > > =20 There's an argument to be made that the choice of the ACE mechanism (if=20 any) actually depends strongly on the context of the usage. For instance, if we ever get around to defining a Mailto:-like IRI,=20 which will then support the UTF-8 encoding of EAI's mailbox names, then=20 by the rules of converting IRIs to URIs, the logical "ACE" format for=20 the corresponding mailto: URI would be the percent-escaped, hex-encoded=20 string that corresponds to the UTF-8 byte sequence. I'll be very surprised if I *ever* encounter a business card with such=20 an address upon it, just as I've never (so far) seen a business card=20 with the Punycode form of a domain name on it. I expect people with two-sided business cards to continue to have an=20 all-ASCII email address on the side that has their all-ASCII postal addre= ss. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 14:21:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1Kf-0004qV-NF; Tue, 13 Nov 2007 14:21:57 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Is1Ke-0004qD-Aj for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 14:21:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1Kd-0004q5-P4 for ima@ietf.org; Tue, 13 Nov 2007 14:21:55 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is1Kb-0000wE-SX for ima@ietf.org; Tue, 13 Nov 2007 14:21:55 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id D8DF924083D; Tue, 13 Nov 2007 19:21:37 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 8E3C11590AE; Tue, 13 Nov 2007 17:19:47 -0200 (BRST) Date: Tue, 13 Nov 2007 17:19:47 -0200 From: Stephane Bortzmeyer To: Chris Walker Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071113191947.GA16028@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Nov 13, 2007 at 09:58:08AM -0700, Chris Walker wrote a message of 121 lines which said: > Consider the following scenario, Let's use a real case. ICANN just announced the implementation of the Registrar Data Escrow system: http://www.icann.org/announcements/announcement-2-09nov07.htm The technical documentation for the ICANN registrars states: 4.1.1 Escrow records shall be compiled into a single (uncompressed) CSV text file or multiple (uncompressed) text files approximately 1 gigabyte or one million rows in size, in compliance with RFC 4180 . In accordance with RFC 4180, the character encoding for the CSV file should be US-ASCII, although UTF-8 is also permissible. If a technical or administrative contact has an internationalized email address, the only way is to send UTF-8 (which is only "permissible"). At the present time, we have no standard way to encode the internationalized address in US-ASCII so the registrar cannot comply with the "should be" above. [This is just an example of a real-life case. It is not an opinion.] _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 14:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1Ug-00071J-Lx; Tue, 13 Nov 2007 14:32:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Is1Uf-00070U-4l for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 14:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1Ue-00070L-RR for ima@ietf.org; Tue, 13 Nov 2007 14:32:16 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is1Ub-0001GV-Jl for ima@ietf.org; Tue, 13 Nov 2007 14:32:16 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0AF4724083A; Tue, 13 Nov 2007 19:32:02 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 119BF1590AE; Tue, 13 Nov 2007 17:27:08 -0200 (BRST) Date: Tue, 13 Nov 2007 17:27:08 -0200 From: Stephane Bortzmeyer To: Andrew Sullivan Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071113192708.GB16028@laperouse.bortzmeyer.org> References: <20071113171102.GF8030@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071113171102.GF8030@afilias.info> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Nov 13, 2007 at 12:11:02PM -0500, Andrew Sullivan wrote a message of 36 lines which said: > Isn't this what the ALT-ADDRESS is for? The way I understand it, ALT-ADDRESS is a human-made alternative, that has to be configured by the user, not an encoding which can be done algorithmically. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 15:39:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2XW-0000Kz-Qj; Tue, 13 Nov 2007 15:39:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Is2XV-0000KT-Ar for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 15:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2XV-0000Jl-0v for ima@ietf.org; Tue, 13 Nov 2007 15:39:17 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is2XT-0003pv-4V for ima@ietf.org; Tue, 13 Nov 2007 15:39:17 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A5BF2596FF; Tue, 13 Nov 2007 21:39:14 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01039-01; Tue, 13 Nov 2007 21:39:06 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45C582596CB; Tue, 13 Nov 2007 21:39:06 +0100 (CET) Message-ID: <473A0B69.306@alvestrand.no> Date: Tue, 13 Nov 2007 21:39:05 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: <20071113191947.GA16028@laperouse.bortzmeyer.org> In-Reply-To: <20071113191947.GA16028@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Stephane Bortzmeyer wrote: > On Tue, Nov 13, 2007 at 09:58:08AM -0700, > Chris Walker wrote > a message of 121 lines which said: > > >> Consider the following scenario, >> > > Let's use a real case. ICANN just announced the implementation of the > Registrar Data Escrow system: > > http://www.icann.org/announcements/announcement-2-09nov07.htm > > The technical documentation for the ICANN registrars states: > > 4.1.1 Escrow records shall be compiled into a single (uncompressed) CSV > text file or multiple (uncompressed) text files approximately 1 gigabyte > or one million rows in size, in compliance with RFC 4180 > . In accordance with RFC 4180, the > character encoding for the CSV file should be US-ASCII, although > UTF-8 is also permissible. > > If a technical or administrative contact has an internationalized > email address, the only way is to send UTF-8 (which is only > "permissible"). At the present time, we have no standard way to encode > the internationalized address in US-ASCII so the registrar cannot > comply with the "should be" above. > Huh? RFC 4180 says absolutely nothing about how email addresses are represented. If you want UTF-8 in email addresses, you have to use an UTF-8 encoding of the CSV file. Just as you have to do if you have non-ASCII characters in the postal addresses. What's new here? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 13 16:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3D5-0006qp-Uo; Tue, 13 Nov 2007 16:22:15 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Is3D3-0006p3-SR for ima-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 16:22:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3D3-0006oq-HZ for ima@ietf.org; Tue, 13 Nov 2007 16:22:13 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is3D3-0000Kq-43 for ima@ietf.org; Tue, 13 Nov 2007 16:22:13 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 74A9C2596FF for ; Tue, 13 Nov 2007 22:22:12 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01991-05 for ; Tue, 13 Nov 2007 22:22:07 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 002ED2596FC for ; Tue, 13 Nov 2007 22:22:06 +0100 (CET) Message-ID: <473A157E.1060001@alvestrand.no> Date: Tue, 13 Nov 2007 22:22:06 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [EAI] Status of tickets, November 13 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As of this date, my tracker lists 4 open tickets against the documents that have completed WG Last Call: 1504 UTF8HDR 4.2: Nested encodings avoidable? I believe the WG consensus is to permit nested encodings. Some tweaking of language is in order. 1505 SMTPEXT 2.2/2.8: Scan whole message to determine if UTF8SMTP is required? I believe the WG consensus is that one has to scan the whole message to determine if UTF8SMTP is required, including the MIME headers of nested MIME entities. This is a consequence of the architectural decision to not put any flag in the envelope or headers to say whether the message required UTF8SMTP or not. I beleive no change to the text is needed on this point. 1506 SMTPEXT cleanup of sections 3-5 I believe the WG consensus is to remove section 3-5 more or less wholesale, keeping any information not pertaining to SMTP in an appendix listing "things that should have been in RFC 4952 if we had known them at the time". 1507 UTF8HDR/DSN: Remove NO-WS_CTL from specification? I do not detect any strong sense of the WG. In the absence of a sense of the WG, the change will remain unmade. If posting on any specific issue, please include the ticket number (in the form #NNNN) in the subject line. Do NOT use "reply" on this message. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 06:19:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGHW-0001h0-4g; Wed, 14 Nov 2007 06:19:42 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsGHU-0001eh-QO for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 06:19:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGHU-0001bZ-AU for ima@ietf.org; Wed, 14 Nov 2007 06:19:40 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsGHQ-0005is-9Q for ima@ietf.org; Wed, 14 Nov 2007 06:19:40 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew$man$ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.262) id 473ad9c6.15221.122 for ima@ietf.org; Wed, 14 Nov 2007 11:19:34 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id lAEBJXN8008672 for ; Wed, 14 Nov 2007 11:19:34 GMT Date: Wed, 14 Nov 2007 11:19:32 -0000 To: IMA Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: <4739E8DE.7020207@alvestrand.no> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4739E8DE.7020207@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 13 Nov 2007 18:11:42 -0000, Harald Alvestrand wrote: >> >> What I am arguing is that as a result of not taking an ASCII encoding >> route, and by taking the UTF8 over the wire route, the following is the >> result of that decision. >> >> There is no STANDARD for systems outside of email protocols that cannot >> support Unicode to use for the encoding of internationalized email >> addresses. If ACE’ing of the local part was used as the method for >> email transmission, then (as in the case of IDNA) the ACE >> representation would be an obvious choice for use in ASCII systems. >> However there is no ACE’ing of the local part, so there is no obvious >> standard for ASCII systems. >> >> > There's an argument to be made that the choice of the ACE mechanism (if > any) actually depends strongly on the context of the usage. > > For instance, if we ever get around to defining a Mailto:-like IRI, > which will then support the UTF-8 encoding of EAI's mailbox names, then > by the rules of converting IRIs to URIs, the logical "ACE" format for > the corresponding mailto: URI would be the percent-escaped, hex-encoded > string that corresponds to the UTF-8 byte sequence. +1 Current mailto URIs (even if largely percent encoded) are a sufficient means of conveying the I18N address within other documents. Or else just use charset=UTF-8 when sending those documents. So the problem does not lie in conveying the global address of the customer from the company in Hong Kong to the manufacturing company in the USA. The problem arises when the manufacturing company in the USA needs to send an email to the customer in Hong Kong. Agreed there is no obvious solution to that if the USA company is not willing or able to implenent EAI. But one simple and possible solution is for the Hong Kong company to set up an automatic forwardng system, so the USA encapsulates the message in some agreed format, and the Hong Kong company (which surely _has_ implemented EAI) unwraps it and sends it on. But yes, maybe we should be looking at other solutions to this particular problem. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 06:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGZx-0006QJ-RM; Wed, 14 Nov 2007 06:38:45 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsGZw-0006OQ-0n for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 06:38:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGZv-0006OI-NA for ima@ietf.org; Wed, 14 Nov 2007 06:38:43 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsGZs-0006D8-8A for ima@ietf.org; Wed, 14 Nov 2007 06:38:43 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0E660240835; Wed, 14 Nov 2007 11:38:26 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 96ACE1590AE; Wed, 14 Nov 2007 09:31:20 -0200 (BRST) Date: Wed, 14 Nov 2007 09:31:20 -0200 From: Stephane Bortzmeyer To: Harald Alvestrand Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071114113120.GA30304@laperouse.bortzmeyer.org> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473A0B69.306@alvestrand.no> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Nov 13, 2007 at 09:39:05PM +0100, Harald Alvestrand wrote a message of 40 lines which said: > RFC 4180 says absolutely nothing about how email addresses are > represented. I never talked about that. Please forget RFC 4180, the important part in the ICANN documentation was: the character encoding for the CSV file should be US-ASCII, although UTF-8 is also permissible. > If you want UTF-8 in email addresses, you have to use an UTF-8 encoding of > the CSV file. See the sentence above. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 06:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGkQ-00045u-Tt; Wed, 14 Nov 2007 06:49:34 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsGkP-00041t-Fx for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 06:49:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGkP-0003zt-2t for ima@ietf.org; Wed, 14 Nov 2007 06:49:33 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsGkO-0006Ut-Cs for ima@ietf.org; Wed, 14 Nov 2007 06:49:32 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IsGkL-000CLL-Gn; Wed, 14 Nov 2007 06:49:29 -0500 Date: Tue, 13 Nov 2007 19:12:50 -0500 From: John C Klensin To: Chris Walker Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <92BD677EB19D1754723A4FC1@7AD4D3FB4841A5E367CCF211> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: -98.1 (---------------------------------------------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 13 November, 2007 09:58 -0700 Chris Walker wrote: > Additional Clarification re: Need of an ACE for EAI. >=20 > Having read the EAI working groups drafts, the Internet Mail > Consortiums draft (prior to its dissolution in this process) > and the EAI working group's message archive going back to > summer of 2006=E2=80=A6 >=20 > There were at several points in time in the past, where there > were proposals to use ACE representation of the local part as >... Chris, This issue and option have been explored at great length in the past. I don't believe you are saying anything new. However, to reprise the reasons that may not be adequately explained... (1) The "no one screws with the local-part except the delivery MTA" principle is important to keep all sorts of things working. Unlike the DNS, where we had a fairly good idea that we wouldn't find any letter-letter-hyphen-hyphen names and could test that hypothesis in, at least, all of the gTLDs, several of the ccTLDs, and the walkable part of the DNS tree, we have no way to verify that a possible ACE prefix would not be construed as something else. Indeed, we know of all sorts of mildly insane, but perfectly valid, email local part conventions, including strings with embedded quotes and spaces and strings that embed command line elements. Those things might be unwise in the extreme, but there is no way that an i18n mail activity can blow them off. (2) I'm at IGF in Rio, and have gotten several earfulls about the degree to which the whole ACE idea is part of a broken big picture because it assumes that ASCII is, and should be the world's base character set. IDNA was built around the assumption that users would never, or almost never, see the punycode ACE forms. That assumption turned out to be false and the user who has been living with a bad transliteration into ASCII that is at least memorable often doesn't think that xn--CCCCCC is an improvement (see Andrew Sullivan's note. I think the IDNA decision was reasonable, but I've been told this week that IDNA is a failure from a cultural diversity standpoint and that we should discard it and dust off and approve my old "new class" proposal (which has its own set of very significant technical and operational problems). I've also been told that, if there is justification for using an ACE, one needs to justify it and not, e.g., what I'm now going to name a ECA... an Arabic-compatible encoding because there is really no rational reason why ASCII should be the base special-case in an internationalized system. =20 The things that you see as protocol difficulties are actually useful because they provide additional protection against misinterpretation of addresses and data in legacy environments. It remains an important goal for email that we know that it will either be delivered to the right place or not at all. ACEs get very weak on that dimension of the receiving systems have any sort of algorithmic way of dealing with addresses. And, as others have pointed out, if you need an ACE, use a URI mailto and let the characters be turned into hex-encoded UTF-8 octets. That format is well-defined as part of the EAI spec, where it is not for raw addresses, it is certainly provides an ASCII form. john b _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 07:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHbz-0002Qw-BJ; Wed, 14 Nov 2007 07:44:55 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsHbx-0002M2-LM for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 07:44:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHbx-0002Ll-71 for ima@ietf.org; Wed, 14 Nov 2007 07:44:53 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsHbw-0000PO-Rd for ima@ietf.org; Wed, 14 Nov 2007 07:44:53 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D29252596FF; Wed, 14 Nov 2007 13:44:51 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30671-07; Wed, 14 Nov 2007 13:44:46 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADAF12596FE; Wed, 14 Nov 2007 13:44:45 +0100 (CET) Message-ID: <473AEDBD.7020002@alvestrand.no> Date: Wed, 14 Nov 2007 13:44:45 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <20071114113120.GA30304@laperouse.bortzmeyer.org> In-Reply-To: <20071114113120.GA30304@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Stephane Bortzmeyer wrote: > On Tue, Nov 13, 2007 at 09:39:05PM +0100, > Harald Alvestrand wrote > a message of 40 lines which said: > > >> RFC 4180 says absolutely nothing about how email addresses are >> represented. >> > > I never talked about that. Please forget RFC 4180, the important part > in the ICANN documentation was: > > the > character encoding for the CSV file should be US-ASCII, although > UTF-8 is also permissible. > > >> If you want UTF-8 in email addresses, you have to use an UTF-8 encoding of >> the CSV file. >> > > See the sentence above. > > but there's no difference between an email address and a postal address in this regard. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 10:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKAt-0000qU-Np; Wed, 14 Nov 2007 10:29:07 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsKAr-0000pT-Sp for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKAr-0000pI-0d for ima@ietf.org; Wed, 14 Nov 2007 10:29:05 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKAn-0005XP-NK for ima@ietf.org; Wed, 14 Nov 2007 10:29:04 -0500 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IsKAn-0000ah-Bz for ima@ietf.org; Wed, 14 Nov 2007 10:29:01 -0500 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id 0696C3AC869; Wed, 14 Nov 2007 10:30:55 -0500 (EST) Date: Wed, 14 Nov 2007 10:30:55 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071114153055.GA22889@afilias.info> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <20071114113120.GA30304@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071114113120.GA30304@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Nov 14, 2007 at 09:31:20AM -0200, Stephane Bortzmeyer wrote: > > I never talked about that. Please forget RFC 4180, the important part > in the ICANN documentation was: > > the > character encoding for the CSV file should be US-ASCII, although > UTF-8 is also permissible. This seems merely to be a member of a class of problems that I'll call "managerial", in the presence of internationalized data. There are obviously going to be people who want ASCII-only values, and who think that magic will happen in the computer world that somehow transmutes 8 bits into 7. But 7 bits ain't that big: no amount of asking to make 7 bits bigger will cause non-ASCII to fit in ASCII-only. I have been in plenty of meetings in my lifetime where the action demanded of me by someone was really "to make light go faster". But no matter how they insisted, I was unable to comply with this request. The correct reply to ICANN's request is, "You get all the data, or you get US-ASCII only. Pick which you prefer." A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 13:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMvV-0008EG-6T; Wed, 14 Nov 2007 13:25:25 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsMvS-00089J-EW for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 13:25:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMvS-000896-3T for ima@ietf.org; Wed, 14 Nov 2007 13:25:22 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMvR-0001UB-J6 for ima@ietf.org; Wed, 14 Nov 2007 13:25:22 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 27-md50000000031.tmp for ; Wed, 14 Nov 2007 11:27:56 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Wed, 14 Nov 2007 11:27:55 -0700 Date: Wed, 14 Nov 2007 11:27:55 -0700 From: "Chris Walker" To: "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <473A0B69.306@alvestrand.no> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Wed, 14 Nov 2007 11:27:56 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > If you want UTF-8 in email addresses, you have to use an UTF-8 encoding > of the CSV file. Just as you have to do if you have non-ASCII > characters > in the postal addresses. > > What's new here? > > Harald The hard cold reality on the ground is that there are innumerable ASCII business processes in existence today. Period. This working group cannot expect all of them to re-engineer to 8 bit capable systems just to support new email addresses. The example above regarding postal addresses is not accurate, transliterations of every significant non roman character based language exist for representing those languages in roman characters. * ISO 9 Cyrillic * ISO 233 Arabic * ISO 259 Hebrew * ISO 843 Greek * ISO 3602 Japanese * ISO 7098 Chinese * ISO 9984 Georgian * ISO 9985 Armenian * ISO 11940 Thai * ISO 11941 Korean (different systems for North and South Korea) * ISO 15919 Indic scripts I have worked in this space for many years and I know of several Fortune 500 companies that have 10s of millions of international customers with *not a single* postal address stored in Unicode. ________________________________________________________ The conversion of all ASCII systems represents 10s or 100s of millions of dollars in development costs, just to support internationalized email addresses. The companies that have these systems may very likely upgrade their email server software when internationalized email functionality is available and can send and receive internationalized emails. That will not magically allow all the other software that exists in a company that stores, communicates, or otherwise 'sees' an email address to function properly. I am positive that the number of systems that come into contact with email addresses vastly outnumber the number of email servers. The burden and costs to business and organizations to upgrade email server software, will be minor compared to other costs. Due to the effort and expense many of these systems will not be upgraded to being 8bit capable. Not doing anything, not providing guidance will naturally result in chaos. There are lots of bright people involved in this effort, there has got to be some way to complete the following sentence, and include it in one of RFCs in a prominent location: The preferred method for representing internationalized email addresses is in their native UTF8 format, however, if it is not possible to do so and an internationalized email address must be stored, communicated, or processed by an ASCII system (all outside of the scope of actually sending an email) the preferred encoding method is _____________________________. Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 14:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNe7-0004uC-FL; Wed, 14 Nov 2007 14:11:31 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsNe5-0004pi-Uw for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 14:11:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNe5-0004pL-HM for ima@ietf.org; Wed, 14 Nov 2007 14:11:29 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsNe4-0007Bo-OL for ima@ietf.org; Wed, 14 Nov 2007 14:11:29 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IsNe3-0005si-QW; Wed, 14 Nov 2007 14:11:28 -0500 Date: Wed, 14 Nov 2007 14:11:27 -0500 From: John C Klensin To: Stephane Bortzmeyer Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <932AEC1C24625DF8BEBF3F44@p3.JCK.COM> In-Reply-To: <20071113191947.GA16028@laperouse.bortzmeyer.org> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 13 November, 2007 17:19 -0200 Stephane Bortzmeyer wrote: >... > The technical documentation for the ICANN registrars states: > > 4.1.1 Escrow records shall be compiled into a single > (uncompressed) CSV text file or multiple (uncompressed) > text files approximately 1 gigabyte or one million rows > in size, in compliance with RFC 4180 > . In accordance with RFC > 4180, the character encoding for the CSV file should be > US-ASCII, although UTF-8 is also permissible. > > > If a technical or administrative contact has an > internationalized email address, the only way is to send UTF-8 > (which is only "permissible"). At the present time, we have no > standard way to encode the internationalized address in > US-ASCII so the registrar cannot comply with the "should be" > above. Stephane, In addition to the comments others have made about this, four observations: (1) Even though it is very useful in trying to nail down the definition of a widely-used but much-varied format, RFC 4180 is an informational document, not an IETF standard of any type. If ICANN wants to "standardize" it to the extent that they write a spec that requires compliance with it, no one can prevent their doing so, but whatever decisions they make and rules they adopt for the use of a non-standard doesn't have much, if anything, to do with the IETF. (2) Since ICANN is not a standards body and, in particular, is not the IETF, we have no real way to real way to interpret what "should be" or "permissible" mean. It is almost certainly not reasonable to assume they correspond to the SHOULD and MAY of RFC 2119. (3) The problems with CSV files, including issues of what to do with too-short or too-long records and the great difficulty in extending the format with new fields and handling information with a variable number of subfields, are well known. Indeed, they are well-known enough that the choice of CSV, rather than some variety of tagged data (e.g., XML) for this type of information should probably be described by such terms of precise technical evaluation as "plain dumb". There is a considerable history of CSV files --even those that contain header lines -- being hard to handle when revisited after several years, especially if the data element list has been changed for more recent versions and software updated to match. That history is strong enough that, were someone actively involved with ICANN reading this discussion, I think he or she would be doing the community a favor by asking that this issue be reopened and the format changed before we all come to regret the CSV files. (4) Finally, "... no standard way to encode the internationalized address in US-ASCII so the registrar cannot comply with the "should be" above" seems to be to lie somewhere between "incorrect" and a "red herring". Even without Alt-Address, nothing prevents a user from having more than one address, whether with aliases or alternate labels. It has been fairly general knowledge for years that people with email addresses structured as joe.blogs@example.com should find something else to use in SOA record contact fields because a lot of tools can't handle "joe\.blogs.example.com" properly. This is really no different: if the information is to be in UTF-8, then an non-ASCII email address might plausibly be included (although I wouldn't recommend it until the EAI work is _very_ widely supported). If the information is to be in ASCII, then anyone with a non-ASCII email address will have to supply an ASCII alias. That is certainly not a big deal in the grand scheme of things. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 15:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsOY3-00015M-0z; Wed, 14 Nov 2007 15:09:19 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsOY1-00011l-73 for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 15:09:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsOY0-00011S-SE for ima@ietf.org; Wed, 14 Nov 2007 15:09:16 -0500 Received: from abenaki.wabanaki.net ([65.99.1.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsOY0-0006va-7i for ima@ietf.org; Wed, 14 Nov 2007 15:09:16 -0500 Received: from eric-brunner-williamss-macbook.local (dpc6745177176.direcpc.com [67.45.177.176]) by abenaki.wabanaki.net (8.14.1/8.14.1) with ESMTP id lAEJfsH5033471; Wed, 14 Nov 2007 14:41:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <473B5563.5010502@nic-naa.net> Date: Wed, 14 Nov 2007 12:06:59 -0800 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <932AEC1C24625DF8BEBF3F44@p3.JCK.COM> In-Reply-To: <932AEC1C24625DF8BEBF3F44@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: mike.zupke@icann.org, eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Guys, I would have caught this had Mike Zupke showed me the draft. I suggest we treat it as something that needs clarification. Of course, you're all free to do otherwise. Eric John C Klensin wrote: > --On Tuesday, 13 November, 2007 17:19 -0200 Stephane Bortzmeyer > wrote: > > >> ... >> The technical documentation for the ICANN registrars states: >> >> 4.1.1 Escrow records shall be compiled into a single >> (uncompressed) CSV text file or multiple (uncompressed) >> text files approximately 1 gigabyte or one million rows >> in size, in compliance with RFC 4180 >> . In accordance with RFC >> 4180, the character encoding for the CSV file should be >> US-ASCII, although UTF-8 is also permissible. >> >> >> If a technical or administrative contact has an >> internationalized email address, the only way is to send UTF-8 >> (which is only "permissible"). At the present time, we have no >> standard way to encode the internationalized address in >> US-ASCII so the registrar cannot comply with the "should be" >> above. >> > > Stephane, > > In addition to the comments others have made about this, four > observations: > > (1) Even though it is very useful in trying to nail down the > definition of a widely-used but much-varied format, RFC 4180 is > an informational document, not an IETF standard of any type. If > ICANN wants to "standardize" it to the extent that they write a > spec that requires compliance with it, no one can prevent their > doing so, but whatever decisions they make and rules they adopt > for the use of a non-standard doesn't have much, if anything, to > do with the IETF. > > (2) Since ICANN is not a standards body and, in particular, is > not the IETF, we have no real way to real way to interpret what > "should be" or "permissible" mean. It is almost certainly not > reasonable to assume they correspond to the SHOULD and MAY of > RFC 2119. > > (3) The problems with CSV files, including issues of what to do > with too-short or too-long records and the great difficulty in > extending the format with new fields and handling information > with a variable number of subfields, are well known. Indeed, > they are well-known enough that the choice of CSV, rather than > some variety of tagged data (e.g., XML) for this type of > information should probably be described by such terms of > precise technical evaluation as "plain dumb". > > There is a considerable history of CSV files --even those that > contain header lines -- being hard to handle when revisited > after several years, especially if the data element list has > been changed for more recent versions and software updated to > match. That history is strong enough that, were someone > actively involved with ICANN reading this discussion, I think he > or she would be doing the community a favor by asking that this > issue be reopened and the format changed before we all come to > regret the CSV files. > > (4) Finally, "... no standard way to encode the > internationalized address in US-ASCII so the registrar cannot > comply with the "should be" above" seems to be to lie somewhere > between "incorrect" and a "red herring". Even without > Alt-Address, nothing prevents a user from having more than one > address, whether with aliases or alternate labels. It has been > fairly general knowledge for years that people with email > addresses structured as joe.blogs@example.com should find > something else to use in SOA record contact fields because a lot > of tools can't handle "joe\.blogs.example.com" properly. This > is really no different: if the information is to be in UTF-8, > then an non-ASCII email address might plausibly be included > (although I wouldn't recommend it until the EAI work is _very_ > widely supported). If the information is to be in ASCII, then > anyone with a non-ASCII email address will have to supply an > ASCII alias. That is certainly not a big deal in the grand > scheme of things. > > john > > > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 14 21:31:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUW7-0000vb-Pd; Wed, 14 Nov 2007 21:31:43 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsUW6-0000v2-GZ for ima-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 21:31:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUW6-0000uW-6O for ima@ietf.org; Wed, 14 Nov 2007 21:31:42 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsUW2-00015S-Ut for ima@ietf.org; Wed, 14 Nov 2007 21:31:42 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 14 Nov 2007 18:31:20 -0800 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Wed, 14 Nov 2007 18:31:38 -0800 From: Shawn Steele To: "ima@ietf.org" Date: Wed, 14 Nov 2007 18:31:29 -0800 Thread-Topic: ACE Thread-Index: AcgmtG/jP7ok+bOIRMm1Qni7n0I1CQAewhvg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {10300FD1-805F-4B52-BA8F-7DB076517959} x-cr-hashedpuzzle: Fsk= I5M= ByiW Df1p DmnE EPK8 FRcm Fyyp F4bf GNU/ GlvW HJyw HUvk JQcg JWhb JnjM; 1; aQBtAGEAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {10300FD1-805F-4B52-BA8F-7DB076517959}; cwBoAGEAdwBuAC4AcwB0AGUAZQBsAGUAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Thu, 15 Nov 2007 02:31:29 GMT;QQBDAEUA acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [EAI] ACE X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Seems to me that the simplest workaround for non-Unicode aware systems is j= ust for the user's admin to assign an ASCII alias for the user's Unicode na= me if its necessary... - Shawn _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 01:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYSn-000761-9N; Thu, 15 Nov 2007 01:44:33 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsYSl-0006zU-Td for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:44:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYSl-0006wa-G6 for ima@ietf.org; Thu, 15 Nov 2007 01:44:31 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsYSe-0007EK-JY for ima@ietf.org; Thu, 15 Nov 2007 01:44:31 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAF6iMnd012439 for ; Thu, 15 Nov 2007 15:44:22 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1171_33246efa_9346_11dc_8cb1_0014221fa3c9; Thu, 15 Nov 2007 15:44:22 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52834) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 15 Nov 2007 15:40:33 +0900 Message-Id: <6.0.0.20.2.20071115153235.08b32470@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 15 Nov 2007 15:35:24 +0900 To: Shawn Steele , "ima@ietf.org" From: Martin Duerst Subject: Re: [EAI] ACE In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 11:31 07/11/15, Shawn Steele wrote: >Seems to me that the simplest workaround for non-Unicode aware systems is >just for the user's admin to assign an ASCII alias for the user's Unicode >name if its necessary... Yes indeed. And that's already necessary for the protocol anyway, in the form of alt-address. For a company that's collecting data from customers into a system that cannot handle our new addresses (and please not that this is independent of whether the system overall can handle non-ASCII characters or not), they may just have to add a little comment ("ASCII only" or some such) near the email address field, and they will have to test internally that the address is ascii-clean. But the later is most probably already done anyway. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 01:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYSn-00077u-Fj; Thu, 15 Nov 2007 01:44:33 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsYSm-0006ze-0D for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:44:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYSl-0006wg-IG for ima@ietf.org; Thu, 15 Nov 2007 01:44:31 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsYSe-0007EF-I5 for ima@ietf.org; Thu, 15 Nov 2007 01:44:31 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAF6iLi4020924 for ; Thu, 15 Nov 2007 15:44:21 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 40ca_324777ca_9346_11dc_8e1b_0014221f2a2d; Thu, 15 Nov 2007 15:44:21 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52834) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 15 Nov 2007 15:40:31 +0900 Message-Id: <6.0.0.20.2.20071115152234.08b5cec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 15 Nov 2007 15:43:34 +0900 To: Stephane Bortzmeyer , Harald Alvestrand From: Martin Duerst Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI In-Reply-To: <20071114113120.GA30304@laperouse.bortzmeyer.org> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <20071114113120.GA30304@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello Stephane, I'm confused. You haven't made it clear whether you are pointing us to RFC 4180 to show that in some contexts, there are limitations to US-ASCII, or to show us that at least in this context, there is no issue, because it's always possible to use UTF-8. It seems that other's reading (most explicitly John's reading) is different, but for me, the text you quoted essentially reads: Use US-ASCII if you can, if not, use UTF-8. Translating into what might be the closest normative IETF language, for what it's worth, would result in something like: The character encoding for the CSV file SHOULD be US-ASCII, although UTF-8 MAY also be used. Again reading this means the same as the above. A SHOULD means: Do unless for good reasons, you can't. The next clause gives an alternative, which makes clear that "the data cannot be represented in US-ASCII" is a good reason for deviating from the SHOULD. So if you indeed wanted to use the text cited for saying "see, here's another case where we an ACE would come in handy", then I don't think you can make this point. Regards, Martin. At 20:31 07/11/14, Stephane Bortzmeyer wrote: >On Tue, Nov 13, 2007 at 09:39:05PM +0100, > Harald Alvestrand wrote > a message of 40 lines which said: > >> RFC 4180 says absolutely nothing about how email addresses are >> represented. > >I never talked about that. Please forget RFC 4180, the important part >in the ICANN documentation was: > > the > character encoding for the CSV file should be US-ASCII, although > UTF-8 is also permissible. > >> If you want UTF-8 in email addresses, you have to use an UTF-8 encoding of >> the CSV file. > >See the sentence above. > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 03:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZks-00004r-Aw; Thu, 15 Nov 2007 03:07:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsZkr-0008W8-2Y for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 03:07:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZkj-0008RS-Ix for ima@ietf.org; Thu, 15 Nov 2007 03:07:09 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsZkj-0007n6-2b for ima@ietf.org; Thu, 15 Nov 2007 03:07:09 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IsZkh-000BUI-Th; Thu, 15 Nov 2007 03:07:08 -0500 Date: Thu, 15 Nov 2007 03:07:07 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Subject: Re: [EAI] ACE Message-ID: <4F27CC33A2390664E0F3B50D@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 14 November, 2007 18:31 -0800 Shawn Steele wrote: > Seems to me that the simplest workaround for non-Unicode aware > systems is just for the user's admin to assign an ASCII alias > for the user's Unicode name if its necessary... And that conclusion, reached tentatively even before the WG was chartered, is exactly why we have Alt-Address. Given the conclusion that there will be many circumstances in which those who have non-ASCII addresses will want to have all-ASCII aliases ones available -- I believe even after every MUA, MSA, and MTA in the world is UTF8SMTP capable -- the only questions are whether that capability should be supported by in-band means (such as Alt-Address) or whether out-of-band ones (such as turning over the business card) are sufficient. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 03:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsaZc-0004hH-Ev; Thu, 15 Nov 2007 03:59:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsaZa-0004bL-Gu for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 03:59:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsaZZ-0004XL-JR for ima@ietf.org; Thu, 15 Nov 2007 03:59:41 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsaZV-0002cE-S8 for ima@ietf.org; Thu, 15 Nov 2007 03:59:41 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsaZN-00047e-1i for ima@ietf.org; Thu, 15 Nov 2007 08:59:29 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2007 08:59:29 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2007 08:59:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 15 Nov 2007 09:56:22 +0100 Lines: 16 Message-ID: References: <20071113191947.GA16028@laperouse.bortzmeyer.org><473A0B69.306@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] Re: Additional Clarification re: Need of an ACE for EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Walker wrote: > The preferred method for representing internationalized email = addresses is > in their native UTF8 format, however, if it is not possible to do so = and > an internationalized email address must be stored, communicated, or > processed by an ASCII system (all outside of the scope of actually = sending > an email) the preferred encoding method is = _____________________________. ...specified as hex. NCR in I-D.klensin-unicode-escapes. Just an idea, the Last Call for this draft ends today. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 08:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IseLb-0008If-QF; Thu, 15 Nov 2007 08:01:32 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IseLZ-0008E1-Gx for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 08:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IseLY-0008D0-QG for ima@ietf.org; Thu, 15 Nov 2007 08:01:28 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IseLV-0002Jg-Fn for ima@ietf.org; Thu, 15 Nov 2007 08:01:28 -0500 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IseLV-00024Q-5B for ima@ietf.org; Thu, 15 Nov 2007 08:01:25 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 640A713744; Thu, 15 Nov 2007 08:01:40 -0500 (EST) Date: Thu, 15 Nov 2007 08:01:40 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071115130139.GB18066@dba3> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Nov 14, 2007 at 11:27:55AM -0700, Chris Walker wrote: > The companies that have these systems may very likely upgrade their email > server software when internationalized email functionality is available > and can send and receive internationalized emails. That will not magically > allow all the other software that exists in a company that stores, > communicates, or otherwise 'sees' an email address to function properly. Right. A company that simply upgrades their mail server and says, "Ok, internationalised mail on now!" gets what they deserve. What you appear to be arguing is that we have to arrange for interoperation with every possible piece of legacy software out there You're quite right that changing the expected characters in email addresses is a Big Expensive Deal, and that it will cause pain with a lot of legacy systems. Any time you change a fundamental feature of your systems, you have this problem. And email is surely a fundamental feature of the Internet. Sorry, but making this kind of fundamental change is going to be expensive. That said, see Frank Ellerman's note on a possible way to do something like what you want. (But it's not perfect.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 09:27:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isfgc-0003ch-Sm; Thu, 15 Nov 2007 09:27:18 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Isfgb-0003a5-6r for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:27:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isfga-0003Zg-Ra for ima@ietf.org; Thu, 15 Nov 2007 09:27:16 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsfgZ-0006SZ-OF for ima@ietf.org; Thu, 15 Nov 2007 09:27:16 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IsfgY-00018H-Ij; Thu, 15 Nov 2007 09:27:14 -0500 Date: Thu, 15 Nov 2007 09:27:13 -0500 From: John C Klensin To: Chris Walker , eai list Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <95C14430286E5144A3531138@p3.JCK.COM> In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 14 November, 2007 11:27 -0700 Chris Walker wrote: > The hard cold reality on the ground is that there are > innumerable ASCII business processes in existence today. > Period. This working group cannot expect all of them to > re-engineer to 8 bit capable systems just to support new email > addresses. Chris, it seems to me that you are making up a problem that does not exist. We all know that there are innumerable ASCII business processes. We also all know that most business transactions that cross arbitrary national boundaries, especially multiparty ones, are carried out in English. This protocol work changes none of that, any more than the 1992 introduction of capability for multilingual mail required that all non-English messages be transmitted in a transliterated = form. I would expect business processes that work in ASCII over the Internet to continue to use all-ASCII addresses... forever or for as long as those processes last. To the extent to which people have native-language addresses, I would expect them to maintain ASCII aliases or ASCII-addressed mailboxes if they want to participate in those business processes. And I would expect downgrading to be used very little in these cases because the processes will continue to work as they are working today. I also expect that, if a multinational business that carries out its interoffice and internal transactions in ASCII, using ASCII content and ASCII addresses, wants to enhance its business to consumer activities in Lower Slobbovia, where few of the Lower Slobs read or write ASCII characters, I will put a large effort into localization for email communications, web sites, etc., that are used to reach and communicate with those consumers. That is just what that business does today if it expects to survive, enhanced only by the ability to advertise a localized (and national character) email address as well as accepting email via my already-localized web site. Throughout history, trying to carry on business with a population in a particular language and script that the population doesn't understand has not been an especially productive or profitable choice and, again, this work won't change that. Now, if the real question you are asking is how one transmits an email address that is defined in non-ASCII characters through some other protocol, the answers to those questions lie in those protocols. In running text in a message, we use whatever encoding would be used for that message -- reversible encodings such as Base64 for email. In something like a MAILTO URL, we know how to do the encoding because it is part of the base URL specification.=20 What we haven't done to create a standard for re-representing internationalized addresses independent of protocol. The reason is yet another symptom of the reason you are seeing resistance: W%CF%87%CF%81%CE%B9%CF%82@example.com is a perfectly valid email address. Worse, it is one that example.com might well interpret as an instruction to try to send mail to the address W%CF%87%CF%81%CE%B9%CF at host 82 (whatever that means to the server at example.com). There is no way to be sure whether the local part should be interpreted as a single address, as routing instructions, or as W=CF=87=CF=81=CE=B9=CF=82 (U+0057 U+03C7 = U+03C1 U+03B9 U+03C2). This would be true of any other encoding one tried to select. > The example above regarding postal addresses is not accurate, > transliterations of every significant non roman character > based language exist for representing those languages in roman > characters. Unfortunately, as you presumably know, while those transliterations exist, they are not guaranteed to be reversible, nor may they be obvious to native users of the original scripts. When they are used in postal mail delivery, they may result in very long delays, in part because the postal treaties do not require that they be accepted. They are also fairly useless to anyone who doesn't actively use Roman characters. Why not transliterate everything into Arabic or Hangul instead? Again, I'm trying to figure out what problem you are seeing here ... one that is not either solved by existing tools or that cannot be solved other than by saying "everyone should learn Latin (and I do mean _Latin_, not 'Roman-derived' here) or, better yet, English". That is not what this is about. It is about facilitating better communications within language communities and I just don't think that the issues you are raising are relevant if that goal is recognized as acceptable and desirable. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 15 09:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg5f-0000rw-7F; Thu, 15 Nov 2007 09:53:11 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Isg5d-0000qc-PY for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:53:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg5d-0000pM-BL for ima@ietf.org; Thu, 15 Nov 2007 09:53:09 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Isg5c-0007n0-0c for ima@ietf.org; Thu, 15 Nov 2007 09:53:08 -0500 Received: (eyou send program); Thu, 15 Nov 2007 22:52:47 +0800 Message-ID: <395138367.26128@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (189.76.105.110) by 159.226.7.146 with SMTP; Thu, 15 Nov 2007 22:52:47 +0800 Message-ID: <101001c82797$338ea330$7fd5bc79@yaojk> From: "YAO Jiankang" To: "Frank Ellermann" References: <47188369.3030909@alvestrand.no> <393215746.21132@cnnic.cn> Subject: Re: [EAI] Re: #1504: Proposed resolution - UTF8HDR 4.2: Nestedencodingsavoidable? Date: Thu, 15 Nov 2007 22:52:50 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 1.5 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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="===============0804214659==" Errors-To: ima-bounces@ietf.org --===============0804214659== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkZyYW5rIEVsbGVybWFubiIg PG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogV2Vk bmVzZGF5LCBPY3RvYmVyIDI0LCAyMDA3IDQ6NDEgUE0NClN1YmplY3Q6IFtFQUldIFJlOiAjMTUw NDogUHJvcG9zZWQgcmVzb2x1dGlvbiAtIFVURjhIRFIgNC4yOiBOZXN0ZWRlbmNvZGluZ3Nhdm9p ZGFibGU/DQoNCg0KSGFyYWxkIEFsdmVzdHJhbmQgd3JvdGU6DQoNCj4+IFNVR0dFU1RFRCBSRVNP TFVUSU9OOg0KPj4gQ29udGludWUgcGVybWl0dGluZyBuZXN0ZWQgZW5jb2RpbmdzLiBJbXByb3Zl IHRoZSBsYW5ndWFnZSA+PnNsaWdodGx5Lg0KDQo+T2theSwgSSB0aGluayB5b3UgY2FuIHBlcm1p dCBpdC4gIEJ1dCBJJ20gbm90IGhhcHB5IHdpdGggdGhlIHdheSBob3cgPnlvdQ0KPnByb3Bvc2Ug dG8gZG8gaXQ6DQoNCmZvciBtZSwgIG5vIG9iamVjdGlvbiB0byBwZXJtaXR0aW5nIG5lc3RlZCBl bmNvZGluZ3MuDQoNCiBJIHRoaW5rIHRoYXQgSGFyYWxkIHN1bW1hcml6ZXMgc29tZSBkZXNpZ24g dGVhbSBtZW1iZXIncyBvcHRpb25zLg0KDQpZQU8gSmlhbmthbmcNCkNOTklDDQogDQo= --===============0804214659== 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 --===============0804214659==-- From ima-bounces@ietf.org Thu Nov 15 12:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiJ0-0004r4-9F; Thu, 15 Nov 2007 12:15:06 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsiIx-0004lP-7l for ima-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiIw-0004jj-MV; Thu, 15 Nov 2007 12:15:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsiIw-00078n-AM; Thu, 15 Nov 2007 12:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 365252AC6F; Thu, 15 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsiIv-0001xw-Ui; Thu, 15 Nov 2007 12:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 12:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-09.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-09.txt Pages : 21 Date : 2007-11-15 This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15110851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15110851.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Nov 16 04:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxwN-00052s-PG; Fri, 16 Nov 2007 04:56:47 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsxwM-00050A-Ia for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:56:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxwM-0004zL-6b for ima@ietf.org; Fri, 16 Nov 2007 04:56:46 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsxwL-0003L9-5W for ima@ietf.org; Fri, 16 Nov 2007 04:56:46 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 37-md50000000072.tmp for ; Fri, 16 Nov 2007 02:59:25 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Fri, 16 Nov 2007 02:59:25 -0700 Date: Fri, 16 Nov 2007 02:59:25 -0700 From: "Chris Walker" To: "John C Klensin" , "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <95C14430286E5144A3531138@p3.JCK.COM> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Fri, 16 Nov 2007 02:59:25 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 John, It isn't an imagined problem, it's a real one. That's why I'm here. Many large corporations do a lot of work with business partners, other corporations, and as such have data flowing into their systems that originates in numerous locations out of their control. Example: User Alice fills out a web form on company X website for some reason or another, and one of the data fields is her email address, company X accepts a raw UTF8 email address e.g. NON ASCII@NON ASCII. Now depending on whar Alice entered in the form, company X may send that data to company Y (or company Z). The mechanism that companies X and Y have is place to do this is ASCII. In this extraordinarily simple example, how does company X communicate the email address to company Y? Should Alice know to have an ASCII email address and to use that one? If Alice is an establised customer of company Y, and has a saved profile with a non ASCII address, and that is used for transmission to company Y, there may not be a data entry field for Alice to fill out on her web form. Again this is a very simple example, in many cases, supply chains for example, the data flow is though numerous companies and back again. In order fulfillment, the orginal order may be split into several sub orders for be fulfilled by numerous companies. Email notification is a common feature of order processing. Ask yourself "Where does data flow?", in these situations, an email address is just another piece of data. A piece a data that has the very unfortunate characteristic of no standard ASCII encoding. Modifying every ASCII system that sees email addresses to handle UTF8 will make the cost and effort of widening date fields to hold four digit years look like childs play. In all probability two dominate solutions will emerge, a multitude of incompatable encodings which over time will corrupt the data quality of databases that store email addresses, or just throwing the data away when it hits an ASCII system. All in all, this burden will be a huge impediment to adoption of EAI as it stands now. Chris -----Original Message----- From: John C Klensin To: Chris Walker , eai list Date: Thu, 15 Nov 2007 09:27:13 -0500 Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > > > --On Wednesday, 14 November, 2007 11:27 -0700 Chris Walker > wrote: > > > The hard cold reality on the ground is that there are > > innumerable ASCII business processes in existence today. > > Period. This working group cannot expect all of them to > > re-engineer to 8 bit capable systems just to support new email > > addresses. > > Chris, it seems to me that you are making up a problem that does > not exist. We all know that there are innumerable ASCII > business processes. We also all know that most business > transactions that cross arbitrary national boundaries, > especially multiparty ones, are carried out in English. This > protocol work changes none of that, any more than the 1992 > introduction of capability for multilingual mail required that > all non-English messages be transmitted in a transliterated form. > > I would expect business processes that work in ASCII over the > Internet to continue to use all-ASCII addresses... forever or > for as long as those processes last. To the extent to which > people have native-language addresses, I would expect them to > maintain ASCII aliases or ASCII-addressed mailboxes if they want > to participate in those business processes. And I would expect > downgrading to be used very little in these cases because the > processes will continue to work as they are working today. > > I also expect that, if a multinational business that carries out > its interoffice and internal transactions in ASCII, using ASCII > content and ASCII addresses, wants to enhance its business to > consumer activities in Lower Slobbovia, where few of the Lower > Slobs read or write ASCII characters, I will put a large effort > into localization for email communications, web sites, etc., > that are used to reach and communicate with those consumers. > That is just what that business does today if it expects to > survive, enhanced only by the ability to advertise a localized > (and national character) email address as well as accepting > email via my already-localized web site. Throughout history, > trying to carry on business with a population in a particular > language and script that the population doesn't understand has > not been an especially productive or profitable choice and, > again, this work won't change that. > > Now, if the real question you are asking is how one transmits an > email address that is defined in non-ASCII characters through > some other protocol, the answers to those questions lie in those > protocols. In running text in a message, we use whatever > encoding would be used for that message -- reversible encodings > such as Base64 for email. In something like a MAILTO URL, we > know how to do the encoding because it is part of the base URL > specification. > > What we haven't done to create a standard for re-representing > internationalized addresses independent of protocol. The reason > is yet another symptom of the reason you are seeing resistance: > W%CF%87%CF%81%CE%B9%CF%82@example.com is a perfectly valid email > address. Worse, it is one that example.com might well interpret > as an instruction to try to send mail to the address > W%CF%87%CF%81%CE%B9%CF at host 82 (whatever that means to the > server at example.com). There is no way to be sure whether the > local part should be interpreted as a single address, as routing > instructions, or as Wχρις (U+0057 U+03C7 U+03C1 U+03B9 > U+03C2). This would be true of any other encoding one tried to > select. > > > The example above regarding postal addresses is not accurate, > > transliterations of every significant non roman character > > based language exist for representing those languages in roman > > characters. > > Unfortunately, as you presumably know, while those > transliterations exist, they are not guaranteed to be > reversible, nor may they be obvious to native users of the > original scripts. When they are used in postal mail delivery, > they may result in very long delays, in part because the postal > treaties do not require that they be accepted. They are also > fairly useless to anyone who doesn't actively use Roman > characters. Why not transliterate everything into Arabic or > Hangul instead? > > Again, I'm trying to figure out what problem you are seeing here > ... one that is not either solved by existing tools or that > cannot be solved other than by saying "everyone should learn > Latin (and I do mean _Latin_, not 'Roman-derived' here) or, > better yet, English". That is not what this is about. It is > about facilitating better communications within language > communities and I just don't think that the issues you are > raising are relevant if that goal is recognized as acceptable > and desirable. > > john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 05:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyaH-00017g-0u; Fri, 16 Nov 2007 05:38:01 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsyaG-00014v-2t for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:38:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyaF-000147-Og for ima@ietf.org; Fri, 16 Nov 2007 05:37:59 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsyaF-00062F-9H for ima@ietf.org; Fri, 16 Nov 2007 05:37:59 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 0E4CC4AC8F; Fri, 16 Nov 2007 11:38:09 +0100 (CET) Message-Id: Date: Fri, 16 Nov 2007 11:38:35 +0100 From: Arnt Gulbrandsen To: eai list Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 It's a real problem and occurs in many guises. Another variant is that for a long time, my postal address was not pure ASCII. More than once, someone attempted to verify that the address existed, was correct, or that a credit card was OK, and the check failed. I venture to suggest that the problem is as old as electronic data processing, and that if EAI has to solve even just the email address part of the problem, EAI won't conclude at all. Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 05:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyuT-0004Sk-2w; Fri, 16 Nov 2007 05:58:53 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IsyuR-0004Pm-VF for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:58:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyuR-0004PU-Kd for ima@ietf.org; Fri, 16 Nov 2007 05:58:51 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsyuR-00078a-9Y for ima@ietf.org; Fri, 16 Nov 2007 05:58:51 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 17-md50000000073.tmp for ; Fri, 16 Nov 2007 04:01:28 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Fri, 16 Nov 2007 04:01:28 -0700 Date: Fri, 16 Nov 2007 04:01:28 -0700 From: "Chris Walker" To: "eai list" Message-ID: X-Mailer: WorldClient 6.8.5 X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Fri, 16 Nov 2007 04:01:28 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] A potential collision free local part ACE ID X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, Didn't you write in RFC 3696 the following: Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters ! # $ % & ' * + - / = ? ^ _ ` . { | } ~ period (".") may also appear, but may not be used to start or end the local part, nor may two or more consecutive periods appear. _____________________________________________ If this is correct, a local part in the form .joebloggs is not legal, and an ACE identifier could use that namespace, as in: .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp Where .yn-- is the identifier that indicates an ASCII encoded local part. Per RFC 3696 .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp can not be a valid email address, is this correct? Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 06:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz6d-0007ts-9t; Fri, 16 Nov 2007 06:11:27 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Isz6c-0007sH-FH for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:11:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz6c-0007qa-2K for ima@ietf.org; Fri, 16 Nov 2007 06:11:26 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isz6b-0008Ie-HP for ima@ietf.org; Fri, 16 Nov 2007 06:11:25 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Isz6a-0001y0-CV; Fri, 16 Nov 2007 06:11:24 -0500 Date: Fri, 16 Nov 2007 06:11:23 -0500 From: John C Klensin To: Chris Walker , eai list Subject: Re: [EAI] A potential collision free local part ACE ID Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.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 --On Friday, 16 November, 2007 04:01 -0700 Chris Walker wrote: > > > John, > > Didn't you write in RFC 3696 the following: > > Without quotes, local-parts may consist of any combination > of alphabetic characters, digits, or any of the special > characters > > ! # $ % & ' * + - / = ? ^ _ ` . { | } ~ > > period (".") may also appear, but may not be used to start > or end the local part, nor may two or more consecutive > periods appear. >... >> If this is correct, a local part in the form .joebloggs is not >> legal, and an ACE identifier could use that namespace, as in: >> >> .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp >> Yes, I probably did. But 3696 is not a standard. More important is that "without quotes" part. While we give mail system operators the advice to avoid creating local-part addresses that require quoting (largely because the quotes get lost or fouled up sometimes), nothing prevents them from doing so. In particular, while I don't know if it still exists in the wild, I knew a system some years ago that used to embed file paths in addresses by startng them with periods and considered the fact that many unknown and potentially hostile systems would trash such addresses to be an advantage. Conversely, and perhaps more important, the fact that this form is treated as invalid makes it inappropriate for use as a transparent ACE because precisely the legacy systems you are concerned about will tell to reject it in transit. Because it is a syntax error, rejecting it in transit doesn't even violate the "don't tamper with the local-part" rule. Other systems, citing the robustness principle, will accept it anyway and treat it as an address rather than an ACE. Finally, I don't want to be the one who tells an end user that, despite the fact that she thinks her email address is something intelligible in her normal language and script, her real address, which she needs to give her friends who don't use that script, is .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp I suspect you don't either. Sorry, but I don't think this works. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 06:14:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz9o-0006KQ-1P; Fri, 16 Nov 2007 06:14:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Isz9n-0006JQ-AJ for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:14:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz9m-0006GH-Up for ima@ietf.org; Fri, 16 Nov 2007 06:14:42 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isz9i-0003Um-Ni for ima@ietf.org; Fri, 16 Nov 2007 06:14:42 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew*man$ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.262) id 473d7b9c.133e5.33 for ima@ietf.org; Fri, 16 Nov 2007 11:14:36 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id lAGBEaQ9002614 for ; Fri, 16 Nov 2007 11:14:37 GMT To: IMA Subject: Re: [EAI] Re: Additional Clarification re: Need of an ACE for EAI References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> Message-ID: Date: Fri, 16 Nov 2007 11:14:36 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: -1.0 (-) 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 Thu, 15 Nov 2007 08:56:22 -0000, Frank Ellermann wrote: > Chris Walker wrote: > >> The preferred method for representing internationalized email addresses >> is >> in their native UTF8 format, however, if it is not possible to do so and >> an internationalized email address must be stored, communicated, or >> processed by an ASCII system (all outside of the scope of actually >> sending >> an email) the preferred encoding method is >> _____________________________. > > ...specified as hex. NCR in I-D.klensin-unicode-escapes. Just an idea, > the Last Call for this draft ends today. But you need some notation to introduce that hex, so people know that it needs to be unscrambled. But we already have such a, notation that works _now_, namely the mailto: URL (which you can also translate to/from an IRI if you wish when crossing a UTF-8/ASCII boundary. -- CharlesH.Lindsey---------AtHome,doingmyownthing------------------------ Tel:+441614366131 Web:http://www.cs.man.ac.uk/~chl Email:chl@clerew.man.ac.ukSnail:5ClerewoodAve,CHEADLE,SK83JU,U.K. PGP:2C15F1A9Fingerprint:736DC25193A001E765E8647E14A4ABA5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 07:24:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It0FX-0005I9-AU; Fri, 16 Nov 2007 07:24:43 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It0FW-0005HS-8n for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 07:24:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It0FV-0005HK-Tj for ima@ietf.org; Fri, 16 Nov 2007 07:24:41 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It0FV-0004Eh-5q for ima@ietf.org; Fri, 16 Nov 2007 07:24:41 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 21-md50000000074.tmp for ; Fri, 16 Nov 2007 05:27:18 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Fri, 16 Nov 2007 05:27:17 -0700 Date: Fri, 16 Nov 2007 05:27:17 -0700 From: "Chris Walker" To: "John C Klensin" , "eai list" Subject: Re: [EAI] A potential collision free local part ACE ID Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: References: X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Fri, 16 Nov 2007 05:27:18 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 The form .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp is not for submission to an email system, it is only for use in ASCII data proccing systems, it would have to be converted back to UTF8 to be submitted to a mail system. The .yn-- signals to the system that is transistioning from ASCII to UTF8 that the local part needs to be decoded back to UTF8. if .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp is not restrictive enough how about any of the following, none of which should be legal. .yn--someasciiencoding--yn.@xn--hxajbheg2az3al.xn--jxalpdlp ..yn--someasciiencoding--yn..@xn--hxajbheg2az3al.xn--jxalpdlp ...yn--someasciiencoding--yn...@xn--hxajbheg2az3al.xn--jxalpdlp And as I'm sure you are aware in reference to your comment about quoted local parts, ".joebloggs" does not start with a period character, it starts with a double quote character. Again none of these forms are suitable for submitting to any type of mail server. They just represent a internationalized email address when the address is considered data in a data processing system. We just need an ACE identifiter that can't exist in a real email address, to determine that a value needs decoding. If none of these forms seem safe then finally the form yn-- JiM5NjA7JiM5NDU7JiM5NjE7JiM5NDA7JiM5NDg7JiM5NDk7JiM5NTM7JiM5NDc7JiM5NTY7J iM5NDU7QCYjOTYwOyYjOTQ1OyYjOTYxOyYjOTQwOyYjOTQ4OyYjOTQ5OyYjOTUzOyYjOTQ3Oy YjOTU2OyYjOTQ1Oy4mIzk0ODsmIzk1OTsmIzk1NDsmIzk1MzsmIzk1NjsmIzk0MjsgIA== Where the ENTIRE email address including the local part, the @ sign, and the domain part, with an encoding system that does not use the @ sign in the encoded output, such as base64, would result in an encoding that in no way could collide with a real email address. Chris -----Original Message----- From: John C Klensin To: Chris Walker , eai list Date: Fri, 16 Nov 2007 06:11:23 -0500 Subject: Re: [EAI] A potential collision free local part ACE ID > > > --On Friday, 16 November, 2007 04:01 -0700 Chris Walker > wrote: > > > > > > > John, > > > > Didn't you write in RFC 3696 the following: > > > > Without quotes, local-parts may consist of any combination > > of alphabetic characters, digits, or any of the special > > characters > > > > ! # $ % & ' * + - / = ? ^ _ ` . { | } ~ > > > > period (".") may also appear, but may not be used to start > > or end the local part, nor may two or more consecutive > > periods appear. > >... > > >> If this is correct, a local part in the form .joebloggs is not > >> legal, and an ACE identifier could use that namespace, as in: > >> > >> .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp > >> > > Yes, I probably did. But 3696 is not a standard. More > important is that "without quotes" part. While we give mail > system operators the advice to avoid creating local-part > addresses that require quoting (largely because the quotes get > lost or fouled up sometimes), nothing prevents them from doing > so. > > In particular, while I don't know if it still exists in the > wild, I knew a system some years ago that used to embed file > paths in addresses by startng them with periods and considered > the fact that many unknown and potentially hostile systems would > trash such addresses to be an advantage. > > Conversely, and perhaps more important, the fact that this form > is treated as invalid makes it inappropriate for use as a > transparent ACE because precisely the legacy systems you are > concerned about will tell to reject it in transit. Because it > is a syntax error, rejecting it in transit doesn't even violate > the "don't tamper with the local-part" rule. Other systems, > citing the robustness principle, will accept it anyway and treat > it as an address rather than an ACE. > > Finally, I don't want to be the one who tells an end user that, > despite the fact that she thinks her email address is something > intelligible in her normal language and script, her real > address, which she needs to give her friends who don't use that > script, is > .yn--someasciiencoding@xn--hxajbheg2az3al.xn--jxalpdlp > > I suspect you don't either. > > Sorry, but I don't think this works. > > john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 09:29:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2CY-0002jI-P7; Fri, 16 Nov 2007 09:29:46 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It2CX-0002h6-LX for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:29:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2CX-0002ft-7c for ima@ietf.org; Fri, 16 Nov 2007 09:29:45 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2CT-0006Sy-L2 for ima@ietf.org; Fri, 16 Nov 2007 09:29:45 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1It2CS-0009gQ-LS; Fri, 16 Nov 2007 09:29:41 -0500 Date: Fri, 16 Nov 2007 09:29:39 -0500 From: John C Klensin To: Chris Walker , eai list Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <57461FEE10B88691128F22A4@p3.JCK.COM> In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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, 16 November, 2007 02:59 -0700 Chris Walker wrote: > John, > > It isn't an imagined problem, it's a real one. That's why I'm > here. >.... Chris, I have lots of experience with the problem you describe. It is quite real, and I tried to carefully avoid saying anything else. The imaginary one is only about assuming that the business partners, who have been using ASCII all along, will suddenly insist on using internationalized email addresses. There is a slightly different problem when those business partners are dealing with their customers. But almost no one is using email any longer to send and receive commercial transactions directly, nothing prevents a company from insisting on an ASCII address (or an ASCII ALT-ADDRESS) on a web page (note that legacy web pages will almost certainly not accept non-ASCII characters- we have enough trouble getting them to accept "+", "=", and "/"). > Many large corporations do a lot of work with business > partners, other corporations, and as such have data flowing > into their systems that originates in numerous locations out > of their control. > > Example: User Alice fills out a web form on company X website > for some reason or another, and one of the data fields is her > email address, company X accepts a raw UTF8 email address > e.g. NON ASCII@NON ASCII. Now depending on whar Alice entered > in the form, company X may send that data to company Y (or > company Z). The mechanism that companies X and Y have is > place to do this is ASCII. If company X permits an non-ASCII address, doesn't get an Alt-Address, and has no theory about how to communicate that address to company Y, then it is, in fact, in trouble. But the same problem occurs in the general case with postal addresses that are entirely in non-Latin characters: the postal treaties _do not_ require that countries accept transliterations on anything that goes inside a bag to an international reception point, bags that are labeled using ISO 3166 codes, not ASCII country names. However, they do have a way to transmit such email addresses. They put them into mailto URLs using %HH encoding. There is, however, one additional thing they need to do and it is why this is inappropriate for standardization: company X and Y have to agree that their mail systems will never accept an address from a customer with multiple "%" signs in it. Since the routing that is normally implied by "%" is now considered a bad and dangerous practice, that shouldn't be a big deal. Or they could adopt some other convention and adjust their procedures so that a different character that _they_ (specifically Company X in its web interface) prohibit in mail addresses was used as an indicator that the local part was encoded and needed to be decoded. I'm not suggesting that these addresses can't be encoded in special circumstances, only that using encoding instead of directly represented (in UTF-8) addresses won't work for the most general cases and consequently can't be standardized. > In this extraordinarily simple example, how does company X > communicate the email address to company Y? Should Alice know > to have an ASCII email address and to use that one? If Alice > is an establised customer of company Y, and has a saved > profile with a non ASCII address, and that is used for > transmission to company Y, there may not be a data entry field > for Alice to fill out on her web form. If company Y has stored a non-ASCII address for Alice and is not prepared to receive a non-ASCII address for her from company X which nonetheless accepts that address from their web forms, then someone is being extraordinarily stupid. Remember that company X must choose to accept a non-ASCII address to have an address to transmit to Company Y. If it can't, or won't, it should, indeed, insist that Alice provide an ASCII-only address. The latter is something I expect to happen regularly for some years, even if only by legacy web pages generating "not a valid address" messages when they see non-ASCII characters. > Again this is a very simple example, in many cases, supply > chains for example, the data flow is though numerous > companies and back again. In order fulfillment, the orginal > order may be split into several sub orders for be fulfilled > by numerous companies. Email notification is a common feature > of order processing. Same comments. I think you should look at the EDI standards in international use and how they handle (or don't handle) selected non-ASCII data. For a competent business enterprise, no data field is "just another piece of data". Phone numbers are validated to make sure that, possibly modulo "+" and well-known separators, they are all-numeric. Dates are validated to make sure that no one is born in the 14th months. And so on. The long supply chains you describe have long-ago learned to do those sorts of validation and insist on it from their partners because, otherwise, chaos results. If someone is going to accept a non-ASCII email address, they will need to obtain upstream agreements about how to process them, and that is true whether the address is passed along in UTF-8 or mapped, by mutual agreement, to an encoded form or alternate representation. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 10:14:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2tL-0002c0-Go; Fri, 16 Nov 2007 10:13:59 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It2tK-0002ad-RA for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:13:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2tK-0002aO-HR for ima@ietf.org; Fri, 16 Nov 2007 10:13:58 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2tH-0001xU-92 for ima@ietf.org; Fri, 16 Nov 2007 10:13:58 -0500 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1It2tH-0001wz-0e for ima@ietf.org; Fri, 16 Nov 2007 10:13:55 -0500 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id 9EDA73B208E; Fri, 16 Nov 2007 10:15:53 -0500 (EST) Date: Fri, 16 Nov 2007 10:15:53 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] A potential collision free local part ACE ID Message-ID: <20071116151553.GD14436@afilias.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Nov 16, 2007 at 05:27:17AM -0700, Chris Walker wrote: > is not for submission to an email system, it is only for use in ASCII > data proccing systems, it would have to be converted back to UTF8 to be > submitted to a mail system. The way I remember it, xn--CCCCCC wasn't for user presentation, and had to be converted back to UTF8 to be presented to the user, too. That worked out splendidly. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 11:20:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3vo-0003Rq-Kv; Fri, 16 Nov 2007 11:20:36 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It3vl-0003O7-7X for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:20:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3vk-0003Na-S3; Fri, 16 Nov 2007 11:20:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3vk-0006we-Eu; Fri, 16 Nov 2007 11:20:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1EA51175E4; Fri, 16 Nov 2007 16:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It3vF-00005p-LQ; Fri, 16 Nov 2007 11:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Nov 2007 11:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-dsn-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : International Delivery and Disposition Notifications Author(s) : C. Newman, A. Melnikov Filename : draft-ietf-eai-dsn-05.txt Pages : 19 Date : 2007-11-16 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-16111628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16111628.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Nov 16 15:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7ZY-00080I-PT; Fri, 16 Nov 2007 15:13:52 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It7ZX-0007x3-6V for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:13:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7ZW-0007wQ-Rd for ima@ietf.org; Fri, 16 Nov 2007 15:13:50 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It7ZW-0007RZ-DP for ima@ietf.org; Fri, 16 Nov 2007 15:13:50 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 45-md50000000082.tmp for ; Fri, 16 Nov 2007 13:16:32 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Fri, 16 Nov 2007 13:16:32 -0700 Date: Fri, 16 Nov 2007 13:16:32 -0700 From: "Chris Walker" To: ima@ietf.org Subject: Re: [EAI] A potential collision free local part ACE ID Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <20071116151553.GD14436@afilias.info> References: <20071116151553.GD14436@afilias.info> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Fri, 16 Nov 2007 13:16:32 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org -----Original Message----- From: Andrew Sullivan To: ima@ietf.org Date: Fri, 16 Nov 2007 10:15:53 -0500 Subject: Re: [EAI] A potential collision free local part ACE ID > On Fri, Nov 16, 2007 at 05:27:17AM -0700, Chris Walker wrote: > > > is not for submission to an email system, it is only for use in ASCII > > data proccing systems, it would have to be converted back to UTF8 to > be > > submitted to a mail system. > > The way I remember it, xn--CCCCCC wasn't for user presentation, and had > to be > converted back to UTF8 to be presented to the user, too. The major difference, IDNA was designed and intended to work at the user interface level. ACE encoding of an internationalized email address is not for use at the user interface level, and not for use as a form that is accepted by SMTP or UTF8SMTP. >That worked> out splendidly. Well, it can also be argued that IDNA IS WORKING, TODAY, RIGHT NOW; which if every DNS client and DNS itself had to be re-implementeed as 8bit systems, it wouldn't be. IDNA also transits non DNS systems as easily as it transits the DNS system, offering virtually no resistance to it's adoption by business. > A > > -- > Andrew Sullivan 204-4141 Yonge Street > Afilias Canada Toronto, Ontario Canada > M2P 2A8 > jabber: ajsaf@jabber.org +1 416 646 3304 x4110 > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 15:32:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7rz-0006TS-7y; Fri, 16 Nov 2007 15:32:55 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It7ry-0006TN-JO for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 15:32:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7ry-0006TF-3b for ima@ietf.org; Fri, 16 Nov 2007 15:32:54 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It7ru-0000PC-E6 for ima@ietf.org; Fri, 16 Nov 2007 15:32:53 -0500 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1It7ru-0005qx-2h for ima@ietf.org; Fri, 16 Nov 2007 15:32:50 -0500 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id 48CEB3B299B; Fri, 16 Nov 2007 15:34:41 -0500 (EST) Date: Fri, 16 Nov 2007 15:34:41 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] A potential collision free local part ACE ID Message-ID: <20071116203440.GP14436@afilias.info> References: <20071116151553.GD14436@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear colleagues, On Fri, Nov 16, 2007 at 01:16:32PM -0700, Chris Walker wrote: > The major difference, IDNA was designed and intended to work at the user > interface level. Yes, but it was also intended not to be human-readable. There are certainly differences, but I think there's enough analogy that we ought to take that experience into consideration. > ACE encoding of an internationalized email address is not for use at the > user interface level, and not for use as a form that is accepted by SMTP > or UTF8SMTP. Agreed, but it seems to me that we'll have a hard time communicating that to people who still think that filtering for four-character TLDs is ok, or people who think that the solution to English-speaking "intransigence" over internationalization is to run an alternate root. My view is that ACE is the newest Internet walled garden: it _will_ leak, and the question is merely how annoying the consequences will be. It'd be better not to have it at all, in the long run. ASCII-only is an unfortunate historical problem to be overcome, not a base state of encoding to which we must always be compatible. > Well, it can also be argued that IDNA IS WORKING, TODAY, RIGHT NOW; Yes-ish. I can tell you from some bitter personal experience that this is only for some values of "working". From the point of view of many users, it has not worked well. See John Klensin's comments up thread. In particular. . . > 8bit systems, it wouldn't be. IDNA also transits non DNS systems as > easily as it transits the DNS system, offering virtually no resistance > to it's adoption by business. . . .that "no resistance" is merely "no technical resistance". As it turns out, that ease of technical implementation (which I still think was not a bad decision, please note) has meant all sorts of other business considerations. Some of those have been at least awkward to deal with. (There are other internationalization problems that the ASCII-only world has had to accept, as well, which may not be entailments of the ACE approach. I'm not talking about that right now.) I think my remarks are probably becoming repetitive, so this is the last I'll post in this thread. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 16:18:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8Zm-00016x-08; Fri, 16 Nov 2007 16:18:10 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1It8Zk-0000xb-9X for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 16:18:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8Zj-0000vp-Pk for ima@ietf.org; Fri, 16 Nov 2007 16:18:07 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It8Zi-0001md-Kv for ima@ietf.org; Fri, 16 Nov 2007 16:18:07 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 61-md50000000083.tmp for ; Fri, 16 Nov 2007 14:20:46 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Fri, 16 Nov 2007 14:20:46 -0700 Date: Fri, 16 Nov 2007 14:20:46 -0700 From: "Chris Walker" To: "John C Klensin" , "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <57461FEE10B88691128F22A4@p3.JCK.COM> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Fri, 16 Nov 2007 14:20:46 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 -----Original Message----- From: John C Klensin To: Chris Walker , eai list Date: Fri, 16 Nov 2007 09:29:39 -0500 Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > > > --On Friday, 16 November, 2007 02:59 -0700 Chris Walker > wrote: > > > John, > > > > It isn't an imagined problem, it's a real one. That's why I'm > > here. > >.... > > Chris, I have lots of experience with the problem you describe. > It is quite real, and I tried to carefully avoid saying anything > else. > > The imaginary one is only about assuming that the business > partners, who have been using ASCII all along, will suddenly > insist on using internationalized email addresses. Yes, you are right, it will probably be the customers of a company insisting on the use of internationalized email addresses. > > There is a slightly different problem when those business > partners are dealing with their customers. But almost no one is > using email any longer to send and receive commercial > transactions directly, What does this have to do with "sending comercial transactions directly" over email, this is a strawman argument. > nothing prevents a company from insisting > on an ASCII address (or an ASCII ALT-ADDRESS) on a web page > (note that legacy web pages will almost certainly not accept > non-ASCII characters- we have enough trouble getting them to > accept "+", "=", and "/"). > If EAI is ever going to enjoy widespread use and popularity, web pages will have to accept UTF8 email addresses. People will have to have a resonable expectation that if they supply a UTF8 email address and it is accepted by some entity that they will actually receive email from that entity at that address. EAI has an opportunity to correct the ills of the past regarding acceptance of "+", "=", and "/" if the work product of this group was more vocal on user interface, interoperability issues, and practices that involve EAI beyond the UTF8SMTP wire. The tunnel- vision view that EAI can be 'solved' by only dealing with the email client server protocol is only a subset of wider set of issues. > > Many large corporations do a lot of work with business > > partners, other corporations, and as such have data flowing > > into their systems that originates in numerous locations out > > of their control. > > > > Example: User Alice fills out a web form on company X website > > for some reason or another, and one of the data fields is her > > email address, company X accepts a raw UTF8 email address > > e.g. NON ASCII@NON ASCII. Now depending on whar Alice entered > > in the form, company X may send that data to company Y (or > > company Z). The mechanism that companies X and Y have is > > place to do this is ASCII. > > If company X permits an non-ASCII address, doesn't get an > Alt-Address, and has no theory about how to communicate that > address to company Y, then it is, in fact, in trouble. But the > same problem occurs in the general case with postal addresses > that are entirely in non-Latin characters: the postal treaties > _do not_ require that countries accept transliterations on > anything that goes inside a bag to an international reception > point, bags that are labeled using ISO 3166 codes, not ASCII > country names. > In the general case, there are alternatives to representing a UTF8 postal address, namely transliteration, and there is a well established history and expectation that the non UTF8 version will transit international systems, including ASCII, and will still be useable to deliver mail. Even if a user supplies their postal address to an entity in native UTF8, that address can be transliterated by the entity before transmission to another party. This transliteration is standardized. UTF8 email address enjoy no similar standard. > However, they do have a way to transmit such email addresses. > They put them into mailto URLs using %HH encoding. There is, > however, one additional thing they need to do and it is why this > is inappropriate for standardization: company X and Y have to > agree that their mail systems will never accept an address from > a customer with multiple "%" signs in it. Since the routing > that is normally implied by "%" is now considered a bad and > dangerous practice, that shouldn't be a big deal. Or they > could adopt some other convention and adjust their procedures so > that a different character that _they_ (specifically Company X > in its web interface) prohibit in mail addresses was used as an > indicator that the local part was encoded and needed to be > decoded. "> company X and Y have to > agree that their mail systems will never accept an address from > a customer with multiple "%" signs in it." Well now we are getting to the meat of the problem. Passing the buck. Just how many of these 'agreements' will be needed? How many possible combinations of interactions are there if only 10 companies existed in the entire world? If the interaction is only between two parties, then each of the 10 companies could have an agreement with the other 9, 10 x 9 = 90. The number of paths that traverse all 10 companies is 10! = 1 x 2 x 3 x 4 x 5 x 6 x 7 x 8 x 9 x 10 = 3,628,800. >"Or they could adopt some other convention". The avoidance of this is why standardization exists. > > I'm not suggesting that these addresses can't be encoded in > special circumstances, only that using encoding instead of > directly represented (in UTF-8) addresses won't work for the > most general cases and consequently can't be standardized. What do you consider special and general circumstances? Auguing that an international email address encoding can't be standardized is like arguing that internatioinalized domain name encoding can't be standardized. Except it's a losing argument, since it already has been standardized. > > > In this extraordinarily simple example, how does company X > > communicate the email address to company Y? Should Alice know > > to have an ASCII email address and to use that one? If Alice > > is an establised customer of company Y, and has a saved > > profile with a non ASCII address, and that is used for > > transmission to company Y, there may not be a data entry field > > for Alice to fill out on her web form. > > If company Y has stored a non-ASCII address for Alice and is not > prepared to receive a non-ASCII address for her from company X > which nonetheless accepts that address from their web forms, > then someone is being extraordinarily stupid. Remember that > company X must choose to accept a non-ASCII address to have an > address to transmit to Company Y. If it can't, or won't, it > should, indeed, insist that Alice provide an ASCII-only address. > The latter is something I expect to happen regularly for some > years, even if only by legacy web pages generating "not a valid > address" messages when they see non-ASCII characters. Again more burden and passing the buck, this time to Alice. Poor Alice who would love to have just her internationalized email address, but can't. She needs two addresses, an ASCII one in addition to her UTF8 one. She has to check email in multiple places, and since there is so little reliability of actually getting any email at her UTF8 address from any company, she considers the UTF8 one a novelty that only a few close friends (actual humans) use. If Alice grows tired of checking her email in two places, which one will she abandon? > > > Again this is a very simple example, in many cases, supply > > chains for example, the data flow is though numerous > > companies and back again. In order fulfillment, the orginal > > order may be split into several sub orders for be fulfilled > > by numerous companies. Email notification is a common feature > > of order processing. > > Same comments. I think you should look at the EDI standards in > international use and how they handle (or don't handle) selected > non-ASCII data. I think you should consider that a fraction of actual supply chain like systems actually use EDI. > > For a competent business enterprise, no data field is "just > another piece of data". Phone numbers are validated to make > sure that, possibly modulo "+" and well-known separators, they > are all-numeric. Dates are validated to make sure that no one > is born in the 14th months. And so on. The long supply chains > you describe have long-ago learned to do those sorts of > validation and insist on it from their partners because, > otherwise, chaos results. If someone is going to accept a > non-ASCII email address, they will need to obtain upstream > agreements about how to process them, and that is true whether > the address is passed along in UTF-8 or mapped, by mutual > agreement, to an encoded form or alternate representation. > Validation and encoding are two seperate proccesses and issues, encoding does not perform validation, and validation does not perform encoding. chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 19:11:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItBHr-0000V4-8X; Fri, 16 Nov 2007 19:11:51 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItBHp-0000O6-Gm for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 19:11:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItBHp-0000Me-5W for ima@ietf.org; Fri, 16 Nov 2007 19:11:49 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItBHm-0008Bq-KJ for ima@ietf.org; Fri, 16 Nov 2007 19:11:47 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAH0Bhox005311 for ; Sat, 17 Nov 2007 09:11:43 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0c02_ad8ee380_94a1_11dc_8515_0014221fa3c9; Sat, 17 Nov 2007 09:11:43 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:45742) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 17 Nov 2007 09:07:51 +0900 Message-Id: <6.0.0.20.2.20071116194233.080b1e40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 16 Nov 2007 19:52:29 +0900 To: "Chris Walker" , "John C Klensin" , "eai list" From: Martin Duerst Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Hello Chris, I think John and Harald and others have already tried, but I'll try again. I think we understand your scenario, and we know it's real. But what is at least as real, and more importantly, already possible/happening, is the same problem with names and addresses. Please take a moment and rewrite your text below and replace "email address" with "person's name", or "customer's street address", or any such. What you will see is that: 1) The problem already exists. 2) If companies haven't handled the problem for name or address, they are already having problems. If they have handled it, they should be able to handle it for email addresses, too. BTW, I happen to speak out of experience. My name, in fully correct spelling, contains an u-umlaut, in ASCII, the closest you can get is something like Du"rst. For most forms, I just enter Duerst. When I (re)joined the ACM a couple years back, I entered the fully correct spelling, because the Web site accepted it and I was in the mood to give it a try. As you might expect, I have received both printed and electronic material with various degradations, and there may be degradations that I haven't seen because they haven't made it here. There are all kinds of weird effects, such as the fact that I repeatedly get invitations to join the IEEE, addressed to the ACM variant of the address, even though I'm already an IEEE member. I'd assume that if the spelling of my name was more consistent, the IEEE would weed out the duplicate. Anyway, as you can see, the problems you mention can already happen. If a company can handle them, they should be able to figure out how to address non-ASCII email addresses, too (if only by not handling them). If a company or organization is currently doing a bad job, then non-ASCII email addresses might give them an incentive to fix some things overall. Regards, Martin. At 18:59 07/11/16, Chris Walker wrote: >John, > >It isn't an imagined problem, it's a real one. That's why I'm here. > >Many large corporations do a lot of work with business partners, other >corporations, and as such have data flowing into their systems that >originates in numerous locations out of their control. > >Example: User Alice fills out a web form on company X website for some >reason or another, and one of the data fields is her email address, >company X accepts a raw UTF8 email address e.g. NON ASCII@NON ASCII. Now >depending on whar Alice entered in the form, company X may send that >data to company Y (or company Z). The mechanism that companies X and Y >have is place to do this is ASCII. > >In this extraordinarily simple example, how does company X communicate >the email address to company Y? Should Alice know to have an ASCII email >address and to use that one? If Alice is an establised customer of >company Y, and has a saved profile with a non ASCII address, and that is >used for transmission to company Y, there may not be a data entry field >for Alice to fill out on her web form. > >Again this is a very simple example, in many cases, supply chains for >example, the data flow is though numerous companies and back again. In >order fulfillment, the orginal order may be split into several sub >orders for be fulfilled by numerous companies. Email notification is a >common feature of order processing. > >Ask yourself "Where does data flow?", in these situations, an email >address is just another piece of data. A piece a data that has the very >unfortunate characteristic of no standard ASCII encoding. > >Modifying every ASCII system that sees email addresses to handle UTF8 >will make the cost and effort of widening date fields to hold four digit >years look like childs play. > >In all probability two dominate solutions will emerge, a multitude of >incompatable encodings which over time will corrupt the data quality of >databases that store email addresses, or just throwing the data away when >it hits an ASCII system. All in all, this burden will be a huge >impediment to adoption of EAI as it stands now. > > > >Chris #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 16 19:59:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItC1R-00020v-Tf; Fri, 16 Nov 2007 19:58:57 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItC1Q-0001zj-6S for ima-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 19:58:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItC1P-0001wZ-Qe for ima@ietf.org; Fri, 16 Nov 2007 19:58:55 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItC1O-0000xp-Kq for ima@ietf.org; Fri, 16 Nov 2007 19:58:55 -0500 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1ItC1N-0007rU-9O; Fri, 16 Nov 2007 19:58:53 -0500 Date: Fri, 16 Nov 2007 19:58:50 -0500 From: John C Klensin To: Chris Walker Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <0D86890E55B438CC0356D4A3@[192.168.1.110]> In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris, I don't think this conversation is being particularly productive or informative, so am about to drop out of it. You may disagree, of course, and continue it with others. A few observations that might help clarify where things stand, even if they don't move things forward: (1) I believe that far more attention has been paid to user interface, process, and deployment issues than you seem to assume. The considerations involved many tradeoffs. The fact that the conclusions were not the ones you might have preferred does not imply that we were ignorant of the issues or that we blew them off. (2) As Andrew somewhat indirectly pointed out, opinions about the success of IDNA differ widely depending on who you talk with and what role they occupy. When they are evaluated as utilized by users, the assumption when the protocol was written was that those users would never (or almost never) actually see the ACE form. Today, users see the ACE form frequently and some even prefer it to the loss of information that might otherwise occur. But the ACE form is not a transliteration: few users who used to deal with transliterations (even while hating them) consider looking at an ACE form that has no mnemonic value at all to be an improvement. (3) The IETF doesn't do UI work. When exceptions have been made, we have usually regretted it because experience indicates that, as a community, we aren't very good at it. In general, the only things we attempt to standardize are things that appear on the wire. So, while everyone would probably agree with you that the on-the-wire behavior isn't all of the picture, the charter of the WG doesn't extend to how email addresses are transmitted in back-end processes within a company or between a company and its business partners. (4) I've tried to say this before, but the big problem with an ACE model for email local-parts is that all of the plausible ACE forms are plausible email addresses. Consequently, there is no way to reliably identify that an encoding has occurred and hence to decode it. This is a much worse problem when email addresses are transmitted in running text or as part of formatted data files than when they are used in email protocols, although the protocol issues are non-trivial. It is also different for email (essentially a collection of peer-to-peer transactions with relaying) than it is for the DNS (a client-server environment), both because of that difference and because we were able to examine the DNS tree carefully to conclude that chances of real problems were acceptably small. Put differently, the big problem with an ACE is telling that it is an ACE, rather than a direct form. Protecting IDNA requires that any string with hyphens in the third and fourth character positions be prohibited as a DNS label unless it is an IDNA ACE ("punycode") form with the "xn--" prefix. There is no practical way to apply such a restriction to email and keep it even reasonably robust (robustness against known behavior of many email systems is, among other things, the reason why making a distinction between .xyz... and ".xyz... is pretty much a non-starter. But the problem is standardizing an auto-detecting ACE form for use in the global email system. Within, e.g., a company environment, arranging some sort of flag or tagging to distinguish, unambiguously and non-heuristically, between an encoded address (whether ACE or something as trivial as Base64 of %HH encoding) and a non-encoded one, no matter how funny-looking, is certainly plausible. But, in the most general case, a ACE that is detected to be an ACE by its spelling or syntax alone isn't going to work for email (as well as getting us back into the problems that are mentioned above and discussed in Andrew's note). That is what I was trying to say about MAILTO. The current definition prohibits non-ASCII strings. But assume that either a revision were undertaken or a new, MAILTOO URL was defined, in either case using ordinary URI rules. One could then prohibit any local-part from appearing in the URI that started with "%" (even though it would be valid in a stand-alone email address). Or one could say that any %NN construction in a MAILTO[O] URL was a character escape and that any actual occurrence of "%" would have to be shown as %25, which would be consistent with the way the specs (both MAILTO and URI) are now written. It would certainly be sensible to look at that possibility, or the possibility of some other tagging or restrictions, for a representation format. Looking at MAILTO _is_ in the WG's charter and it would be entirely reasonable to have this discussion when we get to it. Of course, if that change were made to MAILTO, and a company or set of companies decided that what was to appear in their email address data fields was a MAILTO URL or its data portion, rather than a raw email address, your problem, as I understand it, would essentially be solved. (5) In my experience, when companies or trading partners start exchanging data electronically, the process involves reaching agreements about formats and data elements. Sometimes, those agreements are "we will all follow standard A, with profile B" and sometimes they involve much more specific agreements. But it rarely, if ever, happens that company X will send data to company Y and simply assume that company Y will know how to figure things out. That is particularly important in this context because, if a series of companies have been exchanging information in ASCII-only form, with agreements about elements and formats that say "ASCII-only", if someone suddenly starts sending UTF-8 _or_ Unicode data using some magic encoding that causes them to look like ASCII characters, that would be a breach of the agreements. They might be able to get away with that, but only if there was no expectation of the encoded data being decoded. And that would take us back to the situation in which users (and systems) get to see ugly-looking representational forms that the user who actually owns the address may not even recognize... a bad situation. (6) Despite the standards for transliteration that exist for _some_ (not all important) scripts, transliteration is a bad deal. People who are concerned about national languages and cultural preservation don't like it and often consider it insulting. As I suggested in an earlier note, there is little substantive reason for transliterating to ASCII rather than, e.g., to Cyrillic or Hangul. More important, different languages and dialects use the same characters to represent different phonemes, which can make transliteration models both counter-intuitive and ambiguous in application. (7) Several of your comments imply that you believe that two addresses implies two mailboxes and two places to check for mail, with no alternative. That is simply not how the mail system works and is used in practice. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 17 05:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKk9-0002mb-9V; Sat, 17 Nov 2007 05:17:41 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItKk8-0002ip-FF for ima-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 05:17:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKk3-0002Yz-4Y for ima@ietf.org; Sat, 17 Nov 2007 05:17:35 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItKk2-00015N-PV for ima@ietf.org; Sat, 17 Nov 2007 05:17:35 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C48D3240826; Sat, 17 Nov 2007 10:17:17 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 5CEA01590AC; Fri, 16 Nov 2007 13:11:12 -0200 (BRST) Date: Fri, 16 Nov 2007 13:11:12 -0200 From: Stephane Bortzmeyer To: Martin Duerst Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071116151112.GA25686@laperouse.bortzmeyer.org> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <20071114113120.GA30304@laperouse.bortzmeyer.org> <6.0.0.20.2.20071115152234.08b5cec0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20071115152234.08b5cec0@localhost> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 1.8 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Nov 15, 2007 at 03:43:34PM +0900, Martin Duerst wrote a message of 58 lines which said: > You haven't made it clear whether you are pointing us to RFC 4180 I was pointing to an ICANN document (which itself pointed to RFC 4180, but it was a detail, the relevant part of the ICANN document was not about CSV but about UTF-8). My intent was just to provide a real-world use case for the discussion, not to discuss wether ICANN is right or wrong. > So if you indeed wanted to use the text cited for saying "see, > here's another case where we an ACE would come in handy", Yes, that was the idea. It does not mean I approve the idea of an ACE, just that I wanted people to recognize that there may be a problem (which does not mean it is our responsability to solve it). _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 17 05:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKkC-0002sY-Dt; Sat, 17 Nov 2007 05:17:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItKkB-0002r4-79 for ima-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 05:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKk7-0002gC-R7 for ima@ietf.org; Sat, 17 Nov 2007 05:17:39 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItKk4-0007OA-2n for ima@ietf.org; Sat, 17 Nov 2007 05:17:39 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id CE79F240830; Sat, 17 Nov 2007 10:17:17 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 8F4521590AC; Fri, 16 Nov 2007 13:13:28 -0200 (BRST) Date: Fri, 16 Nov 2007 13:13:28 -0200 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: <20071116151328.GB25686@laperouse.bortzmeyer.org> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <932AEC1C24625DF8BEBF3F44@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <932AEC1C24625DF8BEBF3F44@p3.JCK.COM> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Nov 14, 2007 at 02:11:27PM -0500, John C Klensin wrote a message of 86 lines which said: > (1) Even though it is very useful in trying to nail down the > definition of a widely-used but much-varied format, RFC 4180 is an > informational document, not an IETF standard of any type. My intent was not to use RFC 4180 to prove anything but to show, from a field where some people here may be familiar with (the ICANN world), a possible case where the lack of an ACE may be a problem. > (3) The problems with CSV files, including issues of what to do with > too-short or too-long records and the great difficulty in extending > the format with new fields and handling information with a variable > number of subfields, are well known. Indeed, they are well-known > enough that the choice of CSV, rather than some variety of tagged > data (e.g., XML) for this type of information should probably be > described by such terms of precise technical evaluation as "plain > dumb". Report it to ICANN. XML vs. CSV has nothing to do with this discussion. The point was the sentence about UTF-8 and US-ASCII. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 17 13:27:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSNw-0001DL-Gq; Sat, 17 Nov 2007 13:27:16 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItSNu-00018F-Lt for ima-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 13:27:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSNu-000187-Bz for ima@ietf.org; Sat, 17 Nov 2007 13:27:14 -0500 Received: from abenaki.wabanaki.net ([65.99.1.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItSNq-0007Yy-VA for ima@ietf.org; Sat, 17 Nov 2007 13:27:14 -0500 Received: from eric-brunner-williamss-macbook.local (dpc67142250094.direcpc.com [67.142.250.94]) by abenaki.wabanaki.net (8.14.1/8.14.1) with ESMTP id lAHI0RV4015698; Sat, 17 Nov 2007 13:00:34 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <473F3244.9070004@nic-naa.net> Date: Sat, 17 Nov 2007 10:26:12 -0800 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <20071114113120.GA30304@laperouse.bortzmeyer.org> <6.0.0.20.2.20071115152234.08b5cec0@localhost> <20071116151112.GA25686@laperouse.bortzmeyer.org> In-Reply-To: <20071116151112.GA25686@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Stephane Bortzmeyer wrote: > Yes, that was the idea. It does not mean I approve the idea of an ACE, > just that I wanted people to recognize that there may be a problem > (which does not mean it is our responsability to solve it). > I didn't want to comment on the ICANN registrar data escrow format question (csv vs alternative(s)), as that was settled some months ago, my views not withstanding. I also didn't want to comment on the issue of whether the purpose of registrar data escrow is to transfer data, some of which may be broken, to a successor registrar operator, after some predicate condition is determined to exist, e.g., RegisterFly data transfer to GoDaddy, or to ensure registrant email address validity, as that too was similarly settled. What I wanted to point out was just this. A problematic use case, which we are not responsible to solve. Eric _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 17 17:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItVqv-0001aA-T1; Sat, 17 Nov 2007 17:09:25 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItVqu-0001ZK-R2 for ima-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 17:09:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItVqu-0001Wv-BO for ima@ietf.org; Sat, 17 Nov 2007 17:09:24 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItVqt-0000Y2-5Y for ima@ietf.org; Sat, 17 Nov 2007 17:09:24 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 11-md50000000103.tmp for ; Sat, 17 Nov 2007 15:12:06 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Sat, 17 Nov 2007 15:12:06 -0700 Date: Sat, 17 Nov 2007 15:12:06 -0700 From: "Chris Walker" To: "John C Klensin" , "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <0D86890E55B438CC0356D4A3@[192.168.1.110]> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> <0D86890E55B438CC0356D4A3@[192.168.1.110]> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Sat, 17 Nov 2007 15:12:06 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 -----Original Message----- From: John C Klensin To: Chris Walker Cc: eai list Date: Fri, 16 Nov 2007 19:58:50 -0500 Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > Chris, > > I don't think this conversation is being particularly productive > or informative, so am about to drop out of it. You may > disagree, of course, and continue it with others. > > A few observations that might help clarify where things stand, > even if they don't move things forward: > > (1) I believe that far more attention has been paid to user > interface, process, and deployment issues than you seem to > assume. The considerations involved many tradeoffs. The fact > that the conclusions were not the ones you might have preferred > does not imply that we were ignorant of the issues or that we > blew them off. > > (2) As Andrew somewhat indirectly pointed out, opinions about > the success of IDNA differ widely depending on who you talk with > and what role they occupy. When they are evaluated as utilized > by users, the assumption when the protocol was written was that > those users would never (or almost never) actually see the ACE > form. Today, users see the ACE form frequently and some even > prefer it to the loss of information that might otherwise occur. > But the ACE form is not a transliteration: few users who used to > deal with transliterations (even while hating them) consider > looking at an ACE form that has no mnemonic value at all to be > an improvement. > > (3) The IETF doesn't do UI work. When exceptions have been > made, we have usually regretted it because experience indicates > that, as a community, we aren't very good at it. In general, > the only things we attempt to standardize are things that appear > on the wire. So, while everyone would probably agree with you > that the on-the-wire behavior isn't all of the picture, the > charter of the WG doesn't extend to how email addresses are > transmitted in back-end processes within a company or between a > company and its business partners. > > (4) I've tried to say this before, but the big problem with an > ACE model for email local-parts is that all of the plausible ACE > forms are plausible email addresses. Consequently, there is no > way to reliably identify that an encoding has occurred and hence > to decode it. This is a much worse problem when email addresses > are transmitted in running text or as part of formatted data > files than when they are used in email protocols, although the > protocol issues are non-trivial. It is also different for email > (essentially a collection of peer-to-peer transactions with > relaying) than it is for the DNS (a client-server environment), > both because of that difference and because we were able to > examine the DNS tree carefully to conclude that chances of real > problems were acceptably small. > > Put differently, the big problem with an ACE is telling that it > is an ACE, rather than a direct form. Protecting IDNA requires > that any string with hyphens in the third and fourth character > positions be prohibited as a DNS label unless it is an IDNA ACE > ("punycode") form with the "xn--" prefix. There is no practical > way to apply such a restriction to email and keep it even > reasonably robust (robustness against known behavior of many > email systems is, among other things, the reason why making a > distinction between > .xyz... > and > ".xyz... > is pretty much a non-starter. Actually the problem is defining an encoding that affect only the local part while preserving the @ sign and the domain in its original form. Encoding an email address vs. encoding local-part provides numerous collision free possibilities, any encoding that does not result with an @ sign, or locates the encoding identifier at the trailing end of the encoding string. non-ascii@non-ascii = yn--someasciiencoding or someasciiencoding--yn. However since one of the fundamental cornerstones of this entire UTF8SMTP effort is the argument that an internationaled email address CAN'T be encoded in ASCII, I can see how you are not likely to concede this point. > > But the problem is standardizing an auto-detecting ACE form for > use in the global email system. Within, e.g., a company > environment, arranging some sort of flag or tagging to > distinguish, unambiguously and non-heuristically, between an > encoded address (whether ACE or something as trivial as Base64 > of %HH encoding) and a non-encoded one, no matter how > funny-looking, is certainly plausible. But, in the most general > case, a ACE that is detected to be an ACE by its spelling or > syntax alone isn't going to work for email (as well as getting > us back into the problems that are mentioned above and discussed > in Andrew's note). > > That is what I was trying to say about MAILTO. The current > definition prohibits non-ASCII strings. But assume that either > a revision were undertaken or a new, MAILTOO URL was defined, in > either case using ordinary URI rules. One could then prohibit > any local-part from appearing in the URI that started with "%" > (even though it would be valid in a stand-alone email address). > Or one could say that any %NN construction in a MAILTO[O] URL > was a character escape and that any actual occurrence of "%" > would have to be shown as %25, which would be consistent with > the way the specs (both MAILTO and URI) are now written. It > would certainly be sensible to look at that possibility, or the > possibility of some other tagging or restrictions, for a > representation format. Looking at MAILTO _is_ in the WG's > charter and it would be entirely reasonable to have this > discussion when we get to it. > > Of course, if that change were made to MAILTO, and a company or > set of companies decided that what was to appear in their email > address data fields was a MAILTO URL or its data portion, rather > than a raw email address, your problem, as I understand it, > would essentially be solved. It would only be solved, if there was a statement that indicated that this was a preferred encoding for ASCII data processing so it was not ambiguous which form should be used, vs. other encoding formats e.g. the encoding format used to preserve the downgraded original UTF8 address in 'downgrading' document. > > (5) In my experience, when companies or trading partners start > exchanging data electronically, the process involves reaching > agreements about formats and data elements. Sometimes, those > agreements are "we will all follow standard A, with profile B" > and sometimes they involve much more specific agreements. But > it rarely, if ever, happens that company X will send data to > company Y and simply assume that company Y will know how to > figure things out. > > That is particularly important in this context because, if a > series of companies have been exchanging information in > ASCII-only form, with agreements about elements and formats that > say "ASCII-only", if someone suddenly starts sending UTF-8 _or_ > Unicode data using some magic encoding that causes them to look > like ASCII characters, that would be a breach of the agreements. > They might be able to get away with that, but only if there was > no expectation of the encoded data being decoded. And that > would take us back to the situation in which users (and systems) > get to see ugly-looking representational forms that the user who > actually owns the address may not even recognize... a bad > situation. Of course some chages will need to be made, select an ASCII encoding or reengineer to 8bit, the only point of selecting a preferred ASCII encoding it to prevent the randomness of every interface between two entities from deciding on a different encoding. > > (6) Despite the standards for transliteration that exist for > _some_ (not all important) scripts, transliteration is a bad > deal. People who are concerned about national languages and > cultural preservation don't like it and often consider it > insulting. As I suggested in an earlier note, there is little > substantive reason for transliterating to ASCII rather than, > e.g., to Cyrillic or Hangul. More important, different > languages and dialects use the same characters to represent > different phonemes, which can make transliteration models both > counter-intuitive and ambiguous in application. > > (7) Several of your comments imply that you believe that two > addresses implies two mailboxes and two places to check for > mail, with no alternative. That is simply not how the mail > system works and is used in practice. Having a UTF8 and ASCII email address at the same server MAY happen, I have not seen anything in the drafts to indicate that it shall happen. > > john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 17 18:18:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItWvp-0007pW-To; Sat, 17 Nov 2007 18:18:33 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItWvo-0007o6-DI for ima-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 18:18:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItWvo-0007mQ-1E for ima@ietf.org; Sat, 17 Nov 2007 18:18:32 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItWvm-0002xi-W5 for ima@ietf.org; Sat, 17 Nov 2007 18:18:31 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 62-md50000000103.tmp for ; Sat, 17 Nov 2007 16:21:13 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Sat, 17 Nov 2007 16:21:13 -0700 Date: Sat, 17 Nov 2007 16:21:13 -0700 From: "Chris Walker" To: "Martin Duerst" , "John C Klensin" , "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <6.0.0.20.2.20071116194233.080b1e40@localhost> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <6.0.0.20.2.20071116194233.080b1e40@localhost> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Sat, 17 Nov 2007 16:21:13 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 -----Original Message----- From: Martin Duerst To: "Chris Walker" , "John C Klensin" , "eai list" Date: Fri, 16 Nov 2007 19:52:29 +0900 Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > Hello Chris, > > I think John and Harald and others have already tried, but I'll > try again. I think we understand your scenario, and we know it's > real. But what is at least as real, and more importantly, already > possible/happening, is the same problem with names and addresses. > > Please take a moment and rewrite your text below and replace > "email address" with "person's name", or "customer's street address", > or any such. What you will see is that: > 1) The problem already exists. > 2) If companies haven't handled the problem for name or address, > they are already having problems. If they have handled it, > they should be able to handle it for email addresses, too. > Hi Martin, Are you suggesting that the preferential encoding for an internationalized email address should be romanized phonomes? The mechanisms of delivery are not the same for names, postal addresses and email addresses. Names and postal addresses used in the delivery of postal mail involves a human, where the delivery of an email is expected to be possible without interpretation by a human. > BTW, I happen to speak out of experience. My name, in fully correct > spelling, contains an u-umlaut, in ASCII, the closest you can get > is something like Du"rst. For most forms, I just enter Duerst. > When I (re)joined the ACM a couple years back, I entered the fully > correct spelling, because the Web site accepted it and I was in the > mood to give it a try. As you might expect, I have received both > printed and electronic material with various degradations, and there > may be degradations that I haven't seen because they haven't made > it here. There are all kinds of weird effects, such as the fact > that I repeatedly get invitations to join the IEEE, addressed > to the ACM variant of the address, even though I'm already an > IEEE member. I'd assume that if the spelling of my name was more > consistent, the IEEE would weed out the duplicate. > I certainly understand and sympathize with the complications that you have to deal with. Having personally questioned many people who commonly use germanic languages on the topic (Germans, Austrians, and Swiss). The consensus that I have been able to determine is: It is preferred to preserve characters with umlauts, if that is not possible then convert u umlaut to ue, o umlaut to oe, etc. The character that resembles a fancy capital B, ess-tzet, a long s, is converted to ss. The practice of converting u umlaut to u, and o umlaut to o, is considered ignorant and insensitive. > Anyway, as you can see, the problems you mention can already happen. > If a company can handle them, they should be able to figure out how > to address non-ASCII email addresses, too (if only by not handling > them). > If a company or organization is currently doing a bad job, then > non-ASCII > email addresses might give them an incentive to fix some things > overall. > The issues you notice regarding multiple inclusion or not recognizing your existing inclusion in a list is in the CRM match, merge, purge problem space. Even if a fully 8bit end to end system accepted and preserved UTF8 names and postal addresses, there is a hitch. Some people will submit their identifying information in transliterated or ASCII form. Unless the implementation of the match, merge, purge functions is internally aware of transliteration and even Latin1 to ASCII conversions, it will not notice that two names or postal addresses are the same. Since many of these conversions are one way streets, i.e. there is no way to know that Duerst should be D(u umalaut)rst or that you actually prefer Duerst, all data is usually converted to the most reduced form to provide the ability to perform matches. I wish that applying the best practices for dealing with internationalized names and postal addresses could be applied to internationlized email addresses, however the lack of humans in the delivery process, and the issues you pointed out with Latin1 to ASCII conversions with umlauts would seem to indicate that a more precise solution is needed. > Regards, Martin. > > At 18:59 07/11/16, Chris Walker wrote: > >John, > > > >It isn't an imagined problem, it's a real one. That's why I'm here. > > > >Many large corporations do a lot of work with business partners, other > >corporations, and as such have data flowing into their systems that > >originates in numerous locations out of their control. > > > >Example: User Alice fills out a web form on company X website for some > >reason or another, and one of the data fields is her email address, > >company X accepts a raw UTF8 email address e.g. NON ASCII@NON ASCII. > Now > >depending on whar Alice entered in the form, company X may send that > >data to company Y (or company Z). The mechanism that companies X and Y > >have is place to do this is ASCII. > > > >In this extraordinarily simple example, how does company X communicate > >the email address to company Y? Should Alice know to have an ASCII > email > >address and to use that one? If Alice is an establised customer of > >company Y, and has a saved profile with a non ASCII address, and that > is > >used for transmission to company Y, there may not be a data entry > field > >for Alice to fill out on her web form. > > > >Again this is a very simple example, in many cases, supply chains for > >example, the data flow is though numerous companies and back again. In > >order fulfillment, the orginal order may be split into several sub > >orders for be fulfilled by numerous companies. Email notification is a > >common feature of order processing. > > > >Ask yourself "Where does data flow?", in these situations, an email > >address is just another piece of data. A piece a data that has the > very > >unfortunate characteristic of no standard ASCII encoding. > > > >Modifying every ASCII system that sees email addresses to handle UTF8 > >will make the cost and effort of widening date fields to hold four > digit > >years look like childs play. > > > >In all probability two dominate solutions will emerge, a multitude of > >incompatable encodings which over time will corrupt the data quality > of > >databases that store email addresses, or just throwing the data away > when > >it hits an ASCII system. All in all, this burden will be a huge > >impediment to adoption of EAI as it stands now. > > > > > > > >Chris > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 17 23:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itc6f-0003oe-LP; Sat, 17 Nov 2007 23:50:05 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Itc6e-0003oK-EZ for ima-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 23:50:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itc6e-0003mj-1Q; Sat, 17 Nov 2007 23:50:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itc6d-0003TD-Ke; Sat, 17 Nov 2007 23:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id CC61917573; Sun, 18 Nov 2007 04:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itc6c-0008NA-0P; Sat, 17 Nov 2007 23:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 17 Nov 2007 23:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-downgrade-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Downgrading mechanism for Email Address Internationalization Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-ietf-eai-downgrade-05.txt Pages : 30 Date : 2007-11-17 Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid bouncing internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-downgrade-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-downgrade-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-17234628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-downgrade-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-17234628.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Sun Nov 18 16:08:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItrMz-0003dr-L8; Sun, 18 Nov 2007 16:07:57 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItrMy-0003dm-Nv for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 16:07:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItrMy-0003de-Dj for ima@ietf.org; Sun, 18 Nov 2007 16:07:56 -0500 Received: from smtp05.bis.na.blackberry.com ([216.9.248.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItrMy-0004P9-31 for ima@ietf.org; Sun, 18 Nov 2007 16:07:56 -0500 Received: from bxe121.bisx.prod.on.blackberry (bxe121.bisx.prod.on.blackberry [172.20.225.150]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id lAIJvTJk001077 for ima@ietf.org; Sun, 18 Nov 2007 21:07:50 GMT X-rim-org-msg-ref-id: 813098865 Message-ID: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> X-Priority: Normal Sensitivity: Normal Importance: Normal To: "eai list" From: "=?utf-8?B?RGFuaWVsIFRhaGFybGV2?=" Date: Sun, 18 Nov 2007 21:07:21 +0000 MIME-Version: 1.0 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [EAI] Another subject: left-to-right languages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@taharlev.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1048798165==" Errors-To: ima-bounces@ietf.org --===============1048798165== Content-Transfer-Encoding: base64 Content-Type: text/plain SSd2ZSBiZWVuIHJlYWRpbmcgdGhlIHRocmVhZHMgaGVyZSwgYW5kIGhvcGUgSSBkaWRuJ3QgbWlz cyB0aGlzIGJlaW5nIGRpc2N1c3NlZCB5ZXQuDQoNCkFkZGluZyBub24tYXNjaWkgY2hhcmFjdGVy cyBpcyBncmVhdCBmb3IgbGVmdC10by1yaWdodCBsYW5ndWFnZXM7IHdpdGggYWxsIG9mIHRoZSBp c3N1ZXMsIHRoZXJlIHdpbGwgcHJvYmFibHkgYmUgYSBzb2x1dGlvbiBpbmNsdWRpbmcgYXNjaWkt b25seSBzZWNvbmRhcnkgYWRkcmVzc2VzLCBvciBzb21ldGhpbmcgc2ltaWxhci4NCg0KSG93ZXZl ciwgd2hhdCBhYm91dCByaWdodC10by1sZWZ0IGxhbmd1YWdlcywgc3VjaCBhcyBIZWJyZXc/IElm IGJvdGggdGhlIGFkZHJlc3MgYW5kIHRoZSBkb21haW4gYXJlIHJpZ2h0LXRvLWxlZnQsIHRoZSBh ZGRyZXNzIG1heSBsb29rIGxpa2UgdGhpczoNCnVzZXJAZG9tYWluLmNvbQ0KDQpCdXQgaXQgY291 bGQgYWxzbyBsb29rIGxpa2UgdGhpczoNCm1vYy5uaWFtb2RAcmVzdQ0KDQpTZWUsIHdoZW4gYW4g c210cCBjb25uZWN0aW9uIHN0YXJ0cyBzcGVha2luZywgaXQgc2VuZHMgdGhlIGNoYXJhY3RlcnMg aW4gdGhlIGNvcnJlY3Qgb3JkZXIsIGkuZSBubyBtYXR0ZXIgdGhlIGxhbmd1YWdlLCB0aGUgZmly c3QgY2hhciB3aWxsIGJlICJ1IiwgdGhlbiAicyIsIHRoZW4gImUiIGFuZCBzbyBvbjsgaG93ZXZl ciwgd2hlbiBsb29rZWQgdXAgaW50ZXJuYWxseSwgd2hlbiBmb3J3YXJkZWQsIGV0Yy4sIHRoZSBh ZGRyZXNzJyBkaXNwbGF5IG11c3QgYmUgcmV2ZXJzZWQhDQoNCklmIGFueW9uZSBldmVyIHRyaWVk IGp1c3Qgc2V0dGluZyB1cCBhIHNpbXBsZSBBY3RpdmUgRGlyZWN0b3J5IGVudmlyb25tZW50IHdp dGggdXNlcm5hbWVzLCBwYXNzd29yZHMgb3IgZXZlbiBPVXMgdXNpbmcgcmlnaHQtdG8tbGVmdCBu YW1lcywgSSdtIHN1cmUgeW91IGdvdCBhIHRhc3RlIG9mIHRoZSBwcm9ibGVtOyB3aXRoIHdvcmxk LXdpZGUgc210cCwgaXQgY291bGQgYmUgdGVuIHRpbWVzIHdvcnNlIQ0KDQpXb3VsZCBsb3ZlIHRv IGhlYXIgd2hhdCB5b3UgaGF2ZSB0byBzYXkuDQoNCkRUDQoNCg0KZGFuaWVsQHRhaGFybGV2LmNv bQ== --===============1048798165== 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 --===============1048798165==-- From ima-bounces@ietf.org Sun Nov 18 16:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Its39-0007TK-Bc; Sun, 18 Nov 2007 16:51:31 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Its38-0007T9-75 for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 16:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Its37-0007T1-Tk for ima@ietf.org; Sun, 18 Nov 2007 16:51:29 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Its32-0000xM-8o for ima@ietf.org; Sun, 18 Nov 2007 16:51:29 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Its31-0005tj-Gy; Sun, 18 Nov 2007 16:51:23 -0500 Date: Sun, 18 Nov 2007 16:51:22 -0500 From: John C Klensin To: daniel@taharlev.com, eai list Subject: Re: [EAI] Another subject: left-to-right languages Message-ID: In-Reply-To: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Sunday, 18 November, 2007 21:07 +0000 Daniel Taharlev wrote: > I've been reading the threads here, and hope I didn't miss > this being discussed yet. > > Adding non-ascii characters is great for left-to-right > languages; with all of the issues, there will probably be a > solution including ascii-only secondary addresses, or > something similar. > > However, what about right-to-left languages, such as Hebrew? > If both the address and the domain are right-to-left, the > address may look like this: user@domain.com > > But it could also look like this: > moc.niamod@resu > > See, when an smtp connection starts speaking, it sends the > characters in the correct order, i.e no matter the language, > the first char will be "u", then "s", then "e" and so on; > however, when looked up internally, when forwarded, etc., the > address' display must be reversed! > > If anyone ever tried just setting up a simple Active Directory > environment with usernames, passwords or even OUs using > right-to-left names, I'm sure you got a taste of the problem; > with world-wide smtp, it could be ten times worse! > > Would love to hear what you have to say. Daniel, We have been wrestling with these issues in several contexts, most notably with IDNAbis (see, in particular, draft-alvestrand-idnabis-bidi-01.txt). The short answer is that this sort of thing has to be treated as a human interface issue. The protocol --which is all these documents specify -- has to be to send the material in network order, which is what you suggest ("u", then "s", etc.). The display routines (part of the user interface) will need to understand how to correctly render the characters. That implies not only right-to-left for appropriate scripts, but specific rendering actions for scripts (even left-to-right ones) that require special rendering actions depending on context and embedded format-effecting characters. The other problem involves the question of whether users can get from what is written on a business card to the right address for typing into a computer. One can only hope that those users who are familiar with the script and language in question will get it right. Those who are not may need help from ASCII alternative addresses or some other type of hint: as I said several times at IGF last week, those transcript problems are issues that are direct consequences of ones that have been with us for around 5000 or 6000 years. Neither the Internet, nor some small piece of protocol work, is going to fix them. I think our advice to user interface designers should be "be careful, as there are additional traps in this area". If you would like to propose specific text along those lines and where to put it --for either the EAI documents or for draft-klensin-idnabis-issues, since there is considerable overlap in interest and editors-- I think I can speak for my co-authors and co-editors in saying that such contributions would be very welcome. In the longer term, and for the broader issues, I think the IETF community and others would welcome one or more informational tutorials on how to address the many interface problems associated with right-to-left characters and scripts, especially when the relevant language is unknown (e.g., the issues are slightly different with the Hebrew script for Yiddish and Hebrew, and for the Arabic script with Persian, Urdu, Arabic, and other languages). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 18:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ittuc-0003pX-SX; Sun, 18 Nov 2007 18:50:50 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ittub-0003jn-GS for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 18:50:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ittub-0003jD-23 for ima@ietf.org; Sun, 18 Nov 2007 18:50:49 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IttuZ-0001S2-Vi for ima@ietf.org; Sun, 18 Nov 2007 18:50:48 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAINoih5004609 for ; Mon, 19 Nov 2007 08:50:44 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0b51_13cf68f0_9631_11dc_8bdf_0014221fa3c9; Mon, 19 Nov 2007 08:50:43 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60960) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2007 08:46:52 +0900 Message-Id: <6.0.0.20.2.20071119082806.073d4a40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 19 Nov 2007 08:49:12 +0900 To: John C Klensin , daniel@taharlev.com, eai list From: Martin Duerst Subject: Re: [EAI] Another subject: left-to-right languages In-Reply-To: References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Felix Sasaki , Richard Ishida X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 06:51 07/11/19, John C Klensin wrote: > > >--On Sunday, 18 November, 2007 21:07 +0000 Daniel Taharlev > wrote: > >> I've been reading the threads here, and hope I didn't miss >> this being discussed yet. >> >> Adding non-ascii characters is great for left-to-right >> languages; with all of the issues, there will probably be a >> solution including ascii-only secondary addresses, or >> something similar. >> >> However, what about right-to-left languages, such as Hebrew? >> If both the address and the domain are right-to-left, the >> address may look like this: user@domain.com >> >> But it could also look like this: >> moc.niamod@resu It not only could look like this, if all the components are RTL, it should look like this. An alternative might be resu@niamod.moc, but that would make it extremely difficult to carry such addresses in plain text and to display and later keyboard them again in a consistent way. >> See, when an smtp connection starts speaking, it sends the >> characters in the correct order, i.e no matter the language, >> the first char will be "u", then "s", then "e" and so on; >> however, when looked up internally, when forwarded, etc., the >> address' display must be reversed! >> >> If anyone ever tried just setting up a simple Active Directory >> environment with usernames, passwords or even OUs using >> right-to-left names, I'm sure you got a taste of the problem; >> with world-wide smtp, it could be ten times worse! >> >> Would love to hear what you have to say. > >Daniel, > >We have been wrestling with these issues in several contexts, >most notably with IDNAbis (see, in particular, >draft-alvestrand-idnabis-bidi-01.txt). That draft deals with an important detail that had been forgotten in previous specs, namely the issue of combining marks on RTL letters, in particular at the end of an RTL component. My understanding is that everybody involved agrees that the proposal in the above draft is a non-brainer, it's clear that a fix is needed. But the above draft, although related to the problem of RTL and Bidi, doesn't deal with the core of the issue at all. For much more on this issue, the best place to look at at the moment is section 4 of RFC 3987, or its update, currently at http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-01.txt. (which does not yet integrate all the necessary fixes from the issues list, including some related to bidi). This is about IRIs, the international extension of URIs, which have to deal not only with mail addresses, but with a huge number of other identifier schemes. >The short answer is that this sort of thing has to be treated as >a human interface issue. The protocol --which is all these >documents specify -- has to be to send the material in network >order, which is what you suggest ("u", then "s", etc.). The >display routines (part of the user interface) will need to >understand how to correctly render the characters. That implies >not only right-to-left for appropriate scripts, but specific >rendering actions for scripts (even left-to-right ones) that >require special rendering actions depending on context and >embedded format-effecting characters. Yes. Other rendering issues are also important, but their effect is always local (within a few codepoints). >The other problem involves the question of whether users can get >from what is written on a business card to the right address for >typing into a computer. One can only hope that those users who >are familiar with the script and language in question will get >it right. Yes. This is a particularly important and tricky point for RTL and bidi. What we (actually Mati Allouche from IBM Israel) came up with were some simple conventions that should make the mappings from graphic (visual) to electronic (logical) deterministic. For that, some restrictions were needed on combinations of letters of different directionality in different components. These restrictions were also carried over into IDNA. And these restrictions were where we forgot about combining marks, which we have to fix. >I think our advice to user interface designers should be "be >careful, as there are additional traps in this area". If you >would like to propose specific text along those lines and where >to put it --for either the EAI documents or for >draft-klensin-idnabis-issues, since there is considerable >overlap in interest and editors-- I think I can speak for my >co-authors and co-editors in saying that such contributions >would be very welcome. I think just saying 'be careful' isn't enough. But putting in specific text runs the risk of creating different solutions for IDNs, for non-ASCII emails, for IRIs, and for other kinds of identifiers. One way to go would be to point to section 4 of RFC 3987 (or its successor) and specify what the components of an email LHS are. >In the longer term, and for the broader issues, I think the IETF >community and others would welcome one or more informational >tutorials on how to address the many interface problems >associated with right-to-left characters and scripts, especially >when the relevant language is unknown (e.g., the issues are >slightly different with the Hebrew script for Yiddish and >Hebrew, and for the Arabic script with Persian, Urdu, Arabic, >and other languages). John, are you saying that e.g. there are differences between the Hebrew and Yiddish languages? There are definitely differences in the character repertoire and in the use and importance of vowel marks, but I don't know about any differences with respect to directionality. Please note that the W3C already has quite a bit of material on Bidi issues (see http://www.w3.org/International/resource-index.php?topic=bidi), although there isn't much on identifiers. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 19:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itu3k-0007oO-Bm; Sun, 18 Nov 2007 19:00:16 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Itu3j-0007o4-6M for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 19:00:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itu3i-0007nu-SL for ima@ietf.org; Sun, 18 Nov 2007 19:00:14 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itu3i-0001us-Fc for ima@ietf.org; Sun, 18 Nov 2007 19:00:14 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Itu3b-000Add-Qy; Sun, 18 Nov 2007 19:00:07 -0500 Date: Sun, 18 Nov 2007 19:00:06 -0500 From: John C Klensin To: Martin Duerst , daniel@taharlev.com, eai list Subject: Re: [EAI] Another subject: left-to-right languages Message-ID: <7BE501728E934C7C6821DB8F@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20071119082806.073d4a40@localhost> References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Felix Sasaki , Richard Ishida X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, 19 November, 2007 08:49 +0900 Martin Duerst wrote: >... >> In the longer term, and for the broader issues, I think the >> IETF community and others would welcome one or more >> informational tutorials on how to address the many interface >> problems associated with right-to-left characters and >> scripts, especially when the relevant language is unknown >> (e.g., the issues are slightly different with the Hebrew >> script for Yiddish and Hebrew, and for the Arabic script with >> Persian, Urdu, Arabic, and other languages). > > John, are you saying that e.g. there are differences between > the Hebrew and Yiddish languages? There are definitely > differences in the character repertoire and in the use and > importance of vowel marks, but I don't know about any > differences with respect to directionality. Only in the "vowel mark" issue, e.g., all of the combining mark issues that you describe in your note can be avoided for Hebrew, but not for Yiddish. >... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 19:50:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItuqF-0007Pk-Mg; Sun, 18 Nov 2007 19:50:23 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItuqE-0007Pe-Al for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 19:50:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItuqE-0007PW-1C for ima@ietf.org; Sun, 18 Nov 2007 19:50:22 -0500 Received: from smtp03.bis.na.blackberry.com ([216.9.248.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItuqA-0006b9-Kq for ima@ietf.org; Sun, 18 Nov 2007 19:50:22 -0500 Received: from bxe121.bisx.prod.on.blackberry (bxe121.bisx.prod.on.blackberry [172.20.225.150]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id lAJ0eniA017762; Mon, 19 Nov 2007 00:50:09 GMT X-rim-org-msg-ref-id: 1023408057 Message-ID: <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> X-Priority: Normal References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost><7BE501728E934C7C6821DB8F@p3.JCK.COM> In-Reply-To: <7BE501728E934C7C6821DB8F@p3.JCK.COM> Sensitivity: Normal Importance: Normal To: "John C Klensin" , "Martin Duerst" , "eai list" Subject: Re: [EAI] Another subject: left-to-right languages From: "=?utf-8?B?RGFuaWVsIFRhaGFybGV2?=" Date: Mon, 19 Nov 2007 00:49:41 +0000 MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Felix Sasaki , Richard Ishida X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@taharlev.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1458594899==" Errors-To: ima-bounces@ietf.org --===============1458594899== Content-Transfer-Encoding: base64 Content-Type: text/plain V2l0aCByZWdhcmRzIHRvIHdoYXQgSm9obiBzYWlkLCBsZXQncyBtYWtlIGl0IGV2ZW4gbW9yZSBp bnRlcmVzdGluZy4gSW4gSGVicmV3LCB0aGUgbGV0dGVyICJCZWl0IiBjYW4gc291bmQgYXMgYSAi QiIgb3IgYXMgYSAiViIgLS0gZGVwZW5kaW5nIG9uIGlmIGl0IGhhcyBhICJkYWdlc2giIC0tIGEg bGl0dGxlIGRvdCAtLSBpbiBpdC4gVGhhdCBkb3QgaXMgcGFydCBvZiB0aGUgbGV0dGVyOyBob3dl dmVyLCB3aGVuIHR5cGluZywgb25lIG9mIHRoZSBjb21tb24gc29sdXRpb25zIGlzIHRvIGFjdHVh bGx5IGFkZCB0aGUgImRhZ2VzaCIgY2hhcmFjdGVyIHJpZ2h0IGFmdGVyIHRoZSBsZXR0ZXIsIHdo ZXJlIHRoZSBzeXN0ZW0gZm9udCBiYXNpY2FsbHkgaGFzIGEgc2V0dGluZyBzYXlpbmcgInRoaXMg c3BlY2lhbCBjaGFyYWN0ZXIgbmVlZHMgdG8gYmUgZW1iZWRkZWQgaW50byB0aGUgcHJldmlvdXMg bGV0dGVyLiIgVGhlIGRvdHRlZCBsZXR0ZXIgYXBwZWFycyBpbiB0aGUgY2hhcnNldCBhcyBhIHVu aXF1ZSBhc2NpaSBjb2RlLCBidXQgaXMgbmV2ZXIgdXNlZCAtLSB5b3UnbGwgYWx3YXlzIHVzZSB0 aGUgZm9udCB0cmljay4NCg0KTm93LCBpZiBhbiBzbXRwIGNvbm5lY3Rpb24gaXMgY3JlYXRlZCwg aXQgdHJhbnNtaXRzIHRoZSBjaGFyYWN0ZXJzIG9uZSBieSBvbmU7IHRoZSBzZXJ2ZXIgY2FuIGtu b3cgaG93IHRvIGVtYmVkIHRoZSBjaGFyYWN0ZXIgaW50byB0aGUgZGlzcGxheSwgYnV0IHdpbGwg dGhhdCBtYWtlICJiQGRvbWFpbi5jb20iIGEgZGlmZmVyZW50IGVtYWlsIGFkZHJlc3MgdGhhbiAi Yih3aXRoIGEgZGFnZXNoQGRvbWFpbi5jb20iPyBGb3IgSGVicmV3IHNwZWFrZXJzLCB0aGF0J3Mg bGlrZSBoYXZpbmcgY3Vyc2l2ZS13cml0dGVuIGFkZHJlc3NlcyBkaWZmZXJlbnQgZnJvbSBwcmlu dGVkIGFkZHJlc3Nlcy4gT25lIGNhbiBlYXNpbHkgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhhdCwgcG9z aW5nIGFzIHNvbWVvbmUgZWxzZSwgYnkgYWRkaW5nIGEgc21hbGwgZG90IGludG8gdGhlaXIgdXNl cm5hbWUgLS0gd2hpY2ggaXMgZXZlbiBoYXJkZXIgdG8gZGV0ZWN0IHRoYXQgYSBwaGlzaGluZyBz aXRlIHRha2luZyBhZHZhbnRhZ2UgbWlzdHlwaW5nICJnb29nbGUiIGFzICJnb29nZWwiLg0KDQog DQpkYW5pZWxAdGFoYXJsZXYuY29tDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBKb2huIEMgS2xlbnNpbiA8a2xlbnNpbkBqY2suY29tPg0KDQpEYXRlOiBTdW4sIDE4IE5vdiAy MDA3IDE5OjAwOjA2IA0KVG86TWFydGluIER1ZXJzdCA8ZHVlcnN0QGl0LmFveWFtYS5hYy5qcD4s IGRhbmllbEB0YWhhcmxldi5jb20sZWFpIGxpc3QgPGltYUBpZXRmLm9yZz4NCkNjOlJpY2hhcmQg SXNoaWRhIDxpc2hpZGFAdzMub3JnPiwgRmVsaXggU2FzYWtpIDxmc2FzYWtpQHczLm9yZz4NClN1 YmplY3Q6IFJlOiBbRUFJXSBBbm90aGVyIHN1YmplY3Q6IGxlZnQtdG8tcmlnaHQgbGFuZ3VhZ2Vz DQoNCg0KDQoNCi0tT24gTW9uZGF5LCAxOSBOb3ZlbWJlciwgMjAwNyAwODo0OSArMDkwMCBNYXJ0 aW4gRHVlcnN0DQo8ZHVlcnN0QGl0LmFveWFtYS5hYy5qcD4gd3JvdGU6DQoNCj4uLi4NCj4+IElu IHRoZSBsb25nZXIgdGVybSwgYW5kIGZvciB0aGUgYnJvYWRlciBpc3N1ZXMsIEkgdGhpbmsgdGhl DQo+PiBJRVRGIGNvbW11bml0eSBhbmQgb3RoZXJzIHdvdWxkIHdlbGNvbWUgb25lIG9yIG1vcmUN Cj4+IGluZm9ybWF0aW9uYWwgdHV0b3JpYWxzIG9uIGhvdyB0byBhZGRyZXNzIHRoZSBtYW55IGlu dGVyZmFjZQ0KPj4gcHJvYmxlbXMgYXNzb2NpYXRlZCB3aXRoIHJpZ2h0LXRvLWxlZnQgY2hhcmFj dGVycyBhbmQNCj4+IHNjcmlwdHMsIGVzcGVjaWFsbHkgd2hlbiB0aGUgcmVsZXZhbnQgbGFuZ3Vh Z2UgaXMgdW5rbm93bg0KPj4gKGUuZy4sIHRoZSBpc3N1ZXMgYXJlIHNsaWdodGx5IGRpZmZlcmVu dCB3aXRoIHRoZSBIZWJyZXcNCj4+IHNjcmlwdCBmb3IgWWlkZGlzaCBhbmQgSGVicmV3LCBhbmQg Zm9yIHRoZSBBcmFiaWMgc2NyaXB0IHdpdGgNCj4+IFBlcnNpYW4sIFVyZHUsIEFyYWJpYywgYW5k IG90aGVyIGxhbmd1YWdlcykuDQo+IA0KPiBKb2huLCBhcmUgeW91IHNheWluZyB0aGF0IGUuZy4g dGhlcmUgYXJlIGRpZmZlcmVuY2VzIGJldHdlZW4NCj4gdGhlIEhlYnJldyBhbmQgWWlkZGlzaCBs YW5ndWFnZXM/IFRoZXJlIGFyZSBkZWZpbml0ZWx5DQo+IGRpZmZlcmVuY2VzIGluIHRoZSBjaGFy YWN0ZXIgcmVwZXJ0b2lyZSBhbmQgaW4gdGhlIHVzZSBhbmQNCj4gaW1wb3J0YW5jZSBvZiB2b3dl bCBtYXJrcywgYnV0IEkgZG9uJ3Qga25vdyBhYm91dCBhbnkNCj4gZGlmZmVyZW5jZXMgd2l0aCBy ZXNwZWN0IHRvIGRpcmVjdGlvbmFsaXR5Lg0KDQpPbmx5IGluIHRoZSAidm93ZWwgbWFyayIgaXNz dWUsIGUuZy4sIGFsbCBvZiB0aGUgY29tYmluaW5nIG1hcmsNCmlzc3VlcyB0aGF0IHlvdSBkZXNj cmliZSBpbiB5b3VyIG5vdGUgY2FuIGJlIGF2b2lkZWQgZm9yIEhlYnJldywNCmJ1dCBub3QgZm9y IFlpZGRpc2guDQoNCj4uLi4NCg0KICAgam9obg0KDQoNCg== --===============1458594899== 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 --===============1458594899==-- From ima-bounces@ietf.org Sun Nov 18 20:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvBD-0000sp-Au; Sun, 18 Nov 2007 20:12:03 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItvBC-0000pW-8I for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 20:12:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvBB-0000pO-Tq for ima@ietf.org; Sun, 18 Nov 2007 20:12:01 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItvBB-00041h-HX for ima@ietf.org; Sun, 18 Nov 2007 20:12:01 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 11-md50000000126.tmp for ; Sun, 18 Nov 2007 18:14:48 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Sun, 18 Nov 2007 18:14:48 -0700 Date: Sun, 18 Nov 2007 18:14:48 -0700 From: "Chris Walker" To: "John C Klensin" , "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <0D86890E55B438CC0356D4A3@[192.168.1.110]> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> <0D86890E55B438CC0356D4A3@[192.168.1.110]> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Sun, 18 Nov 2007 18:14:48 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 -----Original Message----- From: John C Klensin To: Chris Walker Cc: eai list Date: Fri, 16 Nov 2007 19:58:50 -0500 Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > That is what I was trying to say about MAILTO. The current > definition prohibits non-ASCII strings. But assume that either > a revision were undertaken or a new, MAILTOO URL was defined, in > either case using ordinary URI rules. One could then prohibit > any local-part from appearing in the URI that started with "%" > (even though it would be valid in a stand-alone email address). > Or one could say that any %NN construction in a MAILTO[O] URL > was a character escape and that any actual occurrence of "%" > would have to be shown as %25, which would be consistent with > the way the specs (both MAILTO and URI) are now written. It > would certainly be sensible to look at that possibility, or the > possibility of some other tagging or restrictions, for a > representation format. Looking at MAILTO _is_ in the WG's > charter and it would be entirely reasonable to have this > discussion when we get to it. Seems ICANN has already moved past that since their IDNA email test pages have UTF8 in the example "Requires full IDN support" mailto links: http://idn.icann.org/E-mail_test Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 20:47:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itvj9-0003DM-B9; Sun, 18 Nov 2007 20:47:07 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Itvj8-0003DF-F8 for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 20:47:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itvj8-0003D2-3g for ima@ietf.org; Sun, 18 Nov 2007 20:47:06 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itvj7-00052x-4m for ima@ietf.org; Sun, 18 Nov 2007 20:47:06 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAJ1l19a004909 for ; Mon, 19 Nov 2007 10:47:01 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4fcc_523b088c_9641_11dc_847d_0014221f2a2d; Mon, 19 Nov 2007 10:47:01 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40070) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2007 10:43:08 +0900 Message-Id: <6.0.0.20.2.20071119091213.07cc1c70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 19 Nov 2007 09:21:59 +0900 To: "Chris Walker" , "John C Klensin", "eai list" From: Martin Duerst Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <6.0.0.20.2.20071116194233.080b1e40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 08:21 07/11/18, Chris Walker wrote: > > >-----Original Message----- >From: Martin Duerst >To: "Chris Walker" , "John C Klensin" >, "eai list" >Date: Fri, 16 Nov 2007 19:52:29 +0900 >Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > >> Hello Chris, >> >> I think John and Harald and others have already tried, but I'll >> try again. I think we understand your scenario, and we know it's >> real. But what is at least as real, and more importantly, already >> possible/happening, is the same problem with names and addresses. >> >> Please take a moment and rewrite your text below and replace >> "email address" with "person's name", or "customer's street address", >> or any such. What you will see is that: >> 1) The problem already exists. >> 2) If companies haven't handled the problem for name or address, >> they are already having problems. If they have handled it, >> they should be able to handle it for email addresses, too. >> > >Hi Martin, > >Are you suggesting that the preferential encoding for an >internationalized email address should be romanized phonomes? No, I'm suggesting that if they already accept input for non-romanized names/addresses, they can also accept non-romanized email addresses (assuming they actually implement EAI). If they don't accept non-romanized names, then they shouldn't accept non-romanized email addresses. The email address will then be whatever ASCII-only address the user will input. This may be a romanized version of an existing non-romanized address, or something completely different, maybe even with a different provider. >The mechanisms of delivery are not the same for names, postal addresses >and email addresses. Names and postal addresses used in the delivery of >postal mail involves a human, where the delivery of an email is expected >to be possible without interpretation by a human. Yes. That doesn't change the fact that a system should only accept what it is able to handle. Automatic conversion from non-ASCII to ASCII only may work in some cases for names and addresses, but in general isn't going to work, even for names and addresses, so it shouldn't be relied on. >> Anyway, as you can see, the problems you mention can already happen. >> If a company can handle them, they should be able to figure out how >> to address non-ASCII email addresses, too (if only by not handling >> them). >> If a company or organization is currently doing a bad job, then >> non-ASCII >> email addresses might give them an incentive to fix some things >> overall. >> > >The issues you notice regarding multiple inclusion or not recognizing >your existing inclusion in a list is in the CRM match, merge, purge >problem space. Even if a fully 8bit end to end system accepted and >preserved UTF8 names and postal addresses, there is a hitch. > >Some people will submit their identifying information in transliterated >or ASCII form. Unless the implementation of the match, merge, purge >functions is internally aware of transliteration and even Latin1 to >ASCII conversions, it will not notice that two names or postal addresses >are the same. Yes. And if somebody in the US registers as Bill Smith and as William Smith, that might not be purged, either. My guess is that match/merge/purge will always to some extent be a black art, i.e. not something that ever will work 100%. >Since many of these conversions are one way streets, i.e. there is no >way to know that Duerst should be D(u umalaut)rst or that you actually >prefer Duerst, all data is usually converted to the most reduced form to >provide the ability to perform matches. > >I wish that applying the best practices for dealing with >internationalized names and postal addresses could be applied to >internationlized email addresses, however the lack of humans in the >delivery process, and the issues you pointed out with Latin1 to ASCII >conversions with umlauts would seem to indicate that a more precise >solution is needed. Yes. But the availability of a standard ACE for internationalized email addresses wouldn't really help. Most people, when asked to input an ASCII-only email address, would certainly prefer to use something like duerst@it.aoyama.ac.jp to something like d$c3%bcrst@it.aoyama.ac.jp (assuming that's a fallback for d(u umalaut)rst@it.aoyama.ac.jp). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 21:24:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwJV-0001Je-8S; Sun, 18 Nov 2007 21:24:41 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItwJQ-0001Hd-VU for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 21:24:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwJQ-0001HV-Kl for ima@ietf.org; Sun, 18 Nov 2007 21:24:36 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItwJQ-0006R9-1A for ima@ietf.org; Sun, 18 Nov 2007 21:24:36 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1ItwJP-000Fdd-Ip; Sun, 18 Nov 2007 21:24:35 -0500 Date: Sun, 18 Nov 2007 21:24:34 -0500 From: John C Klensin To: Chris Walker , eai list Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI Message-ID: In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> <0D86890E55B438CC0356D4A3@[192.168.1.110]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Sunday, 18 November, 2007 18:14 -0700 Chris Walker wrote: >=20 >=20 > -----Original Message----- > From: John C Klensin > To: Chris Walker > Cc: eai list > Date: Fri, 16 Nov 2007 19:58:50 -0500 > Subject: Re: [EAI] Additional Clarification re: Need of an ACE > for EAI >> That is what I was trying to say about MAILTO. The current=20 >> definition prohibits non-ASCII strings. But assume that >> either a revision were undertaken or a new, MAILTOO URL was >> defined, in either case using ordinary URI rules. One could >> then prohibit any local-part from appearing in the URI that >> started with "%" (even though it would be valid in a >> stand-alone email address). Or one could say that any %NN >> construction in a MAILTO[O] URL was a character escape and >> that any actual occurrence of "%" would have to be shown as >> %25, which would be consistent with the way the specs (both >> MAILTO and URI) are now written. It would certainly be >> sensible to look at that possibility, or the possibility of >> some other tagging or restrictions, for a representation >> format. Looking at MAILTO _is_ in the WG's charter and it >> would be entirely reasonable to have this discussion when we >> get to it. >=20 >=20 > Seems ICANN has already moved past that since their IDNA email > test pages have UTF8 in the example "Requires full IDN > support" mailto links: >=20 > http://idn.icann.org/E-mail_test Nope. If you look at RFC 3490, you will see some words about a "domain name slot". An application _may_ choose to accept mailtest@=CF=80=CE=B1=CF=81=CE=AC=CE=B4=CE=B5=CE=B9=CE=B3=CE=BC=CE= =B1.=CE=B4=CE=BF=CE=BA=CE=B9=CE=BC=CE=AE (chosen arbitrarily from the ICANN list) as an address because the Greek strong is in one of those domain name slots. However, without EAI and the UTF8SMTP extension, that application would be very seriously violating RFC 2821 (and other standards) by putting anything other than mailtest@xn--hxajbheg2az3al.xn--jxalpdlp on the wire. The Mailto link is another issue. As a URL, the mailto link for that "full IDN support" column must be represented as=20 mailto:mailtest@%CF%80%CE%B1%CF%81%CE%AC%CE%B4%CE%B5%CE%B9%CE%B3%= CE%BC%CE%B1.%CE%B4%CE%BF%CE%BA%CE%B9%CE%BC%CE%AE which more or less demonstrates my point about just how user-unfriendly automatically-produced ASCII forms that do not lose information can, and will, get. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 22:52:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxgl-0002gK-N2; Sun, 18 Nov 2007 22:52:47 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Itxgk-0002g0-Me for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 22:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxgk-0002fh-C6 for ima@ietf.org; Sun, 18 Nov 2007 22:52:46 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itxgc-0004BS-CK for ima@ietf.org; Sun, 18 Nov 2007 22:52:46 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAJ3qaOv004875 for ; Mon, 19 Nov 2007 12:52:36 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0bc2_ddccaf8e_9652_11dc_981c_0014221fa3c9; Mon, 19 Nov 2007 12:52:35 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53333) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2007 12:48:45 +0900 Message-Id: <6.0.0.20.2.20071119124409.07c89780@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 19 Nov 2007 12:50:33 +0900 To: John C Klensin , Chris Walker , eai list From: Martin Duerst Subject: Re: [EAI] Additional Clarification re: Need of an ACEfor EAI In-Reply-To: References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> <0D86890E55B438CC0356D4A3@[192.168.1.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 11:24 07/11/19, John C Klensin wrote: >The Mailto link is another issue. As a URL, the mailto link >for that "full IDN support" column must be represented as > >mailto:mailtest@%CF%80%CE%B1%CF%81%CE%AC%CE%B4%CE%B5%CE%B9%CE%B3%CE%BC%CE%B1.%CE%B4%CE%BF%CE%BA%CE%B9%CE%BC%CE%AE > >which more or less demonstrates my point about just how >user-unfriendly automatically-produced ASCII forms that do not >lose information can, and will, get. Well, it's actually a bit different. The current mailto: spec does not allow percent-escapes in general, and in particular does not allow them in the domain name 'slot'. Still, several browsers alread allow this, as well as the corresponding IRI. And ICANN is using the IRI form in their example page. I have written a draft to document these changes, but the latest version is over a year old. (see http://tools.ietf.org/html/draft-duerst-mailto-bis-03) I'm planning to update the draft, but that won't happen today, so it won't happen for the next few weeks, because of the deadline. Any comments appreciated. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 23:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ity9S-000474-6o; Sun, 18 Nov 2007 23:22:26 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ity9R-00046z-Ew for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 23:22:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ity9Q-00046r-NU for ima@ietf.org; Sun, 18 Nov 2007 23:22:24 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ity9Q-0002Ky-4C for ima@ietf.org; Sun, 18 Nov 2007 23:22:24 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ity9I-000JxL-63; Sun, 18 Nov 2007 23:22:16 -0500 Date: Sun, 18 Nov 2007 23:22:14 -0500 From: John C Klensin To: Martin Duerst , Chris Walker , eai list Subject: Re: [EAI] Additional Clarification re: Need of an ACEfor EAI Message-ID: <0D4604A5643E1DDEA87BDD7D@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20071119124409.07c89780@localhost> References: <20071113191947.GA16028@laperouse.bortzmeyer.org> <473A0B69.306@alvestrand.no> <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> <0D86890E55B438CC0356D4A3@[192.168.1.110]> <6.0.0.20.2.20071119124409.07c89780@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 19 November, 2007 12:50 +0900 Martin Duerst wrote: > At 11:24 07/11/19, John C Klensin wrote: > > >> The Mailto link is another issue. As a URL, the mailto link >> for that "full IDN support" column must be represented as >> >> mailto:mailtest@%CF%80%CE%B1%CF%81%CE%AC%CE%B4%CE%B5%CE%B9%CE >> %B3%CE%BC%CE%B1.%CE%B4%CE%BF%CE%BA%CE%B9%CE%BC%CE%AE >> >> which more or less demonstrates my point about just how >> user-unfriendly automatically-produced ASCII forms that do not >> lose information can, and will, get. > > Well, it's actually a bit different. The current mailto: spec > does not allow percent-escapes in general, and in particular > does not allow them in the domain name 'slot'. You are, of course, correct. My apologies. > Still, several > browsers alread allow this, as well as the corresponding IRI. > And ICANN is using the IRI form in their example page. > I have written a draft to document these changes, but the > latest version is over a year old. > (see http://tools.ietf.org/html/draft-duerst-mailto-bis-03) > I'm planning to update the draft, but that won't happen today, > so it won't happen for the next few weeks, because of the > deadline. Any comments appreciated. I'm trying very hard to avoid thinking about mailto until the EAI work is essentially complete, partially because of the question of how one might accommodate an alternate address if that were desired. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 18 23:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyHK-0007YL-Cy; Sun, 18 Nov 2007 23:30:34 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ItyHJ-0007Xx-4t for ima-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 23:30:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyHI-0007Xo-QD; Sun, 18 Nov 2007 23:30:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItyHI-0002Un-Eo; Sun, 18 Nov 2007 23:30:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 52F4F2AC5E; Mon, 19 Nov 2007 04:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItyGo-0001Oa-3K; Sun, 18 Nov 2007 23:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 23:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-imap-utf8-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : IMAP Support for UTF-8 Author(s) : P. Resnick, C. Newman Filename : draft-ietf-eai-imap-utf8-02.txt Pages : 15 Date : 2007-11-18 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-imap-utf8-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-imap-utf8-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18232109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-imap-utf8-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-imap-utf8-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18232109.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Nov 19 01:59:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0bh-0006N0-Cv; Mon, 19 Nov 2007 01:59:45 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu0Yv-0004HB-7W for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 01:56:53 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu0Yu-0004H1-TB for ima@ietf.org; Mon, 19 Nov 2007 01:56:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItnGc-0005O7-8F for ima@ietf.org; Sun, 18 Nov 2007 11:45:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItnGb-0004du-HY for ima@ietf.org; Sun, 18 Nov 2007 11:45:06 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1ItnGZ-0005V9-3b for ima@ietf.org; Sun, 18 Nov 2007 16:45:03 +0000 Received: from p5497374a.dip0.t-ipconnect.de ([84.151.55.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Nov 2007 16:45:03 +0000 Received: from GMANE by p5497374a.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Nov 2007 16:45:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: =?UTF-8?B?Q2xhdXMgRsOkcmJlcg==?= Date: Sun, 18 Nov 2007 11:50:46 +0100 Lines: 38 Message-ID: References: <20071116151553.GD14436@afilias.info> <20071116203440.GP14436@afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5497374a.dip0.t-ipconnect.de User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) In-Reply-To: <20071116203440.GP14436@afilias.info> X-Spam-Score: 1.4 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-TMDA-Confirmed: Mon, 19 Nov 2007 01:56:52 -0500 X-Mailman-Approved-At: Mon, 19 Nov 2007 01:59:44 -0500 Subject: [EAI] Re: A potential collision free local part ACE ID X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Andrew Sullivan schrieb: > On Fri, Nov 16, 2007 at 01:16:32PM -0700, Chris Walker wrote: >> The major difference, IDNA was designed and intended to work at the user >> interface level. > > Yes, but it was also intended not to be human-readable. Well, one of its neglected advantages is that it _is_ human-readable. Of course, a user can't read "xn--1lqs71d" and know what it means. However, it _is_ possible to write down the name or read it over the phone. Furthermore, you can easily see that it is different from "xn--1lq90i". The same is not true for "東京" and "北京", especially if the user does not even have the correct fonts and the computer displays them as "??" and "??". In other words, the property that an ACE only uses the Latin LDH repertoire makes it universally human-readable. Unfortunately, this advantageous property of ACEs is neglected by the IDNA specs. It would make sense for user interfaces to show the ASCII version of a label if the computer system or the user lacks the prerequisites to handle or understand the Unicode version (i.e. use toASCII or toUnicode for display, depending on the character repertoire). Consider the following situation: Aiko (living in Japan) sends Bob (living in the US) a message from her email address "愛子＠東京。日", which is her usual email address. Charles (also living in the US) asks Bob what Aiko's email address is. Bob has no idea how to read the characters. Even if Bob could read them, Charles would still have no idea how to type them. However, if Bob's system shows him the address as "xn--i8sr8k@xn--1lqs71d.xn--wgv" (either because it knows Bob can't read Kanji or because Bob told the system so in order to give the address to Charles), he can tell Bob the address (and it's not even that more cryptic than e.g. "st23.mh978@xc.uex.ac.uk"). Claus _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 03:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Eb-0003kr-8C; Mon, 19 Nov 2007 03:44:01 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu2EZ-0003jf-G6 for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 03:43:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2EU-0003e5-7N for ima@ietf.org; Mon, 19 Nov 2007 03:43:54 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu2ET-0005xW-JC for ima@ietf.org; Mon, 19 Nov 2007 03:43:54 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6627E259721; Mon, 19 Nov 2007 09:43:52 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03983-03; Mon, 19 Nov 2007 09:43:46 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 71C7425971F; Mon, 19 Nov 2007 09:43:45 +0100 (CET) Message-ID: <47414CC0.1060200@alvestrand.no> Date: Mon, 19 Nov 2007 09:43:44 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: daniel@taharlev.com Subject: Re: [EAI] Another subject: left-to-right languages References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost><7BE501728E934C7C6821DB8F@p3.JCK.COM> <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> In-Reply-To: <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> 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: 8abaac9e10c826e8252866cbe6766464 Cc: Felix Sasaki , eai list , Richard Ishida X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Daniel Taharlev wrote: > With regards to what John said, let's make it even more interesting. In Hebrew, the letter "Beit" can sound as a "B" or as a "V" -- depending on if it has a "dagesh" -- a little dot -- in it. That dot is part of the letter; however, when typing, one of the common solutions is to actually add the "dagesh" character right after the letter, where the system font basically has a setting saying "this special character needs to be embedded into the previous letter." The dotted letter appears in the charset as a unique ascii code, but is never used -- you'll always use the font trick. > > Now, if an smtp connection is created, it transmits the characters one by one; the server can know how to embed the character into the display, but will that make "b@domain.com" a different email address than "b(with a dagesh@domain.com"? For Hebrew speakers, that's like having cursive-written addresses different from printed addresses. One can easily take advantage of that, posing as someone else, by adding a small dot into their username -- which is even harder to detect that a phishing site taking advantage mistyping "google" as "googel". We're happily leaving all those details to the gentle hands of the Unicode Consortium, which has normatively stated that HEBREW LETTER BET WITH DAGESH is a single character with codepoint 0xFB31, but this character is excluded from being normalized to, so the correct representation for anyone, whether they use NFC, NFKC or NFD, is 0x05D1 (BET) followed by 0x05BC (DAGESH OR MAPIQ). So, as far as the standards are concerned, BET+DAGESH is 2 characters, and BET WITH DAGESH is one character. It is up to the sysadmin to decide whether BET, BET+DAGESH and BET WITH DAGESH, when occuring on the left-hand side, all get delivered to the same mailbox; it is up to the administrators of the zones allowing Hebrew character registration to decide whether or not to allow the registration of BET and BET+DAGESH to different entities or not. One interesting aspect is that we've studiously avoided having the standards require that normalization be applied to the left hand side of the email address, while the current IDNA specs require the use of NFKC, so BET WITH DAGESH is allowed by the standards on the left hand side, but not on the right hand side. Any sysadmin who consciously creates unnormalized mailboxes is, in my opinion, making a really stupid decision, but our job is not to try to forbid stupidity. (ASCII spaces in mailbox names are stupid too, but the base standards have always allowed them, if quoted.) Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 03:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Mf-0005tM-K0; Mon, 19 Nov 2007 03:52:21 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu2Me-0005rt-JN for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 03:52:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Me-0005ra-8b for ima@ietf.org; Mon, 19 Nov 2007 03:52:20 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu2MP-0006jG-B5 for ima@ietf.org; Mon, 19 Nov 2007 03:52:20 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 784CE4ACA0 for ; Mon, 19 Nov 2007 09:52:14 +0100 (CET) Message-Id: Date: Mon, 19 Nov 2007 09:52:18 +0100 From: Arnt Gulbrandsen To: eai list Subject: Re: [EAI] Another subject: left-to-right languages References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost> <7BE501728E934C7C6821DB8F@p3.JCK.COM> <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> <47414CC0.1060200@alvestrand.no> In-Reply-To: <47414CC0.1060200@alvestrand.no> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org There is one issue I don't understand, the cs.ox.ac.uk/uk.ac.ox.cs thing. Suppose two domains exist, which are rendered as asdf.gh anf qwer.ty. (Pretend asdf and qwer is right-to-left and gh and ty left-to-right.) Now a user at qwer.ty gets a localpart of gh.asdf and a user at qwer.yu a localpart of gh.asdf.gh. IIRC the @ doesn't have directionality, so @ the unicode bidi algorithm will render those in the same way. (I have a cold and can't think quite straight. Maybe the localparts have to be rewq.ty or ty.qwer or ty.rewq or something. But I'm sure you can see the problem.) Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 05:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4IO-0007M8-Gz; Mon, 19 Nov 2007 05:56:04 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu4IN-0007M2-G6 for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 05:56:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4IN-0007Lt-5H for ima@ietf.org; Mon, 19 Nov 2007 05:56:03 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu4IM-0007j7-BA for ima@ietf.org; Mon, 19 Nov 2007 05:56:03 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAJAtwPZ004180 for ; Mon, 19 Nov 2007 19:55:58 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0b52_02a6dfec_968e_11dc_9b12_0014221fa3c9; Mon, 19 Nov 2007 19:55:58 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51580) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2007 19:52:07 +0900 Message-Id: <6.0.0.20.2.20071119181006.07c24d60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 19 Nov 2007 18:23:25 +0900 To: Arnt Gulbrandsen , eai list From: Martin Duerst Subject: Re: [EAI] Another subject: left-to-right languages In-Reply-To: References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost> <7BE501728E934C7C6821DB8F@p3.JCK.COM> <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> <47414CC0.1060200@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 17:52 07/11/19, Arnt Gulbrandsen wrote: >There is one issue I don't understand, the cs.ox.ac.uk/uk.ac.ox.cs thing. > >Suppose two domains exist, which are rendered as asdf.gh anf qwer.ty. (Pretend asdf and qwer is right-to-left and gh and ty left-to-right.) To make things clearer, the convention among Bidi experts is to use upper-case for RTL, so that would be ASDF.gh and QUER.ty, yes? Can we assume that the order written here is logical, given that these are the sequences as we find them on a keyboard? >Now a user at qwer.ty gets a localpart of gh.asdf and a user at qwer.yu a localpart of gh.asdf.gh. Okay, so we have: Local part: Domain: gh.ASDF QUER.ty gh.ASDF.gh QUER.yu Still assuming these are logical. >IIRC the @ doesn't have directionality, so @ the unicode bidi algorithm will render those in the same way. Seems you may have intended a sligthly different example: A user at QUER.ty gets a local part of gh.ASDF, and a user at ASDF.gh gets a local part of ty.QUER. Logically, this would produce the following two addresses: a) gh.ASDF@QUER.ty b) ty.QUER@ASDF.gh If we apply Section 4 of the IRI spec (RFC 3987) to this, we would get visual displays reading: a) gh.REUQ@FDSA.ty b) ty.FDSA@REUQ.gh So we definitely get two different things. >(I have a cold and can't think quite straight. Zigzag thinking is much more important for Bidi problems than straight thinking :-). >Maybe the localparts have to be rewq.ty or ty.qwer or ty.rewq or something. But I'm sure you can see the problem.) You mean that there is a problem that two different logical sequences of characters can render in the same way? Such situations are possible, but they have to involve components starting or ending with digits or mixed components (components containing both RTL and LTR characters). That's the reason why IDNA prohibits the mixing of RTL and LTR characters in a single label (the IRI spec does the same but uses the term component to be more general). That's also why both the IDNA spec and the IRI spec prohibit digits at the start or the end of an RTL compontent/label. Unfortunately, it was not possible to prohibit digits at the start or the end of an LTR component/label, because these already existed. So there is still a chance to create havoc. For the update of the IRI spec, I have been asked to add another example to explain this case and say that it's a bad idea to have e.g. a digit at the end of an LTR component next to a RTL component. Regards, Martin.s #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 07:12:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5UX-0007NR-Ol; Mon, 19 Nov 2007 07:12:41 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu5UV-0007Kl-N0 for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:12:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5UV-0007KN-Ch for ima@ietf.org; Mon, 19 Nov 2007 07:12:39 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu5US-0004eC-M0 for ima@ietf.org; Mon, 19 Nov 2007 07:12:39 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6015259718; Mon, 19 Nov 2007 13:12:35 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09286-04; Mon, 19 Nov 2007 13:12:29 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D651259717; Mon, 19 Nov 2007 13:12:28 +0100 (CET) Message-ID: <47417DAB.3010106@alvestrand.no> Date: Mon, 19 Nov 2007 13:12:27 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [EAI] Another subject: left-to-right languages References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost> <7BE501728E934C7C6821DB8F@p3.JCK.COM> <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> <47414CC0.1060200@alvestrand.no> <6.0.0.20.2.20071119181006.07c24d60@localhost> In-Reply-To: <6.0.0.20.2.20071119181006.07c24d60@localhost> 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > >> Maybe the localparts have to be rewq.ty or ty.qwer or ty.rewq or something. But I'm sure you can see the problem.) >> > > You mean that there is a problem that two different logical sequences > of characters can render in the same way? Such situations are possible, > but they have to involve components starting or ending with digits or > mixed components (components containing both RTL and LTR characters). > That's the reason why IDNA prohibits the mixing of RTL and LTR characters > in a single label (the IRI spec does the same but uses the term component > to be more general). That's also why both the IDNA spec and the IRI > spec prohibit digits at the start or the end of an RTL compontent/label. > Unfortunately, it was not possible to prohibit digits at the start or > the end of an LTR component/label, because these already existed. > So there is still a chance to create havoc. For the update of the IRI > spec, I have been asked to add another example to explain this case > and say that it's a bad idea to have e.g. a digit at the end of an > LTR component next to a RTL component. The first interesting example I found when working on my bidi draft was this: a.12-34.b -> a.12-34.b A.12-34.B -> B.34-12.A again using the "uppercase is RTL" convention. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 07:25:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5gf-0000Eb-5s; Mon, 19 Nov 2007 07:25:13 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu5ge-0000Db-6t for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:25:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5gd-0000DD-Si for ima@ietf.org; Mon, 19 Nov 2007 07:25:11 -0500 Received: from p54994961.dip.t-dialin.net ([84.153.73.97] helo=[192.168.0.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu5gd-0003TI-Dc for ima@ietf.org; Mon, 19 Nov 2007 07:25:11 -0500 Message-Id: <+IfTXymFbpmbdENrxg6o1w.md5@[192.168.0.20]> Date: Mon, 19 Nov 2007 13:18:02 +0100 From: Arnt Gulbrandsen To: eai list Subject: Re: [EAI] Another subject: left-to-right languages References: <813098865-1195420070-cardhu_decombobulator_blackberry.rim.net-1410454013-@bxe121.bisx.prod.on.blackberry> <6.0.0.20.2.20071119082806.073d4a40@localhost> <7BE501728E934C7C6821DB8F@p3.JCK.COM> <1023408057-1195433409-cardhu_decombobulator_blackberry.rim.net-1690685905-@bxe121.bisx.prod.on.blackberry> <47414CC0.1060200@alvestrand.no> <6.0.0.20.2.20071119181006.07c24d60@localhost> In-Reply-To: <6.0.0.20.2.20071119181006.07c24d60@localhost> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Martin Duerst writes: > You mean that there is a problem that two different logical sequences > of characters can render in the same way? Yes. Actually that an attacker might construct an address which is rendered like the victim's. > Such situations are possible, but they have to involve components > starting or ending with digits or mixed components (components > containing both RTL and LTR characters). Could you elaborate? (I'm really dense today, I'm afraid.) Which characteristics must the victim's address have in order to be attackable? Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 07:48:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu63Z-00046r-UU; Mon, 19 Nov 2007 07:48:53 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu63Z-00046k-8l for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:48:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu63Y-00045z-V7 for ima@ietf.org; Mon, 19 Nov 2007 07:48:52 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu63U-0006QQ-E6 for ima@ietf.org; Mon, 19 Nov 2007 07:48:52 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Iu63T-000DvT-Cn; Mon, 19 Nov 2007 07:48:48 -0500 Date: Mon, 19 Nov 2007 07:48:46 -0500 From: John C Klensin To: =?UTF-8?Q?Claus_F=C3=A4rber?= , ima@ietf.org Subject: Re: [EAI] Re: A potential collision free local part ACE ID Message-ID: In-Reply-To: References: <20071116151553.GD14436@afilias.info> <20071116203440.GP14436@afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 Sunday, 18 November, 2007 11:50 +0100 Claus F=C3=A4rber wrote: > In other words, the property that an ACE only uses the Latin > LDH repertoire makes it universally human-readable. > Unfortunately, this advantageous property of ACEs is neglected > by the IDNA specs. This has been, as you have probably guessed, generally noticed, and is discussed to some extent in RFC 4690. > It would make sense for user interfaces to show the ASCII > version of a label if the computer system or the user lacks > the prerequisites to handle or understand the Unicode version > (i.e. use toASCII or toUnicode for display, depending on the > character repertoire). Unfortunately, there are three problems that make this less useful than it would appear on first glance: (1) With contemporary operating systems, it is often hard to know whether or not a character can be displayed. There are often no system calls to inquire whether a given character will reach the display or be turned into the dreaded boxes or question marks. Even if such calls existed, it is unlikely that it would be wise to cause the overhead of invoking them. One simply sends a string off to the display routine (printf or equivalent) and hopes for the best. If one always displayed the ASCII version when one could not be certain that the native form would not be messed up, one would basically always display an ACE except when the application was localized to a particular language and font set that matched the script of all of the characters in the label (note that IE7 applies a variation on that rule -- I don't like what they do for other reasons, but it does have some logic). (2) A large fraction of the argument for IDNs, especially IDNs at the top level, has come from communities who haven't said "we prefer to write names in our native script" but from those who have said "our populations don't read or understand Roman-based characters". This is not the right place to argue how often the latter claim is consistent with the facts: there are places in the world where it certainly is. For those populations, an ASCII-based Internet is essentially inaccessible and forcing strings to ASCII forms in order to make them more clear to you or me is a disastrously bad policy. Those of us who speak and write in languages whose scripts are of Western European origin need to keep reminding ourselves that there is nothing that makes those scripts -- particularly the Roman-based ones-- especially "special" or gives them a right to primacy. It is the result of a series of historical accidents that email and domain names weren't defined first in locations that would have resulted in our now talking about, e.g., KCEs, TCEs, or HCEs (Kana, Thai, or Hangul-based encodings, respectively) instead of ACEs (Han-based characters are deliberately not on that list, although I suppose one could pick a small subset). (3) The email problem with ACE-on-the-wire approaches -- approaches that would correspond to the IDNA strategy, but not necessarily what Chris needs -- is that the rules for what can appear in an email local-part are so general, and so widely exploited, that there is no way to design an ACE that would be automatically recognized as such so it could be decoded without loss of information. While one might be able to navigate that problem, such as by requiring an SMTP extension to say "this is an ACE and should be interpreted as such" rather than "this address might be fairly unrestricted UTF-8", we also have a long history in the ASCII email world of structuring local parts. The reason for the "no one before the delivery MTA gets to interpret the local part" rule is because nothing else can tell, in the general case, whether abc%20f.gh@example.com is * an attempt to specify a routing * an attempt to indicate an embedded space in an address that is more robust than quoting or * just an address. or whether /S=3Dbloggs/P=3Djoe/PRMD=3Dmoss-covered/ADMD=3Duniversitymail /C=3DSlobbovia@somewhere.example.net is * a (probably-botched .. my memory is fading) X.400 address and gateway. * a slightly-strange pathname in some operating system * an indirect reference to the address associated with an X.500 certificate or * just an address or whether john+ietf@example.net is * local routing information * local classification and filtering information used to match the sender on a "match or treat as bad spam" basis or * just an address or whether johnXietf@example.net is * just like the above, only with a different delimiter or * just an address or whether fredchem@someu.example.edu is * routing information that is equivalent to what others might write as fred%chem@someu.example.edu or chem!fred@someu.example.edu or even "chem fred"@someu.example.edu with, in any case, the boundary determined not by delimiter but by fixed-length substrings or * just an address or whether joe.blogs@example.widget.de is * a first-name and last-name combination * another attempt at routing * the user-friendly form of an X.400 distinguished name or * just an address Now, if one can't tell by looking at a string (and do so with complete accuracy), whether it is an ACE or a local part with internal syntax and semantics, then one has a choice about the design for non-ASCII local parts: * Don't try to play the ACE game. * Forbid structured addresses, such as those above, if there are any non-ASCII characters present. Or restrict the structuring to some fairly simple forms that use ASCII delimiters, excluding the substring case (last example above) entirely and making things a little complicated if the non-ASCII characters are RtoL (see the examples and discussion in Martin's recent note). Offering the user or administrator of a system where non-ASCII addresses would seem normal a choice between non-ASCII local parts and functionality seems inappropriate, especially if one accepts the position that, as we move forward, we should, insofar as possible, stop treating ASCII as occupying a privileged position. > Consider the following situation: Aiko (living in Japan) sends > Bob (living in the US) a message from her email address > = "=E6=84=9B=E5=AD=90=EF=BC=A0=E6=9D=B1=E4=BA=AC=E3=80=82=E6=97=A5"= , which is her usual email address. > Charles (also living in the US) asks Bob what Aiko's email > address is. Bob has no idea how to read the characters. Even > if Bob could read them, Charles would still have no idea how > to type them. However, if Bob's system shows him the address > as "xn--i8sr8k@xn--1lqs71d.xn--wgv" (either because it knows > Bob can't read Kanji or because Bob told the system so in > order to give the address to Charles), he can tell Bob the > address (and it's not even that more cryptic than e.g. > "st23.mh978@xc.uex.ac.uk"). For better or worse, if Aiko wants to hear from Charles (and reads a language that Charles can write), Bob is likely to have to ask her for an address that Charles can use. Or Charles is likely to have to ask her out-of-band. Remember that you are assuming that Aiko reads English and is willing to use it to communicate with Bob and, presumably, Charles. That is the hard problem because, if she does not, or is not willing, then they will either have to decide they don't want to communicate with her or they will need to either learn Japanese or find translators. Conversely, if Aiko does want to carry on correspondence with people who are ignorant of Japanese, she would be well-advised to maintain an ASCII address alias. And, just to stress again that we are trying to design for a world in which internationalization means just that, rather than "ASCII with some tricks for other characters and scripts", if Aiko has also learned to read and write Hindi and wants to carry on a correspondence with colleagues in India who don't read or write English, she would be well-advised to maintain a Devanagari address alias as well. If she wants to send the _same_ message to both her Indian colleague and to Bob and Charles, who are ignorant of each other's languages, she is likely to rediscover the original reason why multipart/alternative was invented. That, however, is another issue, as is the question of how they respond in a way that each other can read. No one has claimed this is going to be easy or completely smooth when messages (or addresses) cross from one language community into another. I think that, for practical reasons having more to do with content than with addressing, we will actually see little of that sort of crossover. People will find languages that they have in common to communicate (just as they do today), will maintain mail aliases that match those languages, and will use aliases that match the content in incoming and outgoing mail. Probably, because of the existing prevalence, in international trade and related communications, of the ASCII subset of the script used to write English, and because in many parts of the world, people are better at learning English as a second language than many native English-speakers are good at learning any second language (especially ones that use a different script), a very large fraction of the communications that cross language community boundaries will be in ASCII, using ASCII addresses. But we shouldn't have protocols that make that choice for them, or make it permanent. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 11:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9VU-0003Lm-21; Mon, 19 Nov 2007 11:29:56 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu9VS-0003LS-6w for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:29:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9VR-0003KW-AD for ima@ietf.org; Mon, 19 Nov 2007 11:29:53 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu9VO-0005Dh-K0 for ima@ietf.org; Mon, 19 Nov 2007 11:29:51 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 25-md50000000141.tmp for ; Mon, 19 Nov 2007 09:32:41 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Mon, 19 Nov 2007 09:32:40 -0700 Date: Mon, 19 Nov 2007 09:32:40 -0700 From: "Chris Walker" To: "John C Klensin" , "eai list" Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: References: <95C14430286E5144A3531138@p3.JCK.COM> <57461FEE10B88691128F22A4@p3.JCK.COM> <0D86890E55B438CC0356D4A3@[192.168.1.110]> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Mon, 19 Nov 2007 09:32:41 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 John If you look at the HTML source for http://idn.icann.org/E-mail_test you will see that there are UTF8 mailto links, not escaped. Which are congruent with the UTF8 http links at http://idn.icann.org/Main_Page I'm trying yo understand what the point would be of keeping the mailto URI escaped in the future? Chris -----Original Message----- From: John C Klensin To: Chris Walker , eai list Date: Sun, 18 Nov 2007 21:24:34 -0500 Subject: Re: [EAI] Additional Clarification re: Need of an ACE for EAI > > > --On Sunday, 18 November, 2007 18:14 -0700 Chris Walker > wrote: > > > > > > > -----Original Message----- > > From: John C Klensin > > To: Chris Walker > > Cc: eai list > > Date: Fri, 16 Nov 2007 19:58:50 -0500 > > Subject: Re: [EAI] Additional Clarification re: Need of an ACE > > for EAI > >> That is what I was trying to say about MAILTO. The current > >> definition prohibits non-ASCII strings. But assume that > >> either a revision were undertaken or a new, MAILTOO URL was > >> defined, in either case using ordinary URI rules. One could > >> then prohibit any local-part from appearing in the URI that > >> started with "%" (even though it would be valid in a > >> stand-alone email address). Or one could say that any %NN > >> construction in a MAILTO[O] URL was a character escape and > >> that any actual occurrence of "%" would have to be shown as > >> %25, which would be consistent with the way the specs (both > >> MAILTO and URI) are now written. It would certainly be > >> sensible to look at that possibility, or the possibility of > >> some other tagging or restrictions, for a representation > >> format. Looking at MAILTO _is_ in the WG's charter and it > >> would be entirely reasonable to have this discussion when we > >> get to it. > > > > > > Seems ICANN has already moved past that since their IDNA email > > test pages have UTF8 in the example "Requires full IDN > > support" mailto links: > > > > http://idn.icann.org/E-mail_test > > Nope. If you look at RFC 3490, you will see some words about a > "domain name slot". An application _may_ choose to accept > mailtest@παράδειγμα.δοκιμή (chosen arbitrarily > from the ICANN list) as an address because the Greek strong is > in one of those domain name slots. However, without EAI and > the UTF8SMTP extension, that application would be very seriously > violating RFC 2821 (and other standards) by putting anything > other than mailtest@xn--hxajbheg2az3al.xn--jxalpdlp on the wire. > > > The Mailto link is another issue. As a URL, the mailto link > for that "full IDN support" column must be represented as > > mailto:mailtest@%CF%80%CE%B1%CF%81%CE%AC%CE%B4%CE%B5%CE%B9%CE%B3%CE%BC% > CE%B1.%CE%B4%CE%BF%CE%BA%CE%B9%CE%BC%CE%AE > > which more or less demonstrates my point about just how > user-unfriendly automatically-produced ASCII forms that do not > lose information can, and will, get. > > john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 11:44:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9jE-0005em-Es; Mon, 19 Nov 2007 11:44:08 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iu9jD-0005e8-Bc for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:44:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9jC-0005dr-W7 for ima@ietf.org; Mon, 19 Nov 2007 11:44:07 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu9jC-0006f2-IP for ima@ietf.org; Mon, 19 Nov 2007 11:44:06 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 37-md50000000141.tmp for ; Mon, 19 Nov 2007 09:46:57 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Mon, 19 Nov 2007 09:46:56 -0700 Date: Mon, 19 Nov 2007 09:46:56 -0700 From: "Chris Walker" To: "John C Klensin" , "Claus =?iso-8859-1?Q?F=C3=A4rber?=" , ima@ietf.org Subject: Re: [EAI] Re: A potential collision free local part ACE ID MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: References: <20071116151553.GD14436@afilias.info> <20071116203440.GP14436@afilias.info> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Mon, 19 Nov 2007 09:46:57 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 -----Original Message----- From: John C Klensin To: Claus Färber , ima@ietf.org Cc: Date: Mon, 19 Nov 2007 07:48:46 -0500 Subject: Re: [EAI] Re: A potential collision free local part ACE ID > For better or worse, if Aiko wants to hear from Charles (and > reads a language that Charles can write), Bob is likely to have > to ask her for an address that Charles can use. Or Charles is > likely to have to ask her out-of-band. Remember that you are > assuming that Aiko reads English and is willing to use it to > communicate with Bob and, presumably, Charles. That is the > hard problem because, if she does not, or is not willing, then > they will either have to decide they don't want to communicate > with her or they will need to either learn Japanese or find > translators. Conversely, if Aiko does want to carry on > correspondence with people who are ignorant of Japanese, she > would be well-advised to maintain an ASCII address alias. And, > just to stress again that we are trying to design for a world in > which internationalization means just that, rather than "ASCII > with some tricks for other characters and scripts", if Aiko has > also learned to read and write Hindi and wants to carry on a > correspondence with colleagues in India who don't read or write > English, she would be well-advised to maintain a Devanagari > address alias as well. I'm afraid that the concept of maintaining an email address for each language or script that one may wish to communicate in the body of a message is, how you you say it? A non starter. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 12:15:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuADQ-0004Pz-Rv; Mon, 19 Nov 2007 12:15:20 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuAD9-00040e-TY for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 12:15:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuAD9-00040E-H0; Mon, 19 Nov 2007 12:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuAD8-0002TM-AV; Mon, 19 Nov 2007 12:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2B37F327BC; Mon, 19 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuAD8-0002o5-0f; Mon, 19 Nov 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 12:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-08.txt Pages : 17 Date : 2007-11-19 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19112313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19112313.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Nov 19 13:10:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB4x-0001UF-H0; Mon, 19 Nov 2007 13:10:39 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuB4v-0001S4-VV for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:10:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB4v-0001QN-H5 for ima@ietf.org; Mon, 19 Nov 2007 13:10:37 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuB4v-00073o-7X for ima@ietf.org; Mon, 19 Nov 2007 13:10:37 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 19 Nov 2007 10:10:14 -0800 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Mon, 19 Nov 2007 10:10:35 -0800 From: Shawn Steele To: "ima@ietf.org" Date: Mon, 19 Nov 2007 10:10:35 -0800 Thread-Topic: spoofing Thread-Index: AQHIKtd7e0ANXFsjJ02YfrbdIeQxyA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] spoofing X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Re the RTL and general spoofing discussion: I think that for the domain name part of the address, the DNS system and ID= N RFCs covers the behavior. For the local name the local authority will need to make sure that they ass= ign reasonable names. Names can't be spoofed if the person creating locale= names doesn't allow them. I think that recommendations for such registrat= ions could follow whatever guidelines are appropriate for them. FWIW: This is a problem even in ASCII: rnicrosoft looks a lot like microso= ft in many fonts. Many browsers fix the rn/n problem by choosing an approp= riate font, but email is often "prettier". - Shawn Shawn Steele SSDE Windows International Microsoft.Net Microsoft _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 13:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB8S-0003ei-A6; Mon, 19 Nov 2007 13:14:16 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuB8R-0003ap-0D for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:14:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB8Q-0003af-Ew for ima@ietf.org; Mon, 19 Nov 2007 13:14:14 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuB8N-0000Ih-3I for ima@ietf.org; Mon, 19 Nov 2007 13:14:14 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IuB8L-0002DW-5q; Mon, 19 Nov 2007 13:14:09 -0500 Date: Mon, 19 Nov 2007 13:14:06 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Subject: Re: [EAI] spoofing Message-ID: <98C062BC4275D510B34683BB@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 19 November, 2007 10:10 -0800 Shawn Steele wrote: > Re the RTL and general spoofing discussion: > > I think that for the domain name part of the address, the DNS > system and IDN RFCs covers the behavior. > > For the local name the local authority will need to make sure > that they assign reasonable names. Names can't be spoofed if > the person creating locale names doesn't allow them. I think > that recommendations for such registrations could follow > whatever guidelines are appropriate for them. > > FWIW: This is a problem even in ASCII: rnicrosoft looks a lot > like microsoft in many fonts. Many browsers fix the rn/n > problem by choosing an appropriate font, but email is often > "prettier". Shawn, Exactly. And thanks. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 14:23:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCDS-0000rv-Do; Mon, 19 Nov 2007 14:23:30 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuCDR-0000rQ-93 for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:23:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCDQ-0000rG-M2 for ima@ietf.org; Mon, 19 Nov 2007 14:23:28 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuCDP-00066o-Dh for ima@ietf.org; Mon, 19 Nov 2007 14:23:28 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 28-md50000000144.tmp for ; Mon, 19 Nov 2007 12:26:20 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Mon, 19 Nov 2007 12:26:20 -0700 Date: Mon, 19 Nov 2007 12:26:20 -0700 From: "Chris Walker" To: "eai list" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Mon, 19 Nov 2007 12:26:20 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [EAI] A collision free ACE for internationlized email addresses X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org So many examples that purport to demonstrate why an internationalized email address cant be ACE encoded have relied on examples that are really only encodings of the local PART. Why did I capitalize part, to reinforce the concept that the local part is part of an email address, the other side of the @ sign, of course with the domain part, together they constitute an email address. Due to vulgarities of technology, and long standing tradition that IETF documents minimally appear in text, Ill assume 7bit text; I will use examples with short strings of internationalized characters represented in U+hex notation. Additionally, local parts, even in UTF8 examples will be quoted and contain a period character. First what can NON internationalized email addresses look like: "a.b"@a.b.com "a.b"@[192.168.44.239] (non routable IP chosen for example) "a.b"@[2001:0db8:0000:0000:0000:0000:1428:57ab] (non zero collapsed IPv6) and non internationalized email addresses with internationalized domain parts: "a.b"@ U+90F5 U+4EF6 . U+5546 U+52D9 (actual UTF8 characters represented by U+hex) "a.b"@ xn--5nqv22n.xn--lhr59c (same domain part as above, in ACE form) All of the above addresses are capable of transmission over STMP, the internationalized domain one, only in its ACE form. Whether or not these addresses will be accepted, understood by the email server, or displayed properly is NOT the point here, they are, capable of being transmitted over the SMTP protocol by virtue of being in 7bit ASCII or having a 7bit ASCII representation. Now much has been said on the topic of it not being possible to represent internationalized email addresses in an ACE form due to the extreme flexibility of what is considered valid or legal in the local part of existing email addresses. In other words, there is no way to encode a local part into an ACE that might not be a valid existing address already. However, encoding just the local part is not really encoding an internationalized email address is it? It is only encoding part of one part of it, the local part. What happens if we attempt to encode the entire address? The following are examples of internationalized email addresses, same as above with UTF8 local parts. "U+4EF6 . U+5546"@a.b.com "U+4EF6 . U+5546"@[192.168.44.239] (non routable IP chosen for example) "U+4EF6 . U+5546"@[2001:0db8:0000:0000:0000:0000:1428:57ab] (non zero collapsed IPv6) "U+4EF6 . U+5546"@ U+90F5 U+4EF6 . U+5546 U+52D9 "U+4EF6 . U+5546"@ xn--5nqv22n.xn--lhr59c (same domain part as above, in ACE form) Can these be encoded in such a way that the resulting encodings cannot possibly be valid email addresses; in order to prevent the accidental delivery of an email to the wrong party should a system attempt to use them in their encoded form? Encodings need an identifier to make them readily recognizable as encodings, I will choose an identifier that is similar to the one used for punycode ACEs, with a twist, it will be a trailing the encoded string instead of leading it. Why, because the characteristic of the punycode IDN ACE that makes it an invalid non encoded domain name the -- characters, will appear on the domain side of the encoded email address and will make the resulting encoding invalid as a non encoded email address. Encoding is punycode. So the list of addresses above with their encoded representations are: Original: "U+4EF6 . U+5546"@a.b.com Encoded: "."@a.b.com-x00rr07d--yn Decoded: "U+4EF6 . U+5546"@a.b.com Original: "U+4EF6 . U+5546"@[192.168.44.239] (non routable IP chosen for example) Encoded: "."@[192.168.44.239]-wl85a2z4g--yn Decoded: "U+4EF6 . U+5546"@[192.168.44.239] Original: "U+4EF6 . U+5546"@[2001:0db8:0000:0000:0000:0000:1428:57ab] (non zero collapsed IPv6) Encoded: "."@[2001:0db8:0000:0000:0000:0000:1428:57ab]-1i86ed23j--yn Decoded: "U+4EF6 . U+5546"@[2001:0db8:0000:0000:0000:0000:1428:57ab] Original: "U+4EF6 . U+5546"@ U+90F5 U+4EF6 . U+5546 U+52D9 (actual UTF8 characters represented by U+hex) Encoded: "."@.-mn2hd570ftyfea0819n--yn Decoded: "U+4EF6 . U+5546"@ U+90F5 U+4EF6 . U+5546 U+52D9 Original: "U+4EF6 . U+5546"@ xn--5nqv22n.xn--lhr59c (same domain part as above, in ACE form) Encoded: "."@ xn--5nqv22n.xn--lhr59c -zr98bg78--yn Decoded: "U+4EF6 . U+5546"@ xn--5nqv22n.xn--lhr59c You get out of the encoding exactly what you put into it. In all cases internationlized email addresses are input, the resulting encodings have no possibility of being existing email addresses, and when decoded, the result is identical to the original. So what does this mean? a) It is possible to provide an ASCII Compatible Encoding (ACE) for internationalized email addresses. b) The resulting ACE is detectable by a single rule, that is it ends in "--yn" c) The encoded forms cannot be existing email addresses. At this point, this provides a perfectly valid encoding. And if any of the following is disregarded, this should be considered for inclusion as a suggested part of the standard. What else does the above imply? Well, the two main arguments that were used to support UTF8SMTP are that no encoding is possible, and that is an encoding were possible, the leaking, that is the encoding being seen by users; users would find this, quoting RFC 4952, discomfiting or astonishing. Well, UTF8SMTP provides no lack of discomfiting or astonishing features. The downgraded headers that preserve the original UTF8 email address provide their own encoding and leaks to the user. I, also being a user, find the entire alt address concept, having to have them and knowing when and where to use them, both discomfiting and astonishing in the extreme. The entire UTF8SMTP design, and all of its baggage, serves no purpose than to accommodate UTF8 characters of the left side of the @ sign in email addresses. UTF8SMTP fails on both leaking and by being discomfiting and astonishing. A different EAI design that uses the ACE form above where email addresses appear in SMTP headers should be considered. Such a design has the potential to eliminate alt addresses and downgrading. Such a design would not be transparent to existing email servers, they would need to be aware of the encoding, just as they would need to be aware of internationalized domain name encoding to resolve names using DNS. After going down the existing UTF8SMTP design path far enough to see its implications, all I ask is that you take some time to reconsider if its complexity is worth it consideriing it is lacking on meeting design goals. I am sure the first argument I will hear over this idea has something to do with leaking, as I already pointed out, UTF8SMTP already leaks. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 17:24:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF2Z-0005Zr-Um; Mon, 19 Nov 2007 17:24:27 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuF2W-0005XU-6m for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:24:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF2V-0005XK-JI for ima@ietf.org; Mon, 19 Nov 2007 17:24:23 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF2R-0006f5-TB for ima@ietf.org; Mon, 19 Nov 2007 17:24:23 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 409AC259718 for ; Mon, 19 Nov 2007 23:24:19 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25592-08 for ; Mon, 19 Nov 2007 23:24:14 +0100 (CET) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB484259717 for ; Mon, 19 Nov 2007 23:24:13 +0100 (CET) Date: Mon, 19 Nov 2007 23:21:46 +0100 From: Harald Tveit Alvestrand To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [EAI] Second Last Call - EAI protocol core 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 This is the second Last Call for the following documents: draft-ietf-eai-utf8headers-08.txt draft-ietf-eai-dsn-05.txt draft-ietf-eai-smtpext-09.txt As is common for a second Last Call, the question that is being asked is whether or not the changes done resolved the issues raised, or if the changes have raised new issues. This is not a call for opening new issues with the unchanged text of the documents. We know that some people (notably Frank and Charles) disagree with some of the resolutions in these documents. In order to verify that the consensus is with the documents as presented, I'm asking people who have reviewed the changes and agree with them to say so, rather than just going by "silence is consent". This second Last Call will last for one week, ending on November 26, 2007. We will take advantage of the WG meeting in Vancouver to discuss any issues for which we don't have resolution on the mailing list. If there are no such issues, we may send the documents to the IESG asking for an IETF-wide Last Call even before the meeting. Harald, acting as WG chair _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 20:04:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuHXZ-0003Ss-1x; Mon, 19 Nov 2007 20:04:37 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuHXY-0003Sn-7r for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 20:04:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuHXX-0003Sf-TS for ima@ietf.org; Mon, 19 Nov 2007 20:04:35 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuHXT-0001j7-Sa for ima@ietf.org; Mon, 19 Nov 2007 20:04:35 -0500 Received: (snipe 1584 invoked by uid 0); 20 Nov 2007 10:04:40 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.591725 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 20 Nov 2007 10:04:39 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: cw-eai-ietf@iespresio.com, ima@ietf.org, yangwooko@gmail.com Message-ID: <474232B3.9010900@icu.ac.kr> Date: Tue, 20 Nov 2007 10:04:51 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Chris Walker Subject: Re: [EAI] A collision free ACE for internationlized email addresses References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Walker wrote: > (snip) > So the list of addresses above with their encoded representations are: > Original: "U+4EF6 . U+5546"@a.b.com > Encoded: "."@a.b.com-x00rr07d--yn > Decoded: "U+4EF6 . U+5546"@a.b.com > (snip) Dear Chris Walker, Please apologize my misunderstanding if (m)any. The most important virtue of ACE(-like) approaches is that it is an end-to-end approach. No intermediate SMTP server needs to be EAI aware. No protection mechanism (such as UTF8SMTP ESMTP extension) or in-transit manipulatio (such as downgrading) is required. If an SMTP server, which is not aware of the proposed encoding rule, receives "."@a.b.com-x00rr07d--yn, then it will try to get MX record(s) of RHS of @ sign. But, it will certainly fail. What am I missing? >(snip) > I am sure the first argument I will hear over this idea has > something to do with leaking, as I already pointed out, > UTF8SMTP already leaks. > (snip) In order to make the proposed encoding to work, all involved SMTP servers should be updated to be aware of this new encoding rule. If all involved SMTP servers are assumed to fully support current EAI WG's approach, then there will be no leak at all because everything will be in UTF8. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 21:16:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIf9-00083c-Lv; Mon, 19 Nov 2007 21:16:31 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuIf8-00083V-Jv for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 21:16:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIf8-00083N-82 for ima@ietf.org; Mon, 19 Nov 2007 21:16:30 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuIf6-0002ss-Eg for ima@ietf.org; Mon, 19 Nov 2007 21:16:29 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAK2GOlD007936 for ; Tue, 20 Nov 2007 11:16:25 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2bd4_97f6e27e_970e_11dc_9093_0014221fa3c9; Tue, 20 Nov 2007 11:16:24 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36289) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Nov 2007 11:12:32 +0900 Message-Id: <6.0.0.20.2.20071120105255.06fdd470@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Nov 2007 10:58:38 +0900 To: "Chris Walker" , "John C Klensin" , =?ISO-2022-JP?B?IkNsYXVzIEYbJEIlRiEiGyhCcmJlciI=?= , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] Re: A potential collision free local part ACE ID In-Reply-To: References: <20071116151553.GD14436@afilias.info> <20071116203440.GP14436@afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 01:46 07/11/20, Chris Walker wrote: >I'm afraid that the concept of maintaining an email address for each >language or script that one may wish to communicate in the body of a >message is, how you you say it? A non starter. How many languages do you speak? How many scripts are used by these languages? How many languages does the average email user speak and write? How many scripts are used by these languages? It turns out that an amazingly high percentage of the world's population are bi- or multilingual. However, given that it's mostly scripts, not languages, that count, my estimate is that on a world-wide average, the number of email addresses needed would be only two or three. Very far from a non-starter. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 21:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuImM-0001Da-9E; Mon, 19 Nov 2007 21:23:58 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuImK-0001DT-UW for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 21:23:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuImK-0001DK-Ig for ima@ietf.org; Mon, 19 Nov 2007 21:23:56 -0500 Received: from smtpauth03.prod.mesa1.secureserver.net ([64.202.165.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuImG-0003xg-Rb for ima@ietf.org; Mon, 19 Nov 2007 21:23:56 -0500 Received: (qmail 11602 invoked from network); 20 Nov 2007 02:23:51 -0000 Received: from unknown (68.173.30.158) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 20 Nov 2007 02:23:51 -0000 Message-ID: <001601c82b1c$680d4d40$0150a8c0@dtdesktop> From: "Daniel Taharlev" To: "John C Klensin" , "Shawn Steele" , References: <98C062BC4275D510B34683BB@p3.JCK.COM> Subject: Re: [EAI] spoofing Date: Mon, 19 Nov 2007 21:23:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Very well put. ----- Original Message ----- From: "John C Klensin" To: "Shawn Steele" ; Sent: Monday, November 19, 2007 1:14 PM Subject: Re: [EAI] spoofing > > > --On Monday, 19 November, 2007 10:10 -0800 Shawn Steele > wrote: > >> Re the RTL and general spoofing discussion: >> >> I think that for the domain name part of the address, the DNS >> system and IDN RFCs covers the behavior. >> >> For the local name the local authority will need to make sure >> that they assign reasonable names. Names can't be spoofed if >> the person creating locale names doesn't allow them. I think >> that recommendations for such registrations could follow >> whatever guidelines are appropriate for them. >> >> FWIW: This is a problem even in ASCII: rnicrosoft looks a lot >> like microsoft in many fonts. Many browsers fix the rn/n >> problem by choosing an appropriate font, but email is often >> "prettier". > > Shawn, > > Exactly. > And thanks. > john > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 19 22:00:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJLg-0002tH-7A; Mon, 19 Nov 2007 22:00:28 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuJLe-0002tB-F6 for ima-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 22:00:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJLe-0002t3-4R for ima@ietf.org; Mon, 19 Nov 2007 22:00:26 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuJLd-0003t3-7Y for ima@ietf.org; Mon, 19 Nov 2007 22:00:26 -0500 Received: (snipe 32761 invoked by uid 0); 20 Nov 2007 12:00:40 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.400978 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 20 Nov 2007 12:00:40 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: ima@ietf.org, yangwooko@gmail.com Message-ID: <47424DE3.5020509@icu.ac.kr> Date: Tue, 20 Nov 2007 12:00:51 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: eai list Subject: Re: [EAI] Re: A potential collision free local part ACE ID References: <20071116151553.GD14436@afilias.info> <20071116203440.GP14436@afilias.info> <6.0.0.20.2.20071120105255.06fdd470@localhost> In-Reply-To: <6.0.0.20.2.20071120105255.06fdd470@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > At 01:46 07/11/20, Chris Walker wrote: > >> I'm afraid that the concept of maintaining an email address for each >> language or script that one may wish to communicate in the body of a >> message is, how you you say it? A non starter. > > How many languages do you speak? How many scripts are used by these > languages? How many languages does the average email user speak and > write? How many scripts are used by these languages? > > It turns out that an amazingly high percentage of the world's > population are bi- or multilingual. However, given that it's > mostly scripts, not languages, that count, my estimate is that > on a world-wide average, the number of email addresses needed > would be only two or three. Very far from a non-starter. Maybe farther than that. Though it depends on how successful EAG WG's effort will be, my personal experience argues that the average number of "scripts" used in email addresses of a person (not the number of email addresses) could be less than two. When I was teaching my mother-in-law to use email, one of the hardest parts is how to associate capital letters printed on key caps with the lowercase letters used in email addresses. Now she always uses address books that support Korean alias for email addresses. For such a case, one Korean email address is enough. And we have many such cases. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 03:36:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOb7-0002p5-PJ; Tue, 20 Nov 2007 03:36:45 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuOb7-0002os-1s for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 03:36:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOb6-0002nN-KB for ima@ietf.org; Tue, 20 Nov 2007 03:36:44 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuOb6-0002eo-56 for ima@ietf.org; Tue, 20 Nov 2007 03:36:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuOb0-0004i5-UP for ima@ietf.org; Tue, 20 Nov 2007 08:36:38 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 08:36:38 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 08:36:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 20 Nov 2007 09:33:09 +0100 Lines: 27 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [EAI] UTF8HDR (was: Second Last Call - EAI protocol core documents) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: =20 > draft-ietf-eai-utf8headers-08.txt That still uses UTF8-xtra-char, using UTF8-non-ascii=20 everywhere would be clearer.=20 There's an unresolved "note" at the end of 4.1. In 4.3 hardwires control characters %d1-9 etc. intead of using a reference to RFC 2822 . In 4.3 with NO-WS-CTL is a _copy_ from 2822 instead of a _reference_ There's an obsolete "note" near the end of 4.3. In 4.4 the ABNF apparently contains a stray backslash. In 4.4 the contains an invalid 1*FWS instead of just FWS or whatever it's supposed to be. AFAIK new MIME subtypes like message/global need a=20 review on the "types" list at some point in time (?) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 04:08:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuP5c-000423-Ql; Tue, 20 Nov 2007 04:08:16 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuP5b-00041s-Ge for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 04:08:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuP5b-00041k-77 for ima@ietf.org; Tue, 20 Nov 2007 04:08:15 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuP5Y-0003iE-3W for ima@ietf.org; Tue, 20 Nov 2007 04:08:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuP5M-0001Ul-RF for ima@ietf.org; Tue, 20 Nov 2007 09:08:00 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 09:08:00 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 09:08:00 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 20 Nov 2007 10:04:34 +0100 Lines: 20 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] EAI DSN (was: Second Last Call - EAI protocol core documents) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: =20 > draft-ietf-eai-dsn-05.txt Looking at the diff I think that I-D is ready. Maybe (later) add an informative reference to ID.klensin-unicode-escapes about the business. Section 4 introduces , this construct could be already used in section 3 to simplify . Or not, just an idea. I still think this draft deserves some examples. IFF new MIME types need a review on the "types" list it would obviously also affect this draft. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 04:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuPfe-0002ig-9Z; Tue, 20 Nov 2007 04:45:30 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuPfd-0002iV-5V for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 04:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuPfc-0002iL-S7 for ima@ietf.org; Tue, 20 Nov 2007 04:45:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuPfZ-0004cH-HP for ima@ietf.org; Tue, 20 Nov 2007 04:45:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuPck-0000kX-3i for ima@ietf.org; Tue, 20 Nov 2007 09:42:30 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 09:42:30 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 09:42:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 20 Nov 2007 10:33:03 +0100 Lines: 33 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] UTF8SMTP (was: Second Last Call - EAI protocol core documents) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > draft-ietf-eai-smtpext-09.txt Quite a lot of changes, but the reason for=20 "updates 4952" isn't obvious for me. In 2.7.3 the "anchor11" should be transformed into proper text, proposal: | Note: The FOR parameter has been changed to | match the definition in RFC2821bis, an successor of RFC2821, | permitting only one address in the For clause. | The group working on that document reached | mailing list consensus that the syntax in [...] How about this: + The syntax in RFC 2821 that permitted more than + one address is considered as mistake. "Anchor 7" tells the RFC editor that they should replace 5.6.x and 5.6.z by the final codes. They should also replace 5.6.y and 2.6.y. What's the state of the art with the registry I-D(s) ? The informative reference ID.klensin-smtp-code-registry should be ID.hansen-4468upd-mailes-registry, shouldn't it ? (No, Harald, that's not a "new" nit... ;-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 06:20:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR9X-0002NI-Cq; Tue, 20 Nov 2007 06:20:27 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuR9W-0002LJ-4r for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:20:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR9V-0002LB-Oh for ima@ietf.org; Tue, 20 Nov 2007 06:20:25 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuR9V-0007D9-5V for ima@ietf.org; Tue, 20 Nov 2007 06:20:25 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 39-md50000000158.tmp for ; Tue, 20 Nov 2007 04:23:22 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Tue, 20 Nov 2007 04:23:21 -0700 Date: Tue, 20 Nov 2007 04:23:21 -0700 From: "Chris Walker" To: "Yangwoo Ko" , "eai list" Subject: Re: [EAI] A collision free ACE for internationlized email addresses Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <474232B3.9010900@icu.ac.kr> References: <474232B3.9010900@icu.ac.kr> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Tue, 20 Nov 2007 04:23:22 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 -----Original Message----- From: Yangwoo Ko To: Chris Walker Cc: eai list Date: Tue, 20 Nov 2007 10:04:51 +0900 Subject: Re: [EAI] A collision free ACE for internationlized email addresses > > Chris Walker wrote: > > (snip) > > So the list of addresses above with their encoded representations > are: > > Original: "U+4EF6 . U+5546"@a.b.com > > Encoded: "."@a.b.com-x00rr07d--yn > > Decoded: "U+4EF6 . U+5546"@a.b.com > > (snip) > > Dear Chris Walker, > > Please apologize my misunderstanding if (m)any. The most important > virtue of ACE(-like) approaches is that it is an end-to-end approach. > No > intermediate SMTP server needs to be EAI aware. No protection mechanism > (such as UTF8SMTP ESMTP extension) or in-transit manipulatio (such as > downgrading) is required. > > If an SMTP server, which is not aware of the proposed encoding rule, > receives "."@a.b.com-x00rr07d--yn, then it will try to get MX record(s) > of RHS of @ sign. But, it will certainly fail. What am I missing? > At some point close to the sender an internationalized email address would need to be encoded for transit over SMTP and at the recipients side it would need to be decoded for display. It is possible that this could be done in the mail client software used by the users. These mail clients may or may not be directly integrated with the SMTP servers that start and finish the actual transport over SMTP. The address needs to be decoded to access the domain part in order to determine the MX record in DNS. This burden of having to be aware of encodings is not unique to this encoding, if the domain part is in UTF8, a system has to have knowledge of the proper methods (INDA ToASCII) in order to convert the UTF8 domain part in order to query the DNS. All the records in DNS for internationalized domains are stored in punycode form. In both scenarios, knowlegde of a encoding format is needed, to determine (via DNS MX lookup) which mail server needs to be contacted, however after that determination is made, the encoded form will fit within the restrictions of SMTP be 7bit ASCII. > >(snip) > > I am sure the first argument I will hear over this idea has > > something to do with leaking, as I already pointed out, > > UTF8SMTP already leaks. > > (snip) > > In order to make the proposed encoding to work, all involved SMTP > servers should be updated to be aware of this new encoding rule. If all > involved SMTP servers are assumed to fully support current EAI WG's > approach, then there will be no leak at all because everything will be > in UTF8. > > Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 06:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRGw-0002lD-3B; Tue, 20 Nov 2007 06:28:06 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuRGu-0002ky-HZ for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:28:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRGu-0002ko-6m for ima@ietf.org; Tue, 20 Nov 2007 06:28:04 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuRGt-0007OR-Np for ima@ietf.org; Tue, 20 Nov 2007 06:28:04 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 44-md50000000158.tmp for ; Tue, 20 Nov 2007 04:30:59 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Tue, 20 Nov 2007 04:30:59 -0700 Date: Tue, 20 Nov 2007 04:30:59 -0700 From: "Chris Walker" To: "Martin Duerst" , "John C Klensin" , "Claus =?iso-8859-1?B?RoNlgUFyYmVy?=" , ima@ietf.org Subject: Re: [EAI] Re: A potential collision free local part ACE ID MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <6.0.0.20.2.20071120105255.06fdd470@localhost> References: <20071116151553.GD14436@afilias.info> <20071116203440.GP14436@afilias.info> <6.0.0.20.2.20071120105255.06fdd470@localhost> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Tue, 20 Nov 2007 04:30:59 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 -----Original Message----- From: Martin Duerst To: "Chris Walker" , "John C Klensin" , "Claus FeArber" , ima@ietf.org Date: Tue, 20 Nov 2007 10:58:38 +0900 Subject: Re: [EAI] Re: A potential collision free local part ACE ID > At 01:46 07/11/20, Chris Walker wrote: > > >I'm afraid that the concept of maintaining an email address for each > >language or script that one may wish to communicate in the body of a > >message is, how you you say it? A non starter. > > How many languages do you speak? How many scripts are used by these > languages? How many languages does the average email user speak and > write? How many scripts are used by these languages? > > It turns out that an amazingly high percentage of the world's > population are bi- or multilingual. However, given that it's > mostly scripts, not languages, that count, my estimate is that > on a world-wide average, the number of email addresses needed > would be only two or three. Very far from a non-starter. > > Regards, Martin. > > While I may have control of the local parts of the email address and could have them in many languages, will the company hosting the mail server have it registered in all of these languages too? I think the original example on this thread was Keiko who had a Japanese email address UTF8 Japanese @ UTF8 Japanese, I don't understand how the suggestion that she has a UTF8 Devangari @ UTF8 Japanese helps anything, it actually just makes it more complicated. Does Keiko have to get an additional email provider to get a UTF8 Devangari @ UTF8 Devangari address if her existing provider can not help in the matter? Chris > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 06:49:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRbe-0002bq-Cx; Tue, 20 Nov 2007 06:49:30 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuRbc-0002aD-Ok for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:49:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRbc-0002YN-Do for ima@ietf.org; Tue, 20 Nov 2007 06:49:28 -0500 Received: from mail.iespresio.com ([209.181.130.181] helo=iespresio.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuRbb-0007wq-W8 for ima@ietf.org; Tue, 20 Nov 2007 06:49:28 -0500 Received: from WorldClient ([192.168.0.203]) (authenticated user cw-eai-ietf@iespresio.com) by iespresio.com (iespresio.com [192.168.0.203]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 22-md50000000159.tmp for ; Tue, 20 Nov 2007 04:52:25 -0700 Received: from [192.168.0.1] via WorldClient with HTTP; Tue, 20 Nov 2007 04:52:25 -0700 Date: Tue, 20 Nov 2007 04:52:25 -0700 From: "Chris Walker" To: "Yangwoo Ko" , "eai list" Subject: Re: [EAI] A collision free ACE for internationlized email addresses Message-ID: X-Mailer: WorldClient 6.8.5 In-Reply-To: <474232B3.9010900@icu.ac.kr> References: <474232B3.9010900@icu.ac.kr> X-Authenticated-Sender: cw-eai-ietf@iespresio.com X-Spam-Processed: iespresio.com, Tue, 20 Nov 2007 04:52:25 -0700 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.203 X-Return-Path: cw-eai-ietf@iespresio.com X-MDaemon-Deliver-To: ima@ietf.org 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 -----Original Message----- From: Yangwoo Ko To: Chris Walker Cc: eai list Date: Tue, 20 Nov 2007 10:04:51 +0900 Subject: Re: [EAI] A collision free ACE for internationlized email addresses > > Chris Walker wrote: > > (snip) > > So the list of addresses above with their encoded representations > are: > > Original: "U+4EF6 . U+5546"@a.b.com > > Encoded: "."@a.b.com-x00rr07d--yn > > Decoded: "U+4EF6 . U+5546"@a.b.com > > (snip) > > Dear Chris Walker, > > Please apologize my misunderstanding if (m)any. The most important > virtue of ACE(-like) approaches is that it is an end-to-end approach. > No > intermediate SMTP server needs to be EAI aware. No protection mechanism > (such as UTF8SMTP ESMTP extension) or in-transit manipulatio (such as > downgrading) is required. > > If an SMTP server, which is not aware of the proposed encoding rule, > receives "."@a.b.com-x00rr07d--yn, then it will try to get MX record(s) > of RHS of @ sign. But, it will certainly fail. What am I missing? > > >(snip) > > I am sure the first argument I will hear over this idea has > > something to do with leaking, as I already pointed out, > > UTF8SMTP already leaks. > > (snip) > > In order to make the proposed encoding to work, all involved SMTP > servers should be updated to be aware of this new encoding rule. If all > involved SMTP servers are assumed to fully support current EAI WG's > approach, then there will be no leak at all because everything will be > in UTF8. Im sorry, I musunderstood your question to be something else, please disregard my first reply. The 'downgrading' process, is where a UTF8SMTP email is downgraded to SMTP, part of this process as it is currently written is to to preserve the orignial UTF8 headers with UTF8 email addresses in downgraded headers, these headers are encoded to make the data 7bit compatable. Chris > > Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 07:01:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRn5-0000ez-Dd; Tue, 20 Nov 2007 07:01:19 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuRn3-0000Z4-N2 for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 07:01:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRn3-0000Wm-BU for ima@ietf.org; Tue, 20 Nov 2007 07:01:17 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuRn2-0008Ls-U9 for ima@ietf.org; Tue, 20 Nov 2007 07:01:17 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E36202596FC; Tue, 20 Nov 2007 13:01:15 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20209-02; Tue, 20 Nov 2007 13:01:10 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 389F72596F9; Tue, 20 Nov 2007 13:01:10 +0100 (CET) Message-ID: <4742CC85.5030404@alvestrand.no> Date: Tue, 20 Nov 2007 13:01:09 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] UTF8SMTP 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: > Harald Tveit Alvestrand wrote: > > >> draft-ietf-eai-smtpext-09.txt >> > > Quite a lot of changes, but the reason for > "updates 4952" isn't obvious for me. > Read Appendix A. > In 2.7.3 the "anchor11" should be transformed > into proper text, proposal: > > | Note: The FOR parameter has been changed to > | match the definition in RFC2821bis, > an successor of RFC2821, > | permitting only one address in the For clause. > > > | The group working on that document reached > | mailing list consensus that the syntax in > [...] > How about this: > + The syntax in RFC 2821 that permitted more than > + one address is considered as mistake. > But EAI can't say that - it's out of charter. Question: Is that a normative dependency on 2821bis? > "Anchor 7" tells the RFC editor that they should > replace 5.6.x and 5.6.z by the final codes. They > should also replace 5.6.y and 2.6.y. > > What's the state of the art with the registry I-D(s) ? > The informative reference ID.klensin-smtp-code-registry > should be ID.hansen-4468upd-mailes-registry, shouldn't > it ? (No, Harald, that's not a "new" nit... ;-) No, it was a missed one :-( Thank you! _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 07:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuSVl-0005x7-Ev; Tue, 20 Nov 2007 07:47:29 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuSVk-0005x2-TR for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 07:47:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuSVk-0005wu-JJ for ima@ietf.org; Tue, 20 Nov 2007 07:47:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuSVk-0001AM-6b for ima@ietf.org; Tue, 20 Nov 2007 07:47:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuSVX-0003XV-Rc for ima@ietf.org; Tue, 20 Nov 2007 12:47:15 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 12:47:15 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2007 12:47:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 20 Nov 2007 13:43:57 +0100 Lines: 28 Message-ID: References: <4742CC85.5030404@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] Re: UTF8SMTP X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann 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: >> How about this: >> + The syntax in RFC 2821 that permitted more >> + than one address is considered as mistake. =20 > But EAI can't say that - it's out of charter. The WG *tries* to update *MIME* out of charter. Why can't it offer an opinion about a 2821 detail in a draft supported by John (the editor of 2821, also the author of 4952 and 2821bis) ? It's not really a 2821 erratum, and I've already=20 exhausted my "process experiment" tolerance with for today. > Is that a normative dependency on 2821bis? More like an experimental 2821 update, but that's what the draft anyway does. Found appendix A, thanks, I forgot to return to=20 "diff view" after checking the registry reference. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 12:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWwR-00084l-1j; Tue, 20 Nov 2007 12:31:19 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuWwO-000849-TN for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWwO-00083v-H9 for ima@ietf.org; Tue, 20 Nov 2007 12:31:16 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuWwK-0000xZ-9v for ima@ietf.org; Tue, 20 Nov 2007 12:31:16 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IuWwC-0007G5-NE; Tue, 20 Nov 2007 12:31:05 -0500 Date: Tue, 20 Nov 2007 12:31:03 -0500 From: John C Klensin To: Chris Walker Subject: Re: [EAI] A collision free ACE for internationlized email addresses Message-ID: <508ADE6370C3541129C1A530@p3.JCK.COM> In-Reply-To: References: <474232B3.9010900@icu.ac.kr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 20 November, 2007 04:23 -0700 Chris Walker wrote: > At some point close to the sender an internationalized email > address would need to be encoded for transit over SMTP and at > the recipients side it would need to be decoded for display. > It is possible that this could be done in the mail client > software used by the users. These mail clients may or may not > be directly integrated with the SMTP servers that start and > finish the actual transport over SMTP. But, Chris, if you include the domain-part in the encoding -- which is what I now understand you want to do-- then even relay in the path will have to do the decoding in order to know where to forward the mail. That also implies some very nasty bounces, as every (non-submission) SMTP server in the world today knows that address syntax contains a (public/ non-encoded) "@", which precedes an FQDN. Sorry, I just don't see how your ideas work in the real world, at least as I understand it. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 20 12:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXNZ-0006I4-TP; Tue, 20 Nov 2007 12:59:21 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuXNY-0006Ht-OB for ima-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:59:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXNY-0006Hg-EX for ima@ietf.org; Tue, 20 Nov 2007 12:59:20 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXNS-0001ze-Lh for ima@ietf.org; Tue, 20 Nov 2007 12:59:20 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IuXNL-00084V-8F; Tue, 20 Nov 2007 12:59:07 -0500 Date: Tue, 20 Nov 2007 12:59:06 -0500 From: John C Klensin To: Yangwoo Ko , Chris Walker Subject: Re: [EAI] A collision free ACE for internationlized email addresses Message-ID: <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> In-Reply-To: <474232B3.9010900@icu.ac.kr> References: <474232B3.9010900@icu.ac.kr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 20 November, 2007 10:04 +0900 Yangwoo Ko wrote: > If an SMTP server, which is not aware of the proposed encoding > rule, receives "."@a.b.com-x00rr07d--yn, then it will try to > get MX record(s) of RHS of @ sign. But, it will certainly > fail. What am I missing? That it is worse than that. We know that, in the real world, quotes often get lost, even when they shouldn't. If this is accidentally turned into .@a.b.com-x00rr07d--yn either between relays or in local processing, it is likely to be rejected as a syntax error or as a broken attempt to specify a source route. One can certainly handle these things in a sufficiently upgraded server, protected by SMTP extension options that keep other addresses from getting anywhere near it. That upgrade would also require (incompatible) header changes to note that something is an i18n address and not an ASCII one. But those forms are not, in practice, going to be reliably transparent to legacy servers or legacy MUAs. It seems to me that was your main point, with which I agree. And, if protection by an SMTP extension option is required, then there is little advantage over using some flavor of ACE over the straightforward transmission of UTF-8. The latter also makes subaddressing and routing and other actions embedded in the local-part more feasible, doesn't leave us with an "ASCII-plus-kludge" header and envelope construct that we have to live with forever, even when EAI is widely deployed. And so on. Of course, that was the conclusion we reached well over a year ago, based on almost exactly the same knowledge and reasoning that we have and are going through today. Chris, the question about whether Alice (or Aiko) will be able to find an appropriate domain for a Devanagari-script domain is (i) there _is_ an ACE for domain name labels and, more important, (ii) if there is a market demand for such names on a global basis, the names will emerge. If not, then it is not as much of a problem as you assume. It is suggestive of one of the flaws in the model of TLDs that are tied to languages and presumably administrative unavailable to people who are not normally associated with that language community, but that isn't this WG's (or the IETF's) problem. The bottom line is that we have a choice between: (1) Keeping the world nice for those with applications that are all-ASCII and ignorant of, or hostile to, other scripts, even Latin characters outside the ASCII/ISO-646IRV subset. Doing this means that those other scripts will always look like a clumsy add-on. (2) Moving to where we would like to end up, in which the email addressing environment is largely script-agnostic. Now the latter does imply some transition activities. Organizations that have assumed that the whole world is ASCII and will be ASCII forever will either need to adapt to the new address formats or will need to reject them as invalid. For better or worse, the latter is pretty much what happens today: we continue to have problems with web sites that accept email addresses with local parts that contain "strange" characters such as "+" or "=" and with domain names where the TLD is more than three or four characters long. And people who communicate across language communities will either need to stick with ASCII addresses (perhaps as aliases) or become clever. We may open up some market opportunities for address translation and forwarding databases --something else we have been discussing since the beginning-- if sender authentication techniques that are hostile to forwarding don't get in the way. It is likely to be bumpy for a while, especially for any communication that crosses between language communities. We are worrying about downgrading precisely to ease the bounce from some of those bumps. But it will sort itself out and we will end up with an internationalized email system. If it doesn't, the SMTP option and extended syntax will all fall back out of use, resulting in less damage than if we had attempted a complex ACE that turned out to be not-quite-transparent. The first option, by contrast, amounts to an assertion that ASCII is supreme and that every other script is inherently second-class (or worse) and should stay that way. I don't find that acceptable even though I can write most of my native language in ASCII. For others... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 21 13:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuDg-0004a0-8b; Wed, 21 Nov 2007 13:22:40 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IuuDe-0004Zt-Gh for ima-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:22:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuDe-0004Zi-76 for ima@ietf.org; Wed, 21 Nov 2007 13:22:38 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuuDa-0006cG-K9 for ima@ietf.org; Wed, 21 Nov 2007 13:22:38 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Nov 2007 18:22:33 +0000 Message-ID: <4744774D.8070404@isode.com> Date: Wed, 21 Nov 2007 18:22:05 +0000 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: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] UTF8HDR References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Frank Ellermann wrote: >There's an obsolete "note" near the end of 4.3. > > +1. >In 4.4 the ABNF apparently contains a >stray backslash. > > Indeed, please change: angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] \ / obs-angle-addr To angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / obs-angle-addr >In 4.4 the contains an invalid 1*FWS >instead of just FWS or whatever it's supposed to be. > > I vaguely remember that we've settled on 1*FWS >AFAIK new MIME subtypes like message/global need a >review on the "types" list at some point in time (?) > > EAI documents don't change MIME type registration procedure. So yes, you are correct, but I don't think anything needs to be changed in the document. I don't have any other issues with the document, so I support its publication. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 21 21:39:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv1y8-0008MS-4k; Wed, 21 Nov 2007 21:39:08 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iv1y6-0008M6-8p for ima-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 21:39:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv1y5-0008Ly-TR for ima@ietf.org; Wed, 21 Nov 2007 21:39:05 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv1xz-0002xa-KR for ima@ietf.org; Wed, 21 Nov 2007 21:39:05 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAM2cuWU018992 for ; Thu, 22 Nov 2007 11:38:56 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4f1c_12483ffa_98a4_11dc_8968_0014221f2a2d; Thu, 22 Nov 2007 11:38:56 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:38970) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 22 Nov 2007 11:35:03 +0900 Message-Id: <6.0.0.20.2.20071122113243.07af6c30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 22 Nov 2007 11:34:44 +0900 To: John C Klensin From: Martin Duerst Subject: Re: [EAI] A collision free ACE for internationlizedemail addresses In-Reply-To: <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> References: <474232B3.9010900@icu.ac.kr> <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 02:59 07/11/21, John C Klensin wrote: >Chris, the question about whether Alice (or Aiko) will be able >to find an appropriate domain for a Devanagari-script domain is >(i) there _is_ an ACE for domain name labels and, more >important, (ii) if there is a market demand for such names on a >global basis, the names will emerge. If not, then it is not as >much of a problem as you assume. It is suggestive of one of >the flaws in the model of TLDs that are tied to languages and >presumably administrative unavailable to people who are not >normally associated with that language community, but that isn't >this WG's (or the IETF's) problem. Hello John, I have had difficulties parsing/understanding the last sentence in your paragraph. Could you explain (probably just giving an example may be enough). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 01:48:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv5rY-0005UI-Gv; Thu, 22 Nov 2007 01:48:36 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iv5rV-0005EY-R1 for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 01:48:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv5rU-0005B0-RN for ima@ietf.org; Thu, 22 Nov 2007 01:48:32 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv5rU-0008O6-4e for ima@ietf.org; Thu, 22 Nov 2007 01:48:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iv5rE-0007r7-U2 for ima@ietf.org; Thu, 22 Nov 2007 06:48:16 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Nov 2007 06:48:16 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Nov 2007 06:48:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 22 Nov 2007 07:44:48 +0100 Lines: 13 Message-ID: References: <4744774D.8070404@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] Re: UTF8HDR X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Alexey Melnikov wrote: =20 >>In 4.4 the contains an invalid 1*FWS >>instead of just FWS or whatever it's supposed to be. > I vaguely remember that we've settled on 1*FWS That's the known LWSP issue, we can't have more than one FWS in a row, it would match "apparently empty" lines and cause havoc. Just FWS already allows more than one SP or HT, still limited to at most one CRLF. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 02:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv63n-00080B-Kg; Thu, 22 Nov 2007 02:01:15 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iv63m-0007n4-7j for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 02:01:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv63l-0007fW-OS for ima@ietf.org; Thu, 22 Nov 2007 02:01:13 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv63h-0003rU-OI for ima@ietf.org; Thu, 22 Nov 2007 02:01:13 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iv63c-0001PJ-FK for ima@ietf.org; Thu, 22 Nov 2007 07:01:04 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Nov 2007 07:01:04 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Nov 2007 07:01:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 22 Nov 2007 07:55:51 +0100 Lines: 17 Message-ID: References: <474232B3.9010900@icu.ac.kr> <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> <6.0.0.20.2.20071122113243.07af6c30@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [EAI] Re: A collision free ACE for internationlizedemail addresses X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: >> It is suggestive of one of the flaws in the model of TLDs that >> are tied to languages and presumably administrative unavailable >> to people who are not normally associated with that language=20 >> community, but that isn't this WG's (or the IETF's) problem. [...] > I have had difficulties parsing/understanding the last sentence > in your paragraph. Could you explain (probably just giving an > example may be enough). When I created http://xn--80akhbyknj4f.boldlygoingnowhere.org I didn't bother to discuss this creation with PIR (TLD org) or DynDNS (boldlygoingnowhere), possibly I'm not "allowed" to create Cyril IDNA labels in this TLD. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 07:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAjf-00077B-Ft; Thu, 22 Nov 2007 07:00:47 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvAje-000774-L3 for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 07:00:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAje-00076v-8M for ima@ietf.org; Thu, 22 Nov 2007 07:00:46 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvAjd-0003nk-Sn for ima@ietf.org; Thu, 22 Nov 2007 07:00:46 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Nov 2007 12:00:44 +0000 Message-ID: <4745631E.4090209@isode.com> Date: Thu, 22 Nov 2007 11:08:14 +0000 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: EAI WG Subject: Re: [EAI] Second Last Call - EAI protocol core documents References: <4745621C.6080902@isode.com> In-Reply-To: <4745621C.6080902@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Alexey Melnikov wrote: > Harald Tveit Alvestrand wrote: > >> This is the second Last Call for the following documents: >> >> draft-ietf-eai-utf8headers-08.txt >> draft-ietf-eai-dsn-05.txt >> draft-ietf-eai-smtpext-09.txt > > I've reviewed the latest draft-ietf-eai-smtpext-09.txt and all my > issues were addressed. So I support its submission to IESG. One nit: Assuming that the server advertises UTF8SMTP and 8BITMIME, and ", BINARYMIME" is missing after UTF8SMTP receives at least one non-ASCII address, with or without ALT-ADDRESS, the precise interpretation of "No 'Body' parameter", "BODY= 8BITMIME", and "BODY= BINARYMIME" in the MAIL command is: _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 07:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAjc-0006vv-B5; Thu, 22 Nov 2007 07:00:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvAja-0006oZ-BQ for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 07:00:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAjZ-0006lz-Um for ima@ietf.org; Thu, 22 Nov 2007 07:00:41 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvAjZ-0003nd-K2 for ima@ietf.org; Thu, 22 Nov 2007 07:00:41 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Nov 2007 12:00:39 +0000 Message-ID: <4745621C.6080902@isode.com> Date: Thu, 22 Nov 2007 11:03:56 +0000 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: Harald Tveit Alvestrand Subject: Re: [EAI] Second Last Call - EAI protocol core documents References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > This is the second Last Call for the following documents: > > draft-ietf-eai-utf8headers-08.txt > draft-ietf-eai-dsn-05.txt > draft-ietf-eai-smtpext-09.txt I've reviewed the latest draft-ietf-eai-smtpext-09.txt and all my issues were addressed. So I support its submission to IESG. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 08:49:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCR8-0002AP-6g; Thu, 22 Nov 2007 08:49:46 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvCR7-0002AK-0s for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCR6-0002AC-LU for ima@ietf.org; Thu, 22 Nov 2007 08:49:44 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCR3-0000wa-C4 for ima@ietf.org; Thu, 22 Nov 2007 08:49:44 -0500 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IvCR3-0006hx-1C for ima@ietf.org; Thu, 22 Nov 2007 08:49:41 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id C1C3313744; Thu, 22 Nov 2007 08:49:57 -0500 (EST) Date: Thu, 22 Nov 2007 08:49:57 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Second Last Call - EAI protocol core documents Message-ID: <20071122134957.GE25692@dba3> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear colleagues, On Mon, Nov 19, 2007 at 11:21:46PM +0100, Harald Tveit Alvestrand wrote: > This is the second Last Call for the following documents: > > draft-ietf-eai-utf8headers-08.txt I have read this draft. I didn't have any previous objections, but I think that the changes are consistent with addressing the objections that were raised. I support advancing the document. A few nits follow. I note that in section 4.1, on page 5, the following text: [Note in draft: Whether normalizing is needed or not will be place in here.] Should that be removed before advancement? I presume the decision has been made by the WG? I see a similar note in section 4.3 on page 7: [NOTE IN DRAFT: If any header needs to be restricted to disallow this, please raise the issue on the mailing list.] and again in section 5, on page 10: [Note in draft: Whether this non-requirement is adequate is a subject for debate]. Best regards, Andrew -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 09:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCdF-0005rC-6j; Thu, 22 Nov 2007 09:02:17 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvCdD-0005cG-CZ for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCdD-0005Zp-0g for ima@ietf.org; Thu, 22 Nov 2007 09:02:15 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCd7-0001Mx-9n for ima@ietf.org; Thu, 22 Nov 2007 09:02:14 -0500 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IvCd7-0007Cq-1G for ima@ietf.org; Thu, 22 Nov 2007 09:02:09 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id C75A213744; Thu, 22 Nov 2007 09:02:25 -0500 (EST) Date: Thu, 22 Nov 2007 09:02:25 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Second Last Call - EAI protocol core documents Message-ID: <20071122140225.GF25692@dba3> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear colleagues, On Mon, Nov 19, 2007 at 11:21:46PM +0100, Harald Tveit Alvestrand wrote: > draft-ietf-eai-dsn-05.txt I have read that document. I raised no objection in the previous last call, but I believe the changes are consistent with addressing the issues that were raised by others. I support advancing the draft. Best regards, Andrew -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 23:38:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvQJL-00015q-R5; Thu, 22 Nov 2007 23:38:39 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvQJK-00015i-BJ for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 23:38:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvQJK-00015a-1V for ima@ietf.org; Thu, 22 Nov 2007 23:38:38 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvQJH-0002f5-1T for ima@ietf.org; Thu, 22 Nov 2007 23:38:38 -0500 Received: (snipe 26085 invoked by uid 0); 23 Nov 2007 13:38:45 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.624111 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 23 Nov 2007 13:38:44 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: harald@alvestrand.no, ima@ietf.org, yangwooko@gmail.com Message-ID: <4746593E.4090608@icu.ac.kr> Date: Fri, 23 Nov 2007 13:38:22 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [EAI] Second Last Call - EAI protocol core documents References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > > This is the second Last Call for the following documents: > > draft-ietf-eai-utf8headers-08.txt I have read the document and support it be sent to IESG. Followings are trivial typos I found. > Use of this SMTP extension helps prevents the introduction of such ... helps preventing ... > described in [RFC1652]., an encoding may be applied to the message; described in [RFC 1652], an ... > Below list a few possible representation as example. a few possible representations ... > use of the new uFor syntax. UTF-8 information in needed in Received ... UTF-8 information is needed in Received > This will not break the rule of trace fied integrity, because it is ... trace field ... And, I suggest downconvert (or down-convert) to downgrade to make it more consistent with the downgrade I.D. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 22 23:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvQQ4-0005nB-OJ; Thu, 22 Nov 2007 23:45:36 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvQQ3-0005n6-A3 for ima-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 23:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvQQ2-0005my-Uo for ima@ietf.org; Thu, 22 Nov 2007 23:45:34 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvQPx-0002la-1L for ima@ietf.org; Thu, 22 Nov 2007 23:45:34 -0500 Received: (eyou send program); Fri, 23 Nov 2007 12:45:18 +0800 Message-ID: <395793118.25969@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Fri, 23 Nov 2007 12:45:18 +0800 Message-ID: <014e01c82d8b$a6b4a5e0$236ff1da@yaojk> From: "YAO Jiankang" To: "Harald Tveit Alvestrand" , "EAI WG" References: <395511080.18444@cnnic.cn> Subject: Re: [EAI] Second Last Call - EAI protocol core documents Date: Fri, 23 Nov 2007 12:45:19 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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="===============1709002463==" Errors-To: ima-bounces@ietf.org --===============1709002463== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBUdmVpdCBBbHZl c3RyYW5kIiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpUbzogIkVBSSBXRyIgPGltYUBpZXRmLm9y Zz4NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDIwLCAyMDA3IDY6MjEgQU0NClN1YmplY3Q6IFtF QUldIFNlY29uZCBMYXN0IENhbGwgLSBFQUkgcHJvdG9jb2wgY29yZSBkb2N1bWVudHMNCg0KDQo+ IFRoaXMgaXMgdGhlIHNlY29uZCBMYXN0IENhbGwgZm9yIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRz Og0KPiANCj4gZHJhZnQtaWV0Zi1lYWktdXRmOGhlYWRlcnMtMDgudHh0DQo+IGRyYWZ0LWlldGYt ZWFpLWRzbi0wNS50eHQNCj4gZHJhZnQtaWV0Zi1lYWktc210cGV4dC0wOS50eHQNCg0KDQpJIGhh dmUgcmVhZCB0aGVtIGFuZCBzdXBwb3J0IHRoZW0gdG8gYmUgc2VudCB0byBJRVNHLg== --===============1709002463== 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 --===============1709002463==-- From ima-bounces@ietf.org Fri Nov 23 00:58:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvRYj-0002Uo-Ky; Fri, 23 Nov 2007 00:58:37 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvRYj-0002Ui-C6 for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 00:58:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvRYi-0002Ua-Lw for ima@ietf.org; Fri, 23 Nov 2007 00:58:36 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvRYh-0004Qi-UP for ima@ietf.org; Fri, 23 Nov 2007 00:58:36 -0500 Received: (snipe 14053 invoked by uid 0); 23 Nov 2007 14:58:53 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.624002 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 23 Nov 2007 14:58:52 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: harald@alvestrand.no, ima@ietf.org, yangwooko@gmail.com Message-ID: <47466C05.8000908@icu.ac.kr> Date: Fri, 23 Nov 2007 14:58:29 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [EAI] Second Last Call - EAI protocol core documents References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > > This is the second Last Call for the following documents: > > draft-ietf-eai-dsn-05.txt > draft-ietf-eai-smtpext-09.txt I have read these two IDs and support them be forwarded. Following a trivial typo I found in smtpext doc. > but receives a the UTF-8 string in a reply, it may not be able to ... receives a UTF-8 string ... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 23 05:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvVmj-00053A-E3; Fri, 23 Nov 2007 05:29:21 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvVmh-000535-EK for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 05:29:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvVmh-00052i-2T for ima@ietf.org; Fri, 23 Nov 2007 05:29:19 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvVmg-000493-5U for ima@ietf.org; Fri, 23 Nov 2007 05:29:18 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew*man&ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.262) id 4746ab76.11ba2.61 for ima@ietf.org; Fri, 23 Nov 2007 10:29:10 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id lANATAJW026327 for ; Fri, 23 Nov 2007 10:29:10 GMT Date: Fri, 23 Nov 2007 10:29:09 -0000 To: IMA Subject: Re: [EAI] Second Last Call - EAI protocol core documents References: <20071122134957.GE25692@dba3> 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: <20071122134957.GE25692@dba3> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 22 Nov 2007 13:49:57 -0000, Andrew Sullivan wrote: >> draft-ietf-eai-utf8headers-08.txt > A few nits follow. > > I note that in section 4.1, on page 5, the following text: > > [Note in draft: Whether normalizing is needed or not will be place > in here.] > > Should that be removed before advancement? I presume the decision > has been made by the WG? Actually, I am not sure we ever did discuss this in detail. Persnally, I am all in favour of normalising things, especially where they form part of addressing information. So perhaps a quick heads up if anyone else wants to pursue this further. Otherwise the Note should come out. -- CharlesH.Lindsey---------AtHome,doingmyownthing------------------------ Tel:+441614366131 Web:http://www.cs.man.ac.uk/~chl Email:chl@clerew.man.ac.ukSnail:5ClerewoodAve,CHEADLE,SK83JU,U.K. PGP:2C15F1A9Fingerprint:736DC25193A001E765E8647E14A4ABA5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 23 12:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivc9B-0002hW-Po; Fri, 23 Nov 2007 12:16:57 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ivc9A-0002hI-Rt for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:16:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivc9A-0002hA-HQ for ima@ietf.org; Fri, 23 Nov 2007 12:16:56 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivc99-0008LK-VA for ima@ietf.org; Fri, 23 Nov 2007 12:16:56 -0500 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1Ivc98-0002Rd-1f; Fri, 23 Nov 2007 12:16:54 -0500 Date: Fri, 23 Nov 2007 12:16:52 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Second Last Call - EAI protocol core documents Message-ID: In-Reply-To: References: <20071122134957.GE25692@dba3> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, November 23, 2007 10:29 AM +0000 Charles Lindsey wrote: > On Thu, 22 Nov 2007 13:49:57 -0000, Andrew Sullivan > wrote: > >>> draft-ietf-eai-utf8headers-08.txt > >> A few nits follow. >> >> I note that in section 4.1, on page 5, the following text: >> >> [Note in draft: Whether normalizing is needed or not will >> be place in here.] >> >> Should that be removed before advancement? I presume the >> decision has been made by the WG? > > Actually, I am not sure we ever did discuss this in detail. > Persnally, I am all in favour of normalising things, > especially where they form part of addressing information. > > So perhaps a quick heads up if anyone else wants to pursue > this further. Otherwise the Note should come out. Charles, While it is a gray area, normalization of addresses violates the "only the delivery MTA and systems beyond it can interpret the local part" rule, just as case-mapping does. I believe we are better off leaving it alone (i.e., not normalizing) and then recommending to operators of such MTAs that it would be wise to treat all normalized and unnormalized forms of the same string as equivalent, just as we now advise them to treat upper and lower case forms as equivalent. If they want to use a specific form as a trap for the unwary, it is up to them. But I agree with you in that I don't think the WG has reached a clear decision on this. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 23 13:21:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivd9K-0006nw-8k; Fri, 23 Nov 2007 13:21:10 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ivd9J-0006e3-6q for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 13:21:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivd9I-0006bo-Rq for ima@ietf.org; Fri, 23 Nov 2007 13:21:08 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivd9F-0001TP-DH for ima@ietf.org; Fri, 23 Nov 2007 13:21:08 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007491228.msg for ; Fri, 23 Nov 2007 18:25:42 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 23 Nov 2007 18:20:57 +0000 From: "Debbie Garside" To: "'IMA'" References: <20071122134957.GE25692@dba3> Subject: RE: [EAI] Second Last Call - EAI protocol core documents Date: Fri, 23 Nov 2007 18:20:57 -0000 Message-ID: <01ba01c82dfd$98118540$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acgt9OBkIZx66jz/TP+Zuw/In89c3gAB3d+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Fri, 23 Nov 2007 18:25:42 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1847e3886d=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ima@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 23 Nov 2007 18:25:43 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi Quick question with regard to http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-08.txt On page 10 the draft states this: "Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted." On page 11 the draft states this: "Restrictions on usage: This is a structured media type which embeds other MIME media types. The 8-bit or binary content-transfer- encoding MUST be used unless this media type is sent over a 7-bit only transport." This use of "recommended" and "MUST" seem somewhat contradictory. Best regards Debbie Garside _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 23 14:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IveRd-0001ex-RH; Fri, 23 Nov 2007 14:44:09 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IveRc-0001Vv-A0 for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 14:44:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IveRb-0001Vn-VY for ima@ietf.org; Fri, 23 Nov 2007 14:44:08 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IveRb-0005f0-Ak for ima@ietf.org; Fri, 23 Nov 2007 14:44:07 -0500 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1IveRZ-0007AW-0Q; Fri, 23 Nov 2007 14:44:05 -0500 Date: Fri, 23 Nov 2007 14:44:03 -0500 From: John C Klensin To: Martin Duerst Subject: Re: [EAI] A collision free ACE for internationlizedemail addresses Message-ID: <6DE52E4FB30BDAB4CBDF2BCD@[192.168.1.110]> In-Reply-To: <6.0.0.20.2.20071122113243.07af6c30@localhost> References: <474232B3.9010900@icu.ac.kr> <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> <6.0.0.20.2.20071122113243.07af6c30@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, November 22, 2007 11:34 AM +0900 Martin Duerst wrote: >> It is suggestive of one of >> the flaws in the model of TLDs that are tied to languages and >> presumably administrative unavailable to people who are not >> normally associated with that language community, but that >> isn't this WG's (or the IETF's) problem. > > Hello John, > > I have had difficulties parsing/understanding the last sentence > in your paragraph. Could you explain (probably just giving an > example may be enough). Sorry. ICANN problem, not an IETF one. There have been several suggestions to create language-specific TLDs and restrict all registrations and use of those domains (all the way down the tree) to labels in the specific language represented by the TLD and, in many cases, to speakers of those languages authorized by the countries that see themselves as controlling them. There have even been some suggestions that the DNS's matching rules should change based on the language (as defined by the TLD). There are, to put it mildly, several issues with those ideas. The DNS doesn't know anything about language and most labels are not "words" in any language. In a distributed administrative hierarchy, it is not clear how such rules would be enforced if one wanted to enforce them. The "different matching rules" idea is just not feasible without radical changes to the DNS itself. The question of who could make a sufficient claim to ownership of a language to control the TLD specific to that language boggles my mind. An interpretation of Chris's point about having all of the domain name in a the same language (or script) as the local-part would require that someone obtain a domain name for a mail server in each relevant language. That isn't really what I was thinking about -- I was more concerned about the local-part than about the domain name. But, if one did somehow insist that the entire address be in the same script, one might have to negotiate with the appointed owners of the language-TLD for a registration. The difficulties that implies strike me as another argument against language-specific TLDs, rather than one against the EAI model. But this is getting very far off the WG's mission and charter. Speaking of that charter, this is probably the right time to remind people that EAI was chartered to explore one very specific approach, leading to Experimental, not Standards-track documents. That approach includes a "no ACE in addresses" assumption, independent of whether that assumption is logically necessary given the base email protocols (as I believe it to be). If Chris (or others) want to explore a different approach, e.g., to see how far an ACE approach can be pushed and what constraints it would imply, then I believe he or they should be producing an I-D and looking for BOFs and/or a WG, not trying to refine such a proposal in snippets on this list. That is just opinion, of course. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 23 17:39:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvhBQ-0005qt-4E; Fri, 23 Nov 2007 17:39:36 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvhBP-0005mt-Fw for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 17:39:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvhBP-0005iu-4e for ima@ietf.org; Fri, 23 Nov 2007 17:39:35 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvhBO-0003Uu-M0 for ima@ietf.org; Fri, 23 Nov 2007 17:39:34 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EC18224082E; Fri, 23 Nov 2007 22:39:18 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 3E97B157673; Fri, 23 Nov 2007 23:22:14 +0100 (CET) Date: Fri, 23 Nov 2007 23:22:14 +0100 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: [EAI] A collision free ACE for internationlized email addresses Message-ID: <20071123222213.GA25491@laperouse.bortzmeyer.org> References: <474232B3.9010900@icu.ac.kr> <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Nov 20, 2007 at 12:59:06PM -0500, John C Klensin wrote a message of 104 lines which said: > we continue to have problems with web sites that accept email > addresses with local parts that contain "strange" characters such as > "+" or "=" Unfortunately true. The warning in section 6.3 of RFC 4952 is very accurate, alas. Speaking about this issue, two references: * a new I-D which tries to standardize these "sub-addresses". Not sure that it is a good idea, I did not read it yet. Title : Internet Email Subaddressing Author(s) : D. Cridland Filename : draft-newman-email-subaddr-01.txt Pages : 12 Date : 2007-11-16 * A very good article of Douglas Lovell in Linux Journal (http://www.linuxjournal.com/article/9585), "Validate an E-Mail Address with PHP, the Right Way". To quote it: "There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard." _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 23 17:49:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvhKW-0007mb-0I; Fri, 23 Nov 2007 17:49:00 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvhKU-0007mW-TX for ima-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 17:48:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvhKU-0007mO-JH for ima@ietf.org; Fri, 23 Nov 2007 17:48:58 -0500 Received: from ns1.qubic.net ([208.69.177.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvhKU-0003tM-4b for ima@ietf.org; Fri, 23 Nov 2007 17:48:58 -0500 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2/8.14.2) with ESMTP id lANMmeYP007316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 14:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1195858136; x=1195944536; bh=uWlrSbTab1jCItdDO0qbCDett4/uXokS989+ A6DvMQQ=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type; b=iaL f09+aSQn0zMFyohVwv7O9dUJcuQ8L9Y6qkPrflC+gcaiFqKwyHcrzURf5ujpPWYTTWT PxgiBN6XwnmAgFYYi7BBroDU0lVvneOKuhvD2O8TvkghYKPTGS7XDJ9UP3K9ab/rPRO i1r8XnwM+2ZlVrjZyjUgd6yWhcC7JpERwA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=iHcQg246fMQ5dKl06CkIauajhlBSIC/5lejYV8yA9oC+jFEIN3nntcnRyn3qt4h06 Vwuc4ykpNhOEArThyGAXQ0X52xb67REsl/6UrTrbYurNdHdKQQBMrWZnkksV4Zfg1Bl /DMjAxxd6uJOmO6J5E8ASsOThtrex2fJlba8oUk= Message-Id: <6.2.5.6.2.20071123144252.02df9150@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Nov 2007 14:48:12 -0800 To: Stephane Bortzmeyer From: SM Subject: Re: [EAI] A collision free ACE for internationlized email addresses In-Reply-To: <20071123222213.GA25491@laperouse.bortzmeyer.org> References: <474232B3.9010900@icu.ac.kr> <2F1C0D79AB52786DB87C53A0@p3.JCK.COM> <20071123222213.GA25491@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: eai list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 14:22 23-11-2007, Stephane Bortzmeyer wrote: >Speaking about this issue, two references: > >* a new I-D which tries to standardize these "sub-addresses". Not sure >that it is a good idea, I did not read it yet. > Title : Internet Email Subaddressing > Author(s) : D. Cridland > Filename : draft-newman-email-subaddr-01.txt See the Acknowledgements section of that draft. :-) Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Nov 24 06:29:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtCJ-00022u-WB; Sat, 24 Nov 2007 06:29:20 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IvtCJ-00022m-LP for ima-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:29:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtCJ-00022e-Bp; Sat, 24 Nov 2007 06:29:19 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtCF-0006kL-7K; Sat, 24 Nov 2007 06:29:19 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17f474833e5; Sat, 24 Nov 2007 19:42:12 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17947420772; Tue, 20 Nov 2007 01:31:04 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 20 Nov 2007 01:31:04 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuADQ-0004Iu-3U; Mon, 19 Nov 2007 12:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuAD9-00040E-H0; Mon, 19 Nov 2007 12:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuAD8-0002TM-AV; Mon, 19 Nov 2007 12:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2B37F327BC; Mon, 19 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuAD8-0002o5-0f; Mon, 19 Nov 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 12:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-08.txt X-BeenThere: ima@ietf.org Reply-To: internet-drafts@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-08.txt Pages : 17 Date : 2007-11-19 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19112313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19112313.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Nov 26 02:24:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwYKo-0006RH-Kg; Mon, 26 Nov 2007 02:24:50 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IwYKn-0006RC-JI for ima-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 02:24:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwYKn-0006R4-9u for ima@ietf.org; Mon, 26 Nov 2007 02:24:49 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwYKg-0005HN-Ro for ima@ietf.org; Mon, 26 Nov 2007 02:24:49 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IwYKd-0000Rr-9g for ima@ietf.org; Mon, 26 Nov 2007 07:24:39 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 07:24:39 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 07:24:39 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 26 Nov 2007 08:21:05 +0100 Lines: 27 Message-ID: References: <20071122134957.GE25692@dba3> <01ba01c82dfd$98118540$0d00a8c0@CPQ86763045110> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [EAI] Re: Second Last Call - EAI protocol core documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Debbie Garside wrote: > "Encoding considerations: Any content-transfer-encoding is permitted. > The 8-bit or binary content-transfer-encodings are recommended > where permitted." [...] > "Restrictions on usage: This is a structured media type which embeds > other MIME media types. The 8-bit or binary content-transfer- > encoding MUST be used unless this media type is sent over a 7-bit > only transport." =20 > This use of "recommended" and "MUST" seem somewhat contradictory. Guessing: The lower case "recommended" addresses the general case, "if it's a message/global mail use 8bit (or binary), stay away from 7bit, QP, B64". But they're still allowed, in the corner case where the message/global is also a message/rfc822 (ASCII). And for the more important case where it must be somehow sent over a 7-bit hop (relevant for delivery status notes, when message/global senders somehow managed that they can receive their DSNs over a 7-bit hop). The later MUSTard limits the QP and B64 damage to necessary cases,=20 DSNs over 7bit to confused senders. They (EAI) use an unreported 2045 erratum for this required stunt, or rather they try to update MIME, we'll see if that flies... ;-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 26 08:37:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe9g-0001MQ-Aq; Mon, 26 Nov 2007 08:37:44 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iwe9f-0001ML-GI for ima-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 08:37:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe9a-0001MA-5W for ima@ietf.org; Mon, 26 Nov 2007 08:37:38 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwe9Z-0000RA-Nh for ima@ietf.org; Mon, 26 Nov 2007 08:37:38 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB08B2596FB for ; Mon, 26 Nov 2007 14:37:36 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24483-02 for ; Mon, 26 Nov 2007 14:37:31 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C8132596E6 for ; Mon, 26 Nov 2007 14:37:31 +0100 (CET) Message-ID: <474ACC1A.3010505@alvestrand.no> Date: Mon, 26 Nov 2007 14:37:30 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [EAI] Draft agenda for the Vancounver WG meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Email Address Internationalization (EAI) AGENDA Meeting : IETF 70, Vancouver, December , 2007 Time : Wednesday, December 5, 09:00-11:30 Location: Salon 1 Chairs : Harald Alvestrand, Xiaodong Lee Agenda : version 1.0 (draft) =================================================== 0900: Administrativia - NOTE WELL - Scribe selection - Blue sheets 0915: Status of core documents (presentation) (chairs) Listing of outstanding issues and expected edits on: - draft-ietf-eai-utf8headers-08.txt - draft-ietf-eai-dsn-05.txt - draft-ietf-eai-smtpext-09.txt 0925: Outstanding issues discussion (chairs) Under this agenda topic, we discuss issues that have been raised on the mailing list and accepted as outstanding unresolved issues. (Section length will vary according to amount of issues raised; if the documents have been sent to IESG already, agenda item will be removed) 1000: Downgrade document (Yoneya, Fujiwara) - Document: draft-ietf-eai-downgrade-05.txt - Issues: 1030: IMAP and POP - IMAP: draft-ietf-eai-imap-utf8-02.txt (Resnick) - POP: draft-ietf-eai-pop-02.txt (Gellens) Five minute recap of status, discussion of issues. One issue worthy of discussion is the possibility of reconstructing downgraded EAI messages from the mailstore, and whether this can achieve fidelity enough to have signatures broken by the downgrade process return to validity. 11:00 Mailing lists (who presents?) - Document: draft-ietf-eai-mailinglist-02.txt - Five minute introduction, issues discussion 11:10 Any Other Business - Discussion of whether Mailto: URL should be adopted now 11:20 Future plans - Review of action items, discussion of realistic schedule for completion of WG's work 11:30 Close of meeting _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 26 14:29:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjeW-00004y-GD; Mon, 26 Nov 2007 14:29:56 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IwjeV-0008Vk-8M for ima-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:29:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjeU-0008Vb-UV for ima@ietf.org; Mon, 26 Nov 2007 14:29:54 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwjeU-0002zb-Iq for ima@ietf.org; Mon, 26 Nov 2007 14:29:54 -0500 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IwjeU-0007h6-78 for ima@ietf.org; Mon, 26 Nov 2007 14:29:54 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 06A3313744; Mon, 26 Nov 2007 14:30:11 -0500 (EST) Date: Mon, 26 Nov 2007 14:30:11 -0500 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Second Last Call - EAI protocol core documents Message-ID: <20071126193011.GG19883@dba3> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear colleagues, On Mon, Nov 19, 2007 at 11:21:46PM +0100, Harald Tveit Alvestrand wrote: > draft-ietf-eai-smtpext-09.txt I apologise that I did not make the deadline for the second LC, and that I have not had time to perform a complete review of the above document. I did not raise objections in the last round. For the record, I have re-read those objections that were raised and the differences between -08 and -09, and I believe the changes are a reasonable response to the objections that were raised. I therefore have no objection to the document advancing. Best regards, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 27 03:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwCF-0001xK-VY; Tue, 27 Nov 2007 03:53:35 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IwwCF-0001x0-DJ for ima-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:53:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwCF-0001wr-31 for ima@ietf.org; Tue, 27 Nov 2007 03:53:35 -0500 Received: from [133.2.253.16] (helo=scmse1.scbb.aoyama.ac.jp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwwCE-0007VG-CZ for ima@ietf.org; Tue, 27 Nov 2007 03:53:35 -0500 Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7a70_6c0770b4_9cb0_11dc_93f3_0014221fa3c9; Tue, 27 Nov 2007 15:17:24 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46846) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Nov 2007 15:13:29 +0900 Message-Id: <6.0.0.20.2.20071127130518.0a795450@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 27 Nov 2007 15:16:23 +0900 To: Harald Alvestrand ,EAI WG From: Martin Duerst Subject: Re: [EAI] Draft agenda for the Vancounver WG meeting In-Reply-To: <474ACC1A.3010505@alvestrand.no> References: <474ACC1A.3010505@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: jwz@jwz.org, Larry Masinter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 22:37 07/11/26, Harald Alvestrand wrote: >11:10 Any Other Business >- Discussion of whether Mailto: URL should be adopted now I have been planning to publish another version of the mailto: draft (currently expired, sorry). I'm of course fine with you discussing the current mailto: spec and the abovementioned draft. However, I'm not sure what you mean by the above agenda item. Do you mean "Discussion of whether the WG should adopt the mailto: URI draft as a draft of the WG"? If that's the case, then I'll be glad to serve as acting editor. If the WG decides to not adopt the abovementioned draft, I plan to proceed with the changes that are independent of EAI (e.g. internationalization of RHL parts and non-addresses), so that we can come back to integrate EAI-related issues in a later update. The main issue I see with adding EAI-related issues into the current draft is that the current RFC is Standards Track, and an update also should be standards track, but the EAI work is at the moment only experimental. I'm not sure whether we can have a half-standards-track, half-experimental draft/RFC. If not, we may need two separate drafts. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 27 05:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxfH-0001n9-FF; Tue, 27 Nov 2007 05:27:39 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IwxfF-0001mo-Vv for ima-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 05:27:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxfF-0001mb-Lz for ima@ietf.org; Tue, 27 Nov 2007 05:27:37 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwxfC-0004x3-6s for ima@ietf.org; Tue, 27 Nov 2007 05:27:37 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew#man$ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.262) id 474bf10c.36b0.58 for ima@ietf.org; Tue, 27 Nov 2007 10:27:24 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id lARARN0c007868 for ; Tue, 27 Nov 2007 10:27:24 GMT Subject: Fwd: Re: [EAI] Second Last Call - EAI protocol core documents References: <20071122134957.GE25692@dba3> <01ba01c82dfd$98118540$0d00a8c0@CPQ86763045110> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 27 Nov 2007 10:27:23 -0000 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 23 Nov 2007 18:20:57 -0000, Debbie Garside wrote: > On page 10 the draft states this: > > "Encoding considerations: Any content-transfer-encoding is permitted. > The 8-bit or binary content-transfer-encodings are recommended > where permitted." > > On page 11 the draft states this: > > "Restrictions on usage: This is a structured media type which embeds > other MIME media types. The 8-bit or binary content-transfer- > encoding MUST be used unless this media type is sent over a 7-bit > only transport." > > This use of "recommended" and "MUST" seem somewhat contradictory. "SHOULD" would seem about right. -- CharlesH.Lindsey---------AtHome,doingmyownthing------------------------ Tel:+441614366131 Web:http://www.cs.man.ac.uk/~chl Email:chl@clerew.man.ac.ukSnail:5ClerewoodAve,CHEADLE,SK83JU,U.K. PGP:2C15F1A9Fingerprint:736DC25193A001E765E8647E14A4ABA5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 27 08:45:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0kS-0007aG-3l; Tue, 27 Nov 2007 08:45:12 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ix0kR-0007Zm-83 for ima-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 08:45:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0kQ-0007ZX-UQ for ima@ietf.org; Tue, 27 Nov 2007 08:45:10 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0kP-0003fc-2R for ima@ietf.org; Tue, 27 Nov 2007 08:45:10 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 14DAF259708; Tue, 27 Nov 2007 14:45:08 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03282-03; Tue, 27 Nov 2007 14:44:59 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 840E725970E; Tue, 27 Nov 2007 14:44:58 +0100 (CET) Message-ID: <474C1F5A.7070708@alvestrand.no> Date: Tue, 27 Nov 2007 14:44:58 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [EAI] Draft agenda for the Vancounver WG meeting References: <474ACC1A.3010505@alvestrand.no> <6.0.0.20.2.20071127130518.0a795450@localhost> In-Reply-To: <6.0.0.20.2.20071127130518.0a795450@localhost> 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: jwz@jwz.org, EAI WG , Larry Masinter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > At 22:37 07/11/26, Harald Alvestrand wrote: > > >> 11:10 Any Other Business >> - Discussion of whether Mailto: URL should be adopted now >> > > I have been planning to publish another version of the mailto: draft > (currently expired, sorry). I'm of course fine with you discussing > the current mailto: spec and the abovementioned draft. > > However, I'm not sure what you mean by the above agenda item. > Do you mean "Discussion of whether the WG should adopt the mailto: > URI draft as a draft of the WG"? > Yes, that's what I meant to ask. I'll add your draft name to the agenda, as "background". > If that's the case, then I'll be glad to serve as acting editor. > If the WG decides to not adopt the abovementioned draft, I plan > to proceed with the changes that are independent of EAI (e.g. > internationalization of RHL parts and non-addresses), so that > we can come back to integrate EAI-related issues in a later update. > > The main issue I see with adding EAI-related issues into the current > draft is that the current RFC is Standards Track, and an update > also should be standards track, but the EAI work is at the moment > only experimental. I'm not sure whether we can have a half-standards-track, > half-experimental draft/RFC. If not, we may need two separate drafts. > That's an important topic for the agenda. Two drafts may be a good thing. > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 29 06:10:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxhHn-0007VP-9h; Thu, 29 Nov 2007 06:10:27 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IxhHl-0007VG-JK for ima-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 06:10:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxhHk-0007V2-KA for ima@ietf.org; Thu, 29 Nov 2007 06:10:24 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxhHk-0001Zh-6t for ima@ietf.org; Thu, 29 Nov 2007 06:10:24 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54AFF2596C9 for ; Thu, 29 Nov 2007 12:10:23 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20953-06 for ; Thu, 29 Nov 2007 12:10:18 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A2622596C7 for ; Thu, 29 Nov 2007 12:10:18 +0100 (CET) Message-ID: <474E9E19.4010004@alvestrand.no> Date: Thu, 29 Nov 2007 12:10:17 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] Summary and closing of the "ACE" discussion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org It is now time to summarize the long thread on the subject of "ACE". My conclusions: - The approach we have taken precludes using an ACE in the SMTP protocol or the message headers inside the UTF8SMTP-supporting domain. This is outside of the approaches the WG was chartered to consider. - The option of defining an ACE as part of the downgrade mechanism, to be used to represent internationalized addresses in the ASCII SMTP domain, has been considered multiple times, and rejected by the WG. We have defined the alt-addr mechanism instead. This issue is closed. - The use of an ACE to represent internationalized email addresses in other protocols, or in documents that are not in a defined protocol, is not on the charter of this working group. So it's out of scope - anyone who wants one has to make the case that one is needed to some group that is responsible for that context, and possibly petition the IESG to recharter this WG to consider it, if the IESG can be convinced that such a recharter would be the right approach. Conclusion: There is nothing more to be discussed here. The ACE discussion is off-topic for this working group. This topic, in this venue, is closed. Harald, speaking as working group chair _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 29 10:34:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlPU-00062z-8H; Thu, 29 Nov 2007 10:34:40 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IxlPS-0005xF-Fg for ima-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:34:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlPS-0005wJ-1i for ima@ietf.org; Thu, 29 Nov 2007 10:34:38 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxlPR-0000ex-JT for ima@ietf.org; Thu, 29 Nov 2007 10:34:37 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7F8D2596C6 for ; Thu, 29 Nov 2007 16:34:36 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28289-01 for ; Thu, 29 Nov 2007 16:34:30 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE8552596C7 for ; Thu, 29 Nov 2007 16:34:29 +0100 (CET) Message-ID: <474EDC05.8060400@alvestrand.no> Date: Thu, 29 Nov 2007 16:34:29 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] Disposition of comments, second Last Call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Given that the comments after second Last Call yielded no indication that those issues need to remain open, the following issues are closed: *1504 ** UTF8HDR 4.2: Nested encodings avoidable? **1505 ** SMTPEXT 2.2/2.8: Scan whole message to determine if UTF8SMTP is required? **1506 ** SMTPEXT cleanup of sections 3-5 The following issue had comments during second Last Call: **1507 **UTF8HDR/DSN: Remove NO-WS_CTL from specification? However, the current resolution seemed to be acceptable to most participants. The following issue remains open because it's on another document, but I believe it's largely OK in the latest document version: 1496 DOWNGRADE: Simple downgrade procedure? The following types of issues got raised during second Last Call: - A number of typos and orphaned notes were found, especially on the UTF8HDR document. The editors will attempt to address those. - The issue of normalization is not really addressed in the document. New ticket number: #1518. Since we're currently in the pre-IETF draft cutoff period, we'll issue new documents after the physical WG meeting, and plan to pass the documents to the IESG after a quick review of those. Hopefully, we'll then be done with this set. Harald, speaking as chair. * _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 30 04:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1mF-0007ih-JT; Fri, 30 Nov 2007 04:03:15 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iy1mF-0007iV-2J for ima-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 04:03:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1mE-0007iL-OS for ima@ietf.org; Fri, 30 Nov 2007 04:03:14 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy1mE-0005fY-DG for ima@ietf.org; Fri, 30 Nov 2007 04:03:14 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76C222596CA for ; Fri, 30 Nov 2007 10:03:13 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00458-01 for ; Fri, 30 Nov 2007 10:03:08 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD4CB2596C7 for ; Fri, 30 Nov 2007 10:03:07 +0100 (CET) Message-ID: <474FD1CB.1080606@alvestrand.no> Date: Fri, 30 Nov 2007 10:03:07 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [EAI] #1518 Normalization - a proposal for resolution X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 remembering the discussions about the normalization issue, what about the following? In section 4.1, replace the "note in draft" with the following text: This document does not make any requirement that UTF-8 be normalized. While normalization, and casefolding where appropriate, is strongly recommended for all identifiers, the intent of this protocol suite is that the UTF-8 characters that are carried are the UTF-8 characters supplied by the sending application. Normalization will not happen as part of mail forwarding. Does that seem appropriate? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 30 04:18:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy21O-0003Gs-VU; Fri, 30 Nov 2007 04:18:54 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iy21O-0003GU-1t for ima-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 04:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy21N-0003GL-OP for ima@ietf.org; Fri, 30 Nov 2007 04:18:53 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy21L-0003lM-Lu for ima@ietf.org; Fri, 30 Nov 2007 04:18:53 -0500 Received: (snipe 2425 invoked by uid 0); 30 Nov 2007 18:19:04 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.662694 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 30 Nov 2007 18:19:03 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: harald@alvestrand.no, ima@ietf.org, yangwooko@gmail.com Message-ID: <474FD578.3000006@icu.ac.kr> Date: Fri, 30 Nov 2007 18:18:48 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [EAI] #1518 Normalization - a proposal for resolution References: <474FD1CB.1080606@alvestrand.no> In-Reply-To: <474FD1CB.1080606@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > > On remembering the discussions about the normalization issue, what about > the following? > > In section 4.1, replace the "note in draft" with the following text: > > This document does not make any requirement that UTF-8 be normalized. > > While normalization, and casefolding where appropriate, is strongly > recommended > for all identifiers, the intent of this protocol suite is that the > UTF-8 characters that > are carried are the UTF-8 characters supplied by the sending application. > > Normalization will not happen as part of mail forwarding. Though normalization, and casefolding where appropriate, is strongly recommended for all identifiers, this document does not make any additional requirement that UTF-8 be normalized, which may be done outside of mail forwarding process. I don't know whether this sounds stronger but I want to make sure that normalization is not within the scope of email forwarding process. > > Does that seem appropriate? > > Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima