From Internet-Drafts@ietf.org Fri Apr 1 07:30:03 2011 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 320793A6870; Fri, 1 Apr 2011 07:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, 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 Q6ldA2f4QM-s; Fri, 1 Apr 2011 07:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF7F3A6845; Fri, 1 Apr 2011 07:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110401143002.5780.50749.idtracker@localhost> Date: Fri, 01 Apr 2011 07:30:02 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-rfc5337bis-dsn-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: Fri, 01 Apr 2011 14: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 Delivery Status and Disposition Notifications Author(s) : T. Hansen, et al. Filename : draft-ietf-eai-rfc5337bis-dsn-02.txt Pages : 19 Date : 2011-04-01 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798. It replaces the experimental RFC 5337. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5337bis-dsn-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-rfc5337bis-dsn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-01072315.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Sun Apr 10 20:30:04 2011 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 1E8EB3A6A47; Sun, 10 Apr 2011 20:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 RNgHKi4IvtdB; Sun, 10 Apr 2011 20:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839E63A6A43; Sun, 10 Apr 2011 20:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110411033001.22140.80186.idtracker@localhost> Date: Sun, 10 Apr 2011 20:30:01 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-rfc5336bis-09.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, 11 Apr 2011 03:30:04 -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 : SMTP Extension for Internationalized Email Address Author(s) : J. Yao, W. MAO Filename : draft-ietf-eai-rfc5336bis-09.txt Pages : 22 Date : 2011-04-10 This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-09.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-rfc5336bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-10202041.I-D@ietf.org> --NextPart-- From fujiwara@jprs.co.jp Wed Apr 13 03:57:02 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 473D3E0751 for ; Wed, 13 Apr 2011 03:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvSGibmZVITA for ; Wed, 13 Apr 2011 03:57:01 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfc.amsl.com (Postfix) with ESMTP id 54BE0E074E for ; Wed, 13 Apr 2011 03:57:01 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p3DAuwBu002753 for ; Wed, 13 Apr 2011 19:56:58 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id B5C963469 for ; Wed, 13 Apr 2011 19:56:58 +0900 (JST) X-AuditID: ca0b1172-00000005000010a3-51-4da5817a116d Date: Wed, 13 Apr 2011 19:56:58 +0900 (JST) Message-Id: <20110413.195658.35034263.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:57:02 -0000 I have some commens for rfc5336bis-09. Rewriting envelope, headers, message materials described in section 3.2 shoud be separated to another document because the part does not describe how to rewrite non-ASCII envelope, headers, messages. RFC 4409 does not allow unrestricted modifications. | 3.2. The UTF8SMTPbis Extension | | 2. If and only if the EAI-aware SMTP client (sender) is a Message | Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the | envelope, headers, or message material to make them entirely | ASCII [ASCII] and consistent with the provisions of RFC 5321 | [RFC5321] and RFC 5322 [RFC5322]. The comment may be too late to say. I missed making the comment when RFC 5336 was standardized. -- Kazunori Fujiwara, JPRS From alexey.melnikov@isode.com Wed Apr 13 04:57:58 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9F02E06B6 for ; Wed, 13 Apr 2011 04:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHrJRn2lHe+5 for ; Wed, 13 Apr 2011 04:57:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id E4E89E0766 for ; Wed, 13 Apr 2011 04:57:57 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 13 Apr 2011 12:57:55 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DA58FAF.6000800@isode.com> Date: Wed, 13 Apr 2011 12:57:35 +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: fujiwara@jprs.co.jp References: <20110413.195658.35034263.fujiwara@jprs.co.jp> In-Reply-To: <20110413.195658.35034263.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:57:59 -0000 Hi, fujiwara@jprs.co.jp wrote: >I have some commens for rfc5336bis-09. > >Rewriting envelope, headers, message materials described in section >3.2 shoud be separated to another document because the part does not >describe how to rewrite non-ASCII envelope, headers, messages. > >RFC 4409 does not allow unrestricted modifications. > >| 3.2. The UTF8SMTPbis Extension >| >| 2. If and only if the EAI-aware SMTP client (sender) is a Message >| Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the >| envelope, headers, or message material to make them entirely >| ASCII [ASCII] and consistent with the provisions of RFC 5321 >| [RFC5321] and RFC 5322 [RFC5322]. > >The comment may be too late to say. I missed making the comment when >RFC 5336 was standardized. > > I think the purpose of the existing text is to emphasize that such modifications are allowed. I wouldn't make this text any more detailed. So any further details should go into the downgrade-on-submission document. From dhc2@dcrocker.net Wed Apr 13 07:58:40 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92868E078F for ; Wed, 13 Apr 2011 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8shwrh7+ePnF for ; Wed, 13 Apr 2011 07:58:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id 3863DE0778 for ; Wed, 13 Apr 2011 07:58:39 -0700 (PDT) Received: from [192.168.1.12] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3DEwWUY027771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 07:58:37 -0700 Message-ID: <4DA5BA17.2010003@dcrocker.net> Date: Wed, 13 Apr 2011 07:58:31 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexey Melnikov References: <20110413.195658.35034263.fujiwara@jprs.co.jp> <4DA58FAF.6000800@isode.com> In-Reply-To: <4DA58FAF.6000800@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2011 07:58:38 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:58:40 -0000 On 4/13/2011 4:57 AM, Alexey Melnikov wrote: >> | 3.2. The UTF8SMTPbis Extension >> | | 2. If and only if the EAI-aware SMTP client (sender) is a Message >> | Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the >> | envelope, headers, or message material to make them entirely >> | ASCII [ASCII] and consistent with the provisions of RFC 5321 >> | [RFC5321] and RFC 5322 [RFC5322]. >> >> The comment may be too late to say. I missed making the comment when >> RFC 5336 was standardized. >> >> > I think the purpose of the existing text is to emphasize that such modifications > are allowed. I wouldn't make this text any more detailed. So any further details > should go into the downgrade-on-submission document. I'll second the concern raised by Fujiwara-san. The Section 3.2 #2 text is offered almost as if it were a minor comment, when it actually is quite major. Frankly, the best choice is to remove #2 entirely. The authorization for an MSA to effect a downgrade is not stated in any other document. So this one brief entry is the entire specification for MSA downgrading. More text is needed, but it is needed in another document. The current text cannot merely be a 'reminder' that modifications are allowed, because there is no specification yet authorizing such changes. The current model for 5336bis is of a pure UTF-8 environment. Keep it that way. If there is a strong compulsion to refer to downgrading, make the comment extremely generic, along the lines of: Along the messaging handling path, it is possible that a node will translate a message from UTF-8 to be pure ASCII. Specification of this process and its results is outside the scope of this document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alexey.melnikov@isode.com Wed Apr 13 08:20:47 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFEF5E07BC for ; Wed, 13 Apr 2011 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXhMr3XMqss9 for ; Wed, 13 Apr 2011 08:20:47 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id E7740E07B0 for ; Wed, 13 Apr 2011 08:20:46 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 13 Apr 2011 16:20:45 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DA5BF2A.8090306@isode.com> Date: Wed, 13 Apr 2011 16:20:10 +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: dcrocker@bbiw.net References: <20110413.195658.35034263.fujiwara@jprs.co.jp> <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> In-Reply-To: <4DA5BA17.2010003@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:20:47 -0000 Dave CROCKER wrote: [...] > If there is a strong compulsion to refer to downgrading, make the > comment extremely generic, along the lines of: > > Along the messaging handling path, it is possible that a node > will translate a message from UTF-8 to be pure ASCII. Specification > of this process and its results is outside the scope of this document. Actually your proposed text is not correct: there was a very explicit discussion of this point and downgrading anywhere but MSA or MDA is prohibited. From dhc2@dcrocker.net Wed Apr 13 08:26:34 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 953B6E07D7 for ; Wed, 13 Apr 2011 08:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BinpGKjYzVvG for ; Wed, 13 Apr 2011 08:26:33 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id 819D0E07D6 for ; Wed, 13 Apr 2011 08:26:33 -0700 (PDT) Received: from [192.168.1.12] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3DFQRlB028487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 08:26:32 -0700 Message-ID: <4DA5C0A2.9050903@dcrocker.net> Date: Wed, 13 Apr 2011 08:26:26 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexey Melnikov References: <20110413.195658.35034263.fujiwara@jprs.co.jp> <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <4DA5BF2A.8090306@isode.com> In-Reply-To: <4DA5BF2A.8090306@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2011 08:26:32 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:26:34 -0000 On 4/13/2011 8:20 AM, Alexey Melnikov wrote: > Dave CROCKER wrote: > [...] > >> If there is a strong compulsion to refer to downgrading, make the comment >> extremely generic, along the lines of: >> >> Along the messaging handling path, it is possible that a node will translate a >> message from UTF-8 to be pure ASCII. Specification of this process and its >> results is outside the scope of this document. > > Actually your proposed text is not correct: there was a very explicit discussion > of this point and downgrading anywhere but MSA or MDA is prohibited. 1. Please cite the relevant text. I don't find the word "downgrade" in rfc5336bis and the word 'rewrite' occurs only in #2. 2. It is a mistake to have rfc5336bis define a 'pure' utf-8 model and then make statements about the rules for "leaving" that model, especially when it is not specifying the details. Again, the text of #2 is not a mere reminder and it is out of place as a specification. It has been a long journey from the very mixed set of goals the work started with, getting to what is a rather simple model that is easy to understand. The document should stay with that improvement and remove text that taints it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jyee@afilias.info Wed Apr 13 14:58:53 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7F49AE072D for ; Wed, 13 Apr 2011 14:58:53 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNw-yRbxsfUF for ; Wed, 13 Apr 2011 14:58:52 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfc.amsl.com (Postfix) with ESMTP id 79B2FE0723 for ; Wed, 13 Apr 2011 14:58:52 -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 1QA85L-0001TM-7Y for ima@ietf.org; Wed, 13 Apr 2011 21:58:51 +0000 Received: from mail-yw0-f50.google.com ([209.85.213.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QA85L-0008WU-6j for ima@ietf.org; Wed, 13 Apr 2011 21:58:51 +0000 Received: by ywa8 with SMTP id 8so1314712ywa.9 for ; Wed, 13 Apr 2011 14:58:50 -0700 (PDT) Received: by 10.236.176.193 with SMTP id b41mr5833480yhm.280.1302731930496; Wed, 13 Apr 2011 14:58:50 -0700 (PDT) Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id p24sm468833yhm.14.2011.04.13.14.58.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 14:58:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <4DA5BA17.2010003@dcrocker.net> Date: Wed, 13 Apr 2011 17:58:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> References: <20110413.195658.35034263.fujiwara@jprs.co.jp> <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:58:53 -0000 On 2011-04-13, at 10:58 AM, Dave CROCKER wrote: >=20 >=20 > On 4/13/2011 4:57 AM, Alexey Melnikov wrote: >>> | 3.2. The UTF8SMTPbis Extension >>> | | 2. If and only if the EAI-aware SMTP client (sender) is a = Message >>> | Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the >>> | envelope, headers, or message material to make them entirely >>> | ASCII [ASCII] and consistent with the provisions of RFC 5321 >>> | [RFC5321] and RFC 5322 [RFC5322]. >>>=20 >>> The comment may be too late to say. I missed making the comment when >>> RFC 5336 was standardized. >>>=20 >>>=20 >> I think the purpose of the existing text is to emphasize that such = modifications >> are allowed. I wouldn't make this text any more detailed. So any = further details >> should go into the downgrade-on-submission document. >=20 > I'll second the concern raised by Fujiwara-san. >=20 > The Section 3.2 #2 text is offered almost as if it were a minor = comment, when it actually is quite major. Frankly, the best choice is = to remove #2 entirely. RFC4409 permits MSA to rewrite of the message to conform to site's = 'local policy'. RFC5336bis Section 3.2 bulletin 2 is documenting such = capability if 'next hop' is not EAI-aware. Note MSA does not have the = highest priority for this scenario. >=20 > The authorization for an MSA to effect a downgrade is not stated in = any other document. So this one brief entry is the entire specification = for MSA downgrading. More text is needed, but it is needed in another = document. >=20 > The current text cannot merely be a 'reminder' that modifications are = allowed, because there is no specification yet authorizing such changes. Any addition would likely be repeating statement which we had consensus = not to do. The current text made normative reference to RFC4409 = already. =20 >=20 > The current model for 5336bis is of a pure UTF-8 environment. Keep it = that way. >=20 > If there is a strong compulsion to refer to downgrading, make the = comment extremely generic, along the lines of: >=20 > =20 [snip] > Specification of this process and its results is outside the scope of = this document. >=20 Personally, I like this sentence. I think it's good to add it to the = end of bulletin 2. Thoughts? Regards, Joseph > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From fujiwara@jprs.co.jp Wed Apr 13 22:57:58 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 040A3E07A3 for ; Wed, 13 Apr 2011 22:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoWYfOhoqnAo for ; Wed, 13 Apr 2011 22:57:57 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfc.amsl.com (Postfix) with ESMTP id ECD25E06FB for ; Wed, 13 Apr 2011 22:57:55 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p3E5vqNW020892 for ; Thu, 14 Apr 2011 14:57:53 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id D5DB63469 for ; Thu, 14 Apr 2011 14:57:52 +0900 (JST) X-AuditID: ca0b1172-00000006000010a3-8e-4da68ce01602 Date: Thu, 14 Apr 2011 14:57:52 +0900 (JST) Message-Id: <20110414.145752.226773969.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> <4DA58FAF.6000800@isode.com> References: <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:57:58 -0000 Hi, > From: Alexey Melnikov >>Rewriting envelope, headers, message materials described in section >>3.2 shoud be separated to another document because the part does not >>describe how to rewrite non-ASCII envelope, headers, messages. >> >>RFC 4409 does not allow unrestricted modifications. >> >>| 3.2. The UTF8SMTPbis Extension >>| | 2. If and only if the EAI-aware SMTP client (sender) is a Message >>| Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the >>| envelope, headers, or message material to make them entirely >>| ASCII [ASCII] and consistent with the provisions of RFC 5321 >>| [RFC5321] and RFC 5322 [RFC5322]. > I think the purpose of the existing text is to emphasize that such > modifications are allowed. I wouldn't make this text any more > detailed. So any further details should go into the > downgrade-on-submission document. If the purpose of the existing text is to emphasize only, the text is not necessary. If the text updates RFC 4409, the text is necessary. I believe that simple is the best. Unnecessary text should be removed. > From: Joseph Yee > RFC4409 permits MSA to rewrite of the message to conform to site's 'local policy'. RFC5336bis Section 3.2 bulletin 2 is documenting such capability if 'next hop' is not EAI-aware. Note MSA does not have the highest priority for this scenario. If RFC 4409 already permits the text, the text is useless. Otherwise, the text updates RFC 4409. >> Specification of this process and its results is outside the scope of this document. >> > > Personally, I like this sentence. I think it's good to add it to the end of bulletin 2. Thoughts? The sentence seems OK. But if the text is outside of the scope of the draft, then the text is useless. New document will be able to update rfc5336bis. -- Kazunori Fujiwara, JPRS From yaojk@cnnic.cn Thu Apr 14 02:37:16 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9667E0673 for ; Thu, 14 Apr 2011 02:37:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.74 X-Spam-Level: X-Spam-Status: No, score=-98.74 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrqNmSgKU3VG for ; Thu, 14 Apr 2011 02:37:16 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 7EEBCE0669 for ; Thu, 14 Apr 2011 02:37:04 -0700 (PDT) Received: (eyou send program); Thu, 14 Apr 2011 17:37:04 +0800 Message-ID: <502773824.24891@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, 14 Apr 2011 17:37:04 +0800 Message-ID: From: "Jiankang YAO" To: "Joseph Yee" , References: <20110413.195658.35034263.fujiwara@jprs.co.jp><4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> Date: Thu, 14 Apr 2011 17:36:57 +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.5994 Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:37:17 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvc2VwaCBZZWUiIDxqeWVl QGFmaWxpYXMuaW5mbz4NClRvOiA8ZGNyb2NrZXJAYmJpdy5uZXQ+DQpDYzogPGltYUBpZXRmLm9y Zz4NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAxMSA1OjU4IEFNDQpTdWJqZWN0OiBSZTog W0VBSV0gcmZjNTMzNmJpcy0wOTogRG93bmdyYWRlIGluIFN1Ym1pc3Npb24gc2VydmVyDQoNCg0K PiANCj4gT24gMjAxMS0wNC0xMywgYXQgMTA6NTggQU0sIERhdmUgQ1JPQ0tFUiB3cm90ZToNCj4g DQo+IFtzbmlwXQ0KPiANCj4gDQo+PiBTcGVjaWZpY2F0aW9uIG9mIHRoaXMgcHJvY2VzcyBhbmQg aXRzIHJlc3VsdHMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4+IA0K PiANCj4gUGVyc29uYWxseSwgSSBsaWtlIHRoaXMgc2VudGVuY2UuICBJIHRoaW5rIGl0J3MgZ29v ZCB0byBhZGQgaXQgdG8gdGhlIGVuZCBvZiBidWxsZXRpbiAyLiAgVGhvdWdodHM/DQo+IA0KDQoN CmlmIHRoZXJlIHdlcmUgc3VjaCBhIHNlbnRlbmNlLCBpdCBzZWVtcyB0aGF0IHdlIGFyZSB0cnlp bmcgdG8gTm9ybWFsaXplIHRoZSBwb3NzaWJsZSBzdWJtaXNzaW9uIHNlcnZlciBkb3duZ3JhZGUg ZG9jdW1lbnQuDQoNCnRoZSBzaW1wbGUgb25lIGlzICBiZXR0ZXIuDQoNCnNvIEkgc3VnZ2VzdCB0 aGF0IHdlIGp1c3Qga2VlcCB0aGUgY3VycmVudCB3b3JkcyBvZiB0aGUgcmZjNTMzNmJpcy0wOS4N Cg0KSmlhbmthbmcgWWFvIA0KDQo+IFJlZ2FyZHMsDQo+IEpvc2VwaA0KPiANCj4gDQo+PiBkLw0K Pj4gLS0gDQo+PiANCj4+ICBEYXZlIENyb2NrZXINCj4+ICBCcmFuZGVuYnVyZyBJbnRlcm5ldFdv cmtpbmcNCj4+ICBiYml3Lm5ldA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IElNQSBtYWlsaW5nIGxpc3QNCj4+IElNQUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxp c3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaW1h From fujiwara@jprs.co.jp Thu Apr 14 02:41:53 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63DC9E0669 for ; Thu, 14 Apr 2011 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tyzuNDHkxwT for ; Thu, 14 Apr 2011 02:41:52 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfc.amsl.com (Postfix) with ESMTP id 555C0E066A for ; Thu, 14 Apr 2011 02:41:51 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p3E9foZq015222 for ; Thu, 14 Apr 2011 18:41:50 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 8080B346A for ; Thu, 14 Apr 2011 18:41:50 +0900 (JST) X-AuditID: ca0b1172-00000009000010a3-c7-4da6c15d72ec Date: Thu, 14 Apr 2011 18:41:49 +0900 (JST) Message-Id: <20110414.184149.104062483.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [EAI] comment to draft-ietf-eai-rfc5336bis-09 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:41:53 -0000 #2: Insufficient references There are Insufficient references to [EAI Deployment] and [EAI addresses] because they are not listed in WG item. To solve the issue, remove next text in "3.7.2. Mail eXchangers". | 3.7.2. Mail eXchangers | | In order to avoid the possible surprising rejections, the EAI-aware | email system may also implement the advice in EAI addresses advice | document [EAI addresses] and EAI deployment advice document [EAI | Deployment]. Otherwise, merge texts from [EAI Deployment] and [EAI addresses]. #3: Definition of UTF8SMTPbis is unclear. | 3.2. The UTF8SMTPbis Extension | | An SMTP server that announces this UTF8SMTPbis extension MUST be | prepared to accept a UTF-8 string [RFC3629] in any position in which | RFC 5321 specifies that a can appear. The text may become better if you move the definition of before UTF8SMTPbis definition. An SMTP server that announces this UTF8SMTPbis extension MUST be prepared to accept in any position in which RFC 5321 specifies that a can appear. #4: Is "Replace Mailbox in RFC 5321, Section 4.1.2" correct ? There are two ABNF sets. one is the original definition of RFC 5321. The other is internationalized by this draft. The existence of UTF8SMTPbis extention changes the set (from RFC 5321 to this draft). Both sets are valid in an implementation. Each implementation must know both ABNF sets because it may confront the SMTP server which does not advertise "UTF8SMTPbis". and are different in implementations. and are differenct. The same comment is applied to "rfc5335bis". The comment may be, for example, uLocal-part = uDot-string / uQuoted-string ; MAY be case-sensitive ; Internationalized Local-part in RFC 5321, Section 4.1.2 uDot-string = uAtom *("." uAtom) ; Internationalized Dot-string in RFC 5321, Section 4.1.2 uAtom = 1*ucharacter ; Internationalized Atom in RFC 5321, Section 4.1.2 ----- -- Kazunori Fujiwara, JPRS From yaojk@cnnic.cn Thu Apr 14 19:48:28 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E590E0827 for ; Thu, 14 Apr 2011 19:48:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.43 X-Spam-Level: X-Spam-Status: No, score=-98.43 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoPADMEcHFBa for ; Thu, 14 Apr 2011 19:48:27 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 23441E07BD for ; Thu, 14 Apr 2011 19:48:26 -0700 (PDT) Received: (eyou send program); Fri, 15 Apr 2011 10:48:24 +0800 Message-ID: <502835704.26798@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, 15 Apr 2011 10:48:24 +0800 Message-ID: From: "Jiankang YAO" To: , References: <502774119.24891@cnnic.cn> Date: Fri, 15 Apr 2011 10:48:24 +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.5994 Subject: Re: [EAI] comment to draft-ietf-eai-rfc5336bis-09 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:48:28 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGZ1aml3YXJhQGpwcnMuY28u anA+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAxMSA1 OjQxIFBNDQpTdWJqZWN0OiBbRUFJXSBjb21tZW50IHRvIGRyYWZ0LWlldGYtZWFpLXJmYzUzMzZi aXMtMDkNCg0KPHNuaXA+DQoNCj4gDQo+ICMzOiBEZWZpbml0aW9uIG9mIFVURjhTTVRQYmlzIGlz IHVuY2xlYXIuDQo+IA0KPiB8IDMuMi4gIFRoZSBVVEY4U01UUGJpcyBFeHRlbnNpb24NCj4gfA0K PiB8ICBBbiBTTVRQIHNlcnZlciB0aGF0IGFubm91bmNlcyB0aGlzIFVURjhTTVRQYmlzIGV4dGVu c2lvbiBNVVNUIGJlDQo+IHwgIHByZXBhcmVkIHRvIGFjY2VwdCBhIFVURi04IHN0cmluZyBbUkZD MzYyOV0gaW4gYW55IHBvc2l0aW9uIGluIHdoaWNoDQo+IHwgIFJGQyA1MzIxIHNwZWNpZmllcyB0 aGF0IGEgPG1haWxib3g+IGNhbiBhcHBlYXIuDQo+IA0KPiBUaGUgdGV4dCBtYXkgYmVjb21lIGJl dHRlciBpZiB5b3UgbW92ZSB0aGUgZGVmaW5pdGlvbiBvZiA8dU1haWxib3g+DQo+IGJlZm9yZSBV VEY4U01UUGJpcyBkZWZpbml0aW9uLg0KPiANCj4gICBBbiBTTVRQIHNlcnZlciB0aGF0IGFubm91 bmNlcyB0aGlzIFVURjhTTVRQYmlzIGV4dGVuc2lvbiBNVVNUIGJlDQo+ICAgcHJlcGFyZWQgdG8g YWNjZXB0IDx1TWFpbGJveD4gaW4gYW55IHBvc2l0aW9uIGluIHdoaWNoIFJGQyA1MzIxDQo+ICAg c3BlY2lmaWVzIHRoYXQgYSA8bWFpbGJveD4gY2FuIGFwcGVhci4NCj4gDQo+DQoNCklmIHdlIGhv cGUgdG8gdXNlIHRoZSA8dU1haWxib3g+IGluIHRoZSBzZW50ZW5jZSBhYm92ZSwgd2UgY2FuIHN0 aWxsIHVzZSBpdCBhbmQgbWFrZSA8dU1haWxib3g+IHBvaW50aW5nIHRvIHRoZSBkZWZpbml0aW9u IG9mIHNlY3Rpb24gMy4zLg0KDQo+DQo+ICM0OiBJcyAiUmVwbGFjZSBNYWlsYm94IGluIFJGQyA1 MzIxLCBTZWN0aW9uIDQuMS4yIiBjb3JyZWN0ID8NCj4gDQo+ICBUaGVyZSBhcmUgdHdvIEFCTkYg c2V0cy4gb25lIGlzIHRoZSBvcmlnaW5hbCBkZWZpbml0aW9uIG9mIFJGQyA1MzIxLg0KPiAgVGhl IG90aGVyIGlzIGludGVybmF0aW9uYWxpemVkIGJ5IHRoaXMgZHJhZnQuICBUaGUgZXhpc3RlbmNl IG9mDQo+ICBVVEY4U01UUGJpcyBleHRlbnRpb24gY2hhbmdlcyB0aGUgc2V0IChmcm9tIFJGQyA1 MzIxIHRvIHRoaXMgZHJhZnQpLg0KPiAgQm90aCBzZXRzIGFyZSB2YWxpZCBpbiBhbiBpbXBsZW1l bnRhdGlvbi4NCj4gDQo+ICBFYWNoIGltcGxlbWVudGF0aW9uIG11c3Qga25vdyBib3RoIEFCTkYg c2V0cyBiZWNhdXNlIGl0IG1heSBjb25mcm9udA0KPiAgdGhlIFNNVFAgc2VydmVyIHdoaWNoIGRv ZXMgbm90IGFkdmVydGlzZSAiVVRGOFNNVFBiaXMiLg0KPiANCj4gIDxNYWlsYm94PiBhbmQgPHVN YWlsYm94PiBhcmUgZGlmZmVyZW50IGluIGltcGxlbWVudGF0aW9ucy4NCj4gIDx1RG90LXN0cmlu Zz4gYW5kIDxEb3Qtc3RyaW5nPiBhcmUgZGlmZmVyZW5jdC4NCj4gDQo+ICBUaGUgc2FtZSBjb21t ZW50IGlzIGFwcGxpZWQgdG8gInJmYzUzMzViaXMiLg0KPiANCj4gIFRoZSBjb21tZW50IG1heSBi ZSwgZm9yIGV4YW1wbGUsDQo+ICAgIHVMb2NhbC1wYXJ0ID0gdURvdC1zdHJpbmcgLyB1UXVvdGVk LXN0cmluZw0KPiAgICA7IE1BWSBiZSBjYXNlLXNlbnNpdGl2ZQ0KPiAgICA7IEludGVybmF0aW9u YWxpemVkIExvY2FsLXBhcnQgaW4gUkZDIDUzMjEsIFNlY3Rpb24gNC4xLjINCj4gDQo+ICAgdURv dC1zdHJpbmcgPSB1QXRvbSAqKCIuIiB1QXRvbSkNCj4gICAgOyBJbnRlcm5hdGlvbmFsaXplZCBE b3Qtc3RyaW5nIGluIFJGQyA1MzIxLCBTZWN0aW9uIDQuMS4yDQo+IA0KPiAgIHVBdG9tID0gMSp1 Y2hhcmFjdGVyDQo+ICAgIDsgSW50ZXJuYXRpb25hbGl6ZWQgQXRvbSBpbiBSRkMgNTMyMSwgU2Vj dGlvbiA0LjEuMg0KPiANCj4gDQoNCiAiUmVwbGFjZSBMb2NhbC1wYXJ0IGluIFJGQyA1MzIxLCBT ZWN0aW9uIDQuMS4yIiAgVlMgICAiSW50ZXJuYXRpb25hbGl6ZWQgTG9jYWwtcGFydCBpbiBSRkMg NTMyMSwgU2VjdGlvbiA0LjEuMiINCml0IHNlZW1zIHRoYXQgeW91ciBxdWVzdGlvbiBpcyB3aGlj aCBvbmUgYWJvdmUgaXMgYmV0dGVyIG9yIHdoaWNoIG9uZSBpcyBlYXNpbHkgIHVuZGVyc3Rvb2Qg YnkgdGhlIGltcGxlbWVudG9ycy4NCg0KbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGJvdGggYXJl IG9rIGFuZCB0aGVyZSBhcmUgbm90IG11Y2ggZGlmZmVyZW5jZXMuDQoNCnRoYW5rcyBhIGxvdCBm b3IgeW91ciBraW5kIGNvbW1lbnRzLg0KDQpKaWFua2FuZyBZYW8NCg0KDQo+IC0tLS0tDQo+IA0K PiAtLQ0KPiBLYXp1bm9yaSBGdWppd2FyYSwgSlBSUyA8ZnVqaXdhcmFAanBycy5jby5qcD4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1h aWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pbWE= From jyee@afilias.info Fri Apr 15 11:30:07 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D54BE0936 for ; Fri, 15 Apr 2011 11:30:07 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TXGueJGqFva for ; Fri, 15 Apr 2011 11:30:06 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfc.amsl.com (Postfix) with ESMTP id 5A63AE0930 for ; Fri, 15 Apr 2011 11:30:06 -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 1QAnmP-0003DJ-4b for ima@ietf.org; Fri, 15 Apr 2011 18:30:05 +0000 Received: from mail-yw0-f50.google.com ([209.85.213.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QAnmP-0005ZX-3t for ima@ietf.org; Fri, 15 Apr 2011 18:30:05 +0000 Received: by ywa8 with SMTP id 8so2964664ywa.9 for ; Fri, 15 Apr 2011 11:30:04 -0700 (PDT) Received: by 10.101.61.16 with SMTP id o16mr1304479ank.50.1302892204537; Fri, 15 Apr 2011 11:30:04 -0700 (PDT) Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id t23sm2848888ano.25.2011.04.15.11.30.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 11:30:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <20110414.145752.226773969.fujiwara@jprs.co.jp> Date: Fri, 15 Apr 2011 14:30:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> <20110414.145752.226773969.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp X-Mailer: Apple Mail (2.1082) Cc: ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:30:07 -0000 On 2011-04-14, at 1:57 AM, fujiwara@jprs.co.jp wrote: > Hi, >=20 >> From: Alexey Melnikov >>> Rewriting envelope, headers, message materials described in section >>> 3.2 shoud be separated to another document because the part does not >>> describe how to rewrite non-ASCII envelope, headers, messages. >>>=20 >>> RFC 4409 does not allow unrestricted modifications. >>>=20 >>> | 3.2. The UTF8SMTPbis Extension >>> | | 2. If and only if the EAI-aware SMTP client (sender) is a = Message >>> | Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY = rewrite the >>> | envelope, headers, or message material to make them = entirely >>> | ASCII [ASCII] and consistent with the provisions of RFC = 5321 >>> | [RFC5321] and RFC 5322 [RFC5322]. >> I think the purpose of the existing text is to emphasize that such >> modifications are allowed. I wouldn't make this text any more >> detailed. So any further details should go into the >> downgrade-on-submission document. >=20 > If the purpose of the existing text is to emphasize only, > the text is not necessary. >=20 > If the text updates RFC 4409, the text is necessary. >=20 > I believe that simple is the best. Unnecessary text should be removed. Note of the text, just before all bulletin points, the last sentence at = the third paragraph in section 3.2 that leads to the scenario discussion = in the draft: Instead, if an EAI-aware SMTP client (EAI- aware SMTP sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, it MUST make one of the following three choices and the priority order is 1, 2 and 3. This text is to describe what could implementors do, with guided = preferences, and meant to cover all permitted choices. If #2 excluded, = with rest unchanged, there's an implication of new restriction (change) = to MSA under EAI-mode. =20 >=20 >> From: Joseph Yee >> RFC4409 permits MSA to rewrite of the message to conform to site's = 'local policy'. RFC5336bis Section 3.2 bulletin 2 is documenting such = capability if 'next hop' is not EAI-aware. Note MSA does not have the = highest priority for this scenario. >=20 > If RFC 4409 already permits the text, the text is useless. Not useless, see my reason above. > Otherwise, the text updates RFC 4409. Do you mean that if we keep #2, the content must be about updating = RFC4409? Please elaborate. >=20 >>> Specification of this process and its results is outside the scope = of this document. >>>=20 >>=20 >> Personally, I like this sentence. I think it's good to add it to the = end of bulletin 2. Thoughts? >=20 > The sentence seems OK. >=20 > But if the text is outside of the scope of the draft, then the text is = useless. The intention of adding this 'out of scope' sentence is to say this = draft would not discuss *how* MSA may rewrite an internationalized = message. =20 Regards, Joseph >=20 > New document will be able to update rfc5336bis. >=20 > -- > Kazunori Fujiwara, JPRS > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Internet-Drafts@ietf.org Sun Apr 17 20:15:02 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8042CE06C1; Sun, 17 Apr 2011 20:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iK0o-EN-yao; Sun, 17 Apr 2011 20:15:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9953E076A; Sun, 17 Apr 2011 20:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110418031501.6788.90636.idtracker@ietfc.amsl.com> Date: Sun, 17 Apr 2011 20:15:01 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-popimap-downgrade-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 03:15: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 : Post-delivery Message Downgrading for Internationalized Email Messages Author(s) : K. Fujiwara Filename : draft-ietf-eai-popimap-downgrade-01.txt Pages : 15 Date : 2011-04-17 The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in mail header fields. POP and IMAP servers support internationalized email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot send Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be traditional message format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-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-popimap-downgrade-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-17200653.I-D@ietf.org> --NextPart-- From yaojk@cnnic.cn Mon Apr 18 17:52:59 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92D71E0710 for ; Mon, 18 Apr 2011 17:52:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.005 X-Spam-Level: X-Spam-Status: No, score=-98.005 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7u8xDZZD-1v for ; Mon, 18 Apr 2011 17:52:59 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 2F067E0708 for ; Mon, 18 Apr 2011 17:52:57 -0700 (PDT) Received: (eyou send program); Tue, 19 Apr 2011 08:52:52 +0800 Message-ID: <503174372.12153@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, 19 Apr 2011 08:52:52 +0800 Message-ID: From: "Jiankang YAO" To: Date: Tue, 19 Apr 2011 08:52:54 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01CBFE6F.2BECDF40" 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.6090 Subject: [EAI] 80 IETF EAI WG meeting minutes X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 00:52:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01CBFE6F.2BECDF40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001A_01CBFE6F.2BECDF40" ------=_NextPart_001_001A_01CBFE6F.2BECDF40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgIFRoZSBhdHRhY2htZW50IGlzIHRoZSBtaW51dGVzIGZvciA4MCBJRVRG IEVBSSBXRyBtZWV0aW5nLg0KICAgb3IgeW91IG1heSB0YWtlIGEgbG9vayBhdCBodHRwOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzgwL21pbnV0ZXMvZWFpLnR4dC4NCg0KICAgYW55IGNvbW1l bnRzIGFyZSB3ZWxjb21lLg0KDQoNCkppYW5rYW5nIFlhbw== ------=_NextPart_001_001A_01CBFE6F.2BECDF40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MDQ2Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBzaXplPTI+RGVhciBhbGwsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+Jm5ic3A7Jm5ic3A7IFRoZSBhdHRhY2htZW50IGlzIHRoZSBtaW51dGVzIGZvciA4 MCBJRVRGIEVBSSBXRyANCm1lZXRpbmcuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ Jm5ic3A7Jm5ic3A7IG9yIHlvdSBtYXkgdGFrZSBhIGxvb2sgYXQgPEEgDQpocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgwL21pbnV0ZXMvZWFpLnR4dCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy84MC9taW51dGVzL2VhaS50eHQ8L0E+LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PiZuYnNwOyZuYnNwOyBhbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SmlhbmthbmcgWWFvPC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_001_001A_01CBFE6F.2BECDF40-- ------=_NextPart_000_0019_01CBFE6F.2BECDF40 Content-Type: text/plain; name="eai-80.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eai-80.txt" -------------------------------------------=20 Meeting=20 Email Address Internationalization (EAI) WG minutes=20 IETF 80, Tuesday, March 29, 2011 0900-1130=20 Room: Barcelona Chairs: John Klensin =20 Joseph Yee Minutes: Jiankang Yao Agenda Bashing=20 - none=20 Discussion Summary=20 Announcement & Consensus Summary - Neither new advise docs nor revision of advise docs will be discussed until core drafts in Last Call or in RFC Editor queue. - Report summary of consensus results from Dec 2010 - Jan 2011 rfc3536bis: a)This draft is not work of EAI WG b)EAI WG are encouraged to review and provide feedbacks SMTP-bis (draft-ietf-eai-rfc5336bis-08):=20 a) Consensus report - Adopt parameter for MAIL FROM - Adopt parameter for EXPR/VRFY - No new terms for UTF-8, ASCII, non-ASCII b) Most are editorial works c) No other known issues=20 d) Call for more review on it e) Need to update the draft within 2-3 weeks Header-bis (draft-ietf-eai-rfc5335bis-10):=20 a) Consensus report - Keep the naming "message/global" - Keep nested encoding for message/global - Adopt new ABNF proposed by Dave Crocker b) Ned Freed will help to co-edit this document c) Call for more review on it d) Need to update the draft within 2-3 weeks DSN-bis (draft-ietf-eai-rfc5337bis-dsn-01):=20 a) No known issues b) Call for more review on it=20 c) Need to update the draft within 2-3 weeks POP-bis (draft-ietf-eai-rfc5721bis-00):=20 a) No known issues=20 b) New version will come soon c) Call for more review on it IMAP-bis (rfc5738bis):=20 a) No known issues b) New draft will be submitted soon to replace previous draft with = naming typo c) Call for more review on it Post-delivery Message Downgrading for Internationalized Email Messages=20 (draft-ietf-eai-popimap-downgrade-00)=20 a) Editors need more inputs for next revision b) Call for more review on it EAI-mailto (draft-duerst-eai-mailto-00):=20 a) Editors need more inputs for next revision b) Martin Duerst provides update of the current draft draft-ietf-pkix-eai-addresses-00.txt a)Alexey gives an introduction on it A.O.B a)Thanks Alexey and Welcome Pete b)Mailstore and Mailbox formats (UTF-8) discussion reminder:=20 Anyone who committed to review docs=20 should do so as promised.=20 ---------------------------------------- ------=_NextPart_000_0019_01CBFE6F.2BECDF40-- From klensin@jck.com Tue Apr 19 07:37:23 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5BCD2E06E9 for ; Tue, 19 Apr 2011 07:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3yap1el4WaG for ; Tue, 19 Apr 2011 07:37:22 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 883D0E06C0 for ; Tue, 19 Apr 2011 07:37:22 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QCC3A-000HHC-Nr; Tue, 19 Apr 2011 10:37:08 -0400 Date: Tue, 19 Apr 2011 10:37:07 -0400 From: John C Klensin To: Joseph Yee , dcrocker@bbiw.net Message-ID: In-Reply-To: <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> References: <20110413.195658.35034263.fujiwara@jprs.co.jp> <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@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] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:37:23 -0000 Speaking for myself only, let me propose what I think may be a compromise position... --On Wednesday, April 13, 2011 17:58 -0400 Joseph Yee wrote: >... >> The Section 3.2 #2 text is offered almost as if it were a >> minor comment, when it actually is quite major. Frankly, the >> best choice is to remove #2 entirely. > > RFC4409 permits MSA to rewrite of the message to conform to > site's 'local policy'. RFC5336bis Section 3.2 bulletin 2 is > documenting such capability if 'next hop' is not EAI-aware. > Note MSA does not have the highest priority for this scenario. The intent of 4409 is fairly clearly to permit the MSA significant latitude in fixing things that the MUA didn't get right. It focuses on fixes to conform with the standards, but the "local policy" provision that Joseph mentions opens things up to broader changes. So, whether this text is correct and/or desirable or not, it really is a reminder in the sense that it doesn't update 4409 in any substantive way. >... >> The current text cannot merely be a 'reminder' that >> modifications are allowed, because there is no specification >> yet authorizing such changes. > > Any addition would likely be repeating statement which we had > consensus not to do. The current text made normative > reference to RFC4409 already. yes. >> The current model for 5336bis is of a pure UTF-8 environment. >> Keep it that way. >> >> If there is a strong compulsion to refer to downgrading, make >> the comment extremely generic, along the lines of: >> >> > > [snip] > > >> Specification of this process and its results is outside the >> scope of this document. >> > > Personally, I like this sentence. I think it's good to add it > to the end of bulletin 2. Thoughts? Concur. So, at the risk of causing more work for myself, let me suggest the following: (i) We remove the offending "reminder" sentence from #2 and substitute the above sentence (or some editor-chosen variation). (ii) An EAI-related version/revision of 4409 has always been an EAI task if the WG concludes it is necessary. Let's do that, not with the intent of adding detailed EAI-specific provisions, but adding a paragraph that explicitly indicates that conversions of character sets or encodings are within the scope of things that MSAs can do. If that is handled as a clarification --which I think it would be-- than it could be done as a revision in grade or even as part of a full standard 4409bis (whether that document were processed by EAI or YAM would be a matter of some indifference to me). Does that make sense? john From fujiwara@jprs.co.jp Tue Apr 19 21:53:03 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 560C9E0660 for ; Tue, 19 Apr 2011 21:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWUxQ0GHMxUr for ; Tue, 19 Apr 2011 21:53:02 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfc.amsl.com (Postfix) with ESMTP id 4F1C9E0611 for ; Tue, 19 Apr 2011 21:53:01 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p3K4qlWw002826; Wed, 20 Apr 2011 13:52:47 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 9F3E93470; Wed, 20 Apr 2011 13:52:47 +0900 (JST) X-AuditID: ca0b1172-0000000b000010a3-e4-4dae669f4061 Date: Wed, 20 Apr 2011 13:52:47 +0900 (JST) Message-Id: <20110420.135247.258111822.fujiwara@jprs.co.jp> To: klensin@jck.com From: fujiwara@jprs.co.jp In-Reply-To: References: <4DA5BA17.2010003@dcrocker.net> <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: dcrocker@bbiw.net, ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 04:53:03 -0000 > From: John C Klensin >>> Specification of this process and its results is outside the >>> scope of this document. >>> >> >> Personally, I like this sentence. I think it's good to add it >> to the end of bulletin 2. Thoughts? > > Concur. > > So, at the risk of causing more work for myself, let me suggest > the following: > > (i) We remove the offending "reminder" sentence from #2 and > substitute the above sentence (or some editor-chosen variation). > > (ii) An EAI-related version/revision of 4409 has always been an > EAI task if the WG concludes it is necessary. Let's do that, > not with the intent of adding detailed EAI-specific provisions, > but adding a paragraph that explicitly indicates that > conversions of character sets or encodings are within the scope > of things that MSAs can do. If that is handled as a > clarification --which I think it would be-- than it could be > done as a revision in grade or even as part of a full standard > 4409bis (whether that document were processed by EAI or YAM > would be a matter of some indifference to me). > > Does that make sense? I agree. -- Kazunori Fujiwara, JPRS From barryleiba@computer.org Wed Apr 20 15:52:06 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1E23E0791; Wed, 20 Apr 2011 15:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6tQwaqEuGiz; Wed, 20 Apr 2011 15:52:06 -0700 (PDT) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by ietfc.amsl.com (Postfix) with ESMTP id 0ED9BE0765; Wed, 20 Apr 2011 15:52:02 -0700 (PDT) Received: from [192.168.0.2] (ool-457c2d3b.dyn.optonline.net [69.124.45.59]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0LJZ005AM3IOVEL0@mta2.srv.hcvlny.cv.net>; Wed, 20 Apr 2011 18:52:02 -0400 (EDT) Date: Wed, 20 Apr 2011 18:51:59 -0400 From: Barry Leiba To: apps-discuss@ietf.org Message-id: <7000F5E5D27FA961BE7D9EC6@uranus> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline Cc: public-iri@w3.org, draft-hoffman-rfc3536bis@tools.ietf.org, ima@ietf.org, idna-update@alvestrand.no, precis@ietf.org Subject: [EAI] Call for adoption of draft-hoffman-rfc3536bis as an APPSAWG document X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "apps-discuss@ietf.org" <> List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:52:06 -0000 Paul Hoffman and John Klensin have undertaken to update RFC 3536, which specified terminology for use in internationalization-related documents and discussions. The editors, appsawg chairs, and Applications Area directors think the document needs broad review, and propose to make it an appsawg document. You can find the document here: http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ The editors will soon submit an updated version, and await a decision on accepting the document into appsawg before doing that. We ask that anyone with a stake in internationalization review the current version and state any objections to making this an appsawg document by 29 April. You may, or course, also send comments on the document at this point to the editors and/or the apps-discuss list. Remember that there are changes queued, so you might bring up points that they're already planning to change/correct. The reply-to on this message is set to the apps-discuss list . Please put all responses and discussion there. Barry, appsawg chair From yaojk@cnnic.cn Wed Apr 20 20:41:24 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 300A7E0808 for ; Wed, 20 Apr 2011 20:41:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -97.833 X-Spam-Level: X-Spam-Status: No, score=-97.833 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRpmqn9OMhwD for ; Wed, 20 Apr 2011 20:41:22 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 837CFE07C1 for ; Wed, 20 Apr 2011 20:41:20 -0700 (PDT) Received: (eyou send program); Thu, 21 Apr 2011 11:41:20 +0800 Message-ID: <503357280.26519@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, 21 Apr 2011 11:41:20 +0800 Message-ID: <82BC99282E2446E998108FBE1437373B@LENOVO47E041CF> From: "Jiankang YAO" To: References: <20110413.195658.35034263.fujiwara@jprs.co.jp><4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> Date: Thu, 21 Apr 2011 11:41:12 +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.6090 Subject: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 03:41:24 -0000 RGVhciBhbGwsDQoNCg0KSSBqdXN0IGNoZWNrZWQgdGhyb3VnaCB0aGUgamFiYmVyIGxvZyBvZiBQ cmFndWUgZWFpIG1lZXRpbmcuDQoNCkkgZm91bmQgdGhlIGZvbGxvdyBtZXNzYWdlOg0KIg0KWzA3 OjM4OjE3XSA8cmVzbmljaz4gT25lIG9mIG15IGNvbmNlcm5zIHdpdGggNTMzNmJpcyBpcyB3aGV0 aGVyIHdlIGhhdmUgYSBzdG9yeSBmb3Igd2h5IHdlIGRpZCB0aGUgKmV4dGVuc2lvbiogc3ludGF4 IGluIDUzMzViaXMgYnV0IGFyZSB1c2luZyBhbiAqYWx0ZXJuYXRlKiBzeW50YXggb24gNTMzNmJp cy4NClswNzozODo1Ml0gPHJlc25pY2s+IChNeSBjdXJyZW50IHJlYWQgb2YgNTMzNmJpcyBpcyB0 aGF0IGl0J3Mgc3RpbGwgdXNpbmcgdGhlIGFsdGVybmF0ZSBzeW50YXguKQ0KIg0KDQogQUJORiBp cyBhbHNvIGFuIGltcG9ydGFuIGNvbW1lbnQgZnJvbSBEYXZlLiAgSWYgSSB1bmRlcnN0YW5kIERh dmUncyBjb21tZW50cyB0byBBQk5GIGNsZWFybHksIA0KdGhlIGNvcmUgc3VnZ2VzdGlvbiBpcyB0 byBoYXZlIHRoZSByZXZpc2lvbiBmb2N1cyBvbmx5IG9uIHRoZSBleGlzdGluZywgYmFzaWMgNTMy MiAgQUJORiBjb25zdHJ1Y3RzIGFuZA0KICAgICAgICAgc2ltcGx5IGF1Z21lbnQgdGhlbSB0byBz dXBwb3J0IFVURi04IGluc3RlYWQgb2YgdXNpbmcgdGhlIHByZWZpeCAidSIuDQoNCg0KVGhlIGN1 cnJlbnQgdmVyc2lvbiBvZiByZmM1MzM2YmlzIGlzIHN0aWxsICB0byB1c2UgdGhlIHByZWZpeCAi dSIuDQoNCk15IGNvbmNlcm4gaXMgdGhhdCBpZiB0aGUgc3lzdGVtIHN1cHBvcnQgYm90aCByZmM1 MzM2YmlzIGFuZCA1MzIxLCB0aGUgc3lzdGVtIG5lZWRzIHRvIHJlY29nbml6ZSB3aWhpY2ggYWRk cmVzcw0KaXMgbWFpbGJveCBhbmQgd2hpY2ggb25lIGlzIGh0ZSB1TWFpbGJveC4gaWYgd2UganVz dCBleHRlbmQgaXQsICBpdCBpcyBub3QgZWFzaWx5IHRvIGRpc3Rpbmd1c2ggdGhlIG1haWxib3gg aW4gaW1wbGVtZW50YXRpb24gYmVjYXVzZSBib3RoIGFyZSBuYW1lZCB3aXRoICJtYWlsYm94Ii4g Lg0KDQpvbiB0aGUgb3RoZXIgaGFuZCwgdGhlIEVtYWlsIHN5c3RlbSBtYXkgY2hvb3NlIHRvIHJl Y29nbml6ZSBib3RoIHRoZSByZmM1MzM2YmlzIGFkZHJlc3MgYW5kIHJmYzUzMjEgYWRkcmVzcyBh cyBwb2ludGVkIG91dCBieSBGdWppd2FyYSBpbiB0aGUgcHJldmlvdXMgbWVzc2FnZSwgdGh1cw0K bWFpbGJveCBhbmQgdU1haWxib3ggbmVlZCB0byBiZSBlYXNpbHkgc2VwYXJhdGVkLg0KDQpTbywg bXkgcGVyc29uYWwgZmF2b3JpdGUgaXMgc3RpbGwgdG8ga2VlcCB0aGUgY3VycmVudCBhbHRlcm5h dGUgc3ludGF4IHN0eWxlIGZvciByZmM1MzM2YmlzIHRvIGF2b2lkIHRoZSBwb3NzaWJsZSBjb25m dXNpb24gd2l0aCByZmM1MzIxLg0KDQpCdXQgaWYgdGhpcyBjb25jZXJuIGFib3ZlIGlzIG5vdCBh IHByb2JsZW0sIEkgd2lsbCBmb2xsb3cgRGF2ZSdzIG1vZGVsIHRvIGV4dGVuZCBpdCBpbnN0ZWFk IG9mIHVzaW5nIHByZWZpeCAidSIuDQoNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQoNCg== From klensin@jck.com Wed Apr 20 20:59:51 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70750E06FF for ; Wed, 20 Apr 2011 20:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcvYloFYbY-8 for ; Wed, 20 Apr 2011 20:59:50 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 880ECE06DB for ; Wed, 20 Apr 2011 20:59:50 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QCl3V-00010E-4t; Wed, 20 Apr 2011 23:59:49 -0400 Date: Wed, 20 Apr 2011 23:59:48 -0400 From: John C Klensin To: Jiankang YAO , ima@ietf.org Message-ID: <7FA5D34E342AAAFD7A4156EF@PST.JCK.COM> In-Reply-To: <503357280.26519@cnnic.cn>, <82BC99282E2446E998108FBE1437373B@LENOVO47E041CF> References: <20110413.195658.35034263.fujiwara@jprs.co.jp> <4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> <503357280.26519@cnnic.cn>, <82BC99282E2446E998108FBE1437373B@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] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 03:59:51 -0000 --On Thursday, April 21, 2011 11:41 +0800 Jiankang YAO wrote: > Dear all, > > > I just checked through the jabber log of Prague eai meeting. > > I found the follow message: > " > [07:38:17] One of my concerns with 5336bis is > whether we have a story for why we did the *extension* syntax > in 5335bis but are using an *alternate* syntax on 5336bis. > [07:38:52] (My current read of 5336bis is that it's > still using the alternate syntax.) " And, of course, we don't have the "extension" syntax in 5335bis yet either, but I hope we will see it soon. > ABNF is also an importan comment from Dave. If I understand > Dave's comments to ABNF clearly, the core suggestion is to > have the revision focus only on the existing, basic 5322 ABNF > constructs and simply augment them to support UTF-8 > instead of using the prefix "u". I think that is, more or less, the "extension" syntax model, but Dave can speak for himself. > The current version of rfc5336bis is still to use the prefix > "u". As I have said to you several times offlist, whatever the WG decides to do about a basic ABNF model, it should do with all documents, especially the three core ones. I think having their basic models --e.g., what Pete refers to as "alternate" and "extension"-- be different is far less acceptable than making either choice and using it for all three. > My concern is that if the system support both rfc5336bis and > 5321, the system needs to recognize wihich address is mailbox > and which one is hte uMailbox. if we just extend it, it is > not easily to distingush the mailbox in implementation because > both are named with "mailbox". . > on the other hand, the Email system may choose to recognize > both the rfc5336bis address and rfc5321 address as pointed out > by Fujiwara in the previous message, thus mailbox and uMailbox > need to be easily separated. That is, I think, the argument for the WG's original conclusion that we should just an "alternate" syntax, not an "extension" one that reuses production names. > So, my personal favorite is still to keep the current > alternate syntax style for rfc5336bis to avoid the possible > confusion with rfc5321. > > But if this concern above is not a problem, I will follow > Dave's model to extend it instead of using prefix "u". Note that, whether we go with the "alternate" or "extension" syntax, there is a remaining problem of what "mailbox" means -- that issue really needs to be sorted out with/in 5321/5322 and should not be an EAI problem. john From fujiwara@jprs.co.jp Thu Apr 21 02:29:38 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AF3C7E06B2 for ; Thu, 21 Apr 2011 02:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQoG0JlKmglK for ; Thu, 21 Apr 2011 02:29:38 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfc.amsl.com (Postfix) with ESMTP id AC2B9E06A3 for ; Thu, 21 Apr 2011 02:29:36 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p3L9TYcm020994 for ; Thu, 21 Apr 2011 18:29:34 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 894BA3471 for ; Thu, 21 Apr 2011 18:29:34 +0900 (JST) X-AuditID: ca0b1172-00000009000010a3-45-4daff8fe540d Date: Thu, 21 Apr 2011 18:29:34 +0900 (JST) Message-Id: <20110421.182934.241938101.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [EAI] comment to draft-ietf-eai-rfc5337bis-dsn-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 09:29:38 -0000 I have two comments. #1: utf-8-address seems to contain ALT-ADDRESS format. | utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] | ; uMailbox is defined in [I-D.ietf-eai-rfc5336bis]. | ; Mailbox is defined in [RFC5321]. May be: utf-8-address = uMailbox ; uMailbox is defined in [I-D.ietf-eai-rfc5336bis]. #2: Section 4.1 refers RFC 5504 downgrade. Remove reference to "RFC 5504". Regards, -- Kazunori Fujiwara, JPRS From klensin@jck.com Thu Apr 21 05:31:40 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DBD3E071B; Thu, 21 Apr 2011 05:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NixfpDviCjVU; Thu, 21 Apr 2011 05:31:39 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 2A007E070F; Thu, 21 Apr 2011 05:31:39 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QCt2n-0009Kv-Sm; Thu, 21 Apr 2011 08:31:38 -0400 Date: Thu, 21 Apr 2011 08:31:36 -0400 From: klensin@jck.com, john-ietf@jck.com To: jefsey , iucg@ietf.org Message-ID: In-Reply-To: <7.0.1.0.2.20110421111550.059fe118@jefsey.com> References: <7.0.1.0.2.20110421111550.059fe118@jefsey.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: public-iri@w3.org, draft-hoffman-rfc3536bis@tools.ietf.org, idna-update@alvestrand.no, precis@ietf.org, ima@ietf.org Subject: Re: [EAI] terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: apps-discuss@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:31:40 -0000 (top post) Jefsey, Thanks. The notice was already forward to a few other lists, which I hope I have trimmed. Any discussion of the appropriateness of doing this should continue on the apps-discuss list, as requested by Barry, and not cross-posted. I would prefer that any substantive comments be deferred until after AppsAWG makes a decision about discussion venue and then sent to their list (if they decide to take the document on). In the interim, substantive or editorial comments may be sent to Paul and myself at draft-hoffman-rfc3536bis@tools.ietf.org if needed. Neither he nor I have time to track multiple lists for comments so comments to random lists, or long distribution lists are likely to get lost -- please, everyone, don't do a multiple posting and then complain that your comments were lost. Substantive comment for planning purposes: Whether it ends up being posted as draft-ietf-appsawg-rfc3536bis-00 or as draft-hoffman-rfc3536bis-02 (with the version after that posted as draft-ietf-appsawg-rfc3536-00), the main substantive change between that version and the current draft-hoffman-rfc3536bis-01 will be the addition of an extended description of the term "variant" (used in domain name contexts). Wisely or not, the use of that term in various context has been expanded significantly beyond the definition in RFC 3743. Those whose work involves that term, or notions of "equivalence" in domain names, will want to look at the description carefully. Each new version of course also includes a selection of editorial improvements and less significant fixes. john p.s. I note that the "the traditional wiki working transcript" referred to in your note contains several significant errors and that we are unlikely to be able to have a useful discussion or incorporate changes based on that version. I strongly suggest that people use http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ as the relevant discussion/ reading version instead. --On Thursday, April 21, 2011 13:49 +0200 jefsey wrote: > Dear IUsers, > Barry Leiba, WG/APPSAWG Chair has sent the following most > important mail for us: > >> "Paul Hoffman and John Klensin have undertaken to update RFC >> 3536, which specified terminology for use in >> internationalization-related documents and discussions. The >> editors, appsawg chairs, and Applications Area directors >> think the document needs broad review, and propose to make >> it an appsawg document. >> You can find the document here: >> http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ >> The editors will soon submit an updated version, and await a >> decision on accepting the document into appsawg before doing >> that. We ask that anyone with a stake in >> internationalization review the current version and state >> any objections to making this an appsawg document by 29 >> April. >> You may, or course, also send comments on the document at >> this point to the editors and/or the apps-discuss list. >> Remember that there are changes queued, so you might bring >> up points that they're already planning to change/correct. >> The reply-to on this message is set to the apps-discuss list >> . Please put all responses and >> discussion there. > > This terminology is obviously going to be the mutual > understanding bridge between the IETF and the IUTF > communities. >... From dhc2@dcrocker.net Thu Apr 21 10:01:10 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A4A08E072A for ; Thu, 21 Apr 2011 10:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE4qD7Yf8RMA for ; Thu, 21 Apr 2011 10:01:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id 8663AE06A8 for ; Thu, 21 Apr 2011 10:01:09 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3LH10nx019088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 10:01:06 -0700 Message-ID: <4DB062C7.1080802@dcrocker.net> Date: Thu, 21 Apr 2011 10:00:55 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang YAO References: <20110413.195658.35034263.fujiwara@jprs.co.jp><4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> <503357280.26519@cnnic.cn> In-Reply-To: <503357280.26519@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 21 Apr 2011 10:01:07 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 17:01:10 -0000 On 4/20/2011 8:41 PM, Jiankang YAO wrote: > I found the follow message: " [07:38:17] One of my concerns with > 5336bis is whether we have a story for why we did the *extension* syntax in > 5335bis but are using an *alternate* syntax on 5336bis. [07:38:52] > (My current read of 5336bis is that it's still using the alternate syntax.) > " > > ABNF is also an importan comment from Dave. If I understand Dave's comments > to ABNF clearly, the core suggestion is to have the revision focus only on > the existing, basic 5322 ABNF constructs and simply augment them to support > UTF-8 instead of using the prefix "u". > > The current version of rfc5336bis is still to use the prefix "u". > > My concern is that if the system support both rfc5336bis and 5321, the system > needs to recognize wihich address is mailbox and which one is hte uMailbox. > if we just extend it, it is not easily to distingush the mailbox in > implementation because both are named with "mailbox". . There is a very large change that was made in the approach for doing the EAI work. It changed from defining a complete, hybrid system that supports old and new addresses, and instead now focuses only on the UTF-8 case. That is, the current, core specifications do not try to juggle both legacy and new characters. They only seek to handle new (Unicode) characters. Transition and hybrid issues are therefore deferred to other documents, outside of this core. In my view, this simplification is quite a good choice, especially due to the fact that ASCII is a subset of Unicode. Hence, talking only about UTF-8 means that ASCII is still included. However, the documents still reflect the earlier attempt to juggle both old and new. The ABNF I proposed is designed to deal with the simplified environment that is strictly UTF-8. Hence, the core constructs, like mailbox, do not need an old and a new form. The ABNF merely needs to enhance the definition of mailbox to a single, UTF-8 form. In protocol architecture terms, this simplified approach defines use of UTF-8 as a "parallel" protocol stack to the older ASCII-only one. This is why Pete's term "alternate" makes sense. The term "extension" reflects an attempt to add on to existing ABNF without changing its existing core constructs. Hence it is suited for the older hybrid case. However I believe its complexity is neither necessary nor appropriate for the current work. > on the other hand, the Email system may choose to recognize both the > rfc5336bis address and rfc5321 address as pointed out by Fujiwara in the > previous message, thus mailbox and uMailbox need to be easily separated. > > So, my personal favorite is still to keep the current alternate syntax style > for rfc5336bis to avoid the possible confusion with rfc5321. As for rfc5335bis vs. rfc5336bis, I do believe it would be much better to have them reflect the same approach to ABNF enhancement. Obviously my own recommendation is to have both of them use the simpler "alternate" definitions, rather than the more complicated "extension" approach. There is a much larger and longer-term issue concerning some redundant specifications between RFC5321/RFC5322. It came from what I consider a basic mistake that Jon Postel and I made in doing RFC821 and RFC822. I now class redundant specification as evil and I think that the DRUMS effort missed a real opportunity in failing to fix this. But, as noted, this issue is far beyond the scope of the EAI working group. I hope this fully responds to the questions in this thread. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jefsey@jefsey.com Thu Apr 21 04:49:23 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D253EE06CF; Thu, 21 Apr 2011 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkygD8apeAcd; Thu, 21 Apr 2011 04:49:22 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfc.amsl.com (Postfix) with ESMTP id 945B0E0698; Thu, 21 Apr 2011 04:49:22 -0700 (PDT) Received: from 18.109-227-89.dsl.completel.net ([89.227.109.18]:60868 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QCsNr-0004v5-LK; Thu, 21 Apr 2011 04:49:20 -0700 Message-Id: <7.0.1.0.2.20110421111550.059fe118@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 21 Apr 2011 13:49:31 +0200 To: iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Thu, 21 Apr 2011 17:50:53 -0700 Cc: apps-discuss@ietf.org, precis@ietf.org, public-iri@w3.org, idna-update@alvestrand.no, ima@ietf.org, draft-hoffman-rfc3536bis@tools.ietf.org Subject: [EAI] terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:49:24 -0000 Dear IUsers, Barry Leiba, WG/APPSAWG Chair has sent the following most important mail for us: >"Paul Hoffman and John Klensin have undertaken to update RFC 3536, >which specified terminology for use in internationalization-related >documents and discussions. The editors, appsawg chairs, and >Applications Area directors think the document needs broad review, >and propose to make it an appsawg document. >You can find the document here: >http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ >The editors will soon submit an updated version, and await a >decision on accepting the document into appsawg before doing >that. We ask that anyone with a stake in internationalization >review the current version and state any objections to making this >an appsawg document by 29 April. >You may, or course, also send comments on the document at this point >to the editors and/or the apps-discuss list. Remember that there >are changes queued, so you might bring up points that they're >already planning to change/correct. >The reply-to on this message is set to the apps-discuss list >. Please put all responses and discussion there. This terminology is obviously going to be the mutual understanding bridge between the IETF and the IUTF communities. http://iucg.org/wiki/Wiki_RFC_3536bis is the traditional wiki working transcript (unfinished as yet) of the proposed draft. This is in line with my own I_D on orthotypography: http://tools.ietf.org/html/draft-iucg-idna2008-orthotypography-00 I suggest thet our target should be : 1. to make sure RFC 3536bis by APPSAWG is in line with our own understanding of the terms in our own working contexts (IDNA2008, ML-DNS, IUI, EST). 2. to build our own Internet extension section to document in a similar manner the emergent IUse terminology. This section should not document any concept than the way we read and use the existing "Internal Internet" technology (i.e. no bit change). 3. to continue building in contnuity our own dictionnary of the new IUI and Intersem (semiotic/semantic Intercomprehension network) stratum. Best. jfc NB: due to personal constraints that should now progressively reduce I was not able to sustain my post-IDNA2008 endeavour as I planned it. Some terminology used in this mail is not therefore as common and supported by operational prototypes as our little group hoped. Thank you to read the used acronyms/terms as follows: - IDNA2008: as documented by RFC 5890 to 5895 - ML-DNS: multilayer DNS (of which layer 1 is the Internal Internet DNS, layer 2 is IDNA2008). - IUI: Intelligent Use Interface (Internet Use Interface from an Internet perspective). i.e. a generalization of principle introduced by Paul Hoffman and Pete Resnick in RFC 5895 and a stable optional response to problems discussed by the IAB in RFC 6055 - IUse: an emergent community interested in an open general Intelligent Use of the world digital ecosystem (whatever the multitechnological convergence). - EST: Extended System Theory, a glogalization of the General System Theory which includes networking and interfaces and is necessary to better read the IETF RFCs in an IUse perspective. - IUTF: Intelligent Use Task Force, TF under formation further to the responses to the appeals to IESG and IAB following the successfull, but not documented yet as such, introduction of the principle of subsidiarity (IDNA2008) as the third internet architectural principle (RFC 1958: principle of permanent change, RFC 3439: principle of simplicity). I note that subsidiairity should come with suppleance (I did not found so far an English equivalent for the core to support peripheral difficulties) and precaution. - Dictionnary (http://iucg.org/wiki/Dictionnary): this IUCG project to integrate digital ecosystem convergence and ALFA (Free Acrchitecture) words. From paul.hoffman@vpnc.org Thu Apr 21 13:54:36 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35832E0722; Thu, 21 Apr 2011 13:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.054 X-Spam-Level: X-Spam-Status: No, score=-102.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG8TrwXdJuTJ; Thu, 21 Apr 2011 13:54:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 7F754E06B9; Thu, 21 Apr 2011 13:54:35 -0700 (PDT) Received: from sn80.proper.com (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3LKsSV9015073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Apr 2011 13:54:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7000F5E5D27FA961BE7D9EC6@uranus> Date: Thu, 21 Apr 2011 13:54:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B50401F-D2C9-42F1-9D61-D4B9A836DBEF@vpnc.org> References: <7000F5E5D27FA961BE7D9EC6@uranus> To: Apps Discuss X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 21 Apr 2011 17:50:53 -0700 Cc: public-iri@w3.org, precis@ietf.org, draft-hoffman-rfc3536bis@tools.ietf.org, ima@ietf.org, idna-update@alvestrand.no Subject: Re: [EAI] [apps-discuss] Call for adoption of draft-hoffman-rfc3536bis as an APPSAWG document X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:54:36 -0000 On a related note, John and I have issued the -02 with a few fixes, = including a discussion of the always-popular "variant". See = . --Paul Hoffman= From presnick@qualcomm.com Sat Apr 23 15:17:24 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1774CE06C9 for ; Sat, 23 Apr 2011 15:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFbvvlhgdkru for ; Sat, 23 Apr 2011 15:17:23 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfc.amsl.com (Postfix) with ESMTP id 51A59E0663 for ; Sat, 23 Apr 2011 15:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1303597043; x=1335133043; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DB34FF0.9050002@qualcomm.com>|Date:=20Sa t,=2023=20Apr=202011=2017:17:20=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20Jiankang=20YAO=20,=0D=0A=09|Subject:=20Re:=20[EA I]=20uMailbox=20or=20mailbox=20(ABNF=20for=20rfc5336bis) |References:=20<20110413.195658.35034263.fujiwara@jprs.co .jp><4DA58FAF.6000800@isode.com>=09<4DA5BA17.2010003@dcro cker.net>=09<502731942.13941@cnnic.cn>=20<503357280.26519 @cnnic.cn>=20<4DB062C7.1080802@dcrocker.net>|In-Reply-To: =20<4DB062C7.1080802@dcrocker.net>|Content-Type:=20text/p lain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=37ldeDRSs66/Z0nOz2bHyycJWqsmx/n6kHDcfmTKnew=; b=cKLNBtVZiua1SLWkcuwHONZ/DZHwJag7rBz/MQdiSINoGegxr/lMbYMu m9MTo4hJL0fm5Y90Cm2ojAU/TM64bf92xAoEf8cIBaF4BH18p4OSvS89n l4rc4y4OL19lP9SIhGWrXEABqyw5offexwf9zIRtRIulgWbvLDtJ1oIjT g=; X-IronPort-AV: E=McAfee;i="5400,1158,6325"; a="87301612" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 23 Apr 2011 15:17:22 -0700 X-IronPort-AV: E=Sophos;i="4.64,259,1301900400"; d="scan'208";a="68656283" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 23 Apr 2011 15:17:22 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 23 Apr 2011 15:17:21 -0700 Message-ID: <4DB34FF0.9050002@qualcomm.com> Date: Sat, 23 Apr 2011 17:17:20 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20110413.195658.35034263.fujiwara@jprs.co.jp><4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> <503357280.26519@cnnic.cn> <4DB062C7.1080802@dcrocker.net> In-Reply-To: <4DB062C7.1080802@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Dave CROCKER , ima@ietf.org Subject: Re: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 22:17:24 -0000 On 4/21/11 12:00 PM, Dave CROCKER wrote: > Obviously my own recommendation is to have both of them use the > simpler "alternate" definitions, rather than the more complicated > "extension" approach. Darn. I didn't think that would happen. When I said "alternate" syntax, I meant using an *alternate* name (like "uMailbox"). When I said "extension" syntax, I meant *extending* the 532x syntax (like "mailbox =/ blah"). I think (unless I am very confused), Dave swapped them on me. Maybe we can just call one the "u" syntax. I don't know what to call the other. (*mumble*) pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dcrocker@bbiw.net Sat Apr 23 18:25:39 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CCEF8E0689 for ; Sat, 23 Apr 2011 18:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0I8FoJqsgoC for ; Sat, 23 Apr 2011 18:25:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id DA8BEE00BE for ; Sat, 23 Apr 2011 18:25:37 -0700 (PDT) Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3O1POQ0018111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 23 Apr 2011 18:25:30 -0700 References: <20110413.195658.35034263.fujiwara@jprs.co.jp><4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> <503357280.26519@cnnic.cn> <4DB062C7.1080802@dcrocker.net> <4DB34FF0.9050002@qualcomm.com> User-Agent: K-9 Mail for Android In-Reply-To: <4DB34FF0.9050002@qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TCWFGRV55344FQJBQ280EQ31JNF1L3" From: Dave Crocker Date: Sat, 23 Apr 2011 18:25:19 -0700 To: Pete Resnick Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 23 Apr 2011 18:25:31 -0700 (PDT) Cc: Dave CROCKER , ima@ietf.org Subject: Re: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 01:25:39 -0000 ------TCWFGRV55344FQJBQ280EQ31JNF1L3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit oops. d/ -- Dave Crocker bbiw.net (via mobile) Pete Resnick wrote: On 4/21/11 12:00 PM, Dave CROCKER wrote: > Obviously my own recommendation is to have both of them use the > simpler "alternate" definitions, rather than the more complicated > "extension" approach. Darn. I didn't think that would happen. When I said "alternate" syntax, I meant using an *alternate* name (like "uMailbox"). When I said "extension" syntax, I meant *extending* the 532x syntax (like "mailbox =/ blah"). I think (unless I am very confused), Dave swapped them on me. Maybe we can just call one the "u" syntax. I don't know what to call the other. (*mumble*) pr -- Pete Resnick; Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ------TCWFGRV55344FQJBQ280EQ31JNF1L3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit oops.


d/

--
Dave Crocker
bbiw.net

(via mobile)

Pete Resnick <presnick@qualcomm.com> wrote:
On 4/21/11 12:00 PM, Dave CROCKER wrote:
> Obviously my own recommendation is to have both of them use the 
> simpler "alternate" definitions, rather than the more complicated 
> "extension" approach. 

Darn. I didn't think that would happen.

When I said "alternate" syntax, I meant using an *alternate* name (like 
"uMailbox").

When I said "extension" syntax, I meant *extending* the 532x syntax 
(like "mailbox =/ blah").

I think (unless I am very confused), Dave swapped them on me.

Maybe we can just call one the "u" syntax. I don't know what to call the  other. (*mumble*)
 pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>;
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
------TCWFGRV55344FQJBQ280EQ31JNF1L3-- From yaojk@cnnic.cn Sat Apr 23 19:08:27 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53AD7E0727 for ; Sat, 23 Apr 2011 19:08:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.979 X-Spam-Level: X-Spam-Status: No, score=-98.979 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTnQ2QApPwgX for ; Sat, 23 Apr 2011 19:08:26 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 997A4E0722 for ; Sat, 23 Apr 2011 19:08:24 -0700 (PDT) Received: (eyou send program); Sun, 24 Apr 2011 10:08:10 +0800 Message-ID: <503610890.26535@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaogcd67c8424b) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 24 Apr 2011 10:08:10 +0800 Message-ID: From: "Jiankang Yao" To: "Pete Resnick" , References: <20110413.195658.35034263.fujiwara@jprs.co.jp><4DA58FAF.6000800@isode.com> <4DA5BA17.2010003@dcrocker.net> <502731942.13941@cnnic.cn> <503357280.26519@cnnic.cn> <4DB062C7.1080802@dcrocker.net> <503597046.01480@cnnic.cn> Date: Sun, 24 Apr 2011 10:08:03 +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.6090 Cc: Dave CROCKER , ima@ietf.org Subject: Re: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 02:08:27 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBldGUgUmVzbmljayIgPHBy ZXNuaWNrQHF1YWxjb21tLmNvbT4NClRvOiA8ZGNyb2NrZXJAYmJpdy5uZXQ+DQpDYzogIkRhdmUg Q1JPQ0tFUiIgPGRoYzJAZGNyb2NrZXIubmV0PjsgIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmlj LmNuPjsgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFN1bmRheSwgQXByaWwgMjQsIDIwMTEgNjoxNyBB TQ0KU3ViamVjdDogUmU6IFtFQUldIHVNYWlsYm94IG9yIG1haWxib3ggKEFCTkYgZm9yIHJmYzUz MzZiaXMpDQoNCg0KPiBPbiA0LzIxLzExIDEyOjAwIFBNLCBEYXZlIENST0NLRVIgd3JvdGU6DQo+ PiBPYnZpb3VzbHkgbXkgb3duIHJlY29tbWVuZGF0aW9uIGlzIHRvIGhhdmUgYm90aCBvZiB0aGVt IHVzZSB0aGUgDQo+PiBzaW1wbGVyICJhbHRlcm5hdGUiIGRlZmluaXRpb25zLCByYXRoZXIgdGhh biB0aGUgbW9yZSBjb21wbGljYXRlZCANCj4+ICJleHRlbnNpb24iIGFwcHJvYWNoLiANCj4gDQo+ IERhcm4uIEkgZGlkbid0IHRoaW5rIHRoYXQgd291bGQgaGFwcGVuLg0KPiANCj4gV2hlbiBJIHNh aWQgImFsdGVybmF0ZSIgc3ludGF4LCBJIG1lYW50IHVzaW5nIGFuICphbHRlcm5hdGUqIG5hbWUg KGxpa2UgDQo+ICJ1TWFpbGJveCIpLg0KPiANCj4gV2hlbiBJIHNhaWQgImV4dGVuc2lvbiIgc3lu dGF4LCBJIG1lYW50ICpleHRlbmRpbmcqIHRoZSA1MzJ4IHN5bnRheCANCj4gKGxpa2UgIm1haWxi b3ggPS8gYmxhaCIpLg0KPiANCj4gSSB0aGluayAodW5sZXNzIEkgYW0gdmVyeSBjb25mdXNlZCks IERhdmUgc3dhcHBlZCB0aGVtIG9uIG1lLg0KPiANCj4gTWF5YmUgd2UgY2FuIGp1c3QgY2FsbCBv bmUgdGhlICJ1IiBzeW50YXguIEkgZG9uJ3Qga25vdyB3aGF0IHRvIGNhbGwgdGhlIA0KPiBvdGhl ci4gKCptdW1ibGUqKQ0KPiANCg0Kbm93IHdlIGFyZSBjbGVhci4NCml0IGlzICAidSIgc3ludGF4 ICBWUyAgIm1haWxib3ggPS8gYmxhaCIgbW9kZWwgcHJvYmxlbS4NCg0KSWYgd2UgZmF2b3IgdGhl ICJtYWlsYm94ID0vIGJsYWgiLCBhbm90aGVyIHByb2JsZW0gaXMgaG93IHRvIGV4dGVuZCB0aGVt Lg0KDQpzb21lIG5hbWVzIHN1Y2ggYXMgbWFpbGJveCAgYXJlIGRpZmZpY3VsdCB0byB1c2UgdGhl ICAgIm1haWxib3ggPS8gYmxhaCIgIG1vZGVsLg0KDQpvcmlnaW5hbCBkZWZpbnRpb24gb2YgbWFp bGJveCBvZiByZmM1MzIxIGlzIEFTQ0lJQEFTQ0lJLg0KdGhlIG5ldyBkZWZpbnRpb24gb2YgcmZj NTMzNmJpcyBzaG91bGQgaW5jbHVkZSAgQVNDSUlAQVNDSUkuLCBBU0NJSUB1dGYtOCwgdXRmLThA QVNDSUkgLCB1dGYtOEB1dGYtOCANCg0KaWYgd2UgdXNlIHRoZSAgIm1haWxib3ggPS8gYmxhaCIg IG1vZGVsLCB0aGUgc3ludGF4IHdpbGwgYmUgc2ltaWxhciB0byBtYWlsYm94PSAvIChBU0NJSUB1 dGYtOCwgdXRmLThAQVNDSUkgLCB1dGYtOEB1dGYtOCkNCg0KZXhwcmVzc2luZyB0aGUgKEFTQ0lJ QHV0Zi04LCB1dGYtOEBBU0NJSSAsIHV0Zi04QHV0Zi04KSB1c2luZyBBQk5GIGlzIG5vdCBlYXN5 LCBicmluZyBtb3JlIEFCTkYgY29tcGxleC4NCg0KDQpidWYgaWYgd2UgIHVzZSB0aGUgIm1haWxi b3ggPSBibGFoIiBtb2RlbCBmb3IgbWFpbGJveCwgaXQgaXMgZWFzeS4NCmZvciBleGFtcGxlLA0K DQp0aGUgY3VycmVudCBkZWZpbml0aW9uIGZvciBtYWlsYm94IGlzIA0KDQonJw0KIHVNYWlsYm94 ID0gdUxvY2FsLXBhcnQgIkAiICggdURvbWFpbiAvIGFkZHJlc3MtbGl0ZXJhbCApDQogICAgOyBS ZXBsYWNlIE1haWxib3ggaW4gUkZDIDUzMjEsIFNlY3Rpb24gNC4xLjINCg0KICAgYWRkcmVzcy1s aXRlcmFsID0gPERlZmluZWQgaW4gU2VjdGlvbiA0LjEuMiBvZiBSRkMgNTMyMT4NCg0KICAgdUxv Y2FsLXBhcnQgPSB1RG90LXN0cmluZyAvIHVRdW90ZWQtc3RyaW5nDQogICAgOyBNQVkgYmUgY2Fz ZS1zZW5zaXRpdmUNCiAgICA7IFJlcGxhY2UgTG9jYWwtcGFydCBpbiBSRkMgNTMyMSwgU2VjdGlv biA0LjEuMg0KDQonJw0KDQoNCm5vdywgaWYgd2UganVzdCBjaGFuZ2UgdU1haWxib3ggdG8gTWFp bGJveCwgdGhlIGV4YW1wbGUgYWJvdmUgd2lsbCBiZWNvbWUgdG86DQoNCg0KJycNCg0KIE1haWxi b3ggPSB1TG9jYWwtcGFydCAiQCIgKCB1RG9tYWluIC8gYWRkcmVzcy1saXRlcmFsICkNCiAgICA7 IFJlcGxhY2UgTWFpbGJveCBpbiBSRkMgNTMyMSwgU2VjdGlvbiA0LjEuMg0KDQogICBhZGRyZXNz LWxpdGVyYWwgPSA8RGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4yIG9mIFJGQyA1MzIxPg0KDQogICB1 TG9jYWwtcGFydCA9IHVEb3Qtc3RyaW5nIC8gdVF1b3RlZC1zdHJpbmcNCiAgICA7IE1BWSBiZSBj YXNlLXNlbnNpdGl2ZQ0KICAgIDsgUmVwbGFjZSBMb2NhbC1wYXJ0IGluIFJGQyA1MzIxLCBTZWN0 aW9uIDQuMS4yDQoNCg0KJycgDQoNCkkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgICJtYWlsYm94 ID0gYmxhaCIgbW9kZWwgaXMgb2sgb3Igbm90Lg0KDQoNCkppYW5rYW5nIFlhbw0KDQoNCj4gcHIN Cj4gDQo+IC0tIA0KPiBQZXRlIFJlc25pY2s8aHR0cDovL3d3dy5xdWFsY29tbS5jb20vfnByZXNu aWNrLz4NCj4gUXVhbGNvbW0gSW5jb3Jwb3JhdGVkIC0gRGlyZWN0IHBob25lOiAoODU4KTY1MS00 NDc4LCBGYXg6ICg4NTgpNjUxLTExMDINCj4gDQo+ From Shawn.Steele@microsoft.com Sun Apr 24 12:43:32 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6AD8E0668 for ; Sun, 24 Apr 2011 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MOYu+jt22A3 for ; Sun, 24 Apr 2011 12:43:32 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id E34FDE065A for ; Sun, 24 Apr 2011 12:43:31 -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; Sun, 24 Apr 2011 12:43:31 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.69]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Sun, 24 Apr 2011 12:43:30 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Re: uMailbox or mailbox (ABNF for rfc5336bis) Thread-Index: AQHMArfjYh1kxoV9V0qvZUwPeNSE2Q== Date: Sun, 24 Apr 2011 19:43:30 +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.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 19:43:32 -0000 PiBvcmlnaW5hbCBkZWZpbnRpb24gb2YgbWFpbGJveCBvZiByZmM1MzIxIGlzIEFTQ0lJQEFTQ0lJ Lg0KPiB0aGUgbmV3IGRlZmludGlvbiBvZiByZmM1MzM2YmlzIHNob3VsZCBpbmNsdWRlICBBU0NJ SUBBU0NJSS4sIEFTQ0lJQHV0Zi04LCB1dGYtOEBBU0NJSSAsIHV0Zi04QHV0Zi04DQoNClRoYXQn cyB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkLCB1dGYtOEB1dGYtOCBpcyBzdWZmaWNpZW50IChB U0NJSSdzIGEgc3Vic2V0KS4gIFNwZWNpZnlpbmcgYWxsIDQgaXMganVzdCBjb25mdXNpbmcuDQoN Ci1TaGF3bg0KDQrvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3MubXNk bi5jb20vc2hhd25zdGU= From yaojk@cnnic.cn Sun Apr 24 18:09:09 2011 Return-Path: X-Original-To: ima@ietfc.amsl.com Delivered-To: ima@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 205CBE067D for ; Sun, 24 Apr 2011 18:09:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.3 X-Spam-Level: X-Spam-Status: No, score=-99.3 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7dYsOoyFMuR for ; Sun, 24 Apr 2011 18:09:08 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfc.amsl.com (Postfix) with SMTP id 62FDFE0613 for ; Sun, 24 Apr 2011 18:09:06 -0700 (PDT) Received: (eyou send program); Mon, 25 Apr 2011 09:09:05 +0800 Message-ID: <503693745.15100@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, 25 Apr 2011 09:09:05 +0800 Message-ID: From: "Jiankang YAO" To: "Shawn Steele" , References: <503674220.02340@cnnic.cn> Date: Mon, 25 Apr 2011 09:09:05 +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.6090 Subject: Re: [EAI] uMailbox or mailbox (ABNF for rfc5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 01:09:09 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNoYXduIFN0ZWVsZSIgPFNo YXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBNb25k YXksIEFwcmlsIDI1LCAyMDExIDM6NDMgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSB1TWFpbGJveCBv ciBtYWlsYm94IChBQk5GIGZvciByZmM1MzM2YmlzKQ0KDQoNCj4+IG9yaWdpbmFsIGRlZmludGlv biBvZiBtYWlsYm94IG9mIHJmYzUzMjEgaXMgQVNDSUlAQVNDSUkuDQo+PiB0aGUgbmV3IGRlZmlu dGlvbiBvZiByZmM1MzM2YmlzIHNob3VsZCBpbmNsdWRlICBBU0NJSUBBU0NJSS4sIEFTQ0lJQHV0 Zi04LCB1dGYtOEBBU0NJSSAsIHV0Zi04QHV0Zi04DQo+IA0KPiBUaGF0J3MgdW5uZWNlc3Nhcmls eSBjb21wbGljYXRlZCwgdXRmLThAdXRmLTggaXMgc3VmZmljaWVudCAoQVNDSUkncyBhIHN1YnNl dCkuICBTcGVjaWZ5aW5nIGFsbCA0IGlzIGp1c3QgY29uZnVzaW5nLg0KPiANCg0KaWYgd2UgY2hv b3NlIHRvIHVzZSB0aGUgZXh0ZW5kZWQgbW9kZWwgKG1haWxib3g9IG1haWxib3ggLyAgKioqKiks IGl0IHNlZW1zIHRoYXQgd2UgaGF2ZSB0byB1c2UgdGhpcyBjb21wbGljYXRlZCBtb2RlbC4NCg0K SmlhbmthbmcgWWFvDQoNCj4gLVNoYXduDQo+IA0KPiDvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU 76OZDQo+IGh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElN QUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0K Pg== From yaojk@cnnic.cn Mon Apr 25 16:00:59 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1B0E06BD for ; Mon, 25 Apr 2011 16:00:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -97.439 X-Spam-Level: X-Spam-Status: No, score=-97.439 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7rZxeGe0cPI for ; Mon, 25 Apr 2011 16:00:59 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id B3D91E067E for ; Mon, 25 Apr 2011 16:00:53 -0700 (PDT) Received: (eyou send program); Tue, 26 Apr 2011 07:00:49 +0800 Message-ID: <503772449.20058@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaogcd67c8424b) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 26 Apr 2011 07:00:49 +0800 Message-ID: From: "Jiankang Yao" To: Date: Tue, 26 Apr 2011 07:00:41 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CC03DF.A7AD6210" 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.6090 Subject: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 23:00:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01CC03DF.A7AD6210 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgICBBbm90aGVyIHRob3VnaHQgb24gdU1haWxib3ggYW5kIE1haWxib3gg QUJORiBzeW50YXguIExldCB1cyBjb25zaWRlciB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOg0KDQpT dGVwIDE6IEFsaWNlIHdpdGggYW4gQVNDSUlAQVNDSUkgYWRkcmVzcyBmcm9tIHJmYzUzMjEgc3lz dGVtIHNlbmQgdGhlIG1lc3NhZ2UgdG8gQk9CIHdpdGggYW4gQVNDSUlAQS1sYWJsZSBvciBBU0NJ SUBBU0NJSSBhZGRyZXNzIGZyb20gdGhlIEVBSS1hd2FyZSBYWCBzeXN0ZW0uICANClNldHAgMjog Qk9CIHdpdGggYW4gQVNDSUlAQS1sYWJsZSBvciBBU0NJSUBBU0NJSSBhZGRyZXNzIGZyb20gdGhl IEVBSS1hd2FyZSBYWCBzeXN0ZW0gcmVwbHlzIHRoZSBtZXNzYWdlIHRvIEFsaWNlIHdpdGggYW4g QVNDSUlAQVNDSUkgYWRkcmVzcy4NCg0KSWYgd2UgYWxsb3cgdGhlIHN0ZXAgMiBoYXBwZW4sIHRo ZSBFQUktYXdhcmUgWFggc3lzdGVtICBzaG91bGQgcmVjb2duaXplIGJvdGggdU1haWxib3ggYW5k IE1haWxib3ggb3IgbWFrZSBhIGRpZmZlcmVuY2UgYmV0d2VlbiBNYWlsYm94IGFuZCB1TWFpbGJv eC4NCmJ1dCBpZiB3ZSByZWZ1c2Ugc3RlcCAyIHRvIGJlIGhhcHBlbmVkLCBpdCBsb29rcyBsaWtl IGEgbGl0dGxlIHN0cmFuZ2UuDQoNCkFueSB0aG91Z2h0Pw0KDQoNCkppYW5rYW5nIFlhbw== ------=_NextPart_000_001D_01CC03DF.A7AD6210 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MDQ2Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+RGVhciBhbGwsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFub3RoZXIgdGhvdWdodCBvbiB1TWFpbGJveCBh bmQgTWFpbGJveCANCkFCTkYgc3ludGF4LiBMZXQgdXMgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBz Y2VuYXJpbzo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5TdGVwIDE6IEFsaWNlIHdpdGggYW4gPEEgDQpocmVmPSJt YWlsdG86QVNDSUlAQVNDSUkiPkFTQ0lJQEFTQ0lJPC9BPiBhZGRyZXNzIGZyb20gcmZjNTMyMSBz eXN0ZW0mbmJzcDtzZW5kIA0KdGhlIG1lc3NhZ2UgdG8gQk9CIHdpdGggYW4gPEEgaHJlZj0ibWFp bHRvOkFTQ0lJQEEtbGFibGUiPkFTQ0lJQEEtbGFibGU8L0E+IG9yIA0KPEEgaHJlZj0ibWFpbHRv OkFTQ0lJQEFTQ0lJIj5BU0NJSUBBU0NJSTwvQT4mbmJzcDthZGRyZXNzIGZyb20gDQp0aGUmbmJz cDtFQUktYXdhcmUgWFggc3lzdGVtLiZuYnNwOyZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPlNldHAgMjogQk9CIHdpdGggYW4gPEEgDQpocmVmPSJtYWlsdG86QVNDSUlAQS1s YWJsZSI+QVNDSUlAQS1sYWJsZTwvQT4gb3IgPEEgDQpocmVmPSJtYWlsdG86QVNDSUlAQVNDSUki PkFTQ0lJQEFTQ0lJPC9BPiZuYnNwO2FkZHJlc3MmbmJzcDtmcm9tIA0KdGhlJm5ic3A7RUFJLWF3 YXJlIFhYIHN5c3RlbSByZXBseXMgdGhlIG1lc3NhZ2UgdG8gQWxpY2Ugd2l0aCBhbiA8QSANCmhy ZWY9Im1haWx0bzpBU0NJSUBBU0NJSSI+QVNDSUlAQVNDSUk8L0E+IGFkZHJlc3MuPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+SWYgd2UgYWxsb3cgdGhlIHN0ZXAgMiBoYXBwZW4sIHRoZSZuYnNwO0VBSS1hd2FyZSBY WCANCnN5c3RlbSZuYnNwOyBzaG91bGQgcmVjb2duaXplIGJvdGggdU1haWxib3ggYW5kIE1haWxi b3ggb3IgbWFrZSBhIGRpZmZlcmVuY2UgDQpiZXR3ZWVuIE1haWxib3ggYW5kIHVNYWlsYm94Ljwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmJ1dCBpZiB3ZSByZWZ1c2Ugc3RlcCAyIHRv IGJlIGhhcHBlbmVkLCBpdCBsb29rcyBsaWtlIGEgbGl0dGxlIA0Kc3RyYW5nZS48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5BbnkmbmJzcDt0aG91Z2h0PzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkppYW5rYW5nIFlhbzwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_000_001D_01CC03DF.A7AD6210-- From dhc2@dcrocker.net Mon Apr 25 17:33:39 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390C4E067B for ; Mon, 25 Apr 2011 17:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0up8IEOopdM for ; Mon, 25 Apr 2011 17:33:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE75E0674 for ; Mon, 25 Apr 2011 17:33:38 -0700 (PDT) Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3Q0XUOc015056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 Apr 2011 17:33:35 -0700 Message-ID: <4DB612CF.6030605@dcrocker.net> Date: Mon, 25 Apr 2011 17:33:19 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang Yao References: <503772449.20058@cnnic.cn> In-Reply-To: <503772449.20058@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 25 Apr 2011 17:33:35 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 00:33:39 -0000 On 4/25/2011 4:00 PM, Jiankang Yao wrote: > Dear all, > Another thought on uMailbox and Mailbox ABNF syntax. Let us consider the > following scenario: > Step 1: Alice with an ASCII@ASCII address from rfc5321 > system send the message to BOB with an ASCII@A-lable or > ASCII@ASCII address from the EAI-aware XX system. > Setp 2: BOB with an ASCII@A-lable or ASCII@ASCII > address from the EAI-aware XX system replys the message to > Alice with an ASCII@ASCII address. > If we allow the step 2 happen, the EAI-aware XX system should recognize both > uMailbox and Mailbox or make a difference between Mailbox and uMailbox. > but if we refuse step 2 to be happened, it looks like a little strange. > Any thought? The basic problem with your approach is that you are still trying to define a hybrid ASCII + UTF-8 system. However that is no longer the model, for the current, core specifications. The current model is for sending UTF-8 addresses to systems that support UTF-8 addresses. Note that an ASCII@ASCII address is /also/ a UTF-8@UTF-8 address. So there is not need to have the syntax support both ASCII and UTF-8 addresses. They only need to support UTF-8 addresses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yaojk@cnnic.cn Mon Apr 25 18:48:25 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B6AE068C for ; Mon, 25 Apr 2011 18:48:25 -0700 (PDT) X-Quarantine-ID: <1bRDGp9WgMa4> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.741 X-Spam-Level: X-Spam-Status: No, score=-98.741 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bRDGp9WgMa4 for ; Mon, 25 Apr 2011 18:48:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 0AD78E062A for ; Mon, 25 Apr 2011 18:48:23 -0700 (PDT) Received: (eyou send program); Tue, 26 Apr 2011 09:48:23 +0800 Message-ID: <503782503.03885@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, 26 Apr 2011 09:48:23 +0800 Message-ID: From: "Jiankang YAO" To: References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> Date: Tue, 26 Apr 2011 09:48:22 +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.6090 Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 01:48:25 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo YzJAZGNyb2NrZXIubmV0Pg0KVG86ICJKaWFua2FuZyBZYW8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNj OiA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgQXByaWwgMjYsIDIwMTEgODozMyBBTQ0K U3ViamVjdDogUmU6IFtFQUldIFRoZSBzY2VuYXJpbyBmYXZvcmluZyAidU1haWxib3giPw0KDQoN Cj4gDQo+IA0KPiBPbiA0LzI1LzIwMTEgNDowMCBQTSwgSmlhbmthbmcgWWFvIHdyb3RlOg0KPj4g RGVhciBhbGwsDQo+PiBBbm90aGVyIHRob3VnaHQgb24gdU1haWxib3ggYW5kIE1haWxib3ggQUJO RiBzeW50YXguIExldCB1cyBjb25zaWRlciB0aGUNCj4+IGZvbGxvd2luZyBzY2VuYXJpbzoNCj4+ IFN0ZXAgMTogQWxpY2Ugd2l0aCBhbiBBU0NJSUBBU0NJSSA8bWFpbHRvOkFTQ0lJQEFTQ0lJPiBh ZGRyZXNzIGZyb20gcmZjNTMyMQ0KPj4gc3lzdGVtIHNlbmQgdGhlIG1lc3NhZ2UgdG8gQk9CIHdp dGggYW4gQVNDSUlAQS1sYWJsZSA8bWFpbHRvOkFTQ0lJQEEtbGFibGU+IG9yDQo+PiBBU0NJSUBB U0NJSSA8bWFpbHRvOkFTQ0lJQEFTQ0lJPiBhZGRyZXNzIGZyb20gdGhlIEVBSS1hd2FyZSBYWCBz eXN0ZW0uDQo+PiBTZXRwIDI6IEJPQiB3aXRoIGFuIEFTQ0lJQEEtbGFibGUgPG1haWx0bzpBU0NJ SUBBLWxhYmxlPiBvciBBU0NJSUBBU0NJSQ0KPj4gPG1haWx0bzpBU0NJSUBBU0NJST4gYWRkcmVz cyBmcm9tIHRoZSBFQUktYXdhcmUgWFggc3lzdGVtIHJlcGx5cyB0aGUgbWVzc2FnZSB0bw0KPj4g QWxpY2Ugd2l0aCBhbiBBU0NJSUBBU0NJSSA8bWFpbHRvOkFTQ0lJQEFTQ0lJPiBhZGRyZXNzLg0K Pj4gSWYgd2UgYWxsb3cgdGhlIHN0ZXAgMiBoYXBwZW4sIHRoZSBFQUktYXdhcmUgWFggc3lzdGVt IHNob3VsZCByZWNvZ25pemUgYm90aA0KPj4gdU1haWxib3ggYW5kIE1haWxib3ggb3IgbWFrZSBh IGRpZmZlcmVuY2UgYmV0d2VlbiBNYWlsYm94IGFuZCB1TWFpbGJveC4NCj4+IGJ1dCBpZiB3ZSBy ZWZ1c2Ugc3RlcCAyIHRvIGJlIGhhcHBlbmVkLCBpdCBsb29rcyBsaWtlIGEgbGl0dGxlIHN0cmFu Z2UuDQo+PiBBbnkgdGhvdWdodD8NCj4gDQo+IA0KPiBUaGUgYmFzaWMgcHJvYmxlbSB3aXRoIHlv dXIgYXBwcm9hY2ggaXMgdGhhdCB5b3UgYXJlIHN0aWxsIHRyeWluZyB0byBkZWZpbmUgYSANCj4g aHlicmlkIEFTQ0lJICsgVVRGLTggc3lzdGVtLiAgSG93ZXZlciB0aGF0IGlzIG5vIGxvbmdlciB0 aGUgbW9kZWwsIGZvciB0aGUgDQo+IGN1cnJlbnQsIGNvcmUgc3BlY2lmaWNhdGlvbnMuDQo+IA0K DQpJIGFtIG5vdCB0cnlpbmcgdG8gZGVmaW5lIGEgaHlicmlkIEFTQ0lJICsgVVRGLTggc3lzdGVt LiANCmJ1dCBJIHRoaW5rIHRoYXQgdGhlIGltcGxlbWVudG9yIHdpbGwgYmUgbGlrZWx5IHRvIGNo b29zZSB0byByZWNvZ25pemUgYm90aCByZmM1MzIxIGFkZHJlc3MgYW5kIFVURi04IGFkZHJlc3Mu DQpJZiB0aGV5IGNob29zZSB0byByZWNvZ25pemUgYm90aCBhZGRyZXNzZXMsIHdlIHNob3VsZCBn aXZlIHRoZW0gbW9yZSBjb252ZW5pZW50IHdheSB0byBkbyBpdC4NCg0KPg0KPiBUaGUgY3VycmVu dCBtb2RlbCBpcyBmb3Igc2VuZGluZyBVVEYtOCBhZGRyZXNzZXMgdG8gc3lzdGVtcyB0aGF0IHN1 cHBvcnQgVVRGLTggDQo+IGFkZHJlc3Nlcy4gIE5vdGUgdGhhdCBhbiBBU0NJSUBBU0NJSSBhZGRy ZXNzIGlzIC9hbHNvLyBhIFVURi04QFVURi04IGFkZHJlc3MuDQo+IA0KDQp5ZXMsICBhbiBBU0NJ SUBBU0NJSSBhZGRyZXNzIGlzIC9hbHNvLyBhIFVURi04QFVURi04IGFkZHJlc3MuIA0KDQpJdCBt ZWFucyB0aGF0IEVBSSBzeXN0ZW0gc3VwcG9ydHMgQVNDSUlAQVNDSUkgYWRkcmVzcyB0b28gYmVj YXVzZSByZmM1MzM2LzViaXMgZGVmaW5lICBVVEYtOEBVVEYtOCBhZGRyZXNzLg0KDQp0aGUgcHJv YmxlbSBpcyB0aGF0Og0KDQp0aGUgcmZjNTMzNmJpcyBzYWlkDQoNCiAiDQoNCklmIHRoZSBVVEY4 U01UUGJpcyBTTVRQIGV4dGVuc2lvbiBpcyBub3Qgb2ZmZXJlZCBieSB0aGUgU01UUCBzZXJ2ZXIs DQogICB0aGUgRUFJLWF3YXJlIFNNVFAgY2xpZW50IE1VU1QgTk9UIHRyYW5zbWl0IGFuIGludGVy bmF0aW9uYWxpemVkDQogICBlbWFpbCBhZGRyZXNzIGFuZCBNVVNUIE5PVCB0cmFuc21pdCBhIG1h aWwgbWVzc2FnZSBjb250YWluaW5nDQogICBpbnRlcm5hdGlvbmFsaXplZCBtYWlsIGhlYWRlcnMg YXMgZGVzY3JpYmVkIGluIFtSRkM1MzM1YmlzXQ0KIg0KDQpub3cgdGhlIG1lc3NhZ2UgZnJvbSBC T0IgdG8gQWxpY2UgY29udGFpbmluZyB0aGUgQk9CJ3MgQVNDSUlAQS1sYWJlbCBvciBBU0NJSUBB U0NJSSBhZGRyZXNzIGFuZCBBbGljZSdzIEFTQ0lJQEFTQ0lJIGFkZHJlc3MgaXMgaW50ZXJuYXRp b25hbGl6ZWQgbWVzc2FnZSBvciBub3Q/DQoNCmlmIHdlIHJlZ2FyZCBpdCBhcyB0aGUgIGludGVy bmF0aW9uYWxpemVkIG1lc3NhZ2UsIHdlIGNhbiBub3Qgc2VuZCBpdCBhY2NvcmRpbmcgdG8gdGhl IHJ1bGUgYWJvdmUgZGVmaW5lZCBpbiByZmM1MzM2YmlzIGJlY2F1c2UgQWxpY2UncyBlbWFpbCBz ZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCAgVVRGOFNNVFBiaXMgU01UUCBleHRlbnNpb24gLiANCg0K aWYgd2UgcmVnYXJkIGl0IGFzIG5vbi1pbnRlcm5hdGlvbmFsaXplZCBtZXNzYWdlLCB0aGUgRUFJ LWF3YXJlIFhYIHN5c3RlbSBzaG91bGQga25vdyBpdCBvciBhdCBsZWFzdCBrbm93IHRoYXQgaXQg aXMgbm90IGludGVybmF0aW9uYWxpemVkIG1lc3NhZ2UuIEZ1cnRoZXJtb3JlLCBpZiAgIHRoZSBF QUktYXdlYXJlIFhYIHN5c3RlbSBoYXBwZW5zIHRvIGtub3cgdGhhdCBpdCBpcyByZmM1MzIyLzIx IG1lc3NhZ2UgYW5kIHNob3VsZCBmb2xsb3cgdGhlIHJmYzUzMjEvMjIgcnVsZSwgdGhlIFhYIHN5 c3RlbSBhbmQgc2VuZCB0aGlzIG1lc3NhZ2U7IGlmICAgdGhlIEVBSS1hd2FyZSBYWCBzeXN0ZW0g cmVjb2duaXplIHRoYXQgaXQgaXMgbm9uLWludGVybmF0aW9uYWxpemVkIG1lc3NhZ2UgYnV0IGRv ZXMgbm90IGtub3cgaXQgaXMgcmZjNTMyMi8yMSBtZXNzYWdlIG9yIG5vdCwgdGhlIFhYIHN5c3Rt ZSBtYXkgcmVmdXNlIHRvIHNlbmQgdGhpcyBtZXNzYWdlIGZyb20gQk9CIHRvIEFsaWNlIGNvbnRh aW5pbmcgdGhlIEJPQidzIEFTQ0lJQEEtbGFiZWwgb3IgQVNDSUlAQVNDSUkgYWRkcmVzcyBhbmQg QWxpY2UncyBBU0NJSUBBU0NJSSBhZGRyZXNzIC4NCg0KSWYgd2UgYWxsb3cgQk9CIHdpdGggYW4g QVNDSUlAQS1sYWJsZSBvciBBU0NJSUBBU0NJSSBhZGRyZXNzIGZyb20gdGhlIEVBSS1hd2FyZSBY WCBzeXN0ZW0gdG8gcmVwbHkgdGhlIG1lc3NhZ2UgdG8gQWxpY2Ugd2l0aCBhbiBBU0NJSUBBU0NJ SSBhZGRyZXNzIGZyb20gcmZjNTMyMSBzeXN0ZW0sIG1ha2luZyBhIGRpZmZlcmVuY2UgaW4gdU1h aWxib3ggYW5kIE1haWxib3ggaXMgaW1wb3JhbnQgYWx0aG9naCB3ZSBkbyBub3QgdHJ5IHRvIGRl ZmluZSBhIGh5YnJpZCBBU0NJSSArIFVURi04IHN5c3RlbS4NCg0KSmlhbmthbmcgWWFvDQoNCg0K PiBTbyB0aGVyZSBpcyBub3QgbmVlZCB0byBoYXZlIHRoZSBzeW50YXggc3VwcG9ydCBib3RoIEFT Q0lJIGFuZCBVVEYtOCBhZGRyZXNzZXMuIA0KPiAgVGhleSBvbmx5IG5lZWQgdG8gc3VwcG9ydCBV VEYtOCBhZGRyZXNzZXMuDQo+IA0KPiBkLw0KPiANCj4gLS0gDQo+IA0KPiAgIERhdmUgQ3JvY2tl cg0KPiAgIEJyYW5kZW5idXJnIEludGVybmV0V29ya2luZw0KPiAgIGJiaXcubmV0 From dhc2@dcrocker.net Mon Apr 25 19:38:24 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB2DE06B6 for ; Mon, 25 Apr 2011 19:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0erMYgWW5lF for ; Mon, 25 Apr 2011 19:38:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9DE069E for ; Mon, 25 Apr 2011 19:38:23 -0700 (PDT) Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3Q2cCkW021701 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 Apr 2011 19:38:17 -0700 Message-ID: <4DB63009.8060602@dcrocker.net> Date: Mon, 25 Apr 2011 19:38:01 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang YAO References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> In-Reply-To: <503782503.03885@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 25 Apr 2011 19:38:18 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 02:38:24 -0000 On 4/25/2011 6:48 PM, Jiankang YAO wrote: > I am not trying to define a hybrid ASCII + UTF-8 system. but I think that the > implementor will be likely to choose to recognize both rfc5321 address and > UTF-8 address. If they choose to recognize both addresses, we should give > them more convenient way to do it. It is natural to want to be friendly to the implementer. However no, a specification usually must not try to anticipate implementation work that goes beyond the primary goal of the specification. The job of the specification is to define only what it is supposed to cover. In this case, the current goal of the specification is to support UTF-8. The fact that someone might make implementation decisions that go beyond what is covered does not mean that the scope of the specification should be changed. This is an example of the very basic difference between a protocol specification and an implementation specification. >> The current model is for sending UTF-8 addresses to systems that support >> UTF-8 addresses. Note that an ASCII@ASCII address is /also/ a UTF-8@UTF-8 >> address. > > yes, an ASCII@ASCII address is /also/ a UTF-8@UTF-8 address. > > It means that EAI system supports ASCII@ASCII address too because > rfc5336/5bis define UTF-8@UTF-8 address. You have been using ASCII@ASCII to refer to addresses that are not 8-bit. Hence, no, the current specification does not have the goal of supporting ASCII@ASCII. It's goal is to transmit data that are full 8-bits. The fact that some of that data might also qualify as ASCII is proving to be a distraction. That's why it is especially important to have everything put only in terms of UTF-8. > the problem is that: > the rfc5336bis said > > " If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, the > EAI-aware SMTP client MUST NOT transmit an internationalized email address > and MUST NOT transmit a mail message containing internationalized mail > headers as described in [RFC5335bis] " Yes, but the specification does not provide for downgrade. That's the job of separate specifications that cover such gateway translation behavior, but it is not the job of these core specifications. > now the message from BOB to Alice containing the BOB's ASCII@A-label or > ASCII@ASCII address and Alice's ASCII@ASCII address is internationalized > message or not? For the purposes of this specification, there are no ASCII@ASCII addresses. All addresses are UTF-8@UTF-8. > if we regard it as the internationalized message, we can not send it > according to the rule above defined in rfc5336bis because Alice's email > server does not support UTF8SMTPbis SMTP extension . The current specification does not define how to handle messages that are not UTF-8. The previous version tried to specify that hybrid but it did not succeed. The current specification is trying to cover only the simpler, cleaner case: UTF-8@UTF-8. > if we regard it as non-internationalized message, the EAI-aware XX system > should know it or at least know that it is not internationalized message. If it is not an internationalized message, then it has nothing to do with the EAI working group. Or, at least, it has nothing to do with these two, core specifications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yaojk@cnnic.cn Mon Apr 25 20:37:22 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B754E06BB for ; Mon, 25 Apr 2011 20:37:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.066 X-Spam-Level: X-Spam-Status: No, score=-99.066 tagged_above=-999 required=5 tests=[AWL=0.977, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK8rTyc7lOFQ for ; Mon, 25 Apr 2011 20:37:21 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6680DE06BF for ; Mon, 25 Apr 2011 20:37:20 -0700 (PDT) Received: (eyou send program); Tue, 26 Apr 2011 11:37:19 +0800 Message-ID: <503789039.15208@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, 26 Apr 2011 11:37:19 +0800 Message-ID: From: "Jiankang YAO" To: References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <503785503.12770@cnnic.cn> Date: Tue, 26 Apr 2011 11:37:18 +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.6090 Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 03:37:22 -0000 DQpGcm9tIHlvdXIgY29tbWVudHMsIEkgaGF2ZSBhIGZlZWxpbmcgYmVsb3csIGJ1dCBub3Qgc3Vy ZSB3aGVodGVyIGl0IGlzIHJpZ2hpdCBvciBub3QuDQoNCkZvciB0aGUgZXhhbXBsZQ0KIg0KU3Rl cCAxOiBBbGljZSB3aXRoIGFuIEFCQ0BleGFtcGxlMi5jb20gIGFkZHJlc3MgZnJvbSByZmM1MzIx IHN5c3RlbSBzZW5kIHRoZSBtZXNzYWdlIHRvIEJPQiB3aXRoIGFuICBhYmNAZXhhbXBsZS5jb20g b3IgYWJjQGEtbGFiZWwgKEFTQ0lJQEEtbGFibGUgb3IgQVNDSUlAQVNDSUkpIGFkZHJlc3MgZnJv bSB0aGUgcHVyZSBFQUktYXdhcmUgc3lzdGUuICANClNldHAgMjogQk9CIHdpdGggYW4gIGFiY0Bl eGFtcGxlLmNvbSBvciBhYmNAYS1sYWJlbCAoQVNDSUlAQS1sYWJsZSBvciBBU0NJSUBBU0NJSSkg YWRkcmVzcyBmcm9tIHRoZSBwdXJlIEVBSS1hd2FyZSBzeXN0ZW0gdHJ5IHRvIHJlcGx5IHRoZSBt ZXNzYWdlIHRvIEFsaWNlIHdpdGggYW4gQVNDSUlAQVNDSUkgYWRkcmVzcy4NCg0KIg0KSWYgIGFi Y0BleGFtcGxlLmNvbSBvciBhYmNAYS1sYWJlbCAoQVNDSUlAQS1sYWJsZSBvciBBU0NJSUBBU0NJ SSkgYXJlIGluIHRoZSBVVEYtOCBmb3JtLCAgdGhlIGN1cnJlbnQgRUFJIGNvcmUgc3lzdGVtIGFs bG93IGl0IHRvIGJlIHNlbnQuDQpJZiBhYmNAZXhhbXBsZS5jb20gb3IgYWJjQGEtbGFiZWwgKEFT Q0lJQEEtbGFibGUgb3IgQVNDSUlAQVNDSUkpIGFyZSBpbiB0aGUgQVNDSUkgIGZvcm0sICB0aGUg Y3VycmVudCBFQUkgY29yZSBzeXN0ZW0gZG9lcyBub3QgYWxsb3cgaXQgdG8gYmUgc2VudCBvciBk byBub3QgY2FyZSBmb3IgaXQuDQoNCklmIHRoYXQgaXMgdHJ1ZSwNCml0ICBtZWFucyB0aGF0IEFs aWNlIHdpdGggYW4gYWJjQGV4YW1wbGUyLmNvbSBhZGRyZXNzIGZyb20gcmZjNTMyMSBzeXN0ZW0g Y2FuIHNlbmQgdGhlIG1lc3NhZ2UgdG8gQk9CIHdpdGggYW4gIGFiY0BleGFtcGxlLmNvbSBvciBh YmNAYS1sYWJlbGFkZHJlc3MgZnJvbSB0aGUgUHVyZSBFQUktYXdhcmUgc3lzdGVtOw0KYnV0IEJP QiB3aXRoIHRoZSBhYmNAZXhhbXBsZS5jb20gb3IgYWJjQGEtbGFiZWwgYWRkcmVzcyBpbiB0aGUg IFB1cmUgRUFJLWF3YXJlIHN5c3RlbSBjYW4gbm90IHJlcGx5IGl0IHRvIEFsaWNlIHdpdGggdGhl IGFiY0BleGFtcGxlMi5jb20gc2luY2UgQWxpY2UncyBzeXN0ZW0gZG9lcyBub3Qgc3VwcG9ydCBV VEY4U01UUCBleHRlbnNpb24uDQoNCg0Kc28gdGhlIGNvbmNsdXNpb24gaXMgdGhhdCBFQUkgc3lz dGVtIGJsb2NrcyB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFiY0BleGFtcGxlLmNvbSBvciBh YmNAYS1sYWJlbCAgaW4gdGhlIHB1cmUgRUFJIHN5c3RlbSAgYW5kIGFiY0BleGFtcGxlMi5jb20g aW4gcmZjMjgyMSBzeXN0ZW0/Pw0KDQoNCkppYW5rYW5nIFlhbw0KDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRoYzJAZGNyb2NrZXIubmV0Pg0K VG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNjOiA8aW1hQGlldGYub3JnPg0K U2VudDogVHVlc2RheSwgQXByaWwgMjYsIDIwMTEgMTA6MzggQU0NClN1YmplY3Q6IFJlOiBbRUFJ XSBUaGUgc2NlbmFyaW8gZmF2b3JpbmcgInVNYWlsYm94Ij8NCg0KDQo+IA0KPiANCj4gT24gNC8y NS8yMDExIDY6NDggUE0sIEppYW5rYW5nIFlBTyB3cm90ZToNCj4+IEkgYW0gbm90IHRyeWluZyB0 byBkZWZpbmUgYSBoeWJyaWQgQVNDSUkgKyBVVEYtOCBzeXN0ZW0uIGJ1dCBJIHRoaW5rIHRoYXQg dGhlDQo+PiBpbXBsZW1lbnRvciB3aWxsIGJlIGxpa2VseSB0byBjaG9vc2UgdG8gcmVjb2duaXpl IGJvdGggcmZjNTMyMSBhZGRyZXNzIGFuZA0KPj4gVVRGLTggYWRkcmVzcy4gSWYgdGhleSBjaG9v c2UgdG8gcmVjb2duaXplIGJvdGggYWRkcmVzc2VzLCB3ZSBzaG91bGQgZ2l2ZQ0KPj4gdGhlbSBt b3JlIGNvbnZlbmllbnQgd2F5IHRvIGRvIGl0Lg0KPiANCj4gSXQgaXMgbmF0dXJhbCB0byB3YW50 IHRvIGJlIGZyaWVuZGx5IHRvIHRoZSBpbXBsZW1lbnRlci4NCj4gDQo+IEhvd2V2ZXIgbm8sIGEg c3BlY2lmaWNhdGlvbiB1c3VhbGx5IG11c3Qgbm90IHRyeSB0byBhbnRpY2lwYXRlIGltcGxlbWVu dGF0aW9uIA0KPiB3b3JrIHRoYXQgZ29lcyBiZXlvbmQgdGhlIHByaW1hcnkgZ29hbCBvZiB0aGUg c3BlY2lmaWNhdGlvbi4gIFRoZSBqb2Igb2YgdGhlIA0KPiBzcGVjaWZpY2F0aW9uIGlzIHRvIGRl ZmluZSBvbmx5IHdoYXQgaXQgaXMgc3VwcG9zZWQgdG8gY292ZXIuICBJbiB0aGlzIGNhc2UsIHRo ZSANCj4gY3VycmVudCBnb2FsIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHRvIHN1cHBvcnQgVVRG LTguDQo+IA0KPiBUaGUgZmFjdCB0aGF0IHNvbWVvbmUgbWlnaHQgbWFrZSBpbXBsZW1lbnRhdGlv biBkZWNpc2lvbnMgdGhhdCBnbyBiZXlvbmQgd2hhdCBpcw0KPiBjb3ZlcmVkIGRvZXMgbm90IG1l YW4gdGhhdCB0aGUgc2NvcGUgb2YgdGhlIHNwZWNpZmljYXRpb24gc2hvdWxkIGJlIGNoYW5nZWQu DQo+IFRoaXMgaXMgYW4gZXhhbXBsZSBvZiB0aGUgdmVyeSBiYXNpYyBkaWZmZXJlbmNlIGJldHdl ZW4gYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uDQo+IGFuZCBhbiBpbXBsZW1lbnRhdGlvbiBzcGVj aWZpY2F0aW9uLg0KPiANCj4gDQo+Pj4gVGhlIGN1cnJlbnQgbW9kZWwgaXMgZm9yIHNlbmRpbmcg VVRGLTggYWRkcmVzc2VzIHRvIHN5c3RlbXMgdGhhdCBzdXBwb3J0DQo+Pj4gVVRGLTggYWRkcmVz c2VzLiAgTm90ZSB0aGF0IGFuIEFTQ0lJQEFTQ0lJIGFkZHJlc3MgaXMgL2Fsc28vIGEgVVRGLThA VVRGLTgNCj4+PiBhZGRyZXNzLg0KPj4NCj4+IHllcywgIGFuIEFTQ0lJQEFTQ0lJIGFkZHJlc3Mg aXMgL2Fsc28vIGEgVVRGLThAVVRGLTggYWRkcmVzcy4NCj4+DQo+PiBJdCBtZWFucyB0aGF0IEVB SSBzeXN0ZW0gc3VwcG9ydHMgQVNDSUlAQVNDSUkgYWRkcmVzcyB0b28gYmVjYXVzZQ0KPj4gcmZj NTMzNi81YmlzIGRlZmluZSAgVVRGLThAVVRGLTggYWRkcmVzcy4NCj4gDQo+IFlvdSBoYXZlIGJl ZW4gdXNpbmcgQVNDSUlAQVNDSUkgdG8gcmVmZXIgdG8gYWRkcmVzc2VzIHRoYXQgYXJlIG5vdCA4 LWJpdC4NCj4gDQo+IEhlbmNlLCBubywgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCBoYXZlIHRoZSBnb2FsIG9mIHN1cHBvcnRpbmcgDQo+IEFTQ0lJQEFTQ0lJLiAgSXQncyBnb2Fs IGlzIHRvIHRyYW5zbWl0IGRhdGEgdGhhdCBhcmUgZnVsbCA4LWJpdHMuICBUaGUgZmFjdCB0aGF0 IA0KPiBzb21lIG9mIHRoYXQgZGF0YSBtaWdodCBhbHNvIHF1YWxpZnkgYXMgQVNDSUkgaXMgcHJv dmluZyB0byBiZSBhIGRpc3RyYWN0aW9uLiANCj4gVGhhdCdzIHdoeSBpdCBpcyBlc3BlY2lhbGx5 IGltcG9ydGFudCB0byBoYXZlIGV2ZXJ5dGhpbmcgcHV0IG9ubHkgaW4gdGVybXMgb2YgVVRGLTgu DQo+IA0KPiANCj4+IHRoZSBwcm9ibGVtIGlzIHRoYXQ6DQo+PiB0aGUgcmZjNTMzNmJpcyBzYWlk DQo+Pg0KPj4gIiBJZiB0aGUgVVRGOFNNVFBiaXMgU01UUCBleHRlbnNpb24gaXMgbm90IG9mZmVy ZWQgYnkgdGhlIFNNVFAgc2VydmVyLCB0aGUNCj4+IEVBSS1hd2FyZSBTTVRQIGNsaWVudCBNVVNU IE5PVCB0cmFuc21pdCBhbiBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRyZXNzDQo+PiBhbmQg TVVTVCBOT1QgdHJhbnNtaXQgYSBtYWlsIG1lc3NhZ2UgY29udGFpbmluZyBpbnRlcm5hdGlvbmFs aXplZCBtYWlsDQo+PiBoZWFkZXJzIGFzIGRlc2NyaWJlZCBpbiBbUkZDNTMzNWJpc10gIg0KPiAN Cj4gWWVzLCBidXQgdGhlIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcHJvdmlkZSBmb3IgZG93bmdy YWRlLiAgVGhhdCdzIHRoZSBqb2Igb2YgDQo+IHNlcGFyYXRlIHNwZWNpZmljYXRpb25zIHRoYXQg Y292ZXIgc3VjaCBnYXRld2F5IHRyYW5zbGF0aW9uIGJlaGF2aW9yLCBidXQgaXQgaXMgDQo+IG5v dCB0aGUgam9iIG9mIHRoZXNlIGNvcmUgc3BlY2lmaWNhdGlvbnMuDQo+IA0KPiANCj4+IG5vdyB0 aGUgbWVzc2FnZSBmcm9tIEJPQiB0byBBbGljZSBjb250YWluaW5nIHRoZSBCT0IncyBBU0NJSUBB LWxhYmVsIG9yDQo+PiBBU0NJSUBBU0NJSSBhZGRyZXNzIGFuZCBBbGljZSdzIEFTQ0lJQEFTQ0lJ IGFkZHJlc3MgaXMgaW50ZXJuYXRpb25hbGl6ZWQNCj4+IG1lc3NhZ2Ugb3Igbm90Pw0KPiANCj4g Rm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIHNwZWNpZmljYXRpb24sIHRoZXJlIGFyZSBubyBBU0NJ SUBBU0NJSSBhZGRyZXNzZXMuICBBbGwgDQo+IGFkZHJlc3NlcyBhcmUgVVRGLThAVVRGLTguDQo+ IA0KPiANCj4+IGlmIHdlIHJlZ2FyZCBpdCBhcyB0aGUgIGludGVybmF0aW9uYWxpemVkIG1lc3Nh Z2UsIHdlIGNhbiBub3Qgc2VuZCBpdA0KPj4gYWNjb3JkaW5nIHRvIHRoZSBydWxlIGFib3ZlIGRl ZmluZWQgaW4gcmZjNTMzNmJpcyBiZWNhdXNlIEFsaWNlJ3MgZW1haWwNCj4+IHNlcnZlciBkb2Vz IG5vdCBzdXBwb3J0ICBVVEY4U01UUGJpcyBTTVRQIGV4dGVuc2lvbiAuDQo+IA0KPiBUaGUgY3Vy cmVudCBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGRlZmluZSBob3cgdG8gaGFuZGxlIG1lc3NhZ2Vz IHRoYXQgYXJlIG5vdCANCj4gVVRGLTguICBUaGUgcHJldmlvdXMgdmVyc2lvbiB0cmllZCB0byBz cGVjaWZ5IHRoYXQgaHlicmlkIGJ1dCBpdCBkaWQgbm90IA0KPiBzdWNjZWVkLiAgVGhlIGN1cnJl bnQgc3BlY2lmaWNhdGlvbiBpcyB0cnlpbmcgdG8gY292ZXIgb25seSB0aGUgc2ltcGxlciwgY2xl YW5lciANCj4gY2FzZTogVVRGLThAVVRGLTguDQo+IA0KPiANCj4+IGlmIHdlIHJlZ2FyZCBpdCBh cyBub24taW50ZXJuYXRpb25hbGl6ZWQgbWVzc2FnZSwgdGhlIEVBSS1hd2FyZSBYWCBzeXN0ZW0N Cj4+IHNob3VsZCBrbm93IGl0IG9yIGF0IGxlYXN0IGtub3cgdGhhdCBpdCBpcyBub3QgaW50ZXJu YXRpb25hbGl6ZWQgbWVzc2FnZS4NCj4gDQo+IElmIGl0IGlzIG5vdCBhbiBpbnRlcm5hdGlvbmFs aXplZCBtZXNzYWdlLCB0aGVuIGl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIA0KPiBFQUkg d29ya2luZyBncm91cC4gIE9yLCBhdCBsZWFzdCwgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0 aGVzZSB0d28sIGNvcmUgDQo+IHNwZWNpZmljYXRpb25zLg0KPiANCj4gDQo+IGQvDQo+IC0tIA0K PiANCj4gICBEYXZlIENyb2NrZXINCj4gICBCcmFuZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmcNCj4g ICBiYml3Lm5ldA== From johnl@iecc.com Mon Apr 25 21:19:45 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3AFE06CE for ; Mon, 25 Apr 2011 21:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL0a2wGNWpIF for ; Mon, 25 Apr 2011 21:19:44 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1BE067C for ; Mon, 25 Apr 2011 21:19:44 -0700 (PDT) Received: (qmail 9242 invoked from network); 26 Apr 2011 04:19:43 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 26 Apr 2011 04:19:43 -0000 Date: 26 Apr 2011 04:19:21 -0000 Message-ID: <20110426041921.76375.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <503789039.15208@cnnic.cn> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:19:45 -0000 >so the conclusion is that EAI system blocks the communication between >abc@example.com or abc@a-label in the pure EAI system and >abc@example2.com in rfc2821 system?? I wouldn't say it blocks it, although I would say that it doesn't enable it. This group spent a very long time trying to figure out ways to provide downgrades for EAI messages, and gave up. I don't think there is much support for reopening that discussion. R's, John From yaojk@cnnic.cn Mon Apr 25 22:36:28 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEB4E067C for ; Mon, 25 Apr 2011 22:36:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.394 X-Spam-Level: X-Spam-Status: No, score=-99.394 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMJVG+SK2DBN for ; Mon, 25 Apr 2011 22:36:27 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 52FBBE06ED for ; Mon, 25 Apr 2011 22:36:27 -0700 (PDT) Received: (eyou send program); Tue, 26 Apr 2011 13:36:27 +0800 Message-ID: <503796187.10439@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, 26 Apr 2011 13:36:27 +0800 Message-ID: <18B22D4A07AE41D28B134C6559D09CEB@LENOVO47E041CF> From: "Jiankang YAO" To: "John Levine" , References: <503791589.01356@cnnic.cn> Date: Tue, 26 Apr 2011 13:36:26 +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.6090 Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:36:28 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gTGV2aW5lIiA8am9o bmxAdGF1Z2guY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpDYzogPHlhb2prQGNubmljLmNuPg0K U2VudDogVHVlc2RheSwgQXByaWwgMjYsIDIwMTEgMTI6MTkgUE0NClN1YmplY3Q6IFJlOiBbRUFJ XSBUaGUgc2NlbmFyaW8gZmF2b3JpbmcgInVNYWlsYm94Ij8NCg0KDQo+ID5zbyB0aGUgY29uY2x1 c2lvbiBpcyB0aGF0IEVBSSBzeXN0ZW0gYmxvY2tzIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4N Cj4+YWJjQGV4YW1wbGUuY29tIG9yIGFiY0BhLWxhYmVsIGluIHRoZSBwdXJlIEVBSSBzeXN0ZW0g YW5kDQo+PmFiY0BleGFtcGxlMi5jb20gaW4gcmZjMjgyMSBzeXN0ZW0/Pw0KPiANCj4gSSB3b3Vs ZG4ndCBzYXkgaXQgYmxvY2tzIGl0LCBhbHRob3VnaCBJIHdvdWxkIHNheSB0aGF0IGl0IGRvZXNu J3QNCj4gZW5hYmxlIGl0Lg0KPiBUaGlzIGdyb3VwIHNwZW50IGEgdmVyeSBsb25nIHRpbWUgdHJ5 aW5nIHRvIGZpZ3VyZSBvdXQgd2F5cyB0byBwcm92aWRlDQo+IGRvd25ncmFkZXMgZm9yIEVBSSBt ZXNzYWdlcywgYW5kIGdhdmUgdXAuICBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIG11Y2gNCj4gc3Vw cG9ydCBmb3IgcmVvcGVuaW5nIHRoYXQgZGlzY3Vzc2lvbi4NCj4gDQoNCkZvciBjbGFyaWZpY2F0 aW9uLCBJIGFtIG5vdCB0cnlpbmcgdG8gcmVvcGVuIHRoZSBkb3duZ3JhZGUgZGlzY3Vzc2lvbi4N Cg0Kd2UgYXJlIGFyZ3Vpbmcgb3IgZGlzY3Vzc2luZyB3aGV0aGVyIHVNYWlsYm94IG9yIE1haWxi b3ggc2hvdWxkIGJlIHVzZWQgZm9yIEFCTkYgc3ludGF4Lg0KDQpJIHRoaW5rIHRoYXQgdGhlIGNv cmUgaXNzdWUgbGVmdCBmb3IgdGhlIGNvcmUgcmZjcyBpcyBBQk5GIHN5bnRheC4NCg0KSSBob3Bl IHRoYXQgd2UgY2FuIGhhdmUgYSBjbGVhciBjb25jbHVzaW9uIG9yIHNvbHV0aW9uIGZvciBBQk5G IHN5bnRheCBzb29uLg0KDQpKaWFua2FuZyBZYW8gDQoNCg0KPiBSJ3MsDQo+IEpvaG4= From Claudio.Allocchio@garr.it Mon Apr 25 23:36:25 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C358E06F5 for ; Mon, 25 Apr 2011 23:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9221T4xmC-J for ; Mon, 25 Apr 2011 23:36:24 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id CDD68E06FA for ; Mon, 25 Apr 2011 23:36:23 -0700 (PDT) Received: from webcam1-all.garrtest.units.it (webcam1-all.garrtest.units.it [140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p3Q6Zx0K072603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 08:36:01 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p3Q6Zx0K072603 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=FZYhqmAWZ2/p97AvgnuqPhcmPsoSEkKcUunzLd083mf18PCoMwftrzsnTubS32aZl zEXydZqCl7Z8Rk8mY3RtgPXoxiE1vxW7vCPh2VQ0yEV6xch+khIz/EhjSIOLhlrkMeh igv5WMKIBdpPkJJ0ajow+nHkPatJ+kyFuggl11s= Date: Tue, 26 Apr 2011 08:35:59 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio5.local To: dcrocker@bbiw.net In-Reply-To: <4DB63009.8060602@dcrocker.net> Message-ID: References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <4DB63009.8060602@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 06:36:25 -0000 > It is natural to want to be friendly to the implementer. > > However no, a specification usually must not try to anticipate implementation > work that goes beyond the primary goal of the specification. The job of the > specification is to define only what it is supposed to cover. In this case, > the current goal of the specification is to support UTF-8. > > The fact that someone might make implementation decisions that go beyond what > is > covered does not mean that the scope of the specification should be changed. > This is an example of the very basic difference between a protocol > specification > and an implementation specification. If we go back the message exchanges we had in January/February, you will alo see that we somehow suggested to add an informational "implementers' guide" document, where we can both give correct suggestions, and also add a number of useful examples to clarify this and other possible different interpretations. I storngly still think this is the way to go, and let the model clean and separate between the ascii-only and utf8-only areas, and add in between a "gateway" (or call it as you prefer!) specification. > Hence, no, the current specification does not have the goal of supporting > ASCII@ASCII. It's goal is to transmit data that are full 8-bits. The fact > that some of that data might also qualify as ASCII is proving to be a > distraction. That's why it is especially important to have everything put > only in terms of UTF-8. exactly. > Yes, but the specification does not provide for downgrade. That's the job of > separate specifications that cover such gateway translation behavior, but it > is not the job of these core specifications. yes... call it "downgrading" :== gateway :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From klensin@jck.com Tue Apr 26 00:03:07 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EC8E06FB for ; Tue, 26 Apr 2011 00:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewnHCeith0Ml for ; Tue, 26 Apr 2011 00:03:06 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F6E06EA for ; Tue, 26 Apr 2011 00:03:05 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QEcIO-000J0N-8z; Tue, 26 Apr 2011 03:02:52 -0400 Date: Tue, 26 Apr 2011 03:02:50 -0400 From: John C Klensin To: dcrocker@bbiw.net, Jiankang YAO Message-ID: <6829C8D8504A20EFEA36CFA0@PST.JCK.COM> In-Reply-To: <4DB63009.8060602@dcrocker.net> References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <4DB63009.8060602@dcrocker.net> 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] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:03:07 -0000 Dave, I don't think there is "gateway" behavior involved here. Let me try a different version of the problem Jiankang is describing in the hope of clarifying what he is asking about. I apologize for the length of this explanation, but I think we are having both terminology confusion and substantive confusion (and possibly disagreement). I want to be very clear and precise in the hope of isolating those issues so we can discuss them. So... --On Monday, April 25, 2011 19:38 -0700 Dave CROCKER wrote: > > > On 4/25/2011 6:48 PM, Jiankang YAO wrote: >> I am not trying to define a hybrid ASCII + UTF-8 system. but >> I think that the implementor will be likely to choose to >> recognize both rfc5321 address and UTF-8 address. If they >> choose to recognize both addresses, we should give them more >> convenient way to do it. > > It is natural to want to be friendly to the implementer. > > However no, a specification usually must not try to anticipate > implementation work that goes beyond the primary goal of the > specification. The job of the specification is to define only > what it is supposed to cover. In this case, the current goal > of the specification is to support UTF-8. >... For clarity, let me avoid terms like ASCII@ASCII, ASCII@A-label, and ASCII@UTF-8 and say instead "strictly 5321/5322 conforming" (of which the first two cases are members) and "EAI-requiring" (of which the third is an example). Note that "EAI-requiring" is different from "EAI-conformant". The latter requires support for all three of those cases (as well as cases involving local-parts that are not strictly ASCII-conformant). If I correctly understand your notes on the subject, is the only environment you consider interesting in the context of EAI work. "EAI-requiring" is a property of particular messages and/or their transmission. It is not a property of systems. EAI-conformant is a property of systems that fully support the EAI specifications. It is also worth noting that any EAI-conformant system that is going to interact with the DNS MUST be IDNA2008-conformant in its handling of labels (again, that interact with the DNS). Now, JianKang's Alice, who is using a strictly 5321/5322 system, sends a message to Bob using strictly 5321/5322 addresses and message headers. Those addresses might well include domains that contain some A-labels. That case is uninteresting from an EAI standpoint because there is nothing else that Alice can send Bob. Neither 5321/5322 nor IDNA2008 prevent Alice from sending domains containing A-labels since, as far as 5321/5322 are concerned, A-labels are conformant to the domain-part (letter-digit-hyphen) definitions in those specs and a strictly 5321/5322 conformant implementation has no need (or mechanism) for distinguishing between (in IDNA2008 terminology) A-labels and LDH-labels. However, assume that the primary domain name for Bob's address is an internationalized one, i.e., it contains some of the special label formats specified in IDNA2008 as either U-labels or A-labels. While Bob's system is EAI-conformant, there is nothing about the message or its transmission that makes it EAI-requiring. So the message is delivered. Bob (or, more precisely, Bob's MUA) now has it, on his EAI-conformant system. Bob might now decide to reply to Alice. He might instead decide to generate an entirely new message to her. Given how little 5322 says about replies, the on-the-wire difference between the two cases is fairly insignificant. Since either is a new message generated at MUA level (the "reply" case just has some additional decorative header fields or header field content for MUA-level threading purposes) and nothing is happening in transit, there are no gateway or downgrade issues involved. Now Bob's MUA and MSA, which are EAI-conformant, MUST be able to originate an EAI-requiring message. They are also required by the current specs and if possible to recognize A-labels and to _not_ send them. Put differently, an EAI-conformant system sending to an EAI-conformant system is required to send domain parts in addresses (either forward-pointing or backward-pointing) consisting entirely of U-labels or LDH-labels; they are strongly discouraged from passing A-labels around. So, ignoring relays for clarity, Bob's MSA opens an ESMTP session to Alice's delivery MTA. That delivery MTA does not advertise the UTF8SMTPbis capability (however the announcement is spelled), so Bob's systems MUST NOT send an envelope or a message whose headers contain backward-pointing addresses whose domain parts contain U-labels (i.e., MUST NOT attempt to send a message that is EAI-requiring for that reason (or any other reason, but let's stick to my version of Jiankang's example). But because, in that example, the only thing that can make a message from Bob to Alice EAI-requiring is the domain part, Bob's systems can behave like they are strictly 5321/5322 conforming in dealing with Alice. 5321 requires that, if an extension capability is not advertised by the SMTP-server, the SMTP-client MUST NOT use it, i.e., MUST exhibit strict 5321/5322 conforming behavior with regard to that feature. And IDNA2008 requires that systems that conform to it MUST be able to recognize A-labels and U-labels and convert between them as required by context. Now, if I understand it correctly, Jiankang's problem is that he would like to make clear that Bob can (is capable of), and MAY, send Alice a strictly 5321/5322 conformant message, using only 5321/5322 conformant facilities, if Alice's systems cannot handle EAI-requiring messages. Because the WG told him to include a requirement that U-labels be used in internationalized domain parts when possible, it is perfectly reasonable for him to say what should occur when it is not possible (indeed, many people have argued for making a statement of conditions and/or alternatives a near-requirement when SHOULD is stated in a conformance requirement). He would like to use ABNF that facilitates making that statement. I am less sure than he seems to be that one ABNF model blocks him from doing so while the other permits it. But it seems to me that taking a position of "if one is EAI-conformant, it is all UTF-8 and nothing else is an EAI concern" (whether or not that is, in fact, the position you are taking) ignores the IDNA2008 requirement that one be able to convert from U-label to A-label form when communicating with applications or implementations that are known to be non-IDNA-aware. Finally, > The fact that someone might make implementation decisions that > go beyond what is > covered does not mean that the scope of the specification > should be changed. > This is an example of the very basic difference between a > protocol specification > and an implementation specification. If he had asked about converting local-parts, I think the above would be completely appropriate guidance given the WG's choices about "downgrading". However, because being EAI-conformant requires that an implementation be IDNA-aware and IDNA-conformant, it does not appear to me to be strictly applicable to cases involving only the domain-part and statements like "has nothing to do with the EAI Working Group" are not strictly correct. Jiankang, if the above is not consistent with your concern, or misses part of it, please explain. regards, john From yaojk@cnnic.cn Tue Apr 26 00:45:37 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8FE0701 for ; Tue, 26 Apr 2011 00:45:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -100.414 X-Spam-Level: X-Spam-Status: No, score=-100.414 tagged_above=-999 required=5 tests=[AWL=1.629, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lquwkaJY9uZq for ; Tue, 26 Apr 2011 00:45:37 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 52215E06A5 for ; Tue, 26 Apr 2011 00:45:36 -0700 (PDT) Received: (eyou send program); Tue, 26 Apr 2011 15:45:36 +0800 Message-ID: <503803936.32149@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, 26 Apr 2011 15:45:36 +0800 Message-ID: <5F67A0DF86D449AE85EF35D6866BA4EE@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <4DB63009.8060602@dcrocker.net> <503801385.19306@cnnic.cn> Date: Tue, 26 Apr 2011 15:45:34 +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.6090 Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:45:37 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86IDxkY3JvY2tlckBiYml3Lm5ldD47ICJKaWFua2FuZyBZQU8i IDx5YW9qa0Bjbm5pYy5jbj4NCkNjOiA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgQXBy aWwgMjYsIDIwMTEgMzowMiBQTQ0KU3ViamVjdDogUmU6IFtFQUldIFRoZSBzY2VuYXJpbyBmYXZv cmluZyAidU1haWxib3giPw0KDQoNCj4gRGF2ZSwNCj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhlcmUg aXMgImdhdGV3YXkiIGJlaGF2aW9yIGludm9sdmVkIGhlcmUuICBMZXQgbWUNCj4gdHJ5IGEgZGlm ZmVyZW50IHZlcnNpb24gb2YgdGhlIHByb2JsZW0gSmlhbmthbmcgaXMgZGVzY3JpYmluZyBpbg0K PiB0aGUgaG9wZSBvZiBjbGFyaWZ5aW5nIHdoYXQgaGUgaXMgYXNraW5nIGFib3V0LiAgIEkgYXBv bG9naXplDQo+IGZvciB0aGUgbGVuZ3RoIG9mIHRoaXMgZXhwbGFuYXRpb24sIGJ1dCBJIHRoaW5r IHdlIGFyZSBoYXZpbmcNCj4gYm90aCB0ZXJtaW5vbG9neSBjb25mdXNpb24gYW5kIHN1YnN0YW50 aXZlIGNvbmZ1c2lvbiAoYW5kDQo+IHBvc3NpYmx5IGRpc2FncmVlbWVudCkuICBJIHdhbnQgdG8g YmUgdmVyeSBjbGVhciBhbmQgcHJlY2lzZSBpbg0KPiB0aGUgaG9wZSBvZiBpc29sYXRpbmcgdGhv c2UgaXNzdWVzIHNvIHdlIGNhbiBkaXNjdXNzIHRoZW0uDQo+IA0KPiBTby4uLg0KPiANCj4gLS1P biBNb25kYXksIEFwcmlsIDI1LCAyMDExIDE5OjM4IC0wNzAwIERhdmUgQ1JPQ0tFUg0KPiA8ZGhj MkBkY3JvY2tlci5uZXQ+IHdyb3RlOg0KPiANCj4+IA0KPj4gDQo+PiBPbiA0LzI1LzIwMTEgNjo0 OCBQTSwgSmlhbmthbmcgWUFPIHdyb3RlOg0KPj4+IEkgYW0gbm90IHRyeWluZyB0byBkZWZpbmUg YSBoeWJyaWQgQVNDSUkgKyBVVEYtOCBzeXN0ZW0uIGJ1dA0KPj4+IEkgdGhpbmsgdGhhdCB0aGUg aW1wbGVtZW50b3Igd2lsbCBiZSBsaWtlbHkgdG8gY2hvb3NlIHRvDQo+Pj4gcmVjb2duaXplIGJv dGggcmZjNTMyMSBhZGRyZXNzIGFuZCBVVEYtOCBhZGRyZXNzLiBJZiB0aGV5DQo+Pj4gY2hvb3Nl IHRvIHJlY29nbml6ZSBib3RoIGFkZHJlc3Nlcywgd2Ugc2hvdWxkIGdpdmUgdGhlbSBtb3JlDQo+ Pj4gY29udmVuaWVudCB3YXkgdG8gZG8gaXQuDQo+PiANCj4+IEl0IGlzIG5hdHVyYWwgdG8gd2Fu dCB0byBiZSBmcmllbmRseSB0byB0aGUgaW1wbGVtZW50ZXIuDQo+PiANCj4+IEhvd2V2ZXIgbm8s IGEgc3BlY2lmaWNhdGlvbiB1c3VhbGx5IG11c3Qgbm90IHRyeSB0byBhbnRpY2lwYXRlDQo+PiBp bXBsZW1lbnRhdGlvbiB3b3JrIHRoYXQgZ29lcyBiZXlvbmQgdGhlIHByaW1hcnkgZ29hbCBvZiB0 aGUNCj4+IHNwZWNpZmljYXRpb24uICBUaGUgam9iIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHRv IGRlZmluZSBvbmx5DQo+PiB3aGF0IGl0IGlzIHN1cHBvc2VkIHRvIGNvdmVyLiAgSW4gdGhpcyBj YXNlLCB0aGUgY3VycmVudCBnb2FsDQo+PiBvZiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0byBzdXBw b3J0IFVURi04Lg0KPj4uLi4NCj4gDQo+IEZvciBjbGFyaXR5LCBsZXQgbWUgYXZvaWQgdGVybXMg bGlrZSBBU0NJSUBBU0NJSSwgQVNDSUlAQS1sYWJlbCwNCj4gYW5kIEFTQ0lJQFVURi04IGFuZCBz YXkgaW5zdGVhZCAic3RyaWN0bHkgNTMyMS81MzIyIGNvbmZvcm1pbmciDQo+IChvZiB3aGljaCB0 aGUgZmlyc3QgdHdvIGNhc2VzIGFyZSBtZW1iZXJzKSBhbmQgIkVBSS1yZXF1aXJpbmciDQo+IChv ZiB3aGljaCB0aGUgdGhpcmQgaXMgYW4gZXhhbXBsZSkuICAgTm90ZSB0aGF0ICJFQUktcmVxdWly aW5nIg0KPiBpcyBkaWZmZXJlbnQgZnJvbSAiRUFJLWNvbmZvcm1hbnQiLiAgVGhlIGxhdHRlciBy ZXF1aXJlcyBzdXBwb3J0DQo+IGZvciBhbGwgdGhyZWUgb2YgdGhvc2UgY2FzZXMgKGFzIHdlbGwg YXMgY2FzZXMgaW52b2x2aW5nDQo+IGxvY2FsLXBhcnRzIHRoYXQgYXJlIG5vdCBzdHJpY3RseSBB U0NJSS1jb25mb3JtYW50KS4gIElmIEkNCj4gY29ycmVjdGx5IHVuZGVyc3RhbmQgeW91ciBub3Rl cyBvbiB0aGUgc3ViamVjdCwgaXMgdGhlIG9ubHkNCj4gZW52aXJvbm1lbnQgeW91IGNvbnNpZGVy IGludGVyZXN0aW5nIGluIHRoZSBjb250ZXh0IG9mIEVBSSB3b3JrLg0KPiAiRUFJLXJlcXVpcmlu ZyIgaXMgYSBwcm9wZXJ0eSBvZiBwYXJ0aWN1bGFyIG1lc3NhZ2VzIGFuZC9vcg0KPiB0aGVpciB0 cmFuc21pc3Npb24uICBJdCBpcyBub3QgYSBwcm9wZXJ0eSBvZiBzeXN0ZW1zLg0KPiBFQUktY29u Zm9ybWFudCBpcyBhIHByb3BlcnR5IG9mIHN5c3RlbXMgdGhhdCBmdWxseSBzdXBwb3J0IHRoZQ0K PiBFQUkgc3BlY2lmaWNhdGlvbnMuDQo+IA0KPiBJdCBpcyBhbHNvIHdvcnRoIG5vdGluZyB0aGF0 IGFueSBFQUktY29uZm9ybWFudCBzeXN0ZW0gdGhhdCBpcw0KPiBnb2luZyB0byBpbnRlcmFjdCB3 aXRoIHRoZSBETlMgTVVTVCBiZSBJRE5BMjAwOC1jb25mb3JtYW50IGluDQo+IGl0cyBoYW5kbGlu ZyBvZiBsYWJlbHMgKGFnYWluLCB0aGF0IGludGVyYWN0IHdpdGggdGhlIEROUykuDQo+IA0KPiBO b3csIEppYW5LYW5nJ3MgQWxpY2UsIHdobyBpcyB1c2luZyBhIHN0cmljdGx5IDUzMjEvNTMyMiBz eXN0ZW0sDQo+IHNlbmRzIGEgbWVzc2FnZSB0byBCb2IgdXNpbmcgc3RyaWN0bHkgNTMyMS81MzIy IGFkZHJlc3NlcyBhbmQNCj4gbWVzc2FnZSBoZWFkZXJzLiAgVGhvc2UgYWRkcmVzc2VzIG1pZ2h0 IHdlbGwgaW5jbHVkZSBkb21haW5zDQo+IHRoYXQgY29udGFpbiBzb21lIEEtbGFiZWxzLiAgIFRo YXQgY2FzZSBpcyB1bmludGVyZXN0aW5nIGZyb20gYW4NCj4gRUFJIHN0YW5kcG9pbnQgYmVjYXVz ZSB0aGVyZSBpcyBub3RoaW5nIGVsc2UgdGhhdCBBbGljZSBjYW4gc2VuZA0KPiBCb2IuICBOZWl0 aGVyIDUzMjEvNTMyMiBub3IgSUROQTIwMDggcHJldmVudCBBbGljZSBmcm9tIHNlbmRpbmcNCj4g ZG9tYWlucyBjb250YWluaW5nIEEtbGFiZWxzIHNpbmNlLCBhcyBmYXIgYXMgNTMyMS81MzIyIGFy ZQ0KPiBjb25jZXJuZWQsIEEtbGFiZWxzIGFyZSBjb25mb3JtYW50IHRvIHRoZSBkb21haW4tcGFy dA0KPiAobGV0dGVyLWRpZ2l0LWh5cGhlbikgZGVmaW5pdGlvbnMgaW4gdGhvc2Ugc3BlY3MgYW5k IGEgc3RyaWN0bHkNCj4gNTMyMS81MzIyIGNvbmZvcm1hbnQgaW1wbGVtZW50YXRpb24gaGFzIG5v IG5lZWQgKG9yIG1lY2hhbmlzbSkNCj4gZm9yIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gKGluIElE TkEyMDA4IHRlcm1pbm9sb2d5KSBBLWxhYmVscw0KPiBhbmQgTERILWxhYmVscy4NCj4gDQo+IEhv d2V2ZXIsIGFzc3VtZSB0aGF0IHRoZSBwcmltYXJ5IGRvbWFpbiBuYW1lIGZvciBCb2IncyBhZGRy ZXNzDQo+IGlzIGFuIGludGVybmF0aW9uYWxpemVkIG9uZSwgaS5lLiwgaXQgY29udGFpbnMgc29t ZSBvZiB0aGUNCj4gc3BlY2lhbCBsYWJlbCBmb3JtYXRzIHNwZWNpZmllZCBpbiBJRE5BMjAwOCBh cyBlaXRoZXIgVS1sYWJlbHMNCj4gb3IgQS1sYWJlbHMuICBXaGlsZSBCb2IncyBzeXN0ZW0gaXMg RUFJLWNvbmZvcm1hbnQsIHRoZXJlIGlzDQo+IG5vdGhpbmcgYWJvdXQgdGhlIG1lc3NhZ2Ugb3Ig aXRzIHRyYW5zbWlzc2lvbiB0aGF0IG1ha2VzIGl0DQo+IEVBSS1yZXF1aXJpbmcuDQo+IA0KPiBT byB0aGUgbWVzc2FnZSBpcyBkZWxpdmVyZWQuICBCb2IgKG9yLCBtb3JlIHByZWNpc2VseSwgQm9i J3MNCj4gTVVBKSBub3cgaGFzIGl0LCBvbiBoaXMgRUFJLWNvbmZvcm1hbnQgc3lzdGVtLiAgDQo+ IA0KPiBCb2IgbWlnaHQgbm93IGRlY2lkZSB0byByZXBseSB0byBBbGljZS4gIEhlIG1pZ2h0IGlu c3RlYWQgZGVjaWRlDQo+IHRvIGdlbmVyYXRlIGFuIGVudGlyZWx5IG5ldyBtZXNzYWdlIHRvIGhl ci4gIEdpdmVuIGhvdyBsaXR0bGUNCj4gNTMyMiBzYXlzIGFib3V0IHJlcGxpZXMsIHRoZSBvbi10 aGUtd2lyZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQo+IHR3byBjYXNlcyBpcyBmYWlybHkgaW5z aWduaWZpY2FudC4gIFNpbmNlIGVpdGhlciBpcyBhIG5ldw0KPiBtZXNzYWdlIGdlbmVyYXRlZCBh dCBNVUEgbGV2ZWwgKHRoZSAicmVwbHkiIGNhc2UganVzdCBoYXMgc29tZQ0KPiBhZGRpdGlvbmFs IGRlY29yYXRpdmUgaGVhZGVyIGZpZWxkcyBvciBoZWFkZXIgZmllbGQgY29udGVudCBmb3INCj4g TVVBLWxldmVsIHRocmVhZGluZyBwdXJwb3NlcykgYW5kIG5vdGhpbmcgaXMgaGFwcGVuaW5nIGlu DQo+IHRyYW5zaXQsIHRoZXJlIGFyZSBubyBnYXRld2F5IG9yIGRvd25ncmFkZSBpc3N1ZXMgaW52 b2x2ZWQuDQo+IA0KPiBOb3cgQm9iJ3MgTVVBIGFuZCBNU0EsIHdoaWNoIGFyZSBFQUktY29uZm9y bWFudCwgTVVTVCBiZSBhYmxlIHRvDQo+IG9yaWdpbmF0ZSBhbiBFQUktcmVxdWlyaW5nIG1lc3Nh Z2UuICBUaGV5IGFyZSBhbHNvIHJlcXVpcmVkIGJ5DQo+IHRoZSBjdXJyZW50IHNwZWNzIGFuZCBp ZiBwb3NzaWJsZSB0byByZWNvZ25pemUgQS1sYWJlbHMgYW5kIHRvDQo+IF9ub3RfIHNlbmQgdGhl bS4gIFB1dCBkaWZmZXJlbnRseSwgYW4gRUFJLWNvbmZvcm1hbnQgc3lzdGVtDQo+IHNlbmRpbmcg dG8gYW4gRUFJLWNvbmZvcm1hbnQgc3lzdGVtIGlzIHJlcXVpcmVkIHRvIHNlbmQgZG9tYWluDQo+ IHBhcnRzIGluIGFkZHJlc3NlcyAoZWl0aGVyIGZvcndhcmQtcG9pbnRpbmcgb3INCj4gYmFja3dh cmQtcG9pbnRpbmcpIGNvbnNpc3RpbmcgZW50aXJlbHkgb2YgVS1sYWJlbHMgb3INCj4gTERILWxh YmVsczsgdGhleSBhcmUgc3Ryb25nbHkgZGlzY291cmFnZWQgZnJvbSBwYXNzaW5nIEEtbGFiZWxz DQo+IGFyb3VuZC4NCj4gDQo+IFNvLCBpZ25vcmluZyByZWxheXMgZm9yIGNsYXJpdHksIEJvYidz IE1TQSBvcGVucyBhbiBFU01UUA0KPiBzZXNzaW9uIHRvIEFsaWNlJ3MgZGVsaXZlcnkgTVRBLiAg VGhhdCBkZWxpdmVyeSBNVEEgZG9lcyBub3QNCj4gYWR2ZXJ0aXNlIHRoZSBVVEY4U01UUGJpcyBj YXBhYmlsaXR5IChob3dldmVyIHRoZSBhbm5vdW5jZW1lbnQNCj4gaXMgc3BlbGxlZCksIHNvIEJv YidzIHN5c3RlbXMgTVVTVCBOT1Qgc2VuZCBhbiBlbnZlbG9wZSBvciBhDQo+IG1lc3NhZ2Ugd2hv c2UgaGVhZGVycyBjb250YWluIGJhY2t3YXJkLXBvaW50aW5nIGFkZHJlc3NlcyB3aG9zZQ0KPiBk b21haW4gcGFydHMgY29udGFpbiBVLWxhYmVscyAoaS5lLiwgTVVTVCBOT1QgYXR0ZW1wdCB0byBz ZW5kIGENCj4gbWVzc2FnZSB0aGF0IGlzIEVBSS1yZXF1aXJpbmcgZm9yIHRoYXQgcmVhc29uIChv ciBhbnkgb3RoZXINCj4gcmVhc29uLCBidXQgbGV0J3Mgc3RpY2sgdG8gbXkgdmVyc2lvbiBvZiBK aWFua2FuZydzIGV4YW1wbGUpLg0KPiANCj4gQnV0IGJlY2F1c2UsIGluIHRoYXQgZXhhbXBsZSwg dGhlIG9ubHkgdGhpbmcgdGhhdCBjYW4gbWFrZSBhDQo+IG1lc3NhZ2UgZnJvbSBCb2IgdG8gQWxp Y2UgRUFJLXJlcXVpcmluZyBpcyB0aGUgZG9tYWluIHBhcnQsDQo+IEJvYidzIHN5c3RlbXMgY2Fu IGJlaGF2ZSBsaWtlIHRoZXkgYXJlIHN0cmljdGx5IDUzMjEvNTMyMg0KPiBjb25mb3JtaW5nIGlu IGRlYWxpbmcgd2l0aCBBbGljZS4gIDUzMjEgcmVxdWlyZXMgdGhhdCwgaWYgYW4NCj4gZXh0ZW5z aW9uIGNhcGFiaWxpdHkgaXMgbm90IGFkdmVydGlzZWQgYnkgdGhlIFNNVFAtc2VydmVyLCB0aGUN Cj4gU01UUC1jbGllbnQgTVVTVCBOT1QgdXNlIGl0LCBpLmUuLCBNVVNUIGV4aGliaXQgc3RyaWN0 IDUzMjEvNTMyMg0KPiBjb25mb3JtaW5nIGJlaGF2aW9yIHdpdGggcmVnYXJkIHRvIHRoYXQgZmVh dHVyZS4gIEFuZCBJRE5BMjAwOA0KPiByZXF1aXJlcyB0aGF0IHN5c3RlbXMgdGhhdCBjb25mb3Jt IHRvIGl0IE1VU1QgYmUgYWJsZSB0bw0KPiByZWNvZ25pemUgQS1sYWJlbHMgYW5kIFUtbGFiZWxz IGFuZCBjb252ZXJ0IGJldHdlZW4gdGhlbSBhcw0KPiByZXF1aXJlZCBieSBjb250ZXh0Lg0KPiAN Cj4gTm93LCBpZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCBKaWFua2FuZydzIHByb2JsZW0g aXMgdGhhdCBoZQ0KPiB3b3VsZCBsaWtlIHRvIG1ha2UgY2xlYXIgdGhhdCBCb2IgY2FuIChpcyBj YXBhYmxlIG9mKSwgYW5kIE1BWSwNCj4gc2VuZCBBbGljZSBhIHN0cmljdGx5IDUzMjEvNTMyMiBj b25mb3JtYW50IG1lc3NhZ2UsIHVzaW5nIG9ubHkNCj4gNTMyMS81MzIyIGNvbmZvcm1hbnQgZmFj aWxpdGllcywgaWYgQWxpY2UncyBzeXN0ZW1zIGNhbm5vdA0KPiBoYW5kbGUgRUFJLXJlcXVpcmlu ZyBtZXNzYWdlcy4gIEJlY2F1c2UgdGhlIFdHIHRvbGQgaGltIHRvDQo+IGluY2x1ZGUgYSByZXF1 aXJlbWVudCB0aGF0IFUtbGFiZWxzIGJlIHVzZWQgaW4gaW50ZXJuYXRpb25hbGl6ZWQNCj4gZG9t YWluIHBhcnRzIHdoZW4gcG9zc2libGUsIGl0IGlzIHBlcmZlY3RseSByZWFzb25hYmxlIGZvciBo aW0NCj4gdG8gc2F5IHdoYXQgc2hvdWxkIG9jY3VyIHdoZW4gaXQgaXMgbm90IHBvc3NpYmxlIChp bmRlZWQsIG1hbnkNCj4gcGVvcGxlIGhhdmUgYXJndWVkIGZvciBtYWtpbmcgYSBzdGF0ZW1lbnQg b2YgY29uZGl0aW9ucyBhbmQvb3INCj4gYWx0ZXJuYXRpdmVzIGEgbmVhci1yZXF1aXJlbWVudCB3 aGVuIFNIT1VMRCBpcyBzdGF0ZWQgaW4gYQ0KPiBjb25mb3JtYW5jZSByZXF1aXJlbWVudCkuDQo+ IA0KPiBIZSB3b3VsZCBsaWtlIHRvIHVzZSBBQk5GIHRoYXQgZmFjaWxpdGF0ZXMgbWFraW5nIHRo YXQNCj4gc3RhdGVtZW50LiAgIEkgYW0gbGVzcyBzdXJlIHRoYW4gaGUgc2VlbXMgdG8gYmUgdGhh dCBvbmUgQUJORg0KPiBtb2RlbCBibG9ja3MgaGltIGZyb20gZG9pbmcgc28gd2hpbGUgdGhlIG90 aGVyIHBlcm1pdHMgaXQuIA0KPg0KDQp5ZXMsIEkgYW0gY29uY2VybiB0aGF0IG9uZSBBQk5GIG1v ZGVsIG1pZ2h0IGJsb2NrIGl0IGFuZCB0aGUgb3RoZXIgbWlnaHQgcGVybWl0IGl0Lg0KDQoNCj4g QnV0DQo+IGl0IHNlZW1zIHRvIG1lIHRoYXQgdGFraW5nIGEgcG9zaXRpb24gb2YgImlmIG9uZSBp cw0KPiBFQUktY29uZm9ybWFudCwgaXQgaXMgYWxsIFVURi04IGFuZCBub3RoaW5nIGVsc2UgaXMg YW4gRUFJDQo+IGNvbmNlcm4iICh3aGV0aGVyIG9yIG5vdCB0aGF0IGlzLCBpbiBmYWN0LCB0aGUg cG9zaXRpb24geW91IGFyZQ0KPiB0YWtpbmcpIGlnbm9yZXMgdGhlIElETkEyMDA4IHJlcXVpcmVt ZW50IHRoYXQgb25lIGJlIGFibGUgdG8NCj4gY29udmVydCBmcm9tIFUtbGFiZWwgdG8gQS1sYWJl bCBmb3JtIHdoZW4gY29tbXVuaWNhdGluZyB3aXRoDQo+IGFwcGxpY2F0aW9ucyBvciBpbXBsZW1l bnRhdGlvbnMgdGhhdCBhcmUga25vd24gdG8gYmUNCj4gbm9uLUlETkEtYXdhcmUuDQo+IA0KPiBG aW5hbGx5LCANCj4gDQo+PiBUaGUgZmFjdCB0aGF0IHNvbWVvbmUgbWlnaHQgbWFrZSBpbXBsZW1l bnRhdGlvbiBkZWNpc2lvbnMgdGhhdA0KPj4gZ28gYmV5b25kIHdoYXQgaXMNCj4+IGNvdmVyZWQg ZG9lcyBub3QgbWVhbiB0aGF0IHRoZSBzY29wZSBvZiB0aGUgc3BlY2lmaWNhdGlvbg0KPj4gc2hv dWxkIGJlIGNoYW5nZWQuDQo+PiBUaGlzIGlzIGFuIGV4YW1wbGUgb2YgdGhlIHZlcnkgYmFzaWMg ZGlmZmVyZW5jZSBiZXR3ZWVuIGENCj4+IHByb3RvY29sIHNwZWNpZmljYXRpb24NCj4+IGFuZCBh biBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpY2F0aW9uLg0KPiANCj4gSWYgaGUgaGFkIGFza2VkIGFi b3V0IGNvbnZlcnRpbmcgbG9jYWwtcGFydHMsIEkgdGhpbmsgdGhlIGFib3ZlDQo+IHdvdWxkIGJl IGNvbXBsZXRlbHkgYXBwcm9wcmlhdGUgZ3VpZGFuY2UgZ2l2ZW4gdGhlIFdHJ3MgY2hvaWNlcw0K PiBhYm91dCAiZG93bmdyYWRpbmciLiAgSG93ZXZlciwgYmVjYXVzZSBiZWluZyBFQUktY29uZm9y bWFudA0KPiByZXF1aXJlcyB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGJlIElETkEtYXdhcmUgYW5k DQo+IElETkEtY29uZm9ybWFudCwgaXQgZG9lcyBub3QgYXBwZWFyIHRvIG1lIHRvIGJlIHN0cmlj dGx5DQo+IGFwcGxpY2FibGUgdG8gY2FzZXMgaW52b2x2aW5nIG9ubHkgdGhlIGRvbWFpbi1wYXJ0 IGFuZA0KPiBzdGF0ZW1lbnRzIGxpa2UgImhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIEVBSSBX b3JraW5nIEdyb3VwIg0KPiBhcmUgbm90IHN0cmljdGx5IGNvcnJlY3QuDQo+IA0KPiBKaWFua2Fu ZywgaWYgdGhlIGFib3ZlIGlzIG5vdCBjb25zaXN0ZW50IHdpdGggeW91ciBjb25jZXJuLCBvcg0K PiBtaXNzZXMgcGFydCBvZiBpdCwgcGxlYXNlIGV4cGxhaW4uDQo+IA0KDQpJdCBpcyBjb25zaXN0 ZW50IHdpdGggbXkgY29uY2Vybi4NCkkgYWdyZWUgYWxsIHRoZSBwb2ludHMgZGlzY3Vzc2VkIGlu IHRoaXMgbWVzc2FnZS4NClRoYW5rcyBhIGxvdCBmb3IgeW91ciBkZXRhaWxlZCBleHBsYW5hdGlv bi4gDQpKaWFua2FuZyBZYW8NCg0KPiByZWdhcmRzLA0KPiAgICBqb2huDQo+ From Shawn.Steele@microsoft.com Tue Apr 26 08:23:45 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE2CE07CD for ; Tue, 26 Apr 2011 08:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdgwfhXJ8LGR for ; Tue, 26 Apr 2011 08:23:44 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 96A4CE07BF for ; Tue, 26 Apr 2011 08:23:44 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 26 Apr 2011 08:23:44 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.129]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0289.008; Tue, 26 Apr 2011 08:23:43 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: The scenario favoring "uMailbox"? Thread-Index: AQHMBCRuMejXdW6Y+0W/NnpWP+IUQA== Date: Tue, 26 Apr 2011 15:23:43 +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.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:23:45 -0000 I think Dave's point is valid: > The basic problem with your approach is that you are still trying to defi= ne a > hybrid ASCII + UTF-8 system. However that is no longer the model, for th= e > current, core specifications. An ASCII@ASCII address *IS* an EAI address because it is also UTF8@UTF8 > rfc5336bis said > " > If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, > the EAI-aware SMTP client MUST NOT transmit an internationalized > email address and MUST NOT transmit a mail message containing > internationalized mail headers as described in [RFC5335bis] > " But that's OK. ASCII@ASCII is ALSO a legacy email address, so it may be tr= ansmitted as a legacy message. Eg: it won't be transmitted by EAI. The attempt to overspecify this protocol gets to smaller and smaller edge c= ases. If we just try to define EAI and let applications worry about what h= appens if they can't send EAI, then the document is much less confusing. > I am not trying to define a hybrid ASCII + UTF-8 system. > but I think that the implementor will be likely to choose to recognize bo= th rfc5321 address > and UTF-8 address. Probably. So we need to define EAI. rfc5321 is already clearly defined, a= nd the implementor probably already implements it. > If they choose to recognize both addresses, we should give them more conv= enient way to do it. Overspecificity isn't convenient. If they can look to the EAI docs and fig= ure out UTF-8 mail, great. They can also look to 5321 to figure out legacy= email, great. If we try to say how do this, then that, then it becomes le= ss convenient because they have to keep going back & forth and build test c= ases for the edge cases we think about, etc. It's easy for them to conform= to both. If we try to define exactly how they should do that, then the do= c takes longer to write and is harder to adopt. I'd go so far as to say that this language: > the EAI-aware SMTP client MUST NOT transmit an internationalized > email address and MUST NOT transmit a mail message containing > internationalized mail headers as described in [RFC5335bis] Is redundant and not necessary. RFC5321 clearly describes what's permitted= in RFC5321. That is clearly not permitted. There are many other RFCs tha= t an implementation will use (TCP/IP, DNS, IDNA, etc). We don't have to say= "Make sure you follow RFCs xxx, yyy, & zzz" when building your EAI app. > If it is not an internationalized message, then it has nothing to do with= the > EAI working group. Or, at least, it has nothing to do with these two, co= re > specifications. Very much agreed. If we really wanted to, a "how to build an app using bou= t EAI and 5321 best practices" doc could be written, but I dont' think it's= necessary. > it means that Alice with an abc@example2.com address from rfc5321 system > can send the message to BOB with an abc@example.com or abc@a-labeladdres= s > from the Pure EAI-aware system; > but BOB with the abc@example.com or abc@a-label address in the Pure > EAI-aware system can not reply it to Alice with the abc@example2.com sinc= e > Alice's system does not support UTF8SMTP extension. That kind of thing's OK. If you email (with either EAI or 5321) to +142570= 58814@SomeServiceProvider.com that turns your email into a fax and hand-del= ivers it to me, then I may not be able to easily reply. The apps and gatew= ays will have to figure that out. We can write a doc on "best practices" o= r "suggestions" or something, but that doesn't have to be part of the core = spec. - Shawn= From dhc2@dcrocker.net Tue Apr 26 08:50:09 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8FEE0782 for ; Tue, 26 Apr 2011 08:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLZKQjNajnVS for ; Tue, 26 Apr 2011 08:50:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5E6E0681 for ; Tue, 26 Apr 2011 08:50:08 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3QFo2Jb025287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Apr 2011 08:50:08 -0700 Message-ID: <4DB6E99E.2020908@dcrocker.net> Date: Tue, 26 Apr 2011 08:49:50 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 CC: ima@ietf.org References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn> In-Reply-To: <503796187.10439@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 26 Apr 2011 08:50:08 -0700 (PDT) Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:50:09 -0000 Folks, On 4/25/2011 10:36 PM, Jiankang YAO wrote: > I think that the core issue left for the core rfcs is ABNF syntax. > > I hope that we can have a clear conclusion or solution for ABNF syntax soon. I have looked over the ABNF in rfc5335bis and this message contains a proposal for a much simpler approach. The current rfc5335bis draft specifies extensive ABNF, including additions of "u" rules, in Sections: 3.3. Extended Mailbox Address Syntax 3.7.3. Trace Information 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter These sections have a large number of ABNF rules that add UTF-8 support selectively and in the "higher-level" rules, rather than the underlying, basic rules. To follow the different and simpler approach that the EAI working group has now approved for rfc5335bis, I propose adding UTF-8 support to underlying (basic) rules. Here are the only ABNF changes that appear to be needed. From rfc5335bis: UTF8-enhancement = UTF8-2 / UTF8-3 / UTF8-4 ; incorporate from rfc5335bis, Section 2.1 VCHAR =/ UTF8-non-ascii ; incorporate from rfc5335bis, Section 2.1 ctext =/ UTF8-enhancement ; incorporate from rfc5335bis, Section 2.1 atext =/ UTF8-enhancement ; incorporate from rfc5335bis, Section 2.1 qtext =/ UTF8-enhancement ; incorporate from rfc5335bis, Section 2.1 text =/ UTF8-enhancement ; note that this upgrades the body to UTF-8 ; incorporate from rfc5335bis, Section 2.1 {{ how to add IDN to this? }} domain = dot-atom / domain-literal / obs-domain ; incorporate from rfc5335bis, Section 2.1 Add: quoted-pairSMTP =/ %d92 UTF8-enhancement qtextSMTP =/ UTF8-enhancement All other ABNF rules in rfc5335bis would be removed. In terms of the effect of doing this, in rfc5335bis, here is an example: > 3.3. Extended Mailbox Address Syntax > > uMailbox = uLocal-part "@" ( uDomain / address-literal ) > ; Replace Mailbox in RFC 5321, Section 4.1.2 Use existing definition from RFC 5321, with the enhancement from above. This covers UTF-8 in Local-part. IDN handles UTF-8 in the Domain. (Note that the specific details for specifying this in rfc5335bis is not fully resolved; it needs to be resolved the same way for that specification and for this one.) Therefore uLocal-part and uDomain are not needed; none of their supporting rules are needed. Similar simplifications take place for the other higher-level construct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Tue Apr 26 10:05:54 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB784E07DF for ; Tue, 26 Apr 2011 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrUmlhOvBaPT for ; Tue, 26 Apr 2011 10:05:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EEBDEE07DA for ; Tue, 26 Apr 2011 10:05:53 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3QH5jrB027061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 10:05:51 -0700 Message-ID: <4DB6FB5D.605@dcrocker.net> Date: Tue, 26 Apr 2011 10:05:33 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang YAO References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <503785503.12770@cnnic.cn> <503789039.15208@cnnic.cn> In-Reply-To: <503789039.15208@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 26 Apr 2011 10:05:52 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:05:55 -0000 Jiankang, On 4/25/2011 8:37 PM, Jiankang YAO wrote: > For the example " Step 1: Alice with an ABC@example2.com address from > rfc5321 system send the message to BOB with an abc@example.com or > abc@a-label (ASCII@A-lable or ASCII@ASCII) address from the pure EAI-aware > syste. If I understand your example, all of the addresses in them use ASCII. They are not UTF-8. (A-label is ASCII and I believe it works in the existing email environment.) Therefore your example for Step 1 does not seem to require EAI enhancements. As a consequence, I do not understand the reference to "pure EAI-aware" for Step 1. What is the purpose of having that reference in Step 1? > Setp 2: BOB with an abc@example.com or abc@a-label (ASCII@A-lable or > ASCII@ASCII) address from the pure EAI-aware system try to reply the message > to Alice with an ASCII@ASCII address. " If abc@example.com or abc@a-label > (ASCII@A-lable or ASCII@ASCII) are in the UTF-8 form, the current EAI core > system allow it to be sent. The first sentence of Step 2 refers to addresses that only are ASCII. They do not need the EAI enhancement. The second sentence appears to refer to these same ASCII addresses, but has them encoded as UTF-8 rather than pure ASCII. If BOB has an email-system that is based on UTF-8, then yes, it is natural that the ASCII addresses will be encoded as UTF-8, rather than marked as ASCII. However when BOB's system is sending a message has only these types of ASCII addresses, BOB's system can choose to use EAI or not use EAI. That is, BOB's system can choose to "downgrade" the message to pure ASCII or to retain it as UTF-8 and use the EAI SMTP extension. > If abc@example.com or abc@a-label (ASCII@A-lable or ASCII@ASCII) are in the > ASCII form, the current EAI core system does not allow it to be sent or do > not care for it. Correct! However I believe that this choice is outside of the scope of the current core specifications. I further believe that that this issue is where the confusion in the working group discussion is occurring. If BOB's system does not record that the message it received from Alice came in through legacy RFC5321, then you are correct that BOB's system will not know that it can and should use legacy SMTP. If BOB's system sends all UTF-8 addresses as EAI, then it is likely that many transmission will fail. This is an example of an issue that makes it useful to distinguish UTF-8 that is not ASCII. It suggests that an implementation that supports EAI might wish to use legacy SMTP -- rather than EAI-enhanced SMTP -- when all of the addresses are pure ASCII. However, that's implementation guidance, not protocol specification. These need to be kept separate. > so the conclusion is that EAI system blocks the communication between > abc@example.com or abc@a-label in the pure EAI system and abc@example2.com > in rfc2821 system?? If an EAI-enabled system sends all mail only in UTF-8, it is certain that quite a bit of mail will not be delivered. This is especially true during the early stages of EAI adoption. In January, I circulated an architectural description of the current model being pursued by working group: EAI Technical Architecture ========================== +-----------+ +-----------+ | MUA-ASCII | | MUA-ASCII | +----+------+ +-----------+ | ^ v | +-----------+ +-----------+ +-----------+ +----+------+ | MSA-ASCII +--->| MTA-ASCII +--->| MTA-ASCII +--->| MDA-ASCII | +-----------+ ^ +-----------+ ^ +-----------+ ^ +-----------+ | | | | | | | | | +-----------+ V +-----------+ V +-----------+ V +-----------+ | MSA-UTF8 |--->| MTA-UTF8 |--->| MTA-UTF8 |--->| MDA-UTF8 +-----------+ +-----------+ +-----------+ +----+------+ ^ | | V +-----------+ +-----------+ | MUA-UTF8 | | MUA-UTF8 | +-----------+ +-----------+ This is a pure and simple model. However, you are correct that it produces a failure for sending from UTF-8 systems to ASCII systems. That is why the architecture does not show any arrows from UTF-8 to ASCII. Obviously, UTF-8 systems need to be able to send to ASCII systems. The question is how to support that? The working group originally tried to support this with a model that dealt with ASCII and UTF-8 simultaneously. It tried to do specifications that integrated support for pure-ASCII with support for UTF-8. However this was too complicated and the effort was changed to the simpler model that is now being specified. It is reasonable and it probably is necessary to have the working group deal with the scenario that you have described. In terms of the above architecture diagram, it means finding a way to have arrows that go from the UTF-8 environment to the ASCII environment. Certainly the current 'downgrade' specifications are part of that. However that needs to be /separate/ specification work. The attempt to add this to the core specifications re-creates the complexity and problems that the working group originally experienced. I believe the correct place to resolve your concern is with a document that discusses EAI implementation, not the core EAI protocol specification documents. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Tue Apr 26 15:31:27 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE314E07DA for ; Tue, 26 Apr 2011 15:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.37 X-Spam-Level: X-Spam-Status: No, score=-11.37 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFjhoYjCeDrb for ; Tue, 26 Apr 2011 15:31:27 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2E05CE076F for ; Tue, 26 Apr 2011 15:31:27 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 26 Apr 2011 15:31:26 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.129]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Tue, 26 Apr 2011 15:31:26 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: The scenario favoring "uMailbox"? Thread-Index: AcwEYIMO2p0h8ycDTvmGLgC3Eks5Iw== Date: Tue, 26 Apr 2011 22:31:25 +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.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 22:31:27 -0000 > Because the WG told him to > include a requirement that U-labels be used in internationalized > domain parts when possible, it is perfectly reasonable for him > to say what should occur when it is not possible=20 So an EAI conforming mail should use U-labels. Bob's email could do that, = but it won't get to Alice. So his system will quickly discover that it can= 't use EAI. His mail system is left with only the 5321/5322 option, which = is clear that U-labels cannot be sent.=20 I don't think that requires muddying the waters in EAI about ascii/utf-8 if= /and/else/then/but stuff. It's might be fair to note, perhaps in the introduction or an informational= note, that if a conforming EAI message cannot be sent, mail clients mail c= onsider using 5321/5322 if that service is available to them and they have = the information needed to use 5321/5322. I agree with Dave's simplified ABNF suggestion. EAI is all about UTF-8 mai= l. If it's not EAI mail, then it's some other protocol (like 5321/5322). If EAI fails, users have numerous ways to attempt communication: Send an I= M. Send a Fax. Find their corporate office on the web and complain to the= ir boss. Send a letter (snail mail). Pick up the phone and call them. 53= 21/5322 is just one of those alternates. Given that we're already in mail,= it seems particularly likely that 5321/5322 might be useful, but we aren't= going to create language around all the other mechanisms. Any catering to= 5321/5322 fallback (as opposed to downgrade) should be informational or so= mething. -Shawn From yaojk@cnnic.cn Tue Apr 26 17:51:22 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CA6E06B5 for ; Tue, 26 Apr 2011 17:51:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.647 X-Spam-Level: X-Spam-Status: No, score=-99.647 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF5Gi+K+Y9u3 for ; Tue, 26 Apr 2011 17:51:21 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3C20FE0680 for ; Tue, 26 Apr 2011 17:51:21 -0700 (PDT) Received: (eyou send program); Wed, 27 Apr 2011 08:51:20 +0800 Message-ID: <503865480.01228@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, 27 Apr 2011 08:51:20 +0800 Message-ID: From: "Jiankang YAO" To: References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn> <503833016.15024@cnnic.cn> Date: Wed, 27 Apr 2011 08:51:20 +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.6090 Cc: ima@ietf.org Subject: [EAI] (Dave's detail suggestion )Re: The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 00:51:22 -0000 dGhhbmtzIGEgbG90IGZvciBEYXZlJ3MgZGV0YWlsIEFCTkYgc3VnZ2VzdGlvbi4NCkhvcGUgdG8g c2VlIG1vcmUgY29tbWVudHMgdG8gaXQgZnJvbSB0aGUgV0cuDQoNCkppYW5rYW5nIFlhbw0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRoYzJA ZGNyb2NrZXIubmV0Pg0KQ2M6IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAy NiwgMjAxMSAxMTo0OSBQTQ0KU3ViamVjdDogUmU6IFtFQUldIFRoZSBzY2VuYXJpbyBmYXZvcmlu ZyAidU1haWxib3giPw0KDQoNCj4gRm9sa3MsDQo+IA0KPiANCj4gT24gNC8yNS8yMDExIDEwOjM2 IFBNLCBKaWFua2FuZyBZQU8gd3JvdGU6DQo+PiBJIHRoaW5rIHRoYXQgdGhlIGNvcmUgaXNzdWUg bGVmdCBmb3IgdGhlIGNvcmUgcmZjcyBpcyBBQk5GIHN5bnRheC4NCj4+DQo+PiBJIGhvcGUgdGhh dCB3ZSBjYW4gaGF2ZSBhIGNsZWFyIGNvbmNsdXNpb24gb3Igc29sdXRpb24gZm9yIEFCTkYgc3lu dGF4IHNvb24uDQo+IA0KPiBJIGhhdmUgbG9va2VkIG92ZXIgdGhlIEFCTkYgaW4gcmZjNTMzNWJp cyBhbmQgdGhpcyBtZXNzYWdlIGNvbnRhaW5zIGEgcHJvcG9zYWwgDQo+IGZvciBhIG11Y2ggc2lt cGxlciBhcHByb2FjaC4NCj4gDQo+IFRoZSBjdXJyZW50IHJmYzUzMzViaXMgZHJhZnQgc3BlY2lm aWVzIGV4dGVuc2l2ZSBBQk5GLCBpbmNsdWRpbmcgYWRkaXRpb25zIG9mIA0KPiAidSIgcnVsZXMs IGluIFNlY3Rpb25zOg0KPiANCj4gICAgMy4zLiAgRXh0ZW5kZWQgTWFpbGJveCBBZGRyZXNzIFN5 bnRheA0KPiANCj4gICAgMy43LjMuICBUcmFjZSBJbmZvcm1hdGlvbg0KPiANCj4gICAgMy43LjQu Mi4gIFZSRlkgYW5kIEVYUE4gQ29tbWFuZHMgYW5kIHRoZSBVVEY4U01UUGJpcyBQYXJhbWV0ZXIN Cj4gDQo+IFRoZXNlIHNlY3Rpb25zIGhhdmUgYSBsYXJnZSBudW1iZXIgb2YgQUJORiBydWxlcyB0 aGF0IGFkZCBVVEYtOCBzdXBwb3J0IA0KPiBzZWxlY3RpdmVseSBhbmQgaW4gdGhlICJoaWdoZXIt bGV2ZWwiIHJ1bGVzLCByYXRoZXIgdGhhbiB0aGUgdW5kZXJseWluZywgYmFzaWMgDQo+IHJ1bGVz Lg0KPiANCj4gVG8gZm9sbG93IHRoZSBkaWZmZXJlbnQgYW5kIHNpbXBsZXIgYXBwcm9hY2ggdGhh dCB0aGUgRUFJIHdvcmtpbmcgZ3JvdXAgaGFzIG5vdyANCj4gYXBwcm92ZWQgZm9yIHJmYzUzMzVi aXMsIEkgcHJvcG9zZSBhZGRpbmcgVVRGLTggc3VwcG9ydCB0byB1bmRlcmx5aW5nIChiYXNpYykg DQo+IHJ1bGVzLg0KPiANCj4gSGVyZSBhcmUgdGhlIG9ubHkgQUJORiBjaGFuZ2VzIHRoYXQgYXBw ZWFyIHRvIGJlIG5lZWRlZC4NCj4gDQo+IEZyb20gcmZjNTMzNWJpczoNCj4gDQo+ICAgIFVURjgt ZW5oYW5jZW1lbnQgID0gICBVVEY4LTIgLyBVVEY4LTMgLyBVVEY4LTQNCj4gICAgICAgICAgICAg ICAgICAgICAgICA7IGluY29ycG9yYXRlIGZyb20gcmZjNTMzNWJpcywgU2VjdGlvbiAyLjENCj4g DQo+ICAgIFZDSEFSICAgPS8gIFVURjgtbm9uLWFzY2lpDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgOyBpbmNvcnBvcmF0ZSBmcm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+IA0KPiAgICBj dGV4dCAgID0vICBVVEY4LWVuaGFuY2VtZW50DQo+ICAgICAgICAgICAgICAgICAgICAgICAgOyBp bmNvcnBvcmF0ZSBmcm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+IA0KPiAgICBhdGV4dCAg ID0vICBVVEY4LWVuaGFuY2VtZW50DQo+ICAgICAgICAgICAgICAgICAgICAgICAgOyBpbmNvcnBv cmF0ZSBmcm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+IA0KPiAgICBxdGV4dCAgID0vICBV VEY4LWVuaGFuY2VtZW50DQo+ICAgICAgICAgICAgICAgICAgICAgICAgOyBpbmNvcnBvcmF0ZSBm cm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+IA0KPiAgICB0ZXh0ICAgID0vICBVVEY4LWVu aGFuY2VtZW50DQo+ICAgICAgICAgICAgICAgICAgIDsgbm90ZSB0aGF0IHRoaXMgdXBncmFkZXMg dGhlIGJvZHkgdG8gVVRGLTgNCj4gICAgICAgICAgICAgICAgICAgICAgICA7IGluY29ycG9yYXRl IGZyb20gcmZjNTMzNWJpcywgU2VjdGlvbiAyLjENCj4gDQo+ICAgIHt7IGhvdyB0byBhZGQgSURO IHRvIHRoaXM/IH19DQo+ICAgIGRvbWFpbiAgPSAgIGRvdC1hdG9tIC8gZG9tYWluLWxpdGVyYWwg LyBvYnMtZG9tYWluDQo+ICAgICAgICAgICAgICAgICAgICAgICAgOyBpbmNvcnBvcmF0ZSBmcm9t IHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+IA0KPiBBZGQ6DQo+IA0KPiAgICBxdW90ZWQtcGFp clNNVFAgID0vICVkOTIgVVRGOC1lbmhhbmNlbWVudA0KPiANCj4gICAgcXRleHRTTVRQICAgICAg ICA9LyAgVVRGOC1lbmhhbmNlbWVudA0KPiANCj4gDQo+IA0KPiBBbGwgb3RoZXIgQUJORiBydWxl cyBpbiByZmM1MzM1YmlzIHdvdWxkIGJlIHJlbW92ZWQuDQo+IA0KPiANCj4gSW4gdGVybXMgb2Yg dGhlIGVmZmVjdCBvZiBkb2luZyB0aGlzLCBpbiByZmM1MzM1YmlzLCBoZXJlIGlzIGFuIGV4YW1w bGU6DQo+IA0KPiA+IDMuMy4gIEV4dGVuZGVkIE1haWxib3ggQWRkcmVzcyBTeW50YXgNCj4gPg0K PiA+ICAgIHVNYWlsYm94ID0gdUxvY2FsLXBhcnQgIkAiICggdURvbWFpbiAvIGFkZHJlc3MtbGl0 ZXJhbCApDQo+ID4gICAgIDsgUmVwbGFjZSBNYWlsYm94IGluIFJGQyA1MzIxLCBTZWN0aW9uIDQu MS4yDQo+IA0KPiBVc2UgZXhpc3RpbmcgPE1haWxib3g+IGRlZmluaXRpb24gZnJvbSBSRkMgNTMy MSwgd2l0aCB0aGUgPGF0ZXh0PiBlbmhhbmNlbWVudCANCj4gZnJvbSBhYm92ZS4gIFRoaXMgY292 ZXJzIFVURi04IGluIExvY2FsLXBhcnQuDQo+IA0KPiBJRE4gaGFuZGxlcyBVVEYtOCBpbiB0aGUg RG9tYWluLiAoTm90ZSB0aGF0IHRoZSBzcGVjaWZpYyBkZXRhaWxzIGZvciBzcGVjaWZ5aW5nIA0K PiB0aGlzIGluIHJmYzUzMzViaXMgaXMgbm90IGZ1bGx5IHJlc29sdmVkOyBpdCBuZWVkcyB0byBi ZSByZXNvbHZlZCB0aGUgc2FtZSB3YXkgDQo+IGZvciB0aGF0IHNwZWNpZmljYXRpb24gYW5kIGZv ciB0aGlzIG9uZS4pDQo+IA0KPiBUaGVyZWZvcmUgdUxvY2FsLXBhcnQgYW5kIHVEb21haW4gYXJl IG5vdCBuZWVkZWQ7IG5vbmUgb2YgdGhlaXIgc3VwcG9ydGluZyBydWxlcyANCj4gYXJlIG5lZWRl ZC4NCj4gDQo+IFNpbWlsYXIgc2ltcGxpZmljYXRpb25zIHRha2UgcGxhY2UgZm9yIHRoZSBvdGhl ciBoaWdoZXItbGV2ZWwgY29uc3RydWN0Lg0KPiANCj4gZC8NCj4gLS0gDQo+IA0KPiAgIERhdmUg Q3JvY2tlcg0KPiAgIEJyYW5kZW5idXJnIEludGVybmV0V29ya2luZw0KPiAgIGJiaXcubmV0DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBt YWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaW1h From yaojk@cnnic.cn Tue Apr 26 18:58:26 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DC9E0682 for ; Tue, 26 Apr 2011 18:58:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.396 X-Spam-Level: X-Spam-Status: No, score=-99.396 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5VO6sCNSJNo for ; Tue, 26 Apr 2011 18:58:25 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 0C91EE0680 for ; Tue, 26 Apr 2011 18:58:24 -0700 (PDT) Received: (eyou send program); Wed, 27 Apr 2011 09:58:20 +0800 Message-ID: <503869500.14165@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, 27 Apr 2011 09:58:20 +0800 Message-ID: <8014505CC98C4D88B309A072FCA32322@LENOVO47E041CF> From: "Jiankang YAO" To: References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <503785503.12770@cnnic.cn> <503789039.15208@cnnic.cn> <503837555.21823@cnnic.cn> Date: Wed, 27 Apr 2011 09:58:19 +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.6090 Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 01:58:26 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo YzJAZGNyb2NrZXIubmV0Pg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNj OiA8aW1hQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNywgMjAxMSAxOjA1IEFN DQpTdWJqZWN0OiBSZTogW0VBSV0gVGhlIHNjZW5hcmlvIGZhdm9yaW5nICJ1TWFpbGJveCI/DQoN Cg0KPiBKaWFua2FuZywNCj4gDQo+IA0KPiBPbiA0LzI1LzIwMTEgODozNyBQTSwgSmlhbmthbmcg WUFPIHdyb3RlOg0KPj4gRm9yIHRoZSBleGFtcGxlICIgU3RlcCAxOiBBbGljZSB3aXRoIGFuIEFC Q0BleGFtcGxlMi5jb20gIGFkZHJlc3MgZnJvbQ0KPj4gcmZjNTMyMSBzeXN0ZW0gc2VuZCB0aGUg bWVzc2FnZSB0byBCT0Igd2l0aCBhbiAgYWJjQGV4YW1wbGUuY29tIG9yDQo+PiBhYmNAYS1sYWJl bCAoQVNDSUlAQS1sYWJsZSBvciBBU0NJSUBBU0NJSSkgYWRkcmVzcyBmcm9tIHRoZSBwdXJlIEVB SS1hd2FyZQ0KPj4gc3lzdGUuDQo+IA0KPiBJZiBJIHVuZGVyc3RhbmQgeW91ciBleGFtcGxlLCBh bGwgb2YgdGhlIGFkZHJlc3NlcyBpbiB0aGVtIHVzZSBBU0NJSS4gIFRoZXkgYXJlIA0KPiBub3Qg VVRGLTguICAoQS1sYWJlbCBpcyBBU0NJSSBhbmQgSSBiZWxpZXZlIGl0IHdvcmtzIGluIHRoZSBl eGlzdGluZyBlbWFpbCANCj4gZW52aXJvbm1lbnQuKSAgVGhlcmVmb3JlIHlvdXIgZXhhbXBsZSBm b3IgU3RlcCAxIGRvZXMgbm90IHNlZW0gdG8gcmVxdWlyZSBFQUkgDQo+IGVuaGFuY2VtZW50cy4N Cj4gDQo+IEFzIGEgY29uc2VxdWVuY2UsIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHJlZmVyZW5j ZSB0byAicHVyZSBFQUktYXdhcmUiIGZvciBTdGVwIA0KPiAxLiAgV2hhdCBpcyB0aGUgcHVycG9z ZSBvZiBoYXZpbmcgdGhhdCByZWZlcmVuY2UgaW4gU3RlcCAxPw0KPiANCg0KQXMgeW91IGhhdmUg cG9pbnRlZCBpdCBvdXQsICBpZiBhYmNAZXhhbXBsZS5jb20gb3IgYWJjQGEtbGFiZWwgaXMgaW4g dGhlIHV0Zi04IGZvcm0sIHRoZSBFQUkgc3lzdGVtIHdpbGwgc3VwcG9ydCBpdDtpZiBhYmNAZXhh bXBsZS5jb20gb3IgYWJjQGEtbGFiZWwgaXMgbm90IGluIHRoZSB1dGYtOCBmb3JtLCB0aGUgRUFJ IHN5c3RlbSB3aWxsIG5vdCBzdXBwb3J0IGl0Ow0KDQpBbGljZSB3aXRoIGFuIEFCQ0BleGFtcGxl Mi5jb20gIGFkZHJlc3MgZnJvbSByZmM1MzIxIHN5c3RlbSBkb2VzIG5vdCBrbm93IEJPQidzIHN5 c3RlbSB3aXRoICAgYWJjQGV4YW1wbGUuY29tIG9yIGFiY0BhLWxhYmVsICBhZGRyZXNzLg0KDQpB bGljZSB3aWxsIGp1c3Qgc2VuZCB0aGUgbWVzc2FnZSB0byBCb2IuDQoNClRoZSBxdWVzdGlvbiBu b3cgYmVjb21lczoNCjEuIFRoZSBzeXN0ZW0gd2l0aCB0aGUgYWRkcmVzc2VzIHN1Y2ggYXMgIGFi Y0BleGFtcGxlLmNvbSBvciBhYmNAYS1sYWJlbCBpcyBFQUkgc3lzdGVtIG9yIHJmYzUzMjEgc3lz dGVtPw0KMi4gRG9lcyB0aGUgRUFJIHN5c3RlbSBzdXBwb3J0IHRoZSBhZGRyZXNzIHN1Y2ggYXMg YWJjQGV4YW1wbGUuY29tIHdpdGggdXRmLTggZm9ybT8NCjMuIElmIHRoZSAgYWJjQGV4YW1wbGUy LmNvbSB3aXRoIEFTQ0lJIGZvcm0gYmVsb25ncyB0byByZmMyODIxIHN5c3RlbSBhbmQgIHRoZSAg YWJjQGV4YW1wbGUuY29tIHdpdGggdXRmLTggZm9ybSBiZWxvbmdzIHRvIEVBSSBzeXN0ZW0sICB3 aWxsICBCT0IncyBFQUkgc3lzdGVtIHJlZnVzZSB0byBhY2NlcHQgdGhlIG1lc3NhZ2UgZnJvbSBB bGljZSdzIFJGQzUzMjEgc3lzdGVtIHdpdGggYWJjQGV4YW1wbGUyLmNvbSB0byBCT0IncyBzeXN0 ZW0gd2l0aCAgYWJjQGV4YW1wbGUuY29tIG9yIGFiY0BhLWxhYmVsPz8NCg0KSmlhbmthbmcgWWFv DQoNCj4gDQo+PiBTZXRwIDI6IEJPQiB3aXRoIGFuICBhYmNAZXhhbXBsZS5jb20gb3IgYWJjQGEt bGFiZWwgKEFTQ0lJQEEtbGFibGUgb3INCj4+IEFTQ0lJQEFTQ0lJKSBhZGRyZXNzIGZyb20gdGhl IHB1cmUgRUFJLWF3YXJlIHN5c3RlbSB0cnkgdG8gcmVwbHkgdGhlIG1lc3NhZ2UNCj4+IHRvIEFs aWNlIHdpdGggYW4gQVNDSUlAQVNDSUkgYWRkcmVzcy4gIiBJZiAgYWJjQGV4YW1wbGUuY29tIG9y IGFiY0BhLWxhYmVsDQo+PiAoQVNDSUlAQS1sYWJsZSBvciBBU0NJSUBBU0NJSSkgYXJlIGluIHRo ZSBVVEYtOCBmb3JtLCAgdGhlIGN1cnJlbnQgRUFJIGNvcmUNCj4+IHN5c3RlbSBhbGxvdyBpdCB0 byBiZSBzZW50Lg0KPiANCg== From dhc2@dcrocker.net Wed Apr 27 21:16:39 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92741E0680 for ; Wed, 27 Apr 2011 21:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUfwtzZh4c6C for ; Wed, 27 Apr 2011 21:16:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2035E0678 for ; Wed, 27 Apr 2011 21:16:38 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3S4GUCR019743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 21:16:35 -0700 Message-ID: <4DB8EA1E.9030708@dcrocker.net> Date: Wed, 27 Apr 2011 21:16:30 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang YAO References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <503785503.12770@cnnic.cn> <503789039.15208@cnnic.cn> <503837555.21823@cnnic.cn> <503869500.14165@cnnic.cn> In-Reply-To: <503869500.14165@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 27 Apr 2011 21:16:35 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 04:16:39 -0000 Jiankang, On 4/26/2011 6:58 PM, Jiankang YAO wrote: >> 1. What is the purpose of having that reference in Step 1? >> > > As you have pointed it out, if abc@example.com or abc@a-label is in the > utf-8 form, the EAI system will support it;if abc@example.com or abc@a-label > is not in the utf-8 form, the EAI system will not support it; I do not understand what this means. Anything that is in ASCII is also in UTF-8. If a string is "in UTF-8 form" on a system that supports UTF-8, then the string will be supported. So I think I do not know what you mean by "supported". > Alice with an ABC@example2.com address from rfc5321 system does not know > BOB's system with abc@example.com or abc@a-label address. > > Alice will just send the message to Bob. Again, apologies, but I do not understand why this example will fail. > The question now becomes: > > 1. The system with the addresses such as abc@example.com or abc@a-label is > EAI system or rfc5321 system? Both strings appear to be ASCII, so I do not understand why this matters? > 2. Does the EAI system support the address such as abc@example.com with utf-8 > form? Of course it does, since ASCII is a subset of UTF-8. (I do understand that I am missing your point; I'm trying to make clear what I think I am seeing, in the hope thatt you can figure out what part I am missing. Unfortunately it is clear that I am not able to figure that out myself.) > 3. If the abc@example2.com with ASCII form belongs to rfc2821 system and > the abc@example.com with utf-8 form belongs to EAI system, will BOB's EAI > system refuse to accept the message from Alice's RFC5321 system with > abc@example2.com to BOB's system with abc@example.com or abc@a-label?? I think you are asking: will a UTF-8 system accept mail from an ASCII system? (For reference, I suggest that the term "EAI" is not helpful here. Its precise meaning for this sort of discussion is not clear. On the other hand, referring to the encoding of the data is simple, direct and clear.) The answer is no, without a gateway, if both systems only do one form of data. In reality, we can expect a UTF-8 system also to support legacy RFC5321, but that is a pure "dual stack" model and the legacy behavior is outside the scope of the working group, since it is already covered by RFC5321/RFC5322. Again, the architectural model the working group has chosen to pursue is for dual stack: UTF-8 and ASCII are not handled together. If the path is UTF-8, it is /only/ UTF-8. d/ ps. I provided an architectural diagram because it often is helpful to show these types of issues as pictures that label the actors and the data they are exchanging. I do not know whether it will help for you to develop a picture for the above, but it might. -- Dave Crocker Brandenburg InternetWorking bbiw.net From yaojk@cnnic.cn Thu Apr 28 20:25:11 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFFAE0710 for ; Thu, 28 Apr 2011 20:25:11 -0700 (PDT) X-Quarantine-ID: <2ntF-iSpP+jV> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.701 X-Spam-Level: X-Spam-Status: No, score=-99.701 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ntF-iSpP+jV for ; Thu, 28 Apr 2011 20:25:11 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 54FA4E066F for ; Thu, 28 Apr 2011 20:25:09 -0700 (PDT) Received: (eyou send program); Fri, 29 Apr 2011 11:25:05 +0800 Message-ID: <504047505.31177@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, 29 Apr 2011 11:25:05 +0800 Message-ID: <63F3054E786F47289A3C8031E1054C6F@LENOVO47E041CF> From: "Jiankang YAO" To: References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <503785503.12770@cnnic.cn> <503789039.15208@cnnic.cn> <503837555.21823@cnnic.cn> <503869500.14165@cnnic.cn> <503964199.26727@cnnic.cn> Date: Fri, 29 Apr 2011 11:25:06 +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.6090 Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 03:25:11 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo YzJAZGNyb2NrZXIubmV0Pg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNj OiA8aW1hQGlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDI4LCAyMDExIDEyOjE2IFBN DQpTdWJqZWN0OiBSZTogW0VBSV0gVGhlIHNjZW5hcmlvIGZhdm9yaW5nICJ1TWFpbGJveCI/DQoN Cg0KPiBKaWFua2FuZywNCg0KPHNuaXBzPg0KDQo+IA0KPiANCj4+IDMuIElmIHRoZSAgYWJjQGV4 YW1wbGUyLmNvbSB3aXRoIEFTQ0lJIGZvcm0gYmVsb25ncyB0byByZmMyODIxIHN5c3RlbSBhbmQN Cj4+IHRoZSAgYWJjQGV4YW1wbGUuY29tIHdpdGggdXRmLTggZm9ybSBiZWxvbmdzIHRvIEVBSSBz eXN0ZW0sICB3aWxsICBCT0IncyBFQUkNCj4+IHN5c3RlbSByZWZ1c2UgdG8gYWNjZXB0IHRoZSBt ZXNzYWdlIGZyb20gQWxpY2UncyBSRkM1MzIxIHN5c3RlbSB3aXRoDQo+PiBhYmNAZXhhbXBsZTIu Y29tIHRvIEJPQidzIHN5c3RlbSB3aXRoICBhYmNAZXhhbXBsZS5jb20gb3IgYWJjQGEtbGFiZWw/ Pw0KPiANCj4gSSB0aGluayB5b3UgYXJlIGFza2luZzogIHdpbGwgYSBVVEYtOCBzeXN0ZW0gYWNj ZXB0IG1haWwgZnJvbSBhbiBBU0NJSSBzeXN0ZW0/DQo+IA0KDQpteSBxdWVzdGlvbiBpcyBzaW1p bGFyIHRvICJ3aWxsIGEgVVRGLTggc3lzdGVtIHdpdGggcmVjaXBlbnQgYWRkcmVzcyAoYWJjQGEt bGFibGUpIGFjY2VwdCBtYWlsIGZyb20gYW4gQVNDSUkgc3lzdGVtIHdpdGggdGhlIHNlbmRlciBh ZGRyZXNzIChhYmNAZXhhbXBsZTIuY29tKT8NCiINCnRoZSByZXZlcnNlZCBxdWVzdGlvbiBpcyAg ImNhbiBhIFVURi04IHN5c3RlbSB3aXRoIHJlY2lwZW50IGFkZHJlc3MgKGFiY0BhLWxhYmxlKSBz ZW5kIG1haWwgdG8gYW4gQVNDSUkgc3lzdGVtIHdpdGggdGhlIHNlbmRlciBhZGRyZXNzIChhYmNA ZXhhbXBsZTIuY29tKT8NCiIiDQoNCkZvciBib3RoIHF1ZXN0aW9ucywgeW91ciBhbnN3ZXJzIGFy ZSBOby4NCg0KSXMgdGhhdCBteSBjb3JyZWN0IHVuZGVyc3RhbmRpbmcuDQoNCklmIHRoYXQgaXMg Y29ycmVjdCwgSSB0aGluayB0aGF0IG1vc3Qgb2YgdGhlIGN1cnJlbnQgaW1wbGVtZW50b3JzIHdp bGwgY2hvb3NlIHRvIHN1cHBvcnQgImR1YWwgc3RhY2siIG1vZGVsICBpbiB0aGUgZW1haWwgc3lz dGVtIGluIG9yZGVyIHRvIGF2b2lkIHRoZSBzZXJpb3VzIGVtYWlsIGlzbGFuZC4NCg0KSWYgbW9z dCBpbXBsZW1lbnRvcnMgd2lsbCBjaG9vc2UgICJkdWFsIHN0YWNrIiBtb2RlbCwgdGhlIGltcGxl bW50b3JzIG1heSBwcmVmZXIgInVNYWlsYm94IiBzeW50YXggaW5zdGVhZCBvZiAibWFsYm94IiBz eW50YXguDQogDQpFdmVuIGlmIHdlIGp1c3QgdXNlICJtYWlsYm94IiBzeW50YXggaW4gcmZjNTMz NmJpcywgdGhlIGltcGxlbWVudG9ycyB3aWxsIGNob29zZSB0byB1c2UgdGhlIG5ldyBuYW1lIGZv ciB0aGUgIm1haWxib3giICBvZiByZmM1MzM2YmlzIGluIHRoZSBhY3R1YWwgaW1wbGVtZW50YWlv bnMgaW4gb3JkZXIgdG8gZGlmZmVyIGl0IGZyb20gdGhlIHJmYzUzMjEncyAibWFpbGJveCIgbmFt ZS4NCg0KdGhlIHF1ZXN0aW9uIGJlY29tZXM6IHdlIGNoYW5nZSB0aGUgbmFtZSBpbiB0aGUgcmZj NTMzNmJpcyBtYWlsYm94IHN5bnRheCBmb3IgaW1wbGVtZW50b3JzIG9yIHRoZSBpbXBsZW1lbnRv cnMgY2hvb3NlIHRoZWlyIG93biB2ZXJzaW9uIG9mIHRoZSBuYW1lIGZvciB0aGUgcmZjNTMzNmJp cyBtYWlsYm94ID8NCg0KdGhhbmtzLg0KDQpKaWFua2FuZyBZYW8NCg0KPiAgICAgIChGb3IgcmVm ZXJlbmNlLCAgSSBzdWdnZXN0IHRoYXQgdGhlIHRlcm0gIkVBSSIgaXMgbm90IGhlbHBmdWwgaGVy ZS4gSXRzIA0KPiBwcmVjaXNlIG1lYW5pbmcgZm9yIHRoaXMgc29ydCBvZiBkaXNjdXNzaW9uIGlz IG5vdCBjbGVhci4gT24gdGhlIG90aGVyIGhhbmQsIA0KPiByZWZlcnJpbmcgdG8gdGhlIGVuY29k aW5nIG9mIHRoZSBkYXRhIGlzIHNpbXBsZSwgZGlyZWN0IGFuZCBjbGVhci4pDQo+IA0KPiBUaGUg YW5zd2VyIGlzIG5vLCB3aXRob3V0IGEgZ2F0ZXdheSwgaWYgYm90aCBzeXN0ZW1zIG9ubHkgZG8g b25lIGZvcm0gb2YgZGF0YS4NCj4gDQo+IEluIHJlYWxpdHksIHdlIGNhbiBleHBlY3QgYSBVVEYt OCBzeXN0ZW0gYWxzbyB0byBzdXBwb3J0IGxlZ2FjeSBSRkM1MzIxLCBidXQgDQo+IHRoYXQgaXMg YSBwdXJlICJkdWFsIHN0YWNrIiBtb2RlbCBhbmQgdGhlIGxlZ2FjeSBiZWhhdmlvciBpcyBvdXRz aWRlIHRoZSBzY29wZSANCj4gb2YgdGhlIHdvcmtpbmcgZ3JvdXAsIHNpbmNlIGl0IGlzIGFscmVh ZHkgY292ZXJlZCBieSBSRkM1MzIxL1JGQzUzMjIuDQo+IA0KPiBBZ2FpbiwgdGhlIGFyY2hpdGVj dHVyYWwgbW9kZWwgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGNob3NlbiB0byBwdXJzdWUgaXMgZm9y IA0KPiBkdWFsIHN0YWNrOiAgVVRGLTggYW5kIEFTQ0lJIGFyZSBub3QgaGFuZGxlZCB0b2dldGhl ci4gIElmIHRoZSBwYXRoIGlzIFVURi04LCBpdCANCj4gaXMgL29ubHkvIFVURi04Lg0KPiANCj4g DQo+IGQvDQo+IA0KPiBwcy4gIEkgcHJvdmlkZWQgYW4gYXJjaGl0ZWN0dXJhbCBkaWFncmFtIGJl Y2F1c2UgaXQgb2Z0ZW4gaXMgaGVscGZ1bCB0byBzaG93IA0KPiB0aGVzZSB0eXBlcyBvZiBpc3N1 ZXMgYXMgcGljdHVyZXMgdGhhdCBsYWJlbCB0aGUgYWN0b3JzIGFuZCB0aGUgZGF0YSB0aGV5IGFy ZSANCj4gZXhjaGFuZ2luZy4gIEkgZG8gbm90IGtub3cgd2hldGhlciBpdCB3aWxsIGhlbHAgZm9y IHlvdSB0byBkZXZlbG9wIGEgcGljdHVyZSBmb3IgDQo+IHRoZSBhYm92ZSwgYnV0IGl0IG1pZ2h0 Lg0KPiANCj4gLS0gDQo+IA0KPiAgIERhdmUgQ3JvY2tlcg0KPiAgIEJyYW5kZW5idXJnIEludGVy bmV0V29ya2luZw0KPiAgIGJiaXcubmV0 From dhc2@dcrocker.net Thu Apr 28 21:02:59 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E04E066F for ; Thu, 28 Apr 2011 21:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AejizEAcDWRZ for ; Thu, 28 Apr 2011 21:02:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 79656E062B for ; Thu, 28 Apr 2011 21:02:55 -0700 (PDT) Received: from [192.168.1.6] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3T42kGi010068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2011 21:02:51 -0700 Message-ID: <4DBA3867.2050702@dcrocker.net> Date: Thu, 28 Apr 2011 21:02:47 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jiankang YAO References: <503772449.20058@cnnic.cn> <503778018.28156@cnnic.cn> <503782503.03885@cnnic.cn> <503785503.12770@cnnic.cn> <503789039.15208@cnnic.cn> <503837555.21823@cnnic.cn> <503869500.14165@cnnic.cn> <503964199.26727@cnnic.cn> <504047505.31177@cnnic.cn> In-Reply-To: <504047505.31177@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 28 Apr 2011 21:02:52 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] The scenario favoring "uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 04:02:59 -0000 Jiankang, On 4/28/2011 8:25 PM, Jiankang YAO wrote: >> I think you are asking: will a UTF-8 system accept mail from an ASCII >> system? > > my question is similar to "will a UTF-8 system with recipent address > (abc@a-lable) accept mail from an ASCII system with the sender address > (abc@example2.com)? Let's start with the fact that both addresses are also valid UTF-8 addresses. The current work only concerns sending UTF-8 addresses through a special, UTF-8 SMTP extension. So the answer to your first question must be Yes, when the message is sent using the extension. Since both addresses also are coded as ASCII, a different question is whether the recipient could receive the message through legacy SMTP? The answer to that is that it is outside the scope of this working group. However we can expect that most or all systems that support the SMTP extension will also support legacy SMTP. (dual stack) > " the reversed question is "can a UTF-8 system with > recipent address (abc@a-lable) send mail to an ASCII system with the sender > address (abc@example2.com)? "" Here the answer must be No, because the current scope of the EAI working group does not include solving this problem. However, again, we can expect systems that support UTF-8 for sending also to support legacy SMTP for sending. (Again, dual stack.) There will be a software design question of their deciding which to use, but that, again, is outside the current scope of the working group. > For both questions, your answers are No. Only for the second question, I believe. > If that is correct, I think that most of the current implementors will choose > to support "dual stack" model in the email system in order to avoid the > serious email island. I believe you are correct. > If most implementors will choose "dual stack" model, the implemntors may > prefer "uMailbox" syntax instead of "malbox" syntax. Here I believe we run into the confusion between the current protocol specification work, versus software development work that will include the protocol enhancement. The first has a narrow job. The second has a broader job. You are certainly correct that the software development effort must decide how to process dual-stack (ASCII and UTF-8) addresses within the same software system. However that is not the job of the EAI working group. > Even if we just use "mailbox" syntax in rfc5336bis, the implementors will > choose to use the new name for the "mailbox" of rfc5336bis in the actual > implementaions in order to differ it from the rfc5321's "mailbox" name. That's a software choice, not a protocol specification choice. Our requirement needs to be keeping things as simple as possible while doing (only) the work that satisfies the working group requirements. > the question becomes: we change the name in the rfc5336bis mailbox syntax for > implementors or the implementors choose their own version of the name for the > rfc5336bis mailbox ? The problem with the uMailbox approach is that it does not use names that are "instead" of the existing ones; it uses names that are "in addition to" the existing ones. And the result is a much, much more complex set of rules. Complexity means that it is more likely to have bugs in the specification and/or the implementation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net