From root@core3.amsl.com Sat Jul 3 10:00:01 2010 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D69D73A6834; Sat, 3 Jul 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100703170001.D69D73A6834@core3.amsl.com> Date: Sat, 3 Jul 2010 10:00:01 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-frmwrk-4952bis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 17:00:01 -0000 --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 : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-frmwrk-4952bis-01.txt Pages : 23 Date : 2010-07-03 Full use of electronic mail throughout the world requires that, subject to other constraints, people be able to use close variations on their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952 that reflects additional issues identified since that document was published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-frmwrk-4952bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-frmwrk-4952bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-03094650.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 5 06:15:01 2010 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 91B273A6990; Mon, 5 Jul 2010 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705131501.91B273A6990@core3.amsl.com> Date: Mon, 5 Jul 2010 06:15:01 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-rfc5335bis-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 13:15:01 -0000 --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) : . Yang, S. Steele Filename : draft-ietf-eai-rfc5335bis-00.txt Pages : 14 Date : 2010-07-05 Full internationalization of electronic mail requires not only the capabilities 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 the information based on them in mail header fields. This document specifies an 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. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of [RFC2045] to conform with the requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-rfc5335bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05061128.I-D@ietf.org> --NextPart-- From edainow@ca.afilias.info Wed Jul 7 06:41:39 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDB13A67CF for ; Wed, 7 Jul 2010 06:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxp58PK+0lHk for ; Wed, 7 Jul 2010 06:41:38 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 39DB33A67B6 for ; Wed, 7 Jul 2010 06:41:36 -0700 (PDT) Message-ID: <4C348414.50109@ca.afilias.info> Date: Wed, 07 Jul 2010 09:41:40 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:41:39 -0000 2. Role of This Specification [[anchor2: Note in Draft: Is 5825 still relevant, or is a victim of the "no in-transit downgrade" decision.??]] Comment: RFC 5825 describes how to construct the original headers from the "Downgraded-" headers. This is not relevant unless we are planning to use such headers (defined in 5504) for specifying how a final delivery SMTP server/mail store should downgrade messages that POP or IMAP can restore for UTF8 clients. 7.1 SMTP Extension for Internationalized Email Address Conformance to the group of standards specified here for email transport and delivery requires implementation of the SMTP Extension specification, including recognition of the keywords associated with alternate addresses, and the UTF-8 Header specification. Comment: remove "including recognition of the keywords associated with alternate addresses". 8. Downgrading before and after SMTP Transactions While the experiments that preceded these specifications included a mechanism for passing backup ASCII addresses to intermediate relay systems and having those systems alter the relevant message header fields and substitute the addresses, Comment: add a reference to RFC 5504 for future readers who may not know anything about the Experimental drafts. 9. Downgrading in Transit [[anchor16: ... this section will simply be dropped.]] Comment: Leading up to the recharter, there was a lot of heated discussion on algorithmic/ACE transformations, even though it had been covered at the beginning of the working group. I think we need to capture some of this history or future readers of the standard will raise the same questions again. I suggest the following as a starting point. Section 2.3.11 of RFC 2321, and RFC 2821 before that, states that "due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address". Adherence to this rule means that a downgrade mechanism that transforms the local-part of an email address cannot be done in transit. It can only be done at the endpoints, namely by the MUA or submission server or by the final delivery SMTP server. One of the reasons for this rule has to do with legacy email systems that use source routing in the local-part of the address field. Transforming the email address destroys such routing information. There is no way a server other than the final delivery server can know, for example, whether the local-part of user%foo@example.com is a route ("user" is reached via "foo") or simply a local address. - Ernie From klensin@jck.com Wed Jul 7 08:53:56 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2DF3A67B3 for ; Wed, 7 Jul 2010 08:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDM1fKHkiwzn for ; Wed, 7 Jul 2010 08:53:54 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 93A2B3A67E5 for ; Wed, 7 Jul 2010 08:53:54 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OWWwe-0005EO-O1; Wed, 07 Jul 2010 11:53:56 -0400 Date: Wed, 07 Jul 2010 11:53:55 -0400 From: John C Klensin To: Ernie Dainow , ima@ietf.org Message-ID: <17ED2375A01530ABA3588678@PST.JCK.COM> In-Reply-To: <4C348414.50109@ca.afilias.info> References: <4C348414.50109@ca.afilias.info> 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 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 15:53:56 -0000 Unless there is disagreement with any of these changes, they will be incorporated in -02 (which will probably be posted before the weekend). john --On Wednesday, July 07, 2010 09:41 -0400 Ernie Dainow wrote: > 2. Role of This Specification > [[anchor2: Note in Draft: Is 5825 still relevant, or is a > victim of the "no in-transit downgrade" decision.??]] > > Comment: RFC 5825 describes how to construct the original > headers from the "Downgraded-" headers. This is not relevant > unless we are planning to use such headers (defined in 5504) > for specifying how a final delivery SMTP server/mail store > should downgrade messages that POP or IMAP can restore for > UTF8 clients. > > 7.1 SMTP Extension for Internationalized Email Address > Conformance to the group of standards specified here for email > transport and delivery requires implementation of the SMTP > Extension specification, including recognition of the keywords > associated with alternate addresses, and the UTF-8 Header > specification. > > Comment: remove "including recognition of the keywords > associated with alternate addresses". > > 8. Downgrading before and after SMTP Transactions > While the experiments that preceded these specifications > included a mechanism for passing backup ASCII addresses to > intermediate relay systems and having those systems alter the > relevant message header fields and substitute the addresses, > > Comment: add a reference to RFC 5504 for future readers who > may not know anything about the Experimental drafts. > > 9. Downgrading in Transit > [[anchor16: ... this section will simply be dropped.]] > > Comment: Leading up to the recharter, there was a lot of > heated discussion on algorithmic/ACE transformations, even > though it had been covered at the beginning of the working > group. I think we need to capture some of this history or > future readers of the standard will raise the same questions > again. I suggest the following as a starting point. > > Section 2.3.11 of RFC 2321, and RFC 2821 before that, states > that "due to a long history of problems when intermediate > hosts have attempted to optimize transport by modifying them, > the local-part MUST be interpreted and assigned semantics only > by the host specified in the domain part of the address". > > Adherence to this rule means that a downgrade mechanism that > transforms the local-part of an email address cannot be done > in transit. It can only be done at the endpoints, namely by > the MUA or submission server or by the final delivery SMTP > server. > > One of the reasons for this rule has to do with legacy email > systems that use source routing in the local-part of the > address field. Transforming the email address destroys such > routing information. There is no way a server other than the > final delivery server can know, for example, whether the > local-part of user%foo@example.com is a route ("user" is > reached via "foo") or simply a local address. > > > - Ernie > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Shawn.Steele@microsoft.com Wed Jul 7 12:27:44 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59B13A68B1 for ; Wed, 7 Jul 2010 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.739 X-Spam-Level: X-Spam-Status: No, score=-8.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YES0Mc4dvZYc for ; Wed, 7 Jul 2010 12:27:43 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 93D393A68F0 for ; Wed, 7 Jul 2010 12:27:43 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 7 Jul 2010 12:27:46 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Wed, 7 Jul 2010 12:27:46 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Random thought #1 - UTF8SMTP handshaking Thread-Index: Acsa7yYybDXoz4hGT/WWB0TrTt0mlg== Date: Wed, 7 Jul 2010 19:27:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A0DA4FE36TK5EX14MBXC141r_" MIME-Version: 1.0 Subject: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:27:44 -0000 --_000_E14011F8737B524BB564B05FF748464A0DA4FE36TK5EX14MBXC141r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHdhbnQgdG8gZGVyYWlsIG91ciB0aW1lIGZyYW1lLCBidXQgSSB3YXMgd29uZGVy aW5nIGlmIHRoaXMgd2FzIHdvcnRoIGNvbnNpZGVyaW5nOg0KDQpDdXJyZW50bHkgdGhlIFVURjhT TVRQKGJpcykgZXh0ZW5zaW9uIGlzIGEgb25lLXdheSBoYW5kc2hha2luZy4gIEVnOiB0aGUgY2xp ZW50IGtub3dzIHRoZSBzZXJ2ZXIgdW5kZXJzdGFuZHMgVVRGOFNNVFAsIGhvd2V2ZXIgdGhlcmXi gJlzIG5vIHdheSBmb3IgdGhlIHNlcnZlciB0byBnZW5lcmFsbHkga25vdyBpZiB0aGUgY2xpZW50 IGNhbiBhY2NlcHQgVVRGLTguICBUaGF0IGxlYWRzIHVzIHRvIHRoaW5ncyBsaWtlIOKAnFVURjhS RVBMWeKAnS4gIEFkZGl0aW9uYWxseSwgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZWQg dGhhdCBhIE1BSUwgb3IgUkNQVCBjb21tYW5kIGlzIFVURi04IGp1c3QgYmVjYXVzZSBpdOKAmXMg bm9uIEFTQ0lJIChhIG1pc2JlaGF2aW5nIGNsaWVudCBjb3VsZCBiZSB1c2luZyB0aGVpciBsb2Nh bCA4LWJpdCBjb2RlIHBhZ2Ugb3Igc29tZXRoaW5nKS4gIEl04oCZcyBhbHNvIG5vdCBndWFyYW50 ZWVkIHRoYXQgREFUQSBiZSBVVEYtOCAoSSB0aGluayBoaXN0b3JpY2FsbHkgZGF0YSBoYXMgc29t ZXRpbWVzIHVzZWQgbG9jYWwgY29kZSBwYWdlcywgdGhvdWdoIG5vdyBpdOKAmXMgcHJvYmFibHkg bW9yZSBsaWtlbHkgdG8gYmUgY29ycmVjdGx5IHRhZ2dlZCkuDQoNClRvIG1lLCBzdGFtcGluZyDi gJxVVEY4eHh4eOKAnSBvbiBldmVyeSBjb21tYW5kIHNlZW1zIHByZXR0eSBhd2t3YXJkLiAgU2hv dWxkIHdlIGNvbnNpZGVyIGEg4oCcVVRGOOKAnSBjb21tYW5kIHRoYXQgYSBjbGllbnQgY2FuIHVz ZSB0byBjb25maXJtIHRoYXQgaXQgaGFuZGxlcyBVVEYtOD8gIFRoZW4gdGhlIGhhbmRzaGFraW5n IGRvZXNu4oCZdCBoYXZlIHRvIGhhcHBlbiB3aXRoIGV2ZXJ5IGNvbW1hbmQ/ICBFZzoNCg0KVVRG OA0KMjUwIE9rDQpNQUlMIEZST006PHV0ZjhAaWRuLnRsZD4NCjI1MCBPaw0K4oCmDQpEQVRBDQri gKYgdXRmOCBkYXRhIOKApg0KLg0KDQpBcyBtZW50aW9uZWQsIEkgZG9u4oCZdCB3YW50IHRvIGNh dXNlIGEgbG90IG9mIGRlbGF5IGRpc2N1c3NpbmcgdGhpcywgYnV0IGlzIGl0IHdvcnRoIGNvbnNp ZGVyaW5nPyAgV291bGQgaXQgYmUgdG9vIG11Y2ggY2h1cm4/DQoNCi1TaGF3bg0KDQrvo6Lvo5Dv o6fvo5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUNCg0K --_000_E14011F8737B524BB564B05FF748464A0DA4FE36TK5EX14MBXC141r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb2RlMjAwMDsNCglwYW5vc2UtMToyIDAg NiAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQ29kZTIwMDAi Ow0KCXBhbm9zZS0xOjIgMCA2IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZG9u4oCZdCB3YW50IHRvIGRlcmFpbCBvdXIgdGltZSBmcmFtZSwgYnV0IEkgd2FzIHdvbmRl cmluZyBpZiB0aGlzIHdhcyB3b3J0aCBjb25zaWRlcmluZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q3VycmVudGx5IHRoZSBVVEY4U01UUChiaXMpIGV4dGVuc2lvbiBpcyBhIG9uZS13YXkgaGFu ZHNoYWtpbmcuJm5ic3A7IEVnOiB0aGUgY2xpZW50IGtub3dzIHRoZSBzZXJ2ZXIgdW5kZXJzdGFu ZHMgVVRGOFNNVFAsIGhvd2V2ZXIgdGhlcmXigJlzIG5vIHdheSBmb3IgdGhlIHNlcnZlciB0byBn ZW5lcmFsbHkga25vdyBpZiB0aGUgY2xpZW50IGNhbiBhY2NlcHQgVVRGLTguJm5ic3A7IFRoYXQg bGVhZHMgdXMgdG8gdGhpbmdzIGxpa2UNCiDigJxVVEY4UkVQTFnigJ0uJm5ic3A7IEFkZGl0aW9u YWxseSwgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZWQgdGhhdCBhIE1BSUwgb3IgUkNQ VCBjb21tYW5kIGlzIFVURi04IGp1c3QgYmVjYXVzZSBpdOKAmXMgbm9uIEFTQ0lJIChhIG1pc2Jl aGF2aW5nIGNsaWVudCBjb3VsZCBiZSB1c2luZyB0aGVpciBsb2NhbCA4LWJpdCBjb2RlIHBhZ2Ug b3Igc29tZXRoaW5nKS4mbmJzcDsgSXTigJlzIGFsc28gbm90IGd1YXJhbnRlZWQgdGhhdCBEQVRB IGJlIFVURi04IChJIHRoaW5rDQogaGlzdG9yaWNhbGx5IGRhdGEgaGFzIHNvbWV0aW1lcyB1c2Vk IGxvY2FsIGNvZGUgcGFnZXMsIHRob3VnaCBub3cgaXTigJlzIHByb2JhYmx5IG1vcmUgbGlrZWx5 IHRvIGJlIGNvcnJlY3RseSB0YWdnZWQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBtZSwg c3RhbXBpbmcg4oCcVVRGOHh4eHjigJ0gb24gZXZlcnkgY29tbWFuZCBzZWVtcyBwcmV0dHkgYXdr d2FyZC4mbmJzcDsgU2hvdWxkIHdlIGNvbnNpZGVyIGEg4oCcVVRGOOKAnSBjb21tYW5kIHRoYXQg YSBjbGllbnQgY2FuIHVzZSB0byBjb25maXJtIHRoYXQgaXQgaGFuZGxlcyBVVEYtOD8mbmJzcDsg VGhlbiB0aGUgaGFuZHNoYWtpbmcgZG9lc27igJl0IGhhdmUgdG8gaGFwcGVuIHdpdGggZXZlcnkg Y29tbWFuZD8mbmJzcDsgRWc6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVURjg8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjI1MCBPazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TUFJTCBGUk9NOiZsdDt1dGY4QGlkbi50bGQmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yNTAgT2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPuKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+REFU QTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmIHV0ZjggZGF0YSDigKY8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgbWVudGlvbmVkLCBJIGRvbuKAmXQgd2FudCB0byBjYXVzZSBhIGxvdCBvZiBkZWxh eSBkaXNjdXNzaW5nIHRoaXMsIGJ1dCBpcyBpdCB3b3J0aCBjb25zaWRlcmluZz8mbmJzcDsgV291 bGQgaXQgYmUgdG9vIG11Y2ggY2h1cm4/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1TaGF3bjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29kZTIwMDAi Pu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUi Pmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_E14011F8737B524BB564B05FF748464A0DA4FE36TK5EX14MBXC141r_-- From jyee@ca.afilias.info Wed Jul 7 12:59:43 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30BF3A697A for ; Wed, 7 Jul 2010 12:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jHiofCnG9p4 for ; Wed, 7 Jul 2010 12:59:42 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 609CD3A6908 for ; Wed, 7 Jul 2010 12:59:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Joseph Yee In-Reply-To: Date: Wed, 7 Jul 2010 15:59:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Shawn Steele X-Mailer: Apple Mail (2.1081) X-Authenticated: True Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:59:43 -0000 Hi Shawn, Most commands sent from server to client are purely status responses in = pure ASCII, so it's almost not necessary. Except 2 commands, which were = documented in RFC 5336 bis, and had suggested to use keyword like = UTF8REPLY to indicate its capability to accept response with UTF8 = content. And as you mentioned too, I think it's not time for status response = coming back in non-ASCII form now :) best Joseph On 2010-07-07, at 3:27 PM, Shawn Steele wrote: > I don=E2=80=99t want to derail our time frame, but I was wondering if = this was worth considering: > =20 > Currently the UTF8SMTP(bis) extension is a one-way handshaking. Eg: = the client knows the server understands UTF8SMTP, however there=E2=80=99s = no way for the server to generally know if the client can accept UTF-8. = That leads us to things like =E2=80=9CUTF8REPLY=E2=80=9D. Additionally, = it is not necessarily guaranteed that a MAIL or RCPT command is UTF-8 = just because it=E2=80=99s non ASCII (a misbehaving client could be using = their local 8-bit code page or something). It=E2=80=99s also not = guaranteed that DATA be UTF-8 (I think historically data has sometimes = used local code pages, though now it=E2=80=99s probably more likely to = be correctly tagged). > =20 > To me, stamping =E2=80=9CUTF8xxxx=E2=80=9D on every command seems = pretty awkward. Should we consider a =E2=80=9CUTF8=E2=80=9D command = that a client can use to confirm that it handles UTF-8? Then the = handshaking doesn=E2=80=99t have to happen with every command? Eg: > =20 > UTF8 > 250 Ok > MAIL FROM: > 250 Ok > =E2=80=A6 > DATA > =E2=80=A6 utf8 data =E2=80=A6 > . > =20 > As mentioned, I don=E2=80=99t want to cause a lot of delay discussing = this, but is it worth considering? Would it be too much churn? > =20 > -Shawn > =20 > =EF=A3=A2=EF=A3=90=EF=A3=A7=EF=A3=9B =EF=A3=A2=EF=A3=A3=EF=A3=97=EF=A3=94= =EF=A3=99 > http://blogs.msdn.com/shawnste > =20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Shawn.Steele@microsoft.com Wed Jul 7 13:12:41 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59723A693E for ; Wed, 7 Jul 2010 13:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3bCbv32eQWm for ; Wed, 7 Jul 2010 13:12:40 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0C74E3A68CE for ; Wed, 7 Jul 2010 13:12:40 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 7 Jul 2010 13:12:42 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0160.007; Wed, 7 Jul 2010 13:12:42 -0700 From: Shawn Steele To: Joseph Yee Thread-Topic: [EAI] Random thought #1 - UTF8SMTP handshaking Thread-Index: Acsa7yYybDXoz4hGT/WWB0TrTt0mlgDWnGwAAA5CvrA= Date: Wed, 7 Jul 2010 20:12:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:12:42 -0000 QnV0LCBJIHRoaW5rLCB0aGF0IHRoZSBzZXJ2ZXIgZG9lc24ndCBrbm93ICJmb3Igc3VyZSIgdGhh dCBGUk9NLCBSQ1BUIGFuZCBEQVRBIGFyZSBhbHNvIFVURi04LiAgKEl0IGNhbiAiZ3Vlc3MiLCBz aW5jZSB0aGV5J2xsIGhhdmUgZGF0YSA+IDB4N2YsIGhvd2V2ZXIgY2FuIGl0IGJlIHN1cmU/KQ0K DQpOb3QgYSBiaWcgZGVhbCwgb25seSB3ZWlyZCBiZWhhdmluZywgcHJvYmFibHkgb2xkZXIgc3R1 ZmYgd291bGQgYWN0IHVwLCBidXQgPw0KDQotU2hhd24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEpvc2VwaCBZZWUgW21haWx0bzpqeWVlQGNhLmFmaWxpYXMuaW5mb10gDQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMDcsIDIwMTAgMTowMCBQTQ0KVG86IFNoYXduIFN0ZWVsZQ0K Q2M6IGltYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFQUldIFJhbmRvbSB0aG91Z2h0ICMxIC0g VVRGOFNNVFAgaGFuZHNoYWtpbmcNCg0KSGkgU2hhd24sDQoNCk1vc3QgY29tbWFuZHMgc2VudCBm cm9tIHNlcnZlciB0byBjbGllbnQgYXJlIHB1cmVseSBzdGF0dXMgcmVzcG9uc2VzIGluIHB1cmUg QVNDSUksIHNvIGl0J3MgYWxtb3N0IG5vdCBuZWNlc3NhcnkuICBFeGNlcHQgMiBjb21tYW5kcywg d2hpY2ggd2VyZSBkb2N1bWVudGVkIGluIFJGQyA1MzM2IGJpcywgYW5kIGhhZCBzdWdnZXN0ZWQg dG8gdXNlIGtleXdvcmQgbGlrZSBVVEY4UkVQTFkgdG8gaW5kaWNhdGUgaXRzIGNhcGFiaWxpdHkg dG8gYWNjZXB0IHJlc3BvbnNlIHdpdGggVVRGOCBjb250ZW50Lg0KDQpBbmQgYXMgeW91IG1lbnRp b25lZCB0b28sIEkgdGhpbmsgaXQncyBub3QgdGltZSBmb3Igc3RhdHVzIHJlc3BvbnNlIGNvbWlu ZyBiYWNrIGluIG5vbi1BU0NJSSBmb3JtIG5vdyA6KQ0KDQpiZXN0DQpKb3NlcGgNCg0KT24gMjAx MC0wNy0wNywgYXQgMzoyNyBQTSwgU2hhd24gU3RlZWxlIHdyb3RlOg0KDQo+IEkgZG9u4oCZdCB3 YW50IHRvIGRlcmFpbCBvdXIgdGltZSBmcmFtZSwgYnV0IEkgd2FzIHdvbmRlcmluZyBpZiB0aGlz IHdhcyB3b3J0aCBjb25zaWRlcmluZzoNCj4gIA0KPiBDdXJyZW50bHkgdGhlIFVURjhTTVRQKGJp cykgZXh0ZW5zaW9uIGlzIGEgb25lLXdheSBoYW5kc2hha2luZy4gIEVnOiB0aGUgY2xpZW50IGtu b3dzIHRoZSBzZXJ2ZXIgdW5kZXJzdGFuZHMgVVRGOFNNVFAsIGhvd2V2ZXIgdGhlcmXigJlzIG5v IHdheSBmb3IgdGhlIHNlcnZlciB0byBnZW5lcmFsbHkga25vdyBpZiB0aGUgY2xpZW50IGNhbiBh Y2NlcHQgVVRGLTguICBUaGF0IGxlYWRzIHVzIHRvIHRoaW5ncyBsaWtlIOKAnFVURjhSRVBMWeKA nS4gIEFkZGl0aW9uYWxseSwgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZWQgdGhhdCBh IE1BSUwgb3IgUkNQVCBjb21tYW5kIGlzIFVURi04IGp1c3QgYmVjYXVzZSBpdOKAmXMgbm9uIEFT Q0lJIChhIG1pc2JlaGF2aW5nIGNsaWVudCBjb3VsZCBiZSB1c2luZyB0aGVpciBsb2NhbCA4LWJp dCBjb2RlIHBhZ2Ugb3Igc29tZXRoaW5nKS4gIEl04oCZcyBhbHNvIG5vdCBndWFyYW50ZWVkIHRo YXQgREFUQSBiZSBVVEYtOCAoSSB0aGluayBoaXN0b3JpY2FsbHkgZGF0YSBoYXMgc29tZXRpbWVz IHVzZWQgbG9jYWwgY29kZSBwYWdlcywgdGhvdWdoIG5vdyBpdOKAmXMgcHJvYmFibHkgbW9yZSBs aWtlbHkgdG8gYmUgY29ycmVjdGx5IHRhZ2dlZCkuDQo+ICANCj4gVG8gbWUsIHN0YW1waW5nIOKA nFVURjh4eHh44oCdIG9uIGV2ZXJ5IGNvbW1hbmQgc2VlbXMgcHJldHR5IGF3a3dhcmQuICBTaG91 bGQgd2UgY29uc2lkZXIgYSDigJxVVEY44oCdIGNvbW1hbmQgdGhhdCBhIGNsaWVudCBjYW4gdXNl IHRvIGNvbmZpcm0gdGhhdCBpdCBoYW5kbGVzIFVURi04PyAgVGhlbiB0aGUgaGFuZHNoYWtpbmcg ZG9lc27igJl0IGhhdmUgdG8gaGFwcGVuIHdpdGggZXZlcnkgY29tbWFuZD8gIEVnOg0KPiAgDQo+ IFVURjgNCj4gMjUwIE9rDQo+IE1BSUwgRlJPTTo8dXRmOEBpZG4udGxkPg0KPiAyNTAgT2sNCj4g 4oCmDQo+IERBVEENCj4g4oCmIHV0ZjggZGF0YSDigKYNCj4gLg0KPiAgDQo+IEFzIG1lbnRpb25l ZCwgSSBkb27igJl0IHdhbnQgdG8gY2F1c2UgYSBsb3Qgb2YgZGVsYXkgZGlzY3Vzc2luZyB0aGlz LCBidXQgaXMgaXQgd29ydGggY29uc2lkZXJpbmc/ICBXb3VsZCBpdCBiZSB0b28gbXVjaCBjaHVy bj8NCj4gIA0KPiAtU2hhd24NCj4gIA0KPiDvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZDQo+ IGh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0KPiAgDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1B QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQoN Cg0K From yaojk@cnnic.cn Wed Jul 7 20:57:01 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8BB3A67CC for ; Wed, 7 Jul 2010 20:57:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.314 X-Spam-Level: * X-Spam-Status: No, score=1.314 tagged_above=-999 required=5 tests=[AWL=2.225, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJlM3HDX-BPh for ; Wed, 7 Jul 2010 20:57:00 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id A22723A67B6 for ; Wed, 7 Jul 2010 20:56:59 -0700 (PDT) Received: (eyou send program); Thu, 08 Jul 2010 11:57:02 +0800 Message-ID: <478561422.04056@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 08 Jul 2010 11:57:02 +0800 Message-ID: <58197F284E09484286672B4C106C49AC@LENOVO47E041CF> From: "Jiankang YAO" To: "Shawn Steele" , References: <478530872.30112@cnnic.cn> Date: Thu, 8 Jul 2010 11:57:14 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023F_01CB1E94.B4A42340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 03:57:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_023F_01CB1E94.B4A42340 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcVVRGOFJFUExZ4oCdIGlzIHRvIGluZm9ybSB0aGUgc2VydmVyIHRoYXQgdGhlIGNsaWVudCBj YW4gc3VwcG9ydCB1dGY4LiB3aXRob3V0IOKAnFVURjhSRVBMWeKAnSwgdGhlIHNlcnZlciB3aWxs IGlzc3VlIHRoZSBhc2NpaSBtZXNzYWdlIG9ubHkuDQoNCm9uIHRoZSBvdGhlciBoYW5kLA0KDQpp ZiB0aGUgY2xpZW50IGNhbiB1c2UgbWFpbCBmcm9tIG9yIHJjcHQgdG8gIHdpdGggdGhlIHV0ZjhA dXRmOCwgaXQgbWVhbnMgdGhhdCB0aGUgY2xpZW50IGNhbiBzdXBwb3J0IHV0ZjguDQpUaGUgc2Vy dmUgY2FuIGtub3cgdGhlIGNsaWVudCdzIGFiaWxpdHkgdGhyb3VnaCB0aGUgbWVzc2FnZSB0aGUg c2VydmVyIHJlY2lldmVzIGZyb20gdGhlIGNsaWVudC4NCg0Kc28geW91ciB0d28gd2F5IGhhbmRz YWtpbmcgaXMgdGhlb3JldGljYWwgcG9zc2libGUsIGJ1dCBub3QgcHJhY3RpY2FibGUgb3IgbmVj ZXNzYXJ5Lg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBTaGF3biBT dGVlbGUgDQogIFRvOiBpbWFAaWV0Zi5vcmcgDQogIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAy MDEwIDM6MjcgQU0NCiAgU3ViamVjdDogW0VBSV0gUmFuZG9tIHRob3VnaHQgIzEgLSBVVEY4U01U UCBoYW5kc2hha2luZw0KDQoNCiAgSSBkb27igJl0IHdhbnQgdG8gZGVyYWlsIG91ciB0aW1lIGZy YW1lLCBidXQgSSB3YXMgd29uZGVyaW5nIGlmIHRoaXMgd2FzIHdvcnRoIGNvbnNpZGVyaW5nOg0K DQogICANCg0KICBDdXJyZW50bHkgdGhlIFVURjhTTVRQKGJpcykgZXh0ZW5zaW9uIGlzIGEgb25l LXdheSBoYW5kc2hha2luZy4gIEVnOiB0aGUgY2xpZW50IGtub3dzIHRoZSBzZXJ2ZXIgdW5kZXJz dGFuZHMgVVRGOFNNVFAsIGhvd2V2ZXIgdGhlcmXigJlzIG5vIHdheSBmb3IgdGhlIHNlcnZlciB0 byBnZW5lcmFsbHkga25vdyBpZiB0aGUgY2xpZW50IGNhbiBhY2NlcHQgVVRGLTguICBUaGF0IGxl YWRzIHVzIHRvIHRoaW5ncyBsaWtlIOKAnFVURjhSRVBMWeKAnS4gIEFkZGl0aW9uYWxseSwgaXQg aXMgbm90IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZWQgdGhhdCBhIE1BSUwgb3IgUkNQVCBjb21tYW5k IGlzIFVURi04IGp1c3QgYmVjYXVzZSBpdOKAmXMgbm9uIEFTQ0lJIChhIG1pc2JlaGF2aW5nIGNs aWVudCBjb3VsZCBiZSB1c2luZyB0aGVpciBsb2NhbCA4LWJpdCBjb2RlIHBhZ2Ugb3Igc29tZXRo aW5nKS4gIEl04oCZcyBhbHNvIG5vdCBndWFyYW50ZWVkIHRoYXQgREFUQSBiZSBVVEYtOCAoSSB0 aGluayBoaXN0b3JpY2FsbHkgZGF0YSBoYXMgc29tZXRpbWVzIHVzZWQgbG9jYWwgY29kZSBwYWdl cywgdGhvdWdoIG5vdyBpdOKAmXMgcHJvYmFibHkgbW9yZSBsaWtlbHkgdG8gYmUgY29ycmVjdGx5 IHRhZ2dlZCkuDQoNCiAgIA0KDQogIFRvIG1lLCBzdGFtcGluZyDigJxVVEY4eHh4eOKAnSBvbiBl dmVyeSBjb21tYW5kIHNlZW1zIHByZXR0eSBhd2t3YXJkLiAgU2hvdWxkIHdlIGNvbnNpZGVyIGEg 4oCcVVRGOOKAnSBjb21tYW5kIHRoYXQgYSBjbGllbnQgY2FuIHVzZSB0byBjb25maXJtIHRoYXQg aXQgaGFuZGxlcyBVVEYtOD8gIFRoZW4gdGhlIGhhbmRzaGFraW5nIGRvZXNu4oCZdCBoYXZlIHRv IGhhcHBlbiB3aXRoIGV2ZXJ5IGNvbW1hbmQ/ICBFZzoNCg0KICAgDQoNCiAgVVRGOA0KDQogIDI1 MCBPaw0KDQogIE1BSUwgRlJPTTo8dXRmOEBpZG4udGxkPg0KDQogIDI1MCBPaw0KDQogIOKApg0K DQogIERBVEENCg0KICDigKYgdXRmOCBkYXRhIOKApg0KDQogIC4NCg0KICAgDQoNCiAgQXMgbWVu dGlvbmVkLCBJIGRvbuKAmXQgd2FudCB0byBjYXVzZSBhIGxvdCBvZiBkZWxheSBkaXNjdXNzaW5n IHRoaXMsIGJ1dCBpcyBpdCB3b3J0aCBjb25zaWRlcmluZz8gIFdvdWxkIGl0IGJlIHRvbyBtdWNo IGNodXJuPw0KDQogICANCg0KICAtU2hhd24NCg0KICAgDQoNCiAg76Oi76OQ76On76ObIO+jou+j o++jl++jlO+jmQ0KDQogIGh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0KDQogICANCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgSU1BIG1haWxpbmcgbGlzdA0KICBJTUFAaWV0Zi5v cmcNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCg== ------=_NextPart_000_023F_01CB1E94.B4A42340 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+ DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTI4Ij4N CjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQ2FtYnJpYSBNYXRoOw0KfQ0KQGZv bnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IENhbGlicmk7DQp9DQpAZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogQ29kZTIwMDA7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQENvZGUy MDAwOw0KfQ0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1hcmdpbjog MS4waW4gMS4waW4gMS4waW4gMS4waW47IH0NClAuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBpbiAw aW4gMHB0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAx MXB0DQp9DQpMSS5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZ OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQNCn0NCkRJVi5Nc29Ob3Jt YWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOyBGT05ULVNJWkU6IDExcHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQt REVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1z b0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBt c28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRF WFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFO Lk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjogd2luZG93dGV4 dDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCi5Nc29DaHBEZWZhdWx0IHsN CglGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAxMHB0OyBt c28tc3R5bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5Xb3JkU2VjdGlvbjEgew0KCXBhZ2U6 IFdvcmRTZWN0aW9uMQ0KfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgYmdD b2xvcj0jY2NlOGNmIHZMaW5rPXB1cnBsZT4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2T PuKAnFVURjhSRVBMWeKAnSBpcyB0byBpbmZvcm0gdGhlIHNlcnZlciB0aGF0IHRoZSBjbGllbnQg DQpjYW4gc3VwcG9ydCB1dGY4LiB3aXRob3V0IOKAnFVURjhSRVBMWeKAnSwgdGhlIHNlcnZlciB3 aWxsIGlzc3VlIHRoZSBhc2NpaSBtZXNzYWdlIA0Kb25seS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPeWui+S9kz5vbiB0aGUgb3RoZXIgaGFuZCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPeWui+S9kz5pZiB0aGUgY2xpZW50IGNhbiB1c2UgbWFpbCBmcm9tIG9yIHJjcHQg dG8mbmJzcDsgd2l0aCANCnRoZSA8QSBocmVmPSJtYWlsdG86dXRmOEB1dGY4Ij51dGY4QHV0Zjg8 L0E+LCBpdCBtZWFucyB0aGF0IHRoZSBjbGllbnQgY2FuIA0Kc3VwcG9ydCB1dGY4LjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPlRoZSBzZXJ2ZSBjYW4ga25vdyB0 aGUgY2xpZW50J3MgYWJpbGl0eSB0aHJvdWdoIHRoZSANCm1lc3NhZ2UgdGhlIHNlcnZlciByZWNp ZXZlcyBmcm9tIHRoZSBjbGllbnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovk vZM+c28geW91ciB0d28gd2F5IGhhbmRzYWtpbmcgaXMgPFNQQU4gDQpjbGFzcz10cmFucz50aGVv cmV0aWNhbDwvU1BBTj4gcG9zc2libGUsIGJ1dCBub3QgcHJhY3RpY2FibGUgb3IgDQpuZWNlc3Nh cnkuPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJH SU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCDlrovkvZM7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJs YWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPVNoYXduLlN0ZWVsZUBtaWNyb3NvZnQuY29t IA0KICBocmVmPSJtYWlsdG86U2hhd24uU3RlZWxlQG1pY3Jvc29mdC5jb20iPlNoYXduIFN0ZWVs ZTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwvQj4g PEEgdGl0bGU9aW1hQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86aW1hQGlldGYub3JnIj5pbWFA aWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5T ZW50OjwvQj4gVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMzoyNyBBTTwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0OjwvQj4gW0VBSV0gUmFuZG9tIHRob3Vn aHQgIzEgLSBVVEY4U01UUCANCiAgaGFuZHNoYWtpbmc8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+ DQogIDxESVYgY2xhc3M9V29yZFNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+SSBkb27i gJl0IHdhbnQgdG8gZGVyYWlsIG91ciB0aW1lIGZyYW1lLCBidXQgSSB3YXMgd29uZGVyaW5nIA0K ICBpZiB0aGlzIHdhcyB3b3J0aCBjb25zaWRlcmluZzo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ Q3VycmVudGx5IHRoZSBVVEY4U01UUChiaXMpIGV4dGVuc2lvbiBpcyBhIG9uZS13YXkgDQogIGhh bmRzaGFraW5nLiZuYnNwOyBFZzogdGhlIGNsaWVudCBrbm93cyB0aGUgc2VydmVyIHVuZGVyc3Rh bmRzIFVURjhTTVRQLCANCiAgaG93ZXZlciB0aGVyZeKAmXMgbm8gd2F5IGZvciB0aGUgc2VydmVy IHRvIGdlbmVyYWxseSBrbm93IGlmIHRoZSBjbGllbnQgY2FuIA0KICBhY2NlcHQgVVRGLTguJm5i c3A7IFRoYXQgbGVhZHMgdXMgdG8gdGhpbmdzIGxpa2Ug4oCcVVRGOFJFUExZ4oCdLiZuYnNwOyAN CiAgQWRkaXRpb25hbGx5LCBpdCBpcyBub3QgbmVjZXNzYXJpbHkgZ3VhcmFudGVlZCB0aGF0IGEg TUFJTCBvciBSQ1BUIGNvbW1hbmQgaXMgDQogIFVURi04IGp1c3QgYmVjYXVzZSBpdOKAmXMgbm9u IEFTQ0lJIChhIG1pc2JlaGF2aW5nIGNsaWVudCBjb3VsZCBiZSB1c2luZyB0aGVpciANCiAgbG9j YWwgOC1iaXQgY29kZSBwYWdlIG9yIHNvbWV0aGluZykuJm5ic3A7IEl04oCZcyBhbHNvIG5vdCBn dWFyYW50ZWVkIHRoYXQgREFUQSANCiAgYmUgVVRGLTggKEkgdGhpbmsgaGlzdG9yaWNhbGx5IGRh dGEgaGFzIHNvbWV0aW1lcyB1c2VkIGxvY2FsIGNvZGUgcGFnZXMsIA0KICB0aG91Z2ggbm93IGl0 4oCZcyBwcm9iYWJseSBtb3JlIGxpa2VseSB0byBiZSBjb3JyZWN0bHkgdGFnZ2VkKS48bzpwPjwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+VG8gbWUsIHN0YW1waW5nIOKAnFVURjh4eHh44oCdIG9uIGV2ZXJ5 IGNvbW1hbmQgc2VlbXMgcHJldHR5IA0KICBhd2t3YXJkLiZuYnNwOyBTaG91bGQgd2UgY29uc2lk ZXIgYSDigJxVVEY44oCdIGNvbW1hbmQgdGhhdCBhIGNsaWVudCBjYW4gdXNlIHRvIA0KICBjb25m aXJtIHRoYXQgaXQgaGFuZGxlcyBVVEYtOD8mbmJzcDsgVGhlbiB0aGUgaGFuZHNoYWtpbmcgZG9l c27igJl0IGhhdmUgdG8gDQogIGhhcHBlbiB3aXRoIGV2ZXJ5IGNvbW1hbmQ/Jm5ic3A7IEVnOjxv OnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD5VVEY4PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD4yNTAgT2s8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPk1BSUwg RlJPTTombHQ7dXRmOEBpZG4udGxkJmd0OzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+MjUwIE9rPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD7igKY8bzpw PjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkRBVEE8bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPuKApiB1dGY4IGRhdGEg4oCmPG86cD48L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD4uPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkFzIG1lbnRpb25lZCwg SSBkb27igJl0IHdhbnQgdG8gY2F1c2UgYSBsb3Qgb2YgZGVsYXkgDQogIGRpc2N1c3NpbmcgdGhp cywgYnV0IGlzIGl0IHdvcnRoIGNvbnNpZGVyaW5nPyZuYnNwOyBXb3VsZCBpdCBiZSB0b28gbXVj aCANCiAgY2h1cm4/PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPi1TaGF3bjxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvZGUyMDAwIj7vo6Lvo5Dvo6fv o5sgDQogIO+jou+jo++jl++jlO+jmTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxBIA0KICBocmVmPSJodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUiPmh0 dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZTwvQT48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPjwvRElWPg0KICA8UD4NCiAgPEhSPg0K DQogIDxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxCUj5JTUEgbWFpbGluZyANCiAgbGlzdDxCUj5JTUFAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE8QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_023F_01CB1E94.B4A42340-- From Shawn.Steele@microsoft.com Thu Jul 8 00:28:18 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574563A6873 for ; Thu, 8 Jul 2010 00:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.692 X-Spam-Level: X-Spam-Status: No, score=-9.692 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORFpgdVBjo7i for ; Thu, 8 Jul 2010 00:28:17 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6C7883A67EF for ; Thu, 8 Jul 2010 00:28:17 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 00:28:22 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 00:28:22 -0700 From: Shawn Steele To: Jiankang YAO , "ima@ietf.org" Thread-Topic: [EAI] Random thought #1 - UTF8SMTP handshaking Thread-Index: AQHLHlGmbDXoz4hGT/WWB0TrTt0mlpKmntYa Date: Thu, 8 Jul 2010 07:28:20 +0000 Message-ID: References: <478530872.30112@cnnic.cn>, <58197F284E09484286672B4C106C49AC@LENOVO47E041CF> In-Reply-To: <58197F284E09484286672B4C106C49AC@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A0DA50854TK5EX14MBXC141r_" MIME-Version: 1.0 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 07:28:18 -0000 --_000_E14011F8737B524BB564B05FF748464A0DA50854TK5EX14MBXC141r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > if the client can use mail from or rcpt to with the utf8@utf8, > it means that the client can support utf8. Clearly, but how do we know it's utf8@utf8? It "might" b= e iso8859-x@iso8859-x. (Yea, I get that it sho= uldn't be, but if we don't tell the server, how do we know for sure? That = client could be using the ISO8859SMTP extension) UTF8SMTP says "the server= know (& will probably obey) the EAI rules. How do we know what the client= 's going to do? Just because we see data with the high bit set doesn't mea= n its UTF-8 aware. It's probably more interesting for DATA, where "simple" connections are mor= e likely to accidentally (or intentionally) end up in a non-UTF-8 code page= . Eg: if I open a windows cmd window and telnet to a SMTP server and type non= -ASCII data after "DATA", what happens? I'll be sending whatever the machi= nes current ACP is. While that isn't strictly legal, it probably "works" i= n some environments. -Shawn --_000_E14011F8737B524BB564B05FF748464A0DA50854TK5EX14MBXC141r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> if the client can use mail from or rcpt to  with the utf8@utf8,
> it means that the= client can support utf8.
 
Clearly, but how do we know it's utf8@utf= 8?  It "might" be iso8859-x@iso8859-x.  (Yea,= I get that it shouldn't be, but if we don't tell the server, how do we kno= w for sure?  That client could be using the ISO8859SMTP extension)&nbs= p; UTF8SMTP says "the server know (& will probably obey) the EAI rules.  How do we know what the client's going to do?&n= bsp; Just because we see data with the high bit set doesn't mean its UTF-8 = aware.
 
It's probably more interesting for DATA, where "simple" conn= ections are more likely to accidentally (or intentionally) end up in a non-= UTF-8 code page.
 
Eg: if I open a windows cmd window and telnet to a SMTP server and typ= e non-ASCII data after "DATA", what happens?  I'll be sendin= g whatever the machines current ACP is.  While that isn't strictly leg= al, it probably "works" in some environments.
 
-Shawn
--_000_E14011F8737B524BB564B05FF748464A0DA50854TK5EX14MBXC141r_-- From klensin@jck.com Thu Jul 8 09:18:34 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A60F3A6812 for ; Thu, 8 Jul 2010 09:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnzscnI2V8pz for ; Thu, 8 Jul 2010 09:18:33 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 822C13A6A08 for ; Thu, 8 Jul 2010 09:18:32 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OWto2-000H3M-2o; Thu, 08 Jul 2010 12:18:34 -0400 Date: Thu, 08 Jul 2010 12:18:33 -0400 From: John C Klensin To: Shawn Steele , Jiankang YAO , ima@ietf.org Message-ID: In-Reply-To: References: <478530872.30112@cnnic.cn> , <58197F284E09484286672B4C106C49AC@LENOVO47E041CF> 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 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:18:34 -0000 --On Thursday, July 08, 2010 07:28 +0000 Shawn Steele wrote: >> if the client can use mail from or rcpt to with the >> utf8@utf8, it means that the client can >> support utf8. > > Clearly, but how do we know it's utf8@utf8? > It "might" be iso8859-x@iso8859-x. > (Yea, I get that it shouldn't be, but if we don't tell the > server, how do we know for sure? That client could be using > the ISO8859SMTP extension) UTF8SMTP says "the server know (& > will probably obey) the EAI rules. How do we know what the > client's going to do? Just because we see data with the high > bit set doesn't mean its UTF-8 aware. There is no ISO8859SMTP extension. If someone wanted to make one up, they would be obligated to resolve the problem you are concerned about. Without EAI, nothing prevents a client from sending ISO 8859-x or, for that matter EBCDIC, to an unsuspecting server. The server will either notice that the high bit is set and reject the message, or it will invoke its "treat as nonsense" procedure, or it will get into a greater or lesser amount of trouble depending on what is in the material being sent. With EAI, we get a statement from the server that, if non-ASCII is being sent, UTF-8 is expected and, implicitly, that anything else may be treated with hostility. Whatever your "announce that UTF-8 is being used" command might accomplish, solving this problem isn't on the list because a client could omit that command and send UTF-8 (or ISO-8859-x or EBCDIC) anyway. In each case, the server has to be careful enough to avoid being damaged (however that is defined). And, in each case, it would be fairly stupid for the server to accept/ encourage anything but UTF-8. I mention EBCDIC above partially to point out that the potential problem has been with us since the dawn of the Internet, rather than this being a new, i18n-specific, problem. The conclusion 35-odd years ago was "one form on the wire and anyone who tries anything else deserves whatever happens to them". No change with this: we specify UTF-8, we make no provisions for anything other than UTF-8, and anyone who decides to send something else is probably not going to interoperate. We could, if you think it useful, add text to "Framework" (4952bis) to explain this, but, if you want that, say so soon and please send text. In a way, this is a corollary to the message of draft-iab-i18n-encoding: we are much better off with a single on-the-wire encoding than with a multiple-choice situation. If someone wants to use ISO 8859-666 internally to an operating system that is fine... and really no different from using UTF-16 internally. A well-defined conversion model is needed to get the internal form to and from Unicode in UTF-8. But the Unicode folks claim that is a solved problem for all known and widely-used CCSs. If they are wrong and it isn't, it is their problem, not one that we should make worse by creating alternatives. > It's probably more interesting for DATA, where "simple" > connections are more likely to accidentally (or intentionally) > end up in a non-UTF-8 code page. > > Eg: if I open a windows cmd window and telnet to a SMTP server > and type non-ASCII data after "DATA", what happens? I'll be > sending whatever the machines current ACP is. While that > isn't strictly legal, it probably "works" in some environments. It is not only "not strictly legal", it is a serious violation of the spec to send anything other than ASCII text without MIME structure and a Content-type that specifies the relevant "charset". Whether it will "work" or not depends on what the server does to protect itself. Note first that, if 8BITMIME is not specified, the server may reasonably reject anything (envelope, headers, message body) that contains octets with the high bit on. Even if it doesn't, it may reasonably reject anything whose headers do not contain a Content-type header field (and MIME-Version, etc.). Will things "work" if both client and server are 8-bit-clean, permissive, and use the same character coding internally (or have and apply good heuristics)? Yes. But that is one of the main things we've learned from many years of experience with email (and possibly applications protocols in general): if one enables bad practices in the name of more interoperability, what one mostly gets is more bad practices... and indignation by those who are using them that their non-conforming systems don't interoperate better with everything else. As a handy example, to this day, when we discover a case of MIME not working as intended, one of the main reasons usually turns out to be a long-ago decision by a particular vendor to favor the "suffix" of a file name over the content-type in interpreting the content of a message body. I'll leave the name of that particular vendor as an exercise. john From Shawn.Steele@microsoft.com Thu Jul 8 09:38:30 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44AB43A6A93 for ; Thu, 8 Jul 2010 09:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgnz3ubfq7q7 for ; Thu, 8 Jul 2010 09:38:23 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 72BFF3A6B36 for ; Thu, 8 Jul 2010 09:38:20 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 09:38:24 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 09:38:21 -0700 From: Shawn Steele To: John C Klensin , Jiankang YAO , "ima@ietf.org" Thread-Topic: [EAI] Random thought #1 - UTF8SMTP handshaking Thread-Index: AQHLHlGmbDXoz4hGT/WWB0TrTt0mlpKmntYagAEMSoD//4tTVw== Date: Thu, 8 Jul 2010 16:38:20 +0000 Message-ID: References: <478530872.30112@cnnic.cn> , <58197F284E09484286672B4C106C49AC@LENOVO47E041CF> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:38:30 -0000 > I mention EBCDIC above partially to point out that the potential > problem has been with us since the dawn of the Internet, rather > than this being a new, i18n-specific, problem.=20 I think that's my point. > 0x7f has worked in some environments in the pas= t. I'm not saying it was good or bad, or wise or stupid or whatever, but, = in some cases, I believe that there have been systems that blindly exchange= such data and rely on the fact that everyone in the org used the same ACP = to make it "work". I believe I first encountered this on a Unix box running sendmail in the ea= rly 90's. I *think* that modern clients/servers are stricter, so that, unlike html, t= here is less of that strangeness going on now. > There is no ISO8859SMTP extension. If someone wanted to make > one up, they would be obligated to resolve the problem you are > concerned about. Can you guarantee there's no private XISO8859SMTP extension? > if one enables bad practices in the name of more interoperability, what > one mostly gets is more bad practices... I'm not suggesting this to "enable bad practices", I'm suggesting it to ens= ure good practices. Right now the draft has half-way handshaking. The ser= ver says "I'm EAI", and ASSUMES that the client may be EAI if it sends data= with the high bit set. Previously the server should've rejected that data= , but now it'll start allowing it because it's making that assumption, not = because it actually "knows" that the client supports EAI. To be very clear about what you're alluding, I've been told that Exchange i= s very strict about what it does and does not allow, so apparently this isn= 't something Exchange needs for compatibility. I've tested that myself wit= h the FROM: and RCPT:, which fail. I've also had requests from a Korean cu= stomer wanting to know how to get local code page email addresses to intero= perate outside of their intranet. Obviously they weren't using Exchange SM= TP, since we don't support that, even on the intranet. (I don't know what = they were using). In any event, I don't think it's interesting enough to make a huge deal out= of, however it did seem, to me, that we could have a chance to confirm tha= t the client was indeed intending EAI behavior, for all commands, without a= ssumptions and without needing a bunch of UTF8REPLY tokens. You've been ar= ound mail longer than me :), so if you think the assumption is good enough = for interoperability with the huge variety of clients out there, then you'r= e likely correct. Why is it evil for the server to know what the client supports? -Shawn = From klensin@jck.com Thu Jul 8 10:55:17 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA213A6888 for ; Thu, 8 Jul 2010 10:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNN8mk0h9Nq8 for ; Thu, 8 Jul 2010 10:55:16 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id F05E23A688B for ; Thu, 8 Jul 2010 10:55:15 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OWvJc-000KE5-HN; Thu, 08 Jul 2010 13:55:17 -0400 Date: Thu, 08 Jul 2010 13:55:15 -0400 From: John C Klensin To: Shawn Steele , Jiankang YAO , ima@ietf.org Message-ID: 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 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:55:18 -0000 --On Thursday, July 08, 2010 16:38 +0000 Shawn Steele wrote: >... >> There is no ISO8859SMTP extension. If someone wanted to make >> one up, they would be obligated to resolve the problem you are >> concerned about. > > Can you guarantee there's no private XISO8859SMTP extension? Of course not. I can't even guarantee that there is no private BAUDOT or packed ASCII extension, nor an extension that specifies that Content-types are to be interpreted according to rules different from those in the IANA registry, nor an extension that specifies that all DNS name components of email addresses are to be interpreted with the root to the left. The right model for dealing with _any_ private extension is that it is up to those who are using it to sort out interoperability with whatever is standardized. One might reasonably discuss an exception if an extension were demonstrated to be widely deployed and important, but I haven't seen anyone come forward and say "we have an ISO8859SMTP extension, it has been shipping in products for a decade, and nine million people are depending on it", only your wild speculations about some extension that might exist out there somewhere. Even if such an extension did exist, the "one encoding on the wire" argument would constitute a significant tradeoff factor against dealing with it, but we'd at least have a basis for a meaningful discussion. What I can guarantee is that trying to design an extension to be bulletproof against any bad idea that someone might have devised privately would lead to madness as well as to huge delays as we try to sort through all of the alternatives, attacks, and real or imaginary edge cases. And I can suggest that adopting the "someone might have done this, therefore we have to support it forever" mentality is a large part of what got HTML --and the URI and IRI specs-- into trouble. >> if one enables bad practices in the name of more >> interoperability, what one mostly gets is more bad >> practices... > > I'm not suggesting this to "enable bad practices", I'm > suggesting it to ensure good practices. Right now the draft > has half-way handshaking. The server says "I'm EAI", and > ASSUMES that the client may be EAI if it sends data with the > high bit set. Previously the server should've rejected that > data, but now it'll start allowing it because it's making that > assumption, not because it actually "knows" that the client > supports EAI. See procedural note at end. > To be very clear about what you're alluding, I've been told > that Exchange is very strict about what it does and does not > allow, so apparently this isn't something Exchange needs for > compatibility. I've tested that myself with the FROM: and > RCPT:, which fail. I've also had requests from a Korean > customer wanting to know how to get local code page email > addresses to interoperate outside of their intranet. I'd suggest that the correct answer is "things leak, you really want to convert to and be using UTF-8 addresses even in the intranet, and you should not be trying this". Think about the design of an MUA that picks up an address from where it is embedded in a text file. If the standard is "UTF-8 and UTF-8 only on the Internet" then the conversion is clear. If it is "well, you can use UTF-8, or your local code page, or maybe 2022=based table switching", then you have gotten into the worst parts of the "alternate address" theme because you don't know which one to try, which order to try them in, etc. And, worse, with multiple alternatives, the odds of getting things configured correctly so that a submission server could assume that all relays in the chain would support the same options would go down considerably. > Obviously they weren't using Exchange SMTP, since we don't > support that, even on the intranet. (I don't know what they > were using). > In any event, I don't think it's interesting enough to make a > huge deal out of, however it did seem, to me, that we could > have a chance to confirm that the client was indeed intending > EAI behavior, for all commands, without assumptions and > without needing a bunch of UTF8REPLY tokens. You've been > around mail longer than me :), so if you think the assumption > is good enough for interoperability with the huge variety of > clients out there, then you're likely correct. > > Why is it evil for the server to know what the client supports? It isn't. And, if the above is your main point, then let's not waste time and get distracted by arguments about, e.g., private ISO8859SMTP extensions or non-conforming DATA content. I've got two sets of reasons to be hesitant about your proposed command, one about protocol design (and, if you will, religion) and the other about procedures. _Religion_: I'm extremely reluctant to see another state introduced into SMTP. It isn't that we couldn't, but it would be hard to get right, it would turn developing the text for 5336bis into a task that would require deep understanding of 5321 and the design decisions that have accumulated since 821, it would require that we sort out the order in which commands could occur, and it would require that we spend a lot of time ensuring that such a new state didn't have bad interactions with extensions already developed and on the standards track. We'd have to analyze the implications of additional turnarounds, specify whether RSET cleared the "UTF8" state, and review pipelining and figure out whether we needed to update it. None of that is insurmountable, but it wouldn't be quick and I don't think the case has been made yet that it would be worth the trouble. _Procedures_: If we are going to introduce this sort of facility and remain consistent with the WG's roots, we should specify this facility, publish an Experimental spec, develop implementations, and test them against each other and the installed base to be sure that there are no ill effects. Perhaps we could bypass those steps, but it would be risky. My experience with the IETF suggests that even doing the level of examination needed to ensure consistency with 5321 and the Pipelining extension if a new state were added would stretch things out by at least six months and that going through the Experimental spec and testing arrangements would stretch that out to 12 - 18 months. If I adjust for the level of activity in this WG (count the number of comments about anything but editorial issues in 4952bis since it was posted), you can probably double those numbers. There is also the small issue of deployment speed: as with 8BITMIME, the current model requires that a server advertise the extension (a few lines of code) and disable some tests. Implementing a new command, advertising its availability, and maintaining extra state information turns implementation of email i18n back into a big deal. To the extent to which we are depending on rapid deployment (at least within language communities) as part of our defense against needing much more complex transition models, making implementation unnecessarily harder is not in our interest. If there were compelling need here, I'd think that was worthwhile. But, so far, all we've heard about are theoretical cases what would constitute encouraging bad ideas (e.g., anything on the wire other than UTF-8) if were real and we recognized them. I note, although you find it distasteful (and, actually, I do too), that requiring "UTF8 stuff here" parameters on the MAIL, RCPT, and DATA commands is much less problematic than introducing a "UTF-8" command, precisely because it doesn't introduce new state. Of course, it means we would have to look at extensions such as BDAT too, but... john From Shawn.Steele@microsoft.com Thu Jul 8 11:00:52 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21433A6857 for ; Thu, 8 Jul 2010 11:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy0XyqUu4ejx for ; Thu, 8 Jul 2010 11:00:50 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 72D893A6B39 for ; Thu, 8 Jul 2010 11:00:50 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 11:00:54 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 11:00:53 -0700 From: Shawn Steele To: John C Klensin , Jiankang YAO , "ima@ietf.org" Thread-Topic: [EAI] Random thought #1 - UTF8SMTP handshaking Thread-Index: AQHLHsa4bDXoz4hGT/WWB0TrTt0mlpKnUREg Date: Thu, 8 Jul 2010 18:00:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:00:52 -0000 Rm9yIHRoZSByZWNvcmQsIEkgY2FuIGxpdmUgd2l0aCB0aGUgZHJhZnQgd2l0aCB0aGUgd2F5IGl0 IGlzLCBpdCBzb3VuZHMgbGlrZSB0b28gbXVjaCB3b3JrIHRvIGRvIGFueXRoaW5nIGVsc2UuICBJ J20gc3RpbGwgY29uY2VybmVkIHRoYXQgd2UgZWZmZWN0aXZlbHkgaGF2ZSBwYXJ0aWFsIGhhbmRz aGFraW5nLCBidXQgSSBkb24ndCBzZWUgYW55IHJlYXNvbiB3aHkgaXQgY2FuJ3Qgd29yayBhcyBk cmFmdGVkLg0KDQotU2hhd24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Sm9obiBDIEtsZW5zaW4gW21haWx0bzprbGVuc2luQGpjay5jb21dIA0KU2VudDogVGh1cnNkYXks IEp1bHkgMDgsIDIwMTAgMTA6NTUgQU0NClRvOiBTaGF3biBTdGVlbGU7IEppYW5rYW5nIFlBTzsg aW1hQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0VBSV0gUmFuZG9tIHRob3VnaHQgIzEgLSBVVEY4 U01UUCBoYW5kc2hha2luZw0KDQoNCg0KLS1PbiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAxNjoz OCArMDAwMCBTaGF3biBTdGVlbGUgPFNoYXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPiB3cm90ZToN Cg0KPi4uLg0KPj4gVGhlcmUgaXMgbm8gSVNPODg1OVNNVFAgZXh0ZW5zaW9uLiAgSWYgc29tZW9u ZSB3YW50ZWQgdG8gbWFrZSBvbmUgdXAsIA0KPj4gdGhleSB3b3VsZCBiZSBvYmxpZ2F0ZWQgdG8g cmVzb2x2ZSB0aGUgcHJvYmxlbSB5b3UgYXJlIGNvbmNlcm5lZCANCj4+IGFib3V0Lg0KPiANCj4g Q2FuIHlvdSBndWFyYW50ZWUgdGhlcmUncyBubyBwcml2YXRlIFhJU084ODU5U01UUCBleHRlbnNp b24/DQoNCk9mIGNvdXJzZSBub3QuICBJIGNhbid0IGV2ZW4gZ3VhcmFudGVlIHRoYXQgdGhlcmUg aXMgbm8gcHJpdmF0ZSBCQVVET1Qgb3IgcGFja2VkIEFTQ0lJIGV4dGVuc2lvbiwgbm9yIGFuIGV4 dGVuc2lvbiB0aGF0IHNwZWNpZmllcyB0aGF0IENvbnRlbnQtdHlwZXMgYXJlIHRvIGJlIGludGVy cHJldGVkIGFjY29yZGluZyB0byBydWxlcyBkaWZmZXJlbnQgZnJvbSB0aG9zZSBpbiB0aGUgSUFO QSByZWdpc3RyeSwgbm9yIGFuIGV4dGVuc2lvbiB0aGF0IHNwZWNpZmllcyB0aGF0IGFsbCBETlMg bmFtZSBjb21wb25lbnRzIG9mIGVtYWlsIGFkZHJlc3NlcyBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg d2l0aCB0aGUgcm9vdCB0byB0aGUgbGVmdC4gIA0KDQpUaGUgcmlnaHQgbW9kZWwgZm9yIGRlYWxp bmcgd2l0aCBfYW55XyBwcml2YXRlIGV4dGVuc2lvbiBpcyB0aGF0IGl0IGlzIHVwIHRvIHRob3Nl IHdobyBhcmUgdXNpbmcgaXQgdG8gc29ydCBvdXQgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHdoYXRl dmVyIGlzIHN0YW5kYXJkaXplZC4gIE9uZSBtaWdodCByZWFzb25hYmx5IGRpc2N1c3MgYW4gZXhj ZXB0aW9uIGlmIGFuIGV4dGVuc2lvbiB3ZXJlIGRlbW9uc3RyYXRlZCB0byBiZSB3aWRlbHkgZGVw bG95ZWQgYW5kIGltcG9ydGFudCwgYnV0IEkgaGF2ZW4ndCBzZWVuIGFueW9uZSBjb21lIGZvcndh cmQgYW5kIHNheSAid2UgaGF2ZSBhbiBJU084ODU5U01UUCBleHRlbnNpb24sIGl0IGhhcyBiZWVu IHNoaXBwaW5nIGluIHByb2R1Y3RzIGZvciBhIGRlY2FkZSwgYW5kIG5pbmUgbWlsbGlvbiBwZW9w bGUgYXJlIGRlcGVuZGluZyBvbiBpdCIsIG9ubHkgeW91ciB3aWxkIHNwZWN1bGF0aW9ucyBhYm91 dCBzb21lIGV4dGVuc2lvbiB0aGF0IG1pZ2h0IGV4aXN0IG91dCB0aGVyZSBzb21ld2hlcmUuICBF dmVuIGlmIHN1Y2ggYW4gZXh0ZW5zaW9uIGRpZCBleGlzdCwgdGhlICJvbmUgZW5jb2Rpbmcgb24g dGhlIHdpcmUiIGFyZ3VtZW50IHdvdWxkIGNvbnN0aXR1dGUgYSBzaWduaWZpY2FudCB0cmFkZW9m ZiBmYWN0b3IgYWdhaW5zdCBkZWFsaW5nIHdpdGggaXQsIGJ1dCB3ZSdkIGF0IGxlYXN0IGhhdmUg YSBiYXNpcyBmb3IgYSBtZWFuaW5nZnVsIGRpc2N1c3Npb24uDQoNCldoYXQgSSBjYW4gZ3VhcmFu dGVlIGlzIHRoYXQgdHJ5aW5nIHRvIGRlc2lnbiBhbiBleHRlbnNpb24gdG8gYmUgYnVsbGV0cHJv b2YgYWdhaW5zdCBhbnkgYmFkIGlkZWEgdGhhdCBzb21lb25lIG1pZ2h0IGhhdmUgZGV2aXNlZCBw cml2YXRlbHkgd291bGQgbGVhZCB0byBtYWRuZXNzIGFzIHdlbGwgYXMgdG8gaHVnZSBkZWxheXMg YXMgd2UgdHJ5IHRvIHNvcnQgdGhyb3VnaCBhbGwgb2YgdGhlIGFsdGVybmF0aXZlcywgYXR0YWNr cywgYW5kIHJlYWwNCm9yIGltYWdpbmFyeSBlZGdlIGNhc2VzLiAgIEFuZCBJIGNhbiBzdWdnZXN0 IHRoYXQgYWRvcHRpbmcgdGhlDQoic29tZW9uZSBtaWdodCBoYXZlIGRvbmUgdGhpcywgdGhlcmVm b3JlIHdlIGhhdmUgdG8gc3VwcG9ydCBpdCBmb3JldmVyIiBtZW50YWxpdHkgaXMgYSBsYXJnZSBw YXJ0IG9mIHdoYXQgZ290IEhUTUwgLS1hbmQgdGhlIFVSSSBhbmQgSVJJIHNwZWNzLS0gaW50byB0 cm91YmxlLg0KDQo+PiBpZiBvbmUgZW5hYmxlcyBiYWQgcHJhY3RpY2VzIGluIHRoZSBuYW1lIG9m IG1vcmUgaW50ZXJvcGVyYWJpbGl0eSwgDQo+PiB3aGF0IG9uZSBtb3N0bHkgZ2V0cyBpcyBtb3Jl IGJhZCBwcmFjdGljZXMuLi4NCj4gDQo+IEknbSBub3Qgc3VnZ2VzdGluZyB0aGlzIHRvICJlbmFi bGUgYmFkIHByYWN0aWNlcyIsIEknbSBzdWdnZXN0aW5nIGl0IA0KPiB0byBlbnN1cmUgZ29vZCBw cmFjdGljZXMuICBSaWdodCBub3cgdGhlIGRyYWZ0IGhhcyBoYWxmLXdheSANCj4gaGFuZHNoYWtp bmcuICBUaGUgc2VydmVyIHNheXMgIkknbSBFQUkiLCBhbmQgQVNTVU1FUyB0aGF0IHRoZSBjbGll bnQgDQo+IG1heSBiZSBFQUkgaWYgaXQgc2VuZHMgZGF0YSB3aXRoIHRoZSBoaWdoIGJpdCBzZXQu ICBQcmV2aW91c2x5IHRoZSANCj4gc2VydmVyIHNob3VsZCd2ZSByZWplY3RlZCB0aGF0IGRhdGEs IGJ1dCBub3cgaXQnbGwgc3RhcnQgYWxsb3dpbmcgaXQgDQo+IGJlY2F1c2UgaXQncyBtYWtpbmcg dGhhdCBhc3N1bXB0aW9uLCBub3QgYmVjYXVzZSBpdCBhY3R1YWxseSAia25vd3MiIA0KPiB0aGF0 IHRoZSBjbGllbnQgc3VwcG9ydHMgRUFJLg0KDQpTZWUgcHJvY2VkdXJhbCBub3RlIGF0IGVuZC4N Cg0KPiBUbyBiZSB2ZXJ5IGNsZWFyIGFib3V0IHdoYXQgeW91J3JlIGFsbHVkaW5nLCBJJ3ZlIGJl ZW4gdG9sZCB0aGF0IA0KPiBFeGNoYW5nZSBpcyB2ZXJ5IHN0cmljdCBhYm91dCB3aGF0IGl0IGRv ZXMgYW5kIGRvZXMgbm90IGFsbG93LCBzbyANCj4gYXBwYXJlbnRseSB0aGlzIGlzbid0IHNvbWV0 aGluZyBFeGNoYW5nZSBuZWVkcyBmb3IgY29tcGF0aWJpbGl0eS4gIA0KPiBJJ3ZlIHRlc3RlZCB0 aGF0IG15c2VsZiB3aXRoIHRoZSBGUk9NOiBhbmQgUkNQVDosIHdoaWNoIGZhaWwuICBJJ3ZlIA0K PiBhbHNvIGhhZCByZXF1ZXN0cyBmcm9tIGEgS29yZWFuIGN1c3RvbWVyIHdhbnRpbmcgdG8ga25v dyBob3cgdG8gZ2V0IA0KPiBsb2NhbCBjb2RlIHBhZ2UgZW1haWwgYWRkcmVzc2VzIHRvIGludGVy b3BlcmF0ZSBvdXRzaWRlIG9mIHRoZWlyIA0KPiBpbnRyYW5ldC4NCg0KSSdkIHN1Z2dlc3QgdGhh dCB0aGUgY29ycmVjdCBhbnN3ZXIgaXMgInRoaW5ncyBsZWFrLCB5b3UgcmVhbGx5IHdhbnQgdG8g Y29udmVydCB0byBhbmQgYmUgdXNpbmcgVVRGLTggYWRkcmVzc2VzIGV2ZW4gaW4gdGhlIGludHJh bmV0LCBhbmQgeW91IHNob3VsZCBub3QgYmUgdHJ5aW5nIHRoaXMiLiAgVGhpbmsgYWJvdXQgdGhl IGRlc2lnbiBvZiBhbiBNVUEgdGhhdCBwaWNrcyB1cCBhbiBhZGRyZXNzIGZyb20gd2hlcmUgaXQg aXMgZW1iZWRkZWQgaW4gYSB0ZXh0IGZpbGUuICBJZiB0aGUgc3RhbmRhcmQgaXMgIlVURi04IGFu ZCBVVEYtOCBvbmx5IG9uIHRoZSBJbnRlcm5ldCIgdGhlbiB0aGUgY29udmVyc2lvbiBpcyBjbGVh ci4gIElmIGl0IGlzICJ3ZWxsLCB5b3UgY2FuIHVzZSBVVEYtOCwgb3IgeW91ciBsb2NhbCBjb2Rl IHBhZ2UsIG9yIG1heWJlIDIwMjI9YmFzZWQgdGFibGUgc3dpdGNoaW5nIiwgdGhlbiB5b3UgaGF2 ZSBnb3R0ZW4gaW50byB0aGUgd29yc3QgcGFydHMgb2YgdGhlICJhbHRlcm5hdGUgYWRkcmVzcyIg dGhlbWUgYmVjYXVzZSB5b3UgZG9uJ3Qga25vdyB3aGljaCBvbmUgdG8gdHJ5LCB3aGljaCBvcmRl ciB0byB0cnkgdGhlbSBpbiwgZXRjLiAgQW5kLCB3b3JzZSwgd2l0aCBtdWx0aXBsZSBhbHRlcm5h dGl2ZXMsIHRoZSBvZGRzIG9mIGdldHRpbmcgdGhpbmdzIGNvbmZpZ3VyZWQgY29ycmVjdGx5IHNv IHRoYXQgYSBzdWJtaXNzaW9uIHNlcnZlciBjb3VsZCBhc3N1bWUgdGhhdCBhbGwgcmVsYXlzIGlu IHRoZSBjaGFpbiB3b3VsZCBzdXBwb3J0IHRoZSBzYW1lIG9wdGlvbnMgd291bGQgZ28gZG93biBj b25zaWRlcmFibHkuDQoNCj4gT2J2aW91c2x5IHRoZXkgd2VyZW4ndCB1c2luZyBFeGNoYW5nZSBT TVRQLCBzaW5jZSB3ZSBkb24ndCBzdXBwb3J0IA0KPiB0aGF0LCBldmVuIG9uIHRoZSBpbnRyYW5l dC4gIChJIGRvbid0IGtub3cgd2hhdCB0aGV5IHdlcmUgdXNpbmcpLg0KIA0KPiBJbiBhbnkgZXZl bnQsIEkgZG9uJ3QgdGhpbmsgaXQncyBpbnRlcmVzdGluZyBlbm91Z2ggdG8gbWFrZSBhIGh1Z2Ug DQo+IGRlYWwgb3V0IG9mLCBob3dldmVyIGl0IGRpZCBzZWVtLCB0byBtZSwgdGhhdCB3ZSBjb3Vs ZCBoYXZlIGEgY2hhbmNlIA0KPiB0byBjb25maXJtIHRoYXQgdGhlIGNsaWVudCB3YXMgaW5kZWVk IGludGVuZGluZyBFQUkgYmVoYXZpb3IsIGZvciBhbGwgDQo+IGNvbW1hbmRzLCB3aXRob3V0IGFz c3VtcHRpb25zIGFuZCB3aXRob3V0IG5lZWRpbmcgYSBidW5jaCBvZiBVVEY4UkVQTFkgDQo+IHRv a2Vucy4gIFlvdSd2ZSBiZWVuIGFyb3VuZCBtYWlsIGxvbmdlciB0aGFuIG1lIDopLCBzbyBpZiB5 b3UgdGhpbmsgDQo+IHRoZSBhc3N1bXB0aW9uIGlzIGdvb2QgZW5vdWdoIGZvciBpbnRlcm9wZXJh YmlsaXR5IHdpdGggdGhlIGh1Z2UgDQo+IHZhcmlldHkgb2YgY2xpZW50cyBvdXQgdGhlcmUsIHRo ZW4geW91J3JlIGxpa2VseSBjb3JyZWN0Lg0KPiANCj4gV2h5IGlzIGl0IGV2aWwgZm9yIHRoZSBz ZXJ2ZXIgdG8ga25vdyB3aGF0IHRoZSBjbGllbnQgc3VwcG9ydHM/DQoNCkl0IGlzbid0LiAgQW5k LCBpZiB0aGUgYWJvdmUgaXMgeW91ciBtYWluIHBvaW50LCB0aGVuIGxldCdzIG5vdCB3YXN0ZSB0 aW1lIGFuZCBnZXQgZGlzdHJhY3RlZCBieSBhcmd1bWVudHMgYWJvdXQsIGUuZy4sIHByaXZhdGUg SVNPODg1OVNNVFAgZXh0ZW5zaW9ucyBvciBub24tY29uZm9ybWluZyBEQVRBIGNvbnRlbnQuDQoN CkkndmUgZ290IHR3byBzZXRzIG9mIHJlYXNvbnMgdG8gYmUgaGVzaXRhbnQgYWJvdXQgeW91ciBw cm9wb3NlZCBjb21tYW5kLCBvbmUgYWJvdXQgcHJvdG9jb2wgZGVzaWduIChhbmQsIGlmIHlvdSB3 aWxsLCByZWxpZ2lvbikgYW5kIHRoZSBvdGhlciBhYm91dCBwcm9jZWR1cmVzLg0KDQpfUmVsaWdp b25fOiAgSSdtIGV4dHJlbWVseSByZWx1Y3RhbnQgdG8gc2VlIGFub3RoZXIgc3RhdGUgaW50cm9k dWNlZCBpbnRvIFNNVFAuICBJdCBpc24ndCB0aGF0IHdlIGNvdWxkbid0LCBidXQgaXQgd291bGQg YmUgaGFyZCB0byBnZXQgcmlnaHQsIGl0IHdvdWxkIHR1cm4gZGV2ZWxvcGluZyB0aGUgdGV4dCBm b3IgNTMzNmJpcyBpbnRvIGEgdGFzayB0aGF0IHdvdWxkIHJlcXVpcmUgZGVlcCB1bmRlcnN0YW5k aW5nIG9mDQo1MzIxIGFuZCB0aGUgZGVzaWduIGRlY2lzaW9ucyB0aGF0IGhhdmUgYWNjdW11bGF0 ZWQgc2luY2UgODIxLCBpdCB3b3VsZCByZXF1aXJlIHRoYXQgd2Ugc29ydCBvdXQgdGhlIG9yZGVy IGluIHdoaWNoIGNvbW1hbmRzIGNvdWxkIG9jY3VyLCBhbmQgaXQgd291bGQgcmVxdWlyZSB0aGF0 IHdlIHNwZW5kIGEgbG90IG9mIHRpbWUgZW5zdXJpbmcgdGhhdCBzdWNoIGEgbmV3IHN0YXRlIGRp ZG4ndCBoYXZlIGJhZCBpbnRlcmFjdGlvbnMgd2l0aA0KZXh0ZW5zaW9ucyBhbHJlYWR5IGRldmVs b3BlZCBhbmQgb24gdGhlIHN0YW5kYXJkcyB0cmFjay4gICBXZSdkDQpoYXZlIHRvIGFuYWx5emUg dGhlIGltcGxpY2F0aW9ucyBvZiBhZGRpdGlvbmFsIHR1cm5hcm91bmRzLCBzcGVjaWZ5IHdoZXRo ZXIgUlNFVCBjbGVhcmVkIHRoZSAiVVRGOCIgc3RhdGUsIGFuZCByZXZpZXcNCnBpcGVsaW5pbmcg YW5kIGZpZ3VyZSBvdXQgd2hldGhlciB3ZSBuZWVkZWQgdG8gdXBkYXRlIGl0LiAgIE5vbmUNCm9m IHRoYXQgaXMgaW5zdXJtb3VudGFibGUsIGJ1dCBpdCB3b3VsZG4ndCBiZSBxdWljayBhbmQgSSBk b24ndCB0aGluayB0aGUgY2FzZSBoYXMgYmVlbiBtYWRlIHlldCB0aGF0IGl0IHdvdWxkIGJlIHdv cnRoIHRoZSB0cm91YmxlLg0KDQpfUHJvY2VkdXJlc186ICAgSWYgd2UgYXJlIGdvaW5nIHRvIGlu dHJvZHVjZSB0aGlzIHNvcnQgb2YNCmZhY2lsaXR5IGFuZCByZW1haW4gY29uc2lzdGVudCB3aXRo IHRoZSBXRydzIHJvb3RzLCB3ZSBzaG91bGQgc3BlY2lmeSB0aGlzIGZhY2lsaXR5LCBwdWJsaXNo IGFuIEV4cGVyaW1lbnRhbCBzcGVjLCBkZXZlbG9wIGltcGxlbWVudGF0aW9ucywgYW5kIHRlc3Qg dGhlbSBhZ2FpbnN0IGVhY2ggb3RoZXIgYW5kIHRoZSBpbnN0YWxsZWQgYmFzZSB0byBiZSBzdXJl IHRoYXQgdGhlcmUgYXJlIG5vIGlsbCBlZmZlY3RzLg0KUGVyaGFwcyB3ZSBjb3VsZCBieXBhc3Mg dGhvc2Ugc3RlcHMsIGJ1dCBpdCB3b3VsZCBiZSByaXNreS4gIE15IGV4cGVyaWVuY2Ugd2l0aCB0 aGUgSUVURiBzdWdnZXN0cyB0aGF0IGV2ZW4gZG9pbmcgdGhlIGxldmVsIG9mIGV4YW1pbmF0aW9u IG5lZWRlZCB0byBlbnN1cmUgY29uc2lzdGVuY3kgd2l0aCA1MzIxIGFuZCB0aGUgUGlwZWxpbmlu ZyBleHRlbnNpb24gaWYgYSBuZXcgc3RhdGUgd2VyZSBhZGRlZCB3b3VsZCBzdHJldGNoIHRoaW5n cyBvdXQgYnkgYXQgbGVhc3Qgc2l4IG1vbnRocyBhbmQgdGhhdCBnb2luZyB0aHJvdWdoIHRoZSBF eHBlcmltZW50YWwgc3BlYyBhbmQgdGVzdGluZyBhcnJhbmdlbWVudHMgd291bGQgc3RyZXRjaCB0 aGF0IG91dCB0byAxMiAtIDE4IG1vbnRocy4gIElmIEkgYWRqdXN0IGZvciB0aGUgbGV2ZWwgb2Yg YWN0aXZpdHkgaW4gdGhpcyBXRyAoY291bnQgdGhlIG51bWJlciBvZiBjb21tZW50cyBhYm91dCBh bnl0aGluZyBidXQgZWRpdG9yaWFsIGlzc3VlcyBpbiA0OTUyYmlzIHNpbmNlIGl0IHdhcyBwb3N0 ZWQpLCB5b3UgY2FuIHByb2JhYmx5IGRvdWJsZSB0aG9zZSBudW1iZXJzLiANCg0KVGhlcmUgaXMg YWxzbyB0aGUgc21hbGwgaXNzdWUgb2YgZGVwbG95bWVudCBzcGVlZDogYXMgd2l0aCA4QklUTUlN RSwgdGhlIGN1cnJlbnQgbW9kZWwgcmVxdWlyZXMgdGhhdCBhIHNlcnZlciBhZHZlcnRpc2UgdGhl IGV4dGVuc2lvbiAoYSBmZXcgbGluZXMgb2YgY29kZSkgYW5kIGRpc2FibGUgc29tZSB0ZXN0cy4N CkltcGxlbWVudGluZyBhIG5ldyBjb21tYW5kLCBhZHZlcnRpc2luZyBpdHMgYXZhaWxhYmlsaXR5 LCBhbmQgbWFpbnRhaW5pbmcgZXh0cmEgc3RhdGUgaW5mb3JtYXRpb24gdHVybnMgaW1wbGVtZW50 YXRpb24gb2YgZW1haWwgaTE4biBiYWNrIGludG8gYSBiaWcgZGVhbC4gIFRvIHRoZSBleHRlbnQg dG8gd2hpY2ggd2UgYXJlIGRlcGVuZGluZyBvbiByYXBpZCBkZXBsb3ltZW50IChhdCBsZWFzdCB3 aXRoaW4gbGFuZ3VhZ2UNCmNvbW11bml0aWVzKSBhcyBwYXJ0IG9mIG91ciBkZWZlbnNlIGFnYWlu c3QgbmVlZGluZyBtdWNoIG1vcmUgY29tcGxleCB0cmFuc2l0aW9uIG1vZGVscywgbWFraW5nIGlt cGxlbWVudGF0aW9uIHVubmVjZXNzYXJpbHkgaGFyZGVyIGlzIG5vdCBpbiBvdXIgaW50ZXJlc3Qu DQoNCklmIHRoZXJlIHdlcmUgY29tcGVsbGluZyBuZWVkIGhlcmUsIEknZCB0aGluayB0aGF0IHdh cyB3b3J0aHdoaWxlLiAgQnV0LCBzbyBmYXIsIGFsbCB3ZSd2ZSBoZWFyZCBhYm91dCBhcmUgdGhl b3JldGljYWwgY2FzZXMgd2hhdCB3b3VsZCBjb25zdGl0dXRlIGVuY291cmFnaW5nIGJhZCBpZGVh cyAoZS5nLiwgYW55dGhpbmcgb24gdGhlIHdpcmUgb3RoZXIgdGhhbiBVVEYtOCkgaWYgd2VyZSBy ZWFsIGFuZCB3ZSByZWNvZ25pemVkIHRoZW0uDQoNCkkgbm90ZSwgYWx0aG91Z2ggeW91IGZpbmQg aXQgZGlzdGFzdGVmdWwgKGFuZCwgYWN0dWFsbHksIEkgZG8gdG9vKSwgdGhhdCByZXF1aXJpbmcg IlVURjggc3R1ZmYgaGVyZSIgcGFyYW1ldGVycyBvbiB0aGUgTUFJTCwgUkNQVCwgYW5kIERBVEEg Y29tbWFuZHMgaXMgbXVjaCBsZXNzIHByb2JsZW1hdGljIHRoYW4gaW50cm9kdWNpbmcgYSAiVVRG LTgiIGNvbW1hbmQsIHByZWNpc2VseSBiZWNhdXNlIGl0IGRvZXNuJ3QgaW50cm9kdWNlIG5ldyBz dGF0ZS4gIE9mIGNvdXJzZSwgaXQgbWVhbnMgd2Ugd291bGQgaGF2ZSB0byBsb29rIGF0IGV4dGVu c2lvbnMgc3VjaCBhcyBCREFUIHRvbywgYnV0Li4uDQoNCiAgICAgam9obg0KDQoNCg0K From klensin@jck.com Thu Jul 8 11:08:44 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1EF3A6847 for ; Thu, 8 Jul 2010 11:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-ZqeLlKi4tu for ; Thu, 8 Jul 2010 11:08:44 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EF93F3A67C0 for ; Thu, 8 Jul 2010 11:08:43 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OWvWf-000KXB-7M; Thu, 08 Jul 2010 14:08:45 -0400 Date: Thu, 08 Jul 2010 14:08:44 -0400 From: John C Klensin To: Shawn Steele , Jiankang YAO , ima@ietf.org Message-ID: <15E3D3082DCC3F1ABB7B57FD@PST.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 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:08:45 -0000 --On Thursday, July 08, 2010 18:00 +0000 Shawn Steele wrote: > For the record, I can live with the draft with the way it is, > it sounds like too much work to do anything else. I'm still > concerned that we effectively have partial handshaking, but I > don't see any reason why it can't work as drafted. Ack. For the record, we did do the analysis the first time around and concluded that client assertion about what it was doing wouldn't add enough to be worth the trouble. I'd be much more nervous if we hadn't. And my personal instinct would be to repeat the analysis and make sure we had covered all of the cases... but I don't see how to do that unless there is consensus that speed less important than making sure we get everything as bulletproof as possible. john From Shawn.Steele@microsoft.com Thu Jul 8 11:11:00 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B3A3A6B14 for ; Thu, 8 Jul 2010 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.325 X-Spam-Level: X-Spam-Status: No, score=-10.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTyb61AX-EAG for ; Thu, 8 Jul 2010 11:10:57 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id F07963A67C0 for ; Thu, 8 Jul 2010 11:10:55 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 11:10:57 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 11:10:57 -0700 From: Shawn Steele To: John C Klensin , Jiankang YAO , "ima@ietf.org" Thread-Topic: [EAI] Random thought #1 - UTF8SMTP handshaking Thread-Index: AQHLHsa4bDXoz4hGT/WWB0TrTt0mlpKnUREggAB37gD//4sA4A== Date: Thu, 8 Jul 2010 18:10:56 +0000 Message-ID: References: <15E3D3082DCC3F1ABB7B57FD@PST.JCK.COM> In-Reply-To: <15E3D3082DCC3F1ABB7B57FD@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:11:00 -0000 U29ycnkgSSBtaXNzZWQgdGhpcyBvbiB0aGUgZmlyc3QgZ28tYXJvdW5kIHRoZW4gOikgIChCVFc6 IEFyZSB0aGVyZSAiY29tcGxldGUiIGFyY2hpdmVzPyAgTm90IHRoYXQgSSBjYW4gZmluZCBhbnl0 aGluZyBhbnl3YXksIGJ1dCBpdCBsb29rcyBsaWtlIHRoZXkncmUgYXZhaWxhYmxlIGZvciBhIGNl cnRhaW4gd2luZG93PykNCg0KLVNoYXduDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKb2huIEMgS2xlbnNpbiBbbWFpbHRvOmtsZW5zaW5AamNrLmNvbV0gDQpTZW50OiBUaHVy c2RheSwgSnVseSAwOCwgMjAxMCAxMTowOSBBTQ0KVG86IFNoYXduIFN0ZWVsZTsgSmlhbmthbmcg WUFPOyBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbRUFJXSBSYW5kb20gdGhvdWdodCAjMSAt IFVURjhTTVRQIGhhbmRzaGFraW5nDQoNCg0KDQotLU9uIFRodXJzZGF5LCBKdWx5IDA4LCAyMDEw IDE4OjAwICswMDAwIFNoYXduIFN0ZWVsZSA8U2hhd24uU3RlZWxlQG1pY3Jvc29mdC5jb20+IHdy b3RlOg0KDQo+IEZvciB0aGUgcmVjb3JkLCBJIGNhbiBsaXZlIHdpdGggdGhlIGRyYWZ0IHdpdGgg dGhlIHdheSBpdCBpcywgaXQgDQo+IHNvdW5kcyBsaWtlIHRvbyBtdWNoIHdvcmsgdG8gZG8gYW55 dGhpbmcgZWxzZS4gIEknbSBzdGlsbCBjb25jZXJuZWQgDQo+IHRoYXQgd2UgZWZmZWN0aXZlbHkg aGF2ZSBwYXJ0aWFsIGhhbmRzaGFraW5nLCBidXQgSSBkb24ndCBzZWUgYW55IA0KPiByZWFzb24g d2h5IGl0IGNhbid0IHdvcmsgYXMgZHJhZnRlZC4NCg0KQWNrLiAgDQoNCkZvciB0aGUgcmVjb3Jk LCB3ZSBkaWQgZG8gdGhlIGFuYWx5c2lzIHRoZSBmaXJzdCB0aW1lIGFyb3VuZCBhbmQgY29uY2x1 ZGVkIHRoYXQgY2xpZW50IGFzc2VydGlvbiBhYm91dCB3aGF0IGl0IHdhcyBkb2luZyB3b3VsZG4n dCBhZGQgZW5vdWdoIHRvIGJlIHdvcnRoIHRoZSB0cm91YmxlLiAgSSdkIGJlIG11Y2ggbW9yZSBu ZXJ2b3VzIGlmIHdlIGhhZG4ndC4gIEFuZCBteSBwZXJzb25hbCBpbnN0aW5jdCB3b3VsZCBiZSB0 byByZXBlYXQgdGhlIGFuYWx5c2lzIGFuZCBtYWtlIHN1cmUgd2UgaGFkIGNvdmVyZWQgYWxsIG9m IHRoZSBjYXNlcy4uLiBidXQgSSBkb24ndCBzZWUgaG93IHRvIGRvIHRoYXQgdW5sZXNzIHRoZXJl IGlzIGNvbnNlbnN1cyB0aGF0IHNwZWVkIGxlc3MgaW1wb3J0YW50IHRoYW4gbWFraW5nIHN1cmUg d2UgZ2V0IGV2ZXJ5dGhpbmcgYXMgYnVsbGV0cHJvb2YgYXMgcG9zc2libGUuDQoNCiAgICAgam9o bg0KDQoNCg== From klensin@jck.com Thu Jul 8 12:36:51 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6323A6B4B for ; Thu, 8 Jul 2010 12:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNu8WKsaDYG9 for ; Thu, 8 Jul 2010 12:36:51 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id C91DA3A689B for ; Thu, 8 Jul 2010 12:36:50 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OWwtw-000NmG-ME; Thu, 08 Jul 2010 15:36:52 -0400 Date: Thu, 08 Jul 2010 15:36:52 -0400 From: John C Klensin To: Shawn Steele , Jiankang YAO , ima@ietf.org Message-ID: In-Reply-To: References: <15E3D3082DCC3F1ABB7B57FD@PST.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 Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:36:52 -0000 --On Thursday, July 08, 2010 18:10 +0000 Shawn Steele wrote: > Sorry I missed this on the first go-around then :) (BTW: Are > there "complete" archives? Not that I can find anything > anyway, but it looks like they're available for a certain > window?) There should be. Harald would know. But I can't remember whether that analysis was done during the WG period or in the pre-WG JET work. john From edainow@ca.afilias.info Thu Jul 8 12:51:42 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E113A684C for ; Thu, 8 Jul 2010 12:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F78NGwTOyIID for ; Thu, 8 Jul 2010 12:51:41 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 794EC3A688F for ; Thu, 8 Jul 2010 12:51:41 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OWx8L-00021e-5E for ima@ietf.org; Thu, 08 Jul 2010 19:51:45 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=[10.10.68.31]) by smtp.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OWx8L-0007yJ-4X for ima@ietf.org; Thu, 08 Jul 2010 19:51:45 +0000 Message-ID: <4C362C4D.2070803@ca.afilias.info> Date: Thu, 08 Jul 2010 15:51:41 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] More comments on draft-ietf-eai-rfc5336bis-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:51:42 -0000 Expanding on an earlier comment by SM, RFC2821 has been obsoleted by RFC5321. So all references in the document to [RFC2821] should be changed to [RFC5321]. Similarly all references to [RFC2822 ] should be changed to [RFC5322]. 3.2. The UTF8SMTPbis Extension (last paragraph) If a server advertises UTF8SMTP and the client does not recognize the extension, the client may send a regular message [RFC2821 ] and [RFC2822 ]. In this case, the client may continue to use the [RFC3490 ] or [RFC5890 ] ToAscii() to encode the domain portion of an address. The second sentence is not very clear. Is the following what is meant? In this case, the client will not be able to transmit any messages which contain non-ASCII characters in the local-part of any email addresses. If the non-ASCII characters are confined only to the domain portion of the address, such a client will be able to transmit messages if it uses [RFC3490] or [RFC5890] ToAscii() to encode the domain portions of these addresses. (last sentence) UTF8SMTP servers MUST recognize and decode the ACE label(s) as appropriate. A final delivery MTA must recognize that a domain containing UTF8 characters is equivalent to an ACE of that domain, but it's not clear where a server would actually need to decode an ACE back to UTF8. Can an example be provided? If not, omit this sentence. 3.6.2. Mail eXchangers Authorized servers are generally listed in MX records as described in RFC 2821 . When more than one server accepts mail for the domain-part of a mailbox, it is strongly advised that either all or none of them support the UTF8SMTPbis extension. Otherwise, surprising downgrades can happen during temporary failures, which users might perceive as a serious reliability issue. We don't have downgrade anymore. Shouldn't the last sentence read Otherwise, delivery failures will occur for some internationalized messages and not for others, depending on which MX record is selected. -Ernie From edainow@ca.afilias.info Fri Jul 9 11:52:27 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872243A6847 for ; Fri, 9 Jul 2010 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYnZIcqYFkl0 for ; Fri, 9 Jul 2010 11:52:26 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id BFBB63A689D for ; Fri, 9 Jul 2010 11:52:25 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OXIgY-0001Bs-7g; Fri, 09 Jul 2010 18:52:30 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=[10.10.68.31]) by smtp.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OXIgY-0004N5-6p; Fri, 09 Jul 2010 18:52:30 +0000 Message-ID: <4C376FE5.2070503@ca.afilias.info> Date: Fri, 09 Jul 2010 14:52:21 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John C Klensin References: <4C348414.50109@ca.afilias.info> <17ED2375A01530ABA3588678@PST.JCK.COM> In-Reply-To: <17ED2375A01530ABA3588678@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 18:52:27 -0000 Small typo below, plus another reference that goes back to 1989. -Ernie John C Klensin wrote: > Unless there is disagreement with any of these changes, they > will be incorporated in -02 (which will probably be posted > before the weekend). > > john > > > --On Wednesday, July 07, 2010 09:41 -0400 Ernie Dainow > wrote: > > >> 2. Role of This Specification >> [[anchor2: Note in Draft: Is 5825 still relevant, or is a >> victim of the "no in-transit downgrade" decision.??]] >> >> Comment: RFC 5825 describes how to construct the original >> headers from the "Downgraded-" headers. This is not relevant >> unless we are planning to use such headers (defined in 5504) >> for specifying how a final delivery SMTP server/mail store >> should downgrade messages that POP or IMAP can restore for >> UTF8 clients. >> >> 7.1 SMTP Extension for Internationalized Email Address >> Conformance to the group of standards specified here for email >> transport and delivery requires implementation of the SMTP >> Extension specification, including recognition of the keywords >> associated with alternate addresses, and the UTF-8 Header >> specification. >> >> Comment: remove "including recognition of the keywords >> associated with alternate addresses". >> >> 8. Downgrading before and after SMTP Transactions >> While the experiments that preceded these specifications >> included a mechanism for passing backup ASCII addresses to >> intermediate relay systems and having those systems alter the >> relevant message header fields and substitute the addresses, >> >> Comment: add a reference to RFC 5504 for future readers who >> may not know anything about the Experimental drafts. >> >> 9. Downgrading in Transit >> [[anchor16: ... this section will simply be dropped.]] >> >> Comment: Leading up to the recharter, there was a lot of >> heated discussion on algorithmic/ACE transformations, even >> though it had been covered at the beginning of the working >> group. I think we need to capture some of this history or >> future readers of the standard will raise the same questions >> again. I suggest the following as a starting point. >> >> Section 2.3.11 of RFC 2321, and RFC 2821 before that, states >> Change to: Section 2.3.11 of RFC 5321 states (with equivalent wording in earlier standards RFC 2821 and RFC 1123) >> that "due to a long history of problems when intermediate >> hosts have attempted to optimize transport by modifying them, >> the local-part MUST be interpreted and assigned semantics only >> by the host specified in the domain part of the address". >> >> Adherence to this rule means that a downgrade mechanism that >> transforms the local-part of an email address cannot be done >> in transit. It can only be done at the endpoints, namely by >> the MUA or submission server or by the final delivery SMTP >> server. >> >> One of the reasons for this rule has to do with legacy email >> systems that use source routing in the local-part of the >> address field. Transforming the email address destroys such >> routing information. There is no way a server other than the >> final delivery server can know, for example, whether the >> local-part of user%foo@example.com is a route ("user" is >> reached via "foo") or simply a local address. >> >> >> - Ernie >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima >> > > > > > From klensin@jck.com Fri Jul 9 13:08:12 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10BF3A68C1 for ; Fri, 9 Jul 2010 13:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTL8FeuJ+NmG for ; Fri, 9 Jul 2010 13:08:11 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7C7B33A68BE for ; Fri, 9 Jul 2010 13:08:11 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OXJrs-000BsS-Dy for ima@ietf.org; Fri, 09 Jul 2010 16:08:16 -0400 Date: Fri, 09 Jul 2010 16:08:15 -0400 From: John C Klensin To: ima@ietf.org Message-ID: 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 Subject: [EAI] Substantive questions about draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:08:12 -0000 Hi. I had hoped that people would actually read this document, discover the well-documented questions, and respond. But with a very few exceptions, that apparently was not to be. So... The draft contains the following questions or issues about which broader WG input is needed. If we don't hear back soon, I'll assume that anyone who has not expressed an opinion already is either happy with those opinions or doesn't care. Before commenting, please check to determine whether -02 has been posted. If it has, I'd appreciate any comments being addressed to it but note that -02 will probably reflect whatever answers have been received by that time, removal of the sections identified for removal below, etc. Those changes can obviously be undone, but late comments should be very persuasive ("late" is being measured from the posting date of -01 on 3 July, not the time of this note). The list --only a half-dozen items-- appears below. Note that these are extracted from the draft, sometimes with minor editorial changes or explanation to reduce the need for context. If any of them are not clear, see the draft (anchor numbers have been left in place to make that easier). I have not listed the relatively minor editorial issues. Lack of comment on them will be taken to imply that the editors should use their own judgment. (1) [[anchor1: Note to EAI WG: the -00 and -01 drafts are intended to initiate discussion on what should, and should not, be in the Framework document and how we want those topics covered. As such, they are more of an intermediate draft between RFC 4952 and the first draft of 4952bis that could be a Last Call candidate. If we are going to keep the rather aggressive schedule we agreed to in the charter, we need to have enough discussion on critical-path points that a revision suitable (at least) for final review prior to Last Call can be posted before the 12 July I-D cutoff. For that to happen, we should have enough discussion to start determining consensus within the next 24 hours. So, focused comments and soon, please.]] (2) [[anchor2: The document describes the Experimental documents that are being brought forward. We believe that 5825 is no longer relevant and should be dropped. Any disagreement??]] (3) [[anchor12: ... Section 6 has provision for a more or less extensive document list/roadmap. Do we want to include one of those, given that the references will certainly create a situation in which this document can be approved, but not published, until all documents on the list are complete. I'm inclined to list the SMTP extension and headers documents only and hand-wave about the rest, but we need to discuss. Versions -00 and -01 simply refer to the current Experimental documents.]] (4) [[anchor16: Section 9 is now a placeholder for a discussion of "Downgrading in Transit". We could discuss the various issues with in-transit downgrading including the complexities of carrying backup addresses, the problems that motivated the "don't mess with addresses in transit" (paraphrased, obviously) rule in RFC 5321 and friends, and so on. Or we could omit it (and this section). Pragmatically, I think it would take us some time to reach consensus on what, exactly, should be said and that might delay progress. But input is clearly needed -- if it is not received before we prepare -02, this section will simply be dropped.]] (5) Section 10.1 contains a bullet that now reads o In general, it is wise for servers to provide addresses only in Normalized form and to normalize strings on receipt, using either Normalization Form NFC and, except in unusual circumstances, NFKC. [[anchor19: Note in Draft: "Normalize on receipt" is consistent with the recommendations in draft-iab-i18n-encoding. The issue with NFKC is that some of the characters mapped out may be significant, especially in personal names. Anyone with objections should speak up. Soon.]] (6) Section 12, "Experimental Targets" will be removed in -02 unless someone finds something in it on which they want to comment and have retained. best, john From klensin@jck.com Fri Jul 9 13:12:30 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A7A3A68C1 for ; Fri, 9 Jul 2010 13:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAIcS6fRdAjq for ; Fri, 9 Jul 2010 13:12:28 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8D13A3A686C for ; Fri, 9 Jul 2010 13:12:27 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OXJw0-000C2V-8c for ima@ietf.org; Fri, 09 Jul 2010 16:12:32 -0400 Date: Fri, 09 Jul 2010 16:12:31 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <243EF62927A4C6E05CDDCEAD@PST.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 Subject: [EAI] Maastricht meeting and Pre-WG-Last Call alert: draft-ietf-eai-frmwrk-4952bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:12:31 -0000 Hi. Other than two sets of comments from Ernie and Shawn's excursion about a client announcement keyword, I've seen no comments on this document since -01 was posted. I am about to take the silence as an indication that the WG is happy with this document. Note that "happy" implies that we have no remaining protocol design issues whose resolution would need to be reflected in in the framework/summary document. I don't know if that is true or not but, if it isn't, we had better know Really Soon Now. Absent more comments, I'm going to generate a -02 and post it before the deadline (more likely Sunday my time than at the last minute). I will then ask Joseph to initiate a WG Last Call to terminate not later than 0900 Maastricht time July 29 (i.e., 24 hours before we meet face to face) and will start a discussion with Alexey as to whether to issue an IETF Last Call on the document and then let it sit in the RFC Editor queue until the other documents are ready or to adopt some other plan. If you have comments or concerns, please express them _very_ soon. Also, if you are not coming to Maastricht and have any concerns about this document or any of the others, I will expect clear and focused comments to this mailing list well before our Maastricht meeting starts. Conclusions reached during the meeting will be checked with the mailing list as usual, but any criticisms or issues that we were not able to discuss at the meeting because of late posting had better be _really_ important. If there are no such criticisms, I'd expect the period of WG review after the IETF meeting ends to be very short. As far as I know right now, we have the following substantive items for the agenda in Maastricht, not necessarily in this order: (1) Final review of 4952bis, as discussed above. (2) Review and triage of 5335bis and 5336bis. If there are no comments, I would expect those documents to go into WG Last Call no later than mid-August, so people better start reading. (3) Review of other documents, schedules, and sorting out of author/editor responsibilities. Folks with other topics they would like on the agenda should identify them no later than the beginning of next week. While topics can, in principle, be added in Maastricht, we would really like to get comments from those who will not attend and that means that the topic should be on the agenda and discussion should start within the next week or so. Disclaimer: I signed up as co-chair based on what appeared to be WG consensus that we wanted to move things along quickly. While I'm certainly happy to consider special circumstances (e.g., I know August is a vacation month for many people and that a WG Last Call started in August should not terminate before September), "quickly" can be accomplished only if we are relatively intolerant of side discussions, off-topic discussions, or out of sequence discussions. It also means that we should adopt something of what is sometimes called a "you snooze, you lose" attitude: if a document is posted for comments, failure to make comments, or to ask for more time with a reason, will be taken as evidence of either agreement or indifference. If anyone objects to that strategy, he or she should speak up now and try to convince others that a slower and more deliberative pace is better and more likely to produce significantly better results. regards to all, john From alexey.melnikov@isode.com Sun Jul 11 04:51:52 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F58E3A67FA for ; Sun, 11 Jul 2010 04:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ5fao8IyLBZ for ; Sun, 11 Jul 2010 04:51:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 281033A681E for ; Sun, 11 Jul 2010 04:51:51 -0700 (PDT) Received: from [92.40.232.122] (92.40.232.122.sub.mbb.three.co.uk [92.40.232.122]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 11 Jul 2010 12:51:56 +0100 Message-ID: <4C39B05A.7@isode.com> Date: Sun, 11 Jul 2010 12:51:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin References: <243EF62927A4C6E05CDDCEAD@PST.JCK.COM> In-Reply-To: <243EF62927A4C6E05CDDCEAD@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Maastricht meeting and Pre-WG-Last Call alert: draft-ietf-eai-frmwrk-4952bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 11:51:52 -0000 John C Klensin wrote: >Hi. > > Hi John, > > > >Other than two sets of comments from Ernie and Shawn's excursion >about a client announcement keyword, I've seen no comments on >this document since -01 was posted. > >I am about to take the silence as an indication that the WG is >happy with this document. Note that "happy" implies that we >have no remaining protocol design issues whose resolution would >need to be reflected in in the framework/summary document. I >don't know if that is true or not but, if it isn't, we had >better know Really Soon Now. > >Absent more comments, I'm going to generate a -02 and post it >before the deadline (more likely Sunday my time than at the last >minute). I will then ask Joseph to initiate a WG Last Call to >terminate not later than 0900 Maastricht time July 29 (i.e., 24 >hours before we meet face to face) and will start a discussion >with Alexey as to whether to issue an IETF Last Call on the >document and then let it sit in the RFC Editor queue until the >other documents are ready or to adopt some other plan. > >If you have comments or concerns, please express them _very_ >soon. Also, if you are not coming to Maastricht and have any >concerns about this document or any of the others, I will expect >clear and focused comments to this mailing list well before our >Maastricht meeting starts. Conclusions reached during the >meeting will be checked with the mailing list as usual, but any >criticisms or issues that we were not able to discuss at the >meeting because of late posting had better be _really_ >important. If there are no such criticisms, I'd expect the >period of WG review after the IETF meeting ends to be very short. > I think you switched to around this line: >As far as I know right now, we have the following substantive >items for the agenda in Maastricht, not necessarily in this >order: > > (1) Final review of 4952bis, as discussed above. > > (2) Review and triage of 5335bis and 5336bis. If there > are no comments, I would expect those documents to go > into WG Last Call no later than mid-August, so people > better start reading. > > (3) Review of other documents, schedules, and sorting > out of author/editor responsibilities. > >Folks with other topics they would like on the agenda should >identify them no later than the beginning of next week. While >topics can, in principle, be added in Maastricht, we would >really like to get comments from those who will not attend and >that means that the topic should be on the agenda and discussion >should start within the next week or so. > > >Disclaimer: I signed up as co-chair based on what appeared to be >WG consensus that we wanted to move things along quickly. While >I'm certainly happy to consider special circumstances (e.g., I >know August is a vacation month for many people and that a WG >Last Call started in August should not terminate before >September), "quickly" can be accomplished only if we are >relatively intolerant of side discussions, off-topic >discussions, or out of sequence discussions. It also means >that we should adopt something of what is sometimes called a >"you snooze, you lose" attitude: if a document is posted for >comments, failure to make comments, or to ask for more time with >a reason, will be taken as evidence of either agreement or >indifference. If anyone objects to that strategy, he or she >should speak up now and try to convince others that a slower and >more deliberative pace is better and more likely to produce >significantly better results. > >regards to all, > john > > From klensin@jck.com Sun Jul 11 05:57:51 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500AC3A68AF for ; Sun, 11 Jul 2010 05:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0eiwQCQ6HB2 for ; Sun, 11 Jul 2010 05:57:50 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E43223A6891 for ; Sun, 11 Jul 2010 05:57:49 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OXw6V-000Mrq-Vr; Sun, 11 Jul 2010 08:57:56 -0400 Date: Sun, 11 Jul 2010 08:57:55 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: <109AFDAEECC2FD2C612F39E0@PST.JCK.COM> In-Reply-To: <4C39B05A.7@isode.com> References: <243EF62927A4C6E05CDDCEAD@PST.JCK.COM> <4C39B05A.7@isode.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 Cc: ima@ietf.org Subject: Re: [EAI] Maastricht meeting and Pre-WG-Last Call alert: draft-ietf-eai-frmwrk-4952bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 12:57:51 -0000 --On Sunday, July 11, 2010 12:51 +0100 Alexey Melnikov wrote: > John C Klensin wrote: > >> Hi. >> >> > Hi John, > >> >> >> >> Other than two sets of comments from Ernie and Shawn's >> excursion about a client announcement keyword, I've seen no >> comments on this document since -01 was posted. >> >> I am about to take the silence as an indication that the WG is >> happy with this document. Note that "happy" implies that we >> have no remaining protocol design issues whose resolution >> would need to be reflected in in the framework/summary >> document. I don't know if that is true or not but, if it >> isn't, we had better know Really Soon Now. >> >> Absent more comments, I'm going to generate a -02 and post it >> before the deadline (more likely Sunday my time than at the >> last minute). I will then ask Joseph to initiate a WG Last >> Call to terminate not later than 0900 Maastricht time July 29 >> (i.e., 24 hours before we meet face to face) and will start a >> discussion with Alexey as to whether to issue an IETF Last >> Call on the document and then let it sit in the RFC Editor >> queue until the other documents are ready or to adopt some >> other plan. >> >> If you have comments or concerns, please express them _very_ >> soon. Also, if you are not coming to Maastricht and have any >> concerns about this document or any of the others, I will >> expect clear and focused comments to this mailing list well >> before our Maastricht meeting starts. Conclusions reached >> during the meeting will be checked with the mailing list as >> usual, but any criticisms or issues that we were not able to >> discuss at the meeting because of late posting had better be >> _really_ important. If there are no such criticisms, I'd >> expect the period of WG review after the IETF meeting ends to >> be very short. >> > I think you switched to around this line: Yep. Realized that some hours after I sent it. Sorry >> As far as I know right now, we have the following substantive >> items for the agenda in Maastricht, not necessarily in this >> order: >> >> (1) Final review of 4952bis, as discussed above. >> >> (2) Review and triage of 5335bis and 5336bis. If there >> are no comments, I would expect those documents to go >> into WG Last Call no later than mid-August, so people >> better start reading. >> >> (3) Review of other documents, schedules, and sorting >> out of author/editor responsibilities. >> >> Folks with other topics they would like on the agenda should >> identify them no later than the beginning of next week. While >> topics can, in principle, be added in Maastricht, we would >> really like to get comments from those who will not attend and >> that means that the topic should be on the agenda and >> discussion should start within the next week or so. >> >> >> Disclaimer: I signed up as co-chair based on what appeared to >> be WG consensus that we wanted to move things along quickly. >> While I'm certainly happy to consider special circumstances >> (e.g., I know August is a vacation month for many people and >> that a WG Last Call started in August should not terminate >> before September), "quickly" can be accomplished only if we >> are relatively intolerant of side discussions, off-topic >> discussions, or out of sequence discussions. It also means >> that we should adopt something of what is sometimes called a >> "you snooze, you lose" attitude: if a document is posted for >> comments, failure to make comments, or to ask for more time >> with a reason, will be taken as evidence of either agreement >> or indifference. If anyone objects to that strategy, he or >> she should speak up now and try to convince others that a >> slower and more deliberative pace is better and more likely >> to produce significantly better results. >> >> regards to all, >> john >> >> From alexey.melnikov@isode.com Sun Jul 11 13:41:06 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F723A686A for ; Sun, 11 Jul 2010 13:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FjbAP9xbl0H for ; Sun, 11 Jul 2010 13:41:05 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 34CCE3A6838 for ; Sun, 11 Jul 2010 13:41:05 -0700 (PDT) Received: from [188.28.62.104] (188.28.62.104.threembb.co.uk [188.28.62.104]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 11 Jul 2010 21:41:11 +0100 Message-ID: <4C3A2C5A.6060402@isode.com> Date: Sun, 11 Jul 2010 21:40:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 20:41:06 -0000 Catching up with email. : John C Klensin wrote: >--On Thursday, July 08, 2010 16:38 +0000 Shawn Steele > wrote: > > [...] >>In any event, I don't think it's interesting enough to make a >>huge deal out of, however it did seem, to me, that we could >>have a chance to confirm that the client was indeed intending >>EAI behavior, for all commands, without assumptions and >>without needing a bunch of UTF8REPLY tokens. You've been >>around mail longer than me :), so if you think the assumption >>is good enough for interoperability with the huge variety of >>clients out there, then you're likely correct. >> >>Why is it evil for the server to know what the client supports? >> > >It isn't. And, if the above is your main point, then let's not >waste time and get distracted by arguments about, e.g., private >ISO8859SMTP extensions or non-conforming DATA content. > >I've got two sets of reasons to be hesitant about your proposed >command, one about protocol design (and, if you will, religion) >and the other about procedures. > >_Religion_: I'm extremely reluctant to see another state >introduced into SMTP. It isn't that we couldn't, but it would >be hard to get right, it would turn developing the text for >5336bis into a task that would require deep understanding of >5321 and the design decisions that have accumulated since 821, >it would require that we sort out the order in which commands >could occur, and it would require that we spend a lot of time >ensuring that such a new state didn't have bad interactions with >extensions already developed and on the standards track. We'd >have to analyze the implications of additional turnarounds, >specify whether RSET cleared the "UTF8" state, and review >pipelining and figure out whether we needed to update it. None >of that is insurmountable, but it wouldn't be quick and I don't >think the case has been made yet that it would be worth the >trouble. > I agree that adding a new command and new state is risky and not going to work very well for SMTP. >_Procedures_: If we are going to introduce this sort of >facility and remain consistent with the WG's roots, we should >specify this facility, publish an Experimental spec, develop >implementations, and test them against each other and the >installed base to be sure that there are no ill effects. >Perhaps we could bypass those steps, but it would be risky. > I think Experimental stage can be bypassed, but yes, it would be risky. >My experience with the IETF suggests that even doing the level of >examination needed to ensure consistency with 5321 and the >Pipelining extension if a new state were added would stretch >things out by at least six months and that going through the >Experimental spec and testing arrangements would stretch that >out to 12 - 18 months. If I adjust for the level of activity in >this WG (count the number of comments about anything but >editorial issues in 4952bis since it was posted), you can >probably double those numbers. > Right. >There is also the small issue of deployment speed: as with >8BITMIME, the current model requires that a server advertise the >extension (a few lines of code) and disable some tests. >Implementing a new command, advertising its availability, and >maintaining extra state information turns implementation of >email i18n back into a big deal. To the extent to which we are >depending on rapid deployment (at least within language >communities) as part of our defense against needing much more >complex transition models, making implementation unnecessarily >harder is not in our interest. > >If there were compelling need here, I'd think that was >worthwhile. But, so far, all we've heard about are theoretical >cases what would constitute encouraging bad ideas (e.g., >anything on the wire other than UTF-8) if were real and we >recognized them. > >I note, although you find it distasteful (and, actually, I do >too), that requiring "UTF8 stuff here" parameters on the MAIL, >RCPT, and DATA commands is much less problematic than >introducing a "UTF-8" command, precisely because it doesn't >introduce new state. > Agreed about disadvantages of the new state, but I think a new flag/parameter to the MAIL FROM command achieves the same purpose - the whole transaction becomes UTF-8-address-aware, much like 8BITMIME. >Of course, it means we would have to look >at extensions such as BDAT too, but... > Maybe not, if it just a flag/parameter to MAIL FROM. Having said that, I am on the fence on this. While I prefer explicit negotiation as suggested by Shawn, I am also agreeing with your argument about UTF-8 emails leaking to non-extended SMTP environments. From klensin@jck.com Sun Jul 11 15:28:02 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557BA3A68AC for ; Sun, 11 Jul 2010 15:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXFzO5KbnG-8 for ; Sun, 11 Jul 2010 15:28:01 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 15A7A3A68A0 for ; Sun, 11 Jul 2010 15:28:01 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OY50H-000CoL-Hc; Sun, 11 Jul 2010 18:28:05 -0400 Date: Sun, 11 Jul 2010 18:28:04 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: In-Reply-To: <4C3A2C5A.6060402@isode.com> References: <4C3A2C5A.6060402@isode.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 Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] Random thought #1 - UTF8SMTP handshaking X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 22:28:02 -0000 --On Sunday, July 11, 2010 21:40 +0100 Alexey Melnikov wrote: >... >> If there were compelling need here, I'd think that was >> worthwhile. But, so far, all we've heard about are >> theoretical cases what would constitute encouraging bad ideas >> (e.g., anything on the wire other than UTF-8) if were real >> and we recognized them. >> >> I note, although you find it distasteful (and, actually, I do >> too), that requiring "UTF8 stuff here" parameters on the MAIL, >> RCPT, and DATA commands is much less problematic than >> introducing a "UTF-8" command, precisely because it doesn't >> introduce new state. >> > Agreed about disadvantages of the new state, but I think a new > flag/parameter to the MAIL FROM command achieves the same > purpose - the whole transaction becomes UTF-8-address-aware, > much like 8BITMIME. > >> Of course, it means we would have to look >> at extensions such as BDAT too, but... >> > Maybe not, if it just a flag/parameter to MAIL FROM. > Having said that, I am on the fence on this. While I prefer > explicit negotiation as suggested by Shawn, I am also agreeing > with your argument about UTF-8 emails leaking to non-extended > SMTP environments. If we could do this with a parameter on MAIL and no other clutter, I'd probably drop my opposition -- having the client just tell the server that it is about to send UTF-8 traffic is pretty harmless at worst. But part of Shawn's argument for a new verb is that we've already got issues with VRFY and EXPN because the replies from those commands are not "errors" even though they use the response code mechanism. Another issue is that signaling the server that the client is UTF8-capable opens the door to a whole series of issues that we decided to not touch for interoperability reasons, include non-ASCII response messages (with or without non-ASCII digits in the codes), language negotiation for response codes, etc. All of that is very tempting, but would vastly complicate SMTP compared to "take the codes and translate in the MUA that handles the response", especially in relay environments in which the language(s) of the relay operator may have no relationship to those of either the sender or the receiver. best, john From Shawn.Steele@microsoft.com Sun Jul 11 23:08:23 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EEF3A6835 for ; Sun, 11 Jul 2010 23:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.163 X-Spam-Level: X-Spam-Status: No, score=-9.163 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnQPy-aD9LTN for ; Sun, 11 Jul 2010 23:08:22 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A454D3A67C2 for ; Sun, 11 Jul 2010 23:08:22 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 11 Jul 2010 23:08:30 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0160.007; Sun, 11 Jul 2010 23:08:29 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Comments on draft-ietf-eai-frmwrk-4952bis-01 Thread-Index: AcsfnGzQlL9X1gg+SIy9oIBnXfjrbQ== Date: Mon, 12 Jul 2010 06:08:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 06:08:23 -0000 > The second sentence is not very clear. Is the following what is meant? > In this case, the client will not be able to transmit any messages > which contain non-ASCII characters in the local-part of any email > addresses. If the non-ASCII characters are confined only to the > domain portion of the address, such a client will be able to > transmit messages if it uses [RFC3490] or [RFC5890] ToAscii() to > encode the domain portions of these addresses. They may have ASCII aliases (eg: transliterations) available, so I think th= at's a tad too restrictive. In this case, the client will not be able to transmit any messages which contain non-ASCII characters in the local-part of any email addresses. If the client has an ASCII only address available, such as an alias, or by applying [RFC3490bis] ToAscii to the domain portion of the address, then it may be able to send the mail in ASCII as per [RFC2821]. -Shawn= From klensin@jck.com Mon Jul 12 01:38:39 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825313A6A6C for ; Mon, 12 Jul 2010 01:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPJRRnkPHJVk for ; Mon, 12 Jul 2010 01:38:38 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 540473A680E for ; Mon, 12 Jul 2010 01:38:38 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYEXE-0001qp-UC; Mon, 12 Jul 2010 04:38:45 -0400 Date: Mon, 12 Jul 2010 04:38:44 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org 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 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:38:39 -0000 Shawn, --On Monday, July 12, 2010 06:08 +0000 Shawn Steele wrote: >> The second sentence is not very clear. Is the following what >> is meant? > >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the non-ASCII >> characters are confined only to the domain portion of the >> address, such a client will be able to transmit messages >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >> domain portions of these addresses. I can't even find the above text in 4952bis-01. To what are you referring? > They may have ASCII aliases (eg: transliterations) available, > so I think that's a tad too restrictive. And I don't understand this comment. If an ASCII alias is substituted for the non-ASCII local part, then the message proposed to be transmitted no longer contains a non-ASCII local part. Either the local-part in the _message the client is going to transmit_ is all-ASCII or it isn't. If it isn't, the above is true. If it is all-ASCII, the above is irrelevant. If you are suggesting that two messages are somehow the same because one uses ASCII aliases for addresses found in the other, I think that takes us directly into the mess of having to assert an externally-verifiable identity binding between the two addresses. Only the delivery MTA or the destination user can know that, and they aren't obligated to tell (even on VRFY). > In this case, the client will not be able to transmit any > messages which contain non-ASCII characters in the > local-part of any email addresses. If the client has an > ASCII only address available, such as an alias, or by > applying [RFC3490bis] ToAscii to the domain portion of the > address, then it may be able to send the mail in ASCII as > per [RFC2821]. That statement would be true, but a lot less helpful than I think you want, if the last part of it read something like "...then it may be able to send a similar, transformed, message in ASCII as..." best, john From yaojk@cnnic.cn Mon Jul 12 01:50:36 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB46D3A67F2 for ; Mon, 12 Jul 2010 01:50:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.366 X-Spam-Level: ** X-Spam-Status: No, score=2.366 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2B8zse4qtCT for ; Mon, 12 Jul 2010 01:50:35 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 5E0303A6774 for ; Mon, 12 Jul 2010 01:50:35 -0700 (PDT) Received: (eyou send program); Mon, 12 Jul 2010 16:50:41 +0800 Message-ID: <478924641.07896@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 12 Jul 2010 16:50:41 +0800 Message-ID: <4B37B4AF9BC04A92A6F73FD26FEB0B8D@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , "Shawn Steele" , References: <478923931.07894@cnnic.cn> Date: Mon, 12 Jul 2010 16:50:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:50:36 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJTaGF3biBTdGVlbGUiIDxTaGF3bi5TdGVlbGVAbWljcm9z b2Z0LmNvbT47IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1bHkgMTIsIDIwMTAgNDoz OCBQTQ0KU3ViamVjdDogUmU6IFtFQUldIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtZWFpLWZybXdy ay00OTUyYmlzLTAxDQoNCg0KPiBTaGF3biwNCj4gDQo+IA0KPiAtLU9uIE1vbmRheSwgSnVseSAx MiwgMjAxMCAwNjowOCArMDAwMCBTaGF3biBTdGVlbGUNCj4gPFNoYXduLlN0ZWVsZUBtaWNyb3Nv ZnQuY29tPiB3cm90ZToNCj4gDQo+Pj4gVGhlIHNlY29uZCBzZW50ZW5jZSBpcyBub3QgdmVyeSBj bGVhci4gSXMgdGhlIGZvbGxvd2luZyB3aGF0DQo+Pj4gaXMgbWVhbnQ/DQo+PiANCj4+PiAgICBJ biB0aGlzIGNhc2UsIHRoZSBjbGllbnQgd2lsbCBub3QgYmUgYWJsZSB0byB0cmFuc21pdCBhbnkN Cj4+PiAgICBtZXNzYWdlcyB3aGljaCBjb250YWluIG5vbi1BU0NJSSBjaGFyYWN0ZXJzIGluIHRo ZQ0KPj4+ICAgIGxvY2FsLXBhcnQgb2YgYW55IGVtYWlsIGFkZHJlc3Nlcy4gSWYgdGhlIG5vbi1B U0NJSQ0KPj4+ICAgIGNoYXJhY3RlcnMgYXJlIGNvbmZpbmVkIG9ubHkgdG8gdGhlIGRvbWFpbiBw b3J0aW9uIG9mIHRoZQ0KPj4+ICAgIGFkZHJlc3MsIHN1Y2ggYSBjbGllbnQgd2lsbCBiZSBhYmxl IHRvIHRyYW5zbWl0IG1lc3NhZ2VzDQo+Pj4gICAgaWYgaXQgdXNlcyBbUkZDMzQ5MF0gb3IgW1JG QzU4OTBdIFRvQXNjaWkoKSB0byBlbmNvZGUgdGhlDQo+Pj4gICAgZG9tYWluIHBvcnRpb25zIG9m IHRoZXNlIGFkZHJlc3Nlcy4NCj4gDQo+IEkgY2FuJ3QgZXZlbiBmaW5kIHRoZSBhYm92ZSB0ZXh0 IGluIDQ5NTJiaXMtMDEuICBUbyB3aGF0IGFyZSB5b3UNCj4gcmVmZXJyaW5nPw0KPiANCg0KSGUg bWF5IHJlZmVyZW5jZSB0byByZmM1MzM2YmlzDQo= From root@core3.amsl.com Mon Jul 12 02:15:06 2010 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C49513A6A79; Mon, 12 Jul 2010 02:15:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712091506.C49513A6A79@core3.amsl.com> Date: Mon, 12 Jul 2010 02:15:06 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-frmwrk-4952bis-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:15:07 -0000 --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 : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-frmwrk-4952bis-02.txt Pages : 26 Date : 2010-07-12 Full use of electronic mail throughout the world requires that, subject to other constraints, people be able to use close variations on their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952 that reflects additional issues identified since that document was published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-frmwrk-4952bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-frmwrk-4952bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12021500.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Mon Jul 12 02:53:24 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64943A6774 for ; Mon, 12 Jul 2010 02:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHDsdGuIuj06 for ; Mon, 12 Jul 2010 02:53:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 143353A6403 for ; Mon, 12 Jul 2010 02:53:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 19533E06A3; Mon, 12 Jul 2010 02:53:32 -0700 (PDT) To: abelyang@twnic.net.tw, alexey.melnikov@isode.com, stpeter@stpeter.im, john-ietf@jck.com, jyee@ca.afilias.info From: RFC Errata System Message-Id: <20100712095332.19533E06A3@rfc-editor.org> Date: Mon, 12 Jul 2010 02:53:32 -0700 (PDT) Cc: john-ietf@jck.com, ima@ietf.org, rfc-editor@rfc-editor.org Subject: [EAI] [Editorial Errata Reported] RFC5335 (2322) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:53:24 -0000 The following errata report has been submitted for RFC5335, "Internationalized Email Headers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5335&eid=2322 -------------------------------------- Type: Editorial Reported by: John Klensin Section: Author info Original Text ------------- Y. Abel (in first-page header block) Abel (in page footers) Corrected Text -------------- A. Yang Yang Notes ----- The author is listed in the Author's Address section as "Abel Yang (editor)", which is correct although "Abel YANG (editor)" might have been preferable. In any event, the family name is "Yang", not "Abel", so the page 1 header block, page footers, and RFC Index entries are in error. This is fixed in draft-ietf-eai-rfc5335bis-02 and later. A successor to that document will eventually obsolete RFC 5335. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5335 (draft-ietf-eai-utf8headers-12) -------------------------------------- Title : Internationalized Email Headers Publication Date : September 2008 Author(s) : Y. Abel, Ed. Category : EXPERIMENTAL Source : Email Address Internationalization Area : Applications Stream : IETF Verifying Party : IESG From klensin@jck.com Mon Jul 12 03:56:54 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BD33A686E for ; Mon, 12 Jul 2010 03:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=-1.849, BAYES_20=-0.74, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTVjuCqn4x6v for ; Mon, 12 Jul 2010 03:56:53 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 444A83A67E9 for ; Mon, 12 Jul 2010 03:56:53 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYGh2-0006M2-LE for ima@ietf.org; Mon, 12 Jul 2010 06:57:00 -0400 Date: Mon, 12 Jul 2010 06:56:59 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <2C71E672E8DD283B9F8F0DBA@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========A6F11E3F08F30BC4E212==========" Subject: [EAI] draft-ietf-eai-frmwrk-4952bis-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 10:56:54 -0000 --==========A6F11E3F08F30BC4E212========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. Per the comments in my notes last Friday, draft-ietf-eai-frmwrk-4952bis-02 has been posted. I incorporated Ernie's comments, resolved the open issues for which no comments have been received, responded to a few miscellaneous comments, updated references, and did a careful read-through. The list of changes is fairly extensive; I'm attaching the change log listing in the hope that it will motivate people to look at the document. Quoting from the note at the beginning of the Introduction to -02: [[anchor1: Note to EAI WG: All comments received on the mailing list about this document have been incorporated into the -02 draft. As indicated in earlier notes, most placeholders have been removed from it to make the document a WG Last Call candidate. A note was posted on 9 July listing outstanding topics needing discussion in -01 (http://www.ietf.org/mail-archive/web/ima/current/msg03259.html) to which there was no response before -02 was submitted. It may be useful to refer to that note and the change log below as part of review of this draft.]] Joseph, please do a review of your own as needed and then initiate a WG Last Call. That Last Call should be terminated if substantive protocol changes that would require text in this document are discussed seriously. regards, john --==========A6F11E3F08F30BC4E212========== Content-Type: text/plain; charset=utf-8; name="4952bis-02-ChgLog.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="4952bis-02-ChgLog.txt"; size=2864 A.2. Changes between -01 and -02 Note that section numbers in the list that follows may refer = to -01 and not -02. o Discussion of RFC 5825 ("downgraded display") has been = removed per the earlier note and on-list discussion. Any needed = discussion about reconstructed messages will need to appear in the = IMAP and POP documents. However, the introductory material has = been reworded to permit keeping 5504 and 5825 on the list = there, without which the back chain would not be complete. For consistency with this change, 5504 and 5825 have been = added to the "Obsoletes" list (as far as I know, an Informational spec = can obsolete or update Experimental ones, so no downref = problem here --JcK). o Reference to alternate addresses dropped from (former) = Section 7.1. o Reference to RFC 5504 added to (former) Section 8 for completeness. o Ernie's draft comments added (with some minor edits) to = replace the placeholder in (former) Section 9 ("Downgrading in = Transit"). It is intended to capture at least an introduction the = earlier discussions of algorithmic downgrading generally and = ACE/Punycode transformations in particular. Anyone who is unhappy with = it should say so and propose alternate text. RSN. o In the interest of clarity and consistency with the = terminology in Section 4.1, all uses of "final delivery SMTP server" and = "final delivery server" have been changed to "final delivery = MTA". o Placeholder at the end of Section 2 has been removed and = the text revised to promise less. The "Document Plan" (Section 5) = has been revised accordingly. We need to discuss this at IETF 78 = if not sooner. o Sections 5 and 6 have been collapsed into one -- there = wasn't enough left in the former Section 5 to justify a separate = section. o Former Section 11.1 has been dropped and the DSN document = moved up into the "Document Plan" as suggested earlier. o Section 12, "Experimental Targets", has been removed. o Updated references for the new version EAI documents and = added placeholders for all of the known remaining drafts that = will become part of the core EAI series but that have not been = written. o Inserted an additional clarification about the = relationship of these extensions to non-ASCII messages. o Changed some normative/informative reference = classifications based on review of the new text. o Removed references to the pre-EAI documents that were = cited for historical context in 4952. o Got rid of a remaining pointer to address downgrading in = the discussion of an updated MAILTO URI. o Minor additional editorial cleanups and tuning. --==========A6F11E3F08F30BC4E212==========-- From root@core3.amsl.com Mon Jul 12 09:30:02 2010 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A5553A6A83; Mon, 12 Jul 2010 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712163002.5A5553A6A83@core3.amsl.com> Date: Mon, 12 Jul 2010 09:30:02 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-rfc5335bis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:30:03 -0000 --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) : . Yang, S. Steele Filename : draft-ietf-eai-rfc5335bis-01.txt Pages : 14 Date : 2010-7-12 Full internationalization of electronic mail requires not only the capabilities 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 the information based on them in mail header fields. This document specifies an 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. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of [RFC2045] to conform with the requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-rfc5335bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-7-12092414.I-D@ietf.org> --NextPart-- From Shawn.Steele@microsoft.com Mon Jul 12 09:57:15 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939343A69D9 for ; Mon, 12 Jul 2010 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxhyZjlzoxWx for ; Mon, 12 Jul 2010 09:57:14 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 92D493A69C2 for ; Mon, 12 Jul 2010 09:57:14 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 09:57:22 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Mon, 12 Jul 2010 09:57:22 -0700 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 Thread-Index: AQHLIZ2nqKeZX264JEuFP1FIyqgaJpKtflCQ Date: Mon, 12 Jul 2010 16:57:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:57:15 -0000 Sorry, I cut too much context. I was replying to Ernie's reply where he sa= id: 3.2. The UTF8SMTPbis Extension (last paragraph) =20 If a server advertises UTF8SMTP and the client does not recognize the extension, the client may send a regular message [RFC2821 ] and [RFC2822 ]. In this case, the clie= nt may continue to use the [RFC3490 ] or [RFC5890 ] ToAscii() to encode the domain portion of an address. The second sentence is not very clear. Is the following what is meant >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the non-ASCII >> characters are confined only to the domain portion of the >> address, such a client will be able to transmit messages >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >> domain portions of these addresses. So I suggested: > In this case, the client will not be able to transmit any > messages which contain non-ASCII characters in the > local-part of any email addresses. If the client has an > ASCII only address available, such as an alias, or by > applying [RFC3490bis] ToAscii to the domain portion of the > address, then it may be able to send the mail in ASCII as > per [RFC2821]. Where you replied: That statement would be true, but a lot less helpful than I think you want= , if the last part of it read something like "...then it may be able to sen= d a similar, transformed, message in ASCII as..." The original idea seems to be that "If UTF8SMTP isn't supported, you might = be able to try the old way by doing XXXXX". Since we expect at least some = users to have ASCII addresses, then XXXXX has more options than what Ernie'= s suggestion allowed. That's all I was trying to say. Even using Punycode= as in the original idea would be a "transformed" message. I'm not sure we need this text, since, of course, if the server doesn't sup= port UTF8SMTP, the existing standards still work :) It seems like there's = no harm in pointing that out, but I don't want to be overly restrictive in = our wording. Re: transliterations, I think I was confusing. We're expecting admins/user= s to create a Unicode address for their mailbox, and, likely, an ASCII addr= ess, which, in some cases, is probably a transliteration chosen by the admi= n or user. (Eg: Tarek, my manager, instead of however that's spelled in Ar= abic). - Shawn -----Original Message----- From: John C Klensin [mailto:klensin@jck.com]=20 Sent: Monday, July 12, 2010 1:39 AM To: Shawn Steele; ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 Shawn, --On Monday, July 12, 2010 06:08 +0000 Shawn Steele wrote: >> The second sentence is not very clear. Is the following what is=20 >> meant? >=20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the non-ASCII >> characters are confined only to the domain portion of the >> address, such a client will be able to transmit messages >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >> domain portions of these addresses. I can't even find the above text in 4952bis-01. To what are you referring? > They may have ASCII aliases (eg: transliterations) available, so I=20 > think that's a tad too restrictive. And I don't understand this comment. If an ASCII alias is substituted for = the non-ASCII local part, then the message proposed to be transmitted no lo= nger contains a non-ASCII local part. Either the local-part in the _messag= e the client is going to transmit_ is all-ASCII or it isn't. If it isn't, = the above is true. If it is all-ASCII, the above is irrelevant. =20 If you are suggesting that two messages are somehow the same because one us= es ASCII aliases for addresses found in the other, I think that takes us di= rectly into the mess of having to assert an externally-verifiable identity = binding between the two addresses. Only the delivery MTA or the destinatio= n user can know that, and they aren't obligated to tell (even on VRFY). > In this case, the client will not be able to transmit any > messages which contain non-ASCII characters in the > local-part of any email addresses. If the client has an > ASCII only address available, such as an alias, or by > applying [RFC3490bis] ToAscii to the domain portion of the > address, then it may be able to send the mail in ASCII as > per [RFC2821]. That statement would be true, but a lot less helpful than I think you want,= if the last part of it read something like "...then it may be able to send= a similar, transformed, message in ASCII as..." best, john From jyee@ca.afilias.info Mon Jul 12 11:00:56 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C023A6C26 for ; Mon, 12 Jul 2010 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyEuhvuuFIwL for ; Mon, 12 Jul 2010 11:00:55 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id F09CF3A6C19 for ; Mon, 12 Jul 2010 11:00:54 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYNJL-0005gY-6A; Mon, 12 Jul 2010 18:00:59 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYNJL-00074E-5L; Mon, 12 Jul 2010 18:00:59 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: Date: Mon, 12 Jul 2010 14:00:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Shawn Steele X-Mailer: Apple Mail (2.1081) Cc: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:00:56 -0000 Shawn, The discussion on encoding domain part with RFC3490 or RFC5890 is focus = on what may/can do immediately with ascii-only@utf8-domain address = (following the discussion that narrow down the scenario). Your concern = of too restrictive choices was addressed on section 7.1 in Framework-02 = of what MUA and user can do. The text there mentions wide range of = approaches. =20 I believed that Section 7.1 (in Framework-02) address your concern in = Section 3.2 (UTF8SMTPbis). Best Joseph On 2010-07-12, at 12:57 PM, Shawn Steele wrote: > Sorry, I cut too much context. I was replying to Ernie's reply where = he said: >=20 > 3.2. The UTF8SMTPbis Extension > (last paragraph) =20 >=20 > If a server advertises UTF8SMTP and the client does not = recognize the > extension, the client may send a regular message [RFC2821 = ] and > [RFC2822 ]. In this = case, the client may continue to use the > [RFC3490 ] or [RFC5890 = ] ToAscii() to encode the domain = portion of an > address. >=20 > The second sentence is not very clear. Is the following what is = meant >=20 > >> In this case, the client will not be able to transmit any > >> messages which contain non-ASCII characters in the > >> local-part of any email addresses. If the non-ASCII > >> characters are confined only to the domain portion of the > >> address, such a client will be able to transmit messages > >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the > >> domain portions of these addresses. >=20 > So I suggested: >=20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >=20 > Where you replied: >=20 > That statement would be true, but a lot less helpful than I = think you want, if the last part of it read something like "...then it = may be able to send a similar, transformed, message in ASCII as..." >=20 > The original idea seems to be that "If UTF8SMTP isn't supported, you = might be able to try the old way by doing XXXXX". Since we expect at = least some users to have ASCII addresses, then XXXXX has more options = than what Ernie's suggestion allowed. That's all I was trying to say. = Even using Punycode as in the original idea would be a "transformed" = message. >=20 > I'm not sure we need this text, since, of course, if the server = doesn't support UTF8SMTP, the existing standards still work :) It seems = like there's no harm in pointing that out, but I don't want to be overly = restrictive in our wording. >=20 > Re: transliterations, I think I was confusing. We're expecting = admins/users to create a Unicode address for their mailbox, and, likely, = an ASCII address, which, in some cases, is probably a transliteration = chosen by the admin or user. (Eg: Tarek, my manager, instead of however = that's spelled in Arabic). >=20 > - Shawn >=20 > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com]=20 > Sent: Monday, July 12, 2010 1:39 AM > To: Shawn Steele; ima@ietf.org > Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 >=20 > Shawn, >=20 >=20 > --On Monday, July 12, 2010 06:08 +0000 Shawn Steele = wrote: >=20 >>> The second sentence is not very clear. Is the following what is=20 >>> meant? >>=20 >>> In this case, the client will not be able to transmit any >>> messages which contain non-ASCII characters in the >>> local-part of any email addresses. If the non-ASCII >>> characters are confined only to the domain portion of the >>> address, such a client will be able to transmit messages >>> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >>> domain portions of these addresses. >=20 > I can't even find the above text in 4952bis-01. To what are you = referring? >=20 >> They may have ASCII aliases (eg: transliterations) available, so I=20 >> think that's a tad too restrictive. >=20 > And I don't understand this comment. If an ASCII alias is substituted = for the non-ASCII local part, then the message proposed to be = transmitted no longer contains a non-ASCII local part. Either the = local-part in the _message the client is going to transmit_ is all-ASCII = or it isn't. If it isn't, the above is true. If it is all-ASCII, the = above is irrelevant. =20 >=20 > If you are suggesting that two messages are somehow the same because = one uses ASCII aliases for addresses found in the other, I think that = takes us directly into the mess of having to assert an = externally-verifiable identity binding between the two addresses. Only = the delivery MTA or the destination user can know that, and they aren't = obligated to tell (even on VRFY). >=20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >=20 > That statement would be true, but a lot less helpful than I think you = want, if the last part of it read something like "...then it may be able = to send a similar, transformed, message in ASCII as..." >=20 > best, > john >=20 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Shawn.Steele@microsoft.com Mon Jul 12 11:03:07 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA7B3A6A4D for ; Mon, 12 Jul 2010 11:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.277 X-Spam-Level: X-Spam-Status: No, score=-10.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iXx9pNFHWKQ for ; Mon, 12 Jul 2010 11:03:06 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 07F293A6BA4 for ; Mon, 12 Jul 2010 11:03:04 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 11:03:13 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Mon, 12 Jul 2010 11:03:12 -0700 From: Shawn Steele To: Joseph Yee Thread-Topic: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Thread-Index: AQHLIexUTX0ZqHxSUkKl4d4qqa4eFZKtlQ2Q Date: Mon, 12 Jul 2010 18:03:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:03:07 -0000 I'll look, I'm rereading, but not quite there yet. Thanks :) -----Original Message----- From: Joseph Yee [mailto:jyee@ca.afilias.info]=20 Sent: Monday, July 12, 2010 11:01 AM To: Shawn Steele Cc: John C Klensin; ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Shawn, The discussion on encoding domain part with RFC3490 or RFC5890 is focus on = what may/can do immediately with ascii-only@utf8-domain address (following = the discussion that narrow down the scenario). Your concern of too restric= tive choices was addressed on section 7.1 in Framework-02 of what MUA and u= ser can do. The text there mentions wide range of approaches. =20 I believed that Section 7.1 (in Framework-02) address your concern in Secti= on 3.2 (UTF8SMTPbis). Best Joseph On 2010-07-12, at 12:57 PM, Shawn Steele wrote: > Sorry, I cut too much context. I was replying to Ernie's reply where he = said: >=20 > 3.2. The UTF8SMTPbis Extension > (last paragraph) >=20 > If a server advertises UTF8SMTP and the client does not recognize the > extension, the client may send a regular message [RFC2821 ] and > [RFC2822 ]. In this case, the cl= ient may continue to use the > [RFC3490 ] or [RFC5890 ] ToAscii() to encode the domain portion of an > address. >=20 > The second sentence is not very clear. Is the following what is meant >=20 > >> In this case, the client will not be able to transmit any > >> messages which contain non-ASCII characters in the > >> local-part of any email addresses. If the non-ASCII > >> characters are confined only to the domain portion of the > >> address, such a client will be able to transmit messages > >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the > >> domain portions of these addresses. >=20 > So I suggested: >=20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >=20 > Where you replied: >=20 > That statement would be true, but a lot less helpful than I think you wa= nt, if the last part of it read something like "...then it may be able to s= end a similar, transformed, message in ASCII as..." >=20 > The original idea seems to be that "If UTF8SMTP isn't supported, you migh= t be able to try the old way by doing XXXXX". Since we expect at least som= e users to have ASCII addresses, then XXXXX has more options than what Erni= e's suggestion allowed. That's all I was trying to say. Even using Punyco= de as in the original idea would be a "transformed" message. >=20 > I'm not sure we need this text, since, of course, if the server doesn't s= upport UTF8SMTP, the existing standards still work :) It seems like there'= s no harm in pointing that out, but I don't want to be overly restrictive i= n our wording. >=20 > Re: transliterations, I think I was confusing. We're expecting admins/us= ers to create a Unicode address for their mailbox, and, likely, an ASCII ad= dress, which, in some cases, is probably a transliteration chosen by the ad= min or user. (Eg: Tarek, my manager, instead of however that's spelled in = Arabic). >=20 > - Shawn >=20 > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com] > Sent: Monday, July 12, 2010 1:39 AM > To: Shawn Steele; ima@ietf.org > Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 >=20 > Shawn, >=20 >=20 > --On Monday, July 12, 2010 06:08 +0000 Shawn Steele wrote: >=20 >>> The second sentence is not very clear. Is the following what is=20 >>> meant? >>=20 >>> In this case, the client will not be able to transmit any >>> messages which contain non-ASCII characters in the >>> local-part of any email addresses. If the non-ASCII >>> characters are confined only to the domain portion of the >>> address, such a client will be able to transmit messages >>> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >>> domain portions of these addresses. >=20 > I can't even find the above text in 4952bis-01. To what are you referrin= g? >=20 >> They may have ASCII aliases (eg: transliterations) available, so I=20 >> think that's a tad too restrictive. >=20 > And I don't understand this comment. If an ASCII alias is substituted fo= r the non-ASCII local part, then the message proposed to be transmitted no = longer contains a non-ASCII local part. Either the local-part in the _mess= age the client is going to transmit_ is all-ASCII or it isn't. If it isn't= , the above is true. If it is all-ASCII, the above is irrelevant. =20 >=20 > If you are suggesting that two messages are somehow the same because one = uses ASCII aliases for addresses found in the other, I think that takes us = directly into the mess of having to assert an externally-verifiable identit= y binding between the two addresses. Only the delivery MTA or the destinat= ion user can know that, and they aren't obligated to tell (even on VRFY). >=20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >=20 > That statement would be true, but a lot less helpful than I think you wan= t, if the last part of it read something like "...then it may be able to se= nd a similar, transformed, message in ASCII as..." >=20 > best, > john >=20 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Shawn.Steele@microsoft.com Mon Jul 12 11:47:13 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363B93A69B1 for ; Mon, 12 Jul 2010 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j336Ke3ekJxn for ; Mon, 12 Jul 2010 11:47:11 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F1F903A69E7 for ; Mon, 12 Jul 2010 11:47:06 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 11:47:14 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Mon, 12 Jul 2010 11:47:15 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: draft-ietf-eai-frmwrk-4952bis-02 Thread-Index: Acsh6OYFI3YYzXk0SFa2oiAKq5nUlw== Date: Mon, 12 Jul 2010 18:47:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] draft-ietf-eai-frmwrk-4952bis-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:47:13 -0000 > Joseph, please do a review of your own as needed and then > initiate a WG Last Call. That Last Call should be terminated if >substantive protocol changes that would require text in this > document are discussed seriously. :) > o Discussion of RFC 5825 ("downgraded display") has been removed per > the earlier note and on-list discussion. Any needed discussion Good > (as far as I know, an Informational spec can > obsolete or update Experimental ones, so no downref problem here > --JcK). Sounds reasonable. Anchor 5 I'm confused about the timing/process for renaming UTF8SMTPbis - I guess it= needs generated before this doc is published, but this doc is scheduled to= happen before the SMTP doc. Does it need a name before last call? How la= te can we defer creating a name?=20 4.3 "In particular, the use of non-ASCII message content is an integral part of the MIME specifications [RFC2045] and does not require these extensions (although it is compatible with them)." My understanding is that MIME isn't required for UTF-8 UTF8SMTP content. I= 'm not sure if that's clear here. (Though I imagine lots of mail is MIME a= nyway). 6.1 bullet 1: "use of ASCII-compatible (ACE) encoding [RFC3492] [RFC5890] on the right hand side is discouraged" This is fine for this doc, however in an EAI mail, punycode should be forbi= dden. So I'd like to see "MUST NOT", or at least "SHOULD NOT" have punycod= e on the RHS if the LHS has non-ASCII in the UTF8SMTP spec. (Which qualifi= es as "discouraged", which is stated here). 6.1 bullet 4. "no other code pages" Addresses my earlier question, and I'm fine with this text, although, in pr= actice, it's sort of like closing the barn door after the animals have left= . :) =20 7.1 does address my "sender can use legacy mail, if they can figure it out"= concern. =20 [anchor15] - Yao's been working on documents regarding the choice of addres= ses, which helps, I think. Though an interesting problem, I don't think we= need this note. Some of the most interesting parts. (How does my client = learn that Shawn-Unicode and ShawnSte are the same address?, and how do I e= nable the user to choose which address to send with) are probably more usab= ility type things. I'm not sure we need to provide much more than general = address selection/ways we expect them to be used guidelines. Anyway, I'd remove [anchor15] in the interest of not holding up the doc. I= think that 9 adequately captures the idea that app developers need to cons= ider User Interface and Configuration challenges. 9.1 - The charter has the "addresses" spec, I'm not sure you need to go int= o this much depth here. (don't see that it hurts either) * Normalization - I think the key point is that servers should be expected = to see addresses in different normalization (or unnormalized) forms, and th= ey should be prepared to normalize them. I think it is less important for = us to specify that they must use Form C. (They could achieve the same beha= vior if they used NFD internally). =20 Editorial: "Stated differently" restates the 1st bullet, but then lists tw= o new concepts that were alluded to in the text earlier, but not the bullet= s. (so it's not really "stating differently".) I'd remove "stated differe= ntly, and let the C0/C1 and "other kinds of punctionation" be top level bul= lets: o In general, it is wise to support addresses in Normalized form. Servers should normalize with a consistent Unicode normalization form. Compatibility forms may only be appropriate in unusual circums= tances. o It may be wise to support other forms of the same local-part string, either as aliases or by normalization of strings reaching the delivery server, in the event that the sender does not send the strings in normalized form. o C0 (and presumably C1) controls (see The Unicode Standard [Unicode52]) are prohibited, the first in RFC 5321 and the second by an obvious extension from it [RFC5198]. o Other kinds of punctuation, spaces, etc., are risky practice. Perhaps they will work, and SMTP receiver code is required to handle them, but creating dependencies on them in mailbox names that are chosen is usually a bad practice and may lead to interoperability problems. 12 - Security considerations. I think this does a nice job of balancing people's concerns about homograph= s without becoming too unreasonable, and I wouldn't change it :) *IF* some= thing did have to change, it's worth recognizing that email local parts and= domain names have different problems. It's very unclear whether I'm suppo= sed to be ShawnSte@microsoft.com or, maybe, shawnst (who gets most of my ty= poe'd mail :)) It's way worse for places like live mail and gmail where pe= ople end up as shawn1234 and shawn6666. Those are quite confusable regardl= ess of script. In short, I think that enabling Unicode does not increase t= he risk for an enterprise that controls their own assignments (as long as t= hey're careful). And, I think there's no further risk for the large places= that already have quite confusing names. As said, I think this doc does a= decent job of balancing the paranoia without itself becoming a fear monger= . =20 In summary, I can live with the document as it is :) I have asked the Exch= ange folks to review some of the parts I'm less familiar with, but I don't = expect major concerns. Thanks John, -Shawn From Shawn.Steele@microsoft.com Mon Jul 12 11:52:47 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4268F3A69DB for ; Mon, 12 Jul 2010 11:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.341 X-Spam-Level: X-Spam-Status: No, score=-10.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALekWY+iMlXi for ; Mon, 12 Jul 2010 11:52:46 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 866DD3A68A7 for ; Mon, 12 Jul 2010 11:52:46 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 11:52:54 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0180.004; Mon, 12 Jul 2010 11:52:55 -0700 From: Shawn Steele To: Joseph Yee Thread-Topic: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Thread-Index: AQHLIexUTX0ZqHxSUkKl4d4qqa4eFZKtos9g Date: Mon, 12 Jul 2010 18:52:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:52:47 -0000 Confirmed, yes, I'm happy with it. (mentioning again as it might get lost = in my longer reply I just replied). -Shawn -----Original Message----- From: Joseph Yee [mailto:jyee@ca.afilias.info]=20 Sent: Monday, July 12, 2010 11:01 AM To: Shawn Steele Cc: John C Klensin; ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Shawn, The discussion on encoding domain part with RFC3490 or RFC5890 is focus on = what may/can do immediately with ascii-only@utf8-domain address (following = the discussion that narrow down the scenario). Your concern of too restric= tive choices was addressed on section 7.1 in Framework-02 of what MUA and u= ser can do. The text there mentions wide range of approaches. =20 I believed that Section 7.1 (in Framework-02) address your concern in Secti= on 3.2 (UTF8SMTPbis). Best Joseph From jason@exchange.microsoft.com Mon Jul 12 11:58:23 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B360F3A69DC for ; Mon, 12 Jul 2010 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YceQnSnGCv+X for ; Mon, 12 Jul 2010 11:58:23 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id E39C13A68A7 for ; Mon, 12 Jul 2010 11:58:22 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.208.0; Mon, 12 Jul 2010 11:58:30 -0700 Received: from DF-M14-05.exchange.corp.microsoft.com ([169.254.2.6]) by DF-H14-01.exchange.corp.microsoft.com ([157.54.78.139]) with mapi id 14.01.0180.003; Mon, 12 Jul 2010 11:58:32 -0700 From: Jason Nelson To: Shawn Steele , Joseph Yee Thread-Topic: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Thread-Index: AQHLIexgtSHZxK+nj0OrNGA19gBzYpKuGF4A//+LfQA= Date: Mon, 12 Jul 2010 18:58:29 +0000 Message-ID: <6CE0D5FA2297784CB7A6F5F09865C895307F8353@DF-M14-05.exchange.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:58:23 -0000 In the current design, with a message destined to two recipients, A and B, = A supports UTF8 and B does not - what should B's P2 content look like? I g= et that the RFC specifically deals with addresses in transit, and that we s= hould not be mucking about with messages when not the submission server, bu= t resolving how the mail goes to both the guys in the US and the your busin= ess partner in Taiwan with both being able to reply across the board, that'= s giving me a few headaches. -----Original Message----- From: ima-bounces@ietf.org [mailto:ima-bounces@ietf.org] On Behalf Of Shawn= Steele Sent: Monday, July 12, 2010 11:53 AM To: Joseph Yee Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Confirmed, yes, I'm happy with it. (mentioning again as it might get lost = in my longer reply I just replied). -Shawn -----Original Message----- From: Joseph Yee [mailto:jyee@ca.afilias.info]=20 Sent: Monday, July 12, 2010 11:01 AM To: Shawn Steele Cc: John C Klensin; ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02) Shawn, The discussion on encoding domain part with RFC3490 or RFC5890 is focus on = what may/can do immediately with ascii-only@utf8-domain address (following = the discussion that narrow down the scenario). Your concern of too restric= tive choices was addressed on section 7.1 in Framework-02 of what MUA and u= ser can do. The text there mentions wide range of approaches. =20 I believed that Section 7.1 (in Framework-02) address your concern in Secti= on 3.2 (UTF8SMTPbis). Best Joseph _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From edainow@ca.afilias.info Mon Jul 12 12:06:46 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA843A69BD for ; Mon, 12 Jul 2010 12:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.41 X-Spam-Level: X-Spam-Status: No, score=-4.41 tagged_above=-999 required=5 tests=[AWL=-1.855, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omxa6a5rdt5D for ; Mon, 12 Jul 2010 12:06:45 -0700 (PDT) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id E66B93A6BA4 for ; Mon, 12 Jul 2010 12:06:36 -0700 (PDT) Received: from edainow.tor.afilias-int.info ([10.10.68.27]) by tor-gateway.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OYOKv-0001TL-5R; Mon, 12 Jul 2010 15:06:41 -0400 Message-ID: <4C3B2EE2.40404@ca.afilias.info> Date: Mon, 12 Jul 2010 15:04:02 +0000 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-4952bis-01) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:06:46 -0000 The confusion here is that it actually applies to a different thread. The wording I suggested and is being amended by Shawn (with which I agree) is from the thread More comments on draft-ietf-eai-rfc5336bis-00 not from Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 -Ernie Shawn Steele wrote: > Sorry, I cut too much context. I was replying to Ernie's reply where he said: > > 3.2. The UTF8SMTPbis Extension > (last paragraph) > > If a server advertises UTF8SMTP and the client does not recognize the > extension, the client may send a regular message [RFC2821 ] and > [RFC2822 ]. In this case, the client may continue to use the > [RFC3490 ] or [RFC5890 ] ToAscii() to encode the domain portion of an > address. > > The second sentence is not very clear. Is the following what is meant > > >> In this case, the client will not be able to transmit any > >> messages which contain non-ASCII characters in the > >> local-part of any email addresses. If the non-ASCII > >> characters are confined only to the domain portion of the > >> address, such a client will be able to transmit messages > >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the > >> domain portions of these addresses. > > So I suggested: > > >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >> > > Where you replied: > > That statement would be true, but a lot less helpful than I think you want, if the last part of it read something like "...then it may be able to send a similar, transformed, message in ASCII as..." > > The original idea seems to be that "If UTF8SMTP isn't supported, you might be able to try the old way by doing XXXXX". Since we expect at least some users to have ASCII addresses, then XXXXX has more options than what Ernie's suggestion allowed. That's all I was trying to say. Even using Punycode as in the original idea would be a "transformed" message. > > I'm not sure we need this text, since, of course, if the server doesn't support UTF8SMTP, the existing standards still work :) It seems like there's no harm in pointing that out, but I don't want to be overly restrictive in our wording. > > Re: transliterations, I think I was confusing. We're expecting admins/users to create a Unicode address for their mailbox, and, likely, an ASCII address, which, in some cases, is probably a transliteration chosen by the admin or user. (Eg: Tarek, my manager, instead of however that's spelled in Arabic). > > - Shawn > > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com] > Sent: Monday, July 12, 2010 1:39 AM > To: Shawn Steele; ima@ietf.org > Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 > > Shawn, > > > --On Monday, July 12, 2010 06:08 +0000 Shawn Steele wrote: > > >>> The second sentence is not very clear. Is the following what is >>> meant? >>> >>> In this case, the client will not be able to transmit any >>> messages which contain non-ASCII characters in the >>> local-part of any email addresses. If the non-ASCII >>> characters are confined only to the domain portion of the >>> address, such a client will be able to transmit messages >>> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >>> domain portions of these addresses. >>> > > I can't even find the above text in 4952bis-01. To what are you referring? > > >> They may have ASCII aliases (eg: transliterations) available, so I >> think that's a tad too restrictive. >> > > And I don't understand this comment. If an ASCII alias is substituted for the non-ASCII local part, then the message proposed to be transmitted no longer contains a non-ASCII local part. Either the local-part in the _message the client is going to transmit_ is all-ASCII or it isn't. If it isn't, the above is true. If it is all-ASCII, the above is irrelevant. > > If you are suggesting that two messages are somehow the same because one uses ASCII aliases for addresses found in the other, I think that takes us directly into the mess of having to assert an externally-verifiable identity binding between the two addresses. Only the delivery MTA or the destination user can know that, and they aren't obligated to tell (even on VRFY). > > >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >> > > That statement would be true, but a lot less helpful than I think you want, if the last part of it read something like "...then it may be able to send a similar, transformed, message in ASCII as..." > > best, > john > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From Shawn.Steele@microsoft.com Mon Jul 12 12:08:59 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D0B3A69DD for ; Mon, 12 Jul 2010 12:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.364 X-Spam-Level: X-Spam-Status: No, score=-10.364 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt2-8IXdiRaH for ; Mon, 12 Jul 2010 12:08:54 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4E49F3A69DC for ; Mon, 12 Jul 2010 12:08:54 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 12:09:02 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Mon, 12 Jul 2010 12:09:02 -0700 From: Shawn Steele To: Ernie Dainow Thread-Topic: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-4952bis-01) Thread-Index: AQHLIfVnS/djOfRZ6kucr8xKZ7sVqZKtpwzg Date: Mon, 12 Jul 2010 19:09:02 +0000 Message-ID: References: <4C3B2EE2.40404@ca.afilias.info> In-Reply-To: <4C3B2EE2.40404@ca.afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-4952bis-01) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:08:59 -0000 The whole part is different (or I missed it) in the new 02 draft, so I thin= k it's fine now. Sorry, I'm getting "digests", so I have to cut & paste the subject, and obv= iously didn't get it right :) -Shawn -----Original Message----- From: Ernie Dainow [mailto:edainow@ca.afilias.info]=20 Sent: Monday, July 12, 2010 8:04 AM To: Shawn Steele Cc: John C Klensin; ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-495= 2bis-01) The confusion here is that it actually applies to a different thread.=20 The wording I suggested and is being amended by Shawn (with which I agree) is from the thread More comments on draft-ietf-eai-rfc5336bis-00 not from Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 -Ernie Shawn Steele wrote: > Sorry, I cut too much context. I was replying to Ernie's reply where he = said: > > 3.2. The UTF8SMTPbis Extension > (last paragraph) > > If a server advertises UTF8SMTP and the client does not recognize the > extension, the client may send a regular message [RFC2821 ] and > [RFC2822 ]. In this case, the cl= ient may continue to use the > [RFC3490 ] or [RFC5890 ] ToAscii() to encode the domain portion of an > address. > > The second sentence is not very clear. Is the following what is meant > > >> In this case, the client will not be able to transmit any > >> messages which contain non-ASCII characters in the > >> local-part of any email addresses. If the non-ASCII > >> characters are confined only to the domain portion of the > >> address, such a client will be able to transmit messages > >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the > >> domain portions of these addresses. > > So I suggested: > > =20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >> =20 > > Where you replied: > > That statement would be true, but a lot less helpful than I think you wa= nt, if the last part of it read something like "...then it may be able to s= end a similar, transformed, message in ASCII as..." > > The original idea seems to be that "If UTF8SMTP isn't supported, you migh= t be able to try the old way by doing XXXXX". Since we expect at least som= e users to have ASCII addresses, then XXXXX has more options than what Erni= e's suggestion allowed. That's all I was trying to say. Even using Punyco= de as in the original idea would be a "transformed" message. > > I'm not sure we need this text, since, of course, if the server doesn't s= upport UTF8SMTP, the existing standards still work :) It seems like there'= s no harm in pointing that out, but I don't want to be overly restrictive i= n our wording. > > Re: transliterations, I think I was confusing. We're expecting admins/us= ers to create a Unicode address for their mailbox, and, likely, an ASCII ad= dress, which, in some cases, is probably a transliteration chosen by the ad= min or user. (Eg: Tarek, my manager, instead of however that's spelled in = Arabic). > > - Shawn > > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com] > Sent: Monday, July 12, 2010 1:39 AM > To: Shawn Steele; ima@ietf.org > Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 > > Shawn, > > > --On Monday, July 12, 2010 06:08 +0000 Shawn Steele wrote: > > =20 >>> The second sentence is not very clear. Is the following what is=20 >>> meant? >>> =20 >>> In this case, the client will not be able to transmit any >>> messages which contain non-ASCII characters in the >>> local-part of any email addresses. If the non-ASCII >>> characters are confined only to the domain portion of the >>> address, such a client will be able to transmit messages >>> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >>> domain portions of these addresses. >>> =20 > > I can't even find the above text in 4952bis-01. To what are you referrin= g? > > =20 >> They may have ASCII aliases (eg: transliterations) available, so I=20 >> think that's a tad too restrictive. >> =20 > > And I don't understand this comment. If an ASCII alias is substituted fo= r the non-ASCII local part, then the message proposed to be transmitted no = longer contains a non-ASCII local part. Either the local-part in the _mess= age the client is going to transmit_ is all-ASCII or it isn't. If it isn't= , the above is true. If it is all-ASCII, the above is irrelevant. =20 > > If you are suggesting that two messages are somehow the same because one = uses ASCII aliases for addresses found in the other, I think that takes us = directly into the mess of having to assert an externally-verifiable identit= y binding between the two addresses. Only the delivery MTA or the destinat= ion user can know that, and they aren't obligated to tell (even on VRFY). > > =20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >> =20 > > That statement would be true, but a lot less helpful than I think you wan= t, if the last part of it read something like "...then it may be able to se= nd a similar, transformed, message in ASCII as..." > > best, > john > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > =20 From klensin@jck.com Mon Jul 12 12:11:58 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269FA3A6B6F for ; Mon, 12 Jul 2010 12:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vLVAJPVdoyv for ; Mon, 12 Jul 2010 12:11:56 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 0EC8C3A69DF for ; Mon, 12 Jul 2010 12:11:56 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYOQ6-000Pnq-3Z; Mon, 12 Jul 2010 15:12:02 -0400 Date: Mon, 12 Jul 2010 15:12:00 -0400 From: John C Klensin To: Shawn Steele , Joseph Yee , ima@ietf.org Message-ID: 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 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:11:58 -0000 --On Monday, July 12, 2010 16:57 +0000 Shawn Steele wrote: > Sorry, I cut too much context. I was replying to Ernie's > reply where he said: >=20 > 3.2. The UTF8SMTPbis Extension > (last paragraph) =20 >=20 > If a server advertises UTF8SMTP and the client does not > recognize the extension, the client may send a regular > message [RFC2821 ] and > [RFC2822 ]. In this case, > the client may continue to use the [RFC3490 > ] or [RFC5890 > ] ToAscii() to encode the > domain portion of an address. Aha. I rewrote that very severely before putting it into -02, so couldn't find what you were quoting. > The second sentence is not very clear. Is the following what > is meant >=20 > >> In this case, the client will not be able to transmit > any >> messages which contain non-ASCII characters in the > >> local-part of any email addresses. If the non-ASCII >> > characters are confined only to the domain portion of the >> > address, such a client will be able to transmit messages >> > if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >> > domain portions of these addresses. >=20 > So I suggested: >=20 >> In this case, the client will not be able to transmit any >> messages which contain non-ASCII characters in the >> local-part of any email addresses. If the client has an >> ASCII only address available, such as an alias, or by >> applying [RFC3490bis] ToAscii to the domain portion of the >> address, then it may be able to send the mail in ASCII as >> per [RFC2821]. >=20 > Where you replied: >=20 > That statement would be true, but a lot less helpful than I > think you want, if the last part of it read something like > "...then it may be able to send a similar, transformed, > message in ASCII as..." >=20 > The original idea seems to be that "If UTF8SMTP isn't > supported, you might be able to try the old way by doing > XXXXX". Since we expect at least some users to have ASCII > addresses, then XXXXX has more options than what Ernie's > suggestion allowed. That's all I was trying to say. Even > using Punycode as in the original idea would be a > "transformed" message. I don't know what Ernie intended, but I took it as closer to "you either support the extensions or you are on your own with the traditional/legacy system". > I'm not sure we need this text, since, of course, if the > server doesn't support UTF8SMTP, the existing standards still > work :) It seems like there's no harm in pointing that out, > but I don't want to be overly restrictive in our wording. Right. Joseph's interpretation is, I think, close to mine. Have a look at the -02 text and see if you like it any better. I do have one observation about his comments -- see below. > Re: transcriptions, I think I was confusing. We're > expecting admins/users to create a Unicode address for their > mailbox, and, likely, an ASCII address, which, in some cases, > is probably a transcription chosen by the admin or user. > (Eg: Tarek, my manager, instead of however that's spelled in > Arabic). I think that, as you move around the world and look at names written in Roman characters for people whose native language isn't normally written that way, you will find transcriptions, transcriptions, translations, and more or less fanciful alternatives in some proportions. Note that, strictly speaking, Chinese cannot be transliterated, only transcribed (Japanese Kana can be transliterated into Romanji). If you take the three active participants in the WG who are of Chinese descent as examples, we see (I hope they will correct me if I have this wrong): o Joseph (probably not a transcription*; I don't know whether it is a translation of something else or not) o Jiankang (I presume a transcription*; but he has also sometimes used "Health", which I understand to be a translation) o XiaoDong (a transcription*; but he sometimes also has used "Sheldon", which sounds somewhat alike but it neither a translation or transcription) * Note that while Hanyu Pinyin is now the standard transcription system in the PRC and some other places, there are a huge number of mutually-incompatible transcription systems for Chinese. And, of course, transcription systems, by definition, reflect spoken languages, not written ones. Similar issues apply with other languages and names. Knowing the personal name doesn't tell you what convention is being used for a name in a different language/cultural environment. As an example that you and I should find mutually amusing, = =D0=98=D0=B2=D0=B0=D0=BD usually makes it into Roman characters as "Ivan", but Johann, John, and even Sean or Shawn, (but not Jon or Jonathan) are not unreasonable: all derive down different paths from = =D7=99=D7=95=D7=97=D7=A0=D7=9F. --On Monday, July 12, 2010 14:00 -0400 Joseph Yee wrote: > The discussion on encoding domain part with RFC3490 or RFC5890 > is focus on what may/can do immediately with > ascii-only@utf8-domain address (following the discussion that > narrow down the scenario). Your concern of too restrictive > choices was addressed on section 7.1 in Framework-02 of what > MUA and user can do. The text there mentions wide range of > approaches. =20 In going through what became -02 over the weekend, I discovered several clusters of text that are somewhat redundant with each other or that might be organized to be more easily found or understood. While I fixed those that I found and for which the fixes seemed straightforward, there are almost certainly others left. Suggestions about what material can safely be eliminated as covered elsewhere in document, what might better be reorganized and how, and where cross-references are needed would be most welcome. john From jyee@ca.afilias.info Mon Jul 12 12:14:39 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C673A69DF for ; Mon, 12 Jul 2010 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYGLmWfTPkv1 for ; Mon, 12 Jul 2010 12:14:35 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id ABC713A6C21 for ; Mon, 12 Jul 2010 12:14:34 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYOSg-0007AE-4L for ima@ietf.org; Mon, 12 Jul 2010 19:14:42 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYOSg-0000n0-3d for ima@ietf.org; Mon, 12 Jul 2010 19:14:42 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Joseph Yee In-Reply-To: Date: Mon, 12 Jul 2010 15:14:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C3B2EE2.40404@ca.afilias.info> To: "ima@ietf.org WG" X-Mailer: Apple Mail (2.1081) Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-4952bis-01) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:14:39 -0000 The follow text is what Ernie suggested for 5336bis > >> In this case, the client will not be able to transmit any > >> messages which contain non-ASCII characters in the > >> local-part of any email addresses. If the non-ASCII > >> characters are confined only to the domain portion of the > >> address, such a client will be able to transmit messages > >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the > >> domain portions of these addresses. Which Shawn expressed concern, and I believed (and Shawn agreed) that = text in Section 7.1 in Framework-02 addressed Shawn's concern. So the = text above is good (from consensus) for SMTPbis section 3.2 last = paragraph. Hope this is clear, because it involves two docs to discuss two = "inter-related" issues at the same time. Joseph On 2010-07-12, at 3:09 PM, Shawn Steele wrote: > The whole part is different (or I missed it) in the new 02 draft, so I = think it's fine now. >=20 > Sorry, I'm getting "digests", so I have to cut & paste the subject, = and obviously didn't get it right :) >=20 > -Shawn >=20 > -----Original Message----- > From: Ernie Dainow [mailto:edainow@ca.afilias.info]=20 > Sent: Monday, July 12, 2010 8:04 AM > To: Shawn Steele > Cc: John C Klensin; ima@ietf.org > Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not = frmwrk-4952bis-01) >=20 > The confusion here is that it actually applies to a different thread.=20= > The wording I suggested and is being amended by Shawn (with which I > agree) is from the thread >=20 > More comments on draft-ietf-eai-rfc5336bis-00 >=20 > not from Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 >=20 > -Ernie >=20 >=20 > Shawn Steele wrote: >> Sorry, I cut too much context. I was replying to Ernie's reply where = he said: >>=20 >> 3.2. The UTF8SMTPbis Extension >> (last paragraph) >>=20 >> If a server advertises UTF8SMTP and the client does not = recognize the >> extension, the client may send a regular message [RFC2821 = ] and >> [RFC2822 ]. In this = case, the client may continue to use the >> [RFC3490 ] or [RFC5890 = ] ToAscii() to encode the domain = portion of an >> address. >>=20 >> The second sentence is not very clear. Is the following what is = meant >>=20 >> >> In this case, the client will not be able to transmit any >> >> messages which contain non-ASCII characters in the >> >> local-part of any email addresses. If the non-ASCII >> >> characters are confined only to the domain portion of the >> >> address, such a client will be able to transmit messages >> >> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >> >> domain portions of these addresses. >>=20 >> So I suggested: >>=20 >>=20 >>> In this case, the client will not be able to transmit any >>> messages which contain non-ASCII characters in the >>> local-part of any email addresses. If the client has an >>> ASCII only address available, such as an alias, or by >>> applying [RFC3490bis] ToAscii to the domain portion of the >>> address, then it may be able to send the mail in ASCII as >>> per [RFC2821]. >>>=20 >>=20 >> Where you replied: >>=20 >> That statement would be true, but a lot less helpful than I = think you want, if the last part of it read something like "...then it = may be able to send a similar, transformed, message in ASCII as..." >>=20 >> The original idea seems to be that "If UTF8SMTP isn't supported, you = might be able to try the old way by doing XXXXX". Since we expect at = least some users to have ASCII addresses, then XXXXX has more options = than what Ernie's suggestion allowed. That's all I was trying to say. = Even using Punycode as in the original idea would be a "transformed" = message. >>=20 >> I'm not sure we need this text, since, of course, if the server = doesn't support UTF8SMTP, the existing standards still work :) It seems = like there's no harm in pointing that out, but I don't want to be overly = restrictive in our wording. >>=20 >> Re: transliterations, I think I was confusing. We're expecting = admins/users to create a Unicode address for their mailbox, and, likely, = an ASCII address, which, in some cases, is probably a transliteration = chosen by the admin or user. (Eg: Tarek, my manager, instead of however = that's spelled in Arabic). >>=20 >> - Shawn >>=20 >> -----Original Message----- >> From: John C Klensin [mailto:klensin@jck.com] >> Sent: Monday, July 12, 2010 1:39 AM >> To: Shawn Steele; ima@ietf.org >> Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 >>=20 >> Shawn, >>=20 >>=20 >> --On Monday, July 12, 2010 06:08 +0000 Shawn Steele = wrote: >>=20 >>=20 >>>> The second sentence is not very clear. Is the following what is=20 >>>> meant? >>>>=20 >>>> In this case, the client will not be able to transmit any >>>> messages which contain non-ASCII characters in the >>>> local-part of any email addresses. If the non-ASCII >>>> characters are confined only to the domain portion of the >>>> address, such a client will be able to transmit messages >>>> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the >>>> domain portions of these addresses. >>>>=20 >>=20 >> I can't even find the above text in 4952bis-01. To what are you = referring? >>=20 >>=20 >>> They may have ASCII aliases (eg: transliterations) available, so I=20= >>> think that's a tad too restrictive. >>>=20 >>=20 >> And I don't understand this comment. If an ASCII alias is = substituted for the non-ASCII local part, then the message proposed to = be transmitted no longer contains a non-ASCII local part. Either the = local-part in the _message the client is going to transmit_ is all-ASCII = or it isn't. If it isn't, the above is true. If it is all-ASCII, the = above is irrelevant. =20 >>=20 >> If you are suggesting that two messages are somehow the same because = one uses ASCII aliases for addresses found in the other, I think that = takes us directly into the mess of having to assert an = externally-verifiable identity binding between the two addresses. Only = the delivery MTA or the destination user can know that, and they aren't = obligated to tell (even on VRFY). >>=20 >>=20 >>> In this case, the client will not be able to transmit any >>> messages which contain non-ASCII characters in the >>> local-part of any email addresses. If the client has an >>> ASCII only address available, such as an alias, or by >>> applying [RFC3490bis] ToAscii to the domain portion of the >>> address, then it may be able to send the mail in ASCII as >>> per [RFC2821]. >>>=20 >>=20 >> That statement would be true, but a lot less helpful than I think you = want, if the last part of it read something like "...then it may be able = to send a similar, transformed, message in ASCII as..." >>=20 >> best, >> john >>=20 >>=20 >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima >>=20 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Shawn.Steele@microsoft.com Mon Jul 12 12:31:56 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8C43A6BFB for ; Mon, 12 Jul 2010 12:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aly+agMilNTz for ; Mon, 12 Jul 2010 12:31:55 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 099243A6C29 for ; Mon, 12 Jul 2010 12:31:53 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 12:32:01 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0160.007; Mon, 12 Jul 2010 12:32:02 -0700 From: Shawn Steele To: John C Klensin , Joseph Yee , "ima@ietf.org" Thread-Topic: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 Thread-Index: AQHLIZ2nqKeZX264JEuFP1FIyqgaJpKtflCQgACgAgD//4ypcA== Date: Mon, 12 Jul 2010 19:32:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:31:56 -0000 TGlrZSBJIChzb3J0IG9mIGRpZG4ndCkgc2F5OiAgTXkgdXNlIG9mICJ0cmFuc2NyaXB0aW9uIiBt dWRkaWVkIHRoZSB3YXRlciBhbmQgbG9zdCBteSBwb2ludCA6KQ0KDQpBbnl3YXksIEknbSAoc3Rp bGwpIGhhcHB5IHdpdGggLTAyLg0KDQpZb3Ugc2FpZDoNCiJJbiBnb2luZyB0aHJvdWdoIHdoYXQg YmVjYW1lIC0wMiBvdmVyIHRoZSB3ZWVrZW5kLCBJIGRpc2NvdmVyZWQgc2V2ZXJhbCBjbHVzdGVy cyBvZiB0ZXh0IHRoYXQgYXJlIHNvbWV3aGF0IHJlZHVuZGFudCB3aXRoIGVhY2ggb3RoZXIgb3Ig dGhhdCBtaWdodCBiZSBvcmdhbml6ZWQgdG8gYmUgbW9yZSBlYXNpbHkgZm91bmQgb3IgdW5kZXJz dG9vZC4gIFdoaWxlIEkgZml4ZWQgdGhvc2UgdGhhdCBJIGZvdW5kIGFuZCBmb3Igd2hpY2ggdGhl IGZpeGVzIHNlZW1lZCBzdHJhaWdodGZvcndhcmQsIHRoZXJlIGFyZSBhbG1vc3QgY2VydGFpbmx5 IG90aGVycyBsZWZ0LiAgU3VnZ2VzdGlvbnMgYWJvdXQgd2hhdCBtYXRlcmlhbCBjYW4gc2FmZWx5 IGJlIGVsaW1pbmF0ZWQgYXMgY292ZXJlZCBlbHNld2hlcmUgaW4gZG9jdW1lbnQsIHdoYXQgbWln aHQgYmV0dGVyIGJlIHJlb3JnYW5pemVkIGFuZCBob3csIGFuZCB3aGVyZSBjcm9zcy1yZWZlcmVu Y2VzIGFyZSBuZWVkZWQgd291bGQgYmUgbW9zdCB3ZWxjb21lLiINCg0KSSB0aGluayBpdCdzIG1v c3RseSBmaW5lLiAgTXkgKGxvbmdlciBtYWlsKSBjb21tZW50cyBhcmUgbW9zdGx5IG5pdHBpY2tp bmcuICBJIG1lbnRpb25lZCB0aGF0IEkgdGhpbmsgOS4xIGdvZXMgaW50byBtb3JlIGRldGFpbCB0 aGFuIGlzIHN0cmljdGx5IG5lY2Vzc2FyeSwgYnV0IHRoYXQgbmVlZCBub3QgaG9sZCB1cCB0aGUg ZG9jLiAgSXQgYWxzbyBza2lwcyBvdGhlciBpbnRlcmVzdGluZyBjYXNlcyAoZnVsbC9oYWxmIHdp ZHRoLCBoaXJhZ2FuYS9rYXRha2FuYS9rYW5qaSwgZXRjLikgIElmIEkgd2FzIHRvdWNoaW5nIHRo YXQgcGFydCwgSSdkIHlhbmsgbW9zdCBvZiBpdCBhbmQganVzdCBzYXkgInlvdSBuZWVkIHRvIGJl IGNhcmVmdWwgd2l0aCBhZGRyZXNzZXMiIGFuZCBtYXliZSBsaXN0IGEgZmV3IGV4YW1wbGVzIG9m IHdoeSAobGlrZSB0aGUgYnVsbGV0cykuDQoNCi1TaGF3bg0KDQo= From edainow@ca.afilias.info Mon Jul 12 12:37:09 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A453A68C8 for ; Mon, 12 Jul 2010 12:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4d+M+1RpXkg for ; Mon, 12 Jul 2010 12:37:04 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 203C93A69D3 for ; Mon, 12 Jul 2010 12:37:03 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYOoR-0007e7-9L for ima@ietf.org; Mon, 12 Jul 2010 19:37:11 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=[10.10.68.31]) by smtp.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OYOoR-0001ST-5d for ima@ietf.org; Mon, 12 Jul 2010 19:37:11 +0000 Message-ID: <4C3B6EE4.2000107@ca.afilias.info> Date: Mon, 12 Jul 2010 15:37:08 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] ABNF changes in rfc5336bis-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:37:09 -0000 In section 3.3, when references are updated to RFC 5321, the following will need to be removed qcontent = RFC 5321 does not have qcontent (needed for for Quoted-string). Instead it has the following which needs to be extended for UTF8. Quoted-string = DQUOTE *QcontentSMTP DQUOTE QcontentSMTP = qtextSMTP / quoted-pairSMTP quoted-pairSMTP = %d92 %d32-126 ; i.e., backslash followed by any ASCII ; graphic (including itself) or SPace qtextSMTP = %d32-33 / %d35-91 / %d93-126 ; i.e., within a quoted string, any ; ASCII graphic or space is permitted ; without blackslash-quoting except ; double-quote and the backslash itself. Section 3.3 repeats a lot of what is already in section 4.1.2 of RFC 5321, making it difficult to do a comparison and see what has really changed. It would be a lot simpler just to provide the changes that are needed. So provide ABNF only for the following Atom quoted-pairSMTP qtextSMTP uLet-dig uLdh-str after which all the ABNF in RFC 5321 works. -Ernie From klensin@jck.com Mon Jul 12 13:06:50 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB993A67F7 for ; Mon, 12 Jul 2010 13:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD4Fho9p0OjI for ; Mon, 12 Jul 2010 13:06:42 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 934C23A6C19 for ; Mon, 12 Jul 2010 13:06:31 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYPGo-0002O5-2W; Mon, 12 Jul 2010 16:06:30 -0400 Date: Mon, 12 Jul 2010 16:06:28 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org 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 Subject: Re: [EAI] draft-ietf-eai-frmwrk-4952bis-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:06:50 -0000 --On Monday, July 12, 2010 18:47 +0000 Shawn Steele wrote: >... > Anchor 5 > I'm confused about the timing/process for renaming UTF8SMTPbis > - I guess it needs generated before this doc is published, but > this doc is scheduled to happen before the SMTP doc. Does it > need a name before last call? How late can we defer creating > a name? Based on experience with IDNA2003, we can delay up until the time the first document that actually has to include the string is published. That is some time after IETF Last Call and even after the usual definition of AUTH48 (the final review after the RFC Editor gets through editing). Whether that is desirable or not is a question about which the WG needs to reach some conclusion. My own opinion is that deferring the assignment of the keyword/ extension parameter will help with interoperability by just about guaranteeing that anyone who uses the final keyword will have at least had an opportunity to see the final specs rather than making a guess and jumping the gun. That interacts with the publication plan for 4952bis: In principle, we can do any of the following: (1) Complete WG Last Call with the placeholders for the keyword and the other documents retained, but then let the document sit, not moving toward IETF Last Call until the other documents (or at least some of them) are ready. (2) Complete WG Last Call as above and IETF Last Call. Assuming the IESG approves, let the document sit in the RFC Editor queue in "MISSREF" (normative references missing) and/or IANA-hold (waiting for the keyword to be assigned) states until the other documents are ready. (3) Edit the document to hand wave around the references to the other documents and the precise name of the keyword, process it through the IESG, and publish it. Note that early assignment of the keyword doesn't make much difference to (1) or (2): we still need to wait for the other documents. The main difference between (1) and (2) is where it waits and whether we have IESG confirmation about the document and strategy. While we could decide on (1) in principle, the decision among those three is ultimately up to Alexey. I have great confidence that he will pay careful attention to whatever advice the WG gives, but it is his decision. > 4.3 > "In particular, the use of non-ASCII > message content is an integral part of the MIME > specifications [RFC2045] and does not require these > extensions (although it is compatible with them)." > > My understanding is that MIME isn't required for UTF-8 > UTF8SMTP content. I'm not sure if that's clear here. (Though > I imagine lots of mail is MIME anyway). Yes, it is actually a requirement. You should look through the document and see if it needs to be spelled out more clearly, but for an EAI message to be transmitted, the server must support (and announce) and the client must announce 8BITMIME. And 8BITMIME requires MIME structuring and body parts. Remember that, absent 8BITMIME, you can't transmit UTF-8 without some flavor of ASCII encoding and that without MIME, encoded words are a non-starter. We more or less made the same decision that was made about more basic kinds of messages and SMTP extensions that involve advanced features: you want the advanced stuff, supporting MIME is a prerequisite. Non-MIME messages are pretty much bound to 821/822. > 6.1 bullet 1: > "use of ASCII-compatible (ACE) > encoding [RFC3492] [RFC5890] on the right hand side is > discouraged" > > This is fine for this doc, however in an EAI mail, punycode > should be forbidden. So I'd like to see "MUST NOT", or at > least "SHOULD NOT" have punycode on the RHS if the LHS has > non-ASCII in the UTF8SMTP spec. (Which qualifies as > "discouraged", which is stated here). This is another discussion we had the first time around. It may not be sensible to try to prohibit it because an A-label is just another ASCII name. In other words, at least under IDNA2003 (to which 4952 was written), if the domain-part is an ASCII string, an EAI application really doesn't need to know whether that string has the special properties of an A-label or whether it is just an ASCII string. IDNA2008 changes things a bit because it fairly strongly encourages (but does not require) applications that are about to look up an A-label to validate it, which just about requires conversion to a U-label. I can see some basis there for a "SHOULD NOT", but I'd like to hear from others and see a slightly stronger justification than an assertion. Put differently, it is not clear to me that having A-labels in the domain-part is harmful. Stupid and ugly, yes, but not necessarily harmful. > 6.1 bullet 4. "no other code pages" > Addresses my earlier question, and I'm fine with this text, > although, in practice, it's sort of like closing the barn door > after the animals have left. :) Not sure how much non-ASCII text in non-UTF-8 charsets have actually been used in email headers. People thinking they want them is another matter, but a non-trivial number of MTAs and anti-spam filters/evaluators will apparently reject such messages as bogus or worse. So, if you think the animals are out of the barn, I'd be very interested in a census of the relevant animals. That said, I don't think it will change this provision. To paraphrase a colleague of ours, the late thing we need is to introduce more places where people can validly use funky encodings. >... > [anchor15] - Yao's been working on documents regarding the > choice of addresses, which helps, I think. Though an > interesting problem, I don't think we need this note. Some of > the most interesting parts. (How does my client learn that > Shawn-Unicode and ShawnSte are the same address?, and how do I > enable the user to choose which address to send with) are > probably more usability type things. I'm not sure we need to > provide much more than general address selection/ways we > expect them to be used guidelines. > > Anyway, I'd remove [anchor15] in the interest of not holding > up the doc. I think that 9 adequately captures the idea that > app developers need to consider User Interface and > Configuration challenges. Good. I'd like to hear from others, but this is consistent with my personal instincts. > 9.1 - The charter has the "addresses" spec, I'm not sure you > need to go into this much depth here. (don't see that it > hurts either) The answer may depend on when we want to push this document out the door and in what state. See above. > * Normalization - I think the key point is that servers should > be expected to see addresses in different normalization (or > unnormalized) forms, and they should be prepared to normalize > them. I think it is less important for us to specify that > they must use Form C. (They could achieve the same behavior > if they used NFD internally). Not quite, I think. We need to do the case analysis carefully here given that NFC sometimes decomposes (NFD never composes) and that this interacts with the 5321 limits on string lengths. > Editorial: "Stated differently" restates the 1st bullet, but > then lists two new concepts that were alluded to in the text > earlier, but not the bullets. (so it's not really "stating > differently".) I'd remove "stated differently, and let the > C0/C1 and "other kinds of punctionation" be top level bullets: > > o In general, it is wise to support addresses in > Normalized form. Servers should normalize with a > consistent Unicode normalization form. Compatibility > forms may only be appropriate in unusual circumstances. > > o It may be wise to support other forms of the same > local-part string, either as aliases or by normalization > of strings reaching the delivery server, in the event > that the sender does not send the strings in normalized > form. > > o C0 (and presumably C1) controls (see The Unicode Standard > [Unicode52]) are prohibited, the first in RFC 5321 > and the second by an obvious extension from it > [RFC5198]. > > o Other kinds of punctuation, spaces, etc., are risky > practice. Perhaps they will work, and SMTP receiver > code is required to handle them, but creating > dependencies on them in mailbox names that are chosen > is usually a bad practice and may lead to > interoperability problems. I like this organization. I'd like to hear from others before I start making changes (which will not get into the queue today in any event -- see below). > 12 - Security considerations. > I think this does a nice job of balancing people's concerns > about homographs without becoming too unreasonable, and I > wouldn't change it :) *IF* something did have to change, it's > worth recognizing that email local parts and domain names have > different problems. It's very unclear whether I'm supposed to > be ShawnSte@microsoft.com or, maybe, shawnst (who gets most of > my typoe'd mail :)) It's way worse for places like live mail > and gmail where people end up as shawn1234 and shawn6666. > Those are quite confusable regardless of script. In short, I > think that enabling Unicode does not increase the risk for an > enterprise that controls their own assignments (as long as > they're careful). And, I think there's no further risk for > the large places that already have quite confusing names. As > said, I think this doc does a decent job of balancing the > paranoia without itself becoming a fear monger. Actually, in some parts of the world and at the second and third level, foo123, foo124, and foo321 are all seen as domain name labels, so perhaps the situations are not quite as different as you suggest. But I think --and you seem to have confirmed-- that we could spend a lot of effort tuning that text to make it only slightly better. So, unless others have objections or concerns, we are probably at a good stopping point. > In summary, I can live with the document as it is :) I have > asked the Exchange folks to review some of the parts I'm less > familiar with, but I don't expect major concerns. Thanks. For planning purposes, I'm traveling tomorrow and Wednesday. I'm going to try to read and respond to Jason's note, but I'm pretty much out of bandwidth for this document between now and the posting deadline, so the odds of my being able to get a -03 up before IETF are small to none. My going silent in a little while isn't indifference, it is just IAB and "day job" priorities catching up with me. john From jyee@ca.afilias.info Mon Jul 12 13:18:33 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8F03A6A00 for ; Mon, 12 Jul 2010 13:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf6P6ZZQEqJ8 for ; Mon, 12 Jul 2010 13:18:32 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 4C30B3A69F0 for ; Mon, 12 Jul 2010 13:18:32 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYPSZ-0008I0-3h; Mon, 12 Jul 2010 20:18:39 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYPSY-0006Tt-9F; Mon, 12 Jul 2010 20:18:39 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: Date: Mon, 12 Jul 2010 16:18:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96281E96-E78C-46B4-BAF6-7146BDDAFBD3@ca.afilias.info> References: To: John C Klensin X-Mailer: Apple Mail (2.1081) Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-frmwrk-4952bis-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:18:33 -0000 On 2010-07-12, at 4:06 PM, John C Klensin wrote: [snip] >=20 >> ... >> [anchor15] - Yao's been working on documents regarding the >> choice of addresses, which helps, I think. Though an >> interesting problem, I don't think we need this note. Some of >> the most interesting parts. (How does my client learn that >> Shawn-Unicode and ShawnSte are the same address?, and how do I >> enable the user to choose which address to send with) are >> probably more usability type things. I'm not sure we need to >> provide much more than general address selection/ways we >> expect them to be used guidelines. >>=20 >> Anyway, I'd remove [anchor15] in the interest of not holding >> up the doc. I think that 9 adequately captures the idea that >> app developers need to consider User Interface and >> Configuration challenges. >=20 > Good. I'd like to hear from others, but this is consistent with > my personal instincts. >=20 =20 Just want to make quick reply to anchor15. I am in favour to remove it = too. They are more into product design than protocol design. Joseph [snip]= From edainow@ca.afilias.info Mon Jul 12 14:17:16 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D3F3A697A for ; Mon, 12 Jul 2010 14:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaFT-ejxKSC6 for ; Mon, 12 Jul 2010 14:17:15 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id DDF6A3A6878 for ; Mon, 12 Jul 2010 14:17:11 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYQNL-0000yS-93 for ima@ietf.org; Mon, 12 Jul 2010 21:17:19 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=[10.10.68.31]) by smtp.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OYQNL-00083s-8i for ima@ietf.org; Mon, 12 Jul 2010 21:17:19 +0000 Message-ID: <4C3B865C.2040503@ca.afilias.info> Date: Mon, 12 Jul 2010 17:17:16 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:17:16 -0000 A message to mailbox will bounce if the UTF8SMTPbis extension is not supported by an MTA. According to rfc5336bis, this will not be done by an MTA. This is not obvious behavior, since it is fairly trivial to do a punycode conversion of the domain part so that the address is all ASCII. Many users are familiar with web browsers that do this conversion and may expect similar behavior in email. To reinforce that this is a failure case, we should add the following example to section 4.4 of rfc5335bis-00. ; message will bounce if UTF8SMTPbis extension is not supported. An MTA will not convert ; the domain part to ASCII, but this may be done by an MUA or submission server (MSA). -Ernie From edainow@ca.afilias.info Mon Jul 12 14:57:20 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F44E3A67E5 for ; Mon, 12 Jul 2010 14:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.965 X-Spam-Level: X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJCtk9NVAulf for ; Mon, 12 Jul 2010 14:57:19 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id B1C9C3A67C0 for ; Mon, 12 Jul 2010 14:57:19 -0700 (PDT) Message-ID: <4C3B8FC0.7050900@ca.afilias.info> Date: Mon, 12 Jul 2010 17:57:20 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ima@ietf.org References: <4C3B6EE4.2000107@ca.afilias.info> In-Reply-To: <4C3B6EE4.2000107@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: Re: [EAI] ABNF changes in rfc5336bis-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:57:20 -0000 On 7/12/2010 3:37 PM, Ernie Dainow wrote: > In section 3.3, when references are updated to RFC 5321, the following > will need to be removed > > qcontent = > > RFC 5321 does not have qcontent (needed for for Quoted-string). Instead > it has the following which needs to be extended for UTF8. > > Quoted-string = DQUOTE *QcontentSMTP DQUOTE > > QcontentSMTP = qtextSMTP / quoted-pairSMTP > > quoted-pairSMTP = %d92 %d32-126 > ; i.e., backslash followed by any ASCII > ; graphic (including itself) or SPace > > qtextSMTP = %d32-33 / %d35-91 / %d93-126 > ; i.e., within a quoted string, any > ; ASCII graphic or space is permitted > ; without blackslash-quoting except > ; double-quote and the backslash itself. > > Section 3.3 repeats a lot of what is already in section 4.1.2 of RFC > 5321, making it difficult to do a comparison and see what has really > changed. It would be a lot simpler just to provide the changes that are > needed. So provide ABNF only for the following > > Atom > quoted-pairSMTP > qtextSMTP > uLet-dig > uLdh-str > > after which all the ABNF in RFC 5321 works. > > It seems like rfc5335bis uses this style. It only replaces definitions that need to be changed and leaves the others from RFC5322 without defining a variant. For example, in section 4.4 mailbox = name-addr / addr-spec / utf8-addr-spec In some cases where a UTF8 variant is necessary, rfc5335bis uses a naming convention by defining utf8-Label as a variant of Label. By comparison, in rfc5336bis, UTF8 variants seem to be named as uLabel. I think the former style is preferable. Now that we are on standards track, I think we should be striving for more consistency across all the documents. -Ernie From klensin@jck.com Mon Jul 12 15:39:48 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C943A6844 for ; Mon, 12 Jul 2010 15:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xchYahzWibPY for ; Mon, 12 Jul 2010 15:39:46 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 5465E3A69F7 for ; Mon, 12 Jul 2010 15:39:46 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYRf7-0008jw-1p; Mon, 12 Jul 2010 18:39:45 -0400 Date: Mon, 12 Jul 2010 18:39:43 -0400 From: John C Klensin To: Jason Nelson , Shawn Steele , Joseph Yee Message-ID: In-Reply-To: <6CE0D5FA2297784CB7A6F5F09865C895307F8353@DF-M14-05.exchange.corp.microsoft.com> References: <6CE0D5FA2297784CB7A6F5F09865C895307F8353@DF-M14-05.exchange.corp .microsoft.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 Cc: ima@ietf.org Subject: [EAI] Mixed addresses (was: Re: Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02)) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:39:48 -0000 --On Monday, July 12, 2010 18:58 +0000 Jason Nelson wrote: >... > In the current design, with a message destined to two > recipients, A and B, A supports UTF8 and B does not - what > should B's P2 content look like? I get that the RFC > specifically deals with addresses in transit, and that we > should not be mucking about with messages when not the > submission server, but resolving how the mail goes to both the > guys in the US and the your business partner in Taiwan with > both being able to reply across the board, that's giving me a > few headaches. I wonder how many others on this mailing list are familiar enough with that other Standard messaging architecture to know what "P2 Content" is? :-) In any event, it is these mixed cases that are the reason why many of us hoped that we could devise an in-transit downgrading mechanism that would be easy to implement and work universally in a predictable and interoperable way. There are, I believe, three such cases, each with a slightly different scenario: (i) Mixed ASCII and non-ASCII destination (forward-pointing) addresses with the ASCII address sites presumably being non-EAI-capable, as in your example. (ii) ASCII-only destination addresses, some of which are EAI-capable, and a backward-pointing ("sender") non-ASCII address. (iii) Mailing lists with mixed ASCII and non-ASCII addresses. Even if it is fully deliverable, with all information preserved in headers, replying to a message in one of these categories can easily create one of the others --and a less-tractable situation. For purposes of that classification, ASCII-local-part@Punycoded-IDN is an ASCII-only address. If one had code that immediately converted IDN A-labels into U-label form, there are an additional set of cases having to do with systems that are IDNA-aware but perhaps not EAI-aware. Anyway, downgrading failed. We could review/ debate degrees of failure (and waste a lot of time), but it was clear that we weren't going to get the hoped-for predictability as soon as we discovered that messages for which alternate ASCII addresses existed for some of the non-ASCII ones but not all of them. Relative to your example, please note the relationship between "one ASCII destination, one non-ASCII destination" and "two non-ASCII destinations, one with an alternate address available and the other without one". But the problem really isn't new. Ignore the addresses for a moment and assume that A is not only UTF8-capable but prefers message content in Lower Slobbovian. B can handle only ASCII and English. The sender, miraculously, can speak and write both Lower Slobbovian and English. Now, what is to be sent? (i) If the message content is sent in English, A will be unhappy and may reply in Lower Slobbovian with parts of the original message copied. B will receive the message from the sender with everything intact and comprehensible. When A replies, the reply message will be unreadable to B will not be able to read (even though it can be received) and that may be displayed as a low of question marks (since B presumably doesn't have Lower Slobbovian fonts installed and might not even be able to handle "text/plain; charset=utf8"). (ii) If the message content is sent in Lower Slobbovian, B is out of luck. The original message will be received but will be incomprehensible -- only the "From" and "To" header fields and their envelope counterparts are likely to be useful and readable. And any reply from A won't even contain traces of English/ASCII. (iii) If the message is sent with both charsets (ASCII and UTF8) and languages (English and Lower Slobbovian) using multipart/alternative... Well, we had high hopes for that one, but it was never as useful as expected (and is not supported well, unlike the use of multipart/alternative for text and HTML body parts). But assume it worked as intended and think about what happens to A and B. Each sees the message in her preferred language and characters, is only vaguely aware (if at all) that the other language and characters are there. So far, so good. Now A replies to the message she is seeing (a Lower Slobbovian one), in the language she sees. And B responds in the language she is seeing (English) in that language. In a way, this is the worst scenario of all because a slight change in the example results in A and B seeing content in languages that the other one can't read at all. The address case affects whether messages that might be unreadable (or that would lead to unreadable replies) can be delivered or reflected properly in headers, but it doesn't change things as compared to those nasty content example. And, while there are some advantages of having messages the user can't read delivered (as long as they can be rendered, one might be able to find a translator), they are pretty marginal in most cases... especially when they cannot be rendered. I think the bottom line is: (1) Internationalization is a messy business that really is not going to be helpful other than for communication within language communities. EAI is no exception in that regard. (2) A decision to send messages in a possible-mixed environment wrt addressing, like a decision to send messages in a language that some recipients might not be able to read (or even render) is high-risk -- especially in a world in which a popular source of high spam likelihood scores is "message in a language or script I don't normally read or can't read at all". (3) If someone is communicating internationally -- with people who use multiple languages and writing systems -- the conservative approach is going to be to use ASCII addresses and least-common-denominator languages and scripts. EAI is going to work best within a language community where all (or almost all) of the systems are EAI-aware, capable of rendering the relevant script, and all of the addresses are in that script too, regardless of how they are encoded. While we may need to do some education, those principles are user-level common sense even if they are lots better understood about content than about addresses today. We might or might not be able to reinforce the education with automated tools (and might or might not want to). But those users who violate the principles will sooner or later get burned with messages that either don't reach all recipients or replies to those messages that are incomprehensible. Like small children and hot stoves, few of them will need to repeat the experience very many times. I wish I had a more optimistic answer. But we need to remember that every step we take toward a non-ASCII/ non-English (or at least non-Western-European-language) Internet is a step that enables some users and language communities at the price of reducing the degree to which everyone connected to the Internet can communicate with all the others. IMO, that is a good tradeoff, but not one that is without costs. FWIW, we've had variations on the above conversation/ comments/ analysis enough times that maybe it should be written into a more public and permanent place. If there is WG consensus that it should go into 4952bis, I'm ok with that although I'd appreciate it if someone else would suggest text. If not, we should think about other places and opportunities. john From Shawn.Steele@microsoft.com Mon Jul 12 18:22:08 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1C93A69B6 for ; Mon, 12 Jul 2010 18:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.401 X-Spam-Level: X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4yh19KzwOBW for ; Mon, 12 Jul 2010 18:22:06 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 842B23A6879 for ; Mon, 12 Jul 2010 18:22:06 -0700 (PDT) Received: from TK5EX14CASC129.redmond.corp.microsoft.com (157.54.52.7) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 18:22:14 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14CASC129.redmond.corp.microsoft.com ([157.54.52.7]) with mapi id 14.01.0180.004; Mon, 12 Jul 2010 18:22:13 -0700 From: Shawn Steele To: John C Klensin , Jason Nelson , Joseph Yee Thread-Topic: Mixed addresses (was: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02)) Thread-Index: AQHLIhM4gF5tbhj1l0SytrsTRVAKCZKuD2lw Date: Tue, 13 Jul 2010 01:22:22 +0000 Message-ID: References: <6CE0D5FA2297784CB7A6F5F09865C895307F8353@DF-M14-05.exchange.corp .microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Mixed addresses (was: Re: Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02)) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 01:22:08 -0000 > I wonder how many others on this mailing list are familiar enough with th= at other Standard messaging architecture to know > what "P2 Content" is? :-) I had to ask Jason :) - Shawn From Shawn.Steele@microsoft.com Mon Jul 12 18:52:32 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F62D3A6A1E for ; Mon, 12 Jul 2010 18:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz5Ss0gTWeog for ; Mon, 12 Jul 2010 18:52:31 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1555F3A6A1D for ; Mon, 12 Jul 2010 18:52:30 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 18:52:39 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0180.004; Mon, 12 Jul 2010 18:52:38 -0700 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] draft-ietf-eai-frmwrk-4952bis-02 Thread-Index: AQHLIf3MmKiLYD9YXEOjQ8fGN4sByJKuELnw Date: Tue, 13 Jul 2010 01:52:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] draft-ietf-eai-frmwrk-4952bis-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 01:52:32 -0000 > The main difference between (1) and (2) is where it waits I would prefer that the document wait in the step as close to final as poss= ible (eg: 2 if I understand correctly). Or be a bit handwavy and don't hol= d up this doc. Handwavey has another advantage in that it forces someone t= o look at the actual standard instead of just thinking "oh, support UTF-8, = check". > and the client must announce 8BITMIME. I guess I missed where the client must use 8BITMIME. I'd thought that the = server announcing 8BITMIME would be sufficient to guarantee 8bitness, and t= hat MIME structuring wouldn't necessarily be required. It's not quite clea= r to me why MIME structure would be necessary for a simple "hi there" messa= ge if the server announced UTF8SMTP? Clearly UTF8SMTP is permitting non-AS= CII? > 6.1 bullet 1: > "use of ASCII-compatible (ACE) > encoding [RFC3492] [RFC5890] on the right hand side is > discouraged" I'm happy with it for this doc. I think servers have to recognize it anywa= y (since the sender might not be EAI aware), however an EAI aware system sh= ould recognize ACE, so presumably it should be able to send clean UTF-8 w/o= ACE. It's not a big deal, but mostly I would like to try to keep the stuf= f on the wire "clean", which entails trying to forbid the clients from bein= g lazy :) So however much we can discourage laziness is what I'd like. MUS= T NOT may be too strong. > 6.1 bullet 4. "no other code pages" > Addresses my earlier question, and I'm fine with this text, although,=20 > in practice, it's sort of like closing the barn door after the animals=20 > have left. :) > So, if you think the animals are out of the barn, I'd be very > interested in a census of the relevant animals. I believe really, really, really old copies of sendmail :) (& maybe it was= a funky sco version as well, I can't speak to it's pedigree). > That said, I don't think it will change this provision. That's fine. Just saying that adding "no other code pages" isn't going to = fix any two decade old system out there (shudder) that depends on this. =20 > > 9.1 - The charter has the "addresses" spec, I'm not sure you need to=20 > > go into this much depth here. (don't see that it hurts either) > The answer may depend on when we want to push this document out the door = and in what state. See above. Sorry, no clue which "above". Hear from others? That's fine. =20 > > * Normalization - I think the key point is that servers should be=20 > Not quite, I think. If NFC(x) =3D=3D NFC(y), then NFD(x) =3D=3D=3D NFD(y), so equality is fine. > We need to do the case analysis carefully here given that NFC > sometimes decomposes (NFD never composes) and that this > interacts with the 5321 limits on string lengths. I'd missed the length thing, however my feeling is that people will send NF= D (or something neither NFC nor NFD) on the wire, whether or not we think t= hat's smart. So, either way, a server really should be applying either NFC= or NFD so they can appropriately match. At that point I really don't care= what their internal architecture is like, I think. Obviously if I want to= send NFD on the wire and it's too long, then I'm stuck, but we already hav= e been SHOULDing NFC on the wire. Anyway, I don't really care, I'd be using NFC anyway if I was building some= thing. I just wonder if it might be easier for some platforms to use a nat= ive NFD internally, and whether we were overly specifying what they might d= o internally. > Actually, in some parts of the world and at the second and third level, f= oo123, > foo124, and foo321 are all seen as domain name labels,=20 Same reasoning though, when you see those, it's because there're a billion = people getting free blogs or whatever, and then the ASCII gets confusable a= s well. I really think there's too much fear about homographs (see http://= blogs.msdn.com/b/shawnste/archive/2009/11/23/the-fud-of-idn-and-homographs.= aspx ), however since that's the question managers like to ask, it's good t= o address it here. > But I think --and you seem to have confirmed-- > that we could spend a lot of effort tuning that text to make it only slig= htly better. > So, unless others have objections or concerns, we are probably at a good= stopping point. Agreed :) =20 -Shawn From Shawn.Steele@microsoft.com Mon Jul 12 19:00:53 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2FC3A6A1E for ; Mon, 12 Jul 2010 19:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.107 X-Spam-Level: X-Spam-Status: No, score=-10.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dO42Eae6zfO for ; Mon, 12 Jul 2010 19:00:53 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1B82E3A6A1D for ; Mon, 12 Jul 2010 19:00:53 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 12 Jul 2010 19:01:01 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0180.004; Mon, 12 Jul 2010 19:00:59 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: mail bounce versus punycode conversion Thread-Index: AcsiLn+iBMw8Co1uQbeK0kGjkrO8gg== Date: Tue, 13 Jul 2010 02:01:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:00:54 -0000 In practice would a present-day server echo the non-ASCII part in the error= ? (I'm unfamiliar with what normally happens here). Seems like a reasonable, and probably important, example, but there're lots= of combinations possible. ("non-ASCII DISPLAY_NAME" , etc.) -Shawn ------------------------------ Message: 5 Date: Mon, 12 Jul 2010 17:17:16 -0400 From: Ernie Dainow Subject: [EAI] mail bounce versus punycode conversion To: ima@ietf.org Message-ID: <4C3B865C.2040503@ca.afilias.info> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed A message to mailbox will bounce if the UTF8SMTPbis exten= sion is not supported by an MTA. According to rfc5336bis, this will not be = done by an MTA. This is not obvious behavior, since it is fairly trivial to= do a punycode conversion of the domain part so that the address is all ASC= II. Many users are familiar with web browsers that do this conversion and m= ay expect similar behavior in email. To reinforce that this is a failure case, we should add the following examp= le to section 4.4 of rfc5335bis-00. ; message will bounce if UTF8SMTPbis extension is not supported. A= n MTA will not convert ; the domain part to ASCII, but this may be done by an MUA or subm= ission server (MSA). -Ernie From yaojk@cnnic.cn Mon Jul 12 19:42:28 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EEA3A68E3 for ; Mon, 12 Jul 2010 19:42:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[AWL=1.139, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2whi8BPKVsc for ; Mon, 12 Jul 2010 19:42:27 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 035FE3A68BE for ; Mon, 12 Jul 2010 19:42:26 -0700 (PDT) Received: (eyou send program); Tue, 13 Jul 2010 10:42:30 +0800 Message-ID: <478988950.15549@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 13 Jul 2010 10:42:30 +0800 Message-ID: <4D5CBCFBF1904925A587083113CFEF60@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , "Shawn Steele" , "Joseph Yee" , References: <478961931.12964@cnnic.cn> Date: Tue, 13 Jul 2010 10:42:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:42:28 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJTaGF3biBTdGVlbGUiIDxTaGF3bi5TdGVlbGVAbWljcm9z b2Z0LmNvbT47ICJKb3NlcGggWWVlIiA8anllZUBjYS5hZmlsaWFzLmluZm8+OyA8aW1hQGlldGYu b3JnPg0KU2VudDogVHVlc2RheSwgSnVseSAxMywgMjAxMCAzOjEyIEFNDQpTdWJqZWN0OiBSZTog W0VBSV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1lYWktZnJtd3JrLTQ5NTJiaXMtMDENCg0KDQoN Cj4+IFJlOiB0cmFuc2NyaXB0aW9ucywgSSB0aGluayBJIHdhcyBjb25mdXNpbmcuICBXZSdyZQ0K Pj4gZXhwZWN0aW5nIGFkbWlucy91c2VycyB0byBjcmVhdGUgYSBVbmljb2RlIGFkZHJlc3MgZm9y IHRoZWlyDQo+PiBtYWlsYm94LCBhbmQsIGxpa2VseSwgYW4gQVNDSUkgYWRkcmVzcywgd2hpY2gs IGluIHNvbWUgY2FzZXMsDQo+PiBpcyBwcm9iYWJseSBhIHRyYW5zY3JpcHRpb24gY2hvc2VuIGJ5 IHRoZSBhZG1pbiBvciB1c2VyLg0KPj4gKEVnOiBUYXJlaywgbXkgbWFuYWdlciwgaW5zdGVhZCBv ZiBob3dldmVyIHRoYXQncyBzcGVsbGVkIGluDQo+PiBBcmFiaWMpLg0KPiANCj4gSSB0aGluayB0 aGF0LCBhcyB5b3UgbW92ZSBhcm91bmQgdGhlIHdvcmxkIGFuZCBsb29rIGF0IG5hbWVzDQo+IHdy aXR0ZW4gaW4gUm9tYW4gY2hhcmFjdGVycyBmb3IgcGVvcGxlIHdob3NlIG5hdGl2ZSBsYW5ndWFn ZQ0KPiBpc24ndCBub3JtYWxseSB3cml0dGVuIHRoYXQgd2F5LCB5b3Ugd2lsbCBmaW5kIHRyYW5z Y3JpcHRpb25zLA0KPiB0cmFuc2NyaXB0aW9ucywgdHJhbnNsYXRpb25zLCBhbmQgbW9yZSBvciBs ZXNzIGZhbmNpZnVsDQo+IGFsdGVybmF0aXZlcyBpbiBzb21lIHByb3BvcnRpb25zLiAgTm90ZSB0 aGF0LCBzdHJpY3RseSBzcGVha2luZywNCj4gQ2hpbmVzZSBjYW5ub3QgYmUgdHJhbnNsaXRlcmF0 ZWQsIG9ubHkgdHJhbnNjcmliZWQgKEphcGFuZXNlDQo+IEthbmEgICAgIGNhbiBiZSB0cmFuc2xp dGVyYXRlZCBpbnRvIFJvbWFuamkpLiAgSWYgeW91IHRha2UgdGhlDQo+IHRocmVlIGFjdGl2ZSBw YXJ0aWNpcGFudHMgaW4gdGhlIFdHIHdobyBhcmUgb2YgQ2hpbmVzZSBkZXNjZW50DQo+IGFzIGV4 YW1wbGVzLCB3ZSBzZWUgKEkgaG9wZSB0aGV5IHdpbGwgY29ycmVjdCBtZSBpZiBJIGhhdmUgdGhp cw0KPiB3cm9uZyk6DQo+IA0KPiBvIEpvc2VwaCAocHJvYmFibHkgbm90IGEgdHJhbnNjcmlwdGlv bio7IEkgZG9uJ3Qga25vdw0KPiB3aGV0aGVyIGl0IGlzIGEgdHJhbnNsYXRpb24gb2Ygc29tZXRo aW5nIGVsc2Ugb3Igbm90KQ0KPiBvIEppYW5rYW5nIChJIHByZXN1bWUgYSB0cmFuc2NyaXB0aW9u KjsgYnV0IGhlIGhhcw0KPiBhbHNvIHNvbWV0aW1lcyB1c2VkICJIZWFsdGgiLCB3aGljaCBJIHVu ZGVyc3RhbmQgdG8gYmUgYQ0KPiB0cmFuc2xhdGlvbikNCj4gbyBYaWFvRG9uZyAoYSB0cmFuc2Ny aXB0aW9uKjsgYnV0IGhlIHNvbWV0aW1lcyBhbHNvDQo+IGhhcyB1c2VkICJTaGVsZG9uIiwgd2hp Y2ggc291bmRzIHNvbWV3aGF0IGFsaWtlIGJ1dCBpdA0KPiBuZWl0aGVyIGEgdHJhbnNsYXRpb24g b3IgdHJhbnNjcmlwdGlvbikNCj4gDQo+ICogTm90ZSB0aGF0IHdoaWxlIEhhbnl1IFBpbnlpbiBp cyBub3cgdGhlIHN0YW5kYXJkDQo+IHRyYW5zY3JpcHRpb24gc3lzdGVtIGluIHRoZSBQUkMgYW5k IHNvbWUgb3RoZXIgcGxhY2VzLA0KPiB0aGVyZSBhcmUgYSBodWdlIG51bWJlciBvZiBtdXR1YWxs eS1pbmNvbXBhdGlibGUNCj4gdHJhbnNjcmlwdGlvbiBzeXN0ZW1zIGZvciBDaGluZXNlLiAgQW5k LCBvZiBjb3Vyc2UsDQo+IHRyYW5zY3JpcHRpb24gc3lzdGVtcywgYnkgZGVmaW5pdGlvbiwgcmVm bGVjdCBzcG9rZW4NCj4gbGFuZ3VhZ2VzLCBub3Qgd3JpdHRlbiBvbmVzLg0KPiANCg0KeW91IGtu b3cgbW9yZSB0aGFuIG1lIGV2ZW4gSSBhbSBhIENoaW5lc2UuDQp0aGFua3MuDQo= From yaojk@cnnic.cn Mon Jul 12 19:51:42 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA54E3A6965 for ; Mon, 12 Jul 2010 19:51:42 -0700 (PDT) X-Quarantine-ID: <8eh5qI7G6uhp> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.406 X-Spam-Level: * X-Spam-Status: No, score=1.406 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eh5qI7G6uhp for ; Mon, 12 Jul 2010 19:51:41 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id EB2833A67AE for ; Mon, 12 Jul 2010 19:51:40 -0700 (PDT) Received: (eyou send program); Tue, 13 Jul 2010 10:51:49 +0800 Message-ID: <478989509.01083@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 13 Jul 2010 10:51:49 +0800 Message-ID: From: "Jiankang YAO" To: "Ernie Dainow" , References: <4C3B6EE4.2000107@ca.afilias.info> <478971853.19760@cnnic.cn> Date: Tue, 13 Jul 2010 10:51:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] ABNF changes in rfc5336bis-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:51:42 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVybmllIERhaW5vdyIgPGVk YWlub3dAY2EuYWZpbGlhcy5pbmZvPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBKdWx5IDEzLCAyMDEwIDU6NTcgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBBQk5GIGNoYW5nZXMg aW4gcmZjNTMzNmJpcy0wMA0KDQoNCj4gT24gNy8xMi8yMDEwIDM6MzcgUE0sIEVybmllIERhaW5v dyB3cm90ZToNCj4+IEluIHNlY3Rpb24gMy4zLCB3aGVuIHJlZmVyZW5jZXMgYXJlIHVwZGF0ZWQg dG8gUkZDIDUzMjEsIHRoZSBmb2xsb3dpbmcNCj4+IHdpbGwgbmVlZCB0byBiZSByZW1vdmVkDQo+ Pg0KPj4gICBxY29udGVudCA9IDxTZWUgU2VjdGlvbiAzLjIuNSBvZiBSRkMgMjgyMj4NCj4+DQo+ PiBSRkMgNTMyMSBkb2VzIG5vdCBoYXZlIHFjb250ZW50IChuZWVkZWQgZm9yIGZvciBRdW90ZWQt c3RyaW5nKS4gSW5zdGVhZA0KPj4gaXQgaGFzIHRoZSBmb2xsb3dpbmcgd2hpY2ggbmVlZHMgdG8g YmUgZXh0ZW5kZWQgZm9yIFVURjguDQo+Pg0KPj4gICBRdW90ZWQtc3RyaW5nICA9IERRVU9URSAq UWNvbnRlbnRTTVRQIERRVU9URQ0KPj4NCj4+ICAgUWNvbnRlbnRTTVRQICAgPSBxdGV4dFNNVFAg LyBxdW90ZWQtcGFpclNNVFANCj4+DQo+PiAgIHF1b3RlZC1wYWlyU01UUCAgPSAlZDkyICVkMzIt MTI2DQo+PiAgICAgICAgICAgICAgICAgICAgOyBpLmUuLCBiYWNrc2xhc2ggZm9sbG93ZWQgYnkg YW55IEFTQ0lJDQo+PiAgICAgICAgICAgICAgICAgICAgOyBncmFwaGljIChpbmNsdWRpbmcgaXRz ZWxmKSBvciBTUGFjZQ0KPj4NCj4+ICAgcXRleHRTTVRQICAgICAgPSAlZDMyLTMzIC8gJWQzNS05 MSAvICVkOTMtMTI2DQo+PiAgICAgICAgICAgICAgICAgIDsgaS5lLiwgd2l0aGluIGEgcXVvdGVk IHN0cmluZywgYW55DQo+PiAgICAgICAgICAgICAgICAgIDsgQVNDSUkgZ3JhcGhpYyBvciBzcGFj ZSBpcyBwZXJtaXR0ZWQNCj4+ICAgICAgICAgICAgICAgICAgOyB3aXRob3V0IGJsYWNrc2xhc2gt cXVvdGluZyBleGNlcHQNCj4+ICAgICAgICAgICAgICAgICAgOyBkb3VibGUtcXVvdGUgYW5kIHRo ZSBiYWNrc2xhc2ggaXRzZWxmLg0KPj4NCj4+IFNlY3Rpb24gMy4zIHJlcGVhdHMgYSBsb3Qgb2Yg d2hhdCBpcyBhbHJlYWR5IGluIHNlY3Rpb24gNC4xLjIgb2YgUkZDDQo+PiA1MzIxLCBtYWtpbmcg aXQgZGlmZmljdWx0IHRvIGRvIGEgY29tcGFyaXNvbiBhbmQgc2VlIHdoYXQgaGFzIHJlYWxseQ0K Pj4gY2hhbmdlZC4gSXQgd291bGQgYmUgYSBsb3Qgc2ltcGxlciBqdXN0IHRvIHByb3ZpZGUgdGhl IGNoYW5nZXMgdGhhdCBhcmUNCj4+IG5lZWRlZC4gU28gcHJvdmlkZSBBQk5GIG9ubHkgZm9yIHRo ZSBmb2xsb3dpbmcNCj4+DQo+PiAgIEF0b20NCj4+ICAgcXVvdGVkLXBhaXJTTVRQDQo+PiAgIHF0 ZXh0U01UUA0KPj4gICB1TGV0LWRpZw0KPj4gICB1TGRoLXN0cg0KPj4NCj4+IGFmdGVyIHdoaWNo IGFsbCB0aGUgQUJORiBpbiBSRkMgNTMyMSB3b3Jrcy4NCj4+DQo+Pg0KPiBJdCBzZWVtcyBsaWtl IHJmYzUzMzViaXMgdXNlcyB0aGlzIHN0eWxlLiBJdCBvbmx5IHJlcGxhY2VzIGRlZmluaXRpb25z IA0KPiB0aGF0IG5lZWQgdG8gYmUgY2hhbmdlZCBhbmQgbGVhdmVzIHRoZSBvdGhlcnMgZnJvbSBS RkM1MzIyIHdpdGhvdXQgDQo+IGRlZmluaW5nIGEgdmFyaWFudC4gRm9yIGV4YW1wbGUsIGluIHNl Y3Rpb24gNC40DQo+IA0KPiAgICAgbWFpbGJveCA9IG5hbWUtYWRkciAvIGFkZHItc3BlYyAvIHV0 ZjgtYWRkci1zcGVjDQo+IA0KPiBJbiBzb21lIGNhc2VzIHdoZXJlIGEgVVRGOCB2YXJpYW50IGlz IG5lY2Vzc2FyeSwgcmZjNTMzNWJpcyB1c2VzIGEgDQo+IG5hbWluZyBjb252ZW50aW9uIGJ5IGRl ZmluaW5nICAgdXRmOC1MYWJlbCBhcyBhIHZhcmlhbnQgb2YgTGFiZWwuIEJ5IA0KPiBjb21wYXJp c29uLCBpbiByZmM1MzM2YmlzLCBVVEY4IHZhcmlhbnRzIHNlZW0gdG8gYmUgbmFtZWQgYXMgdUxh YmVsLiBJIA0KPiB0aGluayB0aGUgZm9ybWVyIHN0eWxlIGlzIHByZWZlcmFibGUuDQoNCnVMYWJl bCBpcyBlYXNpbHkgZGlzdGluZ3VzaGVkICBmcm9tIG9yaWdpbmFsIGxhYmVsLg0KDQppZiB3ZSBq dXN0IHVwZGF0ZSBsYWJlbCB0byBuZXcgZGVmaW50aW9uLg0KDQp0aGUgdXNlciBtYXkgY29uZnVz ZSB0aGUgb2xkIGxhYmVsIGFuZCBuZXcgbGFiZWwuDQpidXQgbGFiZWwgYW5kIHVMYWJlbCBpcyBl YXN5IHRvIGRlIGRpZmZlcmVudGVkLg0KDQo+IA0KPiBOb3cgdGhhdCB3ZSBhcmUgb24gc3RhbmRh cmRzIHRyYWNrLCBJIHRoaW5rIHdlIHNob3VsZCBiZSBzdHJpdmluZyBmb3IgDQo+IG1vcmUgY29u c2lzdGVuY3kgYWNyb3NzIGFsbCB0aGUgZG9jdW1lbnRzLg0KPiANCj4gLUVybmllDQo+IA0KPiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaW1h From klensin@jck.com Mon Jul 12 22:53:30 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A21A3A6875 for ; Mon, 12 Jul 2010 22:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHryhhC6OaJZ for ; Mon, 12 Jul 2010 22:53:28 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 95D703A67C0 for ; Mon, 12 Jul 2010 22:53:27 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYYQx-000MYN-KZ; Tue, 13 Jul 2010 01:53:35 -0400 Date: Tue, 13 Jul 2010 01:53:34 -0400 From: John C Klensin To: Ernie Dainow , ima@ietf.org Message-ID: <326D84CE7B092784C9F2229E@PST.JCK.COM> In-Reply-To: <4C3B865C.2040503@ca.afilias.info> References: <4C3B865C.2040503@ca.afilias.info> 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 Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 05:53:30 -0000 --On Monday, July 12, 2010 17:17 -0400 Ernie Dainow wrote: > A message to mailbox will bounce if the > UTF8SMTPbis extension is not supported by an MTA. According to > rfc5336bis, this will not be done by an MTA. This is not > obvious behavior, since it is fairly trivial to do a punycode > conversion of the domain part so that the address is all > ASCII. Many users are familiar with web browsers that do this > conversion and may expect similar behavior in email. Speaking for myself only, this is actually one of the difficult cases I was sort of alluding to in an earlier note today. Please review draft-iab-idn-encoding (-03 was posted yesterday). If one has a system in which any string in a multi-target name resolution slot is passed to a common name resolution interface, then it probably will not be possible to prevent an string from being resolved, with or without EAI. Similarly, if a system identifies the domain part as being an IDNA-aware domain name slot, might be turned into before the mail-specific software actually gets its hands on it and subsequently treated as an all-ASCII address. It is plausible to put outside the scope of an EAI standard if the extension isn't specified. That follows from the observation that, if the extension is not specified, everything (ASCII and non-ASCII alike) is outside the scope of the standard. But requiring message rejection in one of those cases is not reasonable: servers who do not announce the extension are bound only by the rules of RFC 5321 and friends. Those specifications are specific about what must be accepted but deliberately not specific about what must be rejected. > To reinforce that this is a failure case, we should add the > following example to section 4.4 of rfc5335bis-00. > > > ; message will bounce if UTF8SMTPbis extension is not > supported. An MTA will not convert > ; the domain part to ASCII, but this may be done by > an MUA or submission server (MSA). The strongest thing that can be said, ideally with a citation of 5321, is something like: ; if theUTF8SMTPbis extension is not supported, ; the MTA is required to be SMTP [RFC 5321]-compliant ; only. Such an MTA is not required to ; convert the domain part to from U-label form to ; A-label form. If it does not, the message may be ; rejected or simply not delivered. Similarly, ; if theUTF8SMTPbis extension is not supported, an ; MUA or submission server (MSA) may perform conversions ; to A-label form, but is not required to do so. Note that the IRI spec makes this even more difficult because mailto:ASCII@non-ASCII is at least as likely to be converted into mailto:ASCII@%-encoded-UTF-8 as into mailto:ASCII@A-label... john From edainow@ca.afilias.info Tue Jul 13 05:59:07 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE843A6922 for ; Tue, 13 Jul 2010 05:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15OAu71TaF7I for ; Tue, 13 Jul 2010 05:59:06 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 329CA3A68E8 for ; Tue, 13 Jul 2010 05:59:05 -0700 (PDT) Message-ID: <4C3C6319.4040101@ca.afilias.info> Date: Tue, 13 Jul 2010 08:59:05 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: John C Klensin References: <4C3B865C.2040503@ca.afilias.info> <326D84CE7B092784C9F2229E@PST.JCK.COM> In-Reply-To: <326D84CE7B092784C9F2229E@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 12:59:07 -0000 On 7/13/2010 1:53 AM, John C Klensin wrote: > > --On Monday, July 12, 2010 17:17 -0400 Ernie Dainow > wrote: > > >> A message to mailbox will bounce if the >> UTF8SMTPbis extension is not supported by an MTA. According to >> rfc5336bis, this will not be done by an MTA. This is not >> obvious behavior, since it is fairly trivial to do a punycode >> conversion of the domain part so that the address is all >> ASCII. Many users are familiar with web browsers that do this >> conversion and may expect similar behavior in email. >> > Speaking for myself only, this is actually one of the difficult > cases I was sort of alluding to in an earlier note today. > > Please review draft-iab-idn-encoding (-03 was posted yesterday). > If one has a system in which any string in a multi-target name > resolution slot is passed to a common name resolution interface, > then it probably will not be possible to prevent an > string from being resolved, with or without > EAI. Similarly, if a system identifies the domain part as being > an IDNA-aware domain name slot, might be > turned into before the mail-specific > software actually gets its hands on it and subsequently treated > as an all-ASCII address. > > It is plausible to put outside the scope of an > EAI standard if the extension isn't specified. That follows > from the observation that, if the extension is not specified, > everything (ASCII and non-ASCII alike) is outside the scope of > the standard. But requiring message rejection in one of those > cases is not reasonable: servers who do not announce the > extension are bound only by the rules of RFC 5321 and friends. > Those specifications are specific about what must be accepted > but deliberately not specific about what must be rejected. > > > >> To reinforce that this is a failure case, we should add the >> following example to section 4.4 of rfc5335bis-00. >> >> >> ; message will bounce if UTF8SMTPbis extension is not >> supported. An MTA will not convert >> ; the domain part to ASCII, but this may be done by >> an MUA or submission server (MSA). >> > The strongest thing that can be said, ideally with a citation of > 5321, is something like: > > > ; if theUTF8SMTPbis extension is not supported, > ; the MTA is required to be SMTP [RFC 5321]-compliant > ; only. Such an MTA is not required to > ; convert the domain part to from U-label form to > ; A-label form. If it does not, the message may be > ; rejected or simply not delivered. Similarly, > ; if theUTF8SMTPbis extension is not supported, an > ; MUA or submission server (MSA) may perform conversions > ; to A-label form, but is not required to do so. > According to section 3.2 in 5336bis-00, is an internationalized address and can't be submitted to an MTA that does not support UTF8SMTPbis. An MTA cannot rewrite such a header so the message must be rejected. If we want to allow an MTA to do punycode conversion, the following paragraph in 5336bis-00 needs to be revised. 1. If and only if the SMTP client (sender) is a Message Submission Server ("MSA") [RFC4409], it MAY, consistent with the general provisions for changes by such servers, rewrite the envelope, headers, or message material to make them entirely ASCII > > Note that the IRI spec makes this even more difficult because > > mailto:ASCII@non-ASCII > > is at least as likely to be converted into > > mailto:ASCII@%-encoded-UTF-8 > > as into > > mailto:ASCII@A-label... > > john > > From edainow@ca.afilias.info Tue Jul 13 06:01:25 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056A33A69C5 for ; Tue, 13 Jul 2010 06:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8+QaerL5TLR for ; Tue, 13 Jul 2010 06:01:24 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 39BA73A696B for ; Tue, 13 Jul 2010 06:01:24 -0700 (PDT) Message-ID: <4C3C63A5.6050705@ca.afilias.info> Date: Tue, 13 Jul 2010 09:01:25 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: [EAI] mailbox in rfc5335bis-00 vs rfc5336bis-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:01:25 -0000 There are different definitions for mailbox, and the component parts local-part, domain in these two drafts. If they are equivalent, can we not just use one definition for both documents? If they are not equivalent, it would help to state what the difference is. There are some other common terms used in both documents, such as quoted strings. I think it would be a good idea for the authors of these two documents to collaborate on a common set of definitions, with explanations of any differences that are necessary. -Ernie From jyee@ca.afilias.info Tue Jul 13 06:51:44 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1313A698F for ; Tue, 13 Jul 2010 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmdjEmZPkj39 for ; Tue, 13 Jul 2010 06:51:43 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 67A243A6959 for ; Tue, 13 Jul 2010 06:51:43 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYftn-0002Sy-8c; Tue, 13 Jul 2010 13:51:51 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYftn-0007qS-4W; Tue, 13 Jul 2010 13:51:51 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <326D84CE7B092784C9F2229E@PST.JCK.COM> Date: Tue, 13 Jul 2010 09:51:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26DA38F8-5532-4266-AA3F-2F0C6E0DA767@ca.afilias.info> References: <4C3B865C.2040503@ca.afilias.info> <326D84CE7B092784C9F2229E@PST.JCK.COM> To: John C Klensin X-Mailer: Apple Mail (2.1081) Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:51:44 -0000 On 2010-07-13, at 1:53 AM, John C Klensin wrote: >=20 >=20 > --On Monday, July 12, 2010 17:17 -0400 Ernie Dainow > wrote: >=20 >> A message to mailbox will bounce if the >> UTF8SMTPbis extension is not supported by an MTA. According to >> rfc5336bis, this will not be done by an MTA. This is not >> obvious behavior, since it is fairly trivial to do a punycode >> conversion of the domain part so that the address is all >> ASCII. Many users are familiar with web browsers that do this >> conversion and may expect similar behavior in email. >=20 > Speaking for myself only, this is actually one of the difficult > cases I was sort of alluding to in an earlier note today. =20 >=20 > Please review draft-iab-idn-encoding (-03 was posted yesterday). > If one has a system in which any string in a multi-target name > resolution slot is passed to a common name resolution interface, > then it probably will not be possible to prevent an > string from being resolved, with or without > EAI. Similarly, if a system identifies the domain part as being > an IDNA-aware domain name slot, might be > turned into before the mail-specific > software actually gets its hands on it and subsequently treated > as an all-ASCII address. Speaking for myself and my past experience on ... Some MUAs, with plugin, converts to = before submitting. Some would display to = . MTAs 'listen' domain in ASCII and A-label format only. =20 So from now to at least in early phase when EAI introduced, there may be = some mail addresses in format but not running under = UTF8SMTPbis. And if EAI aware users with EAI aware MUA and EAI aware = MTA send message to those mail addresses, the message would be rejected. = I would guess this group would be early adopters of EAI, but never = assume this is the case. Personally I see the domain convert as 'last resort' hoping to deliver = the email. I don't think it as must-do, but I hope it does not get into = must-not-do. =20 >=20 > It is plausible to put outside the scope of an > EAI standard if the extension isn't specified. That follows > from the observation that, if the extension is not specified, > everything (ASCII and non-ASCII alike) is outside the scope of > the standard. But requiring message rejection in one of those > cases is not reasonable: servers who do not announce the > extension are bound only by the rules of RFC 5321 and friends. > Those specifications are specific about what must be accepted > but deliberately not specific about what must be rejected. >=20 >=20 >> To reinforce that this is a failure case, we should add the >> following example to section 4.4 of rfc5335bis-00. >>=20 >> >> ; message will bounce if UTF8SMTPbis extension is not >> supported. An MTA will not convert >> ; the domain part to ASCII, but this may be done by >> an MUA or submission server (MSA). >=20 > The strongest thing that can be said, ideally with a citation of > 5321, is something like: >=20 > > ; if theUTF8SMTPbis extension is not supported, > ; the MTA is required to be SMTP [RFC 5321]-compliant > ; only. Such an MTA is not required to=20 > ; convert the domain part to from U-label form to > ; A-label form. If it does not, the message may be=20 > ; rejected or simply not delivered. Similarly, > ; if theUTF8SMTPbis extension is not supported, an > ; MUA or submission server (MSA) may perform conversions > ; to A-label form, but is not required to do so. I like this text. Address the domain convert as optional. We would = need to make sure the new text in both 5335bis section 4.4 and 5336bis = section 3.2 (last paragraph) be consistent. Joseph >=20 > Note that the IRI spec makes this even more difficult because=20 >=20 > mailto:ASCII@non-ASCII >=20 > is at least as likely to be converted into >=20 > mailto:ASCII@%-encoded-UTF-8 >=20 > as into >=20 > mailto:ASCII@A-label... >=20 > john >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Tue Jul 13 09:17:06 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D413A6A36 for ; Tue, 13 Jul 2010 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upOPhWl+J20H for ; Tue, 13 Jul 2010 09:17:05 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 5EB1A3A6A8B for ; Tue, 13 Jul 2010 09:17:04 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYiAS-000MEt-7P; Tue, 13 Jul 2010 12:17:12 -0400 Date: Tue, 13 Jul 2010 12:17:11 -0400 From: John C Klensin To: Ernie Dainow Message-ID: In-Reply-To: <4C3C6319.4040101@ca.afilias.info> References: <4C3B865C.2040503@ca.afilias.info> <326D84CE7B092784C9F2229E@PST.JCK.COM> <4C3C6319.4040101@ca.afilias.info> 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 Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:17:06 -0000 --On Tuesday, July 13, 2010 08:59 -0400 Ernie Dainow wrote: >... >> It is plausible to put outside the scope of >> an EAI standard if the extension isn't specified. That >> follows from the observation that, if the extension is not >> specified, everything (ASCII and non-ASCII alike) is outside >> the scope of the standard. But requiring message rejection >> in one of those cases is not reasonable: servers who do not >> announce the extension are bound only by the rules of RFC >> 5321 and friends. Those specifications are specific about >> what must be accepted but deliberately not specific about >> what must be rejected. >... >> The strongest thing that can be said, ideally with a citation >> of 5321, is something like: >> >> >> ; if theUTF8SMTPbis extension is not supported, >> ; the MTA is required to be SMTP [RFC >> 5321]-compliant ; only. Such an MTA is not >> required to >> ; convert the domain part to from U-label form to >> ; A-label form. If it does not, the message may be >> ; rejected or simply not delivered. Similarly, >> ; if theUTF8SMTPbis extension is not supported, an >> ; MUA or submission server (MSA) may perform >> conversions ; to A-label form, but is not required >> to do so. >> > > According to section 3.2 in 5336bis-00, is > an internationalized address and can't be submitted to an MTA > that does not support UTF8SMTPbis. An MTA cannot rewrite such > a header so the message must be rejected. If we want to allow > an MTA to do punycode conversion, the following paragraph in > 5336bis-00 needs to be revised. >... I obviously was not clear; let me try again. Nothing this WG does can change basic requirements or flexibilities in 5321 or 5322 except in the context of systems advertising the EAI extensions. Doing so is not only out-of-charter, it essentially would fork the SMTP protocol rather than extending it. The Experimental documents may have been sloppy about how things were worded in this area; the standards-track ones must not be. To try to break this down a bit... (1) An SMTP server that does not announce UTF8SMTPbis cannot be constrained by us. If it encounters non-ASCII domain labels and wants to do conversions into A-label form, we cannot prevent it from doing that, nor can we prevent it from looking up the UTF-8 string, normalized or not, in the DNS. If it wants to reject the message instead, we cannot prevent that either. We also cannot prevent it from simply turning off all of the high-order bits and treating the resulting address as ASCII. That would be dumb, but it isn't our problem and there is some history of exactly that behavior. And, finally, if it sees a domain name with A-labels in it, it is expected to treat those as ordinary LDH-style domain names, without any special handling, unless it, or its supporting libraries, are IDNA-aware. If it is IDNA-aware, it might make some tests. (2) We could make a rule that says that a server that announces UTF8SMTPbis is required to recognize and reject A-labels for either the case that the local-part is ASCII, the case where it isn't, or both. I would recommend against doing so because such a rule would require that an EAI-conformant server be less flexible that one that is not EAI-conformant. That, in turn, could act to discourage people from implementing/ announcing UTF8SMTPbis or to encourage them to ignore us. Interoperability would not be improved by such a prohibition. The text in 5335bis and 5336bis must be consistent with the principle above: no restrictions on servers that don't announce the extension. It is up to the WG how to handle the second case but I would urge that we be very careful about prohibitions -- MUST or SHOULD reject language-- that are not strictly needed for interoperability. john From klensin@jck.com Tue Jul 13 09:30:26 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0143A6870 for ; Tue, 13 Jul 2010 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYUeyQthFD-O for ; Tue, 13 Jul 2010 09:30:24 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 99F273A6A5B for ; Tue, 13 Jul 2010 09:30:24 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYiNN-000Mix-1i; Tue, 13 Jul 2010 12:30:33 -0400 Date: Tue, 13 Jul 2010 12:30:32 -0400 From: John C Klensin To: Ernie Dainow , ima@ietf.org Message-ID: <240838A2CE507140DE03CFA8@PST.JCK.COM> In-Reply-To: <4C3C63A5.6050705@ca.afilias.info> References: <4C3C63A5.6050705@ca.afilias.info> 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 Subject: Re: [EAI] mailbox in rfc5335bis-00 vs rfc5336bis-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:30:26 -0000 --On Tuesday, July 13, 2010 09:01 -0400 Ernie Dainow wrote: > There are different definitions for mailbox, and the component > parts local-part, domain in these two drafts. If they are > equivalent, can we not just use one definition for both > documents? If they are not equivalent, it would help to state > what the difference is. > > There are some other common terms used in both documents, such > as quoted strings. > > I think it would be a good idea for the authors of these two > documents to collaborate on a common set of definitions, with > explanations of any differences that are necessary. Yes. I note from recent experience that, if terminology is not consistent within or between documents (down to capitalization and hyphenation, not just spelling), the RFC Editor may try to fix it. That often turns into a painful and time-consuming process; we are much better off if we get things right. And "right" includes absolute consistency of terminology. john From klensin@jck.com Tue Jul 13 10:14:12 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D263A696D for ; Tue, 13 Jul 2010 10:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ibl1HqkindQ for ; Tue, 13 Jul 2010 10:14:11 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B3C1D3A69CE for ; Tue, 13 Jul 2010 10:14:10 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYj3d-000OsV-8M; Tue, 13 Jul 2010 13:14:13 -0400 Date: Tue, 13 Jul 2010 13:14:12 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org 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 Subject: Re: [EAI] draft-ietf-eai-frmwrk-4952bis-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:14:12 -0000 --On Tuesday, July 13, 2010 01:52 +0000 Shawn Steele wrote: >> The main difference between (1) and (2) is where it waits > > I would prefer that the document wait in the step as close to > final as possible (eg: 2 if I understand correctly). Or be a > bit handwavy and don't hold up this doc. Handwavey has > another advantage in that it forces someone to look at the > actual standard instead of just thinking "oh, support UTF-8, > check". But it means that they may not be able to _find_ that "actual standard": no forward reference is possible, the I-D is published under an RFC number that is widely separated from the rest of the documents, the other I-Ds get listed only as "work in progress" without even a file name, etc. As editor, I will do whatever the WG says to do. As co-chair, I will merely advise the WG that this is not an easy decision. In some sense, getting it published faster makes it less useful in the long term, simply because of what needs to be taken out or made non-specific. >> and the client must announce 8BITMIME. > > I guess I missed where the client must use 8BITMIME. I'd > thought that the server announcing 8BITMIME would be > sufficient to guarantee 8bitness, and that MIME structuring > wouldn't necessarily be required. It's not quite clear to me > why MIME structure would be necessary for a simple "hi there" > message if the server announced UTF8SMTP? Clearly UTF8SMTP is > permitting non-ASCII? It depends on what you mean by "permitting". One cannot apply a content-transfer-encoding to headers. Encoded words are forbidden in a lot of contexts, including actual mailbox names. I can construct a few examples that would work but, if there is actually going to be _any_ UTF-8 in the headers, it has to be transmitted in 8bit form, and that means 8BITMIME MUST be enabled. We had a long discussion many months ago about whether to incorporate the effect of 8BITMIME in UTF8SMTP or whether to require that, if UTF8SMTP was used, 8BITMIME was required. We selected the latter, largely because it reduces complexity and saved us working through the downgrade cases for 8BITMIME itself again. The simple "hi there" message doesn't require 8BITMIME transmission (although we still require that the server announce 8BITMIME if it is going to announce UTF8SMTP[bis]), but only if the client doesn't use any EAI facilities: no non-ASCII addresses, no header field elements in UTF-8, etc. >> 6.1 bullet 1: >> "use of ASCII-compatible (ACE) >> encoding [RFC3492] [RFC5890] on the right hand side is >> discouraged" > > I'm happy with it for this doc. I think servers have to > recognize it anyway (since the sender might not be EAI aware), > however an EAI aware system should recognize ACE, so > presumably it should be able to send clean UTF-8 w/o ACE. > It's not a big deal, but mostly I would like to try to keep > the stuff on the wire "clean", which entails trying to forbid > the clients from being lazy :) So however much we can > discourage laziness is what I'd like. MUST NOT may be too > strong. See earlier note to Ernie about the tradeoffs in this. And I would really, really, like to be sure that whatever is said in this doc is consistent with whatever is (or is not) said in 5336bis. >> 6.1 bullet 4. "no other code pages" >> Addresses my earlier question, and I'm fine with this text, >> although, in practice, it's sort of like closing the barn >> door after the animals have left. :) > >> So, if you think the animals are out of the barn, I'd be very >> interested in a census of the relevant animals. > > I believe really, really, really old copies of sendmail :) (& > maybe it was a funky sco version as well, I can't speak to > it's pedigree). The really, really, really old versions of sendmail had a rather elegant and efficient way to deal with octets with the high-order bit turned on. They zeroed the bit without comment and proceeded. So alternate code pages may have worked (and national variations on ASCII (really ISO 646) definitely did, but nothing involving 8bit codings including 8859 variations. >> That said, I don't think it will change this provision. > > That's fine. Just saying that adding "no other code pages" > isn't going to fix any two decade old system out there > (shudder) that depends on this. If there are two decade old versions of sendmail that exhibit that behavior, I'd assume they are locally-patched forked copies. Making provisions for them gets us rather far into the territory of permanent support for bugs and bad local ideas. > > 9.1 - The charter has the "addresses" spec, I'm not sure >> > you need to go into this much depth here. (don't see that >> > it hurts either) > >> The answer may depend on when we want to push this document >> out the door and in what state. See above. > > Sorry, no clue which "above". Hear from others? That's fine. Hear from others and those three options about handling the document, how long it waits, etc. >> > * Normalization - I think the key point is that servers >> > should be > >> Not quite, I think. > > If NFC(x) == NFC(y), then NFD(x) === NFD(y), so equality is > fine. > >> We need to do the case analysis carefully here given that NFC >> sometimes decomposes (NFD never composes) and that this >> interacts with the 5321 limits on string lengths. > > I'd missed the length thing, however my feeling is that people > will send NFD (or something neither NFC nor NFD) on the wire, > whether or not we think that's smart. So, either way, a > server really should be applying either NFC or NFD so they can > appropriately match. At that point I really don't care what > their internal architecture is like, I think. Obviously if I > want to send NFD on the wire and it's too long, then I'm > stuck, but we already have been SHOULDing NFC on the wire. > > Anyway, I don't really care, I'd be using NFC anyway if I was > building something. I just wonder if it might be easier for > some platforms to use a native NFD internally, and whether we > were overly specifying what they might do internally. We haven't said a thing about what is done internally, only that testing has to be equivalent under NFC. "The length thing" may cause some strings to be valid under NFC but not under NFD (and vice versa) so being clear about the canonical test is important. >> Actually, in some parts of the world and at the second and >> third level, foo123, foo124, and foo321 are all seen as >> domain name labels, > > Same reasoning though, when you see those, it's because > there're a billion people getting free blogs or whatever, and > then the ASCII gets confusable as well. I really think > there's too much fear about homographs (see > http://blogs.msdn.com/b/shawnste/archive/2009/11/23/the-fud-of > -idn-and-homographs.aspx ), however since that's the question > managers like to ask, it's good to address it here. Exactly. >> But I think --and you seem to have confirmed-- >> that we could spend a lot of effort tuning that text to make >> it only slightly better. So, unless others have objections or >> concerns, we are probably at a good stopping point. > > Agreed :) thx john From klensin@jck.com Tue Jul 13 10:16:52 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDCD3A6B3F for ; Tue, 13 Jul 2010 10:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng6+nRKQDSzO for ; Tue, 13 Jul 2010 10:16:51 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8937F3A6B3B for ; Tue, 13 Jul 2010 10:16:49 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYj6H-000OwG-E3; Tue, 13 Jul 2010 13:16:57 -0400 Date: Tue, 13 Jul 2010 13:16:56 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <2B3C266F7CCFFBE411E9CFA2@PST.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 Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:16:52 -0000 --On Tuesday, July 13, 2010 02:01 +0000 Shawn Steele wrote: > In practice would a present-day server echo the non-ASCII part > in the error? (I'm unfamiliar with what normally happens > here). While there are exceptions, most present-day servers use fixed text in response messages whenever possible, rather than "echoing" anything, ASCII or not. The principle is that one should be able to build localized translations of the response messages based on reply codes only and ignoring (rather than trying to parse and translate) the text. The main exceptions are VRFY and EXPN where they are supported. john From edainow@ca.afilias.info Tue Jul 13 11:17:45 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28EF3A6B38 for ; Tue, 13 Jul 2010 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3pMnP+bNGob for ; Tue, 13 Jul 2010 11:17:14 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 98E933A6B45 for ; Tue, 13 Jul 2010 11:16:38 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OYk2A-0007VU-4x; Tue, 13 Jul 2010 18:16:46 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=[10.10.68.31]) by smtp.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OYk2A-0007A4-4P; Tue, 13 Jul 2010 18:16:46 +0000 Message-ID: <4C3CAD8A.6040008@ca.afilias.info> Date: Tue, 13 Jul 2010 14:16:42 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John C Klensin References: <4C3B865C.2040503@ca.afilias.info> <326D84CE7B092784C9F2229E@PST.JCK.COM> <4C3C6319.4040101@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:17:46 -0000 John C Klensin wrote: > --On Tuesday, July 13, 2010 08:59 -0400 Ernie Dainow > wrote: > > >> ... >> >>> It is plausible to put outside the scope of >>> an EAI standard if the extension isn't specified. That >>> follows from the observation that, if the extension is not >>> specified, everything (ASCII and non-ASCII alike) is outside >>> the scope of the standard. But requiring message rejection >>> in one of those cases is not reasonable: servers who do not >>> announce the extension are bound only by the rules of RFC >>> 5321 and friends. Those specifications are specific about >>> what must be accepted but deliberately not specific about >>> what must be rejected. >>> >> ... >> >>> The strongest thing that can be said, ideally with a citation >>> of 5321, is something like: >>> >>> >>> ; if theUTF8SMTPbis extension is not supported, >>> ; the MTA is required to be SMTP [RFC >>> 5321]-compliant ; only. Such an MTA is not >>> required to >>> ; convert the domain part to from U-label form to >>> ; A-label form. If it does not, the message may be >>> ; rejected or simply not delivered. Similarly, >>> ; if theUTF8SMTPbis extension is not supported, an >>> ; MUA or submission server (MSA) may perform >>> conversions ; to A-label form, but is not required >>> to do so. >>> >>> >> According to section 3.2 in 5336bis-00, is >> an internationalized address and can't be submitted to an MTA >> that does not support UTF8SMTPbis. An MTA cannot rewrite such >> a header so the message must be rejected. If we want to allow >> an MTA to do punycode conversion, the following paragraph in >> 5336bis-00 needs to be revised. >> ... >> > > I obviously was not clear; let me try again. Nothing this WG > does can change basic requirements or flexibilities in 5321 or > 5322 except in the context of systems advertising the EAI > extensions. Understood. The context of the above paragraph from 5336bis-00 section 3.2, is an MTA that supports UTF8SMTPbis. If such a server is allowed to submit to another MTA that does not support UTF8SMTPbis, then we cannot place any new rules on that server, and it is bound only by earlier SMTP standards. But my interpretation of 5336bis-00 is that cannot be submitted to a non-UTF8SMTPbis MTA, so it must make one of the three choices in section 3.2. These choices do not include doing a conversion of the domain, unless it is an MSA. In the interest of maximum interoperability, I think we should specify that a UTF8SMTPbis MTA should do a conversion in this case. > Doing so is not only out-of-charter, it essentially > would fork the SMTP protocol rather than extending it. The > Experimental documents may have been sloppy about how things > were worded in this area; the standards-track ones must not be. > > To try to break this down a bit... > > (1) An SMTP server that does not announce UTF8SMTPbis > cannot be constrained by us. If it encounters non-ASCII > domain labels and wants to do conversions into A-label > form, we cannot prevent it from doing that, nor can we > prevent it from looking up the UTF-8 string, normalized > or not, in the DNS. If it wants to reject the message > instead, we cannot prevent that either. We also cannot > prevent it from simply turning off all of the high-order > bits and treating the resulting address as ASCII. That > would be dumb, but it isn't our problem and there is > some history of exactly that behavior. And, finally, if > it sees a domain name with A-labels in it, it is > expected to treat those as ordinary LDH-style domain > names, without any special handling, unless it, or its > supporting libraries, are IDNA-aware. If it is > IDNA-aware, it might make some tests. > > (2) We could make a rule that says that a server that > announces UTF8SMTPbis is required to recognize and > reject A-labels for either the case that the local-part > is ASCII, the case where it isn't, or both. I would > recommend against doing so because such a rule would > require that an EAI-conformant server be less flexible > that one that is not EAI-conformant. That, in turn, > could act to discourage people from implementing/ > announcing UTF8SMTPbis or to encourage them to ignore > us. Interoperability would not be improved by such a > prohibition. > > The text in 5335bis and 5336bis must be consistent with the > principle above: no restrictions on servers that don't announce > the extension. It is up to the WG how to handle the second > case but I would urge that we be very careful about prohibitions > -- MUST or SHOULD reject language-- that are not strictly needed > for interoperability. > > john > > > > From klensin@jck.com Tue Jul 13 11:33:10 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C083A67F5 for ; Tue, 13 Jul 2010 11:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZf1HNg1MJTh for ; Tue, 13 Jul 2010 11:33:08 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 688D53A69D8 for ; Tue, 13 Jul 2010 11:33:06 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYkI5-0002dp-Li; Tue, 13 Jul 2010 14:33:13 -0400 Date: Tue, 13 Jul 2010 14:33:12 -0400 From: John C Klensin To: Ernie Dainow Message-ID: <9BAEAE4D07DAE7BC89C4C009@PST.JCK.COM> In-Reply-To: <4C3CAD8A.6040008@ca.afilias.info> References: <4C3B865C.2040503@ca.afilias.info> <326D84CE7B092784C9F2229E@PST.JCK.COM> <4C3C6319.4040101@ca.afilias.info> <4C3CAD8A.6040008@ca.afilias.info> 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 Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:33:10 -0000 --On Tuesday, July 13, 2010 14:16 -0400 Ernie Dainow wrote: >>> According to section 3.2 in 5336bis-00, is >>> an internationalized address and can't be submitted to an MTA >>> that does not support UTF8SMTPbis. An MTA cannot rewrite such >>> a header so the message must be rejected. If we want to allow >>> an MTA to do punycode conversion, the following paragraph in >>> 5336bis-00 needs to be revised. >>> ... >>> >> >> I obviously was not clear; let me try again. Nothing this WG >> does can change basic requirements or flexibilities in 5321 or >> 5322 except in the context of systems advertising the EAI >> extensions. > Understood. The context of the above paragraph from 5336bis-00 > section 3.2, is an MTA that supports UTF8SMTPbis. If such a > server is allowed to submit to another MTA > that does not support UTF8SMTPbis, then we cannot place any > new rules on that server, and it is bound only by earlier SMTP > standards. But my interpretation of 5336bis-00 is that > cannot be submitted to a non-UTF8SMTPbis > MTA, so it must make one of the three choices in section 3.2. > These choices do not include doing a conversion of the domain, > unless it is an MSA. > > In the interest of maximum interoperability, I think we should > specify that a UTF8SMTPbis MTA should do a conversion in this > case. Speaking with my WG Co-Chair hat distinctly off, I agree. Interoperability is good and, if we know how to get messages through without problems, we should do so. On the other hand, if there is lots of UTF-8 stuff in the headers, that might be harder than just converting domains to A-labels, so we need to think through this carefully. john From Shawn.Steele@microsoft.com Tue Jul 13 14:58:24 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C46F3A679C for ; Tue, 13 Jul 2010 14:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.4 X-Spam-Level: X-Spam-Status: No, score=-10.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkuJ4Ahqo+Rt for ; Tue, 13 Jul 2010 14:58:23 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6E4E43A6833 for ; Tue, 13 Jul 2010 14:58:23 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Jul 2010 14:58:32 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0180.004; Tue, 13 Jul 2010 14:58:30 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: ulabel Thread-Index: Acsi1kPA+YbLD+69SISITbnDQXksdg== Date: Tue, 13 Jul 2010 21:58:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:58:24 -0000 > the user may confuse the old label and new label. > but label and uLabel is easy to de differented. Ulabel makes me wary because its use in IDN presumes there's an alabel. So= the connotations make me uneasy (whether that's reasonable or not). So I'd prefer utf8-label:) -Shawn From klensin@jck.com Tue Jul 13 15:51:39 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA1F3A6836 for ; Tue, 13 Jul 2010 15:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlvD7ZPFxvzQ for ; Tue, 13 Jul 2010 15:51:39 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A8CA63A67EE for ; Tue, 13 Jul 2010 15:51:38 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYoKI-000DvK-Lp; Tue, 13 Jul 2010 18:51:46 -0400 Date: Tue, 13 Jul 2010 18:51:44 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <3EA1FEAB65749F8F5DB9E6A4@[192.168.130.212]> 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 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:51:40 -0000 --On Tuesday, 13 July, 2010 21:58 +0000 Shawn Steele wrote: >> the user may confuse the old label and new label. >> but label and uLabel is easy to de differented. > > Ulabel makes me wary because its use in IDN presumes there's > an alabel. So the connotations make me uneasy (whether that's > reasonable or not). > > So I'd prefer utf8-label:) I sort of agree with Shawn. I have no strong preference, one way or the other, for utf8-label. But all IDNA2003 terminology needs to come out of the documents (remember that the ToASCII and ToUnicode operations no longer exist) and "ulabel" and "alabel" should be avoided unless they are spelled U-label and A-label and used precisely the way IDNA2008 uses them. Just my personal opinion, but I'll fight fairly hard to keep terminology as clear, consistent, and precise as possible. john From Shawn.Steele@microsoft.com Tue Jul 13 16:14:18 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C396E3A69E5 for ; Tue, 13 Jul 2010 16:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.412 X-Spam-Level: X-Spam-Status: No, score=-10.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ne99PL41UXB for ; Tue, 13 Jul 2010 16:14:18 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E3D203A69C3 for ; Tue, 13 Jul 2010 16:14:17 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Jul 2010 16:14:26 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0180.004; Tue, 13 Jul 2010 16:14:24 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: mail bounce versus punycode conversion Thread-Index: Acsi4QGa85FQVE/TSGGuNLQuXEY1GQ== Date: Tue, 13 Jul 2010 23:14:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 23:14:19 -0000 IMO I don't see any harm in stating that ascii@utf-8 might fail in unaware = systems. Like John said, it can't be required though. I'm also not sure t= hat it gains much to add that though. -Shawn From Shawn.Steele@microsoft.com Tue Jul 13 16:23:21 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81CC3A6860 for ; Tue, 13 Jul 2010 16:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJU+Z80++S3K for ; Tue, 13 Jul 2010 16:23:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1D1013A6A09 for ; Tue, 13 Jul 2010 16:23:21 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Jul 2010 16:23:30 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0180.004; Tue, 13 Jul 2010 16:23:28 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: mail bounce versus punycode conversion Thread-Index: Acsi4aZustZw8h5YQdi10CiygDRTQA== Date: Tue, 13 Jul 2010 23:23:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 23:23:22 -0000 > > In the interest of maximum interoperability, I think we should specify= =20 > > that a UTF8SMTPbis MTA should do a conversion in this case. > Speaking with my WG Co-Chair hat distinctly off, I agree. > Interoperability is good and, if we know how to get messages > through without problems, we should do so. I agree as well. > On the other hand, > if there is lots of UTF-8 stuff in the headers, that might be harder than= just converting domains to A-labels, so we need > to think through this ca= refully. I wouldn't over-analyze the how part. Yes, it can be "harder", however str= ange stuff could already be happening by non-aware servers, so I don't thin= k we need to state exactly how. This is something a 2821 environment could= already do if it wanted, so there's very little we could add in the UTF8SM= TP spec. -Shawn From yaojk@cnnic.cn Tue Jul 13 18:41:34 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82313A6925 for ; Tue, 13 Jul 2010 18:41:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.274 X-Spam-Level: * X-Spam-Status: No, score=1.274 tagged_above=-999 required=5 tests=[AWL=1.317, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKd7+kqpQgZC for ; Tue, 13 Jul 2010 18:41:34 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 635543A68DA for ; Tue, 13 Jul 2010 18:41:32 -0700 (PDT) Received: (eyou send program); Wed, 14 Jul 2010 09:41:41 +0800 Message-ID: <479071701.02977@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 14 Jul 2010 09:41:41 +0800 Message-ID: From: "Jiankang YAO" To: "Shawn Steele" , References: <479058319.19810@cnnic.cn> Date: Wed, 14 Jul 2010 09:41:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 01:41:34 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNoYXduIFN0ZWVsZSIgPFNo YXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBXZWRu ZXNkYXksIEp1bHkgMTQsIDIwMTAgNTo1OCBBTQ0KU3ViamVjdDogUmU6IFtFQUldIHVsYWJlbA0K DQoNCj4+IHRoZSB1c2VyIG1heSBjb25mdXNlIHRoZSBvbGQgbGFiZWwgYW5kIG5ldyBsYWJlbC4N Cj4+IGJ1dCBsYWJlbCBhbmQgdUxhYmVsIGlzIGVhc3kgdG8gZGUgZGlmZmVyZW50ZWQuDQo+IA0K PiBVbGFiZWwgbWFrZXMgbWUgd2FyeSBiZWNhdXNlIGl0cyB1c2UgaW4gSUROIHByZXN1bWVzIHRo ZXJlJ3MgYW4gYWxhYmVsLiAgU28gdGhlIGNvbm5vdGF0aW9ucyBtYWtlIG1lIHVuZWFzeSAod2hl dGhlciB0aGF0J3MgcmVhc29uYWJsZSBvciBub3QpLg0KVWxhYmVsIHdhcyBwcmV2ZW50ZWQgYmVm b3JlIGlkbmEyMDA4IGRlZmluZWQgYSB1LWxhYmVsIGFuZCBhLWxhYmVsLg0KdWxhYmVsIG1heSBi ZSBzaW1pbGFyIHRvIHUtbGFiZS4NCg0KYnV0IHdlIHdpbGwgbm90IGNvbmZ1c2UgVW1haWxib3gg d2l0aCB1LWxhYmVsLg0KDQpzbyBJIHRoaW5rIHRoYXQgd2Ugc3RpbGwga2VlcCBVbWFpbGJveCwg VWNoYXJhY3RlciwgVWF0b20uLi4uLi4NCg0KdGhlICBnZW5lcmFsIG5hbWUgb2YgYWxsIHRoZSBs YWJlbHMgaW5jbHVkaW5nICAgVW1haWxib3gsIFVjaGFyYWN0ZXIgYW5kIFVhdG9tIG1heSBiZSB1 dGYtOGxhYmVsLg0KDQoNCg0KPiANCj4gU28gSSdkIHByZWZlciB1dGY4LWxhYmVsOikNCj4gDQo+ IC1TaGF3bg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ== From yaojk@cnnic.cn Tue Jul 13 18:55:33 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCD33A6953 for ; Tue, 13 Jul 2010 18:55:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS7KY+3W9re1 for ; Tue, 13 Jul 2010 18:55:32 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 7B9073A6872 for ; Tue, 13 Jul 2010 18:55:30 -0700 (PDT) Received: (eyou send program); Wed, 14 Jul 2010 09:55:39 +0800 Message-ID: <479072539.10870@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 14 Jul 2010 09:55:39 +0800 Message-ID: From: "Jiankang YAO" To: "Ernie Dainow" , "John C Klensin" References: <4C3B865C.2040503@ca.afilias.info><326D84CE7B092784C9F2229E@PST.JCK.COM><4C3C6319.4040101@ca.afilias.info> <479045079.10930@cnnic.cn> Date: Wed, 14 Jul 2010 09:55:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 01:55:33 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVybmllIERhaW5vdyIgPGVk YWlub3dAY2EuYWZpbGlhcy5pbmZvPg0KVG86ICJKb2huIEMgS2xlbnNpbiIgPGtsZW5zaW5AamNr LmNvbT4NCkNjOiA8aW1hQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE0LCAyMDEw IDI6MTYgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBtYWlsIGJvdW5jZSB2ZXJzdXMgcHVueWNvZGUg Y29udmVyc2lvbg0KDQoNCj4gDQo+IA0KPiBKb2huIEMgS2xlbnNpbiB3cm90ZToNCj4+IC0tT24g VHVlc2RheSwgSnVseSAxMywgMjAxMCAwODo1OSAtMDQwMCBFcm5pZSBEYWlub3cNCj4+IDxlZGFp bm93QGNhLmFmaWxpYXMuaW5mbz4gd3JvdGU6DQo+Pg0KPj4gICANCj4+PiAuLi4NCj4+PiAgICAg DQo+Pj4+IEl0IGlzIHBsYXVzaWJsZSB0byBwdXQ8QVNDSUlAbm9uLUFTQ0lJPiAgb3V0c2lkZSB0 aGUgc2NvcGUgb2YNCj4+Pj4gYW4gRUFJIHN0YW5kYXJkIGlmIHRoZSBleHRlbnNpb24gaXNuJ3Qg c3BlY2lmaWVkLiAgVGhhdA0KPj4+PiBmb2xsb3dzIGZyb20gdGhlIG9ic2VydmF0aW9uIHRoYXQs IGlmIHRoZSBleHRlbnNpb24gaXMgbm90DQo+Pj4+IHNwZWNpZmllZCwgZXZlcnl0aGluZyAoQVND SUkgYW5kIG5vbi1BU0NJSSBhbGlrZSkgaXMgb3V0c2lkZQ0KPj4+PiB0aGUgc2NvcGUgb2YgdGhl IHN0YW5kYXJkLiAgQnV0IHJlcXVpcmluZyBtZXNzYWdlIHJlamVjdGlvbg0KPj4+PiBpbiBvbmUg b2YgdGhvc2UgY2FzZXMgaXMgbm90IHJlYXNvbmFibGU6IHNlcnZlcnMgd2hvIGRvIG5vdA0KPj4+ PiBhbm5vdW5jZSB0aGUgZXh0ZW5zaW9uIGFyZSBib3VuZCBvbmx5IGJ5IHRoZSBydWxlcyBvZiBS RkMNCj4+Pj4gNTMyMSBhbmQgZnJpZW5kcy4gVGhvc2Ugc3BlY2lmaWNhdGlvbnMgYXJlIHNwZWNp ZmljIGFib3V0DQo+Pj4+IHdoYXQgbXVzdCBiZSBhY2NlcHRlZCBidXQgZGVsaWJlcmF0ZWx5IG5v dCBzcGVjaWZpYyBhYm91dA0KPj4+PiB3aGF0IG11c3QgYmUgcmVqZWN0ZWQuDQo+Pj4+ICAgICAg IA0KPj4+IC4uLg0KPj4+ICAgICANCj4+Pj4gVGhlIHN0cm9uZ2VzdCB0aGluZyB0aGF0IGNhbiBi ZSBzYWlkLCBpZGVhbGx5IHdpdGggYSBjaXRhdGlvbg0KPj4+PiBvZiA1MzIxLCBpcyBzb21ldGhp bmcgbGlrZToNCj4+Pj4NCj4+Pj4gICAgICA8QVNDSUlAbm9uLUFTQ0lJPg0KPj4+PiAgICAgICAg ICAgOyBpZiB0aGVVVEY4U01UUGJpcyBleHRlbnNpb24gaXMgbm90IHN1cHBvcnRlZCwNCj4+Pj4g ICAgICAgICAgIDsgdGhlIE1UQSBpcyByZXF1aXJlZCB0byBiZSBTTVRQIFtSRkMNCj4+Pj4gICAg ICAgICAgIDUzMjFdLWNvbXBsaWFudCA7IG9ubHkuICBTdWNoIGFuIE1UQSBpcyBub3QNCj4+Pj4g ICAgICAgICAgIHJlcXVpcmVkIHRvDQo+Pj4+ICAgICAgICAgICA7IGNvbnZlcnQgdGhlIGRvbWFp biBwYXJ0IHRvIGZyb20gVS1sYWJlbCBmb3JtIHRvDQo+Pj4+ICAgICAgICAgICA7IEEtbGFiZWwg Zm9ybS4gIElmIGl0IGRvZXMgbm90LCB0aGUgbWVzc2FnZSBtYXkgYmUNCj4+Pj4gICAgICAgICAg IDsgcmVqZWN0ZWQgb3Igc2ltcGx5IG5vdCBkZWxpdmVyZWQuICBTaW1pbGFybHksDQo+Pj4+ICAg ICAgICAgICA7IGlmIHRoZVVURjhTTVRQYmlzIGV4dGVuc2lvbiBpcyBub3Qgc3VwcG9ydGVkLCBh bg0KPj4+PiAgICAgICAgICAgOyBNVUEgb3Igc3VibWlzc2lvbiBzZXJ2ZXIgKE1TQSkgbWF5IHBl cmZvcm0NCj4+Pj4gICAgICAgICAgIGNvbnZlcnNpb25zIDsgdG8gQS1sYWJlbCBmb3JtLCBidXQg aXMgbm90IHJlcXVpcmVkDQo+Pj4+ICAgICAgICAgICB0byBkbyBzby4NCj4+Pj4gICAgDQo+Pj4+ ICAgICAgIA0KPj4+IEFjY29yZGluZyB0byBzZWN0aW9uIDMuMiBpbiAgNTMzNmJpcy0wMCwgPEFT Q0lJQG5vbi1BU0NJST4gaXMNCj4+PiBhbiBpbnRlcm5hdGlvbmFsaXplZCBhZGRyZXNzIGFuZCBj YW4ndCBiZSBzdWJtaXR0ZWQgdG8gYW4gTVRBDQo+Pj4gdGhhdCBkb2VzIG5vdCBzdXBwb3J0IFVU RjhTTVRQYmlzLiBBbiBNVEEgY2Fubm90IHJld3JpdGUgc3VjaA0KPj4+IGEgaGVhZGVyIHNvIHRo ZSBtZXNzYWdlIG11c3QgYmUgcmVqZWN0ZWQuIElmIHdlIHdhbnQgdG8gYWxsb3cNCj4+PiBhbiBN VEEgdG8gZG8gcHVueWNvZGUgY29udmVyc2lvbiwgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaW4N Cj4+PiA1MzM2YmlzLTAwIG5lZWRzIHRvIGJlIHJldmlzZWQuDQo+Pj4gLi4uDQo+Pj4gICAgIA0K Pj4NCj4+IEkgb2J2aW91c2x5IHdhcyBub3QgY2xlYXI7IGxldCBtZSB0cnkgYWdhaW4uICBOb3Ro aW5nIHRoaXMgV0cNCj4+IGRvZXMgY2FuIGNoYW5nZSBiYXNpYyByZXF1aXJlbWVudHMgb3IgZmxl eGliaWxpdGllcyBpbiA1MzIxIG9yDQo+PiA1MzIyIGV4Y2VwdCBpbiB0aGUgY29udGV4dCBvZiBz eXN0ZW1zIGFkdmVydGlzaW5nIHRoZSBFQUkNCj4+IGV4dGVuc2lvbnMuICANCj4gVW5kZXJzdG9v ZC4gVGhlIGNvbnRleHQgb2YgdGhlIGFib3ZlIHBhcmFncmFwaCBmcm9tIDUzMzZiaXMtMDAgc2Vj dGlvbiANCj4gMy4yLCBpcyBhbiBNVEEgdGhhdCBzdXBwb3J0cyBVVEY4U01UUGJpcy4gSWYgc3Vj aCBhIHNlcnZlciBpcyBhbGxvd2VkIHRvIA0KPiBzdWJtaXQgPEFTQ0lJQG5vbi1BU0NJST4gdG8g YW5vdGhlciBNVEEgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IA0KPiBVVEY4U01UUGJpcywgdGhlbiB3 ZSBjYW5ub3QgcGxhY2UgYW55IG5ldyBydWxlcyBvbiB0aGF0IHNlcnZlciwgYW5kIGl0IA0KPiBp cyBib3VuZCBvbmx5IGJ5IGVhcmxpZXIgU01UUCBzdGFuZGFyZHMuIEJ1dCBteSBpbnRlcnByZXRh dGlvbiBvZiANCj4gNTMzNmJpcy0wMCBpcyB0aGF0IDxBU0NJSUBub24tQVNDSUk+IGNhbm5vdCBi ZSBzdWJtaXR0ZWQgdG8gYSANCj4gbm9uLVVURjhTTVRQYmlzIE1UQSwgc28gaXQgbXVzdCBtYWtl IG9uZSBvZiB0aGUgdGhyZWUgY2hvaWNlcyBpbiBzZWN0aW9uIA0KPiAzLjIuIFRoZXNlIGNob2lj ZXMgZG8gbm90IGluY2x1ZGUgZG9pbmcgYSBjb252ZXJzaW9uIG9mIHRoZSBkb21haW4sIA0KPiB1 bmxlc3MgaXQgaXMgYW4gTVNBLg0KDQoNCnNlY3Rpb24gMy4yIGluICA1MzM2YmlzLTAwIHNhaWQg IklmIGEgc2VydmVyIGFkdmVydGlzZXMgVVRGOFNNVFAgYW5kIHRoZSBjbGllbnQgZG9lcyBub3Qg cmVjb2duaXplIHRoZQ0KICAgZXh0ZW5zaW9uLCB0aGUgY2xpZW50IG1heSBzZW5kIGEgcmVndWxh ciBtZXNzYWdlIFtSRkMyODIxXSBhbmQNCiAgIFtSRkMyODIyXS4gIEluIHRoaXMgY2FzZSwgdGhl IGNsaWVudCBtYXkgY29udGludWUgdG8gdXNlIHRoZQ0KICAgW1JGQzM0OTBdIG9yIFtSRkM1ODkw XSBUb0FzY2lpKCkgdG8gZW5jb2RlIHRoZSBkb21haW4gcG9ydGlvbiBvZiBhbg0KICAgYWRkcmVz cy4gIg0KDQpzbyB0aGUgc210cCBtYXkgc2VuZCA8QVNDSUlAbm9uLUFTQ0lJPiBpZiB0aGUgY2xp ZW50IGNhbiBkbyB0b2FzY2lpIG9wZXJhdGlvbiB0byB0aGUgZG9tYWluIHBvcnRpb24gb2YgPEFT Q0lJQG5vbi1BU0NJST4uDQoNCmluIHRoaXMgY2FzZSwgdGhlIHNtdHAgd2lsbCByZWdhcmQgPEFT Q0lJQEFDRSBkb21haW4+IGFzIHRoZSByZmMyODIxIGFkZHJlc3MuDQoNCg0KPiANCg== From edainow@ca.afilias.info Wed Jul 14 05:29:03 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109BE3A67E9 for ; Wed, 14 Jul 2010 05:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8srlX-o-8LA for ; Wed, 14 Jul 2010 05:29:02 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 1018D3A6842 for ; Wed, 14 Jul 2010 05:29:01 -0700 (PDT) Message-ID: <4C3DAD89.7070003@ca.afilias.info> Date: Wed, 14 Jul 2010 08:28:57 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jiankang YAO References: <4C3B865C.2040503@ca.afilias.info><326D84CE7B092784C9F2229E@PST.JCK.COM><4C3C6319.4040101@ca.afilias.info> <479045079.10930@cnnic.cn> <479072539.10870@cnnic.cn> In-Reply-To: <479072539.10870@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: ima@ietf.org Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 12:29:03 -0000 On 7/13/2010 9:55 PM, Jiankang YAO wrote: > ----- Original Message ----- > From: "Ernie Dainow" > To: "John C Klensin" > Cc: > Sent: Wednesday, July 14, 2010 2:16 AM > Subject: Re: [EAI] mail bounce versus punycode conversion > > > >> John C Klensin wrote: >> >>> --On Tuesday, July 13, 2010 08:59 -0400 Ernie Dainow >>> wrote: >>> >>> >>> >>>> >>>> ... >>>> >>>> >>>>> The strongest thing that can be said, ideally with a citation >>>>> of 5321, is something like: >>>>> >>>>> >>>>> ; if theUTF8SMTPbis extension is not supported, >>>>> ; the MTA is required to be SMTP [RFC >>>>> 5321]-compliant ; only. Such an MTA is not >>>>> required to >>>>> ; convert the domain part to from U-label form to >>>>> ; A-label form. If it does not, the message may be >>>>> ; rejected or simply not delivered. Similarly, >>>>> ; if theUTF8SMTPbis extension is not supported, an >>>>> ; MUA or submission server (MSA) may perform >>>>> conversions ; to A-label form, but is not required >>>>> to do so. >>>>> >>>>> >>>>> >>>> According to section 3.2 in 5336bis-00, is >>>> an internationalized address and can't be submitted to an MTA >>>> that does not support UTF8SMTPbis. An MTA cannot rewrite such >>>> a header so the message must be rejected. If we want to allow >>>> an MTA to do punycode conversion, the following paragraph in >>>> 5336bis-00 needs to be revised. >>>> ... >>>> >>>> >>> I obviously was not clear; let me try again. Nothing this WG >>> does can change basic requirements or flexibilities in 5321 or >>> 5322 except in the context of systems advertising the EAI >>> extensions. >>> >> Understood. The context of the above paragraph from 5336bis-00 section >> 3.2, is an MTA that supports UTF8SMTPbis. If such a server is allowed to >> submit to another MTA that does not support >> UTF8SMTPbis, then we cannot place any new rules on that server, and it >> is bound only by earlier SMTP standards. But my interpretation of >> 5336bis-00 is that cannot be submitted to a >> non-UTF8SMTPbis MTA, so it must make one of the three choices in section >> 3.2. These choices do not include doing a conversion of the domain, >> unless it is an MSA. >> > section 3.2 in 5336bis-00 said "If a server advertises UTF8SMTP and the client does not recognize the > extension, the client may send a regular message [RFC2821] and > [RFC2822]. In this case, the client may continue to use the > [RFC3490] or [RFC5890] ToAscii() to encode the domain portion of an > address. " > > so the smtp may send if the client can do toascii operation to the domain portion of. > > in this case, the smtp will regard as the rfc2821 address. > > This is the case of SMTP ---> UTF8SMTPbis. The initial comment was the case of UTF8SMTPbis ---> SMTP. Perhaps we can make this section more clear and complete by enumerating all the possibilities. Sender Receiver ========== ========== SMTP ---> SMTP Legacy systems, not covered by these specifications. SMTP ---> UTF8SMTPbis Sender will send only ASCII@ASCII or ASCII@ACE. Both must be accepted by the receiver. UTF8SMTPbis ---> SMTP Sender can only send ASCII@ASCII or ASCII@ACE. Anything with non-ASCII in addresses is returned as a delivery failure (bounce), except for the case ASCII@non-ASCII which should be converted to ASCII@ACE so that it can be sent (if the rest of the message conforms to legacy email RFC 5321/5322). UTF8SMTPbis ---> UTF8SMTPbis Sender can send any combination of ASCII, non-ASCII, ACE. -Ernie From jyee@ca.afilias.info Wed Jul 14 11:46:11 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BEA3A6A71 for ; Wed, 14 Jul 2010 11:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3etLK2gZ0SOV for ; Wed, 14 Jul 2010 11:46:09 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id A65DD3A6A5A for ; Wed, 14 Jul 2010 11:46:09 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1OZ6yJ-0000pl-3l for ima@ietf.org; Wed, 14 Jul 2010 18:46:19 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OZ6yJ-0007Qy-3S for ima@ietf.org; Wed, 14 Jul 2010 18:46:19 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 14:46:18 -0400 Message-Id: <1D6ABA8C-9936-41EA-8354-09816F1390DF@ca.afilias.info> To: "ima@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [EAI] Agenda for IETF 78 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:46:11 -0000 All, The agenda for IETF78 meeting is posted on IETF http://www.ietf.org/proceedings/78/agenda/eai.txt The meeting scheduled to meet from 9:00am - 11:30am Central European = Time on Friday July 30. Please review and provide comments or propose other items to current = agenda items. We have until 17:00 PT (24:00 UTC) Monday, July 19 for = final revision. Joseph Yee co chair of EAI= From Shawn.Steele@microsoft.com Wed Jul 14 11:58:44 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0A93A69AC for ; Wed, 14 Jul 2010 11:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq4omxbyYbt1 for ; Wed, 14 Jul 2010 11:58:43 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4A4F73A6972 for ; Wed, 14 Jul 2010 11:58:43 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 14 Jul 2010 11:58:52 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0180.004; Wed, 14 Jul 2010 11:58:52 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: ulabel Thread-Index: Acsjhc+Du1fBGOdgRmaryK286TkeUw== Date: Wed, 14 Jul 2010 18:59:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:58:44 -0000 Whatever you think's best. I can't get very excited about nomenclature :),= I just have the one minor concern about what ulabel means to me, but I can= 't even get very worked up about that :) I have a very mild preference for utf-8 in contexts where UTF-8 is interest= ing. (Internally, I expect most windows apps to store email addresses in U= TF-16 WCHARS as that's what our native data/string types are, so u* as in "= Unicode" could still be vague in some contexts. Utf8* would be very clear = that UTF-8 is expected and not some other form of Unicode). IDNA didn't ca= re about the encoding of the Unicode, so U-Label works for it. That said, I reiterate that I've said way more words on this topic than I r= eally have the passion for, whatever's easy for the authors is fine with me= . I mildly agree that consistency between docs would be nice, but I can't = even get worked up about that either. -Shawn ----- Original Message ----- From: "Shawn Steele" To: Sent: Wednesday, July 14, 2010 5:58 AM Subject: Re: [EAI] ulabel >> the user may confuse the old label and new label. >> but label and uLabel is easy to de differented. >=20 > Ulabel makes me wary because its use in IDN presumes there's an alabel. = So the connotations make me uneasy (whether that's reasonable or not). Ulabel was prevented before idna2008 defined a u-label and a-label. ulabel may be similar to u-labe. but we will not confuse Umailbox with u-label. so I think that we still keep Umailbox, Ucharacter, Uatom...... the general name of all the labels including Umailbox, Ucharacter and Ua= tom may be utf-8label. >=20 > So I'd prefer utf8-label:) >=20 > -Shawn > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From edainow@ca.afilias.info Wed Jul 14 14:43:40 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAF23A69F9 for ; Wed, 14 Jul 2010 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.005 X-Spam-Level: X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvlUt-Yfgxh2 for ; Wed, 14 Jul 2010 14:43:38 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id CAB903A6A40 for ; Wed, 14 Jul 2010 14:43:38 -0700 (PDT) Message-ID: <4C3E2F89.2040601@ca.afilias.info> Date: Wed, 14 Jul 2010 17:43:37 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: YAO Jiankang , Shawn Steele , ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:43:40 -0000 On 7/14/2010 2:59 PM, Shawn Steele wrote: > Whatever you think's best. I can't get very excited about nomenclature :), I just have the one minor concern about what ulabel means to me, but I can't even get very worked up about that :) > > I have a very mild preference for utf-8 in contexts where UTF-8 is interesting. (Internally, I expect most windows apps to store email addresses in UTF-16 WCHARS as that's what our native data/string types are, so u* as in "Unicode" could still be vague in some contexts. Utf8* would be very clear that UTF-8 is expected and not some other form of Unicode). IDNA didn't care about the encoding of the Unicode, so U-Label works for it. > > That said, I reiterate that I've said way more words on this topic than I really have the passion for, whatever's easy for the authors is fine with me. I mildly agree that consistency between docs would be nice, but I can't even get worked up about that either. > Consistency is important to support best software engineering practices. If there is inconsistency between documents and different definitions that are in fact equivalent, you are increasing the probability of interoperability failures. One implementer might conclude that the different definitions are equivalent and use common code; another implementer might follow the letter of the spec and write separate code for each set of equivalent functions. In the first case you are increasing the chance of error through misinterpretation of what is equivalent. In the second case you are increasing the chance of error through doubling the amount of code that needs to be written and tested. For example, in rfc5335bis-00 we have mailbox = name-addr / addr-spec / utf8-addr-spec utf8-atom = [CFWS] 1*utf8-atext [CFWS] while in rfc5336bis-00 we have these definitions uMailbox = uLocal-part "@" uDomain uAtom = 1*ucharacter Mailbox is certainly the same in both contexts. I don't know if the definition of atom needs to be different or not. One common set of ABNF across documents should be a goal of subsequent drafts. For example put them all in rfc5335bis-00 and refer back to that document where necessary. If different definitions are necessary for different documents, they should have names that are more distinctly different than utf8-atom and uAtom. -Ernie > -Shawn > > ----- Original Message ----- > From: "Shawn Steele" > To: > Sent: Wednesday, July 14, 2010 5:58 AM > Subject: Re: [EAI] ulabel > > > >>> the user may confuse the old label and new label. >>> but label and uLabel is easy to de differented. >>> >> Ulabel makes me wary because its use in IDN presumes there's an alabel. So the connotations make me uneasy (whether that's reasonable or not). >> > Ulabel was prevented before idna2008 defined a u-label and a-label. > ulabel may be similar to u-labe. > > but we will not confuse Umailbox with u-label. > > so I think that we still keep Umailbox, Ucharacter, Uatom...... > > the general name of all the labels including Umailbox, Ucharacter and Uatom may be utf-8label. > > > > >> So I'd prefer utf8-label:) >> >> -Shawn >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima >> > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From Shawn.Steele@microsoft.com Wed Jul 14 15:32:03 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545F53A6814 for ; Wed, 14 Jul 2010 15:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm8dmDAEkctj for ; Wed, 14 Jul 2010 15:32:01 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 45AD43A67D7 for ; Wed, 14 Jul 2010 15:32:01 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 14 Jul 2010 15:32:11 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0180.004; Wed, 14 Jul 2010 15:32:10 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: mail bounce versus punycode conversion Thread-Index: Acsjo02zgGJh8mW6QSqrNJTjhdx7LA== Date: Wed, 14 Jul 2010 22:32:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] mail bounce versus punycode conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:32:03 -0000 > Sender Receiver > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > SMTP ---> SMTP > Legacy systems, not covered by these specifications. > SMTP ---> UTF8SMTPbis > Sender will send only ASCII@ASCII or ASCII@ACE. Both must be accepted by= =20 > the receiver. > UTF8SMTPbis ---> SMTP >Sender can only send ASCII@ASCII or ASCII@ACE. >Anything with non-ASCII in addresses is returned as a delivery failure=20 > (bounce), except for the case ASCII@non-ASCII which should be converted=20 > to ASCII@ACE so that it can be sent (if the rest of the message conforms= =20 > to legacy email RFC 5321/5322). For the 2nd case, it's not really different than the first, except that we = have the opportunity to suggest that the receiver recognize ACE. I wouldn'= t say MUST though. For the 3rd case, again, it's limited to the legacy specifications. Again,= we can mention that the sender could consider punycode, but there are othe= r reasons that might not work, so I think it's fair to say it depends on th= e legacy specifications. There's not much point to encouraging the sender = to do something that a legacy sender might not do. =20 In short, I guess what I'm suggesting is that an EAI mail server must recog= nize the legacy stuff anyway, since it may need to send/receive regular SMT= P traffic. I think that overly specifying legacy interaction may unnecessa= rily complicate the main focus of these specs, which is to support UTF-8 ma= il. =20 -Shawn From Shawn.Steele@microsoft.com Thu Jul 15 10:14:44 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14563A69C0 for ; Thu, 15 Jul 2010 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6kpuoQYN3U0 for ; Thu, 15 Jul 2010 10:14:42 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A08743A68B2 for ; Thu, 15 Jul 2010 10:14:41 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 15 Jul 2010 10:14:52 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0180.004; Thu, 15 Jul 2010 10:14:52 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: My mail was acting oddly. Thread-Index: AcskQTdlbagnfkLNSFWuorFx7yU1DA== Importance: low X-Priority: 5 Date: Thu, 15 Jul 2010 17:14:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [EAI] My mail was acting oddly. X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:14:44 -0000 Something odd happened to my mail, so I received some stuff after a long de= lay, and perhaps out-of-order. If you're still expecting a reply from me o= n something, I may have missed it. -Shawn From yaojk@cnnic.cn Thu Jul 15 20:02:28 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4886B3A6830 for ; Thu, 15 Jul 2010 20:02:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe6Wda1tAowh for ; Thu, 15 Jul 2010 20:02:27 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id D34D83A6814 for ; Thu, 15 Jul 2010 20:02:25 -0700 (PDT) Received: (eyou send program); Fri, 16 Jul 2010 11:02:36 +0800 Message-ID: <479249356.04518@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 16 Jul 2010 11:02:36 +0800 Message-ID: <2778163CA4DC436A91D4531E74B73A6E@LENOVO47E041CF> From: "Jiankang YAO" To: "Ernie Dainow" , "Shawn Steele" , References: <479143835.17877@cnnic.cn> Date: Fri, 16 Jul 2010 11:02:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 03:02:28 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVybmllIERhaW5vdyIgPGVk YWlub3dAY2EuYWZpbGlhcy5pbmZvPg0KVG86ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5j bj47ICJTaGF3biBTdGVlbGUiIDxTaGF3bi5TdGVlbGVAbWljcm9zb2Z0LmNvbT47IDxpbWFAaWV0 Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVseSAxNSwgMjAxMCA1OjQzIEFNDQpTdWJqZWN0OiBS ZTogW0VBSV0gdWxhYmVsDQoNCg0KPiBPbiA3LzE0LzIwMTAgMjo1OSBQTSwgU2hhd24gU3RlZWxl IHdyb3RlOg0KPj4gV2hhdGV2ZXIgeW91IHRoaW5rJ3MgYmVzdC4gIEkgY2FuJ3QgZ2V0IHZlcnkg ZXhjaXRlZCBhYm91dCBub21lbmNsYXR1cmUgOiksIEkganVzdCBoYXZlIHRoZSBvbmUgbWlub3Ig Y29uY2VybiBhYm91dCB3aGF0IHVsYWJlbCBtZWFucyB0byBtZSwgYnV0IEkgY2FuJ3QgZXZlbiBn ZXQgdmVyeSB3b3JrZWQgdXAgYWJvdXQgdGhhdCA6KQ0KPj4NCj4+IEkgaGF2ZSBhIHZlcnkgbWls ZCBwcmVmZXJlbmNlIGZvciB1dGYtOCBpbiBjb250ZXh0cyB3aGVyZSBVVEYtOCBpcyBpbnRlcmVz dGluZy4gIChJbnRlcm5hbGx5LCBJIGV4cGVjdCBtb3N0IHdpbmRvd3MgYXBwcyB0byBzdG9yZSBl bWFpbCBhZGRyZXNzZXMgaW4gVVRGLTE2IFdDSEFSUyBhcyB0aGF0J3Mgd2hhdCBvdXIgbmF0aXZl IGRhdGEvc3RyaW5nIHR5cGVzIGFyZSwgc28gdSogYXMgaW4gIlVuaWNvZGUiIGNvdWxkIHN0aWxs IGJlIHZhZ3VlIGluIHNvbWUgY29udGV4dHMuICBVdGY4KiB3b3VsZCBiZSB2ZXJ5IGNsZWFyIHRo YXQgVVRGLTggaXMgZXhwZWN0ZWQgYW5kIG5vdCBzb21lIG90aGVyIGZvcm0gb2YgVW5pY29kZSku ICBJRE5BIGRpZG4ndCBjYXJlIGFib3V0IHRoZSBlbmNvZGluZyBvZiB0aGUgVW5pY29kZSwgc28g VS1MYWJlbCB3b3JrcyBmb3IgaXQuDQo+Pg0KPj4gVGhhdCBzYWlkLCBJIHJlaXRlcmF0ZSB0aGF0 IEkndmUgc2FpZCB3YXkgbW9yZSB3b3JkcyBvbiB0aGlzIHRvcGljIHRoYW4gSSByZWFsbHkgaGF2 ZSB0aGUgcGFzc2lvbiBmb3IsIHdoYXRldmVyJ3MgZWFzeSBmb3IgdGhlIGF1dGhvcnMgaXMgZmlu ZSB3aXRoIG1lLiAgSSBtaWxkbHkgYWdyZWUgdGhhdCBjb25zaXN0ZW5jeSBiZXR3ZWVuIGRvY3Mg d291bGQgYmUgbmljZSwgYnV0IEkgY2FuJ3QgZXZlbiBnZXQgd29ya2VkIHVwIGFib3V0IHRoYXQg ZWl0aGVyLg0KPj4gICAgDQo+IA0KPiBDb25zaXN0ZW5jeSBpcyBpbXBvcnRhbnQgdG8gc3VwcG9y dCBiZXN0IHNvZnR3YXJlIGVuZ2luZWVyaW5nIHByYWN0aWNlcy4gDQoNCnllcy4NCg0Kc28gU2hh d24sIGFuZCBBYmVsLCB3aWxsIHdlIGtlZXAgdXRmLThtYWlsYm94IG9yIHVtYWlsYm94Pw0KaW4g bmV4dCB2ZXJzaW9uLCB3ZSBtYXkgbWFrZSBpdCB0byBiZSBzYW1lIGluIG91ciBkcmFmdHMuDQoN CkppYW5rYW5nICBZYW8= From abelyang@twnic.net.tw Thu Jul 15 21:15:51 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9663A6820 for ; Thu, 15 Jul 2010 21:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw0bKaCjnGsB for ; Thu, 15 Jul 2010 21:15:50 -0700 (PDT) Received: from twnic.net.tw (unknown [IPv6:2001:288:4:1:21e:8cff:fe22:a99d]) by core3.amsl.com (Postfix) with ESMTP id 8924E3A67F0 for ; Thu, 15 Jul 2010 21:15:49 -0700 (PDT) Received: from abelnb2 (pc094.twnic.net.tw [211.72.211.94]) by twnic.net.tw (8.14.3/8.14.3) with SMTP id o6G4FOfp021278; Fri, 16 Jul 2010 12:15:27 +0800 Message-ID: From: "Abel" To: "Jiankang YAO" , "Ernie Dainow" , "Shawn Steele" , References: <479143835.17877@cnnic.cn> <479249356.04518@cnnic.cn> In-Reply-To: <479249356.04518@cnnic.cn> Date: Fri, 16 Jul 2010 12:15:46 +0800 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Scanned-By: MIMEDefang 2.67 on 211.72.210.250 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 04:15:51 -0000 >> On 7/14/2010 2:59 PM, Shawn Steele wrote: >>> Whatever you think's best. I can't get very excited about nomenclature >>> :), I just have the one minor concern about what ulabel means to me, but >>> I can't even get very worked up about that :) >>> >>> I have a very mild preference for utf-8 in contexts where UTF-8 is >>> interesting. (Internally, I expect most windows apps to store email >>> addresses in UTF-16 WCHARS as that's what our native data/string types >>> are, so u* as in "Unicode" could still be vague in some contexts. Utf8* >>> would be very clear that UTF-8 is expected and not some other form of >>> Unicode). IDNA didn't care about the encoding of the Unicode, so >>> U-Label works for it. >>> >>> That said, I reiterate that I've said way more words on this topic than >>> I really have the passion for, whatever's easy for the authors is fine >>> with me. I mildly agree that consistency between docs would be nice, >>> but I can't even get worked up about that either. >>> >> >> Consistency is important to support best software engineering practices. > > yes. > > so Shawn, and Abel, will we keep utf-8mailbox or umailbox? > in next version, we may make it to be same in our drafts. > > Jiankang Yao I have no idea, and I will follow you. In the next version, we can check the term to each other and make it consistency. Abel > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From Shawn.Steele@microsoft.com Thu Jul 15 22:00:51 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7820A3A6883 for ; Thu, 15 Jul 2010 22:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIfXn53-pWXG for ; Thu, 15 Jul 2010 22:00:50 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 550293A6784 for ; Thu, 15 Jul 2010 22:00:50 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 15 Jul 2010 22:01:01 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0180.004; Thu, 15 Jul 2010 22:01:01 -0700 From: Shawn Steele To: Jiankang YAO , Ernie Dainow , "ima@ietf.org" Thread-Topic: [EAI] ulabel Thread-Index: AQHLJJNdEbcnhMXoeUumtbp6Tgn2A5Ky/S23 Date: Fri, 16 Jul 2010 05:01:01 +0000 Message-ID: References: <479143835.17877@cnnic.cn>, <2778163CA4DC436A91D4531E74B73A6E@LENOVO47E041CF> In-Reply-To: <2778163CA4DC436A91D4531E74B73A6E@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 05:00:51 -0000 V2hhdGV2ZXIgeW91J2QgbGlrZS4gIENvbnNpc3RlbmN5IGlzIGdvb2QgYmV0d2VlbiBkb2NzLiAg SSdtIGZpbmUgd2l0aCB1bWFpbGJveC4NCg0KSSB0aGluayB0aGUgbW9yZSBpbnRlcmVzdGluZyB0 aGluZyBpcyB0byBOT1QgcmVkZWZpbmUgdGhlIHRlcm1zIGluIGRpZmZlcmVudCB3YXlzIGluIGRp ZmZlcmVudCBwbGFjZXMuICBJIHRoaW5rIGl0J2QgYmUgYmV0dGVyPyBmb3IgNTMzNmJpcyB0byBw b2ludCB0byB0aGUgZGVmaW5pdGlvbnMgb2YgbWFpbGJveGVzIGluIDUzMzViaXM/ICBFZzogNTMz NSBzaG91bGQgZm9jdXMgb24gaGVhZGVycyAmIGFkZHJlc3NlcywgYW5kIDUzMzYgc2hvdWxkIGZv Y3VzIG9uIGhvdyBTTVRQIGhhbmRsZXMgdGhvc2UgY2hhbmdlcz8NCg0KLVNoYXduDQoNCu+jou+j kO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEppYW5r YW5nIFlBTyBbeWFvamtAY25uaWMuY25dDQpTZW50OiBUaHVyc2RheSwgSnVseSAxNSwgMjAxMCA4 OjAyIFBNDQpUbzogRXJuaWUgRGFpbm93OyBTaGF3biBTdGVlbGU7IGltYUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtFQUldIHVsYWJlbA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG cm9tOiAiRXJuaWUgRGFpbm93IiA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+DQpUbzogIllBTyBK aWFua2FuZyIgPHlhb2prQGNubmljLmNuPjsgIlNoYXduIFN0ZWVsZSIgPFNoYXduLlN0ZWVsZUBt aWNyb3NvZnQuY29tPjsgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE1LCAy MDEwIDU6NDMgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSB1bGFiZWwNCg0KDQo+IE9uIDcvMTQvMjAx MCAyOjU5IFBNLCBTaGF3biBTdGVlbGUgd3JvdGU6DQo+PiBXaGF0ZXZlciB5b3UgdGhpbmsncyBi ZXN0LiAgSSBjYW4ndCBnZXQgdmVyeSBleGNpdGVkIGFib3V0IG5vbWVuY2xhdHVyZSA6KSwgSSBq dXN0IGhhdmUgdGhlIG9uZSBtaW5vciBjb25jZXJuIGFib3V0IHdoYXQgdWxhYmVsIG1lYW5zIHRv IG1lLCBidXQgSSBjYW4ndCBldmVuIGdldCB2ZXJ5IHdvcmtlZCB1cCBhYm91dCB0aGF0IDopDQo+ Pg0KPj4gSSBoYXZlIGEgdmVyeSBtaWxkIHByZWZlcmVuY2UgZm9yIHV0Zi04IGluIGNvbnRleHRz IHdoZXJlIFVURi04IGlzIGludGVyZXN0aW5nLiAgKEludGVybmFsbHksIEkgZXhwZWN0IG1vc3Qg d2luZG93cyBhcHBzIHRvIHN0b3JlIGVtYWlsIGFkZHJlc3NlcyBpbiBVVEYtMTYgV0NIQVJTIGFz IHRoYXQncyB3aGF0IG91ciBuYXRpdmUgZGF0YS9zdHJpbmcgdHlwZXMgYXJlLCBzbyB1KiBhcyBp biAiVW5pY29kZSIgY291bGQgc3RpbGwgYmUgdmFndWUgaW4gc29tZSBjb250ZXh0cy4gIFV0Zjgq IHdvdWxkIGJlIHZlcnkgY2xlYXIgdGhhdCBVVEYtOCBpcyBleHBlY3RlZCBhbmQgbm90IHNvbWUg b3RoZXIgZm9ybSBvZiBVbmljb2RlKS4gIElETkEgZGlkbid0IGNhcmUgYWJvdXQgdGhlIGVuY29k aW5nIG9mIHRoZSBVbmljb2RlLCBzbyBVLUxhYmVsIHdvcmtzIGZvciBpdC4NCj4+DQo+PiBUaGF0 IHNhaWQsIEkgcmVpdGVyYXRlIHRoYXQgSSd2ZSBzYWlkIHdheSBtb3JlIHdvcmRzIG9uIHRoaXMg dG9waWMgdGhhbiBJIHJlYWxseSBoYXZlIHRoZSBwYXNzaW9uIGZvciwgd2hhdGV2ZXIncyBlYXN5 IGZvciB0aGUgYXV0aG9ycyBpcyBmaW5lIHdpdGggbWUuICBJIG1pbGRseSBhZ3JlZSB0aGF0IGNv bnNpc3RlbmN5IGJldHdlZW4gZG9jcyB3b3VsZCBiZSBuaWNlLCBidXQgSSBjYW4ndCBldmVuIGdl dCB3b3JrZWQgdXAgYWJvdXQgdGhhdCBlaXRoZXIuDQo+Pg0KPg0KPiBDb25zaXN0ZW5jeSBpcyBp bXBvcnRhbnQgdG8gc3VwcG9ydCBiZXN0IHNvZnR3YXJlIGVuZ2luZWVyaW5nIHByYWN0aWNlcy4N Cg0KeWVzLg0KDQpzbyBTaGF3biwgYW5kIEFiZWwsIHdpbGwgd2Uga2VlcCB1dGYtOG1haWxib3gg b3IgdW1haWxib3g/DQppbiBuZXh0IHZlcnNpb24sIHdlIG1heSBtYWtlIGl0IHRvIGJlIHNhbWUg aW4gb3VyIGRyYWZ0cy4NCg0KSmlhbmthbmcgIFlhbw== From yaojk@cnnic.cn Fri Jul 16 00:05:55 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE273A6843 for ; Fri, 16 Jul 2010 00:05:55 -0700 (PDT) X-Quarantine-ID: <7za6lCKQpK0p> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=1.849, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7za6lCKQpK0p for ; Fri, 16 Jul 2010 00:05:54 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 2134C3A680A for ; Fri, 16 Jul 2010 00:05:53 -0700 (PDT) Received: (eyou send program); Fri, 16 Jul 2010 15:06:04 +0800 Message-ID: <479263964.27698@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 16 Jul 2010 15:06:04 +0800 Message-ID: <185792DAF85743FFB0C81775790E76F7@LENOVO47E041CF> From: "Jiankang YAO" To: "Shawn Steele" , "Ernie Dainow" , References: <479143835.17877@cnnic.cn>, <2778163CA4DC436A91D4531E74B73A6E@LENOVO47E041CF> <479256464.04416@cnnic.cn> Date: Fri, 16 Jul 2010 15:06:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 07:05:55 -0000 dGhlIHRyYWRpb24gaXMgdGhhdCByZmMyODIxIGFuZCByZmMyODgyMiwgcmZjNTMyMSBhbmQgcmZj NTMyMiBoYXMgc2ltaWxhciBkZWZpbml0aW9ucyBvZiBtYWlsYm94Lg0KDQpib3RoIGhlYWRuZXIg YW5kIHNtdHAgZG9jdW1lbnRzIG5lZWQgbWFpbGJveCBkZWZpbnRpb24sIGVpdGhlciB5b3Ugc2Fp ZCB5b3UgcmVmZXJlbmNlIGl0IG9yIHJlcGVhdCBpdCBpcyBzYW1lLg0KDQpldmVuIHJmYzUzMzZi aXMgcmVmZXJlbmNlIHJmYzUzMzViaXMnZGVmaW5pdG9uLCByZmM1MzM2YmlzIHNob3VsZCBiZSBz dGlsbCByZXBlYXQgdGhlIG1haWxib3gnZGVmaW50aW9uLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQpGcm9tOiAiU2hhd24gU3RlZWxlIiA8U2hhd24uU3RlZWxlQG1pY3Jvc29m dC5jb20+DQpUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPjsgIkVybmllIERhaW5v dyIgPGVkYWlub3dAY2EuYWZpbGlhcy5pbmZvPjsgPGltYUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRh eSwgSnVseSAxNiwgMjAxMCAxOjAxIFBNDQpTdWJqZWN0OiBSRTogW0VBSV0gdWxhYmVsDQoNCg0K PiBXaGF0ZXZlciB5b3UnZCBsaWtlLiAgQ29uc2lzdGVuY3kgaXMgZ29vZCBiZXR3ZWVuIGRvY3Mu ICBJJ20gZmluZSB3aXRoIHVtYWlsYm94Lg0KPiANCj4gSSB0aGluayB0aGUgbW9yZSBpbnRlcmVz dGluZyB0aGluZyBpcyB0byBOT1QgcmVkZWZpbmUgdGhlIHRlcm1zIGluIGRpZmZlcmVudCB3YXlz IGluIGRpZmZlcmVudCBwbGFjZXMuICBJIHRoaW5rIGl0J2QgYmUgYmV0dGVyPyBmb3IgNTMzNmJp cyB0byBwb2ludCB0byB0aGUgZGVmaW5pdGlvbnMgb2YgbWFpbGJveGVzIGluIDUzMzViaXM/ICBF ZzogNTMzNSBzaG91bGQgZm9jdXMgb24gaGVhZGVycyAmIGFkZHJlc3NlcywgYW5kIDUzMzYgc2hv dWxkIGZvY3VzIG9uIGhvdyBTTVRQIGhhbmRsZXMgdGhvc2UgY2hhbmdlcz8NCj4gDQo+IC1TaGF3 bg0KPiANCj4g76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmQ0KPiBodHRwOi8vYmxvZ3MubXNk bi5jb20vc2hhd25zdGUNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEZyb206IEppYW5rYW5nIFlBTyBbeWFvamtAY25uaWMuY25dDQo+IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDE1LCAyMDEwIDg6MDIgUE0NCj4gVG86IEVybmllIERhaW5vdzsgU2hh d24gU3RlZWxlOyBpbWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtFQUldIHVsYWJlbA0KPiAN Cj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiRXJuaWUgRGFpbm93IiA8 ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+DQo+IFRvOiAiWUFPIEppYW5rYW5nIiA8eWFvamtAY25u aWMuY24+OyAiU2hhd24gU3RlZWxlIiA8U2hhd24uU3RlZWxlQG1pY3Jvc29mdC5jb20+OyA8aW1h QGlldGYub3JnPg0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAxNSwgMjAxMCA1OjQzIEFNDQo+IFN1 YmplY3Q6IFJlOiBbRUFJXSB1bGFiZWwNCj4gDQo+IA0KPj4gT24gNy8xNC8yMDEwIDI6NTkgUE0s IFNoYXduIFN0ZWVsZSB3cm90ZToNCj4+PiBXaGF0ZXZlciB5b3UgdGhpbmsncyBiZXN0LiAgSSBj YW4ndCBnZXQgdmVyeSBleGNpdGVkIGFib3V0IG5vbWVuY2xhdHVyZSA6KSwgSSBqdXN0IGhhdmUg dGhlIG9uZSBtaW5vciBjb25jZXJuIGFib3V0IHdoYXQgdWxhYmVsIG1lYW5zIHRvIG1lLCBidXQg SSBjYW4ndCBldmVuIGdldCB2ZXJ5IHdvcmtlZCB1cCBhYm91dCB0aGF0IDopDQo+Pj4NCj4+PiBJ IGhhdmUgYSB2ZXJ5IG1pbGQgcHJlZmVyZW5jZSBmb3IgdXRmLTggaW4gY29udGV4dHMgd2hlcmUg VVRGLTggaXMgaW50ZXJlc3RpbmcuICAoSW50ZXJuYWxseSwgSSBleHBlY3QgbW9zdCB3aW5kb3dz IGFwcHMgdG8gc3RvcmUgZW1haWwgYWRkcmVzc2VzIGluIFVURi0xNiBXQ0hBUlMgYXMgdGhhdCdz IHdoYXQgb3VyIG5hdGl2ZSBkYXRhL3N0cmluZyB0eXBlcyBhcmUsIHNvIHUqIGFzIGluICJVbmlj b2RlIiBjb3VsZCBzdGlsbCBiZSB2YWd1ZSBpbiBzb21lIGNvbnRleHRzLiAgVXRmOCogd291bGQg YmUgdmVyeSBjbGVhciB0aGF0IFVURi04IGlzIGV4cGVjdGVkIGFuZCBub3Qgc29tZSBvdGhlciBm b3JtIG9mIFVuaWNvZGUpLiAgSUROQSBkaWRuJ3QgY2FyZSBhYm91dCB0aGUgZW5jb2Rpbmcgb2Yg dGhlIFVuaWNvZGUsIHNvIFUtTGFiZWwgd29ya3MgZm9yIGl0Lg0KPj4+DQo+Pj4gVGhhdCBzYWlk LCBJIHJlaXRlcmF0ZSB0aGF0IEkndmUgc2FpZCB3YXkgbW9yZSB3b3JkcyBvbiB0aGlzIHRvcGlj IHRoYW4gSSByZWFsbHkgaGF2ZSB0aGUgcGFzc2lvbiBmb3IsIHdoYXRldmVyJ3MgZWFzeSBmb3Ig dGhlIGF1dGhvcnMgaXMgZmluZSB3aXRoIG1lLiAgSSBtaWxkbHkgYWdyZWUgdGhhdCBjb25zaXN0 ZW5jeSBiZXR3ZWVuIGRvY3Mgd291bGQgYmUgbmljZSwgYnV0IEkgY2FuJ3QgZXZlbiBnZXQgd29y a2VkIHVwIGFib3V0IHRoYXQgZWl0aGVyLg0KPj4+DQo+Pg0KPj4gQ29uc2lzdGVuY3kgaXMgaW1w b3J0YW50IHRvIHN1cHBvcnQgYmVzdCBzb2Z0d2FyZSBlbmdpbmVlcmluZyBwcmFjdGljZXMuDQo+ IA0KPiB5ZXMuDQo+IA0KPiBzbyBTaGF3biwgYW5kIEFiZWwsIHdpbGwgd2Uga2VlcCB1dGYtOG1h aWxib3ggb3IgdW1haWxib3g/DQo+IGluIG5leHQgdmVyc2lvbiwgd2UgbWF5IG1ha2UgaXQgdG8g YmUgc2FtZSBpbiBvdXIgZHJhZnRzLg0KPiANCj4gSmlhbmthbmcgIFlhbw== From Shawn.Steele@microsoft.com Fri Jul 16 00:24:54 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BAB3A6895 for ; Fri, 16 Jul 2010 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxOKwQl2+zaW for ; Fri, 16 Jul 2010 00:24:53 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A929E3A67AE for ; Fri, 16 Jul 2010 00:24:53 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Jul 2010 00:25:05 -0700 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.215]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0180.004; Fri, 16 Jul 2010 00:25:04 -0700 From: Shawn Steele To: Jiankang YAO , Ernie Dainow , "ima@ietf.org" Thread-Topic: [EAI] ulabel Thread-Index: AQHLJJNdEbcnhMXoeUumtbp6Tgn2A5KzIa6KgAAEu5M= Date: Fri, 16 Jul 2010 07:23:26 +0000 Message-ID: References: <479143835.17877@cnnic.cn>, <2778163CA4DC436A91D4531E74B73A6E@LENOVO47E041CF> <479256464.04416@cnnic.cn>, <185792DAF85743FFB0C81775790E76F7@LENOVO47E041CF> In-Reply-To: <185792DAF85743FFB0C81775790E76F7@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 07:24:54 -0000 UmVwZWF0aW5nIGlzIGZpbmUsIHNvIGxvbmcgYXMgdGhleSdyZSB0aGUgZXhhY3RseSB0aGUgc2Ft ZSAod2hpY2ggdGhleSBhcmVuJ3QgcmlnaHQgbm93KS4gIFNvIHJlZmVyZW5jaW5nIHNlZW1zIHNh ZmVyIHRvIG1lLiAgVGhlIHByb2JsZW0gd2l0aCByZXBlYXRpbmcgaXMgdGhhdCBpZiBzb21ldGhp bmcncyBzbGlnaHRseSBkaWZmZXJlbnQsIHRoZW4gYW55IGFtYmlndWl0eSBiZWNvbWVzIG1vcmUg Y29uZnVzaW5nLg0KDQotU2hhd24NCg0K76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmQ0KaHR0 cDovL2Jsb2dzLm1zZG4uY29tL3NoYXduc3RlDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogSmlhbmthbmcgWUFPIFt5YW9qa0Bjbm5pYy5jbl0NClNl bnQ6IEZyaWRheSwgSnVseSAxNiwgMjAxMCAxMjowNiBBTQ0KVG86IFNoYXduIFN0ZWVsZTsgRXJu aWUgRGFpbm93OyBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSB1bGFiZWwNCg0KdGhl IHRyYWRpb24gaXMgdGhhdCByZmMyODIxIGFuZCByZmMyODgyMiwgcmZjNTMyMSBhbmQgcmZjNTMy MiBoYXMgc2ltaWxhciBkZWZpbml0aW9ucyBvZiBtYWlsYm94Lg0KDQpib3RoIGhlYWRuZXIgYW5k IHNtdHAgZG9jdW1lbnRzIG5lZWQgbWFpbGJveCBkZWZpbnRpb24sIGVpdGhlciB5b3Ugc2FpZCB5 b3UgcmVmZXJlbmNlIGl0IG9yIHJlcGVhdCBpdCBpcyBzYW1lLg0KDQpldmVuIHJmYzUzMzZiaXMg cmVmZXJlbmNlIHJmYzUzMzViaXMnZGVmaW5pdG9uLCByZmM1MzM2YmlzIHNob3VsZCBiZSBzdGls bCByZXBlYXQgdGhlIG1haWxib3gnZGVmaW50aW9uLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCkZyb206ICJTaGF3biBTdGVlbGUiIDxTaGF3bi5TdGVlbGVAbWljcm9zb2Z0LmNv bT4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+OyAiRXJuaWUgRGFpbm93IiA8 ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+OyA8aW1hQGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBK dWx5IDE2LCAyMDEwIDE6MDEgUE0NClN1YmplY3Q6IFJFOiBbRUFJXSB1bGFiZWwNCg0KDQo+IFdo YXRldmVyIHlvdSdkIGxpa2UuICBDb25zaXN0ZW5jeSBpcyBnb29kIGJldHdlZW4gZG9jcy4gIEkn bSBmaW5lIHdpdGggdW1haWxib3guDQo+DQo+IEkgdGhpbmsgdGhlIG1vcmUgaW50ZXJlc3Rpbmcg dGhpbmcgaXMgdG8gTk9UIHJlZGVmaW5lIHRoZSB0ZXJtcyBpbiBkaWZmZXJlbnQgd2F5cyBpbiBk aWZmZXJlbnQgcGxhY2VzLiAgSSB0aGluayBpdCdkIGJlIGJldHRlcj8gZm9yIDUzMzZiaXMgdG8g cG9pbnQgdG8gdGhlIGRlZmluaXRpb25zIG9mIG1haWxib3hlcyBpbiA1MzM1YmlzPyAgRWc6IDUz MzUgc2hvdWxkIGZvY3VzIG9uIGhlYWRlcnMgJiBhZGRyZXNzZXMsIGFuZCA1MzM2IHNob3VsZCBm b2N1cyBvbiBob3cgU01UUCBoYW5kbGVzIHRob3NlIGNoYW5nZXM/DQo+DQo+IC1TaGF3bg0KPg0K PiDvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZDQo+IGh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9z aGF3bnN0ZQ0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEZyb206IEppYW5rYW5nIFlBTyBbeWFvamtAY25uaWMuY25dDQo+IFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDE1LCAyMDEwIDg6MDIgUE0NCj4gVG86IEVybmllIERhaW5vdzsgU2hhd24gU3RlZWxl OyBpbWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtFQUldIHVsYWJlbA0KPg0KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJFcm5pZSBEYWlub3ciIDxlZGFpbm93QGNh LmFmaWxpYXMuaW5mbz4NCj4gVG86ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj47ICJT aGF3biBTdGVlbGUiIDxTaGF3bi5TdGVlbGVAbWljcm9zb2Z0LmNvbT47IDxpbWFAaWV0Zi5vcmc+ DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE1LCAyMDEwIDU6NDMgQU0NCj4gU3ViamVjdDogUmU6 IFtFQUldIHVsYWJlbA0KPg0KPg0KPj4gT24gNy8xNC8yMDEwIDI6NTkgUE0sIFNoYXduIFN0ZWVs ZSB3cm90ZToNCj4+PiBXaGF0ZXZlciB5b3UgdGhpbmsncyBiZXN0LiAgSSBjYW4ndCBnZXQgdmVy eSBleGNpdGVkIGFib3V0IG5vbWVuY2xhdHVyZSA6KSwgSSBqdXN0IGhhdmUgdGhlIG9uZSBtaW5v ciBjb25jZXJuIGFib3V0IHdoYXQgdWxhYmVsIG1lYW5zIHRvIG1lLCBidXQgSSBjYW4ndCBldmVu IGdldCB2ZXJ5IHdvcmtlZCB1cCBhYm91dCB0aGF0IDopDQo+Pj4NCj4+PiBJIGhhdmUgYSB2ZXJ5 IG1pbGQgcHJlZmVyZW5jZSBmb3IgdXRmLTggaW4gY29udGV4dHMgd2hlcmUgVVRGLTggaXMgaW50 ZXJlc3RpbmcuICAoSW50ZXJuYWxseSwgSSBleHBlY3QgbW9zdCB3aW5kb3dzIGFwcHMgdG8gc3Rv cmUgZW1haWwgYWRkcmVzc2VzIGluIFVURi0xNiBXQ0hBUlMgYXMgdGhhdCdzIHdoYXQgb3VyIG5h dGl2ZSBkYXRhL3N0cmluZyB0eXBlcyBhcmUsIHNvIHUqIGFzIGluICJVbmljb2RlIiBjb3VsZCBz dGlsbCBiZSB2YWd1ZSBpbiBzb21lIGNvbnRleHRzLiAgVXRmOCogd291bGQgYmUgdmVyeSBjbGVh ciB0aGF0IFVURi04IGlzIGV4cGVjdGVkIGFuZCBub3Qgc29tZSBvdGhlciBmb3JtIG9mIFVuaWNv ZGUpLiAgSUROQSBkaWRuJ3QgY2FyZSBhYm91dCB0aGUgZW5jb2Rpbmcgb2YgdGhlIFVuaWNvZGUs IHNvIFUtTGFiZWwgd29ya3MgZm9yIGl0Lg0KPj4+DQo+Pj4gVGhhdCBzYWlkLCBJIHJlaXRlcmF0 ZSB0aGF0IEkndmUgc2FpZCB3YXkgbW9yZSB3b3JkcyBvbiB0aGlzIHRvcGljIHRoYW4gSSByZWFs bHkgaGF2ZSB0aGUgcGFzc2lvbiBmb3IsIHdoYXRldmVyJ3MgZWFzeSBmb3IgdGhlIGF1dGhvcnMg aXMgZmluZSB3aXRoIG1lLiAgSSBtaWxkbHkgYWdyZWUgdGhhdCBjb25zaXN0ZW5jeSBiZXR3ZWVu IGRvY3Mgd291bGQgYmUgbmljZSwgYnV0IEkgY2FuJ3QgZXZlbiBnZXQgd29ya2VkIHVwIGFib3V0 IHRoYXQgZWl0aGVyLg0KPj4+DQo+Pg0KPj4gQ29uc2lzdGVuY3kgaXMgaW1wb3J0YW50IHRvIHN1 cHBvcnQgYmVzdCBzb2Z0d2FyZSBlbmdpbmVlcmluZyBwcmFjdGljZXMuDQo+DQo+IHllcy4NCj4N Cj4gc28gU2hhd24sIGFuZCBBYmVsLCB3aWxsIHdlIGtlZXAgdXRmLThtYWlsYm94IG9yIHVtYWls Ym94Pw0KPiBpbiBuZXh0IHZlcnNpb24sIHdlIG1heSBtYWtlIGl0IHRvIGJlIHNhbWUgaW4gb3Vy IGRyYWZ0cy4NCj4NCj4gSmlhbmthbmcgIFlhbw== From tony@att.com Fri Jul 16 06:14:05 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DA73A68A2 for ; Fri, 16 Jul 2010 06:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDLkCV2RkH3X for ; Fri, 16 Jul 2010 06:14:04 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 7DD233A69F9 for ; Fri, 16 Jul 2010 06:14:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1279286054!58695262!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 4523 invoked from network); 16 Jul 2010 13:14:15 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Jul 2010 13:14:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6GDETeM013351 for ; Fri, 16 Jul 2010 09:14:29 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6GDEQXo013322 for ; Fri, 16 Jul 2010 09:14:26 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o6GDEA2r017501 for ; Fri, 16 Jul 2010 09:14:10 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o6GDE6dw017407 for ; Fri, 16 Jul 2010 09:14:06 -0400 Received: from [135.70.168.33] (vpn-135-70-168-33.vpn.mwst.att.com[135.70.168.33]) by maillennium.att.com (mailgw1) with ESMTP id <20100716131405gw100s4p3ee> (Authid: tony); Fri, 16 Jul 2010 13:14:06 +0000 X-Originating-IP: [135.70.168.33] Message-ID: <4C405B1D.30105@att.com> Date: Fri, 16 Jul 2010 09:14:05 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "ima@ietf.org" References: <479143835.17877@cnnic.cn>, <2778163CA4DC436A91D4531E74B73A6E@LENOVO47E041CF> <479256464.04416@cnnic.cn>, <185792DAF85743FFB0C81775790E76F7@LENOVO47E041CF> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [EAI] ulabel X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 13:14:05 -0000 +1 for referencing. Tony Hansen tony@att.com On 7/16/2010 3:23 AM, Shawn Steele wrote: > Repeating is fine, so long as they're the exactly the same (which they aren't right now). So referencing seems safer to me. The problem with repeating is that if something's slightly different, then any ambiguity becomes more confusing. > > > ________________________________________ > From: Jiankang YAO [yaojk@cnnic.cn] > Sent: Friday, July 16, 2010 12:06 AM > To: Shawn Steele; Ernie Dainow; ima@ietf.org > Subject: Re: [EAI] ulabel > > the tradion is that rfc2821 and rfc28822, rfc5321 and rfc5322 has similar definitions of mailbox. > > both headner and smtp documents need mailbox defintion, either you said you reference it or repeat it is same. > > even rfc5336bis reference rfc5335bis'definiton, rfc5336bis should be still repeat the mailbox'defintion. From wwwrun@core3.amsl.com Thu Jul 29 05:50:22 2010 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 83B7C28C166; Thu, 29 Jul 2010 05:50:22 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100729125022.83B7C28C166@core3.amsl.com> Date: Thu, 29 Jul 2010 05:50:22 -0700 (PDT) Cc: Internet Architecture Board , eai mailing list , eai chair , RFC Editor Subject: [EAI] Document Action: 'Mailing Lists and Internationalized Email Addresses' to Experimental RFC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 12:50:22 -0000 The IESG has approved the following document: - 'Mailing Lists and Internationalized Email Addresses ' as an Experimental RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-07.txt Technical Summary This document describes considerations for mailing lists with the introduction of internationalized email addresses in RFC 5335 and makes some specific recommendations on how mailing lists should act in various situations. Working Group Summary The EAI Working Group produced this document and it is the result of solid consensus in the WG for these recommendations. Document Quality Experimental implementations of this document are currently underway, though not completed. Personnel Pete Resnick is the Document Shepherd. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 1, change the 1st paragraph: OLD: This document describes considerations for mailing lists with the introduction of internationalized email addresses. NEW: This document describes considerations for mailing lists with the introduction of internationalized email addresses [RFC5335]. In Section 5, please change the 1st sentence of the 4th paragraph to read: OLD: These mailing list header fields contain URLs. NEW: Except for the List-ID header field, these mailing list header fields contain URLs [RFC3986]. In Section 5, 10th paragraph change: OLD: The List-ID header field uniquely identifies a list. NEW: The List-ID header field provides an opaque value that uniquely identifies a list. In Section 8, please replace the 1st paragraph with 2 paragraphs: OLD: Security considerations are discussed in the Framework document [EAI-Framework]. No further security considerations are raised by this document. NEW: Because use of both a UTF-8 address and an alt-address for the same entity introduces a potential ambiguity regarding the identity of list subscribers and message senders, implementers are advised to carefully handle authorization decisions regarding subscriptions, sender filters, and other common list administration features. For example, a binding between a UTF-8 address and an US-ASCII alt-address can be used by an attacker to deny another person admission to an EAI mailing list. Other relevant security considerations are discussed in the Framework document [EAI-Framework]. Please add [RFC5335] and [RFC3986] to the list of Normative References.