From yangwooko@gmail.com Mon Jan 3 00:07:23 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 7CD6C3A6984 for ; Mon, 3 Jan 2011 00:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 8hYANap9GFYS for ; Mon, 3 Jan 2011 00:07:22 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 57B213A6982 for ; Mon, 3 Jan 2011 00:07:22 -0800 (PST) Received: by qyj19 with SMTP id 19so14101136qyj.10 for ; Mon, 03 Jan 2011 00:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=lYNVokA3UJr2spsGX4jjN2Qhv71c5buAVl9M17ecCHI=; b=PPccOKyTFX/y+Ls92dRWVmXWEAVCgzOsDHvaJ3RNX8zZKlrvuFQQlO12+mL3Ce+fxe kL8CyuMBq9yC7S9czfD8zB91j1R7ufO3AcPqEovoejm00eU7Fx8T9Zn+LIhneieBtPQR RY0EohmGvFSCVx0IClVSU2vuDB8gZp6nANbRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Sf+9TN3PCBEra8XNMbU25E4grNKg/avS/hKAmlo/UYJmOFv/n3jKo9q17u/ufMS+ZE IW0oS5fQhyfg6qx0UdDMNhkdLXS7u7oz0wKtt+0mv6qdkf+RDFh2C1MGRaDj/nMEf5j/ MfHY0ZsQhWg1h6PVKPPGtN2tHj5ZzosCTVSZY= Received: by 10.229.233.196 with SMTP id jz4mr17922492qcb.135.1294042168614; Mon, 03 Jan 2011 00:09:28 -0800 (PST) MIME-Version: 1.0 Sender: yangwooko@gmail.com Received: by 10.220.202.134 with HTTP; Mon, 3 Jan 2011 00:09:08 -0800 (PST) In-Reply-To: References: From: Yangwoo Ko Date: Mon, 3 Jan 2011 17:09:08 +0900 X-Google-Sender-Auth: Ufcz3b2JN-XKjGVkNtKnqqYfKA0 Message-ID: To: Shawn Steele Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range 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, 03 Jan 2011 08:07:23 -0000 Do you mean that "Basic Latin" is for a set of characters and "ASCII" for encoding of them in 7bit? On Sat, Jan 1, 2011 at 3:32 AM, Shawn Steele w= rote: > Random thought:=C2=A0 Unicode calls 00-7F =E2=80=9CC0 Controls and Basic = Latin.=E2=80=9D=C2=A0 Given > that the C0 Controls are pretty much illegal in email addresses, we could > shorten that to =E2=80=9CBasic Latin=E2=80=9D, which isn=E2=80=99t terrib= ly wordy, and evades the > question of whether we mean the ASCII set of characters U+0000-U+007f or = the > encoding. > > > > - Shawn > > > > =EF=A3=A2=EF=A3=90=EF=A3=A7=EF=A3=9B =EF=A3=A2=EF=A3=A3=EF=A3=97=EF=A3=94= =EF=A3=99 > > http://blogs.msdn.com/shawnste > > (Selfhost 7903) > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > --=20 a human known as yangwooko@gmail.com @ gtalk From chl@clerew.man.ac.uk Mon Jan 3 02:19:36 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 321B528C113 for ; Mon, 3 Jan 2011 02:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 r-63O6S1TMxC for ; Mon, 3 Jan 2011 02:19:34 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 6B79C3A6993 for ; Mon, 3 Jan 2011 02:19:14 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 8D4E321FBC for ; Mon, 3 Jan 2011 10:21:20 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 03 Jan 2011 10:21:20 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p03ALJti007872 for ; Mon, 3 Jan 2011 10:21:20 GMT Date: Mon, 03 Jan 2011 10:21:19 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d21a320.8373-79f6-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] non-EAI messages 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, 03 Jan 2011 10:19:36 -0000 On Fri, 31 Dec 2010 21:01:55 -0000, Troy Starr wrote: > Hi Shawn - > >> > The reason it's a terrible idea is that only some subset of the >> messages a given MTA handles will be EAI messages. >> >> I'm not sure how this is interesting? > > Assuming that all of the future MTAs in the message delivery chain > support UTF8SMTPbis, then I agree, it's not interesting. But what > happens if the previous MUA/MSA/MTA applied a UTF8SMTPbis flag to the > entire session rather than on a per-message basis, then the current MTA > wants to deliver one of those messages to an MTA which doesn't support > UTF8SMTPbis? I see the following possibilities: But surely it is obvious, and certainly so after your examples, that is there is to be a UTF8SMTPbis flag sent to a server by a client, then it HAS to be a per message flag rather than a session flag? Where did this idea of a session flag come from? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From dhc2@dcrocker.net Mon Jan 3 07:08:43 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 0BDFC3A69DE for ; Mon, 3 Jan 2011 07:08:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmT79GQT1LAn for ; Mon, 3 Jan 2011 07:08:42 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 038003A695C for ; Mon, 3 Jan 2011 07:08:42 -0800 (PST) Received: from [192.168.42.109] (m3b2736d0.tmodns.net [208.54.39.59]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p03FAfsA032355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 07:10:48 -0800 Message-ID: <4D21E6EC.7060100@dcrocker.net> Date: Mon, 03 Jan 2011 07:10:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 03 Jan 2011 07:10:48 -0800 (PST) Cc: "ima@ietf.org" Subject: Re: [EAI] Repeating normative text from other specifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 03 Jan 2011 15:08:43 -0000 On 12/31/2010 10:39 AM, Shawn Steele wrote: > I would also rather only list the differences, and not repeat stuff. That > lends to getting out-of-sync. Also it might make reviewing simpler since if > it wasn't there we couldn't mess it up :) Also we wouldn't have to worry > about other extensions that may impact the original RFC, or updates to that > RFC. Exactly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Mon Jan 3 07:21:19 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 9745A3A69E1 for ; Mon, 3 Jan 2011 07:21:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht08PMGZdyBb for ; Mon, 3 Jan 2011 07:21:13 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E0B033A69B4 for ; Mon, 3 Jan 2011 07:21:12 -0800 (PST) Received: from [192.168.42.109] (m3b2736d0.tmodns.net [208.54.39.59]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p03FN7qB003819 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 07:23:15 -0800 Message-ID: <4D21E9D4.1000201@dcrocker.net> Date: Mon, 03 Jan 2011 07:23:00 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yangwoo Ko References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 03 Jan 2011 07:23:16 -0800 (PST) Cc: Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 03 Jan 2011 15:21:19 -0000 On 1/3/2011 12:09 AM, Yangwoo Ko wrote: > Do you mean that "Basic Latin" is for a set of characters and "ASCII" > for encoding of them in 7bit? > > On Sat, Jan 1, 2011 at 3:32 AM, Shawn Steele wrote: >> Random thought: Unicode calls 00-7F “C0 Controls and Basic Latin.” Kudos to Shawn for being both creative and diligent, in finding such a well-founded basis for an additional label to consider. I had the same question as Yangwoo, but on re-reading Shawn's note I see that "Latin" comes from a reference to Unicode. Therefore I think yes, Latin is the set of characters and "ASCII" would be an encoding of those characters. Hence, the 2x2 table would be: | Representation | Encoding | +----------------+------------+ | | | Legacy | Latin | ASCII | | | | +----------------+------------+ | | | International | Unicode | UTF-8 | | | | +----------------+------------+ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Mon Jan 3 07:29:23 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 531C93A6A08 for ; Mon, 3 Jan 2011 07:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.145 X-Spam-Level: X-Spam-Status: No, score=-111.145 tagged_above=-999 required=5 tests=[AWL=0.054, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReJwLGvOMJ7z for ; Mon, 3 Jan 2011 07:29:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id C8AAA3A6A03 for ; Mon, 3 Jan 2011 07:29:21 -0800 (PST) Received: (qmail 89872 invoked from network); 3 Jan 2011 15:31:28 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 3 Jan 2011 15:31:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=12d2c.4d21ebd0.k1101; i=johnl@user.iecc.com; bh=73LIUt4puXnRkkoJDlK9LgHtP2akzhDVLiA4GQTNv3Q=; b=Vg4hzrFFr5ayGfaTljcZdnm4qmAwoQMQAnXBv8bX6lwkx17r1Lgzn6jNaWpBibcRpwnyoPpzu3k0ktSGgkK1qRuDC2gWpwIkVZ6eVuZP0Z8y3NEWjTPu5KWMcVbvNqTaAsj/D4M8mRrRQWopJq6eBHasxEBbnRojvOZgctadw4g= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=12d2c.4d21ebd0.k1101; olt=johnl@user.iecc.com; bh=73LIUt4puXnRkkoJDlK9LgHtP2akzhDVLiA4GQTNv3Q=; b=r6TR6hmh+RWNwERxgDevlqgI98+yviNbiEEqDq7NGLZQ+3KWTIt4zUZorZsDINIEV4HXxoztXdM8BriY4/sx7yW8K8pBUhx93eC5sz17Bs/ReOkvOzZMMB1iFigqxt2/HN86gKtwrVF1ZPLUVw7HjLpFPwCPcNkr0A5/su2sZcU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Jan 2011 15:31:28 -0000 Message-ID: <20110103153128.77099.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: chl@clerew.man.ac.uk Subject: Re: [EAI] non-EAI messages 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, 03 Jan 2011 15:29:23 -0000 > Where did this idea of a session flag come from? >From me, I suppose. There are clearly two ways to tell whether a message to be relayed needs an EAI server. One is what we might call Deep Message Inspection, scrutinize the message body and envelope to see if they contain anything that classic SMTP can't handle. The other is Assertion, use whatever EAI flag the sender used. My advice is simply to document the two possibilities and move on. They both work, for plausible albeit different definitions of work. Whatever we do, some people will do one, some will do the other. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From dhc2@dcrocker.net Mon Jan 3 07:45:42 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 DC7EB3A697E for ; Mon, 3 Jan 2011 07:45:42 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwkV0DNb6sSI for ; Mon, 3 Jan 2011 07:45:41 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 3F5713A697C for ; Mon, 3 Jan 2011 07:45:38 -0800 (PST) Received: from [192.168.42.109] (m3b2736d0.tmodns.net [208.54.39.59]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p03FlXP7010692 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 3 Jan 2011 07:47:41 -0800 Message-ID: <4D21EF8F.8060007@dcrocker.net> Date: Mon, 03 Jan 2011 07:47:27 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ima@ietf.org References: <20110103153128.77099.qmail@joyce.lan> In-Reply-To: <20110103153128.77099.qmail@joyce.lan> 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, 03 Jan 2011 07:47:42 -0800 (PST) Subject: Re: [EAI] non-EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 03 Jan 2011 15:45:43 -0000 On 1/3/2011 7:31 AM, John Levine wrote: >> Where did this idea of a session flag come from? > >> From me, I suppose. > > There are clearly two ways to tell whether a message to be relayed > needs an EAI server. One is what we might call Deep Message > Inspection, scrutinize the message body and envelope to see if they > contain anything that classic SMTP can't handle. The other is > Assertion, use whatever EAI flag the sender used. > > My advice is simply to document the two possibilities and move on. > They both work, for plausible albeit different definitions of work. > Whatever we do, some people will do one, some will do the other. The characters set of a message is a property of the message. The encoding of the message is a property of the message. Consecutive messages could -- and likely will -- have different character sets and/or encoding. A single user speak to many different recipients. A single email environment often supports many different users. This combination means that the transport service needs to impose as few session limitations as possible. A "session" flag would require establishing a new session in order to change character sets and/or encodings. That makes it a highly sub-optimal choice. Making character and encoding declarations work at a per-message level, rather than a per-session level is by far the better choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From McQuilWP@pobox.com Mon Jan 3 08:50:15 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 BB0AB3A69BE for ; Mon, 3 Jan 2011 08:50:15 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+vHxqvk7+be for ; Mon, 3 Jan 2011 08:50:14 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 9204B3A68C9 for ; Mon, 3 Jan 2011 08:50:13 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id B653088F3; Mon, 3 Jan 2011 11:52:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=SBqcBYdIX3e4 HFxZ9gREQXznmOE=; b=NwoexxdGHQJTrpE4hdpLtJfPq+XBwBg5Ty3yvujjR3a3 KQpYaGkCvv7jicT+4DiPf0b8Rimm+jHYJtLt+Kfdspp67/NhxjhSUGPp6yl+G+Qu WRG0acBU46QZRNpn1loK4d+vRS34LOBxcdEqOP2BM8TxVHKjUbdn+Cd7aXO0N/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=iGyZqj q69JK4h9eic1KQ1SWp5V7sq1qXSohrGmgEAVfaZ6QpcFmjyl1coPADfxYPcAzY+A FB47Vf+krJD0DUv4pAzFeJ/fc5pHnnkLA1xPerdDT5aGv0SvqkOxFwnApWKMh6fX b4tnG/GrO4aCG6sibVvwz/hqG18+foPTlt5Xk= Received: from b-pb-sasl-quonix. (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 9552088E9; Mon, 3 Jan 2011 11:52:17 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 09CC488E5; Mon, 3 Jan 2011 11:52:14 -0500 (EST) Date: Mon, 3 Jan 2011 08:52:13 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <58840212.20110103085213@pobox.com> To: IMA Discussion In-Reply-To: <4D21EF8F.8060007@dcrocker.net> References: <20110103153128.77099.qmail@joyce.lan> <4D21EF8F.8060007@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D2B6664A-1759-11E0-A2FB-DD55F7BC62F2-02871704!b-pb-sasl-quonix.pobox.com Cc: Dave CROCKER Subject: Re: [EAI] non-EAI messages 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, 03 Jan 2011 16:50:15 -0000 On Mon, 2011-01-03, Dave CROCKER wrote: > A "session" flag would require establishing a new session in order to change > character sets and/or encodings. That makes it a highly sub-optimal choice. > Making character and encoding declarations work at a per-message level, rather > than a per-session level is by far the better choice. I seems to me that two different client assertions are being discussed here, "I understand UTF8SMTPbis" and "The current message has non-ASCII in the header". Originally the idea was that Deep Message Inspection was able to determine the value of the second assertion without a flag or command. However the issue of allowing UTF-8 in responses to VRFY and EXPN raised the issue of the first assertion in the absence of any message to be inspected. I fear the only clean solution is both a session state setting command and a per-transaction flag. -- Bill McQuillan From ned+ima@mrochek.com Mon Jan 3 09:47:47 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 63F5F3A69BC for ; Mon, 3 Jan 2011 09:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCHdDHXnlnr2 for ; Mon, 3 Jan 2011 09:47:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 30DE83A69BB for ; Mon, 3 Jan 2011 09:47:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NW6KZRJ01C00F8NZ@mauve.mrochek.com> for ima@ietf.org; Mon, 3 Jan 2011 09:49:52 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NW55M3N45S007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 3 Jan 2011 09:49:49 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NW6KZQLDRQ007FL5@mauve.mrochek.com> Date: Mon, 03 Jan 2011 09:31:54 -0800 (PST) In-reply-to: "Your message dated Mon, 03 Jan 2011 08:52:13 -0800" <58840212.20110103085213@pobox.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110103153128.77099.qmail@joyce.lan> <4D21EF8F.8060007@dcrocker.net> <58840212.20110103085213@pobox.com> To: Bill McQuillan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1294074009; bh=WVGm05HqXJZAmWAk1Bfcajewj02QA/lsf3ZH7YGTM/E=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=h670cHz6qS2lqxXmcKpXEtb6Z9KlMkduLl4wKqfv6TGY5W/pg5xlYnhS736J5MZUx OgNDSHjHhWluvX/6ogTUK4X0PaqW3HOEEN71LljPLwBcodmxcIJZfR+5Av01Ze2Avt Ov7bge8B4HOr2N/7jibTfwGQMgZggX7lPk9/DU0U= Cc: Dave CROCKER , IMA Discussion Subject: Re: [EAI] non-EAI messages 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, 03 Jan 2011 17:47:47 -0000 > On Mon, 2011-01-03, Dave CROCKER wrote: > > A "session" flag would require establishing a new session in order to change > > character sets and/or encodings. That makes it a highly sub-optimal choice. > > Making character and encoding declarations work at a per-message level, rather > > than a per-session level is by far the better choice. > I seems to me that two different client assertions are being discussed > here, "I understand UTF8SMTPbis" and "The current message has non-ASCII in > the header". Correct, but it is also important to note that they are essentially disjoint in terms of usage - the former is applicable to VRFY/EXPN, the latter to message transfer transactions. So these are really two different problems. > Originally the idea was that Deep Message Inspection was able to determine > the value of the second assertion without a flag or command. Which is still true. It's not that deep inspection doesn't work - it does - but rather that it's not good choice operationally. > However the > issue of allowing UTF-8 in responses to VRFY and EXPN raised the issue of > the first assertion in the absence of any message to be inspected. > I fear the only clean solution is both a session state setting command and > a per-transaction flag. Actually, while a session flag solution for VRFY/EXPN is nowhere near as sucky as it is for MAIL FROM, it's not the cleanest solution either. The problematic case would be some sort of lookup proxy, where sometimes the operation being performed is amendable to a utf-8 return value and sometimes it is not. Such an agent would have essentially the same issue with global state complexity. Now, I'm by no means sure such agents - assuming they even exist - would be worth catering to if it meant messing things up in some way. But it's not like having either a command argument or a separate set of commands are themselves problematic for other reasons. So I'm inclined to stick with the VRFY/EXPN parameter as the cleanest overall approach. Ned From klensin@jck.com Mon Jan 3 12:17:35 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 8E26E3A6B5F for ; Mon, 3 Jan 2011 12:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599, GB_I_LETTER=-2] 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 paFu6rLcPN-r for ; Mon, 3 Jan 2011 12:17:34 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4F4473A6A34 for ; Mon, 3 Jan 2011 12:17:33 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PZqsS-0000te-R4; Mon, 03 Jan 2011 15:19:37 -0500 Date: Mon, 03 Jan 2011 15:19:36 -0500 From: John C Klensin To: Yangwoo Ko , Shawn Steele Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Random thought on ASCII range 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, 03 Jan 2011 20:17:35 -0000 --On Monday, January 03, 2011 17:09 +0900 Yangwoo Ko wrote: > Do you mean that "Basic Latin" is for a set of characters and > "ASCII" for encoding of them in 7bit? Well, if one is going to be completely precise, "Basic Latin" and "ASCII repertoire" aren't synonyms. We sort of got away with it in IDNA because we did a bit of hand waving and had already excluded all of the inconvenient punctuation, C0 control characters, etc., from consideration in other ways. Unicode gets away with it because they define things that way, but that isn't the only common usage of that term, it is a local definition. We can make it a local definition here too, but only at the risk of using a term that is used differently elsewhere in a special way. I don't have a problem with that if the WG is ok with it. But the state of the C0 controls actually is important because they are valid, if little-used, in 821/822/5321/5322 email. The WG has discussed, and I think agreed on, prohibiting them if EAI features are needed (deliberately vague-- another issue), but they are still valid in legacy, all-ASCII, addresses. If one is comparing to Unicode and ignores the ASCII embedding problem, there is an ASCII repertoire and a Unicode repertoire, a native encoding for ASCII and three native encodings for Unicode. FWIW, Unicode code points are usually expressed as a range of hexidecimal integers (with the normal notation of U+[N[N]]NNN) and ASCII code points have historically been expressed either as a decimal number or in row/column form, e.g., 4/1 for upper case A). The ASCII repertoire, however, includes not only the letter characters that Unicode calls "Basic Latin" but much of the linguistic and writing system communities do not. As Unicode's definition and Shawn's note only partially point out, those letters aren't Basic Latin: classical Latin doesn't use W, differentiate between U and V or I and J, etc.). And the ASCII repertoire also includes a set of Indic-Arabic digits that classical Latin definitely does not use (and doesn't include all of the characters needed to write classical Roman numerals), a collection of so-called C0 controls (characters 0/1 through 1/15), and character 7/15. We actually already have a term for ASCII in the native encoding and IETF 8bit embedding. We've been calling it "NVT" for many, many years. The only problem is that there has been an ambiguity for almost that many years as to whether NVT includes some or all of the C0 controls. These problems are not new. Once one accepts those definitions, and ignores the other two native encodings for Unicode, we've got an updated version of Dave's 2x2 matrix. However, the most important, and most difficult, term needed to make the relevant distinctions is what we've often (and sloppily) called non-ASCII. Due to some duplications in Unicode, it isn't the set difference between the Unicode repertoire and the ASCII repertoire unless one accepts that those duplications are actually different characters by virtue of being coded differently (an assertion that much of the linguistic and writing system community rejects). Instead, it has to be defined in terms of ranges, e.g., Unicode code points above U+007F. Let me say differently what I've tried to say before: If the right solution at this point is for the WG to define its own set of words (per Andrew's proposal or some variation), I'm ok with that. If, however, we are going to use words with definitions that are slightly different from definitions and usage elsewhere, I think we do a real disservice to the community if those definitions are not made IETF-wide (a job that lies outside EAI's scope). Otherwise, people reading specs will have to figure out what a given term means in the context of that spec. I think most of us have already had ample experience with where that expectation leads -- people skip over definitions that they are confident that they know and then guess wrong about what the spec means. john From dhc2@dcrocker.net Mon Jan 3 15:21:52 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 D10AD3A6D45 for ; Mon, 3 Jan 2011 15:21:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbPcGhNtCHp3 for ; Mon, 3 Jan 2011 15:21:51 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 46DD63A6D44 for ; Mon, 3 Jan 2011 15:21:51 -0800 (PST) Received: from [172.28.172.96] (12-198-124-226att-inc.com [12.198.124.226] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p03NNoj3028115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 15:23:58 -0800 Message-ID: <4D225A80.2040001@dcrocker.net> Date: Mon, 03 Jan 2011 15:23:44 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: 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, 03 Jan 2011 15:23:58 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] "non-ascii" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 03 Jan 2011 23:21:53 -0000 On 1/3/2011 12:19 PM, John C Klensin wrote: > However, the most important, and most difficult, term needed to > make the relevant distinctions is what we've often (and > sloppily) called non-ASCII. Why does the current work require a formal term for that (sub)set? The reference to that subset of Unicode is -- or, rather, should be -- actually quite limited. In the specifications, almost every reference to "non-ascii" actually means "Unicode", rather than "the subset of Unicode that is above x07F." That is, they appear to be making the reference to "non-ascii" when that should not be what is really meant. I've posted more than one note asking this question. Perhaps I missed the responses that provide a clear and compelling argument for needing the term? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From klensin@jck.com Mon Jan 3 19:39:53 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 5F1CC3A69B3 for ; Mon, 3 Jan 2011 19:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqzZiYcVQU+4 for ; Mon, 3 Jan 2011 19:39:52 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 145143A681E for ; Mon, 3 Jan 2011 19:39:52 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PZxmY-0003hM-98; Mon, 03 Jan 2011 22:41:58 -0500 Date: Mon, 03 Jan 2011 22:41:57 -0500 From: John C Klensin To: dcrocker@bbiw.net Message-ID: <47C29ECCF684835B84A9A0B7@PST.JCK.COM> In-Reply-To: <4D225A80.2040001@dcrocker.net> References: <4D225A80.2040001@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] "non-ascii" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:39:53 -0000 --On Monday, January 03, 2011 15:23 -0800 Dave CROCKER wrote: > On 1/3/2011 12:19 PM, John C Klensin wrote: >> However, the most important, and most difficult, term needed >> to make the relevant distinctions is what we've often (and >> sloppily) called non-ASCII. > > > Why does the current work require a formal term for that > (sub)set? > > The reference to that subset of Unicode is -- or, rather, > should be -- actually quite limited. > > In the specifications, almost every reference to "non-ascii" > actually means "Unicode", rather than "the subset of Unicode > that is above x07F." That is, they appear to be making the > reference to "non-ascii" when that should not be what is > really meant. > > I've posted more than one note asking this question. Perhaps > I missed the responses that provide a clear and compelling > argument for needing the term? Dave, perhaps you haven't tried writing specs or developed code in the i18n area and that is why this seems obvious to those who have but not to you and, hence why explanations that seem "clear and compelling" to some of the more active participants in this work seem less so to you. Let me try a different explanation in the hope that it will make sense to you. At first glance, one should only have the situation your matrix seems to assume: ignoring encoding and embedding issues, a string is either ASCII or it is relatively unrestricted Unicode. And, if it is the latter, one doesn't need to worry about ASCII as a distinct subset. In practice, Unicode outside the ASCII range always seems to carry a certain amount of baggage with it: requirements for normalization, case and character comparison situations that can use a number of different rules, alternate collation sequences (possible with ASCII too depending, e.g., on whether one thinks in terms of "ABC...abc" or "AaBbCc..." but with far fewer alternate variations), and so on. The result of this is that, when one actually sits down to sort out the details of specs, the situation often comes down to a need to talk about the difference between a string containing only characters from the ASCII repertoire (regardless of what one decides to call that) and a string of characters from the Unicode repertoire that contains at least one character outside the ASCII range. A recent discussion on this list about local parts provides a fairly typical example. A particular address is internationalized, requiring EAI extensions be present, iff it contains at least one Unicode character outside the ASCII range in either the local-part or the domain part (or a display name containing Unicode characters outside the ASCII range encoded in UTF-8 rather than as encoded words). It isn't sufficient to write that rule as "Unicode" or "UTF-8" because the ASCII repertoire is a proper superset of the first and the ASCII codes (embedded in 8bit fields) are proper supersets of the latter. Hope that helps. john From klensin@jck.com Mon Jan 3 20:47:39 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 82D853A6A5C for ; Mon, 3 Jan 2011 20:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 9NKw5NvQHWVt for ; Mon, 3 Jan 2011 20:47:38 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9A3833A6A5A for ; Mon, 3 Jan 2011 20:47:38 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PZyq1-00044E-BE; Mon, 03 Jan 2011 23:49:37 -0500 Date: Mon, 03 Jan 2011 23:49:36 -0500 From: John C Klensin To: Dave CROCKER , Joseph Yee Message-ID: In-Reply-To: <4D1D24E8.8020005@bbiw.net> References: <68655A9F86D4BE7ED933F8A6@192.168.1.128> <4D192FF8.1030706@dcrocker.net> <9B48F59821946F2EA2DCDEA0@192.168.1.128> <4D19623F.3040804@dcrocker.net> <61939C011F6BB4A93749804C@192.168.1.128> <0D625A27294258D00E95152A@192.168.1.128> <4D1AD148.7070000@dcrocker.net> <2D0309E0-97FD-4303-83DC-3A2296B0A102@ca.afilias.info> <82115E5B-A387-486C-A46D-70CCA176C4A8@ca.afilias.info> <4D1D24E8.8020005@bbiw.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] Unicode vs. UTF-8 / Encoding vs. Representation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 04:47:39 -0000 --On Thursday, December 30, 2010 16:33 -0800 Dave CROCKER wrote: >... > If a message is in legacy form, then it is ASCII (or, rather, > ASCII-only). If it is in Unicode form, then it is in Unicode, > even if all the characters are x07F or below... To amplify on my previous note with another example, consider the VRFY/EXPN situation. If the server receives an all-ASCII argument, the condition in the spec is that it MUST NOT return a string in which any characters outside the ASCII repertoire are present. One can figure out lots of more or less convoluted ways to say that (the above is an example), but the obvious ones all involve having a term for what has, in IETF i18n terminology, traditionally been called "non-ASCII". john From klensin@jck.com Mon Jan 3 21:02:45 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 BF3C23A6B10 for ; Mon, 3 Jan 2011 21:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 MgkbqLBhimjL for ; Mon, 3 Jan 2011 21:02:45 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E05883A6A5E for ; Mon, 3 Jan 2011 21:02:44 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PZz4g-0004CQ-BG; Tue, 04 Jan 2011 00:04:46 -0500 Date: Tue, 04 Jan 2011 00:04:45 -0500 From: John C Klensin To: Charles Lindsey , IMA Message-ID: <88B011BD899484DA740CE0BA@PST.JCK.COM> In-Reply-To: References: <68655A9F86D4BE7ED933F8A6@192.168.1.128> <4D192FF8.1030706@dcrocker.net> <9B48F59821946F2EA2DCDEA0@192.168.1.128> <4D19623F.3040804@dcrocker.net> <61939C011F6BB4A93749804C@192.168.1.128> <0D625A27294258D00E95152A@[192.168.1.128]> <4D1AD148.7070000@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 Subject: Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Representation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 05:02:45 -0000 --On Thursday, December 30, 2010 10:40 +0000 Charles Lindsey wrote: > If you are looking for a term to describe some UTF-8 text that > is not also an ASCII text, then normal mathematical usage is > to use the word "proper". > > E.g., a is A is a "proper subset" of B, then A is not > identical to B. > > So something like "proper-utf8" would follow that concention. > You might even use "PROPER_UTF8" as that parameter of the MAIL > command. At one level, harking back to the years when I pretended to be a mathematician (or at least an aspiring one), this really appeals to me. At another, I believe that "proper utf-8" (no matter how punctuated) will be read by most non-mathematicians and even some mathematicians who haven't been alerted to the special usage) as the opposite of "improper UTF-8" or "invalid UTF-8". Unfortunately, that is a real category. A small oversight in the original UTF-8 spec (see RFC 2044 and elsewhere) permitted there to exist situations in which two [bitstring-] different UTF-8 strings would map to/represent the same Unicode code point. That was later corrected (see RFC 2279 and 3629 and elsewhere) so that the longer of the two encodings became invalid. john From yangwooko@gmail.com Mon Jan 3 21:50:10 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 2C37C3A6B27 for ; Mon, 3 Jan 2011 21:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 w2k6Hq8szCk4 for ; Mon, 3 Jan 2011 21:50:08 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 93FB63A6B2C for ; Mon, 3 Jan 2011 21:50:08 -0800 (PST) Received: by qwg5 with SMTP id 5so14875366qwg.31 for ; Mon, 03 Jan 2011 21:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=548dcmPpF3YxMSbGrPIdRnCjYfnfu9oJCd8f1xHXdLY=; b=rsxu5LtcW66yUHXN+L0EF+f6M3Bun/sVh9Q2tkdGzqrqt8+s/pIparHzUOtWsbXpAX tL/ea1NV59t3tW0krjuWq20Be/bfZfuepewkWPwSpGMAdhsZXdWQYsqIe4Q2iOt/Ulsz AtzFatjg8czY750xxiQ4HjU4o8A2R6HYOUhFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rI2Zs3f163RcrGIEEif/7xIXyyY8W9dbJeTTIr2zpLxTLCTrsY/phsXBqE+94RQ8yU Dhh4sR3j1v4jcpjT+RteaA6OwegWcoRRgZGJHkspvCsuX11p9qxEsw7ibNwGfKX8qxsz rWY2E+A2R3XDHIfg8m1rrLT01T1PvE65/mRBw= Received: by 10.229.212.6 with SMTP id gq6mr18737751qcb.150.1294120334919; Mon, 03 Jan 2011 21:52:14 -0800 (PST) MIME-Version: 1.0 Sender: yangwooko@gmail.com Received: by 10.220.19.3 with HTTP; Mon, 3 Jan 2011 21:51:54 -0800 (PST) In-Reply-To: <47C29ECCF684835B84A9A0B7@PST.JCK.COM> References: <4D225A80.2040001@dcrocker.net> <47C29ECCF684835B84A9A0B7@PST.JCK.COM> From: Yangwoo Ko Date: Tue, 4 Jan 2011 14:51:54 +0900 X-Google-Sender-Auth: 2Ds07FtyHMWCW72vA9YKlGx9L7M Message-ID: To: John C Klensin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dcrocker@bbiw.net, ima@ietf.org Subject: Re: [EAI] "non-ascii" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 05:50:10 -0000 This discussion reveals that we need to be clear about whether terms are about a set of charcters or about a string. In the context of EAI, I thought (and still think) that the latter terms are enough. In other words, we need to have a term for "non-ASII string" not for "set of characters > 0x7f". On Tue, Jan 4, 2011 at 12:41 PM, John C Klensin wrote: > > > > > --On Monday, January 03, 2011 15:23 -0800 Dave CROCKER > wrote: > >> On 1/3/2011 12:19 PM, John C Klensin wrote: >>> However, the most important, and most difficult, term needed >>> to make the relevant distinctions is what we've often (and >>> sloppily) called non-ASCII. >> >> >> Why does the current work require a formal term for that >> (sub)set? >> >> The reference to that subset of Unicode is -- or, rather, >> should be -- actually quite limited. >> >> In the specifications, almost every reference to "non-ascii" >> actually means "Unicode", rather than "the subset of Unicode >> that is above x07F." =C2=A0That is, they appear to be making the >> reference to "non-ascii" when that should not be what is >> really meant. >> >> I've posted more than one note asking this question. =C2=A0Perhaps >> I missed the responses that provide a clear and compelling >> argument for needing the term? > > Dave, perhaps you haven't tried writing specs or developed code > in the i18n area and that is why this seems obvious to those who > have but not to you and, hence why explanations that seem "clear > and compelling" to some of the more active participants in this > work seem less so to you. =C2=A0Let me try a different explanation in > the hope that it will make sense to you. > > At first glance, one should only have the situation your matrix > seems to assume: ignoring encoding and embedding issues, a > string is either ASCII or it is relatively unrestricted Unicode. > And, if it is the latter, one doesn't need to worry about ASCII > as a distinct subset. =C2=A0In practice, Unicode outside the ASCII > range always seems to carry a certain amount of baggage with it: > requirements for normalization, case and character comparison > situations that can use a number of different rules, alternate > collation sequences (possible with ASCII too depending, e.g., on > whether one thinks in terms of "ABC...abc" or "AaBbCc..." but > with far fewer alternate variations), and so on. =C2=A0 The result of > this is that, when one actually sits down to sort out the > details of specs, the situation often comes down to a need to > talk about the difference between a string containing only > characters from the ASCII repertoire (regardless of what one > decides to call that) and a string of characters from the > Unicode repertoire that contains at least one character outside > the ASCII range. > > A recent discussion on this list about local parts provides a > fairly typical example. =C2=A0A particular address is > internationalized, requiring EAI extensions be present, iff it > contains at least one Unicode character outside the ASCII range > in either the local-part or the domain part (or a display name > containing Unicode characters outside the ASCII range encoded in > UTF-8 rather than as encoded words). =C2=A0 It isn't sufficient to > write that rule as "Unicode" or "UTF-8" because the ASCII > repertoire is a proper superset of the first and the ASCII codes > (embedded in 8bit fields) are proper supersets of the latter. > > Hope that helps. > =C2=A0 =C2=A0john > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > --=20 a human known as yangwooko@gmail.com @ gtalk From klensin@jck.com Tue Jan 4 07:42:50 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 A7B693A6CA5 for ; Tue, 4 Jan 2011 07:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psI5niIzBzVq for ; Tue, 4 Jan 2011 07:42:49 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 455F43A6CA3 for ; Tue, 4 Jan 2011 07:42:49 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pa947-0008qd-1W; Tue, 04 Jan 2011 10:44:51 -0500 Date: Tue, 04 Jan 2011 10:44:50 -0500 From: John C Klensin To: Yangwoo Ko Message-ID: <4AEBE8BA5C79F7F79FA18936@PST.JCK.COM> In-Reply-To: References: <4D225A80.2040001@dcrocker.net> <47C29ECCF684835B84A9A0B7@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dcrocker@bbiw.net, ima@ietf.org Subject: Re: [EAI] "non-ascii" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 15:42:50 -0000 --On Tuesday, January 04, 2011 14:51 +0900 Yangwoo Ko wrote: > This discussion reveals that we need to be clear about whether > terms are about a set of charcters or about a string. In the > context of EAI, I thought (and still think) that the latter > terms are enough. Well, I've been trying to stay within the bounds of Dave's rather neat little matrix, but your note reminded me of how much difficulty we've had with that distinction, starting with the use of "variant" to describe both individual sets of characters and labels that contain one or more such characters in early versions of what became RFC 3743 (a problem that continues to confuse ICANN even though we corrected in in 3743 before it was published). It adds a third dimension to Dave's table. > In other words, we need to have a term for "non-ASII string" > not for "set of characters > 0x7f". I would say that we need a term for "string containing at least one character outside the ASCII repertoire". I don't think EAI needs a special definition for the set of Unicode characters outside the ASCII repertoire, but other protocols might. We should at least be aware of that possibility so as to avoid choosing a term that would create even more confusion when the set terminology is needed. john From Shawn.Steele@microsoft.com Tue Jan 4 09:29:26 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 C0B1E3A6CE0 for ; Tue, 4 Jan 2011 09:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lGufGSk6Juc for ; Tue, 4 Jan 2011 09:29:25 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A81873A6C0B for ; Tue, 4 Jan 2011 09:29:25 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 4 Jan 2011 09:31:32 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.174]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0255.003; Tue, 4 Jan 2011 09:31:31 -0800 From: Shawn Steele To: "dcrocker@bbiw.net" , Yangwoo Ko Thread-Topic: [EAI] Random thought on ASCII range Thread-Index: AcupF+V53djy5w7pS1ilQ7YHTFLyCwCSKd0AAA8nEgAAJet1cA== Date: Tue, 4 Jan 2011 17:31:31 +0000 Message-ID: References: <4D21E9D4.1000201@dcrocker.net> In-Reply-To: <4D21E9D4.1000201@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 17:29:26 -0000 U29ycnkgZm9yIG5vdCBiZWluZyBjbGVhcmVyLCB5ZXMsIEkgd2FzIHRoaW5raW5nIG9mIExhdGlu IGFzIHRoZSByYW5nZSBvZiBjaGFyYWN0ZXJzIChhZnRlciB0aGUgVW5pY29kZSBuYW1lIGZvciAw MC03ZikuICBOb3Qgc3RyaWN0bHkgYWNjdXJhdGUgKHRoZXJlJ3JlIG5vbi1zY3JpcHQgdGhpbmdz IGluIDAwLTdGKS4gIENvdWxkIGFsc28gYmUgbWlzbGVhZGluZyAoc2luY2UgdGhlcmUgYXJlIGxh dGluLXggY2hhcmFjdGVyIHNldHMpLCBidXQgSSBqdXN0IHRocmV3IGl0IG91dCBzaW5jZSB3ZSBz ZWVtZWQgY29uZnVzZWQgOikNCg0KLVNoYXduDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBEYXZlIENST0NLRVIgW21haWx0bzpkaGMyQGRjcm9ja2VyLm5ldF0gDQpTZW50OiBQ xY3Ku2FrYWhpLCBJYW51YWxpIDAzLCAyMDExIDc6MjMgQU0NClRvOiBZYW5nd29vIEtvDQpDYzog U2hhd24gU3RlZWxlOyBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSBSYW5kb20gdGhv dWdodCBvbiBBU0NJSSByYW5nZQ0KDQoNCg0KT24gMS8zLzIwMTEgMTI6MDkgQU0sIFlhbmd3b28g S28gd3JvdGU6DQo+IERvIHlvdSBtZWFuIHRoYXQgIkJhc2ljIExhdGluIiBpcyBmb3IgYSBzZXQg b2YgY2hhcmFjdGVycyBhbmQgIkFTQ0lJIg0KPiBmb3IgZW5jb2Rpbmcgb2YgdGhlbSBpbiA3Yml0 Pw0KPg0KPiBPbiBTYXQsIEphbiAxLCAyMDExIGF0IDM6MzIgQU0sIFNoYXduIFN0ZWVsZTxTaGF3 bi5TdGVlbGVAbWljcm9zb2Z0LmNvbT4gIHdyb3RlOg0KPj4gUmFuZG9tIHRob3VnaHQ6ICBVbmlj b2RlIGNhbGxzIDAwLTdGIOKAnEMwIENvbnRyb2xzIGFuZCBCYXNpYyBMYXRpbi7igJ0NCg0KDQpL dWRvcyB0byBTaGF3biBmb3IgYmVpbmcgYm90aCBjcmVhdGl2ZSBhbmQgZGlsaWdlbnQsIGluIGZp bmRpbmcgc3VjaCBhIHdlbGwtZm91bmRlZCBiYXNpcyBmb3IgYW4gYWRkaXRpb25hbCBsYWJlbCB0 byBjb25zaWRlci4NCg0KSSBoYWQgdGhlIHNhbWUgcXVlc3Rpb24gYXMgWWFuZ3dvbywgYnV0IG9u IHJlLXJlYWRpbmcgU2hhd24ncyBub3RlIEkgc2VlIHRoYXQgIkxhdGluIiBjb21lcyBmcm9tIGEg cmVmZXJlbmNlIHRvIFVuaWNvZGUuICBUaGVyZWZvcmUgSSB0aGluayB5ZXMsIExhdGluIGlzIHRo ZSBzZXQgb2YgY2hhcmFjdGVycyBhbmQgIkFTQ0lJIiB3b3VsZCBiZSBhbiBlbmNvZGluZyBvZiB0 aG9zZSBjaGFyYWN0ZXJzLg0KDQpIZW5jZSwgdGhlIDJ4MiB0YWJsZSB3b3VsZCBiZToNCg0KDQoN CiAgICAgICAgICAgICAgICAgIHwgUmVwcmVzZW50YXRpb24gfCAgRW5jb2RpbmcgIHwNCiAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgICAgICAgTGVnYWN5 IHwgICAgIExhdGluICAgICAgfCAgIEFTQ0lJICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgIHwNCiAgICBJbnRlcm5hdGlvbmFsIHwgICAgVW5pY29kZSAgICAgfCAgIFVU Ri04ICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0K ZC8NCi0tIA0KDQogICBEYXZlIENyb2NrZXINCiAgIEJyYW5kZW5idXJnIEludGVybmV0V29ya2lu Zw0KICAgYmJpdy5uZXQNCg0K From Shawn.Steele@microsoft.com Tue Jan 4 09:40:44 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 E96553A699F for ; Tue, 4 Jan 2011 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.439 X-Spam-Level: X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpqiogjW3lla for ; Tue, 4 Jan 2011 09:40:44 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 3EFB43A6D15 for ; Tue, 4 Jan 2011 09:40:44 -0800 (PST) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 4 Jan 2011 09:42:51 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.174]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0255.003; Tue, 4 Jan 2011 09:42:50 -0800 From: Shawn Steele To: John C Klensin , Yangwoo Ko Thread-Topic: [EAI] Random thought on ASCII range Thread-Index: AcupF+V53djy5w7pS1ilQ7YHTFLyCwCSKd0AABmC4gAAG7kzIA== Date: Tue, 4 Jan 2011 17:42:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 17:40:45 -0000 RldJVzogSSB0aGluayB0aGF0IChzaW5jZSB0aGVyZSdzIG5vIElFVEYtd2lkZSBkZWZpbml0aW9u KSwgdGhhdCB3ZSBzaG91bGQganVzdCAicGljayBzb21ldGhpbmciIGFuZCBtYWtlIHN1cmUgaXQn cyBjbGVhcmx5IGRlZmluZWQuICBUaGUgcHJvYmxlbSB3ZSd2ZSBoYWQgc2VlbXMgdG8gYmUgbW9y ZSBhbG9uZyBjb25zaXN0ZW50IHVzZSBvZiB0aGUgdGVybXMsIEkgZG91YnQgd2UnbGwgZmluZCBh ICJwZXJmZWN0IiB0ZXJtIHRoYXQncyBvYnZpb3VzIHcvbyBkZWZpbmluZyBpdC4NCg0KLVNoYXdu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIEMgS2xlbnNpbiBbbWFp bHRvOmtsZW5zaW5AamNrLmNvbV0gDQpTZW50OiBQxY3Ku2FrYWhpLCBJYW51YWxpIDAzLCAyMDEx IDEyOjIwIFBNDQpUbzogWWFuZ3dvbyBLbzsgU2hhd24gU3RlZWxlDQpDYzogaW1hQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0VBSV0gUmFuZG9tIHRob3VnaHQgb24gQVNDSUkgcmFuZ2UNCg0KLi4u DQoNCkxldCBtZSBzYXkgZGlmZmVyZW50bHkgd2hhdCBJJ3ZlIHRyaWVkIHRvIHNheSBiZWZvcmU6 ICBJZiB0aGUgcmlnaHQgc29sdXRpb24gYXQgdGhpcyBwb2ludCBpcyBmb3IgdGhlIFdHIHRvIGRl ZmluZSBpdHMgb3duIHNldCBvZiB3b3JkcyAocGVyIEFuZHJldydzIHByb3Bvc2FsIG9yIHNvbWUg dmFyaWF0aW9uKSwgSSdtIG9rIHdpdGgNCnRoYXQuICAgSWYsIGhvd2V2ZXIsIHdlIGFyZSBnb2lu ZyB0byB1c2Ugd29yZHMgd2l0aCBkZWZpbml0aW9ucw0KdGhhdCBhcmUgc2xpZ2h0bHkgZGlmZmVy ZW50IGZyb20gZGVmaW5pdGlvbnMgYW5kIHVzYWdlIGVsc2V3aGVyZSwgSSB0aGluayB3ZSBkbyBh IHJlYWwgZGlzc2VydmljZSB0byB0aGUgY29tbXVuaXR5IGlmIHRob3NlIGRlZmluaXRpb25zIGFy ZSBub3QgbWFkZSBJRVRGLXdpZGUgKGEgam9iIHRoYXQgbGllcyBvdXRzaWRlIEVBSSdzIHNjb3Bl KS4gIE90aGVyd2lzZSwgcGVvcGxlIHJlYWRpbmcgc3BlY3Mgd2lsbCBoYXZlIHRvIGZpZ3VyZSBv dXQgd2hhdCBhIGdpdmVuIHRlcm0gbWVhbnMgaW4gdGhlIGNvbnRleHQgb2YgdGhhdCBzcGVjLiAg SSB0aGluayBtb3N0IG9mIHVzIGhhdmUgYWxyZWFkeSBoYWQgYW1wbGUgZXhwZXJpZW5jZSB3aXRo IHdoZXJlIHRoYXQgZXhwZWN0YXRpb24gbGVhZHMgLS0gcGVvcGxlIHNraXAgb3ZlciBkZWZpbml0 aW9ucyB0aGF0IHRoZXkgYXJlIGNvbmZpZGVudCB0aGF0IHRoZXkga25vdyBhbmQgdGhlbiBndWVz cyB3cm9uZyBhYm91dCB3aGF0IHRoZSBzcGVjIG1lYW5zLg0KDQogICBqb2huDQoNCg0K From dcrocker@bbiw.net Tue Jan 4 10:13:43 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 894D73A6B83 for ; Tue, 4 Jan 2011 10:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuyNMfGEwYMv for ; Tue, 4 Jan 2011 10:13:41 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id BD87B3A6A32 for ; Tue, 4 Jan 2011 10:13:41 -0800 (PST) Received: from [172.28.172.96] (12-198-124-226att-inc.com [12.198.124.226] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p04IFaWM010804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 10:15:43 -0800 Message-ID: <4D2363C2.5010606@bbiw.net> Date: Tue, 04 Jan 2011 10:15:30 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Shawn Steele References: <4D21E9D4.1000201@dcrocker.net> In-Reply-To: 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, 04 Jan 2011 10:15:45 -0800 (PST) Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 18:13:43 -0000 On 1/4/2011 9:31 AM, Shawn Steele wrote: > Sorry for not being clearer, yes, I was thinking of Latin as the range of characters (after the Unicode name for 00-7f). Not strictly accurate (there're non-script things in 00-7F). Could also be misleading (since there are latin-x character sets), but I just threw it out since we seemed confused :) In fact the IETF use of the term "ASCII" usually is imprecise in the same way. The original term was "Network ASCII" as was defined for a Network Virtual Terminal. It is a subset of full ASCII. Interestingly, it is discussed at length in RFC 5198... However although the fine-grained details of this distinction are highly relevant for someone writing code they are almost never relevant to other discussions. I believe the same "permission" for being casual with the label "Latin" can reasonably apply here. Within a community that is conducting discussions on a topic, it is common, efficient and productive to use labels that are approximate rather than precise. Simplification is the essence of defining useful categories. The challenge is to make sure that the scope of the community is appropriate. So, for example, terminology that is specific to one working group but different from terms used in a related working group is almost certainly a bad idea. Terminology in one standards group that directly conflicts with that of another might also be problematic. Also, there is the potential -- and occasionally the reality -- that casualness in terminology masks sloppy thinking and sloppy specification. The group certainly needs to be careful in make its choices. The purpose behind the 2x2 matrix is to define a particular scope, between original Internet and international Internet. That's a constrained environment, but useful, environment. The constraint permits excluding quite a bit of related, but not essential, terminology and discussion. Speaking of related... I am increasingly developing the view that reference to "non-ASCII" should be rare and quite isolated. From the working group specifications and from postings on this list, it appears to be used as a synonym for Unicode or UTF-8. This can lead to the erroneous view that an all-ASCII string is not Unicode. While the presence of "non-ASCII" does indeed define data as Unicode, data containing only ASCII also can be Unicode. Hence a distinction such as "Latin" vs. "Unicode" needs to depend solely on an explicit label for the data and not depend upon inspecting the data before deciding on what label to use. If the group moves away from inspecting the data and then defining its type based on that inspection, and instead moves to explicit labeling, it will have very restricted need for referring to "non-ascii". For VRFY/EXPN, when a client declares it can support Unicode, the server does not have to worry about whether the responses contain ascii or non-ascii. When the client has not made this declaration, a server can reasonably deliver only responses that are ASCII. The only interesting case is when the server wants to provide Unicode strings that happen to be only ASCII. In this case, "non-ascii" does not mean "Unicode"; it means "a character that was not ASCII was found". But this is an extremely specific situation for the working group's specification; there are few others. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Tue Jan 4 10:16:56 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 BA0C93A6C50 for ; Tue, 4 Jan 2011 10:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNvi2E5dmvKF for ; Tue, 4 Jan 2011 10:16:56 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 116153A6C3C for ; Tue, 4 Jan 2011 10:16:56 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 4 Jan 2011 10:19:03 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.174]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Tue, 4 Jan 2011 10:19:01 -0800 From: Shawn Steele To: Dave CROCKER Thread-Topic: [EAI] Random thought on ASCII range Thread-Index: AcupF+V53djy5w7pS1ilQ7YHTFLyCwCSKd0AAA8nEgAAJet1cAASZWsAABC0LiA= Date: Tue, 4 Jan 2011 18:19:01 +0000 Message-ID: References: <4D21E9D4.1000201@dcrocker.net> <4D2363C2.5010606@bbiw.net> In-Reply-To: <4D2363C2.5010606@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 18:16:56 -0000 > I am increasingly developing the view that reference to "non-ASCII"=20 > should be rare and quite isolated. From the working group specifications > and from postings on this list, it appears to be used as a synonym for=20 > Unicode or UTF-8.=20 > This can lead to the erroneous view that an all-ASCII string is not Unico= de. Actually "non-ASCII" is used (in a very few places I think) to indicate the= characters >=3D U+0080. Eg: the characters that force the use of EAI and = which can't be used in legacy SMTP addresses. -Shawn From klensin@jck.com Tue Jan 4 11:07:51 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 83CE33A6BA7 for ; Tue, 4 Jan 2011 11:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, GB_I_LETTER=-2] 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 QnnPZOeOVdAp for ; Tue, 4 Jan 2011 11:07:50 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AF46A3A6A74 for ; Tue, 4 Jan 2011 11:07:49 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PaCGS-000ALU-AZ; Tue, 04 Jan 2011 14:09:48 -0500 Date: Tue, 04 Jan 2011 14:09:47 -0500 From: John C Klensin To: Shawn Steele , dcrocker@bbiw.net Message-ID: <597CE5A41EC31597499FFE13@PST.JCK.COM> In-Reply-To: References: <4D21E9D4.1000201@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] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:07:51 -0000 --On Tuesday, January 04, 2011 17:31 +0000 Shawn Steele wrote: > Sorry for not being clearer, yes, I was thinking of Latin as > the range of characters (after the Unicode name for 00-7f). > Not strictly accurate (there're non-script things in 00-7F). > Could also be misleading (since there are latin-x character > sets), but I just threw it out since we seemed confused :) Please, let's be _very_ careful about this. In Unicode-speak (at least most of the time), "Basic Latin" (the term you used) refers to a subset of the U+0000 to U+007F range. Which subset is actually not well-defined: the U+0000 to U+007F code block is titled "C0 Controls and Basic Latin". But the category groups within the code block are divided up as "C0 controls", "ASCII punctuation and symbols", "ASCII digits", "ASCII punctuation and symbols", "Uppercase Latin alphabet", "ASCII punctuation and symbols", "Lowercase Latin alphabet", "ASCII punctuation and symbols", and "Control character". There are two things that are important about this: the "ASCII punctuation and symbols" group is not contiguous -- an inconvenience, but probably not a problem-- and their explicit use of the term "ASCII" to describe parts of the range in that block in spite of the fact that the "ASCII repertoire" is the entire block, including the C0 controls and the odd, one-code-point title that Unicode assigns to U+007F. These titles are an editorial convenience in the Unicode definition; they are neither normative nor guaranteed to be stable, so, if we are going to depend on them, we probably need to reference a particular version of Unicode (not a good idea when avoidable, as several IETF activities have learned the hard way). Second, while you said "Basic Latin", Dave's revised chart said "Latin". In Unicode-speak, "Latin" refers to a script (or script family). That script, according to Section 7.1 of Unicode 5.0, includes the letters of Basic Latin and the Latin-1 supplement; the characters of Latin Extended-A, B, C, and D, Extended Additional, and Ligatures. It also includes the IPA and Phonetic Extensions, whose inclusion in "Latin" on any basis but derivation is debated by linguist and phoneticists. Again, while the block definitions (i.e., ranges of code points) are stable, there are no guarantees about the names. The list is, in principle, open-ended: new characters and new blocks could be added at any time. But, most excitingly, "Latin Script" (as in 7.1), does not include either the ASCII punctuation and symbols (a few of which, like period and hyphen and maybe space and "@" are important to EAI), nor does it include the so-called European digits (which are also important to EAI). >From a later note: > FWIW: I think that (since there's no IETF-wide definition), > that we should just "pick something" and make sure it's > clearly defined. The problem we've had seems to be more along > consistent use of the terms, I doubt we'll find a "perfect" > term that's obvious w/o defining it. Shawn, let me suggest a few guidelines, all of them derived from experience with IDNA, the development of the various JET and CDNC "variant" documents, ICANN's attempts to engage with IDNs and variants, and some closely-related work. Perhaps they will put the reasons I'm being careful (or resistant) into perspective. (0) While it implies risks and is not a strategy I prefer to advocate, we can often get away with informal uses of terms that are not precisely defined. When it is clear we are doing that, people can often figure out what is intended from context and get that right. While precise, formal, definitions are better than that sort of informal/contextual approach, formal definitions that are imprecise or that fail on one or more of the criteria below are usually even worse. (1) It is a bad idea to use the same term in different IETF specifications for two different things. Doing so causes people to skip over local definitions (even if they are present) and read things based on what they think the words mean. That, in turn, leads to trouble. When feasible, we should even avoid definitional conflicts with non-IETF-stream RFCs. (2) If Unicode uses a term, we should either use that term in exactly the same way they do or not use it at all. If they use a term, but use it inconsistently or ambiguously, we are better off avoiding it. (3) Borrowing a bit from an ICANN discussion, we should avoid affiliating ourselves with the Humpty Dumpty School of Philology, i.e., claiming that common words mean whatever we say they mean (but being willing to supply those definitions and being reasonably consistent about them). (4) Staying out of the Queen of Hearts School of Philology, in which words mean whatever one wants them to mean at the moment, with no obligation to explain the definitions, is even more important. That list has some obvious corollaries: -- If we are going to try to define terms that are likely to be picked up and used throughout the IETF, we need to either get the work out of EAI or make certain we look backward at IDNA, forward at the PRECIS work, and sideways at Unicode and whatever other i18n work may be coming in the IETF. -- If we are going to try to use common terms in a specific and precise way, it isn't going to be easy. -- If the WG is still committed to getting this work done quickly, and precise terminology is an objective (or requirement), then we are probably better off defining terms that are clearly EAI-specific (following the lead of Andrew's suggestion) rather than trying to sort out precise and usable definitions for terms in more common use. The alternative could easily hold us up for several months as authors waited while we tried to sort terminology, get agreement from other relevant groups within the IETF, etc. best, john From dcrocker@bbiw.net Tue Jan 4 11:19:00 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 C1ED03A6D20 for ; Tue, 4 Jan 2011 11:19:00 -0800 (PST) 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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fEX-v3zw0Yy for ; Tue, 4 Jan 2011 11:18:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 98F533A6A7C for ; Tue, 4 Jan 2011 11:18:59 -0800 (PST) Received: from [172.28.172.96] (12-198-124-226att-inc.com [12.198.124.226] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p04JKoSK026061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 11:20:57 -0800 Message-ID: <4D23730D.6040800@bbiw.net> Date: Tue, 04 Jan 2011 11:20:45 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Shawn Steele References: <4D21E9D4.1000201@dcrocker.net> <4D2363C2.5010606@bbiw.net> In-Reply-To: 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, 04 Jan 2011 11:20:58 -0800 (PST) Cc: "ima@ietf.org" Subject: Re: [EAI] Random thought on ASCII range X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:19:00 -0000 On 1/4/2011 10:19 AM, Shawn Steele wrote: >> I am increasingly developing the view that reference to "non-ASCII" should >> be rare and quite isolated. From the working group specifications and from >> postings on this list, it appears to be used as a synonym for Unicode or >> UTF-8. This can lead to the erroneous view that an all-ASCII string is not >> Unicode. > > Actually "non-ASCII" is used (in a very few places I think) to indicate the > characters>= U+0080. Eg: the characters that force the use of EAI and which > can't be used in legacy SMTP addresses. And my point is that the "force the use" reference is an example of having the label derived from the data, rather than have the label /dictate/ the data. It's not that the derivation is wrong; it is that it is limiting. In each of the places that the language does this sort of "force the use of EAI" perspective is document, the group should consider whether it is, instead, possible to have the language be strictly in terms of a Latin-vs-Unicode "mode". A specific benefit of this will be to permit all-ASCII to be classed as Unicode rather than Latin. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chl@clerew.man.ac.uk Wed Jan 5 03:46:27 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 41B6A3A6E12 for ; Wed, 5 Jan 2011 03:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.814 X-Spam-Level: X-Spam-Status: No, score=-3.814 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 P9HWUVuJzUbJ for ; Wed, 5 Jan 2011 03:46:25 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 9C7BB3A6CD5 for ; Wed, 5 Jan 2011 03:46:24 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 91D3922136 for ; Wed, 5 Jan 2011 11:48:30 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Wed, 05 Jan 2011 11:48:30 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p05BmTtq003343 for ; Wed, 5 Jan 2011 11:48:30 GMT Date: Wed, 05 Jan 2011 11:48:29 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <68655A9F86D4BE7ED933F8A6@192.168.1.128> <4D192FF8.1030706@dcrocker.net> <9B48F59821946F2EA2DCDEA0@192.168.1.128> <4D19623F.3040804@dcrocker.net> <61939C011F6BB4A93749804C@192.168.1.128> <0D625A27294258D00E95152A@[192.168.1.128]> <4D1AD148.7070000@dcrocker.net> <88B011BD899484DA740CE0BA@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <88B011BD899484DA740CE0BA@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d245a8e.161e-1c78-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Representation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:46:27 -0000 On Tue, 04 Jan 2011 05:04:45 -0000, John C Klensin wrote: > --On Thursday, December 30, 2010 10:40 +0000 Charles Lindsey > wrote: >> E.g., a is A is a "proper subset" of B, then A is not >> identical to B. >> >> So something like "proper-utf8" would follow that concention. >> You might even use "PROPER_UTF8" as that parameter of the MAIL >> command. > > At one level, harking back to the years when I pretended to be a > mathematician (or at least an aspiring one), this really appeals > to me. At another, I believe that "proper utf-8" (no matter how > punctuated) will be read by most non-mathematicians and even > some mathematicians who haven't been alerted to the special > usage) as the opposite of "improper UTF-8" or "invalid UTF-8". > Yes, I was a bit worried about that. So how about "UTF8_PROPER". -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Wed Jan 5 03:52:41 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 A7B7C3A6E1F for ; Wed, 5 Jan 2011 03:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.868 X-Spam-Level: X-Spam-Status: No, score=-3.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qE9GLyVHpO3q for ; Wed, 5 Jan 2011 03:52:40 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 544C53A6D3C for ; Wed, 5 Jan 2011 03:52:38 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id B34C922137 for ; Wed, 5 Jan 2011 11:54:43 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Wed, 05 Jan 2011 11:54:43 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p05BsgxV003718 for ; Wed, 5 Jan 2011 11:54:43 GMT Date: Wed, 05 Jan 2011 11:54:42 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <20110103153128.77099.qmail@joyce.lan> <4D21EF8F.8060007@dcrocker.net> <58840212.20110103085213@pobox.com> <01NW6KZQLDRQ007FL5@mauve.mrochek.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <01NW6KZQLDRQ007FL5@mauve.mrochek.com> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d245c03.109c3-1e6f-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] non-EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:52:41 -0000 On Mon, 03 Jan 2011 17:31:54 -0000, wrote: >> On Mon, 2011-01-03, Dave CROCKER wrote: >> I fear the only clean solution is both a session state setting command >> and >> a per-transaction flag. > > Actually, while a session flag solution for VRFY/EXPN is nowhere near as > sucky > as it is for MAIL FROM, it's not the cleanest solution either. The > problematic > case would be some sort of lookup proxy, where sometimes the operation > being > performed is amendable to a utf-8 return value and sometimes it is not. > Such an > agent would have essentially the same issue with global state complexity. +1. I think session flags are a Bad Thing in themselves, and would much prefer to cover the VRFY/EXPN case with some UTF* parameter for that command (indeed, we could allow that parameter for ALL commands, though MAIL/VRFY/EXPN are the obvious beeficiaries). Note that a client MUST NOT send that parameter unless it is aware, from and earlier EHLO, that it is allowed. I think that solution was gaining consensus in John's recent poll. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From klensin@jck.com Wed Jan 5 18:47:44 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 1F33D3A6DD5 for ; Wed, 5 Jan 2011 18:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyB0l-RlqsVm for ; Wed, 5 Jan 2011 18:47:43 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 0489A3A67E3 for ; Wed, 5 Jan 2011 18:47:43 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PafvB-000NtU-J8 for ima@ietf.org; Wed, 05 Jan 2011 21:49:49 -0500 Date: Wed, 05 Jan 2011 21:49:49 -0500 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Consensus-determining procedures X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:47:44 -0000 (writing as co-chair) Hi. In the interest of full disclosure and avoidance of surprises... Joseph, Alexey, and I had a discussion about how to organize consensus calls on the many issues that have been brought up by reviewers or by the responses to those reviews. We concluded that, since I've been much more actively involved in the discussions, have written a review response, and have taken positions on several issues, Joseph will make the final decisions about consensus calls (in terms of questions to be asked), ask the questions, and evaluate the results. I provided him (and the design/author team) a preliminary list of draft questions, but he will need to add additional questions and is free to use my list (or not use it) in whatever way he finds appropriate. I've also given him two pieces of advice which, again, he can ignore if he is so inclined: (1) That he check proposed text with the author group in the hope of saving the WG time. That proposed text isn't about answers, just draft questions. (2) That he try to get agreement, and call consensus as appropriate, on broad issues before trying to lock down the details. For example, we decide whether we really need a parameter on the MAIL command before trying to formally reach consensus on what that parameter should be called, whether it has values, etc. best, john p.s. for those who joined the WG list since this was last mentioned, there is a separate mailing list to which all document authors have been invited to subscribe (at least one author is subscribed for each document) and which also includes the co-chairs, secretary, and both ADs. It is variously referred to as the design team list (which is how it started, long ago) or the author list, but really serves a coordination function rather than a design or equivalent one. It obeys all of the usual constraints for a standing design team list, with the additional constraint that it has retired from design and hence isn't even trying to guide or offer options to the WG from a design standpoint. I don't believe its existence should affect the WG in any significant way, but wanted to be sure (again) that it wasn't a secret either. From yaojk@cnnic.cn Wed Jan 5 19:47:53 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 6394F3A6896 for ; Wed, 5 Jan 2011 19:47:53 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.209 X-Spam-Level: X-Spam-Status: No, score=-98.209 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up1LbxFn33Z1 for ; Wed, 5 Jan 2011 19:47:52 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 9E3143A67E2 for ; Wed, 5 Jan 2011 19:47:51 -0800 (PST) Received: (eyou send program); Thu, 06 Jan 2011 11:49:58 +0800 Message-ID: <494285798.29850@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, 06 Jan 2011 11:49:58 +0800 Message-ID: <47EA0DC5AC724C6381C1F5D04F954C8C@LENOVO47E041CF> From: "Jiankang YAO" To: References: <493053984.00826@cnnic.cn> Date: Thu, 6 Jan 2011 11:50:00 +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: [EAI] MAY transmit mailbox names X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 03:47:53 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJEYXZlIENST0NLRVIiIDxkaGNA ZGNyb2NrZXIubmV0Pg0KVG86ICJBcHBzIERpc2N1c3MiIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+ OyA8aW1hQGlldGYub3JnPjsgPGRyYWZ0LWlldGYtZWFpLXJmYzUzMzZiaXNAdG9vbHMuaWV0Zi5v cmc+OyAiU00iIDxzbStpZXRmQGVsYW5kc3lzLmNvbT47IDxBbGV4ZXkuTWVsbmlrb3ZAaXNvZGUu Y29tPg0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIzLCAyMDEwIDI6MDQgQU0NClN1YmplY3Q6 IFtFQUldIFthcHBzLWRpc2N1c3NdIChwcml2YXRlKSBkcmFmdCByZXZpZXdvZjogZHJhZnQtaWV0 Zi1lYWktcmZjNTMzNmJpcy0wNy50eHQgKHYzKQ0KLi4uIA0KPiANCj4+IEFuIFNNVFAgY2xpZW50 IHRoYXQgcmVjZWl2ZXMgdGhlIFVURjhTTVRQYmlzIGV4dGVuc2lvbiBrZXl3b3JkIGluIHJlc3Bv bnNlDQo+PiB0byB0aGUgRUhMTyBjb21tYW5kIE1BWSB0cmFuc21pdCBtYWlsYm94IG5hbWVzIHdp dGhpbiBTTVRQIGNvbW1hbmRzIGFzDQo+PiBpbnRlcm5hdGlvbmFsaXplZCBzdHJpbmdzIGluIFVU Ri04IGZvcm0uICBJdCBNQVkgc2VuZCBhIFVURi04IGhlYWRlcg0KPj4gW1JGQzUzMzViaXNdICh3 aGljaCBtYXkgYWxzbyBpbmNsdWRlIG1haWxib3ggbmFtZXMgaW4gVVRGLTgpLiAgSXQgTUFZDQo+ PiB0cmFuc21pdCB0aGUgZG9tYWluIHBhcnRzIG9mIG1haWxib3ggbmFtZXMgd2l0aGluIFNNVFAg Y29tbWFuZHMgb3IgdGhlDQo+PiBtZXNzYWdlIGhlYWRlciBhcyBBLWxhYmVscyBvciBVLWxhYmVs cw0KPiANCj4geyBJIGJlbGlldmUgdGhhdCB0aGUgdXNlIG9mICJNQVkiIGlzIG5vdCBjb3JyZWN0 LiBUaGlzIHdvdWxkIG1lYW4gdGhhdCB0aGUgDQo+IHJlY2VpdmVyIG5lZWRzIGEgbWVhbnMgb2Yg ZGlzdGluZ3Vpc2hpbmcgd2hldGhlciB0aGUgZGF0YSBhcmUgVVRGLTggb3Igbm90LiBUaGlzIA0K PiB3b3VsZCBib3JkZXIgb24gcmVxdWlyaW5nIHN1cHBvcnQgb2YgYSBoZXVyaXN0aWMsIGJ1dCBp dCBjZXJ0YWlubHkgYWRkcyBhIA0KPiBzaWduaWZpY2FudCBwcm9jZXNzaW5nIG92ZXJoZWFkIGFu ZCBhZGRpdGlvbmFsIHNvZnR3YXJlIGNvbXBsZXhpdHkuDQo+IA0KPiBUaGUgb25seSBhbHRlcm5h dGl2ZSBpcyB0byBzcGVjaWZ5IHVzZSBvZiBhIE1BSUwgY29tbWFuZCA8TWFpbC1wYXJhbWV0ZXJz PiANCj4gb3B0aW9uIHRoYXQgZGVjbGFyZXMgdGhhdCB0aGUgbWVzc2FnZSBzdXBwb3J0cyBpbnRl cm5hdGlvbmFsaXplZCBhZGRyZXNzZXMuIA0KPiBHaXZlbiB0aGUgYXBwcm9hY2ggaW4gdGhpcyBz cGVjaWZpY2F0aW9uLCBJIGJlbGlldmUgdGhlIGludGVudCBpcyBhbHNvIHRvIGhhdmUgDQo+IGl0 IG1lYW4gdGhhdCBVVEYtOCBlbmNvZGluZyBpcyBzdXBwb3J0ZWQuDQo+IA0KPiBUaGUgY29yZSBp c3N1ZSBoZXJlIGlzIHNwZWNpZnlpbmcgYW4gb3B0aW9uIHdoaWNoIGRlY2xhcmVzIGEgbWVzc2Fn ZSB0byBoYXZlIGFuIA0KPiBFQUkgY29udGV4dCBmb3IgYWxsIG9mIHRoZSBtZXNzYWdlLiAgU28g dGhlIHByb2Nlc3NpbmcgY29udGV4dCBpcyBmdWxseSANCj4gRUFJL1VURi04IG9yIGl0IGlzIGxl Z2FjeSBuZXQtQVNDSUkuICBUaGlzIGlzIGNvbnNpZGVyYWJseSBzaW1wbGVyIHRvIHNwZWNpZnkg DQo+IGFuZCB0byBwcm9jZXNzLCB0aGFuIHdvdWxkIGJlIHJlcXVpcmluZyBwYXJzaW5nIHRoZSBp bmNvbWluZyBzdHJpbmcgYW5kIGxvb2tpbmcgDQo+IGZvciBub24tQVNDSUkgVVRGLTguDQo+IA0K PiBIZW5jZTogfQ0KPiANCj4gICAgICBBbiBTTVRQIGNsaWVudC4uLlUtbGFiZWxzDQo+ICAgICAg LT4NCj4gICAgICBBbiBTTVRQIGNsaWVudCB0aGF0IHJlY2VpdmVzIHRoZSBVVEY4U01UUGJpcyBl eHRlbnNpb24ga2V5d29yZCwgaW4gcmVzcG9uc2UgdG8NCj4gdGhlIEVITE8gY29tbWFuZCwgd2ls bCB0cmFuc21pdCA8bG9jYWwtcGFydD4gd2l0aGluIFNNVFAgY29tbWFuZHMgYXMNCj4gaW50ZXJu YXRpb25hbGl6ZWQgc3RyaW5ncyBpbiBVVEYtOCBmb3JtLiAgSXQgd2lsbCBzZW5kIHRoZSBlbWFp bCBoZWFkZXIgaW4gVVRGLTgNCj4gW1JGQzUzMzViaXNdICh3aGljaCBjYW4gYWxzbyBpbmNsdWRl IDxtYWlsYm94PiBuYW1lcyBpbiBVVEYtOC4pICBJdCBhbHNvIHdpbGwNCj4gdHJhbnNtaXQgdGhl IGRvbWFpbiBwYXJ0cyBvZiBtYWlsYm94IG5hbWVzIHdpdGhpbiBTTVRQIGNvbW1hbmRzIG9yIHRo ZSBtZXNzYWdlDQo+IGhlYWRlciBhcyBBLWxhYmVscyBvciBVLWxhYmVscw0KPiANCg0KdGhhbmtz IGZvciB5b3VyIGtpbmQgY29tbWVudHMuDQoNCmhlcmUsIHlvdSBzdWdnZXN0IHRvIGNoYW5nZSAi TUFZIHRyYW5zbWl0ICIgdG8gIndpbGwgdHJhbnNtaXQgIi4NCg0KbXkgdW5kZXJzdGFuZGluZyBp cyB0aGF0IHRoZSBlYWktYXdhcmUgc210cCBjbGllbnQgaGFzIHR3byBjaG9pY2VzIHdoZW4gcmVj ZWl2aW5nIHRoZSAgVVRGOFNNVFBiaXMgZXh0ZW5zaW9uIGtleXdvcmQ6DQoxLiBzZW5kaW5nIHRo ZSBsZWdhY3kgbWFpbA0KMi4gc2VuZGluZyB0aGUgdXRmOHNtdHAgbWFpbA0KDQppZiB3ZSB1c2Ug Ik1BWXRyYW5zbWl0ICIsIGl0ICBpbmRpY2F0ZXMgdGhhdCB0aGUgZWFpLWF3YXJlIHNtdHAgY2xp ZW50IGhhcyB0d28gY2hvaWNlcyB3aGVuIHJlY2VpdmluZyB0aGUgIFVURjhTTVRQYmlzIGV4dGVu c2lvbiBrZXl3b3JkOg0KMS4gc2VuZGluZyB0aGUgbGVnYWN5IG1haWwNCjIuIHNlbmRpbmcgdGhl IHV0ZjhzbXRwIG1haWwNCg0KDQppZiB3ZSB1c2UgIndpbGwgdHJhbnNtaXQgIiwgaXQgbWF5IGlu ZGljYXRlIHRoYXQgdGhlIGVhaS1hd2FyZSBzbXRwIGNsaWVudCBoYXMgb25seSBvbmUgY2hvaWNl IHdoZW4gcmVjZWl2aW5nIHRoZSAgVVRGOFNNVFBiaXMgZXh0ZW5zaW9uIGtleXdvcmQ6DQoxLiBz ZW5kaW5nIHRoZSB1dGY4c210cCBtYWlsDQpidXQgdGhlIHVzZXIgbWF5IHN0aWxsIHRyeSB0byBz ZW5kIHRoZSBsZWdhY3kgbWFpbC4NCg0KaXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KDQpK aWFua2FuZyBZYW8NCg0KDQoNCg0KDQoNCg0K From jyee@ca.afilias.info Wed Jan 5 23:41:00 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 666B53A6EFE for ; Wed, 5 Jan 2011 23:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.995 X-Spam-Level: X-Spam-Status: No, score=-105.995 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa+cS7beBsa9 for ; Wed, 5 Jan 2011 23:40:59 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 4C55F3A6BAD for ; Wed, 5 Jan 2011 23:40:59 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 02:43:04 -0500 Message-Id: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 07:41:00 -0000 Hi all, Recent reviews raised some concerns and the WG had discussions on = various issues including negotiation mechanism, protocol logic, = terminologies, document style, etc. =20 As John mentioned in separate email; John, Alexey and I had discussion = on how to organize consensus calls. And before heading to consensus = call, we will confirm with the WG on the set of questions. Once the set = confirmed, we will proceed in discussion on each topic and will evaluate = the results. (1) Should the WG add parameter on MAIL FROM to start EAI transaction and = avoid the need for deep inspection? (2) Should the parameter be permitted only if VRFY or EXPN appears = subsequent to an EHLO response that includes UTF8SMTPbis? (3) Should the WG remove repetition of normative text from other documents = to the extent possible. Incorporate by reference and, where necessary, = note explicitly that tutorial / context-providing references are not = normative. If the WG remove the repetition of normative text, will it make the = draft hard to read? If not, are there any text in current draft may = result in inaccurate or confusing information because by update of other = RFCs? (4) Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" = with new or different term s that precisely and accurately identify what = is intended? (5) Should the WG add additional text for gateways? (6) Should the WG add additional text for ticket systems that interface with = email address, internationalized string, log, and traces? (7) Should the WG keep the decision about nested encodings and the use of = message/global as described in RFC5336 and RFC5336bis? Or is a different = model needed? (8) Once errors are corrected, is the current metalanguage model (including = the 'u' prefixes) acceptable? If not, should only those rules be = included that are modified from RFC 5321 or 5322 respectively, forcing = the user to reference the original documents for parts of substantially = every rule? ------- Note: Issues (5) and (6) were extracted from review composed by Claudio = Allocchio and there are lack of discussion on them. For more details, = please refer to Claudio's review = (http://www.ietf.org/mail-archive/web/ima/current/msg03621.html) I am also working on the issue tracker, and will send out the track = number as soon as possible for questions agreed by the WG. Regards, Joseph, co chair of EAI= From yaojk@cnnic.cn Fri Jan 7 01:27:17 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 BD90D3A67F4 for ; Fri, 7 Jan 2011 01:27:16 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.474 X-Spam-Level: X-Spam-Status: No, score=-99.474 tagged_above=-999 required=5 tests=[AWL=0.569, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQqIW40Gtd0s for ; Fri, 7 Jan 2011 01:27:15 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 97A7F3A67EE for ; Fri, 7 Jan 2011 01:27:14 -0800 (PST) Received: (eyou send program); Fri, 07 Jan 2011 17:29:18 +0800 Message-ID: <494392558.18256@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, 07 Jan 2011 17:29:18 +0800 Message-ID: <302AA5E7CE314086AB65C61425470BDE@LENOVO47E041CF> From: "Jiankang YAO" To: References: <493041112.16848@cnnic.cn> Date: Fri, 7 Jan 2011 17:29: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.5994 Cc: ima@ietf.org Subject: [EAI] utf8 reply in RCPT Commands 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, 07 Jan 2011 09:27:17 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo Y0BkY3JvY2tlci5uZXQ+DQpUbzogIkFwcHMgRGlzY3VzcyIgPGFwcHMtZGlzY3Vzc0BpZXRmLm9y Zz47IDxpbWFAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1lYWktcmZjNTMzNmJpc0B0b29scy5pZXRm Lm9yZz47ICJTTSIgPHNtK2lldGZAZWxhbmRzeXMuY29tPjsgPEFsZXhleS5NZWxuaWtvdkBpc29k ZS5jb20+DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjMsIDIwMTAgMjowNCBBTQ0KU3ViamVj dDogW0VBSV0gKHByaXZhdGUpIGRyYWZ0IHJldmlldyBvZjogZHJhZnQtaWV0Zi1lYWktcmZjNTMz NmJpcy0wNy50eHQodjMpDQoNCg0KPiANCi4uLg0KPiANCj4gDQoNCj4+IDMuNi40LiAgVVRGLTgg U3RyaW5ncyBpbiBSZXBsaWVzDQo+Pg0KPj4gMy42LjQuMS4gIFJDUFQgQ29tbWFuZHMNCj4+DQo+ PiBJZiBhbiBTTVRQIGNsaWVudCBmb2xsb3dzIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgc2VuZHMg YW55IFJDUFQgY29tbWFuZHMNCj4+IGNvbnRhaW5pbmcgbm9uLUFTQ0lJIGFkZHJlc3NlcywgdGhl IFNNVFAgc2VydmVyIGlzIHBlcm1pdHRlZCB0byB1c2UgVVRGLTgNCj4+IGNoYXJhY3RlcnMgaW4g dGhlIGVtYWlsIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIDI1MSBhbmQgNTUxIHJlc3BvbnNlIGNv ZGVzLA0KPj4gYW5kIHRoZSBjbGllbnQgTVVTVCBiZSBhYmxlIHRvIGFjY2VwdCBhbmQgcHJvY2Vz cyB0aGVtLg0KPiANCj4geyBJIGFzc3VtZSB0aGF0ICJmb2xsb3dzIHRoaXMgc3BlY2lmaWNhdGlv biIgbWVhbnMgdGhhdCB0aGUgVVRGOFNNVFBiaXMgb3B0aW9uIA0KPiBpcyBpbiBmb3JjZS4gIElm IHNvLCB0aGVuIHNheSB0aGF0LCBiZWNhdXNlIGl0IGlzIHNpbXBsZXIgYW5kIG1vcmUgcHJlY2lz ZS4gQnV0LCANCj4gdGhlbiwgaXQgZG9lcyByZXF1aXJlIGRlY2xhcmluZyAvdXNlLyBvZiB0aGUg b3B0aW9uLi4uDQo+IA0KPiBIb3dldmVyIHRoZSBtZWFuaW5nIG9mIHRoZSB0ZXh0IGhlcmUgaXMg b2RkLiAgSXQgaW1wbGllcyB0aGF0IHRoZSBzZXJ2ZXIgaXMgbm90IA0KPiBwZXJtaXR0ZWQgdG8g dXNlIFVURi04IHVubGVzcyBpdCBoYXMgYWxyZWFkeSByZWNlaXZlZCBVVEYtOCwgZXZlbiB0aG91 Z2ggdGhlIA0KPiBvcHRpb24gaXMgaW4gZm9yY2UuICBJIHN1c3BlY3QgdGhhdCB0aGF0IGlzIG5v dCB0aGUgc3BlY2lmaWNhdGlvbiB0aGF0IGlzIA0KPiBpbnRlbmRlZC4gIE9yLCBhdCBsZWFzdCwg SSBob3BlIGl0IGlzIG5vdC4NCj4gDQo+IElmIGl0IGFjdHVhbGx5IC9pcy8gd2hhdCBpcyBpbnRl bmRlZCwgaXQgbWVhbnMgdGhhdCB0aGUgZW5oYW5jZWQgZW52aXJvbm1lbnQgaXMgDQo+IGdvaW5n IHRvIGhhdmUgYWxsIHNvcnRzIG9mIC9hZGRpdGlvbmFsLyBjb25kaXRpb25hbCBjb2RlLCB0byBj aGVjayBvbiB3aGV0aGVyIGEgDQo+IHNwZWNpZmljIGNvbnRleHQgaW4gdGhlIHN0YXRlIG1hY2hp bmUgaXMgYWxsb3dlZCB0byBhY3QgaW4gb25lIHdheSBvciBhbm90aGVyLg0KPiANCj4gVGhlIHNp bXBsZSBhbmQgbW9yZSByZWFzb25hYmxlIG1vZGVsIGlzIHRoYXQgd2hlbiB0aGUgZXh0ZW5zaW9u IGlzIGluIGZvcmNlLCANCj4gVVRGLTggaXMgYWxsb3dlZC4gIFBlcmlvZC4gIFNvLi4uIH0NCj4g DQo+ICAgICAgSWYgYW4gU01UUCBzZXNzaW9uIGlzIHVzaW5nIHRoaXMgZXh0ZW5zaW9uLCB0aGVu IHRoZSBzZXJ2ZXIgaXMgcGVybWl0dGVkIA0KPiB0byB1c2UgVVRGLTggY2hhcmFjdGVycyBpbiB0 aGUgZW1haWwgYWRkcmVzcyBhc3NvY2lhdGVkIHdpdGggMjUxIGFuZCA1NTEgDQo+IHJlcGx5LWNv ZGVzLCBhbmQgdGhlIGNsaWVudCBNVVNUIGJlIGFibGUgdG8gYWNjZXB0IGFuZCBwcm9jZXNzIHRo ZW0uDQo+IA0KPg0KDQpUaGVyZSBhcmUgdHdvIGtpbmRzIG9mIGNhc2VzIHdoZW4gdGhlIGNsaWVu dCByZWNlaXZlcyB0aGUgdXRmOHNtdHAgZWhsbyB3b3JkIGFuZCBidWlsZHMgYSBzbXRwIHNlc3Np b246DQoNCjEpIGVhaS1zbXRwLWNsaWVudC0tLS0+ZWFpLXNtdHAtc2VydmVyDQoyKSBub24tZWFp LXNtdHAtY2xpZW50LS0tLT5lYWktc210cC1zZXJ2ZXINCg0KZm9yIHRoZSBjYXNlIDEpLCBib3Ro IHRoZSBvcmlnaW5hbCB0ZXh0IGFuZCB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGFib3ZlIGFyZSBvay4N CmZvciB0aGUgY2FzZSAyKSwgdGhlIGVhaS1zbXRwLXNlcnZlciBtdXN0IG5vdCBzZW5kIHRoZSB0 ZXh0IHRvIG5vbi1lYWktc210cC1jbGllbnQuDQoNCnRoZSBvcmlnaW5hbCB0ZXh0IGludGVudGlv bmFsbHkgZXhjbHVkZXMgdGhlIGNhc2UgMikuDQoNCnlvdXIgc3VnZ2VzdGVkIHRleHQgc2VlbXMg dG8gc3RpbGwgaW5jbHVkZSB0aGUgY2FzZSAyKS4NCg0KYnV0IGZvciB0aGUgY2FzZSAyKSwgdGhl IGNsaWVudCBjYW4gbm90IGFjY2VwdCB0aGUgdXRmOCBtZXNzYWdlIHNpbmNlIGl0IGlzIG5vbi1l YWktc210cC4NCg0Kd2hhdCBpcyB5b3VyIHZpZXc/DQoNCnRoYW5rcyBhIGxvdC4NCg0KSmlhbmth bmcgWWFvDQoNCg0KDQoNCg0KPg0KPg0KPiB7IEkgY2hvc2UgIlNNVFAgc2Vzc2lvbiIgdG8gYXZv aWQgdGhlIG1vcmUgY29tcGxleCBkaXNjdXNzaW9uIG9mIHRoZSANCj4gY2xpZW50L3NlcnZlciAn bmVnb3RpYXRpb24nIGFib3V0IHVzaW5nIHRoZSBleHRlbnNpb24uICBTbywgaGVyZSBpdCBpcyBl aXRoZXIgaW4gDQo+IGZvcmNlIG9yIGl0IGlzbid0IGFuZCBpZiBpdCBpcyBpbiBmb3JjZSwgaXQg aXMgZm9yIGNsaWVudCBBTkQgc2VydmVyLiB9DQo+IA0KPiANCj4+ICAgICAgSWYgYSBnaXZlbiBS Q1BUDQo+PiBjb21tYW5kIGRvZXMgbm90IGluY2x1ZGUgYSBub24tQVNDSUkgZW52ZWxvcGUgYWRk cmVzcywgdGhlIHNlcnZlciBNVVNUIE5PVA0KPj4gcmV0dXJuIGEgMjUxIG9yIDU1MSByZXNwb25z ZSBjb250YWluaW5nIGEgbm9uLUFTQ0lJIG1haWxib3guICBJbnN0ZWFkLCBpdA0KPj4gTVVTVCB0 cmFuc2Zvcm0gc3VjaCByZXNwb25zZXMgaW50byAyNTAgb3IgNTUwIHJlc3BvbnNlcyB0aGF0IGRv IG5vdCBjb250YWluDQo+PiBub24tQVNDSUkgYWRkcmVzc2VzLg0KPiANCj4geyAgU2VlIGFib3Zl LiAgSSB2ZXJ5IHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggaGF2aW5nIHRoZSBjb21wbGV4aXR5IHRo aXMga2luZCBvZiANCj4gY29uZGl0aW9uYWwgcmVxdWlyZW1lbnQgY3JlYXRlcy4gIE9yIGVsc2Ug dGhlcmUgaXMgYSBiYXNpYyBpc3N1ZSBpbnZvbHZlZCBoZXJlIA0KPiB0aGF0IHRoZSBkb2N1bWVu dCBkb2VzIG5vdCBkaXNjdXNzIGJ1dCBuZWVkcyB0bywgdG8ganVzdGlmeSB0aGUgY29tcGxleGl0 eS4gfQ0KPiANCj4gDQo= From barryleiba.mailing.lists@gmail.com Fri Jan 7 13:06:52 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 57DF43A6945 for ; Fri, 7 Jan 2011 13:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, 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 6qHbJ6EBKV6a for ; Fri, 7 Jan 2011 13:06:51 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 02C503A6832 for ; Fri, 7 Jan 2011 13:06:50 -0800 (PST) Received: by iwn40 with SMTP id 40so18679802iwn.31 for ; Fri, 07 Jan 2011 13:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=1b3deNPtAIb/TErC7lClx0tWlGYY4wrNRPQu5z4hhYc=; b=afgZZplKom3P9kq4jdwk1PeVwAtOto4TRn6v8GrCUDPgtLwB25MIwFbj82x/s0p4vV 0oWYvBq0S09czx/GqV2qACf2J7oUzPzF6Aitk2YHB7hFT5KrRsfctUkMUP5fnv1jRwee BExC8mlqdHHHou012zkIAjfYFz6uZ5DyUhEj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=CAjxwV8CXHCtTR/KjJ1g57aCWlL6GGq2JQbkjEBZ26/GMhTYibiCkbxZiN3klg1rLT 5SSvaC+a344b5TvOZwjT++/uNXi2ChKn4gV5veeALOBf9OqU99ZtvS1KqBrlkS9F7HWt a8haojfGnNZqiWAMz1aZ9ulZTSozNPgjffw/U= MIME-Version: 1.0 Received: by 10.42.174.198 with SMTP id w6mr1346286icz.281.1294434537332; Fri, 07 Jan 2011 13:08:57 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.240.2 with HTTP; Fri, 7 Jan 2011 13:08:57 -0800 (PST) In-Reply-To: References: <68655A9F86D4BE7ED933F8A6@192.168.1.128> <4D192FF8.1030706@dcrocker.net> <9B48F59821946F2EA2DCDEA0@192.168.1.128> <4D19623F.3040804@dcrocker.net> <61939C011F6BB4A93749804C@192.168.1.128> <0D625A27294258D00E95152A@192.168.1.128> <4D1AD148.7070000@dcrocker.net> Date: Fri, 7 Jan 2011 16:08:57 -0500 X-Google-Sender-Auth: ntwg72eoEFSUKEv891HWZpCx_K0 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: dcrocker@bbiw.net, ima@ietf.org Subject: Re: [EAI] Unicode vs. UTF-8 / Encoding vs. Representation 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, 07 Jan 2011 21:06:52 -0000 I've been watching the discussion about this and thinking about it myself, weighing the arguments everyone's been giving. And I've decided it's time to step in and give my own opinion. I think it's very important to make the distinction between characters ("Unicode") and encoding ("UTF-8"), and to (1) be rigorous in the documents about using the terms we choose, and (2) choose our terms and define them clearly. I'm sympathetic to the arguments about what's been used, misused, and inconsistently used in the past. I'm sympathetic to the arguments about trying to define terms in this document, given that the definitions are needed more broadly, that people can't be depended upon to read and understand *our* versions of the terms, and so on. Nevertheless, I think it's what we have to do. I don't much care whether we choose (1) "Latin" characters and "ASCII" encoding, (2) "ASCII" characters and "7-bit" encoding (which is defined in RFC 2045 in a way that I think is adequate and e-mail-related), or (3) something else. What I care about is that we settle on something, define what we mean clearly, and move these documents forward without too much more delay. I also think it's important to maintain the concept of a string that contains characters that are not in the ASCII character set (what we've been calling "non-ASCII"). I think we can limit the use of the term we choose for that to the "characters" side of things (and not use it for the "encoding" side). For example, we might say (contrived example, just to make the point) "a string that contains non-ASCII characters [or non-Latin characters, or whatever] MUST be encoded with UTF-8 encoding. Finally, I think that in order to make things absolutely clear, we NEVER use the word "character" when we refer to encoding, and we ALWAYS use the word "encoding" and treat "ASCII" or "7-bit" or "UTF-8" as a modifier, not as a noun (in other words, we NEVER say just "UTF-8", but ALWAYS "UTF-8 encoding"). I am willing (eager, I might even say) to draft a document section that does the definitions, to give us something specific to talk about. I'll wait until someone appropriate tells me to go ahead with that before I do it. But I think that if we have definition text to talk about, and if we take the approach that we need to do this as well as we reasonably can, but understand the futility of expecting perfection, we can get this settled and move ahead. Barry From dhc2@dcrocker.net Sat Jan 8 13:38:51 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 AB2113A683E for ; Sat, 8 Jan 2011 13:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB+JPEmCvxEd for ; Sat, 8 Jan 2011 13:38:50 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id B29EF3A6831 for ; Sat, 8 Jan 2011 13:38:50 -0800 (PST) Received: from [192.168.1.117] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p08Leopq010452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 8 Jan 2011 13:40:55 -0800 Message-ID: <4D28D9DE.60309@dcrocker.net> Date: Sat, 08 Jan 2011 13:40:46 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jiankang YAO References: <493041112.16848@cnnic.cn> <494392558.18256@cnnic.cn> In-Reply-To: <494392558.18256@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]); Sat, 08 Jan 2011 13:40:56 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] utf8 reply in RCPT Commands X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Jan 2011 21:38:51 -0000 On 1/7/2011 1:29 AM, Jiankang YAO wrote: > There are two kinds of cases when the client receives the utf8smtp ehlo word and builds a smtp session: > > 1) eai-smtp-client---->eai-smtp-server > 2) non-eai-smtp-client---->eai-smtp-server > > for the case 1), both the original text and your suggested text above are ok. > for the case 2), the eai-smtp-server must not send the text to non-eai-smtp-client. > > the original text intentionally excludes the case 2). > > your suggested text seems to still include the case 2). Jiankang, Thank you for the follow-up. I certainly admit to my having been confused about this part of the specification. Yours and other's comments have clarified this. To start with a basic point of agreement: An EAI server must not send UTF-8 data to a non-EAI client. Any discussion therefore needs to be based on this absolute requirement, and I definitely did not mean to suggest that the rule be violated. (There is also the requirement that an EAI client must not send UTF-8 data to a non-EAI server, but the proposed SMTP extension keyword solves that problem is the simple, usual way.) The current specification is based on the idea that the server can treat a client as supporting UTF-8 if the server receives UTF-8 message or address data. This requires inspecting address strings, for VRFY and EXPN, for example. (The client is not permitted to send UTF-8 unless is sees that the server can support it.) Hence, the client/server interaction moves from ASCII to UTF-8 as an artifact of some address data representation. This kind of protocol characteristic often has limitations and side-effects that are undesirable. The alternative that has been suggested is to have the client add an explicit parameter to declare use of UTF-8. This is a much more clean and common approach for switching "modes" in a protocol exchange. I think the relatively appropriate approach is the simple and usual method of adding a parameter to MAIL, EXPN and VRFY. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sat Jan 8 13:50:16 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 ABB3D3A68B9 for ; Sat, 8 Jan 2011 13:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk0T9B1EL7co for ; Sat, 8 Jan 2011 13:50:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id C84063A6878 for ; Sat, 8 Jan 2011 13:50:14 -0800 (PST) Received: from [192.168.1.117] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p08LpvtA010689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 8 Jan 2011 13:52:02 -0800 Message-ID: <4D28DC78.7040000@dcrocker.net> Date: Sat, 08 Jan 2011 13:51:52 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joseph Yee References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> In-Reply-To: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> 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]); Sat, 08 Jan 2011 13:52:02 -0800 (PST) Cc: EAI WG Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Jan 2011 21:50:16 -0000 On 1/5/2011 11:43 PM, Joseph Yee wrote: > And before heading to consensus call, we will > confirm with the WG on the set of questions. Once the set confirmed, we will > proceed in discussion on each topic and will evaluate the results. My own preferences: > (1) Should the WG add parameter on MAIL FROM to start EAI transaction and > avoid the need for deep inspection? Yes. > (2) Should the parameter be permitted only if VRFY or EXPN appears subsequent > to an EHLO response that includes UTF8SMTPbis? It should be permitted whenever VRFY or EXPN is permitted. In other words, this enhancement should not change the basic SMTP state machine. > (3) Should the WG remove repetition of normative text from other documents to > the extent possible. Incorporate by reference and, where necessary, note > explicitly that tutorial / context-providing references are not normative. Yes. > If the WG remove the repetition of normative text, will it make the draft > hard to read? If not, are there any text in current draft may result in > inaccurate or confusing information because by update of other RFCs? Removal will simplify the current text. Simpler specifications usually are much easier to read and understand. The changes made by this extension should be relatively specific. Hence they should not require going back and forth between the based SMTP specification and this extension specification. In addition, anyone who implements these changes already needs to be familiar with the SMTP specification. They do not need to be reminded of some details but not others. Concern for inaccuracy or confusion is most serious for the future, not the present. However even in the present there is a problem that copying part of the text from another specification means that the copied text loses the context in which it was written. This can produce significant misunderstandings. > (4) Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" > with new or different term s that precisely and accurately identify what is > intended? Yes. > (5) Should the WG add additional text for gateways? Probably not, unless the working group wants to specify interworking between ASCII and UTF-8 environments. (My understanding is that the WG decided NOT to support this interworking.) The design needs to be reasonably friendly to gateway work, but that is different from actually doing specification. > (6) Should the WG add additional text for ticket systems that interface with > email address, internationalized string, log, and traces? I don't have an opinion about this, yet. > (7) Should the WG keep the decision about nested encodings and the use of > message/global as described in RFC5336 and RFC5336bis? Or is a different > model needed? No. The working group should not change MIME encoding rules. > (8) Once errors are corrected, is the current metalanguage model (including > the 'u' prefixes) acceptable? If not, should only those rules be included > that are modified from RFC 5321 or 5322 respectively, forcing the user to > reference the original documents for parts of substantially every rule? I think the ABNF changes are better, if 'replacement' rules being with a string that can be reliably and accurately parsed, such as 'utf-' rather than 'u'. The concern is to make the string more likely to be unique. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From klensin@jck.com Sat Jan 8 20:26:26 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 5C0E53A68BA for ; Sat, 8 Jan 2011 20:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv5e5IUjyh1O for ; Sat, 8 Jan 2011 20:26:25 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 91A803A6817 for ; Sat, 8 Jan 2011 20:26:24 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PbmtB-0003gV-Ds; Sat, 08 Jan 2011 23:28:21 -0500 Date: Sat, 08 Jan 2011 23:28:20 -0500 From: John C Klensin To: dcrocker@bbiw.net, Jiankang YAO Message-ID: <0264711669B8A362CF1660F0@PST.JCK.COM> In-Reply-To: <4D28D9DE.60309@dcrocker.net> References: <493041112.16848@cnnic.cn> <494392558.18256@cnnic.cn> <4D28D9DE.60309@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] utf8 reply in RCPT Commands X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 04:26:26 -0000 --On Saturday, January 08, 2011 13:40 -0800 Dave CROCKER wrote: > > On 1/7/2011 1:29 AM, Jiankang YAO wrote: >> There are two kinds of cases when the client receives the >> utf8smtp ehlo word and builds a smtp session: >... > To start with a basic point of agreement: > > An EAI server must not send UTF-8 data to a non-EAI client. > > Any discussion therefore needs to be based on this absolute > requirement, and I definitely did not mean to suggest that the > rule be violated. >... > The alternative that has been suggested is to have the client > add an explicit parameter to declare use of UTF-8. This is a > much more clean and common approach for switching "modes" in a > protocol exchange. > > I think the relatively appropriate approach is the simple and > usual method of adding a parameter to MAIL, EXPN and VRFY. In the interest of avoiding confusion and focusing the questions: * A parameter for VRFY/EXPN was specified in RFC 5336, so the availability of that parameter is not an proposed addition here. There is, IMO, a problem with both the 5336 and 5336bis text, which is that it is not clear whether the client is required to supply the parameter if the string argument contains characters outside the ASCII range. I think we are headed toward "yes", even though a test on that string is lots less complex than tests on message content as would be required for the MAIL command if no parameter is required there. * Neither 5336 nor 5336bis-07 specify a parameter for the MAIL command. That issue is already on Joseph's list of questions. Is that a correct summary? john From klensin@jck.com Sat Jan 8 21:00:31 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 C30A73A6910 for ; Sat, 8 Jan 2011 21:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRci0GKbw2i3 for ; Sat, 8 Jan 2011 21:00:30 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7195F3A682B for ; Sat, 8 Jan 2011 21:00:30 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PbnQF-0003y3-Qj; Sun, 09 Jan 2011 00:02:32 -0500 Date: Sun, 09 Jan 2011 00:02:31 -0500 From: John C Klensin To: dcrocker@bbiw.net, Joseph Yee Message-ID: <53D0834D971F1CA5D81D9531@PST.JCK.COM> In-Reply-To: <4D28DC78.7040000@dcrocker.net> References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> <4D28DC78.7040000@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: EAI WG Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 05:00:31 -0000 --On Saturday, January 08, 2011 13:51 -0800 Dave CROCKER wrote: >... >> (2) Should the parameter be permitted only if VRFY or EXPN >> appears subsequent to an EHLO response that includes >> UTF8SMTPbis? > > It should be permitted whenever VRFY or EXPN is permitted. In > other words, this enhancement should not change the basic SMTP > state machine. That is interesting. Although one can read the text of 5321 (and its predecessors back to 1425) to allow this because there is no obvious and explicit prohibition, we have never before allowed an extension parameter to be specified prior to its being authorized by a matching . You implicitly referred to the assumed requirement in your earlier note when you wrote: > (There is also the requirement that an EAI client must not > send UTF-8 data to a non-EAI server, but the proposed SMTP > extension keyword solves that problem is the simple, usual > way.) So it seems to me that there is a choice: (1) Permit VRFY or EXPN with the keyword (and possibly with a command argument outside the ASCII range) only after EHLO and an EHLO response that authorizes EAI extensions. (2) Permit this keyword, and possibly other keywords, on VRFY and EXPN wherever they might occur, without the protection of the extension mechanism when they are used outside a mail session (i.e., before EHLO). I don't see either of these as changing the state machine. VRFY and EXPN can still be issued without a mail session and still don't change the state of the mail session if they are issued inside one. The difference is where the parameter is permitted and whether we are redesigning the commands themselves. As someone (Ned?) noted earlier, unlike MAIL and RCPT, there is no template syntax for parameters in 5321 (or 1425) for VRFY or EXPN. Some procedural complications aside (note that, if there is a problem with how and where parameters are added to VRFY and EXPN, the problem was committed in RFC 5336 -- it is not new here), we can certainly add those parameters and invoke the general extension model, as long as the parameterized versions of the commands occur only after a mail session is established with the appropriate ESMTP keyword response. The other possibility is to redefine VRFY and EXPN entirely, and do so outside the bounds of the extension mechanism. The redefinition would permitting the Unicode-enabling keyword at any time the command is permitted, without any expectation of getting server permission first. In principle, that is a pretty big step with some risk of confusion by previously too-robust servers. In practice, maybe not. john From dhc2@dcrocker.net Sun Jan 9 13:15:36 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 452223A6845 for ; Sun, 9 Jan 2011 13:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz-BEjsccWRa for ; Sun, 9 Jan 2011 13:15:35 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 3DFE13A682C for ; Sun, 9 Jan 2011 13:15:35 -0800 (PST) Received: from [192.168.1.117] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p09LHfe5015848 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 9 Jan 2011 13:17:46 -0800 Message-ID: <4D2A25F0.2070107@dcrocker.net> Date: Sun, 09 Jan 2011 13:17:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: EAI WG References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> <4D28DC78.7040000@dcrocker.net> <53D0834D971F1CA5D81D9531@PST.JCK.COM> In-Reply-To: <53D0834D971F1CA5D81D9531@PST.JCK.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]); Sun, 09 Jan 2011 13:17:47 -0800 (PST) Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 09 Jan 2011 21:15:36 -0000 On 1/8/2011 9:02 PM, John C Klensin wrote: > --On Saturday, January 08, 2011 13:51 -0800 Dave CROCKER > wrote: >>> (2) Should the parameter be permitted only if VRFY or EXPN >>> appears subsequent to an EHLO response that includes >>> UTF8SMTPbis? >> >> It should be permitted whenever VRFY or EXPN is permitted. In >> other words, this enhancement should not change the basic SMTP >> state machine. ... > So it seems to me that there is a choice: > > (1) Permit VRFY or EXPN with the keyword (and possibly > with a command argument outside the ASCII range) only > after EHLO and an EHLO response that authorizes EAI > extensions. > > (2) Permit this keyword, and possibly other keywords, on > VRFY and EXPN wherever they might occur, without the > protection of the extension mechanism when they are used > outside a mail session (i.e., before EHLO). Apologies. I thought I had read the relevant, previous messages adequately, but had not. I think I've remedied that oversight. I also thought that what I meant was straightforward, but that wasn't true either. The discussion thread about a new command versus restricted use of the existing command -- where the restriction is to require EHLO first -- looks reasonable to me, as does its conclusion. Hence, I think this wg should settle on a parameter on the existing query commands, with a restriction that the parameters must not be used unless an EHLO has signaled server support for them. Considering new commands might be interesting, but as noted goes beyond the scope of this working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@bbiw.net Sun Jan 9 13:34:43 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 046643A6847 for ; Sun, 9 Jan 2011 13:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvMem8YxDwFY for ; Sun, 9 Jan 2011 13:34:41 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 14F4D3A67D4 for ; Sun, 9 Jan 2011 13:34:41 -0800 (PST) Received: from [192.168.1.117] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p09LahCG016320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 9 Jan 2011 13:36:48 -0800 Message-ID: <4D2A2A66.2010205@bbiw.net> Date: Sun, 09 Jan 2011 13:36:38 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John C Klensin References: <493041112.16848@cnnic.cn> <494392558.18256@cnnic.cn> <4D28D9DE.60309@dcrocker.net> <0264711669B8A362CF1660F0@PST.JCK.COM> In-Reply-To: <0264711669B8A362CF1660F0@PST.JCK.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]); Sun, 09 Jan 2011 13:36:49 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] utf8 reply in RCPT Commands X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 21:34:43 -0000 On 1/8/2011 8:28 PM, John C Klensin wrote: > * A parameter for VRFY/EXPN was specified in RFC 5336, so the > availability of that parameter is not an proposed addition here. > > There is, IMO, a problem with both the 5336 and 5336bis > text, which is that it is not clear whether the client > is required to supply the parameter if the string > argument contains characters outside the ASCII range. > I think we are headed toward "yes", even though a test > on that string is lots less complex than tests on > message content as would be required for the MAIL > command if no parameter is required there. > > * Neither 5336 nor 5336bis-07 specify a parameter for the MAIL > command. That issue is already on Joseph's list of questions. > > Is that a correct summary? Almost. However it is reasonable to supply the VRFY/EXPN parameter when the string argument contains characters INSIDE the ASCII range, also. I'll repeat that the working group is showing a tendency to use phrases like "outside the ASCII range" or "non-ASCII" as synonyms for Unicode or UTF-8. Yet ASCII is also part of Unicode and the UTF-8 encoding of it. There are some very specific cases in which it is essential to refer to the specific subset UTF-8 characters that are above x07F but I believe these cases are far fewer than occur in the working group. In the example, here, there is no reason to prohibit use of the parameter, even when the string argument is "ASCII". For one thing, ASCII is part of Unicode. For another, it signals that the client can accept responses containing UTF-8. Such responses might, of course, occur for string arguments that are all-ASCII. I suspect everyone in the working group already understands these points. So my reason for flagging the issue is that this is an issue that is easily confused and the working group needs to be particularly careful in the way it discusses and documents it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Jan 9 14:06:34 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 549743A67D4 for ; Sun, 9 Jan 2011 14:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.027 X-Spam-Level: X-Spam-Status: No, score=-111.027 tagged_above=-999 required=5 tests=[AWL=0.172, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOrB70JnDelH for ; Sun, 9 Jan 2011 14:06:33 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 0B0C73A6842 for ; Sun, 9 Jan 2011 14:06:32 -0800 (PST) Received: (qmail 91623 invoked from network); 9 Jan 2011 22:08:43 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Jan 2011 22:08:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=155c6.4d2a31ea.k1101; i=johnl@user.iecc.com; bh=fquOXWQhKdKk3mQNsdce9/PCzs9KfC0GjMIjKYORhms=; b=DYlQWJQtKLU4/NNHQf+JFk74N/wAIVLJStTckNzJojJ3640KPBr16IPO5AlAYLcIjXkWPKWhtgpQkZTdsCoMsX3no/8hiI2KAeC6jhJo5t9od+PPJXVn0TK/GuNZ79adOPVUyTJV1PNc5a39VrH0kaJggxNGdoN22e0D5MvUCQg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=155c6.4d2a31ea.k1101; olt=johnl@user.iecc.com; bh=fquOXWQhKdKk3mQNsdce9/PCzs9KfC0GjMIjKYORhms=; b=oHwiq3rUKnGs8Jd16p95FwMv854d8KmBi+z5qukFlPKtEorremv2/zMAMHYEa0r7pkoxeFz3EiAK8xRp+iVrxD9F59n/uTRA6rCi65HK1D9bUIlkIESIJ/NOEm+ziUJeDX8xIp2Rbr6aSUOOFyOoqQbWJaPpX65Shomr/ko9qsQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Jan 2011 22:08:42 -0000 Message-ID: <20110109220842.87493.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D2A25F0.2070107@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:06:34 -0000 >Hence, I think this wg should settle on a parameter on the existing >query commands, with a restriction that the parameters must not be >used unless an EHLO has signaled server support for them. Having gone back and looked at the relevant bits of the drafts and of RFC 5321, I agree. When I suggested the STARTEAI command I was under the mistaken impression that VRFY and EXPN allowed arbitrary text after the command, which would have made whatever the parameter is retroactively a reserved word. But on rereading, I see that they take an argument which is one possibly quoted string, so the parameter doesn't collide with anything. We definitely need a two-way handshake so both ends of a connection know that they're speaking EAI, and this seems the least complicated way to do it. As far as whether to allow the parameter on EXPN and VRFY before EHLO, I realize that it changes the state machine to require EHLO first, but I wouldn't want to make assumptions about what a non-EAI server might do with a parameter it wasn't coded to handle. R's, John From klensin@jck.com Sun Jan 9 15:45:38 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 D7D9E3A6859 for ; Sun, 9 Jan 2011 15:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oLMmKOulgLY for ; Sun, 9 Jan 2011 15:45:37 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 992333A6853 for ; Sun, 9 Jan 2011 15:45:33 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pc4yf-000Bis-73; Sun, 09 Jan 2011 18:47:16 -0500 Date: Sun, 09 Jan 2011 18:46:56 -0500 From: John C Klensin To: Dave CROCKER Message-ID: In-Reply-To: <4D2A2A66.2010205@bbiw.net> References: <493041112.16848@cnnic.cn> <494392558.18256@cnnic.cn> <4D28D9DE.60309@dcrocker.net> <0264711669B8A362CF1660F0@PST.JCK.COM> <4D2A2A66.2010205@bbiw.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] utf8 reply in RCPT Commands X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:45:39 -0000 --On Sunday, January 09, 2011 13:36 -0800 Dave CROCKER wrote: > On 1/8/2011 8:28 PM, John C Klensin wrote: >> * A parameter for VRFY/EXPN was specified in RFC 5336, so the >> availability of that parameter is not an proposed addition >> here. >> >> There is, IMO, a problem with both the 5336 and 5336bis >> text, which is that it is not clear whether the client >> is required to supply the parameter if the string >> argument contains characters outside the ASCII range. >> I think we are headed toward "yes", even though a test >> on that string is lots less complex than tests on >> message content as would be required for the MAIL >> command if no parameter is required there. >> >> * Neither 5336 nor 5336bis-07 specify a parameter for the MAIL >> command. That issue is already on Joseph's list of questions. >> >> Is that a correct summary? > > > Almost. However it is reasonable to supply the VRFY/EXPN > parameter when the string argument contains characters INSIDE > the ASCII range, also. That is what I said, I think. I agree with you that it is reasonable. Whether it is necessary or not is, IMO, an unresolved question although I'm personally strongly leaning in the direction of permitting the parameter always and requiring if either the string argument to the comment contains Unicode characters outside the ASCII range (see below) or if such characters are permitted on replies. > I'll repeat that the working group is showing a tendency to > use phrases like "outside the ASCII range" or "non-ASCII" as > synonyms for Unicode or UTF-8. Yet ASCII is also part of > Unicode and the UTF-8 encoding of it. Careful, please. I agree with you, at least in retrospect, that "non-ASCII" is sloppy terminology and that we should get rid of it even though I suggest that the meaning is clear to almost every person on earth who works regularly with Unicode or internationalization more generally. However, especially since the EAI specs are, I think, already quite clear that no CCS other than Unicode is permitted on the wire, nor is any encoding of Unicode other than UTF-8, "outside the ASCII range" or "outside the ASCII repertoire" are completely and very precisely well-defined and, for all practical purposes, synonymous. The difference between the two is only relevant if a constraint to Unicode (with or without a UTF-8 encoding requirement) has not already been specified: "ASCII repertoire" is still well-defined but "ASCII range" might not so well-defined on another code space (although, in practice, unless one is using either a very old CCS (e.g., BCD) or a non-ISO CCS like EBDCIC, "ASCII range" is still well-defined. The only way to be more precise about what is intended would be to say something like "Unicode code points outside the range U+0000 through U+007F inclusive", but, in addition to being pedantic, that is actually less clear about what is intended than terminology based on ASCII, at least to the less-sophisticated reader. > There are some very specific cases in which it is essential to > refer to the specific subset UTF-8 characters that are above > x07F but I believe these cases are far fewer than occur in the > working group. Maybe I still don't understand the point you are trying to make, but, as you would be the first to point out in other contexts, there is an installed base out there and the commands and headers of that installed base are defined entirely in terms of "ASCII characters". Exceptions arise for message content: you will recall that one of the, if not the, primary original goal for what became MIME was internationalization of textual content. It is also worth noting that MIME "charset" parameters deliberately and explicitly conflate coded character sets with their encodings. We claimed for many years that was a strength to reduce confusion so, while I agree with you that it may be time to untangle the two, relative to IETF precedents in the email area, we are swimming upstream (together). Faulting the EAI WG and is document for creating this situation is, IMO, a little bit unreasonable. More broadly and again unless I misunderstand, I think you are contradicting your own arguments. Because of that installed base, the WG has been extremely careful to avoid requiring EAI behavior or parameters when whatever both client and server are intending to do is strictly conformant with 5321/5322. There are some tricky balances there and we may not have gotten them right. But it seems to me that, if someone sends, e.g., VRFY using exactly the syntax specified by 5321 and its predecessors, they should be able to expect to get back exactly what 5321 specifies... and that is NVT ASCII in and NVT ASCII out. Similarly, _especially_ if we provide a parameter to the MAIL command to indicate that EAI features are needed, it may be ok for a client to supply that parameter and send NVT ASCII only, but, if the client sends NVT ASCII without a parameter, both client and server should expect to behave exactly as 5321 (and any other extensions) specify. Another example of this is message/rfc822. It is clearly specified (Section 5.2.2 of RFC 2045 and probably elsewhere) as supporting all-ASCII headers in the embedded messages. It has no provision for a charset parameter or other indication that headers in something other than ASCII are being transmitted. Rejection of the idea of message/global is a threat to the installed base because it would force changing the semantics of a well-defined and well-established concept (and content-type)... unless, of course, one is willing to say that no EAI-conformant message that does not conform to the restrictions of 2046 (e.g., one that contains characters outside the ASCII repertoire in UTF-8 encoding rather than RFC 2047 ("encoded word") encoding) may ever be encapsulated for forwarding or other purposes. > In the example, here, there is no reason to prohibit use of > the parameter, even when the string argument is "ASCII". For > one thing, ASCII is part of Unicode. Sure. There is probably no reason to prohibit it and no reason why an EAI-compliant shouldn't include it, other than giving the server a little bit more information... _unless_ the client is sending ASCII and unable to accept a reply that contains anything but ASCII. I distinctly remember MTAs that, because various lookup systems were required that were not used elsewhere in their systems, branched off into completely separate code modules if VRFY or EXPN were received, pushing down or otherwise remembering session state if EHLO had been received first. I don't know if such systems are still in active use but, if they are, one could easily imagine a different implementation schedule for VRFY/EXPN than for actual message transmission. I assume we would not want to delay deployment of i18n mail for such an implementation until VRFY/EXPN caught up, especially for vendors whose customer experience was that no one enabled either operationally anyway. > For another, it signals that the client can accept responses > containing UTF-8. Such responses might, of course, occur for > string arguments that are all-ASCII. And that was the case where 5336 (and the current text of 5336bis) absolutely require the parameter. So I don't know who you think you have to persuade. > I suspect everyone in the working group already understands > these points. So my reason for flagging the issue is that > this is an issue that is easily confused and the working group > needs to be particularly careful in the way it discusses and > documents it. No disagreement there. john From klensin@jck.com Sun Jan 9 15:52:58 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 4F9F23A685A for ; Sun, 9 Jan 2011 15:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di7t23AhlBIL for ; Sun, 9 Jan 2011 15:52:57 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8A4C03A6860 for ; Sun, 9 Jan 2011 15:52:55 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pc565-000BkX-It; Sun, 09 Jan 2011 18:54:55 -0500 Date: Sun, 09 Jan 2011 18:54:36 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: In-Reply-To: <20110109220842.87493.qmail@joyce.lan> References: <20110109220842.87493.qmail@joyce.lan> 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: dcrocker@bbiw.net Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:52:58 -0000 --On Sunday, January 09, 2011 22:08 +0000 John Levine wrote: >> Hence, I think this wg should settle on a parameter on the >> existing query commands, with a restriction that the >> parameters must not be used unless an EHLO has signaled >> server support for them. > > Having gone back and looked at the relevant bits of the drafts > and of RFC 5321, I agree. > > When I suggested the STARTEAI command I was under the mistaken > impression that VRFY and EXPN allowed arbitrary text after the > command, which would have made whatever the parameter is > retroactively a reserved word. But on rereading, I see that > they take an argument which is one possibly quoted string, so > the parameter doesn't collide with anything. Yes. The only issues are two bits of flexibility that occur in practice (but violate 5321): (1) In 821, the string argument to VRFY or EXPN could contain blanks and other odd characters as long as they were preceded by backslash (no surrounding double quotes required). It is possible that code to send such strings is around somewhere; whether or not we should allow for them is a judgment call. (2) In part because of the confusion created by that odd quoting convention in 821, there are, or used to be, servers in the wild that would behave in exactly the way you were concerned about, i.e., treat the entire command line following VRFY or EXPN as the argument, effectively quoting the entire argument as a string if it wasn't quoted already. My personal view right now is that we can probably safely ignore both of those cases. But we should be explicit that is what we are doing, e.g., by making an explicit requirement that any server that advertises UTF8SMTPbis takes responsibility for a 5321-conforming interpretation of VRFY and EXPN arguments. > We definitely need a two-way handshake so both ends of a > connection know that they're speaking EAI, and this seems the > least complicated way to do it. Ack. > As far as whether to allow the parameter on EXPN and VRFY > before EHLO, I realize that it changes the state machine to > require EHLO first, but I wouldn't want to make assumptions > about what a non-EAI server might do with a parameter it > wasn't coded to handle. Exactly. john From barryleiba.mailing.lists@gmail.com Sun Jan 9 16:32:15 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 ED5DA3A6855 for ; Sun, 9 Jan 2011 16:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 qa8GK-n+jhN8 for ; Sun, 9 Jan 2011 16:32:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 0F05A3A6833 for ; Sun, 9 Jan 2011 16:32:15 -0800 (PST) Received: by iyi42 with SMTP id 42so18906579iyi.31 for ; Sun, 09 Jan 2011 16:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=stf5fTtnNkEzxBGLVjSK45LvUZaqTJcniSXRPDN2AJU=; b=OgPYdybARi5xrEggtwxJQaTwHvWwHCMolb+OBUJ33iFrVmoEWd2+nz7OtA8YilzGOs SkBJ67kKedfzpqJ06y2F9C2xfopgn6N1d9NnAE3o/85DiFOwgYrIYNra2XkwfqjgooAs H4R6AtT0RWiAyAp4m13Kw5qap8IRqwJcwspXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vWBhIrgRj4ErYBPf00X1+/kMpztYNda0RLZqGXENDbQ6nOQ4rj1pOiDOdHErwGB3Yo szu4du8Idnk39j6ZdSdBvzoLmr5tZK+tM8uqeSw0mpTTn8QQH7LZMtlLxQAwv0yLpkOs sum476kxqYkIiEVjKQhWOAnws7cRRNoFyN8ww= MIME-Version: 1.0 Received: by 10.42.167.67 with SMTP id r3mr3275787icy.13.1294619667186; Sun, 09 Jan 2011 16:34:27 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.240.2 with HTTP; Sun, 9 Jan 2011 16:34:27 -0800 (PST) In-Reply-To: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> Date: Sun, 9 Jan 2011 19:34:27 -0500 X-Google-Sender-Auth: JvEP4eHrNrRmP1jfV3k0IlFqEro Message-ID: From: Barry Leiba To: Joseph Yee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: EAI WG Subject: Re: [EAI] determining the question set for consensus call 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, 10 Jan 2011 00:32:16 -0000 > (1) Should the WG add parameter on MAIL FROM to start EAI transaction and > avoid the need for deep inspection? Absolutely, yes. > (2) Should the parameter be permitted only if VRFY or EXPN appears subseq= uent > to an EHLO response that includes UTF8SMTPbis? Yes. In order to use EAI-enabled VRFY of EXPN, the client MUST do EHLO first and check for the server support. If the client wants to use VRFY or EXPN without EHLO, it's limited to the old, pre-EAI version (and it will not get Unicode/UTF-8-encoded responses). > (3) Should the WG remove repetition of normative text from other document= s to > the extent possible. =A0Incorporate by reference and, where necessary, no= te explicitly > that tutorial / context-providing references are not normative. Yes. > If the WG remove the repetition of normative text, will it make the draft= hard to read? No. >=A0If not, are there any text in current draft may result in inaccurate or= confusing > information because by update of other RFCs? RFCs aren't updated in place; if the references are to the RFCs by number, the references will be stable. If an RFC is updated or obsoleted, that will be noted, but the referenced text in the original RFC will still be there and will not have changed. Of course, it might be a good idea to update our documents if/when an RFC they reference has an updating or obsoleting RFC... but that's a different issue. > (4) Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8"= with new > or different term s that precisely and accurately identify what is intend= ed? I've answered this in my other note: I think we need to define the terms we use, and then use them rigorously. And we need to make it clear when we're referring to "characters" in the abstract sense, and when we're referring to encoded characters. > (5) Should the WG add additional text for gateways? I don't think that's in scope, so I'd say no. Follow-on informative advice to gateways might be appropriate, as a separate effort. > (6) Should the WG add additional text for ticket systems that interface w= ith email > address, internationalized string, log, and traces? I think my answer to that is the same as for (5). I wouldn't mind brief text -- a paragraph, maybe -- that points out things to watch for, but any significant treatment should be saved for follow-on informative advice. > (7) Should the WG keep the decision about nested encodings and the use of > message/global as described in RFC5336 and RFC5336bis? Or is a different > model needed? I'm undecided about this one. > (8) Once errors are corrected, is the current metalanguage model (includi= ng > the 'u' prefixes) acceptable? =A0If not, should only those rules be inclu= ded that > are modified from RFC 5321 or 5322 respectively, forcing the user to refe= rence > the original documents for parts of substantially every rule? The documents should introduce new ABNF elements for the new strings, and update ABNF rules from the other documents. Yes, we should use references to the other documents for the original rules. Barry From duerst@it.aoyama.ac.jp Sun Jan 9 17:24:10 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 A769228C0DB for ; Sun, 9 Jan 2011 17:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.415 X-Spam-Level: X-Spam-Status: No, score=-100.415 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 21X-BbY2xJs0 for ; Sun, 9 Jan 2011 17:24:08 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id A30D33A6868 for ; Sun, 9 Jan 2011 17:24:08 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0A1QEWt016750 for ; Mon, 10 Jan 2011 10:26:14 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 71bc_0818_9dabb7bc_1c58_11e0_a319_001d096c566a; Mon, 10 Jan 2011 10:26:14 +0900 Received: from [IPv6:::1] ([133.2.210.1]:43462) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 10 Jan 2011 10:26:14 +0900 Message-ID: <4D2A6023.8020701@it.aoyama.ac.jp> Date: Mon, 10 Jan 2011 10:25:55 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: EAI WG Subject: Re: [EAI] determining the question set for consensus call 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, 10 Jan 2011 01:24:10 -0000 My understanding from John and Joseph, and from the Subject of this thread, was that Joseph's list of questions was put on the mailing list just to check whether they are the right questions to later (when?) ask one-by-one. Now I see that some people are just replying to the questions here. Can we please do either one or the other? Regards, Martin. On 2011/01/10 9:34, Barry Leiba wrote: >> (1) Should the WG add parameter on MAIL FROM to start EAI transaction and >> avoid the need for deep inspection? > > Absolutely, yes. > >> (2) Should the parameter be permitted only if VRFY or EXPN appears subsequent >> to an EHLO response that includes UTF8SMTPbis? > > Yes. In order to use EAI-enabled VRFY of EXPN, the client MUST do > EHLO first and check for the server support. If the client wants to > use VRFY or EXPN without EHLO, it's limited to the old, pre-EAI > version (and it will not get Unicode/UTF-8-encoded responses). > >> (3) Should the WG remove repetition of normative text from other documents to >> the extent possible. Incorporate by reference and, where necessary, note explicitly >> that tutorial / context-providing references are not normative. > > Yes. > >> If the WG remove the repetition of normative text, will it make the draft hard to read? > > No. > >> If not, are there any text in current draft may result in inaccurate or confusing >> information because by update of other RFCs? > > RFCs aren't updated in place; if the references are to the RFCs by > number, the references will be stable. If an RFC is updated or > obsoleted, that will be noted, but the referenced text in the original > RFC will still be there and will not have changed. > > Of course, it might be a good idea to update our documents if/when an > RFC they reference has an updating or obsoleting RFC... but that's a > different issue. > >> (4) Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" with new >> or different term s that precisely and accurately identify what is intended? > > I've answered this in my other note: I think we need to define the > terms we use, and then use them rigorously. And we need to make it > clear when we're referring to "characters" in the abstract sense, and > when we're referring to encoded characters. > >> (5) Should the WG add additional text for gateways? > > I don't think that's in scope, so I'd say no. Follow-on informative > advice to gateways might be appropriate, as a separate effort. > >> (6) Should the WG add additional text for ticket systems that interface with email >> address, internationalized string, log, and traces? > > I think my answer to that is the same as for (5). I wouldn't mind > brief text -- a paragraph, maybe -- that points out things to watch > for, but any significant treatment should be saved for follow-on > informative advice. > >> (7) Should the WG keep the decision about nested encodings and the use of >> message/global as described in RFC5336 and RFC5336bis? Or is a different >> model needed? > > I'm undecided about this one. > >> (8) Once errors are corrected, is the current metalanguage model (including >> the 'u' prefixes) acceptable? If not, should only those rules be included that >> are modified from RFC 5321 or 5322 respectively, forcing the user to reference >> the original documents for parts of substantially every rule? > > The documents should introduce new ABNF elements for the new strings, > and update ABNF rules from the other documents. Yes, we should use > references to the other documents for the original rules. > > Barry > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From yaojk@cnnic.cn Sun Jan 9 17:44:23 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 5F39C28C0DB for ; Sun, 9 Jan 2011 17:44:23 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.049 X-Spam-Level: X-Spam-Status: No, score=-98.049 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 qxGR2FS0hYdF for ; Sun, 9 Jan 2011 17:44:22 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 4147D28C0D7 for ; Sun, 9 Jan 2011 17:44:22 -0800 (PST) Received: (eyou send program); Mon, 10 Jan 2011 09:46:34 +0800 Message-ID: <494623994.08796@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, 10 Jan 2011 09:46:34 +0800 Message-ID: From: "Jiankang YAO" To: =?iso-8859-1?Q?=22Martin_J._D=FCrst=22?= , "Barry Leiba" References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> <494622821.93528@cnnic.cn> Date: Mon, 10 Jan 2011 09:46:45 +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: EAI WG Subject: Re: [EAI] determining the question set for consensus call 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, 10 Jan 2011 01:44:23 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIiJNYXJ0aW4gSi4gRPxyc3Qi IiA8ZHVlcnN0QGl0LmFveWFtYS5hYy5qcD4NClRvOiAiQmFycnkgTGVpYmEiIDxiYXJyeWxlaWJh QGNvbXB1dGVyLm9yZz4NCkNjOiAiRUFJIFdHIiA8aW1hQGlldGYub3JnPg0KU2VudDogTW9uZGF5 LCBKYW51YXJ5IDEwLCAyMDExIDk6MjUgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBkZXRlcm1pbmlu ZyB0aGUgcXVlc3Rpb24gc2V0IGZvciBjb25zZW5zdXMgY2FsbA0KDQoNCj5NeSB1bmRlcnN0YW5k aW5nIGZyb20gSm9obiBhbmQgSm9zZXBoLCBhbmQgZnJvbSB0aGUgU3ViamVjdCBvZiB0aGlzIA0K PnRocmVhZCwgd2FzIHRoYXQgSm9zZXBoJ3MgbGlzdCBvZiBxdWVzdGlvbnMgd2FzIHB1dCBvbiB0 aGUgbWFpbGluZyBsaXN0IA0KPmp1c3QgdG8gY2hlY2sgd2hldGhlciB0aGV5IGFyZSB0aGUgcmln aHQgcXVlc3Rpb25zIHRvIGxhdGVyICh3aGVuPykgYXNrIA0KPm9uZS1ieS1vbmUuIE5vdyBJIHNl ZSB0aGF0IHNvbWUgcGVvcGxlIGFyZSBqdXN0IHJlcGx5aW5nIHRvIHRoZSANCj5xdWVzdGlvbnMg aGVyZS4gQ2FuIHdlIHBsZWFzZSBkbyBlaXRoZXIgb25lIG9yIHRoZSBvdGhlcj8NCj4NCg0KbXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0IHdlIGNhbiBkbyBib3RoLg0KYW5zd2VyIHRoZSBxdWVzdGlv bnMsIGFuZCBhZGQgdGhlIG5ldyBxdWVzdGlvbiBpZiB3ZSAgaGF2ZS4NCg0KSmlhbmthbmcgWWFv DQoNCg0K From jyee@ca.afilias.info Sun Jan 9 18:49:15 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 AFAF128C0E3 for ; Sun, 9 Jan 2011 18:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.049 X-Spam-Level: X-Spam-Status: No, score=-106.049 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-x-Oo-tl3Qa for ; Sun, 9 Jan 2011 18:49:14 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 551AE28C0D9 for ; Sun, 9 Jan 2011 18:49:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Joseph Yee X-Priority: 3 In-Reply-To: <494623994.08796@cnnic.cn> Date: Sun, 9 Jan 2011 21:51:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1D84D2A0-A26D-4D9D-BAF1-241F33B70804@ca.afilias.info> References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> <494622821.93528@cnnic.cn> <494623994.08796@cnnic.cn> To: "Jiankang YAO" X-Mailer: Apple Mail (2.1082) X-Authenticated: True Cc: Barry Leiba , EAI WG Subject: Re: [EAI] determining the question set for consensus call 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, 10 Jan 2011 02:49:15 -0000 Hi, I am looking for the WG to confirm that we have the right questions to = ask, and of course I am looking for suggestions (including new question) = or questions to the question-set. So please hold your answer for little = longer, the question will post to the mailing list one by one. If you = answered any question, I take it that the question is a good question = from your perspective. If you like all questions and see no change, = please say so in replying this thread too. I would rather have the questions reviewed and confirmed quick by the WG = rather than based on time. But I don't see that we need lots of time to = confirm the questions (I will let the discussion flow to prove my = estimation wrong, and will adjust accordingly). I will make summary on = discussions coming before Wednesday Jan 12, 8pm Pacific Time. I will = update the question list in between to help speed up the discussion. Thanks Jospeh On 2011-01-09, at 8:46 PM, Jiankang YAO wrote: >=20 > ----- Original Message -----=20 > From: ""Martin J. D=FCrst"" > To: "Barry Leiba" > Cc: "EAI WG" > Sent: Monday, January 10, 2011 9:25 AM > Subject: Re: [EAI] determining the question set for consensus call >=20 >=20 >> My understanding from John and Joseph, and from the Subject of this=20= >> thread, was that Joseph's list of questions was put on the mailing = list=20 >> just to check whether they are the right questions to later (when?) = ask=20 >> one-by-one. Now I see that some people are just replying to the=20 >> questions here. Can we please do either one or the other? >>=20 >=20 > my understanding is that we can do both. > answer the questions, and add the new question if we have. >=20 > Jiankang Yao >=20 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From duerst@it.aoyama.ac.jp Sun Jan 9 19:06:58 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 E840928C0E4 for ; Sun, 9 Jan 2011 19:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.385 X-Spam-Level: X-Spam-Status: No, score=-100.385 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 P+9j4-xFGOGK for ; Sun, 9 Jan 2011 19:06:55 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 83F4328C0D9 for ; Sun, 9 Jan 2011 19:06:55 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0A392mD027587 for ; Mon, 10 Jan 2011 12:09:02 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 71bf_0f88_fa133620_1c66_11e0_a319_001d096c566a; Mon, 10 Jan 2011 12:09:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41653) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 10 Jan 2011 12:09:02 +0900 Message-ID: <4D2A783B.6040007@it.aoyama.ac.jp> Date: Mon, 10 Jan 2011 12:08:43 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joseph Yee References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> <494622821.93528@cnnic.cn> <494623994.08796@cnnic.cn> <1D84D2A0-A26D-4D9D-BAF1-241F33B70804@ca.afilias.info> In-Reply-To: <1D84D2A0-A26D-4D9D-BAF1-241F33B70804@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Barry Leiba , EAI WG Subject: Re: [EAI] determining the question set for consensus call 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, 10 Jan 2011 03:06:59 -0000 I think the questions you listed are the right ones, so please go ahead with putting them before the WG. There is always the possibility that we find an additional question or two, but that shouldn't hold us up starting with the questions we already have. Regards, Martin. On 2011/01/10 11:51, Joseph Yee wrote: > Hi, > > I am looking for the WG to confirm that we have the right questions to ask, and of course I am looking for suggestions (including new question) or questions to the question-set. So please hold your answer for little longer, the question will post to the mailing list one by one. If you answered any question, I take it that the question is a good question from your perspective. If you like all questions and see no change, please say so in replying this thread too. > > I would rather have the questions reviewed and confirmed quick by the WG rather than based on time. But I don't see that we need lots of time to confirm the questions (I will let the discussion flow to prove my estimation wrong, and will adjust accordingly). I will make summary on discussions coming before Wednesday Jan 12, 8pm Pacific Time. I will update the question list in between to help speed up the discussion. > > Thanks > Jospeh -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From yaojk@cnnic.cn Sun Jan 9 19:19:20 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 45DC828C0D9 for ; Sun, 9 Jan 2011 19:19:20 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.161 X-Spam-Level: X-Spam-Status: No, score=-98.161 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq46ukD5zMDK for ; Sun, 9 Jan 2011 19:19:19 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 924B728C0E5 for ; Sun, 9 Jan 2011 19:19:18 -0800 (PST) Received: (eyou send program); Mon, 10 Jan 2011 11:21:29 +0800 Message-ID: <494629689.30402@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, 10 Jan 2011 11:21:29 +0800 Message-ID: From: "Jiankang YAO" To: "Claudio Allocchio" References: <493038677.16806@cnnic.cn> Date: Mon, 10 Jan 2011 11:21:40 +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: [EAI] syntax: uAtom 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, 10 Jan 2011 03:19:20 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNsYXVkaW8gQWxsb2NjaGlv IiA8Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdD4NClRvOiA8YXBwcy1kaXNjdXNzQGlldGYub3Jn PjsgPGltYUBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzQHRvb2xzLmlldGYu b3JnPg0KQ2M6IDxBbGV4ZXkuTWVsbmlrb3ZAaXNvZGUuY29tPjsgIlNNIiA8c20raWV0ZkBlbGFu ZHN5cy5jb20+DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjMsIDIwMTAgMToyNCBBTQ0KU3Vi amVjdDogW2FwcHMtZGlzY3Vzc10gYXBwcy10ZWFtIHJldmlldyBvZiBkcmFmdC1pZXRmLWVhaS1y ZmM1MzM2YmlzDQoNCg0KPiANCi4uLg0KPiANCj4gICAzLjMuICBFeHRlbmRlZCBNYWlsYm94IEFk ZHJlc3MgU3ludGF4DQo+IA0KPiBUaGUgZGVmaW5pdGlvbiBvZg0KPiANCj4gICAgICAgICAgICAg IHVBdG9tID0gMSp1Y2hhcmFjdGVyDQo+ICAgICAgICAgICAgICAgIDsgUmVwbGFjZSBBdG9tIGlu IFJGQyA1MzIxLCBTZWN0aW9uIDQuMS4yDQo+IA0KPiAgICAgICAgICAgICAgdWNoYXJhY3RlciA9 IGF0ZXh0IC8gVVRGOC1ub24tYXNjaWkNCj4gDQo+ICAgICAgICAgICAgICBhdGV4dCA9IDxTZWUg U2VjdGlvbiAzLjIuMyBvZiBSRkMgNTMyMj4NCj4gDQo+IHBlcm1pdHMgdGhhdCB1QXRvbSBpcyBl aXRoZXIgYW4gYXRleHQgT1IgYW4gVVRGOC1ub24tYXNjaWkuLi4gd2hpY2ggaW4gdGhlDQo+IGVu ZCBhbGxvd3MgYSB1TWFpbGJveCB0byBiZSBhIG1peGVkIGNvbnRydWN0aW9uIHdoZXJlIHNvbWUg dUF0b20gaXMgaW4NCj4gYXRleHQsIHdoaWxlIHNvbWUgb3RoZXIgdUF0b20gaXMgaW4gVVRGOC1u b24tYXNjaWkgQVQgVEhFIFNBTUUgVElNRSwgZS5nLiBhDQo+IGNvbnN0cnVjdCBsaWtlDQo+IA0K PiAgICAgIHNvbWUtYXNjaWkuc29tZS1VVEY4LW5vbi1hc2NpaUBzb21lLVVURjgtbm9uLWFzY2lp LnNvbWUtYXNjaWkudGxkDQo+IA0KPiBpcyBhbGxvd2VkLiBIb3dldmVyIHRoZSBkaXN0aW5jdGlv biBoZXJlIHNlZW1zIHRvIGJlIHVubmVlZGVkLCBhcyBBU0NJSSBpcyBhDQo+IHN1YnNldCBvZiBV VEY4Lg0KPiANCg0KdGhhbmtzIGZvciB5b3VyIGtpbmQgY29tbWVudHMuDQoNClVURjgtQVNDSUkg aW5jbHVkZXMgYWxsIG9mIEFTQ0lJIGNoYXJhY3RlcnMuDQphdGV4dCBvbmx5IGluY2x1ZGVzIHBh cnQgb2YgQVNDSUkgY2hhcmFjdGVycywgYW5kIGV4Y2x1ZGVzIHNvbWUgY29udHJvbCBjaGFyYWN0 ZXJzIGluIEFTQ0lJDQoNCmlmIHVjaGFyYWN0ZXI9VVRGOC1jaGFyYWN0ZXJzOyAgVVRGOC1BU0NJ SSAgcGx1cyBVVEY4LW5vbi1hc2NpaQ0KDQp0aGVuIHVjaGFyYWN0ZXJzIHdpbGwgaW5jbHVkZSBz b21lIGNvbnRyb2wgY2hhcmFjdGVycyBpbiBBU0NJSS4NCg0Kc28gaW4gb3JpZ2luYWwgdGV4dCwg d2UgaW50ZW5zaW9uYWxseSBleGNsdWRlcyBzb21lIGNvbnRyb2wgY2hhcmFjdGVycyBpbiBBU0NJ SS4NCg0KY2FuIHdlIGluY2x1ZGUgdGhlICBjb250cm9sIGNoYXJhY3RlcnMgaW4gQVNDSUk/DQoN Cg0KSmlhbmthbmcgWWFvDQoNCj4gDQo= From yaojk@cnnic.cn Mon Jan 10 23:04:25 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 8E7B33A69BA for ; Mon, 10 Jan 2011 23:04:19 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.132 X-Spam-Level: X-Spam-Status: No, score=-98.132 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGY824TPxPzd for ; Mon, 10 Jan 2011 23:04:16 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id DB4E53A6765 for ; Mon, 10 Jan 2011 23:04:14 -0800 (PST) Received: (eyou send program); Tue, 11 Jan 2011 15:06:29 +0800 Message-ID: <494729589.27132@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, 11 Jan 2011 15:06:29 +0800 Message-ID: <72D14AE69A6A4AAC9F091AE6B61FC892@LENOVO47E041CF> From: "Jiankang YAO" To: "Ned Freed" References: <493069746.02098@cnnic.cn> Date: Tue, 11 Jan 2011 15:06:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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: [EAI] vrfy syntax X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:04:25 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk5lZCBGcmVlZCIgPE5FRCtl YWlAbWF1dmUubXJvY2hlay5jb20+DQpUbzogPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz47IDxpbWFA aWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1lYWktcmZjNTMzNmJpc0B0b29scy5pZXRmLm9yZz47IDxB bGV4ZXkuTWVsbmlrb3ZAaXNvZGUuY29tPjsgIlNNIiA8c20raWV0ZkBlbGFuZHN5cy5jb20+DQpT ZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjMsIDIwMTAgMTA6MDEgQU0NClN1YmplY3Q6IFJlOiBb RUFJXSBhcHBzLXRlYW0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtZWFpLXJmYzUzMzZiaXMNCg0KDQo+ DQouLi4uDQo+IA0KPiAoMSkgMy4xIGl0ZW0gNCBhbmQgMy42LjQuMiBhZGQgYW4gb3B0aW9uYWwg VVRGOFJFUExZIHBhcmFtZXRlciB0byBWUkZZIGFuZA0KPiAgICBFWFBOLiBUaGV5IGRvIHRoaXMg YnkgcmVkZWZpbmluZyB0aGUgc3ludGF4IHRvIGJlOg0KPiANCj4gICAgdnJmeSA9ICJWUkZZIiBT UCAoIHVMb2NhbC1wYXJ0IC8gdU1haWxib3ggKQ0KPiAgICAgICAgICAgICAgICAgICAgIFsgU1Ag IlVURjhSRVBMWSIgXSBDUkxGDQo+IA0KPiAgICBleHBuID0gIkVYUE4iIFNQICggdUxvY2FsLXBh cnQgLyB1TWFpbGJveCApDQo+ICAgICAgICAgICAgICAgICAgICAgWyBTUCAiVVRGOFJFUExZIiBd IENSTEYNCj4gDQo+ICAgIFRoZSBvcmlnaW5hbCBzeW50YXggZm9yIFZSRlkgYW5kIEVYUE4gZ2l2 ZW4gaW4gUkZDIDUzMjEgaXM6DQo+IA0KPiAgICB2cmZ5ID0gIlZSRlkiIFNQIFN0cmluZyBDUkxG DQo+ICAgIGV4cG4gPSAiRVhQTiIgU1AgU3RyaW5nIENSTEYNCj4gICAgU3RyaW5nID0gQXRvbSAv IFF1b3RlZC1zdHJpbmcNCj4gICAgQXRvbSA9IDEqYXRleHQNCj4gDQo+ICAgIEl0J3Mgbm90IGlt bWVkaWF0ZWx5IG9idmlvdXMsIGJ1dCB0aGUgbmV3IHN5bnRheCBpcyBpbiBmYWN0IGEgc3VwZXJz ZXQgb2YNCj4gICAgdGhlIG9sZC4gKHVMb2NhbC1wYXJ0IHN1YnN1bWVzIGxvY2FsLXBhcnQsIHdo aWNoIGluIHR1cm4gYWxsb3dzIGF0b21zDQo+ICAgIGFuZCBxdW90ZWQgc3RyaW5ncy4pIEhvd2V2 ZXIsIHRoaXMgY2hhbmdlIGRvZXMgbXVjaCBtb3JlIHRoYW4gaGFuZyBhDQo+ICAgIHBhcmFtZXRl ciBvbiB0aGUgY29tbWFuZDsgZm9yIHRoZSBmaXJzdCB0aW1lIGFuIGVudGlyZSBhZGRyZXNzIGlz DQo+ICAgIHBlcm1pdHRlZCBhcyBhbiBFWFBOL1ZSRlkgYXJndW1lbnQuIEJ1dCBubyBzZW1hbnRp Y3MgYXJlIGdpdmVuIGZvcg0KPiAgICB0aGlzIHNpZ25pZmljYW50IHN5bnRheCBleHBhbnNpb24s IG5vciBkb2VzIHRoaXMgZXhwYW5zaW9uIGFwcGVhciB0byBiZQ0KPiAgICB3aXRoaW4gc2NvcGUg Zm9yIEVBSS4NCj4gDQo+ICAgIEEgbW9yZSByZWFzb25hYmxlIHN5bnRheCB3b3VsZCBiZToNCj4g DQo+ICAgIHZyZnkgPSAiVlJGWSIgU1AgdVN0cmluZyBbIFNQICJVVEY4UkVQTFkiIF0gQ1JMRg0K PiANCj4gICAgZXhwbiA9ICJFWFBOIiBTUCB1U3RyaW5nIFsgU1AgIlVURjhSRVBMWSIgXSBDUkxG DQo+IA0KPiAgICB1U3RyaW5nID0gdUF0b20gLyB1UXVvdGVkLXN0cmluZw0KPg0KPg0KDQp0aGFu a3MgZm9yIHlvdXIga2luZCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNClBlcnNvbmFsbHks IEkgcHJlZmVyIHRoZSBzeW50YXggZGVmaW5pdGlvbiBhYm92ZS4gSSB0aGluayB0aGF0IGl0IGlz IG1vcmUgY2xlYXIuDQoNCg0KZm9yIHRoZSBzeW50YXggZGVmaW5pdGlvbiBiZWxvdywNCkl0IGlz IHVubGlrZWx5IHRoYXQgdGhlcmUgd2lsbCBoYXZlIG5ldyBwYXJhbWV0ZXIgZm9yIHZyZnkgb3Ig ZXhwbiBpbiB0aGUgbmVhciBmdXR1cmUuIGV2ZW4gaWYgaXQgaGFzLCB0aGUgbmV3IHNwZWNpZmlj YXRpb24gY2FuIHN0aWxsIGRlZmluZSB0aGUgbmV3IG9uZS4NCg0KDQpKaWFua2FuZyBZYW8NCg0K PiANCj4gICAgQnV0IHRoaXMgbm93IGZhaWxzIGFsb25nIGEgZGlmZmVyZW50IGRpbWVuc2lvbjog V2hlbiBhZGRpbmcgYSBwYXJhbWV0ZXINCj4gICAgY2FwYWJpbGl0eSB0byBhIGNvbW1hbmQsIGl0 IHNob3VsZCBiZSBkb25lIGluIGEgZ2VuZXJhbCB3YXksIHNvIHRoYXQgYW55DQo+ICAgIGZ1dHVy ZSBleHRlbnNpb25zIGNhbiBidWlsZCBvbiBhIGNsZWFubHkgc3BlY2lmaWVkIGZvdW5kYXRpb24u IExpa2Ugc286DQo+IA0KPiAgICB2cmZ5ID0gIlZSRlkiIFNQIHVTdHJpbmcgWyBTUCB2cmZ5LXBh cmFtZXRlcnMgXSBDUkxGDQo+ICAgIHZyZnktcGFyYW1ldGVycyA9IGVzbXRwLXBhcmFtICooU1Ag ZXNtdHAtcGFyYW0pDQo+IA0KPiAgICBleHBuID0gIkVYUE4iIFNQIHVTdHJpbmcgWyBTUCBleHBu LXBhcmFtZXRlcnMgXSBDUkxGDQo+ICAgIGV4cG4tcGFyYW1ldGVycyA9IGVzbXRwLXBhcmFtICoo U1AgZXNtdHAtcGFyYW0pDQo+IA0KPiAgICB1U3RyaW5nID0gdUF0b20gLyB1UXVvdGVkLXN0cmlu Zw0KPiANCj4gICAgT2YgY291cnNlIHRoaXMgd2lsbCBhZGQgNTU1IGFzIGEgcG9zc2libGUgcmVz cG9uc2UgdG8gVlJGWS9FWFBOLCBhbmQgdGhhdA0KPiAgICBuZWVkcyB0byBiZSBub3RlZC4NCj4g DQo= From klensin@jck.com Mon Jan 10 23:53:18 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 1720F3A69E8 for ; Mon, 10 Jan 2011 23:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, GB_I_LETTER=-2] 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 1vLpvllAwEYO for ; Mon, 10 Jan 2011 23:53:16 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A613E3A69EF for ; Mon, 10 Jan 2011 23:53:13 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PcZ4X-000KAe-QE; Tue, 11 Jan 2011 02:55:18 -0500 Date: Tue, 11 Jan 2011 02:55:16 -0500 From: John C Klensin To: Jiankang YAO , Claudio Allocchio Message-ID: <9103FFC3A9948BD2300F8379@PST.JCK.COM> In-Reply-To: <494629689.30402@cnnic.cn>, References: <493038677.16806@cnnic.cn> <494629689.30402@cnnic.cn>, 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] syntax: uAtom X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:53:18 -0000 --On Monday, January 10, 2011 11:21 +0800 Jiankang YAO wrote: > From: "Claudio Allocchio" > To: ; ; > Cc: > ; "SM" Sent: > Thursday, December 23, 2010 1:24 AM > Subject: [apps-discuss] apps-team review of > draft-ietf-eai-rfc5336bis > ... >> >> 3.3. Extended Mailbox Address Syntax >> >> The definition of >> >> uAtom = 1*ucharacter >> ; Replace Atom in RFC 5321, Section 4.1.2 >> >> ucharacter = atext / UTF8-non-ascii >> >> atext = >> >> permits that uAtom is either an atext OR an UTF8-non-ascii... >> which in the end allows a uMailbox to be a mixed contruction >> where some uAtom is in atext, while some other uAtom is in >> UTF8-non-ascii AT THE SAME TIME, e.g. a construct like >... > thanks for your kind comments. > > UTF8-ASCII includes all of ASCII characters. > atext only includes part of ASCII characters, and excludes > some control characters in ASCII > > if ucharacter=UTF8-characters; UTF8-ASCII plus UTF8-non-ascii > > then ucharacters will include some control characters in ASCII. > > so in original text, we intensionally excludes some control > characters in ASCII. Exactly right, but see below. > can we include the control characters in ASCII? I'm not certain I understand exactly what question you are asking, but let me try to give some perspective on the issue and, in the process, suggest an additional question for Joseph's list. I assume that, if we can figure out what we really want to do, we can get the syntax sorted out, but there may still be uncertainty about what we want to do. Personal opinion only... When RFC 821 and its predecessors were first defined, the rule was, effectively, "any character in the ASCII repertoire" (with a quoting convention for some of them that we now see as undesirable). The ASCII repertoire consists, in terminology used by Unicode but introduced in later versions of the ASCII standard and its international counterpart (ISO/IEC 646), of The C0 control set Space ASCII graphics DEL "ASCII graphics" can be further subdivided, but the divisions don't appear to be relevant to EAI. In today's word (perhaps unlike that of 25 or 30 years ago), there seems to be no advantage and some risks from including control characters in email local-parts and other data elements. We changed the quoting convention to eliminate some of the problems and evolved the preferred (not requiring quotes) form of local parts to depend on "atext", which is restricted to ASCII graphics (printable characters). Largely because of concerns about the installed base and incompatible changes, we have never deprecated use of non-graphic characters entirely, or even removed the control characters (some of them potentially quite dangerous) from what may appear in quoted strings. Moving to Unicode does not only expand the repertoire of graphic characters, it adds a second group of explicit control characters (the C1 set), plus a lot of characters that are used only for annotations of particular sorts. Example of the latter include such things as the Language Tag Characters that have been deprecated by the Unicode consortium and by the IETF in RFC 6082. The question is what should be permitted in what I'm going to refer to in the balance of this note as "EAI-address-characters" (a repertoire, not an encoding) to avoid any confusion with Unicode, UTF-8, ASCII, and other terms. If we make it "all of Unicode", then we include both the ASCII characters that have proven problematic and increase the risk of mischief and mapping errors by including the C1 controls as well as tagging, annotation, and other characters. The WG spent some time on this and concluded that we needed to prohibit use of both the C0 and C1 controls, the latter to avoid adding characters with direct security consequences and no known benefits and the former for consistency and to reduce risks that become more severe in the context of the expanded repertoire. So we now have (completely new terminology for clarity -- please do not copy into document) and informally because it may make the intent more clear: 821-address-characters = Any ASCII character, whole range. Some require quoting. EAI-address-characters = Any Unicode character, whole range, _except_ C0 and C1 controls. Some require quoting. So the first answer is that, while the Unicode repertoire is a proper superset of the ASCII one and the set of octets that can appear in UTF-8 encoding is a proper superset of the set of octets that can appear in NVT encoding (NVT is always ASCII), the set of characters allowed in EAI-address-characters is _not_ a proper superset of the set of characters allowed in 821-address-characters because the C0 set is excluded. Now, to my personal taste and based on a number of things I think we have learned since the EAI work got started, we would be a lot better off further reducing the list of valid EAI-address-characters. It would probably be unreasonable to go all the way to the strict letters (and characters used to construct them), digits, and hyphen rule used by IDNA, but we would almost certainly be better off if we confined ourselves to graphic ("printing" in the vocabulary of 5322) characters and perhaps a subset of those. However the WG has _not_ discussed such restrictions, so the intent is that EAI-address-characters contain those described above. And, because of the exclusion of C0 (as well as C1) controls, all of the "[US-]ASCII is a subset of UTF-8" discussions are not really relevant, quite independent of Dave's concern that the statement itself represents a muddling of terminology, at least unless one assumes that both have their meaning as "charset" names, not a repertoire name and an encoding name. john From yaojk@cnnic.cn Tue Jan 11 01:12:07 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 15E883A6A32 for ; Tue, 11 Jan 2011 01:12:07 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.106 X-Spam-Level: X-Spam-Status: No, score=-98.106 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRDMxwLAmCbw for ; Tue, 11 Jan 2011 01:12:06 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id E93883A6A2D for ; Tue, 11 Jan 2011 01:12:04 -0800 (PST) Received: (eyou send program); Tue, 11 Jan 2011 17:14:19 +0800 Message-ID: <494737259.14884@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, 11 Jan 2011 17:14:19 +0800 Message-ID: <69FD65E514844478A5AA63E046D85100@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , "Claudio Allocchio" , "Joseph Yee" References: <493038677.16806@cnnic.cn> <494629689.30402@cnnic.cn>, <494732530.27143@cnnic.cn> Date: Tue, 11 Jan 2011 17:14:32 +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: [EAI] new question to the question list Re: syntax: uAtom X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:12:07 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47ICJD bGF1ZGlvIEFsbG9jY2hpbyIgPENsYXVkaW8uQWxsb2NjaGlvQGdhcnIuaXQ+DQpDYzogPGltYUBp ZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTEsIDIwMTEgMzo1NSBQTQ0KU3ViamVj dDogUmU6IFtFQUldIHN5bnRheDogdUF0b20NCg0KDQo+IA0KPiANCi4uLi4uDQo+IGFuZCwgaW4g dGhlIHByb2Nlc3MsIHN1Z2dlc3QgYW4gYWRkaXRpb25hbCBxdWVzdGlvbiBmb3IgSm9zZXBoJ3MN Cj4gbGlzdC4gDQoNCndlIGFkZCB0aGUgcXVlc3Rpb24gc2ltaWxhciB0byBiZWxvdz8NCg0KcXVl c3Rpb246DQp3aGF0IGlzIHRoZSBwcm9wZXIgZGVmaW5pdGlvbiBvZiB1QXRvbSBvciBlYWktbG9j YWwtcGFydC1jaGFyYWN0ZXJzPw0KDQpJIHRoaW5rIHRoYXQgQ2hhaXJzIG1heSBoYXZlIGEgYmV0 dGVyIHN1Z2dlc3Rpb24uDQoNCkppYW5rYW5nIFlhbw0KDQoNCg0KDQoNCg== From duerst@it.aoyama.ac.jp Tue Jan 11 01:49:26 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 CD8853A69F8 for ; Tue, 11 Jan 2011 01:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.332 X-Spam-Level: X-Spam-Status: No, score=-100.332 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 QhfQ6p8RiPS4 for ; Tue, 11 Jan 2011 01:49:24 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 5B4B23A6A13 for ; Tue, 11 Jan 2011 01:49:23 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0B9pZDP006295 for ; Tue, 11 Jan 2011 18:51:35 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 71c3_22d8_6089ba1c_1d68_11e0_a319_001d096c566a; Tue, 11 Jan 2011 18:51:35 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38481) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 11 Jan 2011 18:51:34 +0900 Message-ID: <4D2C2824.3000608@it.aoyama.ac.jp> Date: Tue, 11 Jan 2011 18:51:32 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Jiankang YAO References: <493038677.16806@cnnic.cn> <494629689.30402@cnnic.cn>, <494732530.27143@cnnic.cn> <494737259.14884@cnnic.cn> In-Reply-To: <494737259.14884@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Claudio Allocchio , ima@ietf.org Subject: Re: [EAI] new question to the question list Re: syntax: uAtom X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:49:26 -0000 On 2011/01/11 18:14, Jiankang YAO wrote: > From: "John C Klensin" >> and, in the process, suggest an additional question for Joseph's >> list. > > we add the question similar to below? > > question: > what is the proper definition of uAtom or eai-local-part-characters? I think this is too open. There is the potential to spend endless time discussing this and that (kind of) character/code point. I'd reword it as: Do we need to tweak the definition of uAtom, and if yes, how? Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Shawn.Steele@microsoft.com Tue Jan 11 13:09:36 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 611373A67AA for ; Tue, 11 Jan 2011 13:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uls4+zCV5FIR for ; Tue, 11 Jan 2011 13:09:35 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6AF453A635F for ; Tue, 11 Jan 2011 13:09:35 -0800 (PST) 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, 11 Jan 2011 13:11:53 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.88]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Tue, 11 Jan 2011 13:11:52 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: UTF8REPLY Thread-Index: Acux1A9vjhJqu6SqQHW+xvgYjBnCvQ== Date: Tue, 11 Jan 2011 21:11:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A11B7146DTK5EX14MBXC133r_" MIME-Version: 1.0 Subject: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:09:36 -0000 --_000_E14011F8737B524BB564B05FF748464A11B7146DTK5EX14MBXC133r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgd2XigJlyZSBhZGRpbmcgaXQgdG8gTUFJTCBGUk9NOiBjYW4gd2UgY2hhbmdlIGl0IHRvIGp1 c3Qg4oCcVVRGOOKAnSBpbnN0ZWFkIG9mIOKAnFVURjhSRVBMWeKAnT8gIChFZzogSeKAmWQgbGlr ZSBhIGNvbnNpc3RlbnQgdGVybSB0aGF0IHdvcmtzIGZvciBNQUlMIEZST00sIFZSRlkgYW5kIEVY UE4sIGFuZCBpcyB0aGUgc2FtZSBmb3IgYWxsIDMuDQoNCg0KLSBTaGF3bg0KDQrvo6Lvo5Dvo6fv o5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUNCg0KDQo= --_000_E14011F8737B524BB564B05FF748464A11B7146DTK5EX14MBXC133r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvZGUyMDAwOw0KCXBhbm9zZS0xOjIgMCA2IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBDb2RlMjAwMCI7DQoJcGFub3NlLTE6MiAwIDYgMCAwIDAgMCAw IDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIHdl4oCZcmUgYWRkaW5nIGl0IHRvIE1BSUwgRlJPTTogY2FuIHdlIGNoYW5n ZSBpdCB0byBqdXN0IOKAnFVURjjigJ0gaW5zdGVhZCBvZiDigJxVVEY4UkVQTFnigJ0/Jm5ic3A7 IChFZzogSeKAmWQgbGlrZSBhIGNvbnNpc3RlbnQgdGVybSB0aGF0IHdvcmtzIGZvciBNQUlMIEZS T00sIFZSRlkgYW5kIEVYUE4sIGFuZCBpcyB0aGUgc2FtZSBmb3IgYWxsIDMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpK QSI+LSBTaGF3bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkpB IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb2RlMjAwMDttc28tZmFyZWFz dC1sYW5ndWFnZTpKQSI+76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb2RlMjAwMCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL2Jsb2dzLm1z ZG4uY29tL3NoYXduc3RlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+aHR0cDovL2Jsb2dzLm1z ZG4uY29tL3NoYXduc3RlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E14011F8737B524BB564B05FF748464A11B7146DTK5EX14MBXC133r_-- From ned+ima@mrochek.com Tue Jan 11 13:16:26 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 7BB273A67AC for ; Tue, 11 Jan 2011 13:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rALnyAtW1qKt for ; Tue, 11 Jan 2011 13:16:25 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 084D03A659A for ; Tue, 11 Jan 2011 13:16:25 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWHYMF5CB400G3AQ@mauve.mrochek.com> for ima@ietf.org; Tue, 11 Jan 2011 13:18:41 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWGYKREYPC007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 11 Jan 2011 13:18:38 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWHYMDZ636007FL5@mauve.mrochek.com> Date: Tue, 11 Jan 2011 13:18:18 -0800 (PST) In-reply-to: "Your message dated Tue, 11 Jan 2011 21:11:52 +0000" To: Shawn Steele DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1294777713; bh=+tM6fwLaS+ErJTQb9r2iERwDmyaD40JSlh4lSdphy8A=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:To; b=Uk259hErPcQZo/LJXVtsFT4jZfEwr8+2alCEKRbdcPDdAi+ZtgZ539v+9XBwxLzp4 YXZAeSi4LIyVSvjn8KW3+RAe2W69XibSK8/vgZH0IACtRqYBEdbdwTMwx8KJUxvBcq t2xFr0rJANI8jT7/VruvKls51qlvGvWrygfWa3zg= Cc: "ima@ietf.org" Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:16:26 -0000 > If we’re adding it to MAIL FROM: can we change it to just “UTF8†instead of “UTF8REPLYâ€? (Eg: I’d like a consistent term that works for MAIL FROM, VRFY and EXPN, and is the same for all 3. +1 Ned From klensin@jck.com Tue Jan 11 13:33:59 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 49EF63A67A1 for ; Tue, 11 Jan 2011 13:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D9tIaCmUxn3 for ; Tue, 11 Jan 2011 13:33:57 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D68803A635F for ; Tue, 11 Jan 2011 13:33:56 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pclsz-000Iac-RO; Tue, 11 Jan 2011 16:36:13 -0500 Date: Tue, 11 Jan 2011 16:36:13 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <1853BC27C36DDDB89B4BEB95@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:33:59 -0000 --On Tuesday, January 11, 2011 21:11 +0000 Shawn Steele wrote: > If we're adding it to MAIL FROM: can we change it to just > "UTF8" instead of "UTF8REPLY"? (Eg: I'd like a > consistent term that works for MAIL FROM, VRFY and EXPN, and > is the same for all 3. FWIW, I'd rather use a parameter name that matches (is identical to) whatever we turn UTF8SMTPbis into. Just one for all three commands, but "UTF8" causes all of the problems that Dave, JianKang, myself, and others have been discussing -- confusion of encoding with character repertoire, character repertoire that doesn't exactly match what the keyword seems to mean, etc. Since we don't need more than one parameter name, having it match the EHLO reply value lowers the possibility of confusion and simplifies things for everyone, IMO. john From Shawn.Steele@microsoft.com Tue Jan 11 13:39:01 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 BD0A43A67CC for ; Tue, 11 Jan 2011 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.414 X-Spam-Level: X-Spam-Status: No, score=-9.414 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] 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 64G0aJou9dZZ for ; Tue, 11 Jan 2011 13:39:00 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id CF7233A67C1 for ; Tue, 11 Jan 2011 13:38:59 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 11 Jan 2011 13:41:12 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.88]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Tue, 11 Jan 2011 13:41:11 -0800 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] UTF8REPLY Thread-Index: Acux1A9vjhJqu6SqQHW+xvgYjBnCvQARpBeAABCckQA= Date: Tue, 11 Jan 2011 21:41:11 +0000 Message-ID: References: <1853BC27C36DDDB89B4BEB95@PST.JCK.COM> In-Reply-To: <1853BC27C36DDDB89B4BEB95@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:39:01 -0000 SSdtIGZpbmUgaWYgaXQgbWF0Y2hlcyBFSExPLiAgSU1PIHRoZSByZXBlcnRvaXJlIGlzbid0IHJl YWxseSB0aGF0IGNvbmZ1c2luZyA6KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSm9obiBDIEtsZW5zaW4gW21haWx0bzprbGVuc2luQGpjay5jb21dIA0KU2VudDogUMWNyrss IElhbnVhbGkgMTEsIDIwMTEgMTozNiBQTQ0KVG86IFNoYXduIFN0ZWVsZTsgaW1hQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0VBSV0gVVRGOFJFUExZDQoNCg0KDQotLU9uIFR1ZXNkYXksIEphbnVh cnkgMTEsIDIwMTEgMjE6MTEgKzAwMDAgU2hhd24gU3RlZWxlIDxTaGF3bi5TdGVlbGVAbWljcm9z b2Z0LmNvbT4gd3JvdGU6DQoNCj4gSWYgd2UncmUgYWRkaW5nIGl0IHRvIE1BSUwgRlJPTTogY2Fu IHdlIGNoYW5nZSBpdCB0byBqdXN0ICJVVEY4IiANCj4gaW5zdGVhZCBvZiAiVVRGOFJFUExZIj8g IChFZzogSSdkIGxpa2UgYSBjb25zaXN0ZW50IHRlcm0gdGhhdCB3b3JrcyANCj4gZm9yIE1BSUwg RlJPTSwgVlJGWSBhbmQgRVhQTiwgYW5kIGlzIHRoZSBzYW1lIGZvciBhbGwgMy4NCg0KRldJVywg SSdkIHJhdGhlciB1c2UgYSBwYXJhbWV0ZXIgbmFtZSB0aGF0IG1hdGNoZXMgKGlzIGlkZW50aWNh bA0KdG8pIHdoYXRldmVyIHdlIHR1cm4gVVRGOFNNVFBiaXMgaW50by4gIEp1c3Qgb25lIGZvciBh bGwgdGhyZWUgY29tbWFuZHMsIGJ1dCAiVVRGOCIgY2F1c2VzIGFsbCBvZiB0aGUgcHJvYmxlbXMg dGhhdCBEYXZlLCBKaWFuS2FuZywgbXlzZWxmLCBhbmQgb3RoZXJzIGhhdmUgYmVlbiBkaXNjdXNz aW5nIC0tIGNvbmZ1c2lvbiBvZiBlbmNvZGluZyB3aXRoIGNoYXJhY3RlciByZXBlcnRvaXJlLCBj aGFyYWN0ZXIgcmVwZXJ0b2lyZSB0aGF0IGRvZXNuJ3QgZXhhY3RseSBtYXRjaCB3aGF0IHRoZSBr ZXl3b3JkIHNlZW1zIHRvIG1lYW4sIGV0Yy4NClNpbmNlIHdlIGRvbid0IG5lZWQgbW9yZSB0aGFu IG9uZSBwYXJhbWV0ZXIgbmFtZSwgaGF2aW5nIGl0IG1hdGNoIHRoZSBFSExPIHJlcGx5IHZhbHVl IGxvd2VycyB0aGUgcG9zc2liaWxpdHkgb2YgY29uZnVzaW9uIGFuZCBzaW1wbGlmaWVzIHRoaW5n cyBmb3IgZXZlcnlvbmUsIElNTy4NCg0KICAgIGpvaG4NCg0KDQo= From yaojk@cnnic.cn Tue Jan 11 19:34:57 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 EB43E3A6893 for ; Tue, 11 Jan 2011 19:34:57 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -97.931 X-Spam-Level: X-Spam-Status: No, score=-97.931 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 W+KbRnazwmyH for ; Tue, 11 Jan 2011 19:34:56 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id CA22A3A688F for ; Tue, 11 Jan 2011 19:34:55 -0800 (PST) Received: (eyou send program); Wed, 12 Jan 2011 11:37:13 +0800 Message-ID: <494803433.31988@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, 12 Jan 2011 11:37:13 +0800 Message-ID: <77AAAAE906264C36A36B229C39A201A8@LENOVO47E041CF> From: "Jiankang YAO" To: =?iso-8859-1?Q?=22Martin_J._D=FCrst=22?= References: <493038677.16806@cnnic.cn> <494629689.30402@cnnic.cn>, <494732530.27143@cnnic.cn> <494737259.14884@cnnic.cn> <494739499.14918@cnnic.cn> Date: Wed, 12 Jan 2011 11:37:25 +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: Claudio Allocchio , ima@ietf.org Subject: Re: [EAI] new question to the question list Re: syntax: uAtom X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 03:34:58 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIiJNYXJ0aW4gSi4gRPxyc3Qi IiA8ZHVlcnN0QGl0LmFveWFtYS5hYy5qcD4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25u aWMuY24+DQpDYzogIkpvaG4gQyBLbGVuc2luIiA8a2xlbnNpbkBqY2suY29tPjsgIkNsYXVkaW8g QWxsb2NjaGlvIiA8Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdD47ICJKb3NlcGggWWVlIiA8anll ZUBjYS5hZmlsaWFzLmluZm8+OyA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgSmFudWFy eSAxMSwgMjAxMSA1OjUxIFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gbmV3IHF1ZXN0aW9uIHRvIHRo ZSBxdWVzdGlvbiBsaXN0IFJlOiBzeW50YXg6IHVBdG9tDQoNCg0KPiANCj4gDQo+IE9uIDIwMTEv MDEvMTEgMTg6MTQsIEppYW5rYW5nIFlBTyB3cm90ZToNCj4+IEZyb206ICJKb2huIEMgS2xlbnNp biI8a2xlbnNpbkBqY2suY29tPg0KPiANCj4+PiBhbmQsIGluIHRoZSBwcm9jZXNzLCBzdWdnZXN0 IGFuIGFkZGl0aW9uYWwgcXVlc3Rpb24gZm9yIEpvc2VwaCdzDQo+Pj4gbGlzdC4NCj4+DQo+PiB3 ZSBhZGQgdGhlIHF1ZXN0aW9uIHNpbWlsYXIgdG8gYmVsb3c/DQo+Pg0KPj4gcXVlc3Rpb246DQo+ PiB3aGF0IGlzIHRoZSBwcm9wZXIgZGVmaW5pdGlvbiBvZiB1QXRvbSBvciBlYWktbG9jYWwtcGFy dC1jaGFyYWN0ZXJzPw0KPiANCj4gSSB0aGluayB0aGlzIGlzIHRvbyBvcGVuLiBUaGVyZSBpcyB0 aGUgcG90ZW50aWFsIHRvIHNwZW5kIGVuZGxlc3MgdGltZSANCj4gZGlzY3Vzc2luZyB0aGlzIGFu ZCB0aGF0IChraW5kIG9mKSBjaGFyYWN0ZXIvY29kZSBwb2ludC4gSSdkIHJld29yZCBpdCBhczoN Cj4gDQo+IERvIHdlIG5lZWQgdG8gdHdlYWsgdGhlIGRlZmluaXRpb24gb2YgdUF0b20sIGFuZCBp ZiB5ZXMsIGhvdz8NCj4gDQoNCml0IGlzIGJldHRlciB0aGFuIG1pbmUuDQoNCjopDQoNCkppYW5r YW5nIFlhbw0KDQo+IFJlZ2FyZHMsICAgTWFydGluLg0KPiANCj4gDQo+IC0tIA0KPiAjLSMgTWFy dGluIEouIET8cnN0LCBQcm9mZXNzb3IsIEFveWFtYSBHYWt1aW4gVW5pdmVyc2l0eQ0KPiAjLSMg aHR0cDovL3d3dy5zdy5pdC5hb3lhbWEuYWMuanAgICBtYWlsdG86ZHVlcnN0QGl0LmFveWFtYS5h Yy5qcA== From dhc2@dcrocker.net Wed Jan 12 08:34:31 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 1C4593A6A4D for ; Wed, 12 Jan 2011 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DQ96qHP9ScQ for ; Wed, 12 Jan 2011 08:34:30 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 1AE583A6A4A for ; Wed, 12 Jan 2011 08:34:30 -0800 (PST) Received: from [192.168.1.117] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0CGaigf015538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 12 Jan 2011 08:36:50 -0800 Message-ID: <4D2DD89A.2070409@dcrocker.net> Date: Wed, 12 Jan 2011 08:36:42 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 12 Jan 2011 08:36:50 -0800 (PST) Cc: "ima@ietf.org" Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 12 Jan 2011 16:34:31 -0000 On 1/11/2011 1:11 PM, Shawn Steele wrote: > If we’re adding it to MAIL FROM: can we change it to just “UTF8” instead of > “UTF8REPLY”? (Eg: I’d like a consistent term that works for MAIL FROM, VRFY and > EXPN, and is the same for all 3. +1 (And using UTF8 does correctly assert that the option covers Unicode encoded in UTF8...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jyee@ca.afilias.info Wed Jan 12 12:05:36 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 4B3543A6A8B for ; Wed, 12 Jan 2011 12:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.115 X-Spam-Level: X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGGzu5n4PkgC for ; Wed, 12 Jan 2011 12:05:35 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id DC2633A69A4 for ; Wed, 12 Jan 2011 12:05:34 -0800 (PST) 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 1Pd6yy-0001LL-74; Wed, 12 Jan 2011 20:07:48 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Pd6yx-0007XQ-9N; Wed, 12 Jan 2011 20:07:48 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Joseph Yee In-Reply-To: <4D2A783B.6040007@it.aoyama.ac.jp> Date: Wed, 12 Jan 2011 15:07:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> <494622821.93528@cnnic.cn> <494623994.08796@cnnic.cn> <1D84D2A0-A26D-4D9D-BAF1-241F33B70804@ca.afilias.info> <4D2A783B.6040007@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1082) Cc: Barry Leiba , EAI WG Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 20:05:36 -0000 Repeating the question listed, with the new one on uAtom, and rephrase = issue (2). ------------------- (1) Should the WG add parameter on MAIL FROM to start EAI transaction and = avoid the need for deep inspection? (2)=20 Should the new parameter to VRFY/EXPN only be permitted after the SMTP = client issued EHLO command and saw a response that included UTF8SMTPbis? (3) Should the WG remove repetition of normative text from other documents = to the extent possible. Incorporate by reference and, where necessary, = note explicitly that tutorial / context-providing references are not = normative. If the WG remove the repetition of normative text, will it make the = draft hard to read? If not, are there any text in current draft may = result in inaccurate or confusing information because by update of other = RFCs? (4) Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" = with new or different term s that precisely and accurately identify what = is intended? (5) Should the WG add additional text for gateways? (6) Should the WG add additional text for ticket systems that interface with = email address, internationalized string, log, and traces? (7) Should the WG keep the decision about nested encodings and the use of = message/global as described in RFC5336 and RFC5336bis? Or is a different = model needed? (8) Once errors are corrected, is the current metalanguage model (including = the 'u' prefixes) acceptable? If not, should only those rules be = included that are modified from RFC 5321 or 5322 respectively, forcing = the user to reference the original documents for parts of substantially = every rule? (9)=20 Do we need to tweak the definition of uAtom, and if yes, how? ------ Some observation from early consensus: - Issues (5) and (6) were perceived towards editing matters or not in = scope. If no opposition observed, it's likely I will remove them from = consensus discussion. - I received suggestions to move the second part of issue (3) into later = discussion, which I personally think is reasonable. Suggestions welcomed. Just friendly reminder that this is to confirm the question before = getting into it. I (even lack of reply) take note to opinions expressed = so far and will discuss them afterwards. Regards, Joseph On 2011-01-09, at 10:08 PM, Martin J. D=FCrst wrote: > I think the questions you listed are the right ones, so please go = ahead with putting them before the WG. >=20 > There is always the possibility that we find an additional question or = two, but that shouldn't hold us up starting with the questions we = already have. >=20 > Regards, Martin. >=20 > On 2011/01/10 11:51, Joseph Yee wrote: >> Hi, >>=20 >> I am looking for the WG to confirm that we have the right questions = to ask, and of course I am looking for suggestions (including new = question) or questions to the question-set. So please hold your answer = for little longer, the question will post to the mailing list one by = one. If you answered any question, I take it that the question is a = good question from your perspective. If you like all questions and see = no change, please say so in replying this thread too. >>=20 >> I would rather have the questions reviewed and confirmed quick by the = WG rather than based on time. But I don't see that we need lots of time = to confirm the questions (I will let the discussion flow to prove my = estimation wrong, and will adjust accordingly). I will make summary on = discussions coming before Wednesday Jan 12, 8pm Pacific Time. I will = update the question list in between to help speed up the discussion. >>=20 >> Thanks >> Jospeh >=20 > --=20 > #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Shawn.Steele@microsoft.com Wed Jan 12 12:34:18 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 B15603A6A9E for ; Wed, 12 Jan 2011 12:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.389 X-Spam-Level: X-Spam-Status: No, score=-9.389 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] 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 9KteGrQGFDCF for ; Wed, 12 Jan 2011 12:34:18 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id CB0D13A69A4 for ; Wed, 12 Jan 2011 12:34:17 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Jan 2011 12:36:32 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.88]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Wed, 12 Jan 2011 12:36:32 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: UTF8REPLY Thread-Index: AcuymCraK+fuVlUwRxyPoU0f4widlw== Date: Wed, 12 Jan 2011 20:36:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 20:34:18 -0000 I realize the discussion of the actual command is jumping the gun, but I'd = prefer UTF8, or, distant secondly EAI as a "simple" tag for EAI mail. > +1 > > (And using UTF8 does correctly assert that the option covers Unicode enco= ded in=20 > UTF8...) From edainow@ca.afilias.info Thu Jan 13 05:57:47 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 2ED5D3A6B8A for ; Thu, 13 Jan 2011 05:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjKaS9e-e8PO for ; Thu, 13 Jan 2011 05:57:45 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 9BDEC3A6B89 for ; Thu, 13 Jan 2011 05:57:45 -0800 (PST) Message-ID: <4D2F055D.2060303@ca.afilias.info> Date: Thu, 13 Jan 2011 08:59:57 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: [EAI] RFC publication numbers and titles X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 13:57:47 -0000 Starting with RFCs 821/822 there has been a consistent pattern for publishing SMTP standards as paired documents, where the first is the SMTP protocol and the second is the Internet message format. This was continued until 5321/5322. The EAI Experimental drafts were published in the reverse order, with 5335 being Email Headers and 5336 SMTP Extensions. Can we reserve RFC numbers in advance to be consistent with the past and also get a 21/22 pair. 5336bis -> 6321 SMTP Extension for Internationalized Email Address 5335bis -> 6322 Internationalized Email Headers Editorial notes: 1) The title on 5336bis should be corrected to: SMTP Extensions for Internationalized Email Addresses 2) 5335bis is not only email headers, it includes specifications for message bodies. The title should be changed to conform to the previous x22 documents: Internet Message Format for Internationalized Email Addresses -Ernie From klensin@jck.com Thu Jan 13 09:22:21 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 13D7F3A6B3C for ; Thu, 13 Jan 2011 09:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8YSXJ3oCH-o for ; Thu, 13 Jan 2011 09:22:20 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 19C4A3A6B39 for ; Thu, 13 Jan 2011 09:22:20 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PdQud-000LNe-CU; Thu, 13 Jan 2011 12:24:39 -0500 Date: Thu, 13 Jan 2011 12:24:38 -0500 From: John C Klensin To: dcrocker@bbiw.net, Shawn Steele Message-ID: <4EE622DA0D738FE4D81EFEF9@PST.JCK.COM> In-Reply-To: <4D2DD89A.2070409@dcrocker.net> References: <4D2DD89A.2070409@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] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:22:21 -0000 --On Wednesday, January 12, 2011 08:36 -0800 Dave CROCKER wrote: > On 1/11/2011 1:11 PM, Shawn Steele wrote: >> If we're adding it to MAIL FROM: can we change it to just >> "UTF8" instead of "UTF8REPLY"? (Eg: I'd like a >> consistent term that works for MAIL FROM, VRFY and EXPN, and >> is the same for all 3. > > +1 > > (And using UTF8 does correctly assert that the option covers > Unicode encoded in UTF8...) And incorrectly implies that all of Unicode is permitted as long as it is encoded in UTF-8. If we want precision in the use of terms like "UTF-8" (which, by the way, is the correct spelling), then we should be precise. john From dcrocker@bbiw.net Thu Jan 13 09:37:16 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 1470C3A6B3C for ; Thu, 13 Jan 2011 09:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.574 X-Spam-Level: X-Spam-Status: No, score=-7.574 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKcXQcvlZg42 for ; Thu, 13 Jan 2011 09:37:14 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id D9AD93A6BBF for ; Thu, 13 Jan 2011 09:37:14 -0800 (PST) Received: from [192.168.1.117] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0DHdW0j019990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2011 09:39:37 -0800 Message-ID: <4D2F38D0.7070102@bbiw.net> Date: Thu, 13 Jan 2011 09:39:28 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John C Klensin References: <4D2DD89A.2070409@dcrocker.net> <4EE622DA0D738FE4D81EFEF9@PST.JCK.COM> In-Reply-To: <4EE622DA0D738FE4D81EFEF9@PST.JCK.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]); Thu, 13 Jan 2011 09:39:38 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:37:16 -0000 On 1/13/2011 9:24 AM, John C Klensin wrote: >> (And using UTF8 does correctly assert that the option covers >> Unicode encoded in UTF8...) > > And incorrectly implies that all of Unicode is permitted as long > as it is encoded in UTF-8. > > If we want precision in the use of terms like "UTF-8" (which, by > the way, is the correct spelling), then we should be precise. Choosing labels is often a matter of trade-offs. There is always a danger of the classic perfect being the enemy of the good. Given that established IETF use of "ASCII" does not typically mean pure ASCII and given that the EAI working group and most other IETF use of UTF-8 means UTF-8 adapted for use within IETF protocols, the lack of "precision" that you cite does not seem to cause all that much trouble. In fact, there appears to be a similar comfort with approximation within the Unicode community. After the group's previous exchange about the term "Latin" and your concerns: On 1/4/2011 11:09 AM, John C Klensin wrote: > Second, while you said "Basic Latin", Dave's revised chart said > "Latin". In Unicode-speak, "Latin" refers to a script (or > script family). That script, according to Section 7.1 of > Unicode 5.0, includes the letters of Basic Latin and the Latin-1 > supplement; the characters of Latin Extended-A, B, C, and D, > Extended Additional, and Ligatures. I happened to find: Which interestingly has an entry under "European Scripts" labeled "Latin". That entry points to: which is the very C0 Controls and Basic Latin table we want to reference. (The Label on the chart 'home' page does have the sub-entries you cite, but the label itself points only to this one page. In other words, the Unicode Consortium is comfortable calling the table "Latin". In any event, since you object to the offered label, presumably you have a better term to suggest, so that the working group can make some progress? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Thu Jan 13 10:00:59 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 589B83A6B3C for ; Thu, 13 Jan 2011 10:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.054 X-Spam-Level: X-Spam-Status: No, score=-111.054 tagged_above=-999 required=5 tests=[AWL=0.145, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0s31p8Ha24P for ; Thu, 13 Jan 2011 10:00:58 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 05C413A67B8 for ; Thu, 13 Jan 2011 10:00:57 -0800 (PST) Received: (qmail 28853 invoked from network); 13 Jan 2011 18:03:20 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 Jan 2011 18:03:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=127a7.4d2f3e68.k1101; i=johnl@user.iecc.com; bh=Tja5Gokr6zb5tui9NmUDQJwGLel4U/hVJZlsTRtYXBg=; b=oO/RucF9MPylAp/auwAWMLbb9rkObFxbK0na1JcBn834qvM6je3aIo2WButw3iXPi55Rj/cFpdsyg/xdslt0SpUpywkBD7yG2F3kxVyBnV+F3E11pxDXsMJpse85JHFXFSOgrf5QFBZDiGHcY3EH1KBjWlz4x8UZ+Sa8u+d3M8A= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=127a7.4d2f3e68.k1101; olt=johnl@user.iecc.com; bh=Tja5Gokr6zb5tui9NmUDQJwGLel4U/hVJZlsTRtYXBg=; b=O4HTOEqk2akU20fYPFvI7lkNh6m4AfethIyhgX1cjGM+MCCCqYRM73gUH8f/4Fqvzj2Z/SVh3ac+wntX3Pz/BjJRWxAK0l26ObN/B/4pjYnxzj+zJqwWES6zlSpA21sTvAG/MlbutQODQMO1xk8geUqG6+NLUcraVy+UpVStIIk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Jan 2011 18:03:20 -0000 Message-ID: <20110113180320.75686.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D2F38D0.7070102@bbiw.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:00:59 -0000 >In any event, since you object to the offered label, presumably you have a >better term to suggest, so that the working group can make some progress? UTF8ISH ? R's, John From klensin@jck.com Thu Jan 13 12:49:00 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 EB7803A6A92 for ; Thu, 13 Jan 2011 12:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDi8clmZ1S74 for ; Thu, 13 Jan 2011 12:48:59 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id ABD4E3A6B48 for ; Thu, 13 Jan 2011 12:48:59 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PdU8g-00057t-6T; Thu, 13 Jan 2011 15:51:22 -0500 Date: Thu, 13 Jan 2011 15:51:21 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <261435EF00AF357CBBBD73F7@PST.JCK.COM> In-Reply-To: <20110113180320.75686.qmail@joyce.lan> References: <20110113180320.75686.qmail@joyce.lan> 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: dcrocker@bbiw.net Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 20:49:01 -0000 --On Thursday, January 13, 2011 18:03 +0000 John Levine wrote: >> In any event, since you object to the offered label, >> presumably you have a better term to suggest, so that the >> working group can make some progress? > > UTF8ISH ? I'm inclined to appeal to minimization of keywords and to precedent. The former is important because if we end up with a situation in the future in which there are lots of parameters (there are very few today), being able to associate the parameter name with the relevant extension keyword may actually be more important than some intuition about meaning. If you examine the registered extension list and corresponding EHLO keywords in the mail parameter registry (http://www.iana.org/assignments/mail-parameters) and then track down the extension that have corresponding keywords on the MAIL or RCPT commands, it appears that our general practice has been the one that I consider most obvious: unless multiple parameter keywords are needed on a given command to convey distinct meaning, we simply reuse the EHLO reply keyword name as the parameter. In other words, we set the value for the VRFY/EXPN and MAIL command parameters to UTF8SMTPbis (whatever that turns out to be). Another way to make progress involves actually reading each other's postings -- this idea has not only been mentioned before, but more than one person has expressed support for it. john From klensin@jck.com Thu Jan 13 13:08:52 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 C7EB93A6B4A for ; Thu, 13 Jan 2011 13:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, GB_I_LETTER=-2] 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 YXPv0eu9yES4 for ; Thu, 13 Jan 2011 13:08:51 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4AD743A6A9F for ; Thu, 13 Jan 2011 13:08:51 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PdURu-0005Zr-Af; Thu, 13 Jan 2011 16:11:14 -0500 Date: Thu, 13 Jan 2011 16:11:13 -0500 From: John C Klensin To: Dave CROCKER Message-ID: In-Reply-To: <4D2F38D0.7070102@bbiw.net> References: <4D2DD89A.2070409@dcrocker.net> <4EE622DA0D738FE4D81EFEF9@PST.JCK.COM> <4D2F38D0.7070102@bbiw.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: [EAI] "Latin" (was: Re: UTF8REPLY) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:08:52 -0000 --On Thursday, January 13, 2011 09:39 -0800 Dave CROCKER wrote: >... > Given that established IETF use of "ASCII" does not typically > mean pure ASCII and given that the EAI working group and most > other IETF use of UTF-8 means UTF-8 adapted for use within > IETF protocols, the lack of "precision" that you cite does not > seem to cause all that much trouble. Dave, you raised this issue in commenting on the use of ASCII and non-ASCII, which, for better or worse, is also extremely established IETF usage. I've agreed with you that the usage is worth changing, but, if we are going to do it, let's actually do it, not complain first and then suggest making the same errors again. > In fact, there appears to be a similar comfort with > approximation within the Unicode community. After the group's > previous exchange about the term "Latin" and your concerns: > > On 1/4/2011 11:09 AM, John C Klensin wrote: > > Second, while you said "Basic Latin", Dave's revised chart > said > > "Latin". In Unicode-speak, "Latin" refers to a script (or > > script family). That script, according to Section 7.1 of > > Unicode 5.0, includes the letters of Basic Latin and the > Latin-1 > > supplement; the characters of Latin Extended-A, B, C, and D, > > Extended Additional, and Ligatures. > > I happened to find: > > > > Which interestingly has an entry under "European Scripts" > labeled "Latin". That entry points to: > > > > which is the very C0 Controls and Basic Latin table we want to > reference. (The Label on the chart 'home' page does have the > sub-entries you cite, but the label itself points only to this > one page. > In other words, the Unicode Consortium is comfortable calling > the table "Latin". Actually, the comfort within the Unicode community is that, as the Standard, and text that describes it, has evolved contradictions have crept in. Virtually everyone who have been working with i18n issues for any length of time is aware of them, interprets intended meaning from context, and moves on. This is one such example, where "Latin" is used to refer to the ASCII code space, and the letters within that code space, and the graphic (printing) characters within that code space, and the whole collection of Latin-derived characters and marks that are associated with the script. Part, but only part, of the problem is that it is common to use "Latin" to refer to "Latin characters" and "Latin script" (without the qualifications) but sometimes referring to somewhat different repertoires. There are really only two ways around these problems: (1) Use the somewhat-imprecise terminology, accept the ambiguity and occasional need to deduce what is intended, and promise never to complain about low-precision or ambiguous terminology. (2) Learn to be very precise. Because the list of characters associated with a script or such properties as "letter", "digit", "format character", etc. (see RFC 3536 for some of this) even defining those in terms of blocks or ranges is imprecise unless the particular version of Unicode is specified. Consequently, being precise typically requires either inventing completely new terms or building definitions based on stable Unicode properties, not blocks or names for groups of code points. FWIW, IDNA2008 ended up needing to do both, as Andrew pointed out some time ago. The WG effectively selected the first approach for its Experimental documents and received no negative comments about it during Last Call on those documents. Your review of 5336bis caught a few actual errors --which I, at least, appreciate-- but raised this more general issue of precision as a serious problem. My inclination is that we are better off fixing that problem. But I think that, if we are going to do that, being consistent about it has some merit. john john From Shawn.Steele@microsoft.com Thu Jan 13 13:22:18 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 99A703A6BD8 for ; Thu, 13 Jan 2011 13:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.366 X-Spam-Level: X-Spam-Status: No, score=-9.366 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] 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 wfG2owOtt4+3 for ; Thu, 13 Jan 2011 13:22:17 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B31E53A6BD4 for ; Thu, 13 Jan 2011 13:22:17 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 13 Jan 2011 13:24:40 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.88]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Thu, 13 Jan 2011 13:24:41 -0800 From: Shawn Steele To: John C Klensin , "dcrocker@bbiw.net" Thread-Topic: [EAI] UTF8REPLY Thread-Index: Acux1A9vjhJqu6SqQHW+xvgYjBnCvQA5eM4AADP3KQAACIGkgA== Date: Thu, 13 Jan 2011 21:24:40 +0000 Message-ID: References: <4D2DD89A.2070409@dcrocker.net> <4EE622DA0D738FE4D81EFEF9@PST.JCK.COM> In-Reply-To: <4EE622DA0D738FE4D81EFEF9@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] UTF8REPLY X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:22:18 -0000 SSBkaXNhZ3JlZSBhcyB0byB0aGUgcHJlY2lzaW9uIG9mIHRoZSBtZWFuaW5nIDopICBVVEYtOCBp cyBvZnRlbiB1c2VkIGZvciBjb250ZXh0cyB3aGVyZSB0aGUgZnVsbCByYW5nZSBvZiBjb2RlIHBv aW50cyBpc24ndCBsZWdhbCwgb3Igd2hlcmUgdGhlcmUgYXJlIG90aGVyIHNwZWNpYWwgcnVsZXMu ICBIVE1MIGZvciBleGFtcGxlIGNhbiBiZSBkZWNsYXJlZCBhcyBVVEYtOCwgYnV0IHRoYXQgZG9l c24ndCBtZWFuIEkgY2FuIHVzZSBhbnkgY29kZSBwb2ludCBJIGZlZWwgbGlrZSwgcGFydGljdWxh cmx5IGluIGFueSBvcmRlciBJIGZlZWwgbGlrZSwgdGhlcmUgYXJlIG90aGVyIHJ1bGVzIHRoYXQg cmVzdHJpY3Qgd2hpY2ggcGFydHMgb2YgVW5pY29kZSBjYW4gYmUgdXNlZCBpbiB3aGF0IHBsYWNl cy4NCg0KQW5kLCBJTU8sIGl0J3MgYSBiaXQgZWFzaWVyIHRvIHJlbWVtYmVyIFVURjggYXMgYSBr ZXl3b3JkIGZvciBnbG9iYWxpemVkIHRoYW4gc29tZSBhYnN0cmFjdCB0ZXJtLiAgVVRGOCBhbHNv IGhhcyB0aGUgYWR2YW50YWdlIG9mIGltcHJlc3NpbmcgdGhhdCBpdCBpcyBjbGVhcmx5IFVURi04 LCBhbmQgeW91IGFyZW4ndCB0byBhYnVzZSB0aGlzIHN0YW5kYXJkIHdpdGggc29tZSBvdGhlciBl bmNvZGluZy4NCg0KLVNoYXduDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBK b2huIEMgS2xlbnNpbiBbbWFpbHRvOmtsZW5zaW5AamNrLmNvbV0gDQpTZW50OiBQb8q7YWjEgSwg SWFudWFsaSAxMywgMjAxMSA5OjI1IEFNDQpUbzogZGNyb2NrZXJAYmJpdy5uZXQ7IFNoYXduIFN0 ZWVsZQ0KQ2M6IGltYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFQUldIFVURjhSRVBMWQ0KDQoN Cg0KLS1PbiBXZWRuZXNkYXksIEphbnVhcnkgMTIsIDIwMTEgMDg6MzYgLTA4MDAgRGF2ZSBDUk9D S0VSIDxkaGMyQGRjcm9ja2VyLm5ldD4gd3JvdGU6DQoNCj4gT24gMS8xMS8yMDExIDE6MTEgUE0s IFNoYXduIFN0ZWVsZSB3cm90ZToNCj4+IElmIHdlJ3JlIGFkZGluZyBpdCB0byBNQUlMIEZST006 IGNhbiB3ZSBjaGFuZ2UgaXQgdG8ganVzdCAiVVRGOCIgDQo+PiBpbnN0ZWFkIG9mICJVVEY4UkVQ TFkiPyAoRWc6IEknZCBsaWtlIGEgY29uc2lzdGVudCB0ZXJtIHRoYXQgd29ya3MgDQo+PiBmb3Ig TUFJTCBGUk9NLCBWUkZZIGFuZCBFWFBOLCBhbmQgaXMgdGhlIHNhbWUgZm9yIGFsbCAzLg0KPiAN Cj4gKzENCj4gDQo+IChBbmQgdXNpbmcgVVRGOCBkb2VzIGNvcnJlY3RseSBhc3NlcnQgdGhhdCB0 aGUgb3B0aW9uIGNvdmVycyBVbmljb2RlIA0KPiBlbmNvZGVkIGluIFVURjguLi4pDQoNCkFuZCBp bmNvcnJlY3RseSBpbXBsaWVzIHRoYXQgYWxsIG9mIFVuaWNvZGUgaXMgcGVybWl0dGVkIGFzIGxv bmcgYXMgaXQgaXMgZW5jb2RlZCBpbiBVVEYtOC4NCg0KSWYgd2Ugd2FudCBwcmVjaXNpb24gaW4g dGhlIHVzZSBvZiB0ZXJtcyBsaWtlICJVVEYtOCIgKHdoaWNoLCBieSB0aGUgd2F5LCBpcyB0aGUg Y29ycmVjdCBzcGVsbGluZyksIHRoZW4gd2Ugc2hvdWxkIGJlIHByZWNpc2UuDQoNCiAgICBqb2hu DQoNCg0KDQoNCg== From jyee@ca.afilias.info Thu Jan 13 20:26:29 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 218D63A6C47 for ; Thu, 13 Jan 2011 20:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.085 X-Spam-Level: X-Spam-Status: No, score=-106.085 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXytZlxGgYal for ; Thu, 13 Jan 2011 20:26:28 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 65A553A6C42 for ; Thu, 13 Jan 2011 20:26:28 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 23:28:51 -0500 Message-Id: To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] consensus questions 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, 14 Jan 2011 04:26:29 -0000 Hi all, Each consensus question, except text for gateways and ticket-system, was = logged with IETF's issue tracker tool. Please use the thread to discuss = the specific subject matter. As mentioned before, I will collect and review everyone's responses. Regards, Joseph, co-chair= From yaojk@cnnic.cn Fri Jan 14 01:28:52 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 716E33A6AA6 for ; Fri, 14 Jan 2011 01:28:52 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.353 X-Spam-Level: X-Spam-Status: No, score=-99.353 tagged_above=-999 required=5 tests=[AWL=0.690, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBm5e0EQdBkD for ; Fri, 14 Jan 2011 01:28:51 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id D41413A6A98 for ; Fri, 14 Jan 2011 01:28:50 -0800 (PST) Received: (eyou send program); Fri, 14 Jan 2011 17:31:15 +0800 Message-ID: <494997475.19740@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, 14 Jan 2011 17:31:15 +0800 Message-ID: <6F641608FD2F4EA6A515DF888A3F9AA3@LENOVO47E041CF> From: "Jiankang YAO" To: References: <493054033.31724@cnnic.cn> Date: Fri, 14 Jan 2011 17:31: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.5994 Cc: ima@ietf.org Subject: [EAI] return A-label? 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, 14 Jan 2011 09:28:52 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo Y0BkY3JvY2tlci5uZXQ+DQpUbzogIkFwcHMgRGlzY3VzcyIgPGFwcHMtZGlzY3Vzc0BpZXRmLm9y Zz47IDxpbWFAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1lYWktcmZjNTMzNmJpc0B0b29scy5pZXRm Lm9yZz47ICJTTSIgPHNtK2lldGZAZWxhbmRzeXMuY29tPjsgPEFsZXhleS5NZWxuaWtvdkBpc29k ZS5jb20+DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjMsIDIwMTAgMjowNCBBTQ0KU3ViamVj dDogW2FwcHMtZGlzY3Vzc10gKHByaXZhdGUpIGRyYWZ0IHJldmlldyBvZjpkcmFmdC1pZXRmLWVh aS1yZmM1MzM2YmlzLTA3LnR4dCAodjMpDQoNCg0KPiANCj4NCi4uLi4NCj4NCj4+ICAgICAgICAg ICAgICAgICAgICAgICAgQW55IGRvbWFpbiBuYW1lcyB0aGF0IGFyZSB0byBiZQ0KPj4gICAgY29t cGFyZWQgdG8gbG9jYWwgc3RyaW5ncyBTSE9VTEQgYmUgY2hlY2tlZCBmb3IgdmFsaWRpdHkgYW5k IHRoZW4NCj4+ICAgIE1VU1QgYmUgY29tcGFyZWQgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gMyBv ZiBbUkZDNTg5MV0uDQo+IA0KPiB7IERpY3RhdGluZyB1c2Ugb2YgUkZDNTg5MSBpcyB3aXRoaW4g c2NvcGUuICBEaWN0YXRpbmcgdmFsaWRhdGlvbiBzZWVtcyBub3QgdG8gDQo+IGJlLiAgU28uLi59 DQo+IA0KDQoNCg0KIHNlY3Rpb24gMy42LjEuICBUaGUgSW5pdGlhbCBTTVRQIEV4Y2hhbmdlDQoi DQogICBXaGVuIGFuIFNNVFAgY29ubmVjdGlvbiBpcyBvcGVuZWQsIHRoZSBzZXJ2ZXIgbm9ybWFs bHkgc2VuZHMgYQ0KICAgImdyZWV0aW5nIiByZXNwb25zZSBjb25zaXN0aW5nIG9mIHRoZSAyMjAg cmVzcG9uc2UgY29kZSBhbmQgc29tZQ0KICAgaW5mb3JtYXRpb24uICBUaGUgY2xpZW50IHRoZW4g c2VuZHMgdGhlIEVITE8gY29tbWFuZC4gIFNpbmNlIHRoZQ0KICAgY2xpZW50IGNhbm5vdCBrbm93 IHdoZXRoZXIgdGhlIHNlcnZlciBzdXBwb3J0cyBVVEY4U01UUGJpcyB1bnRpbA0KICAgYWZ0ZXIg aXQgcmVjZWl2ZXMgdGhlIHJlc3BvbnNlIGZyb20gRUhMTywgdGhlIGNsaWVudCBtdXN0IHNlbmQg b25seQ0KICAgQVNDSUkgKExESCBsYWJlbCBbUkZDNTg5MF0gb3IgQS1sYWJlbCkgZG9tYWlucyBp biB0aGUgRUhMTyBjb21tYW5kDQogICBhbmQgdGhhdCwgaWYgdGhlIHNlcnZlciBwcm92aWRlcyBk b21haW4gbmFtZXMgaW4gdGhlIEVITE8gcmVzcG9uc2UsDQogICB0aGV5IG11c3QgYmUgaW4gdGhl IGZvcm0gb2YgTERIIGxhYmVscyBvciBBLWxhYmVscy4NCg0KIg0KDQpCYXNlZCBvbiBEYXZlJ3Mg Y29tbWVudHMsIGl0IHNlZW1zIHRoYXQgd2UgaGF2ZSB0byByZW1vdmUgdGhlIGRvbWFpbiBsYWJl bCB2YWxpZGF0aW9uIHJlcXVpcmVtZW50Lg0KDQpub3cgdGhlIHByb2JsZW0gaXMgdGhhdA0KDQpp ZiB3ZSByZW1vdmUgdGhpcyByZXF1aXJlbWVudCwNCmluIGNhc2UgdGhhdCB0aGUgc2VydmVyIHBy b3ZpZGVzIHNvbWUgc3RyaW5ncyB0aGF0IGFyZSBub3QgdmFsaWQgSUROLCB0aGUgc3RyaW5ncyBj YW4gbm90IGJlIHRyYW5zZm9ybWVkIGludG8gdGhlIEEtbGFiZWwgZm9ybS4NCnNlY3Rpb24gMy42 LjEgcmVxdWlyZXMgdGhhdCAiaWYgdGhlIHNlcnZlciBwcm92aWRlcyBkb21haW4gbmFtZXMgaW4g dGhlIEVITE8gcmVzcG9uc2UsDQogICB0aGV5IG11c3QgYmUgaW4gdGhlIGZvcm0gb2YgTERIIGxh YmVscyBvciBBLWxhYmVscy4iDQpzaW5jZSB0aGUgc2VydmVyIGNhbiBub3QgZ2V0IHRoZSBBLWxh YmVscyBmcm9tIHRoZSBpbnZhbGlkIElETiBzdHJpbmcsIHdoYXQga2luZCBvZiBBQ0Ugc3RyaW5n cyAgc2hvdWxkIGJlIHJldHVybmVkIHRvIHRoZSBjbGllbnQ/DQoNCg0KSmlhbmthbmcgWWFvDQoN Cg0KDQoNCg== From alexey.melnikov@isode.com Sun Jan 16 08:22:18 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 484FF3A6BCD for ; Sun, 16 Jan 2011 08:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 7JYUq14WUkeW for ; Sun, 16 Jan 2011 08:22:17 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6F1F73A6BC4 for ; Sun, 16 Jan 2011 08:22:17 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 16 Jan 2011 16:24:48 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D331BB3.5080909@isode.com> Date: Sun, 16 Jan 2011 16:24:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ernie Dainow References: <4D2F055D.2060303@ca.afilias.info> In-Reply-To: <4D2F055D.2060303@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] RFC publication numbers and titles X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 16:22:18 -0000 Hi Ernie, Ernie Dainow wrote: > Starting with RFCs 821/822 there has been a consistent pattern for > publishing SMTP standards as paired documents, where the first is the > SMTP protocol and the second is the Internet message format. This was > continued until 5321/5322. > > The EAI Experimental drafts were published in the reverse order, with > 5335 being Email Headers and 5336 SMTP Extensions. > > Can we reserve RFC numbers in advance to be consistent with the past > and also get a 21/22 pair. > 5336bis -> 6321 SMTP Extension for Internationalized Email Address > 5335bis -> 6322 Internationalized Email Headers I can talk to the RFC Editor about reserving the suggested RFC numbers, if that is what the WG wants. Regards, Alexey From dhc2@dcrocker.net Sun Jan 16 08:30:23 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 445363A6D3F for ; Sun, 16 Jan 2011 08:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYC7CqKNuXtR for ; Sun, 16 Jan 2011 08:30:22 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 52F4F3A6D29 for ; Sun, 16 Jan 2011 08:30:22 -0800 (PST) Received: from [192.168.1.184] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0GGWmKR026913 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 16 Jan 2011 08:32:54 -0800 Message-ID: <4D331DA9.9000708@dcrocker.net> Date: Sun, 16 Jan 2011 08:32:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexey Melnikov References: <4D2F055D.2060303@ca.afilias.info> <4D331BB3.5080909@isode.com> In-Reply-To: <4D331BB3.5080909@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]); Sun, 16 Jan 2011 08:32:54 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] RFC publication numbers and titles X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 16 Jan 2011 16:30:23 -0000 On 1/16/2011 8:24 AM, Alexey Melnikov wrote: >> Can we reserve RFC numbers in advance to be consistent with the past and also >> get a 21/22 pair. >> 5336bis -> 6321 SMTP Extension for Internationalized Email Address >> 5335bis -> 6322 Internationalized Email Headers > > I can talk to the RFC Editor about reserving the suggested RFC numbers, if that > is what the WG wants. Why not 6336 and 6335? But I think that reserving RFC numbers is quite exceptional and possibly not typically allowed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From klensin@jck.com Sun Jan 16 15:50:14 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 EDF2E3A6C41 for ; Sun, 16 Jan 2011 15:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45FTn2axIsT7 for ; Sun, 16 Jan 2011 15:50:07 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AE0D73A6BA5 for ; Sun, 16 Jan 2011 15:50:06 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PecOd-000J8b-Rg; Sun, 16 Jan 2011 18:52:32 -0500 Date: Sun, 16 Jan 2011 18:52:30 -0500 From: John C Klensin To: dcrocker@bbiw.net, Alexey Melnikov Message-ID: In-Reply-To: <4D331DA9.9000708@dcrocker.net> References: <4D2F055D.2060303@ca.afilias.info> <4D331BB3.5080909@isode.com> <4D331DA9.9000708@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] RFC publication numbers and titles X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 23:50:14 -0000 --On Sunday, 16 January, 2011 08:32 -0800 Dave CROCKER wrote: >> I can talk to the RFC Editor about reserving the suggested >> RFC numbers, if that is what the WG wants. > > > Why not 6336 and 6335? > > But I think that reserving RFC numbers is quite exceptional > and possibly not typically allowed. Indeed. And it is much easier to have those discussions when one has a clear understanding / good prediction of when the documents will be finished. FWIW, I do agree with Ernie that having them in the order SMTP (as in 821, 2821, 5321) and then headers (822, 2822, 5322) would probably be wiser. john From McQuilWP@pobox.com Sun Jan 16 23:39: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 4BFF53A6E96 for ; Sun, 16 Jan 2011 23:39:03 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNhHnc0nnGwm for ; Sun, 16 Jan 2011 23:39:02 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 0E3613A6E94 for ; Sun, 16 Jan 2011 23:39:01 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 9414C2B8B; Mon, 17 Jan 2011 02:41:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=VDEXyDtG1Po7 T6ZadLJ95cgquvg=; b=IpDDowgkqX7PEjUiI4b3cQxVruZPsPBHH2xfcwOErY6z xYckftHeVZJK8WYBDz8hQCE8PK8tdCXtTykmKsMlyhik0GGKAr+tRkN2bYEOMxG5 ScAdB880cfinMIUT65Cs1afIrOaT5TUb29/ATPUIKK7v98u8rwTDSZu7twgeeFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=QSaYkw /Lv1Ps0zWxw5nxbaf1K255tqmWEis/g3qZ2zKjLyZ7PiFWktW4+9hbdbLXQ+OMC4 IjkkLQ17xZraj2oxKzAEDn2NOIz8ZsbnAo5th7DFc17H46vdyvVkFBpJ2mf4b8+K nBTlECal8BTSGyeiw4+Rgu7sh9q0zlcWMkOds= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 407862B8A; Mon, 17 Jan 2011 02:41:30 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 5E1282B83; Mon, 17 Jan 2011 02:41:25 -0500 (EST) Date: Sun, 16 Jan 2011 23:41:23 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <784304069.20110116234123@pobox.com> To: IMA Discussion In-Reply-To: References: <4D2F055D.2060303@ca.afilias.info> <4D331BB3.5080909@isode.com> <4D331DA9.9000708@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 32BD8876-220D-11E0-9A14-D3BDF791CF9A-02871704!b-pb-sasl-quonix.pobox.com Cc: dcrocker@bbiw.net Subject: Re: [EAI] RFC publication numbers and titles 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, 17 Jan 2011 07:39:03 -0000 On Sun, 2011-01-16, John C Klensin wrote: > FWIW, I do agree with Ernie that having them in the order SMTP > (as in 821, 2821, 5321) and then headers (822, 2822, 5322) would > probably be wiser. I don't disagree with changing the ordering, but I would point out that the x21/x22 series are complete replacements whereas the EAI docs are extensions. -- Bill McQuillan From klensin@jck.com Sun Jan 16 23:52:25 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 C52513A6EA1 for ; Sun, 16 Jan 2011 23:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnk9773iCZJ8 for ; Sun, 16 Jan 2011 23:52:24 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 952F33A6D06 for ; Sun, 16 Jan 2011 23:52:24 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PejvU-00004n-VK; Mon, 17 Jan 2011 02:54:57 -0500 Date: Mon, 17 Jan 2011 02:54:55 -0500 From: John C Klensin To: Bill McQuillan , IMA Discussion Message-ID: In-Reply-To: <784304069.20110116234123@pobox.com> References: <4D2F055D.2060303@ca.afilias.info> <4D331BB3.5080909@isode.com> <4D331DA9.9000708@dcrocker.net> <784304069.20110116234123@pobox.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: dcrocker@bbiw.net Subject: Re: [EAI] RFC publication numbers and titles 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, 17 Jan 2011 07:52:25 -0000 --On Sunday, 16 January, 2011 23:41 -0800 Bill McQuillan wrote: > > On Sun, 2011-01-16, John C Klensin wrote: > > >> FWIW, I do agree with Ernie that having them in the order SMTP >> (as in 821, 2821, 5321) and then headers (822, 2822, 5322) >> would probably be wiser. > > I don't disagree with changing the ordering, but I would point > out that the x21/x22 series are complete replacements whereas > the EAI docs are extensions. Of course. It seems to me that might be an argument against trying to make the EAI documents 6321/6322 or equivalent. But the order should be independent of that. Right now, knowing that SMTP is before Headers in the base document but the order is reversed in the EAI ones has already caused some confusion and mistakes to be made. Nothing serious, but it seems like a problem best avoided, with no particular downside. john From jyee@ca.afilias.info Mon Jan 17 09:13:07 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 668A328C165 for ; Mon, 17 Jan 2011 09:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.215 X-Spam-Level: X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHzGHC2JQmzC for ; Mon, 17 Jan 2011 09:13:06 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 9161428C132 for ; Mon, 17 Jan 2011 09:13:06 -0800 (PST) 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 1Pesg8-00075V-90 for ima@ietf.org; Mon, 17 Jan 2011 17:15:40 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Pesg8-0001c7-5Q for ima@ietf.org; Mon, 17 Jan 2011 17:15:40 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:40 -0500 Message-Id: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 17 Jan 2011 17:13:07 -0000 Issue #1: parameter on MAIL FROM?=20 http://trac.tools.ietf.org/wg/eai/trac/ticket/1 Description=20 --------------- Should the WG add parameter on MAIL FROM to start EAI transaction and = avoid the need for deep inspection? --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From jyee@ca.afilias.info Mon Jan 17 09:13:08 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 8AA4628C165 for ; Mon, 17 Jan 2011 09:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVU--V+EK4UW for ; Mon, 17 Jan 2011 09:13:07 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id C411828C132 for ; Mon, 17 Jan 2011 09:13:07 -0800 (PST) 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 1PesgA-00075Y-7y for ima@ietf.org; Mon, 17 Jan 2011 17:15:42 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PesgA-0001c7-4B for ima@ietf.org; Mon, 17 Jan 2011 17:15:42 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:42 -0500 Message-Id: To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 17 Jan 2011 17:13:08 -0000 Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? http://trac.tools.ietf.org/wg/eai/trac/ticket/2 Description=20 --------------- Should the new parameter to VRFY/EXPN only be permitted after the SMTP = client issued EHLO command and saw a response that included UTF8SMTPbis? --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From jyee@ca.afilias.info Mon Jan 17 09:13:10 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 3F7AE28C171 for ; Mon, 17 Jan 2011 09:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.157 X-Spam-Level: X-Spam-Status: No, score=-106.157 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, 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 Oi8v4YeDMbDQ for ; Mon, 17 Jan 2011 09:13:09 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 5212328C16B for ; Mon, 17 Jan 2011 09:13:09 -0800 (PST) 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 1PesgC-0000lA-3F for ima@ietf.org; Mon, 17 Jan 2011 17:15:44 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PesgB-0001c7-5z for ima@ietf.org; Mon, 17 Jan 2011 17:15:43 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:43 -0500 Message-Id: To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #3: remove repetition of normative text? 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, 17 Jan 2011 17:13:10 -0000 Issue #3: remove repetition of normative text? http://trac.tools.ietf.org/wg/eai/trac/ticket/3 Description=20 --------------- Should the WG remove repetition of normative text from other documents = to the extent possible. Incorporate by reference and, where necessary, = note explicitly that tutorial / context-providing references are not = normative. --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From jyee@ca.afilias.info Mon Jan 17 09:13:11 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 7DD2028C181 for ; Mon, 17 Jan 2011 09:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.151 X-Spam-Level: X-Spam-Status: No, score=-106.151 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 Ykrq6wFWCpdJ for ; Mon, 17 Jan 2011 09:13:10 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id B103A28C171 for ; Mon, 17 Jan 2011 09:13:10 -0800 (PST) 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 1PesgD-00075i-7l for ima@ietf.org; Mon, 17 Jan 2011 17:15:45 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PesgD-0001c7-4C for ima@ietf.org; Mon, 17 Jan 2011 17:15:45 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:45 -0500 Message-Id: <42E6F4BD-9570-4474-8910-3671CDB678C9@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? 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, 17 Jan 2011 17:13:11 -0000 Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? http://trac.tools.ietf.org/wg/eai/trac/ticket/4 Description=20 --------------- Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" = with new or different term s that precisely and accurately identify what = is intended? --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From jyee@ca.afilias.info Mon Jan 17 09:19:42 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 7636C28C19F for ; Mon, 17 Jan 2011 09:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09KTmJgYi7AX for ; Mon, 17 Jan 2011 09:19:41 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id B464F28C19A for ; Mon, 17 Jan 2011 09:19:41 -0800 (PST) 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 1PesgK-0000lX-4y for ima@ietf.org; Mon, 17 Jan 2011 17:15:52 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PesgK-0001c7-4d for ima@ietf.org; Mon, 17 Jan 2011 17:15:52 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:52 -0500 Message-Id: <06E3D341-001D-411C-9A07-21E2096C2F6C@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #7: change definition of uAtom? 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, 17 Jan 2011 17:19:42 -0000 Issue #7: change definition of uAtom? http://trac.tools.ietf.org/wg/eai/trac/ticket/7 Description=20 --------------- Do we need to tweak the definition of uAtom, and if yes, how? --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From jyee@ca.afilias.info Mon Jan 17 09:19:42 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 BC19528C19A for ; Mon, 17 Jan 2011 09:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fGhEQjZ6IBM for ; Mon, 17 Jan 2011 09:19:42 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id EAAC928C19C for ; Mon, 17 Jan 2011 09:19:41 -0800 (PST) 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 1PesgE-0000lL-4o for ima@ietf.org; Mon, 17 Jan 2011 17:15:46 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PesgE-0001c7-4S for ima@ietf.org; Mon, 17 Jan 2011 17:15:46 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:46 -0500 Message-Id: To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #5: keep nested encodings for message/global? 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, 17 Jan 2011 17:19:42 -0000 Issue #5: keep nested encodings for message/global? http://trac.tools.ietf.org/wg/eai/trac/ticket/5 Description=20 --------------- Should the WG keep the decision about nested encodings and the use of = message/global as described in RFC5336 and RFC5336bis? Or is a different = model needed? --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From jyee@ca.afilias.info Mon Jan 17 09:19:42 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 DC43928C19C for ; Mon, 17 Jan 2011 09:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0RLRyMmuPul for ; Mon, 17 Jan 2011 09:19:41 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 6836228C165 for ; Mon, 17 Jan 2011 09:19:41 -0800 (PST) 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 1PesgH-0000lR-4T for ima@ietf.org; Mon, 17 Jan 2011 17:15:49 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PesgH-0001c7-48 for ima@ietf.org; Mon, 17 Jan 2011 17:15:49 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 12:15:49 -0500 Message-Id: To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Issue #6: current metalanguage model acceptable? 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, 17 Jan 2011 17:19:43 -0000 Issue #6: current metalanguage model acceptable? http://trac.tools.ietf.org/wg/eai/trac/ticket/6 Description=20 --------------- Once errors are corrected, is the current metalanguage model (including = the 'u' prefixes) acceptable? If not, should only those rules be = included that are modified from RFC 5321 or 5322 respectively, forcing = the user to reference the original documents for parts of substantially = every rule? --------------- Please use this thread or the issue tracker for discussion. The end date = of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will = be drawn afterwards. =20 Best, Joseph= From Shawn.Steele@microsoft.com Mon Jan 17 16:53: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 46B5128C1DA for ; Mon, 17 Jan 2011 16:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11LTOkPMN7qs for ; Mon, 17 Jan 2011 16:53:03 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 2F5B328C16B for ; Mon, 17 Jan 2011 16:53:03 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 16:55:31 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 16:55:31 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: parameter on MAIL FROM Thread-Index: Acu2qe92XQ30j1SmTcm6xhR4Ka8I5A== Date: Tue, 18 Jan 2011 00:55:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 00:53:04 -0000 > Issue #1: parameter on MAIL FROM?=20 > http://trac.tools.ietf.org/wg/eai/trac/ticket/1 > Description=20 > --------------- > Should the WG add parameter on MAIL FROM to start EAI transaction and avo= id the need for deep inspection? > --------------- Yes :) And I'd prefer it be "UTF8" -Shawn From Shawn.Steele@microsoft.com Mon Jan 17 16:54:14 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 004A128C20E for ; Mon, 17 Jan 2011 16:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvRyXa45+8lS for ; Mon, 17 Jan 2011 16:54:13 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 3BFB828C20C for ; Mon, 17 Jan 2011 16:54:13 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 16:56:39 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 16:56:39 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: new parameter to VRFY/EXPN only after Thread-Index: Acu2qm/dR7LfI+W8QCS82Awbx15lBA== Date: Tue, 18 Jan 2011 00:56:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] new parameter to VRFY/EXPN only after X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 00:54:14 -0000 > Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? > http://trac.tools.ietf.org/wg/eai/trac/ticket/2 > Description=20 > Should the new parameter to VRFY/EXPN only be permitted after the SMTP cl= ient issued EHLO > command and saw a response that included UTF8SMTPbis? Yes. From Shawn.Steele@microsoft.com Mon Jan 17 16:55:33 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 8E0E93A6B9B for ; Mon, 17 Jan 2011 16:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIEjIRteR0EK for ; Mon, 17 Jan 2011 16:55:32 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B0BA53A6DA3 for ; Mon, 17 Jan 2011 16:55:32 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 16:58:08 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 16:58:07 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM Thread-Index: Acu2qrW1p9A3/7k0QCu4SR+Nhw56lA== Date: Tue, 18 Jan 2011 00:58:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 00:55:33 -0000 Oops, messed up the subject when I cut & paste from the digest... Same ans= wer > Issue #1: parameter on MAIL FROM?=20 > http://trac.tools.ietf.org/wg/eai/trac/ticket/1 > Description=20 > --------------- > Should the WG add parameter on MAIL FROM to start EAI transaction and avo= id the need for deep inspection? > --------------- Yes :) And I'd prefer it be "UTF8" -Shawn From Shawn.Steele@microsoft.com Mon Jan 17 16:55:53 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 D5F103A6F72 for ; Mon, 17 Jan 2011 16:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9aW0OBLGd-8 for ; Mon, 17 Jan 2011 16:55:53 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1A6333A6B9B for ; Mon, 17 Jan 2011 16:55:53 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 16:58:28 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 16:58:27 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #2: new parameter to VRFY/EXPN only after Thread-Index: Acu2qsmeiV+pTeWjSkuyHNjZkDeEtQ== Date: Tue, 18 Jan 2011 00:58: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.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 00:55:53 -0000 Fixed subject, answer's still the same. > Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? > http://trac.tools.ietf.org/wg/eai/trac/ticket/2 > Description > Should the new parameter to VRFY/EXPN only be permitted after the SMTP=20 > client issued EHLO command and saw a response that included UTF8SMTPbis? Yes. From Shawn.Steele@microsoft.com Mon Jan 17 16:56:44 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 DF6393A6F76 for ; Mon, 17 Jan 2011 16:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.325 X-Spam-Level: X-Spam-Status: No, score=-10.325 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] 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 lYv9YzDzhgZn for ; Mon, 17 Jan 2011 16:56:44 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2051B3A6B9B for ; Mon, 17 Jan 2011 16:56:44 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 16:59:19 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 16:59:19 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #3: remove repetition of normative text? Thread-Index: Acu2quDvmvu9ag3iThekzNXx4uHp5Q== Date: Tue, 18 Jan 2011 00:59:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #3: remove repetition of normative text? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 00:56:45 -0000 > Issue #3: remove repetition of normative text? > http://trac.tools.ietf.org/wg/eai/trac/ticket/3 > Should the WG remove repetition of normative text from other documents to= the extent possible. Incorporate by reference and, where necessary, note e= xplicitly that tutorial / context-providing references are not normative. Yes. -Shawn From Shawn.Steele@microsoft.com Mon Jan 17 17:00:17 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 B1E853A6F73 for ; Mon, 17 Jan 2011 17:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] 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 ZjwjPSA-JKmS for ; Mon, 17 Jan 2011 17:00:17 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 08EA93A6B9B for ; Mon, 17 Jan 2011 17:00:17 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 17:02:52 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 17:02:52 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? Thread-Index: Acu2qzCjPeEePMw8TiGwIA45j9Y+YA== Date: Tue, 18 Jan 2011 01:02:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:00:17 -0000 > Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? > Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" wit= h new or > different term s that precisely and accurately identify what is intended? I am happy with these terms and think the intent is understandable in conte= xt. I don't object if someone has another idea, but I don't want deciding = on these to slow down the working group. -Shawn From Shawn.Steele@microsoft.com Mon Jan 17 17:02:34 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 93A6B28C21B for ; Mon, 17 Jan 2011 17:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.408 X-Spam-Level: X-Spam-Status: No, score=-10.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zeCXWKNt8vG for ; Mon, 17 Jan 2011 17:02:33 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4BBAB28C20C for ; Mon, 17 Jan 2011 17:02:32 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 17:05:07 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 17:05:07 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #6: current metalanguage model acceptable? Thread-Index: Acu2q3XRohiGzUsRTwqL/A4EZL1J4A== Date: Tue, 18 Jan 2011 01:05:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #6: current metalanguage model acceptable? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:02:34 -0000 > Issue #6: current metalanguage model acceptable? > Once errors are corrected, is the current metalanguage model (including t= he 'u' prefixes) > acceptable? I don't mind either way. > If not, should only those rules be included that are modified from RFC 53= 21 or 5322 > respectively, forcing the user to reference the original documents for pa= rts of substantially every rule? If it's going to be changed and doesn't delay the process, I think it'd be = easier to just change the modified rules, and refer to the original documen= ts. (Note that this allows revisions to the original documents to work, an= d avoids confusing in case of an error). However I'd prefer whichever path= produces the fastest results. -Shawn From Shawn.Steele@microsoft.com Mon Jan 17 17:04:25 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 407EC28C1E2 for ; Mon, 17 Jan 2011 17:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.412 X-Spam-Level: X-Spam-Status: No, score=-10.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBmBL3ruegDg for ; Mon, 17 Jan 2011 17:04:24 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 671D328C16B for ; Mon, 17 Jan 2011 17:04:24 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 17:07:00 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 17:06:59 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #7: change definition of uAtom? Thread-Index: Acu2q/TvLJEqo+s6QHi5DPrnbZgHHw== Date: Tue, 18 Jan 2011 01:07:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #7: change definition of uAtom? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:04:25 -0000 > Issue #7: change definition of uAtom? > Do we need to tweak the definition of uAtom, and if yes, how? I don't feel strongly about this either way. -Shawn From Shawn.Steele@microsoft.com Mon Jan 17 17:09:30 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 C8C7E3A6D1E for ; Mon, 17 Jan 2011 17:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbnr9ZpfA0JF for ; Mon, 17 Jan 2011 17:09:29 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C10723A6D1A for ; Mon, 17 Jan 2011 17:09:29 -0800 (PST) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 17:12:05 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 17:12:05 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #5: keep nested encodings for message/global? Thread-Index: Acu2qxn7iUrjD726T1apaUsJDKTxsQ== Date: Tue, 18 Jan 2011 01:12:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #5: keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:09:30 -0000 > Issue #5: keep nested encodings for message/global? > http://trac.tools.ietf.org/wg/eai/trac/ticket/5 > Description=20 > --------------- > Should the WG keep the decision about nested encodings and the use of mes= sage/global as described in RFC5336 and RFC5336bis? Or is a different mode= l needed? IMO they aren't necessary as the path between the sender and the recipient = would necessarily be EAI-aware, so you shouldn't have trouble between 7 bit= and 8 bit environments. I'd be happy either way. -Shawn From eai@troystarr.net Mon Jan 17 22:36:40 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 43C303A6F29 for ; Mon, 17 Jan 2011 22:36:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad8qrQU7Kc4t for ; Mon, 17 Jan 2011 22:36:37 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id C0EDF3A6F24 for ; Mon, 17 Jan 2011 22:36:36 -0800 (PST) Received: from FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8]) by FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8%10]) with mapi; Mon, 17 Jan 2011 22:39:12 -0800 From: Troy Starr To: 'EAI WG' Date: Mon, 17 Jan 2011 22:39:10 -0800 Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: Acu2gYYob1M0J4FfT5aE2PK2ytZf0AAT3OYA Message-ID: References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> In-Reply-To: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 06:36:40 -0000 Yes, it should. I would prefer it to be a parameter that takes a value, and that the value = indicates legacy behavior or EAI behavior, because I believe that makes any= potential future extensions to this standard easier to integrate. I would= prefer that the value be descriptive of the type of character encoding (AS= CII/UTF-8, or whatever terminology is deemed appropriate) rather than a sim= ple binary value, again because I believe that makes any potential future e= xtensions to this standard easier to integrate. If it had such a value, th= en a parameter name such as HEADERENCODING might be a good name. But if there was a consensus for this parameter to have a binary value, or = no value at all, I would not object. - Troy Starr -----Original Message----- From: Joseph Yee [mailto:jyee@ca.afilias.info]=20 Sent: Monday, January 17, 2011 9:16 AM To: EAI WG Subject: [EAI] Consensus Issue #1: parameter on MAIL FROM? Issue #1: parameter on MAIL FROM?=20 http://trac.tools.ietf.org/wg/eai/trac/ticket/1 Description=20 --------------- Should the WG add parameter on MAIL FROM to start EAI transaction and avoid= the need for deep inspection? --------------- Please use this thread or the issue tracker for discussion. The end date of= discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will be dr= awn afterwards. =20 Best, Joseph From eai@troystarr.net Mon Jan 17 22:36:40 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 D9BBB3A6F24 for ; Mon, 17 Jan 2011 22:36:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWQHBU4PYeSo for ; Mon, 17 Jan 2011 22:36:39 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id 6D45A3A6F25 for ; Mon, 17 Jan 2011 22:36:37 -0800 (PST) Received: from FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8]) by FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8%10]) with mapi; Mon, 17 Jan 2011 22:39:12 -0800 From: Troy Starr To: 'EAI WG' Date: Mon, 17 Jan 2011 22:39:12 -0800 Thread-Topic: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? Thread-Index: Acu2gYYo1PvgPkLmTCmZmkXTSuJP3gAVUYog Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 06:36:41 -0000 Yes, it should only be permitted after the SMTP client issued an EHLO comma= nd and saw a response that included UTF8SMTPbis. In general, I am leery of trying to establish a parameter extensibility mod= el to any of the SMTP commands in this RFC. It seems like the kind of thin= g that should happen in the core SMTP RFC (such as RFC 5321) while the actu= al extensions that take advantage of that extensibility model would be defi= ned in separate RFCs like this EAI RFC. So in the future, if someone wante= d to define another parameter extension for these SMTP commands, but not im= ply EAI support, they may have to reference the very specific portions of t= he EAI RFC that deals with parameter extensibility while explicitly ignorin= g everything else. That said, we are where we are and we need to be able to move forward. I t= hink both the server and client MUST explicitly indicate that they want the= EAI behavior for these commands, and that the client MUST NOT include para= meters on these commands if the server has not indicated support for them. = The EHLO advertisements from the server and a parameter on the commands fr= om the client seem quite reasonable to achieve this. I have no reason to b= elieve this change will be a significant burden on implementers. It might be useful to write a specific section that defines an extensibilit= y model for VRFY/EXPN for easier external reference by other RFCs, and then= a section that defines the explicit parameter that we'll be introducing fo= r EAI support. - Troy Starr -----Original Message----- From: Joseph Yee [mailto:jyee@ca.afilias.info]=20 Sent: Monday, January 17, 2011 9:16 AM To: EAI WG Subject: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EH= LO with UTF8SMTPbis? Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? http://trac.tools.ietf.org/wg/eai/trac/ticket/2 Description=20 --------------- Should the new parameter to VRFY/EXPN only be permitted after the SMTP clie= nt issued EHLO command and saw a response that included UTF8SMTPbis? --------------- Please use this thread or the issue tracker for discussion. The end date of= discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will be dr= awn afterwards. =20 Best, Joseph From Shawn.Steele@microsoft.com Mon Jan 17 23:00:56 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 2D67F3A6F90 for ; Mon, 17 Jan 2011 23:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-XLHEbt3J5p for ; Mon, 17 Jan 2011 23:00:55 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 37CE33A6F8F for ; Mon, 17 Jan 2011 23:00:55 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 23:03:31 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 23:03:31 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLtt3HSrbjteeHlk+Oe2FHbwAJBQ== Date: Tue, 18 Jan 2011 07:03:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:00:56 -0000 Character encodings are, in short, evil, and should be avoided. Most of th= e other encodings have variants, ambiguities and other inconsistencies that= make them inappropriate for reliable use. So we really shouldn't have thi= s be extensible in that direction. It's unclear to me how other extensions= might interact with, or extend EAI, but it seems that a general extensibil= ity is outside of the purview of this WG. -Shawn ------------------------------ Message: 10 Date: Mon, 17 Jan 2011 22:39:10 -0800 From: Troy Starr Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: 'EAI WG' Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Yes, it should. I would prefer it to be a parameter that takes a value, and that the value = indicates legacy behavior or EAI behavior, because I believe that makes any= potential future extensions to this standard easier to integrate. I would= prefer that the value be descriptive of the type of character encoding (AS= CII/UTF-8, or whatever terminology is deemed appropriate) rather than a sim= ple binary value, again because I believe that makes any potential future e= xtensions to this standard easier to integrate. If it had such a value, th= en a parameter name such as HEADERENCODING might be a good name. But if there was a consensus for this parameter to have a binary value, or = no value at all, I would not object. - Troy Starr= From McQuilWP@pobox.com Tue Jan 18 01:26:34 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 D86EB3A6EB9 for ; Tue, 18 Jan 2011 01:26:34 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yTeUqPZWA55 for ; Tue, 18 Jan 2011 01:26:33 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id D2C573A6DAA for ; Tue, 18 Jan 2011 01:26:32 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 0874A28B2; Tue, 18 Jan 2011 04:29:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=2uLhmP1aU9HK V4Sv/JoVZJgMn9Y=; b=T9DsNJXlK24cgfAmsSqB4Zp2lIm668Br+jWCjbjs4VUB 1kONmQtLytKLmHX2AiyY5u/ZMFkuTigZR9iYV2BfynXe6Hl0kjuB2HhIGtluuwmC olYK2TRCnlIT1Hs65Wush8jSDJg900c3zzwlKtJd6oFPOAk2enPsOHpWL1XjtRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=ddaYZA tbW4hz3IqZ+alCj8n/CPpIr1Y4IK7p7AqdhHz5WNVByA4gbBayzXV00mXbjdBUdY KeWzCu1/1/KT5JCYdG+XHZz3ZtRA2O/xl3VFndw0eS2PsdX+AZ3RN40sTWjPRuUG 9arYlwapLXW+QRAvyfM56bq+4lS5MfSypTbdA= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id E4CCF28B1; Tue, 18 Jan 2011 04:29:06 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 77E4628B0; Tue, 18 Jan 2011 04:29:05 -0500 (EST) Date: Tue, 18 Jan 2011 01:29:03 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <749808477.20110118012903@pobox.com> To: IMA Discussion In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 65A17A08-22E5-11E0-9902-D3BDF791CF9A-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 09:26:34 -0000 If there is to be a parameter on the MAIL FROM: command, it seems that it may have overloaded meanings: 1 - The message immediately following has non-ASCII 2 - The client is able to accept non-ASCII in responses to any commands related to the immediately following message This might entail a syntax like: UTF8=WITHIN or UTF8=ACCEPTED Where WITHIN implies ACCEPTED. -- Bill McQuillan From klensin@jck.com Tue Jan 18 06:21:51 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 E7EC428C0E4 for ; Tue, 18 Jan 2011 06:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaCu0fyP8zSb for ; Tue, 18 Jan 2011 06:21:51 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DAF3B28C0D6 for ; Tue, 18 Jan 2011 06:21:50 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfCTz-000O4g-Ek; Tue, 18 Jan 2011 09:24:27 -0500 Date: Tue, 18 Jan 2011 09:24:25 -0500 From: John C Klensin To: Joseph Yee , EAI WG Message-ID: <776BF023647501BC29F8F1DA@[192.168.1.6]> In-Reply-To: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:21:52 -0000 yes --On Monday, 17 January, 2011 12:15 -0500 Joseph Yee wrote: > Issue #1: parameter on MAIL FROM? > http://trac.tools.ietf.org/wg/eai/trac/ticket/1 > > Description > --------------- > > Should the WG add parameter on MAIL FROM to start EAI > transaction and avoid the need for deep inspection? > > From klensin@jck.com Tue Jan 18 06:22:38 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 D154128C0E6 for ; Tue, 18 Jan 2011 06:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YYhOQMqVIWh for ; Tue, 18 Jan 2011 06:22:37 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1498328C0D6 for ; Tue, 18 Jan 2011 06:22:37 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfCUj-000O5B-W8; Tue, 18 Jan 2011 09:25:14 -0500 Date: Tue, 18 Jan 2011 09:25:11 -0500 From: John C Klensin To: Joseph Yee , EAI WG Message-ID: <4DB1CE951BE77825D56AB295@[192.168.1.6]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:22:39 -0000 yes --On Monday, 17 January, 2011 12:15 -0500 Joseph Yee wrote: > Issue #2: new parameter to VRFY/EXPN only after EHLO with > UTF8SMTPbis? http://trac.tools.ietf.org/wg/eai/trac/ticket/2 > > Description > --------------- > > Should the new parameter to VRFY/EXPN only be permitted after > the SMTP client issued EHLO command and saw a response that > included UTF8SMTPbis? From klensin@jck.com Tue Jan 18 06:32:23 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 7503228C10C for ; Tue, 18 Jan 2011 06:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzAKAOTHITMh for ; Tue, 18 Jan 2011 06:32:22 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 50B2728C0D6 for ; Tue, 18 Jan 2011 06:32:22 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfCeA-000OFt-OS; Tue, 18 Jan 2011 09:34:59 -0500 Date: Tue, 18 Jan 2011 09:34:57 -0500 From: John C Klensin To: Joseph Yee , EAI WG Message-ID: <901FAFF275EADC2A13FBB129@[192.168.1.6]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #5: keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:32:23 -0000 Yes, keep message/global and move on. With one exception, I do not see any way to avoid this and still be able to forward EAI-style messages with addresses in header fields to EAI-unaware environments. Even then, message/rfc822 clearly does not permit headers containing characters outside the ASCII repertoire that are expressed using a coding that requires octets with the high bit on. The exception would be some "downgrade" encoding for that purpose that would expand the scope in which encoded words can be used to include addresses and perhaps additional header fields and then used some downgrade procedure to make valid message/rfc822 body parts from arbitrary messages that depended on EAI facilities. Such a proposal would also take us backwards, away from the goal of simply using UTF-8 where appropriate and into the domain of yet more long-term use of IETF-protocol-specific encodings. In any event, the WG does not have such a proposal in front of it; I believe that writing one that gets all of the cases right would require some skill and considerable work by the WG and I just do not see avoiding message/global as important enough to justify the delay the effort to generate such a proposal would cause.. to say nothing of the disadvantages of inventing and deploying yet another kludge. --On Monday, 17 January, 2011 12:15 -0500 Joseph Yee wrote: > Issue #5: keep nested encodings for message/global? > > http://trac.tools.ietf.org/wg/eai/trac/ticket/5 > > Description > --------------- > > Should the WG keep the decision about nested encodings and the > use of message/global as described in RFC5336 and RFC5336bis? > Or is a different model needed? From dhc2@dcrocker.net Tue Jan 18 07:10:58 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 4B0583A7010 for ; Tue, 18 Jan 2011 07:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwr0xdfluESn for ; Tue, 18 Jan 2011 07:10:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id D59193A7012 for ; Tue, 18 Jan 2011 07:10:55 -0800 (PST) Received: from [192.168.1.202] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0IFDRhR015462 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 07:13:33 -0800 Message-ID: <4D35AE14.4090309@dcrocker.net> Date: Tue, 18 Jan 2011 07:13:24 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bill McQuillan References: <749808477.20110118012903@pobox.com> In-Reply-To: <749808477.20110118012903@pobox.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]); Tue, 18 Jan 2011 07:13:33 -0800 (PST) Cc: IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 15:10:58 -0000 On 1/18/2011 1:29 AM, Bill McQuillan wrote: > If there is to be a parameter on the MAIL FROM: command, it seems that it > may have overloaded meanings: > > 1 - The message immediately following has non-ASCII A message can be in UTF-8 and have only ASCII. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Tue Jan 18 07:59:40 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 4E13D28C16F for ; Tue, 18 Jan 2011 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.054 X-Spam-Level: X-Spam-Status: No, score=-111.054 tagged_above=-999 required=5 tests=[AWL=0.145, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CscFXzS5d6VV for ; Tue, 18 Jan 2011 07:59:39 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 69EA928C151 for ; Tue, 18 Jan 2011 07:59:38 -0800 (PST) Received: (qmail 16558 invoked from network); 18 Jan 2011 16:02:14 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 18 Jan 2011 16:02:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b025.4d35b986.k1101; i=johnl@user.iecc.com; bh=/h+GCEIouNNq1wmxUfCcsWYCEQV36zKnj7eJW7FWRrU=; b=RVJrEzKvze8Zwc/JPwWWczNS/GYqevEkoJeDaPjDizAKNsW25a99E3umO4HxTRYDGOAZLVhXIVdxtDCSPARZLOwk+xEGIs2bccUeJbpseo0KkAqgmEJl6jyC94M8CLCUqnVFdAkkhiHJPYaJlpp35OE1TV/n25zKloLd1VyT0IU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b025.4d35b986.k1101; olt=johnl@user.iecc.com; bh=/h+GCEIouNNq1wmxUfCcsWYCEQV36zKnj7eJW7FWRrU=; b=WiZ8rxEX8ver/K3k1G8/wWLupJfUtkAhRNwJ7m8P1yICqVfd0cUT50sRZNz2ZJgAj2V3Pc5jV4VohjladQIvgXhiPpj/Kyhm94+xIAeKJghJTbwHFZ8vUgWDObVidp5pzPWjGzLFBm1xQG+vGoeDKeiNoCKOO0Aat+nh2ACIZ8A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Jan 2011 16:02:14 -0000 Message-ID: <20110118160214.45092.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <749808477.20110118012903@pobox.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: McQuilWP@pobox.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:59:40 -0000 >If there is to be a parameter on the MAIL FROM: command, it seems that it >may have overloaded meanings: > > 1 - The message immediately following has non-ASCII > > 2 - The client is able to accept non-ASCII in responses to any commands > related to the immediately following message I suppose that's hypothetically true, but I do not ever want to meet a mail client that sends a UTF-8 message but can't accept UTF-8 in the responses. For EAI, you're either on the bus or you aren't. Add my +1 to having one parameter with no options. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Tue Jan 18 08:05:21 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 CC6253A6F49 for ; Tue, 18 Jan 2011 08:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.057 X-Spam-Level: X-Spam-Status: No, score=-111.057 tagged_above=-999 required=5 tests=[AWL=0.142, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX7N+moUdExj for ; Tue, 18 Jan 2011 08:05:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 47E473A7021 for ; Tue, 18 Jan 2011 08:05:20 -0800 (PST) Received: (qmail 19583 invoked from network); 18 Jan 2011 16:07:57 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 18 Jan 2011 16:07:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b5c8.4d35badd.k1101; i=johnl@user.iecc.com; bh=iJMgsYPZjmRtxgkvNOKelJSgizvuS+2CTDRGjwVgTi0=; b=xtEqic0lOq7/3laTEE+Q95q5+x9cqES9H775gA4/zImDbDRaW+OWpAcWb+2dkwbMV8wfgDVb7EgY4z4nBcxabz1JKDtbG8DRvfgJ814evbxehZx0UKSMy7BK+hKthFGv3JfqjUPtL5CoEfWCuQH6O3G4Ja8eLMLSEB2E3ZfZPd0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b5c8.4d35badd.k1101; olt=johnl@user.iecc.com; bh=iJMgsYPZjmRtxgkvNOKelJSgizvuS+2CTDRGjwVgTi0=; b=jqJMbDd6yXEdMKlBLcyIEsMJYnCvf9y38qf8T2Ja/ZDMUe5iZXY+karjNGzfZD0PkJTy8ZN0eTjl8gnfQoTXQGTmDCHd1KK98LJ3BS+YdsDzJXFPvqfmG1S4Y3dprD4l5afnJppsrjQ/0kS4/VmItfq/5jijpgdeQvyanEEgwaQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Jan 2011 16:07:57 -0000 Message-ID: <20110118160757.46535.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: eai@troystarr.net Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:05:21 -0000 >Yes, it should only be permitted after the SMTP client issued an EHLO command and saw a response that included UTF8SMTPbis. +1 >It might be useful to write a specific section that defines an >extensibility model for VRFY/EXPN for easier external reference by >other RFCs, and then a section that defines the explicit parameter >that we'll be introducing for EAI support. I'd rather not step into that tarpit. When the followon to 5321 is written, I have no doubt that whoever is writing it will be aware of what EAI did, and can consider whether VRFY and EXPN need an extensibility model. Since this is, as far as I can tell, the first extension in 30 years, probably not. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Tue Jan 18 08:08: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 0DEC228C14A for ; Tue, 18 Jan 2011 08:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.059 X-Spam-Level: X-Spam-Status: No, score=-111.059 tagged_above=-999 required=5 tests=[AWL=0.140, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBe1t5PxC73o for ; Tue, 18 Jan 2011 08:08:02 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D5BF228C0F3 for ; Tue, 18 Jan 2011 08:08:01 -0800 (PST) Received: (qmail 21152 invoked from network); 18 Jan 2011 16:10:38 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 18 Jan 2011 16:10:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b871.4d35bb7e.k1101; i=johnl@user.iecc.com; bh=MJ7/uUm0NmERm69zpdwyav48Jks+wdZyXOaxGzXHz74=; b=h8mtHCxUoyKo8bsMA3Fsojo+/3POcgd/SmMeC7P5Jl/Ma+1Mbk1ceCAPPmJS4hgcASGM/BuK+0o0lqKdS6zv0K35Fdxs9WabyiJmxq4dzuKq4vEcgbPJXui58VQjteREaNe2Jfm47/lJzQMuLJ/00WgqbAst60VkyVrcKr3Mzkk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=b871.4d35bb7e.k1101; olt=johnl@user.iecc.com; bh=MJ7/uUm0NmERm69zpdwyav48Jks+wdZyXOaxGzXHz74=; b=C79KlEpH26qEFRzrhe3AW8QysLp+/aOnGzcQpl95rhhceAPtcRcWS/jiTghJEC+ondjRRFmLtlcZGOK5b3EJc47cOwYDRCtatnyXAh9zS4R7zV0zZxqP0+gOAwvEAKUX+jkfEEx/vPTOHloc8MinMVjsTLRH52AByR7EQ+PcVYM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Jan 2011 16:10:38 -0000 Message-ID: <20110118161038.47216.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <901FAFF275EADC2A13FBB129@[192.168.1.6]> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Consensus Issue #5: keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:08:03 -0000 >Yes, keep message/global and move on. +1 If over-eager gateways want to downgrade some subset of message/global message parts to message/rfc822, they can do it without our help. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From klensin@jck.com Tue Jan 18 09:46:35 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 7438E3A6FCF for ; Tue, 18 Jan 2011 09:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkKdokmufk60 for ; Tue, 18 Jan 2011 09:46:34 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8AB523A6E78 for ; Tue, 18 Jan 2011 09:46:34 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfFg3-0004ve-F1; Tue, 18 Jan 2011 12:49:07 -0500 Date: Tue, 18 Jan 2011 12:49:05 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: In-Reply-To: <20110118160214.45092.qmail@joyce.lan> References: <20110118160214.45092.qmail@joyce.lan> 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: McQuilWP@pobox.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:46:35 -0000 --On Tuesday, 18 January, 2011 16:02 +0000 John Levine wrote: >... > I suppose that's hypothetically true, but I do not ever want > to meet a mail client that sends a UTF-8 message but can't > accept UTF-8 in the responses. For EAI, you're either on the > bus or you aren't. >... And that should be a conformance issue elsewhere in the text. More generally, the WG has so far consistently taken the position that one is either EAI-conforming (i.e., fully i18n-email-capable) or not. I think that is consistent with the view John expresses above. john From klensin@jck.com Tue Jan 18 09:52:11 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 190FA3A6FBA for ; Tue, 18 Jan 2011 09:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lKBQC2Vib7a for ; Tue, 18 Jan 2011 09:52:09 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B2B433A6E78 for ; Tue, 18 Jan 2011 09:52:09 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfFlR-00057v-ND; Tue, 18 Jan 2011 12:54:42 -0500 Date: Tue, 18 Jan 2011 12:54:40 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <9E2E763236F9FF31A31DC59F@[192.168.1.6]> In-Reply-To: <20110118160757.46535.qmail@joyce.lan> References: <20110118160757.46535.qmail@joyce.lan> 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: eai@troystarr.net Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:52:11 -0000 --On Tuesday, 18 January, 2011 16:07 +0000 John Levine wrote: >> It might be useful to write a specific section that defines an >> extensibility model for VRFY/EXPN for easier external >> reference by other RFCs, and then a section that defines the >> explicit parameter that we'll be introducing for EAI support. > > I'd rather not step into that tarpit. When the followon to > 5321 is written, I have no doubt that whoever is writing it > will be aware of what EAI did, and can consider whether VRFY > and EXPN need an extensibility model. Since this is, as far > as I can tell, the first extension in 30 years, probably not. Procedurally, that would be a new feature and would presumably cause a reset to Proposed, It would change the conformance model so one might be able to get away with it with enough procedural-lawyering, but I'm not convinced that it would be desirable. I think the right advice about this, for other than the narrow EAI case, is the same as the advice for all other general extension models for SMTP -- develop a separate I-D to put the extension through at Proposed, diligently pursue implementation reports etc., to get that spec to Draft Standard, and then, timing permitting, argue for including the feature in 5321bis when it is prepared for Full Standard. For the record, I am neither volunteering to do that work nor recommending that anyone else do so -- just pointing out what would be procedurally correct if someone were so inclined. john \ From klensin@jck.com Tue Jan 18 10:01:16 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 6D5A93A7056 for ; Tue, 18 Jan 2011 10:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYVr3v+2oFRV for ; Tue, 18 Jan 2011 10:01:15 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 6769A3A7055 for ; Tue, 18 Jan 2011 10:01:15 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfFu7-0005P4-MA; Tue, 18 Jan 2011 13:03:39 -0500 Date: Tue, 18 Jan 2011 13:03:38 -0500 From: John C Klensin To: dcrocker@bbiw.net, Bill McQuillan Message-ID: <2B24E62B175BDF70D95A44A8@[192.168.1.6]> In-Reply-To: <4D35AE14.4090309@dcrocker.net> References: <749808477.20110118012903@pobox.com> <4D35AE14.4090309@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 Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:01:16 -0000 --On Tuesday, 18 January, 2011 07:13 -0800 Dave CROCKER wrote: > > > On 1/18/2011 1:29 AM, Bill McQuillan wrote: >> If there is to be a parameter on the MAIL FROM: command, it >> seems that it may have overloaded meanings: >> >> 1 - The message immediately following has non-ASCII > > A message can be in UTF-8 and have only ASCII. So? Assuming you are not just being pedantic for its own sake, what does that suggest to you? It was part of the WG's original reasoning for _not_ needing this parameter -- the server had asserted that it was UTF-8 capable (or whatever one wants to call it), so the client could send UTF-8 (including just the ASCII subset) without additional fussing. If the server actually needs to know whether the extended features are being used, without having to parse the message, then it seems to me that the client should tell the server what it actually knows about addresses and main and MIME headers, not assert that maybe it is sending characters outside the ASCII, 5321/5322-conforming, range and maybe it isn't. If all that parameter means is that the client is sending UTF-8 that might happen to be nothing but ASCII, then, if the server cares whether what it is getting requires extended capabilities, it needs to parse the message and its headers. And that is exactly what those who took the strongest positions in favor of this parameter seemed to me to want to avoid. john From dhc@dcrocker.net Tue Jan 18 10:12:55 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 5B0A23A7023 for ; Tue, 18 Jan 2011 10:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MByu4U2A6UQ6 for ; Tue, 18 Jan 2011 10:12:54 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 514A73A704D for ; Tue, 18 Jan 2011 10:12:54 -0800 (PST) Received: from [192.168.1.202] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0IIFQvt021287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 10:15:31 -0800 Message-ID: <4D35D8BB.5060301@dcrocker.net> Date: Tue, 18 Jan 2011 10:15:23 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John C Klensin References: <749808477.20110118012903@pobox.com> <4D35AE14.4090309@dcrocker.net> <2B24E62B175BDF70D95A44A8@[192.168.1.6]> In-Reply-To: <2B24E62B175BDF70D95A44A8@[192.168.1.6]> 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, 18 Jan 2011 10:15:32 -0800 (PST) Cc: IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 18:12:55 -0000 On 1/18/2011 10:03 AM, John C Klensin wrote: > > > --On Tuesday, 18 January, 2011 07:13 -0800 Dave CROCKER > wrote: > >> >> >> On 1/18/2011 1:29 AM, Bill McQuillan wrote: >>> If there is to be a parameter on the MAIL FROM: command, it >>> seems that it may have overloaded meanings: >>> >>> 1 - The message immediately following has non-ASCII >> >> A message can be in UTF-8 and have only ASCII. > > So? Assuming you are not just being pedantic for its own sake, > what does that suggest to you? (Thanks for that assumption and, of course, for expressing it.) As I have been repeatedly noting, this group has fallen into the pattern of using "non-ascii" as a synonym for UTF-8. It's not a synonym. An example of the error this inaccurate usage causes is to assume that someone sending an ASCII message is not working within a UTF-8 environment. > It was part of the WG's > original reasoning for _not_ needing this parameter -- the > server had asserted that it was UTF-8 capable (or whatever one > wants to call it), so the client could send UTF-8 (including > just the ASCII subset) without additional fussing. The problem was the step after that: The committee felt that the server could determine whether an incoming message was in UTF-8 by whether it contained only ASCII characters. Hence it did not require an explicit label. This was an erroneous assumption and I believe it flowed directly from this mis-use of "non-ascii". > If the > server actually needs to know whether the extended features are > being used, without having to parse the message, then it seems > to me that the client should tell the server what it actually > knows about addresses and main and MIME headers, not assert that > maybe it is sending characters outside the ASCII, > 5321/5322-conforming, range and maybe it isn't. If the message is in UTF-8, it does not matter whether it happens to have characters only inside, only outside, or inside and outside the ASCII range. What matters is that the message and the participants have declared that they are working within the set of specifications defined for UTF-8 messages. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From McQuilWP@pobox.com Tue Jan 18 10:23:24 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 11BBD3A705E for ; Tue, 18 Jan 2011 10:23:24 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1f9fqXxLPbo for ; Tue, 18 Jan 2011 10:23:22 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 77E363A6FE2 for ; Tue, 18 Jan 2011 10:23:22 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 93B221219; Tue, 18 Jan 2011 13:25:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=3vN4ZJktNoBN ZiVj+hgxbbVuSjY=; b=RBjr9YM52R1GCK/j8jmNO2SfVok1bpMPGrvGt8y/LdnA dbeUyfB9tMiHcp31cZk4PJaw0MJ4lBVOYFq7GaXimt5ERIWbiZUh34khAKUo/g25 CPBA2tCxrt+ycUBvi9k9aSPAOCtyTAuIs4hfZaWO3DNns/YPX6U/reR6IdkbNnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=raENGZ Ys8C2viE6YcGGpQKbcNab3ZCEz1tSvfOst0do0GLmJJnXW1YopYQujjHHHiZmTd5 fLRlE/35TrOylt3Ejl9iC5W+gqXYHZpkCdSTpua4hJBm5M6hNSLO/0xcINbfe2q8 z8xC5Ey6lhhw+qkpByEQBwuSgEQGxVjjp35rA= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 521CE1217; Tue, 18 Jan 2011 13:25:56 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 7FC511216; Tue, 18 Jan 2011 13:25:52 -0500 (EST) Date: Tue, 18 Jan 2011 10:25:50 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <564971012.20110118102550@pobox.com> To: IMA Discussion In-Reply-To: References: <20110118160214.45092.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 63EDDE40-2330-11E0-BE01-D3BDF791CF9A-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:23:24 -0000 On Tue, 2011-01-18, John C Klensin wrote: > --On Tuesday, 18 January, 2011 16:02 +0000 John Levine > wrote: >>... >> I suppose that's hypothetically true, but I do not ever want >> to meet a mail client that sends a UTF-8 message but can't >> accept UTF-8 in the responses. For EAI, you're either on the >> bus or you aren't. >>... > And that should be a conformance issue elsewhere in the text. > More generally, the WG has so far consistently taken the > position that one is either EAI-conforming (i.e., fully > i18n-email-capable) or not. I think that is consistent with the > view John expresses above. That's certainly right. But NOT what I was concerned with. How does an EAI compliant client express that fact when sending a message that is ASCII only? If it marks the message as UTF8, it may limit it's propagation unnecessarily, and if the client *doesn't* mark it as UTF8, it may miss out on some useful responses from the server. Case 0 - Non-EAI client; Message Header MUST be ASCII only Case 1 - EAI client; Message Header is ASCII only Case 2 - EAI client; Message Header is *not* ASCII only -- Bill McQuillan From klensin@jck.com Tue Jan 18 10:46:26 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 6BC013A705C for ; Tue, 18 Jan 2011 10:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb80gQWvyCFZ for ; Tue, 18 Jan 2011 10:46:25 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id F0B993A6E32 for ; Tue, 18 Jan 2011 10:46:24 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfGc2-0006sR-28; Tue, 18 Jan 2011 13:49:02 -0500 Date: Tue, 18 Jan 2011 13:49:00 -0500 From: John C Klensin To: dcrocker@bbiw.net Message-ID: <744A7809405397D2C4D8CB4F@[192.168.1.6]> In-Reply-To: <4D35D8BB.5060301@dcrocker.net> References: <749808477.20110118012903@pobox.com> <4D35AE14.4090309@dcrocker.net> <2B24E62B175BDF70D95A44A8@[192.168.1.6]> <4D35D8BB.5060301@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 Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:46:26 -0000 --On Tuesday, 18 January, 2011 10:15 -0800 Dave CROCKER wrote: >... >> It was part of the WG's >> original reasoning for _not_ needing this parameter -- the >> server had asserted that it was UTF-8 capable (or whatever one >> wants to call it), so the client could send UTF-8 (including >> just the ASCII subset) without additional fussing. > > The problem was the step after that: The committee felt that > the server could determine whether an incoming message was in > UTF-8 by whether it contained only ASCII characters. Hence it > did not require an explicit label. > > This was an erroneous assumption and I believe it flowed > directly from this mis-use of "non-ascii". > > > > If the >> server actually needs to know whether the extended features >> are being used, without having to parse the message, then it >> seems to me that the client should tell the server what it >> actually knows about addresses and main and MIME headers, not >> assert that maybe it is sending characters outside the ASCII, >> 5321/5322-conforming, range and maybe it isn't. > > If the message is in UTF-8, it does not matter whether it > happens to have characters only inside, only outside, or > inside and outside the ASCII range. Aha. I finally think I understand what you are talking about. I still think you are wrong, but starting to understand where we disagree is progress. First, nothing in the EAI work, with or without parameters, requires that the _message_, and its various body parts, be in UTF-8. That is why we have content-types and, for some text/ types, charset parameters (which deliberately and explicitly specify both a CCS and a particular encoding rather than a cell in a matrix). While some of us believe that gradually retiring everything on the wire other than Unicode-in-UTF-8 (even its ASCII subset) would be a good idea, making that a requirement would be well outside EAI's scope as well as implausible for the near future. So we are talking only about addresses and [other] header information, both the main set of header fields and any MIME body part headers, not "messages" or "message content". Now prior to the EAI work, the technical term for any message containing non-ASCII (and I do mean "non-ASCII", not just UTF-8 Unicode outside that range) characters was "seriously non-conforming" (or perhaps "invalid" or "broken"). If there are instances of that particular bad behavior around, addressing them is outside EAI's scope (at best). So a server that advertises availability of the EAI extension is asserting that it can accept headers and addresses in UTF-8 (yes, including nothing-but-ASCII). It is not asserting that it can handle, e.g., ISO 8859-5 or BIG5 in headers or addresses. If your reasoning is correct, the client really doesn't need to assert anything as long as what it sends is UTF-8 (which might be nothing but ASCII) in its address and header material. I.e., 5321/5322-conforming: headers and addresses are ASCII-only EAI-conforming: headers and addresses are UTF-8 only (and might be all-ASCII because that is a proper subset). But then we don't need this parameter except for one case that the WG has explicitly tried to exclude. That case arises if the server gets to advertise both UTF8SMTP and LowerSlobbovianSMTP. If that is permitted -- if we are going to accept and tolerate a whole collection of CCSs and encodings from which a client might choose, then the client would properly have to assert that its headers and addresses are Unicode-in-UTF-8, and not "something else". A better solution is to avoid specifying and standardizing such extensions. Even if that were the concern, it would be far better to simply have a provision that a given server can advertise at most one address and/or header CCS or encoding extension at a time. Anything else leads to more interesting edge cases and complexities than could possibly be wise. The much stronger argument for a parameter, IMO, is for a client to assert that it is actually using some EAI facilities and hence that any subsequent relay must make sure that those facilities are available (and can make the determination that it needs to require them without parsing all headers in the message to determine if non-ASCII (sic, but think "octets with the high bit on") characters are present. john From ned+ima@mrochek.com Tue Jan 18 10:51:36 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 A73F73A6F0B for ; Tue, 18 Jan 2011 10:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYS18PNtIlyb for ; Tue, 18 Jan 2011 10:51:34 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id D5D4B3A6E32 for ; Tue, 18 Jan 2011 10:51:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRLLPHCI800HLJO@mauve.mrochek.com> for ima@ietf.org; Tue, 18 Jan 2011 10:54:11 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRL7QI6DS007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 18 Jan 2011 10:54:09 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWRLLOJPBG007CHU@mauve.mrochek.com> Date: Tue, 18 Jan 2011 10:44:39 -0800 (PST) In-reply-to: "Your message dated Tue, 18 Jan 2011 01:29:03 -0800" <749808477.20110118012903@pobox.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <749808477.20110118012903@pobox.com> To: Bill McQuillan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295373814; bh=A6NzKgu4srGLECiLE+PH8wOBWxMArhOZNJ2cCI+a1XA=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=cw1A957t1MneOlMiPOyKbPyKkPJvYpxbHT3+MNaCutbjxCIlap+n70zBkK3b5pZwD CVVzalIFChbzlJG9U9orKO6/uiHyBxBonDgVwDVPRu54ksd/jfGT03uIkWpo/XP3C6 cInIZRiUITHGB7rkdRLLAiF5COL2gex96EiWBxsg= Cc: IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:51:36 -0000 > If there is to be a parameter on the MAIL FROM: command, it seems that it > may have overloaded meanings: > 1 - The message immediately following has non-ASCII THat's not what the proposed parameter means. The proposed parameter is an indicator that the following *transaction* may contain utf-8 in several new places. The new places include not only header fields but also envelope parameters. And since it is pretty common - and in some cases essential - to be able to return some of that now-potentially-utf-8 material in error responses, this needs to extend to server responses as well. > 2 - The client is able to accept non-ASCII in responses to any commands > related to the immediately following message You're making this sound like it is an independent thing. It's not. It's a direct consequence of sending utf-8 material (and addresses in particular). Indeed, it is easy to envision a different sort of extension that lets the language of SMTP responses be negotiated. This would almost certainly also require suport for utf-8 in SMTP server responses. But it isn't what we're considering here. > This might entail a syntax like: > UTF8=WITHIN or UTF8=ACCEPTED > Where WITHIN implies ACCEPTED. Unless you can come up with an argument for why it would be useful to allow one of these but not the other - and without getting into capabilities that go beyond what this WG is chartered to do, I see no point in having such a split. Ned From klensin@jck.com Tue Jan 18 10:54:32 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 C00083A6FAA for ; Tue, 18 Jan 2011 10:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlmUd1tGQB+8 for ; Tue, 18 Jan 2011 10:54:32 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CA7C33A6E32 for ; Tue, 18 Jan 2011 10:54:31 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfGjs-00078R-Dv; Tue, 18 Jan 2011 13:57:08 -0500 Date: Tue, 18 Jan 2011 13:57:06 -0500 From: John C Klensin To: Bill McQuillan , IMA Discussion Message-ID: <38B4C798C12D3203B705ED86@[192.168.1.6]> In-Reply-To: <564971012.20110118102550@pobox.com> References: <20110118160214.45092.qmail@joyce.lan> <564971012.20110118102550@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:54:32 -0000 --On Tuesday, 18 January, 2011 10:25 -0800 Bill McQuillan wrote: >... > That's certainly right. But NOT what I was concerned with. > > How does an EAI compliant client express that fact when > sending a message that is ASCII only? If it marks the message > as UTF8, it may limit it's propagation unnecessarily, and if > the client *doesn't* mark it as UTF8, it may miss out on some > useful responses from the server. > > Case 0 - Non-EAI client; Message Header MUST be ASCII only > > Case 1 - EAI client; Message Header is ASCII only > > Case 2 - EAI client; Message Header is *not* ASCII only This may be at the core of the discussion Dave and I are having, except that it really isn't about UTF-8 except as a consequence. If one has a parameter, the desired behavior is: * No EAI facilities used or required: no parameter associated with the extensions on MAIL. That corresponds to your cases 0 and 1 and is the same whether the server advertises UTF8SMTPbis or not. * EAI facilities used or required: appropriate parameter is sent with MAIL, VRFY, or EXPN as needed. Server actually doesn't know much more about the handling of the commands or message (other than that it can return replies that would have have conformed to 5321) but it knows that, if it relays the message, it has to require those facilities downstream without having to parse anything. john From johnl@taugh.com Tue Jan 18 11:00:11 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 1E90D3A7030 for ; Tue, 18 Jan 2011 11:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.062 X-Spam-Level: X-Spam-Status: No, score=-11.062 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KhrKx08cnob for ; Tue, 18 Jan 2011 11:00:10 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 98FA53A7057 for ; Tue, 18 Jan 2011 11:00:09 -0800 (PST) Received: (qmail 8554 invoked from network); 18 Jan 2011 19:02:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2169.4d35e3d6.k1101; i=johnl@submit.iecc.com; bh=1koRCtMoMnGKphX326OplbyxbV5wm6YssOYLorieoFk=; b=UmI4V8G1AzPE9BwWwKoAVBt/27Et7yrpi6bItzc0lXavMzL5n29Q7YXVaBDbXu5lIfS5XhjYOLwxDgYmDiVKb1luYskMFeq2678id5PSc5BuSooSyCyVV/aps8VaY3/HvZac63WzbFlQ1hD/ZPRNkyzoAhbvA984Twi0QcLKg5I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2169.4d35e3d6.k1101; olt=johnl@submit.iecc.com; bh=1koRCtMoMnGKphX326OplbyxbV5wm6YssOYLorieoFk=; b=PzD2RIklbJuek81L1sv99JZR4treS5xjIncSiyWqKaMyemdB0KpCuklLSNuPfEcBkQuVkz/itlID1X1VRt5kv12sEhBEhBM1b0mOIhKcxp2jjMJKsWxwlpGAc+Gn6Tv8BlgZMEfIiJibW7RgpZxMEkGDHDkff4MygOHPk2BQCnU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Jan 2011 19:02:24 -0000 Date: 18 Jan 2011 14:02:45 -0500 Message-ID: From: "John R Levine" To: "Bill McQuillan" In-Reply-To: <564971012.20110118102550@pobox.com> References: <20110118160214.45092.qmail@joyce.lan> <564971012.20110118102550@pobox.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:00:11 -0000 > How does an EAI compliant client express that fact when sending a message > that is ASCII only? It doesn't. I believe that the consensus is that all the efforts at selective downgrading turned out to be more trouble than they were worth. If you think that there will be enough pure ASCII mail sent to non-ASCII addresses that then forward to ASCII addresses to merit special case code to recognize and downgrade and do some kludge to fix any non-ASCII stuff in Received: headers, you still have the option of Deep Message Inspection. Personally, I think that's not sufficiently likely to be worry about. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From eai@troystarr.net Tue Jan 18 11:58:44 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 C10C63A6FB1 for ; Tue, 18 Jan 2011 11:58:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukdyx2+G41dY for ; Tue, 18 Jan 2011 11:58:43 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id 8FDF53A6F02 for ; Tue, 18 Jan 2011 11:58:43 -0800 (PST) Received: from FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8]) by FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8%10]) with mapi; Tue, 18 Jan 2011 12:01:21 -0800 From: Troy Starr To: "'ima@ietf.org'" Date: Tue, 18 Jan 2011 12:01:19 -0800 Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: Acu3OAZMfdtH0sUTQi+rDU0/flZn0gAD9Oew Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:58:45 -0000 Hi Shawn - While I don't think I have the same zeal about character encodings, I appre= ciate your concern. I don't think the working group should spend a signifi= cant amount of time trying to think about how the standard might be extende= d, but I still think it's valuable to acknowledge that it might happen for = reasons that aren't obvious to us today. And if we can design our paramete= rs to be more friendly to potential future extensions with minimal cost and= no negative impact on implementing this standard, then I think it would be= wise for us to do so. We don't need to concern ourselves with whether tho= se future extensions are good ideas - that can be safely left to future wor= king groups who wish to propose those extensions. And as I said, while I would prefer the type of design I've described, the = other proposals that have been given also meet the goal of this working gro= up and I would have no objection to them. - Troy Starr -----Original Message----- From: Shawn Steele [mailto:Shawn.Steele@microsoft.com]=20 Sent: Monday, January 17, 2011 11:04 PM To: ima@ietf.org Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? Character encodings are, in short, evil, and should be avoided. Most of th= e other encodings have variants, ambiguities and other inconsistencies that= make them inappropriate for reliable use. So we really shouldn't have thi= s be extensible in that direction. It's unclear to me how other extensions= might interact with, or extend EAI, but it seems that a general extensibil= ity is outside of the purview of this WG. -Shawn From McQuilWP@pobox.com Tue Jan 18 15:21:30 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 807A028C13C for ; Tue, 18 Jan 2011 15:21:30 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is3VfNGBvbjM for ; Tue, 18 Jan 2011 15:21:28 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 7B76028C0FA for ; Tue, 18 Jan 2011 15:21:28 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 4C568228F; Tue, 18 Jan 2011 18:24:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=wSBj18OANYt/ tBtWBsvAV6/O7iw=; b=KmJfwVOvqjIWGwQNDPjz5w31hXyH4YheYAUXsSfyJVMR cFRRpqwgugHLqJfrQ84uHfD2FMSG2hxzU6dewz75LwVztnCTKr9oP8VAzEvoOXxN mrH3hmnRR3T9hy/RezUVKCSehhlUp75G4lby3AKqZ9ZUOVrVhWKJEP6VtUzUaa0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=bcfAF7 WZCws8643ETls4D2YB+8/xXn+Xprg2AAakTlFsIpYepMhCm6oRzyPm65pYTcYeUc 5MHDzx2l0LpPTu5i7VgWxgyTktBBJMc4UpJS5oC2FOvKPrWNY2Dh6/yjmQ7xW4lQ u6eZOC4B0Z3GjDIbJbauRKPHdFUCq+VyERQ/w= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 1EA69228D; Tue, 18 Jan 2011 18:24:04 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 4E08F228C; Tue, 18 Jan 2011 18:23:58 -0500 (EST) Date: Tue, 18 Jan 2011 15:23:56 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1033592644.20110118152356@pobox.com> To: IMA Discussion In-Reply-To: <38B4C798C12D3203B705ED86@[192\.168\.1\.6]> References: <20110118160214.45092.qmail@joyce.lan> <564971012.20110118102550@pobox.com> <38B4C798C12D3203B705ED86@[192.168.1.6]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 09E16640-235A-11E0-91C9-D3BDF791CF9A-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:21:30 -0000 On Tue, 2011-01-18, John C Klensin wrote: > --On Tuesday, 18 January, 2011 10:25 -0800 Bill McQuillan > wrote: >>... >> That's certainly right. But NOT what I was concerned with. >> >> How does an EAI compliant client express that fact when >> sending a message that is ASCII only? If it marks the message >> as UTF8, it may limit it's propagation unnecessarily, and if >> the client *doesn't* mark it as UTF8, it may miss out on some >> useful responses from the server. >> >> Case 0 - Non-EAI client; Message Header MUST be ASCII only >> >> Case 1 - EAI client; Message Header is ASCII only >> >> Case 2 - EAI client; Message Header is *not* ASCII only > This may be at the core of the discussion Dave and I are having, > except that it really isn't about UTF-8 except as a consequence. > If one has a parameter, the desired behavior is: > * No EAI facilities used or required: no parameter associated > with the extensions on MAIL. That corresponds to your cases 0 > and 1 and is the same whether the server advertises UTF8SMTPbis > or not. I am concerned about the case where the client does NOT know that there is an EAI facility needed, but THERE IS a need! For example, a client (which is EAI compliant) is handed a message (say, by SUBMISSION) which has no non-ASCII recipients or non-ASCII in its header. The client contacts the MX server for one or more of the recipients and begins a transaction with MAIL FROM: using *no* UTF8 parameter. It then sends RCPT TO: commands until one of the recipients has a forwarding address and the MX server would like to return a 551 reply suggesting a . However, the is a non-ASCII address and the MX server has no way to return this to the client since the client must be presumed to be NON-EAI compliant due to the lack of a UTF8 parameter on the MAIL FROM: command. This all presumes we are using the UTF8 parameter to both relieve the MX server from Deep-Analysis as well as informing it of the capabilities of the client. > * EAI facilities used or required: appropriate parameter is sent > with MAIL, VRFY, or EXPN as needed. Server actually doesn't > know much more about the handling of the commands or message > (other than that it can return replies that would have have > conformed to 5321) but it knows that, if it relays the message, > it has to require those facilities downstream without having to > parse anything. > john > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima -- Bill McQuillan From ned+ima@mrochek.com Tue Jan 18 16:26:33 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 BE5183A6E63 for ; Tue, 18 Jan 2011 16:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjEvVHOXmog0 for ; Tue, 18 Jan 2011 16:26:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 7B66B3A6DB6 for ; Tue, 18 Jan 2011 16:26:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRXAZ6Z4W00GWX1@mauve.mrochek.com> for ima@ietf.org; Tue, 18 Jan 2011 16:29:08 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRL7QI6DS007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 18 Jan 2011 16:29:05 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWRXAXUKQU007CHU@mauve.mrochek.com> Date: Tue, 18 Jan 2011 16:06:35 -0800 (PST) In-reply-to: "Your message dated Tue, 18 Jan 2011 15:23:56 -0800" <1033592644.20110118152356@pobox.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110118160214.45092.qmail@joyce.lan> <564971012.20110118102550@pobox.com> <38B4C798C12D3203B705ED86@[192.168.1.6]> <38B4C798C12D3203B705ED86@[192\.168\.1\.6]> <1033592644.20110118152356@pobox.com> To: Bill McQuillan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295393910; bh=AP//pwRN2yo0bkC6tzMVbHZR4m4eXQQsJRVifOqhuWM=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=BJMEEQRGY/TC/KLrPd7tlAcNt8rfWGb5sJYpt5SvynAoGH3GNj6Q0+REbb4nOFKp7 Eg5Cy0TilOCwpXkcfGblVtNotb+yLM+b+1lgXSR4+okKPZoz8MP8dl/U5wExxG4nBk ocxXAHw1mOC1FHfltLefj8CjdRd6kKUwszZtGKvU= Cc: IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 00:26:33 -0000 > I am concerned about the case where the client does NOT know that there is > an EAI facility needed, but THERE IS a need! OK, now I see what you're getting at. My problem with this is that in my experience the use of the address correction facilities in RFC 5321 is quite rare, bordering on nonexistent. I'd like to see some evidence that such facilities are not just in some code somewhere, but in such active use that the costs of complicating this proposal are worth the added benefit of supporting this capability for non-ASCII responses. The tradeoff here may seem to be similar to when we decide whether or not to retain some obscure feature in some specification (like, say, all the obsolete syntax in RFC 5322), but it really isn't. The difference is in fact rather stark: Support costs versus deployment costs. Most of the support costs for obscure existing are, in one way or another, sunk costs, e.g., if you have code that supports source routes, you've already paid the price of developing that code. Deployment costs are another matter. These are mostly future costs and hence have a direct impact on deployability - the more complex and costly this stuff is to implement and operate, the less people are going to be willing to be early adopters. Raise the cost too high, and this dog is not going to hunt. And that more than anything is my goal here - I want this specification to be as simole and as easy to implement as possible, because otherwise I think this group is going to be very surprised at just how little large parts of the world care about having the ability to put utf-8 in addresses. > For example, a client (which is EAI compliant) is handed a message (say, by > SUBMISSION) which has no non-ASCII recipients or non-ASCII in its header. > The client contacts the MX server for one or more of the recipients and > begins a transaction with MAIL FROM: using *no* UTF8 parameter. > It then sends RCPT TO: commands until one of the recipients has a > forwarding address and the MX server would like to return a 551 reply > suggesting a . However, the is a non-ASCII > address and the MX server has no way to return this to the client since the > client must be presumed to be NON-EAI compliant due to the lack of a UTF8 > parameter on the MAIL FROM: command. > This all presumes we are using the UTF8 parameter to both relieve the MX server > from Deep-Analysis as well as informing it of the capabilities of the > client. I think the avoidance of message inspection is vitally important, but let's not forget this also facilities early rejection of messages on a per-recipient basis as well. Ned From duerst@it.aoyama.ac.jp Tue Jan 18 23:01:08 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 5AF873A6EF5 for ; Tue, 18 Jan 2011 23:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.309 X-Spam-Level: X-Spam-Status: No, score=-100.309 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 asPcwwopNIXO for ; Tue, 18 Jan 2011 23:01:07 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 15B063A6E7E for ; Tue, 18 Jan 2011 23:01:06 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0J73dTH028378 for ; Wed, 19 Jan 2011 16:03:39 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 31bc_e6b7_3e0c34d2_239a_11e0_a4bb_001d096c566a; Wed, 19 Jan 2011 16:03:39 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48619) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 19 Jan 2011 16:03:39 +0900 Message-ID: <4D368CC8.6000300@it.aoyama.ac.jp> Date: Wed, 19 Jan 2011 16:03:36 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joseph Yee References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> In-Reply-To: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: EAI WG Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:01:08 -0000 On 2011/01/18 2:15, Joseph Yee wrote: > Issue #1: parameter on MAIL FROM? > http://trac.tools.ietf.org/wg/eai/trac/ticket/1 > > Description > --------------- > > Should the WG add parameter on MAIL FROM to start EAI transaction and avoid the need for deep inspection? Yes. To the extent possible, the parameter should be short. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Tue Jan 18 23:02:27 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 74B023A6E7E for ; Tue, 18 Jan 2011 23:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.298 X-Spam-Level: X-Spam-Status: No, score=-100.298 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 ZX+tS9ozIzzw for ; Tue, 18 Jan 2011 23:02:26 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 33B943A70CD for ; Tue, 18 Jan 2011 23:02:25 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0J753fw008767 for ; Wed, 19 Jan 2011 16:05:03 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 31ad_9c1a_6f5b9cda_239a_11e0_a4bb_001d096c566a; Wed, 19 Jan 2011 16:05:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48635) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 19 Jan 2011 16:05:02 +0900 Message-ID: <4D368D1B.5040406@it.aoyama.ac.jp> Date: Wed, 19 Jan 2011 16:04:59 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joseph Yee References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: EAI WG Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:02:27 -0000 On 2011/01/18 2:15, Joseph Yee wrote: > Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? > http://trac.tools.ietf.org/wg/eai/trac/ticket/2 > > Description > --------------- > > Should the new parameter to VRFY/EXPN only be permitted after the SMTP client issued EHLO command and saw a response that included UTF8SMTPbis? Yes. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Tue Jan 18 23:03:39 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 977193A70E9 for ; Tue, 18 Jan 2011 23:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.211 X-Spam-Level: X-Spam-Status: No, score=-100.211 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, 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 6Wv1YdsqQniK for ; Tue, 18 Jan 2011 23:03:38 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 8B9183A6E7E for ; Tue, 18 Jan 2011 23:03:38 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0J76H6C009822 for ; Wed, 19 Jan 2011 16:06:17 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 31b5_768f_9c57f24c_239a_11e0_a4bb_001d096c566a; Wed, 19 Jan 2011 16:06:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48656) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 19 Jan 2011 16:06:18 +0900 Message-ID: <4D368D66.8020904@it.aoyama.ac.jp> Date: Wed, 19 Jan 2011 16:06:14 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:03:39 -0000 I agree with Shawn. Regards, Martin. On 2011/01/18 10:02, Shawn Steele wrote: >> Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? > >> Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" with new or >> different term s that precisely and accurately identify what is intended? > > I am happy with these terms and think the intent is understandable in context. I don't object if someone has another idea, but I don't want deciding on these to slow down the working group. > > -Shawn > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Tue Jan 18 23:05:40 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 63F863A70E8 for ; Tue, 18 Jan 2011 23:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.276 X-Spam-Level: X-Spam-Status: No, score=-100.276 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 z0YHOpa3XRDt for ; Tue, 18 Jan 2011 23:05:39 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 6A2F13A70DC for ; Tue, 18 Jan 2011 23:05:38 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0J78Hgs032501 for ; Wed, 19 Jan 2011 16:08:17 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2d53_44e4_e3c8c566_239a_11e0_8b02_001d096c5782; Wed, 19 Jan 2011 16:08:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52549) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 19 Jan 2011 16:08:17 +0900 Message-ID: <4D368DDE.8070409@it.aoyama.ac.jp> Date: Wed, 19 Jan 2011 16:08:14 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #6: current metalanguage model acceptable? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:05:40 -0000 I agree with Shawn. Regards, Martin. On 2011/01/18 10:05, Shawn Steele wrote: > >> Issue #6: current metalanguage model acceptable? > >> Once errors are corrected, is the current metalanguage model (including the 'u' prefixes) >> acceptable? > > I don't mind either way. > >> If not, should only those rules be included that are modified from RFC 5321 or 5322 >> respectively, forcing the user to reference the original documents for parts of substantially every rule? > > If it's going to be changed and doesn't delay the process, I think it'd be easier to just change the modified rules, and refer to the original documents. (Note that this allows revisions to the original documents to work, and avoids confusing in case of an error). However I'd prefer whichever path produces the fastest results. > > -Shawn > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From McQuilWP@pobox.com Wed Jan 19 00:04:25 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 239753A70E6 for ; Wed, 19 Jan 2011 00:04:25 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMJf0jtTCaMe for ; Wed, 19 Jan 2011 00:04:24 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 0E5313A6F90 for ; Wed, 19 Jan 2011 00:04:23 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id DF6A62B30; Wed, 19 Jan 2011 03:07:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=Jg0+W7oYbwya uO4jWpkqQLeRd8Q=; b=gmZzXHjLko0+BxurVh5wMtXwWHYfFMzbLPOH0R4lSEoj yS/bKRfXpvXJ0WErSx9bQ/iUr9XFjKjMBp28VotjDoGOOP+DC35s4s9tU5xsBEGS LHKuTIje/8beUtEZc/ZtgJBgbBp7tpXStfefffwNXe+FgkeDeQxY1wBysFWkioU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=jX/Rad KnHNLpu+dphl9fHehAJtkwCXn5XNPYRP3KD8nQYYBz8mW2umYhASzDe8HfPHSuPu LIW8ewkUkHIrTlbbHcEDIbrsgykaEVn2g7utfPVZhR46uh3hY6NNvDMngP4aeZQK F//Vw852RCc8rBQdxWfExOGyHETdhNA1i4fDw= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id B3EEF2B2F; Wed, 19 Jan 2011 03:07:00 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id C4B412B21; Wed, 19 Jan 2011 03:06:57 -0500 (EST) Date: Wed, 19 Jan 2011 00:06:55 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <636117746.20110119000655@pobox.com> To: IMA Discussion In-Reply-To: <01NWRXAXUKQU007CHU@mauve.mrochek.com> References: <20110118160214.45092.qmail@joyce.lan> <564971012.20110118102550@pobox.com> <38B4C798C12D3203B705ED86@[192.168.1.6]> <38B4C798C12D3203B705ED86@[192\.168\.1\.6]> <1033592644.20110118152356@pobox.com> <01NWRXAXUKQU007CHU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 17BAA72E-23A3-11E0-AD46-D3BDF791CF9A-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 08:04:25 -0000 On Tue, 2011-01-18, ned+ima@mrochek.com wrote: >> I am concerned about the case where the client does NOT know that there is >> an EAI facility needed, but THERE IS a need! > OK, now I see what you're getting at. My problem with this is that in my > experience the use of the address correction facilities in RFC 5321 is quite > rare, bordering on nonexistent. I'd like to see some evidence that such > facilities are not just in some code somewhere, but in such active use that the > costs of complicating this proposal are worth the added benefit of supporting > this capability for non-ASCII responses. > The tradeoff here may seem to be similar to when we decide whether or not to > retain some obscure feature in some specification (like, say, all the obsolete > syntax in RFC 5322), but it really isn't. The difference is in fact rather > stark: Support costs versus deployment costs. > Most of the support costs for obscure existing are, in one way or another, sunk > costs, e.g., if you have code that supports source routes, you've already paid > the price of developing that code. > Deployment costs are another matter. These are mostly future costs and hence > have a direct impact on deployability - the more complex and costly this stuff > is to implement and operate, the less people are going to be willing to be > early adopters. Raise the cost too high, and this dog is not going to hunt. And > that more than anything is my goal here - I want this specification to be as > simole and as easy to implement as possible, because otherwise I think this > group is going to be very surprised at just how little large parts of the world > care about having the ability to put utf-8 in addresses. My main concern was to raise this issue for completeness sake. I defer to others with more recent operational and development experience as to the importance of this special case. -- Bill McQuillan From klensin@jck.com Wed Jan 19 04:40:05 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 C14293A710F for ; Wed, 19 Jan 2011 04:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEIrOuuJxLf5 for ; Wed, 19 Jan 2011 04:40:05 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id ED4AC3A6FD9 for ; Wed, 19 Jan 2011 04:40:04 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfXN4-0009QM-D3; Wed, 19 Jan 2011 07:42:42 -0500 Date: Wed, 19 Jan 2011 07:42:41 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Joseph Yee Message-ID: <8BFCED19C12258D99A1451A9@[192.168.1.6]> In-Reply-To: <4D368CC8.6000300@it.aoyama.ac.jp> References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> <4D368CC8.6000300@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 12:40:05 -0000 --On Wednesday, 19 January, 2011 16:03 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > On 2011/01/18 2:15, Joseph Yee wrote: >> Issue #1: parameter on MAIL FROM? >> http://trac.tools.ietf.org/wg/eai/trac/ticket/1 >>=20 >> Description >> --------------- >>=20 >> Should the WG add parameter on MAIL FROM to start EAI >> transaction and avoid the need for deep inspection? >=20 > Yes. To the extent possible, the parameter should be short. Out of curiousity, because? Remember that this parameter is part of the SMTP envelope only -- users never see these things; most users would be unable to see them if they wanted to and knew how to look for them (it requires either looking inside an MTA or intercepting MTA-MTA transactions). I don't object to "short", but am wondering why you think it is important. john From Shawn.Steele@microsoft.com Wed Jan 19 09:27:55 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 A42C628C0DB for ; Wed, 19 Jan 2011 09:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLP+upc8Fvog for ; Wed, 19 Jan 2011 09:27:53 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E67EB28C0D8 for ; Wed, 19 Jan 2011 09:27:52 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 09:30:26 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 09:30:26 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLt/6Ol6CXVYikRECtXQ1SEnKkRw== Date: Wed, 19 Jan 2011 17:30: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.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:27:56 -0000 IMO that's way more complex than is necessary. Either the client understan= ds EAI or it doesn't. -Shawn ------------------------------ Message: 2 Date: Tue, 18 Jan 2011 01:29:03 -0800 From: Bill McQuillan Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: IMA Discussion Message-ID: <749808477.20110118012903@pobox.com> Content-Type: text/plain; charset=3Dus-ascii If there is to be a parameter on the MAIL FROM: command, it seems that it may have overloaded meanings: 1 - The message immediately following has non-ASCII 2 - The client is able to accept non-ASCII in responses to any commands related to the immediately following message This might entail a syntax like: UTF8=3DWITHIN or UTF8=3DACCEPTED Where WITHIN implies ACCEPTED. -- Bill McQuillan = From Shawn.Steele@microsoft.com Wed Jan 19 09:34:56 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 5501728C0FD for ; Wed, 19 Jan 2011 09:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPADNGPi2q1L for ; Wed, 19 Jan 2011 09:34:55 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 5B36728C102 for ; Wed, 19 Jan 2011 09:34:55 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 09:37:36 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 09:37:35 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLt/+OL3gOcQrXbUSzW8PTBVNfPw== Date: Wed, 19 Jan 2011 17:37:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:34:56 -0000 IMO: An EAI compliant client shouldn't be sending "ASCII" mail, it should b= e sending "UTF-8" mail (even if it only contains ASCII range characters). = Sure they're the same, but there's no reason the client, or the server, nee= d to care because they're both EAI aware. *IF* the recipient wants to forward the message, his end can worry about wh= at to do with the encoding at that time. And if the server wants to send i= t on to a non-EAI server, then it can deal with it at that time. Forcing t= he client to parse and continue to support this information, forever, even = after 99% of the servers support EAI, is a waste of effort. A system of EAI aware servers shouldn't care what range of characters is en= coded within a UTF-8 encoded mail. -Shawn ------------------------------ Message: 4 Date: Tue, 18 Jan 2011 10:25:50 -0800 From: Bill McQuillan Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: IMA Discussion Message-ID: <564971012.20110118102550@pobox.com> Content-Type: text/plain; charset=3Dus-ascii On Tue, 2011-01-18, John C Klensin wrote: > --On Tuesday, 18 January, 2011 16:02 +0000 John Levine > wrote: >>... >> I suppose that's hypothetically true, but I do not ever want >> to meet a mail client that sends a UTF-8 message but can't >> accept UTF-8 in the responses. For EAI, you're either on the >> bus or you aren't. >>... > And that should be a conformance issue elsewhere in the text. > More generally, the WG has so far consistently taken the > position that one is either EAI-conforming (i.e., fully > i18n-email-capable) or not. I think that is consistent with the > view John expresses above. That's certainly right. But NOT what I was concerned with. How does an EAI compliant client express that fact when sending a message that is ASCII only? If it marks the message as UTF8, it may limit it's propagation unnecessarily, and if the client *doesn't* mark it as UTF8, it may miss out on some useful responses from the server. Case 0 - Non-EAI client; Message Header MUST be ASCII only Case 1 - EAI client; Message Header is ASCII only Case 2 - EAI client; Message Header is *not* ASCII only -- Bill McQuillan = From Shawn.Steele@microsoft.com Wed Jan 19 09:38:40 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 77C6D28C106 for ; Wed, 19 Jan 2011 09:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TWSCT5pYouQ for ; Wed, 19 Jan 2011 09:38:39 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B0B2D28C105 for ; Wed, 19 Jan 2011 09:38:39 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 09:41:20 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 09:41:20 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLuAAUzCe5Ex1j5kG6ANd8fzo1wg== Date: Wed, 19 Jan 2011 17:41:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:38:40 -0000 Nothing requires UTF-8, but we certainly strongly suggest that EAI messages= are entirely UTF-8. IMO you'd be a pretty ugly EAI implementation if that= wasn't your default. ------------------------------ Message: 5 Date: Tue, 18 Jan 2011 13:49:00 -0500 From: John C Klensin Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: dcrocker@bbiw.net Cc: IMA Discussion Message-ID: <744A7809405397D2C4D8CB4F@[192.168.1.6]> Content-Type: text/plain; charset=3Dus-ascii ... First, nothing in the EAI work, with or without parameters, requires that the _message_, and its various body parts, be in UTF-8. That is why we have content-types and, for some text/ types, charset parameters (which deliberately and explicitly specify both a CCS and a particular encoding rather than a cell in a matrix). While some of us believe that gradually retiring everything on the wire other than Unicode-in-UTF-8 (even its ASCII subset) would be a good idea, making that a requirement would be well outside EAI's scope as well as implausible for the near future. ...= From Shawn.Steele@microsoft.com Wed Jan 19 09:45:19 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 3A07528C10F for ; Wed, 19 Jan 2011 09:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.434 X-Spam-Level: X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VviiXC6AxaWV for ; Wed, 19 Jan 2011 09:45:17 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A9C073A7044 for ; Wed, 19 Jan 2011 09:45:17 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 09:47:58 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 09:47:58 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLuADu5ym/sOVg60CpHPlo/tGfeg== Date: Wed, 19 Jan 2011 17:47:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:45:19 -0000 PiAqIE5vIEVBSSBmYWNpbGl0aWVzIHVzZWQgb3IgcmVxdWlyZWQ6IG5vIHBhcmFtZXRlciBhc3Nv Y2lhdGVkDQo+IHdpdGggdGhlIGV4dGVuc2lvbnMgb24gTUFJTC4gIFRoYXQgY29ycmVzcG9uZHMg dG8geW91ciBjYXNlcyAwDQo+IGFuZCAxIGFuZCBpcyB0aGUgc2FtZSB3aGV0aGVyIHRoZSBzZXJ2 ZXIgYWR2ZXJ0aXNlcyBVVEY4U01UUGJpcw0KPiBvciBub3QuDQoNClRoaXMgaW5mb3JtYXRpb24g c2hvdWxkIGJlIGlycmVsZXZlbnQuICBJZiB5b3VyIHN5c3RlbSBzdXBwb3J0cyBFQUkgKHdoaWNo IGlzICJqdXN0IiBwYXJzaW5nIHRoZSBtYWlsIHdpdGggVVRGLTggaW5zdGVhZCBvZiBBU0NJSSks IHRoZW4gaXQgc2hvdWxkbid0IG1hdHRlciBpZiBhIHBhcnRpY3VsYXIgbWVzc2FnZSBpcyBzcGVj aWZpY2FsbHkgRUFJIG9yIG5vdC4gIFN1cmUsIGlmIHRoZSByZWNlaXZpbmcgZW5kIHdhbnRzIHRv IGRvIHNvbWV0aGluZyBzbWFydCBpdCBtYXkgaGF2ZSB0byBmaWd1cmUgb3V0IHdoYXQgdG8gZG8g d2l0aCBpdCwgYnV0IHRoYXQncyB0aGUgc2FtZSB0aGluZyB0aGF0IGhhcHBlbnMgaWYgaXQgc2Vu ZHMgbWFpbCBmcm9tIGFuIEVITE8gZW52aXJvbm1lbnQgdG8gSEVMTywgb3IgOEJJVE1JTUUgdG8g YSA3IGJpdCBlbnZpcm9ubWVudCwgZXRjLiAgDQoNCkJ1dCwgYXNzdW1pbmcgdGhhdCB0aGUgc3lz dGVtIHN1cHBvcnRzIEVBSSBiZWNhdXNlIGl0IGFjdHVhbGx5IGludGVuZHMgdG8gdXNlIGl0LCB0 aGVuIGl0IHNob3VsZG4ndCBoYXZlIGFueSBtaXNzaW5nIHBpZWNlcy4uLiAgQXQgdGhlIHZlcnkg bGVhc3QsIGFueXRoaW5nIHRoYXQgbmVlZGVkIHRoaXMgaW5mb3JtYXRpb24gc2hvdWxkIGJlICJ0 ZW1wb3JhcnkiLi4uDQoNCi1TaGF3bg0KDQrvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZDQpo dHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGU= From Shawn.Steele@microsoft.com Wed Jan 19 09:52:40 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 4F4DF3A7184 for ; Wed, 19 Jan 2011 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nNTrN6M53ib for ; Wed, 19 Jan 2011 09:52:39 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6DA2E3A7182 for ; Wed, 19 Jan 2011 09:52:39 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 09:55:20 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 09:55:17 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLuAHLyRjjn7aL3kCQoio9ejr/aA== Date: Wed, 19 Jan 2011 17:55:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:52:40 -0000 Since you have no objection, I suppose my reply is irrelevent, however: IMO saying "UTF8SMTP" or whatever describes the behavior of EAI. "Extendin= g" EAI to another encoding is a non-starter. Other extensions may be usefu= l, but I don't see how adding EAI parameters helps as we cannot foresee the= direction of the extension, and it's out of the scope of the WG to (re)def= ine extension methods. I don't see needing EAI-specific extensions in the = future, though I could be short-sighted. I suppose if we had a "Human languages the user can read" extension to faci= litate machine translation, or at least correct selection of response langu= age, that could include "LANGUAGES: en, de, es", then perhaps there'd be an= international-related extension to the standard. Even in that case, I don= 't see why it couldn't have it's own "LANG" extension with whatever syntax = that extension needed. Assuming we really screw up EAI and need to "fix" it, we always have the op= tion of changing the tag to "UTF8V2" or something. -Shawn ------------------------------ Message: 2 Date: Tue, 18 Jan 2011 12:01:19 -0800 From: Troy Starr Subject: Re: [EAI] To: "'ima@ietf.org'" Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Shawn - While I don't think I have the same zeal about character encodings, I appre= ciate your concern. I don't think the working group should spend a signifi= cant amount of time trying to think about how the standard might be extende= d, but I still think it's valuable to acknowledge that it might happen for = reasons that aren't obvious to us today. And if we can design our paramete= rs to be more friendly to potential future extensions with minimal cost and= no negative impact on implementing this standard, then I think it would be= wise for us to do so. We don't need to concern ourselves with whether tho= se future extensions are good ideas - that can be safely left to future wor= king groups who wish to propose those extensions. And as I said, while I would prefer the type of design I've described, the = other proposals that have been given also meet the goal of this working gro= up and I would have no objection to them. - Troy Starr= From Shawn.Steele@microsoft.com Wed Jan 19 09:59: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 D121D3A7187 for ; Wed, 19 Jan 2011 09:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K66lM9dDc6mX for ; Wed, 19 Jan 2011 09:59:03 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B32113A6FCF for ; Wed, 19 Jan 2011 09:59:03 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 10:01:38 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 10:01:38 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLuALhtm3SkVVbk0CBtAeNuxW53w== Date: Wed, 19 Jan 2011 18:01:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:59:04 -0000 RXhhY3RseT8gIElmIEknbSBhbiBFQUkgYXdhcmUgY2xpZW50IGFuZCBJJ20gY29ubmVjdGluZyB0 byBhbiBFQUkgYXdhcmUgc2VydmVyLCB0aGVuIEkgU0hPVUxEIHJlYWxseSB1c2UgdGhlIFVURjgg TUFJTCBGUk9NLg0KDQpUaGUgdmFsdWUgb2YgTUFJTCBGUk9NIGlzIHRvIGNvbXBsZXRlIHRoZSBo YW5kc2hha2luZywgc28gdGhlIHNlcnZlciBrbm93cyB0aGF0IHRoZSBjbGllbnQgaXMgRUFJIGF3 YXJlLiAgTm9ib2R5IHNob3VsZCBiZSBpbnNwZWN0aW5nIGV2ZXJ5IG1lc3NhZ2UuDQoNClRoZSBv bmUgZXhjZXB0aW9uIGNvdWxkIGJlIGlmIG15IEVBSSBhd2FyZSBjbGllbnQgaXMgcGFzc2luZyBh bG9uZyBhIG1lc3NhZ2UgaXQgZ290IGZyb20gYSBub24tRUFJIHNvdXJjZSwgaW4gd2hpY2ggY2Fz ZSBpdCBjb3VsZCBhdm9pZCB0aGUgTUFJTCBGUk9NIFVURjgsIHRvIGF2b2lkIHRoZSByaXNrIG9m IGFueSByZXNwb25zZSBicmVha2luZyB0aGUgcmV0dXJuIHBhdGguICBBbnkgbWVzc2FnZXMgZ2Vu ZXJhdGVkIGZyb20gdGhlIEVBSSBhd2FyZSBzeXN0ZW0gU0hPVUxEIHVzZSB0aGUgVVRGOCB0YWcg dGhvdWdoLg0KDQotU2hhd24NCg0K76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmQ0KaHR0cDov L2Jsb2dzLm1zZG4uY29tL3NoYXduc3RlDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAx DQpEYXRlOiBUdWUsIDE4IEphbiAyMDExIDE1OjIzOjU2IC0wODAwDQpGcm9tOiBCaWxsIE1jUXVp bGxhbiA8TWNRdWlsV1BAcG9ib3guY29tPg0KU3ViamVjdDogUmU6IFtFQUldIENvbnNlbnN1cyBJ c3N1ZSAjMTogIHBhcmFtZXRlciBvbiBNQUlMIEZST00/DQpUbzogSU1BIERpc2N1c3Npb24gPGlt YUBpZXRmLm9yZz4NCk1lc3NhZ2UtSUQ6IDwxMDMzNTkyNjQ0LjIwMTEwMTE4MTUyMzU2QHBvYm94 LmNvbT4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11cy1hc2NpaQ0KDQpJIGFt IGNvbmNlcm5lZCBhYm91dCB0aGUgY2FzZSB3aGVyZSB0aGUgY2xpZW50IGRvZXMgTk9UIGtub3cg dGhhdCB0aGVyZSBpcw0KYW4gRUFJIGZhY2lsaXR5IG5lZWRlZCwgYnV0IFRIRVJFIElTIGEgbmVl ZCENCg0KRm9yIGV4YW1wbGUsIGEgY2xpZW50ICh3aGljaCBpcyBFQUkgY29tcGxpYW50KSBpcyBo YW5kZWQgYSBtZXNzYWdlIChzYXksIGJ5DQpTVUJNSVNTSU9OKSB3aGljaCBoYXMgbm8gbm9uLUFT Q0lJIHJlY2lwaWVudHMgb3Igbm9uLUFTQ0lJIGluIGl0cyBoZWFkZXIuDQpUaGUgY2xpZW50IGNv bnRhY3RzIHRoZSBNWCBzZXJ2ZXIgZm9yIG9uZSBvciBtb3JlIG9mIHRoZSByZWNpcGllbnRzIGFu ZA0KYmVnaW5zIGEgdHJhbnNhY3Rpb24gd2l0aCBNQUlMIEZST006IHVzaW5nICpubyogVVRGOCBw YXJhbWV0ZXIuDQoNCkl0IHRoZW4gc2VuZHMgUkNQVCBUTzogY29tbWFuZHMgdW50aWwgb25lIG9m IHRoZSByZWNpcGllbnRzIGhhcyBhDQpmb3J3YXJkaW5nIGFkZHJlc3MgYW5kIHRoZSBNWCBzZXJ2 ZXIgd291bGQgbGlrZSB0byByZXR1cm4gYSA1NTEgcmVwbHkNCnN1Z2dlc3RpbmcgYSA8Zm9yd2Fy ZC1wYXRoPi4gSG93ZXZlciwgdGhlIDxmb3J3YXJkLXBhdGg+IGlzIGEgbm9uLUFTQ0lJDQphZGRy ZXNzIGFuZCB0aGUgTVggc2VydmVyIGhhcyBubyB3YXkgdG8gcmV0dXJuIHRoaXMgdG8gdGhlIGNs aWVudCBzaW5jZSB0aGUNCmNsaWVudCBtdXN0IGJlIHByZXN1bWVkIHRvIGJlIE5PTi1FQUkgY29t cGxpYW50IGR1ZSB0byB0aGUgbGFjayBvZiBhIFVURjgNCnBhcmFtZXRlciBvbiB0aGUgTUFJTCBG Uk9NOiBjb21tYW5kLg0KDQpUaGlzIGFsbCBwcmVzdW1lcyB3ZSBhcmUgdXNpbmcgdGhlIFVURjgg cGFyYW1ldGVyIHRvIGJvdGggcmVsaWV2ZSB0aGUgTVggc2VydmVyDQpmcm9tIERlZXAtQW5hbHlz aXMgYXMgd2VsbCBhcyBpbmZvcm1pbmcgaXQgb2YgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUNCmNs aWVudC4NCg0KQmlsbCBNY1F1aWxsYW4gPE1jUXVpbFdQQHBvYm94LmNvbT4= From klensin@jck.com Wed Jan 19 10:21:42 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 6F5F828C0F0 for ; Wed, 19 Jan 2011 10:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWdDwGgKNpGl for ; Wed, 19 Jan 2011 10:21:41 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AACA528C0E7 for ; Wed, 19 Jan 2011 10:21:40 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pfchf-000JFj-Ry; Wed, 19 Jan 2011 13:24:20 -0500 Date: Wed, 19 Jan 2011 13:24:18 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:21:42 -0000 Hmm. It seems to me that we have another, more fundamental, issue here. I'm not trying to do a formal appraisal of consensus (Joseph's problem), but it seems to me that among those who have advocated a keyword (without counting, at least a majority so far), there are two separate opinions about what it means: (1) A handshake announcement that the client is EAI-capable (see Shawn's note below as an example) (2) An announcement from the client to the server that the message actually requires (or at least probably requires) EAI capabilities. FWIW, note that the _only_ reply text that require EAI-capability are those to VRFY and EXPN and the "new address" codes, which we have nearly, but not quite, deprecated in broader Internet contexts (e.g., non-enterprise ones). Those three cases need to return addresses, nothing else does. Inclusion of mailbox names in replies to MAIL, RCPT, or any other command is not required or suggested in RFC 5321 and, at least in my experience, is uncommon. If we go with the "handshake" model, then there is no issue with replies containing text not permitted by 5321 (i.e., text containing Unicode characters with code points above U+007F, encoded in UTF-8). But a server that actually needs to know whether a message requires EAI capabilities (e.g., to deliver it to a message store with appropriate information for POP or IMAP clients) has to parse the message. If we go with the "announcement" model, then the parsing problem is eliminated but there is no possibility of replies that are invalid under 5321 when the announcement is not made, i.e., when the message, headers, and addresses are strictly 5321-conforming. Speaking personally, I could live with either decision although I have a preference. But we need to resolve this difference and have an unambiguous interpretation for the authors of 5336bis to complete their work. I assume that will require a separate consensus call but hope we can have enough discussion first that everyone understands both options. john --On Wednesday, 19 January, 2011 18:01 +0000 Shawn Steele wrote: > Exactly? If I'm an EAI aware client and I'm connecting to an > EAI aware server, then I SHOULD really use the UTF8 MAIL FROM. > > The value of MAIL FROM is to complete the handshaking, so the > server knows that the client is EAI aware. Nobody should be > inspecting every message. > > The one exception could be if my EAI aware client is passing > along a message it got from a non-EAI source, in which case it > could avoid the MAIL FROM UTF8, to avoid the risk of any > response breaking the return path. Any messages generated > from the EAI aware system SHOULD use the UTF8 tag though. From klensin@jck.com Wed Jan 19 10:30:25 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 3CF303A718A for ; Wed, 19 Jan 2011 10:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z0C6N9njIsh for ; Wed, 19 Jan 2011 10:30:24 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CDF3E3A7158 for ; Wed, 19 Jan 2011 10:30:21 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pfcq5-000Jms-JF; Wed, 19 Jan 2011 13:33:02 -0500 Date: Wed, 19 Jan 2011 13:33:00 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Extensions to EAI (was: Re: Consensus Issue #1: parameter on MAIL FROM?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:30:25 -0000 --On Wednesday, 19 January, 2011 17:55 +0000 Shawn Steele wrote: > Since you have no objection, I suppose my reply is irrelevent, > however: > > IMO saying "UTF8SMTP" or whatever describes the behavior of > EAI. "Extending" EAI to another encoding is a non-starter. > Other extensions may be useful, but I don't see how adding EAI > parameters helps as we cannot foresee the direction of the > extension, and it's out of the scope of the WG to (re)define > extension methods. I don't see needing EAI-specific > extensions in the future, though I could be short-sighted. >... > Assuming we really screw up EAI and need to "fix" it, we > always have the option of changing the tag to "UTF8V2" or > something. >... Right. Although I assume that "UTF8V2" would cause us terrible problems about whether we really intended a new version of UTF-8 and "or something" would be chosen. More generally, there are two types of "extensions to EAI", those that are really extensions and those that head off in another direction. There are also lots of in-between cases, so the decision would be a judgment call. Either way, that can be done either by an additional extension keyword that requires EAI as a prerequisite (as we have done with 8BITMIME) or a separate, presumably orthogonal, extension. But, in my interpretation of Shawn's comment, let's not make trouble for ourselves. Paraphrasing a comment that was carried forward into RFC 5321, we've had lots of experience that extensions and features that are simple and that have few or no options deploy well and without interoperability problems while features that are more complex, with many options, tend to have lots of trouble. The WG has explicitly decided on several occasions to try to keep things simple and option-free: UTF-8 only rather than allowances for other charsets in header fields, dropping downgrading and alternate addresses, and so on. Let's keep it that way with one EAI, one set of specifications to which everyone either conforms or does not, and so on. We can all invent plausible variations to cover theoretically-plausible cases. But let's not. john From ned+ima@mrochek.com Wed Jan 19 11:04:10 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 3DB093A71A2 for ; Wed, 19 Jan 2011 11:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-MsQHJlX5JM for ; Wed, 19 Jan 2011 11:04:09 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 326E33A71A1 for ; Wed, 19 Jan 2011 11:04:09 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWT0COIA5S009WH6@mauve.mrochek.com> for ima@ietf.org; Wed, 19 Jan 2011 11:06:48 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRL7QI6DS007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 19 Jan 2011 11:06:46 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWT0CNL6QI007CHU@mauve.mrochek.com> Date: Wed, 19 Jan 2011 11:01:48 -0800 (PST) In-reply-to: "Your message dated Wed, 19 Jan 2011 17:41:19 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Shawn Steele DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295460962; bh=MLnzrYYX6PLefoJfCu4mxq2BGMcBpeWFJfE3Xa+QKj8=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=tEX5m87vA4p0ubMHlU2IBZBd0i2TQ8VlgpnEgf+SJqHpj28TAfGpf3v4LKGwEd4Q7 2bBjnrkivNUq8ntswUlLo3Yh97pWDaWQSzQE+blw/f4DKJzI9IfLE8TI/nBtkvsn9O nL8F4gxTu0wppL9LNy5AU3/gRgWqQ0ke0IZ/YonE= Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:04:10 -0000 > Nothing requires UTF-8, but we certainly strongly suggest that EAI messages > are entirely UTF-8. IMO you'd be a pretty ugly EAI implementation if that > wasn't your default. I think this is a very good point worthy of a separate consensus call - the format document needs to say something like: Media types that support multiple charsets SHOULD employ either utf-8 or us-ascii. As Shown wells knows, the continued use of charsets other than utf-8, especially some of the multibyte ones whose definitions vary depending on the software you're using, represent a significant ongoing interoperability problem for email. Given that you have to support utf-8 to support EAI, there is absolutely no reason for EAI to condone this nonsense. Ned From klensin@jck.com Wed Jan 19 11:56:40 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 B76A93A71AD for ; Wed, 19 Jan 2011 11:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SywFrJtwPBa for ; Wed, 19 Jan 2011 11:56:39 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A69003A7060 for ; Wed, 19 Jan 2011 11:56:39 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfeBb-000Lw0-Rx; Wed, 19 Jan 2011 14:59:20 -0500 Date: Wed, 19 Jan 2011 14:59:19 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <6029984443BD1E6732AE2973@[192.168.1.6]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:56:40 -0000 --On Wednesday, 19 January, 2011 17:37 +0000 Shawn Steele wrote: > IMO: An EAI compliant client shouldn't be sending "ASCII" > mail, it should be sending "UTF-8" mail (even if it only > contains ASCII range characters). Sure they're the same, but > there's no reason the client, or the server, need to care > because they're both EAI aware. That is the "announce capability and handshake" story in a nutshell, at least IMO. > *IF* the recipient wants to forward the message, his end can > worry about what to do with the encoding at that time. And if > the server wants to send it on to a non-EAI server, then it > can deal with it at that time. Forcing the client to parse > and continue to support this information, forever, even after > 99% of the servers support EAI, is a waste of effort. Certainly. But if one adopts the "this messages needs EAI capabilities" model, then that recipient (or at least a relay) doesn't need to parse, it just needs to pass the indicator along and reject if it hits a server that doesn't advertise EAI capability. Note the relationship between this and the message/global situation: if I want to encapsulate and forward a message, I can always encapsulate as message/global but can use message/rfc822 only if I know that the outermost headers do not require EAI capability. Whether an EAI-conformant MUA should be bothering to make that test, or should just retire message/rfc822 in favor of message/global is a judgment call that probably gets easier as more EAI-conformant systems deploy. >... john From Shawn.Steele@microsoft.com Wed Jan 19 14:59:00 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 8C6D728C108 for ; Wed, 19 Jan 2011 14:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.443 X-Spam-Level: X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdF4wv27aVKw for ; Wed, 19 Jan 2011 14:58:59 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4120728C0F1 for ; Wed, 19 Jan 2011 14:58:59 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 15:01:34 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 15:01:34 -0800 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLt/+OL3gOcQrXbUSzW8PTBVNfP5PZPNSA//+sSMA= Date: Wed, 19 Jan 2011 23:01:34 +0000 Message-ID: References: <6029984443BD1E6732AE2973@[192.168.1.6]> In-Reply-To: <6029984443BD1E6732AE2973@[192.168.1.6]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:59:00 -0000 IMO the case that could be fixed by tracking some message state is an edge = case. If I go from one end to the other, encounter an EAI server, and then= end up back in a non-EAI environment, then, IMO, something's broken. Even= if my message would work, "real" EAI messages would fail, so there's no po= int to having an EAI server. Once that end's fixed, then the "is this mess= age ASCII-only" question becomes irrelevant. I don't think we should build= in this edge case.... -Shawn -----Original Message----- From: John C Klensin [mailto:klensin@jck.com]=20 Sent: Wednesday, January 19, 2011 11:59 AM To: Shawn Steele; ima@ietf.org Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? --On Wednesday, 19 January, 2011 17:37 +0000 Shawn Steele wrote: > IMO: An EAI compliant client shouldn't be sending "ASCII" > mail, it should be sending "UTF-8" mail (even if it only contains=20 > ASCII range characters). Sure they're the same, but there's no reason=20 > the client, or the server, need to care because they're both EAI=20 > aware. That is the "announce capability and handshake" story in a nutshell, at lea= st IMO. > *IF* the recipient wants to forward the message, his end can worry=20 > about what to do with the encoding at that time. And if the server=20 > wants to send it on to a non-EAI server, then it can deal with it at=20 > that time. Forcing the client to parse and continue to support this=20 > information, forever, even after 99% of the servers support EAI, is a=20 > waste of effort. Certainly. But if one adopts the "this messages needs EAI capabilities" model, then that recipient (or at least a relay) doesn't need= to parse, it just needs to pass the indicator along and reject if it hits = a server that doesn't advertise EAI capability. Note the relationship betw= een this and the message/global situation: if I want to encapsulate and for= ward a message, I can always encapsulate as message/global but can use message/rfc822 only if I know that the outermost headers do not require EAI= capability. Whether an EAI-conformant MUA should be bothering to make tha= t test, or should just retire message/rfc822 in favor of message/global is a judgment call that probably = gets easier as more EAI-conformant systems deploy. >... john From Shawn.Steele@microsoft.com Wed Jan 19 15:33:36 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 613153A71EF for ; Wed, 19 Jan 2011 15:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXlGlI6s7-tS for ; Wed, 19 Jan 2011 15:33:35 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D45423A71EE for ; Wed, 19 Jan 2011 15:33:34 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 15:36:10 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 15:36:09 -0800 From: Shawn Steele To: 'John C Klensin' , "ima@ietf.org" Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLuALhtm3SkVVbk0CBtAeNuxW535PZIkEA//+EqaA= Date: Wed, 19 Jan 2011 23:36:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 23:33:36 -0000 SSBhZ3JlZSB3aXRoIHlvdXIgYW5hbHlzaXMsIGJ1dCBJIHRoaW5rIEkgcmVhY2ggYSBkaWZmZXJl bnQgY29uY2x1c2lvbi4gIEknbSBub3Qgc3VyZSB0aGF0IGluIHByYWN0aWNlIGl0IG1hdHRlcnMg d2hldGhlciBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UgYW5ub3VuY2VzIFVURjhTTVRQIG9yIG5vdC4N Cg0KSXQgc2VlbXMgbGlrZWx5IHRoYXQsIGF0IGxlYXN0IHNvbWUsIGNsaWVudHMgd2lsbCBhbm5v dW5jZSBVVEY4IG9uIE1BSUwgRlJPTSBqdXN0IGJlY2F1c2UgdGhleSBjYW4sIG9yIGJlY2F1c2Ug aXQncyBlYXN5LCBvciBiZWNhdXNlIG9mIGEgYnVnLCBidXQsIGluIGFueSBjYXNlLCB0aGF0IHRo ZSBzZXJ2ZXIgd2lsbCBnZXQgVVRGOCBkZWNsYXJlZCBtZXNzYWdlcyBjb250YWluaW5nIG9ubHkg QVNDSUkgY29udGVudC4gIA0KDQpTaW1pbGFybHksIHNvbWUgbWFpbCBzZXJ2ZXJzIGRvbid0IGdv aW5nIHRvIHRydXN0IHRoYXQgdGhlIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgYXJlIHBlcmZlY3Qs IGFuZCB3aWxsIHByb2JhYmx5IGNoZWNrIGZvciBVVEY4IGV2ZW4gaWYgdGhlIGtleXdvcmQgaXMg bWlzc2luZywganVzdCB0byBiZSBjYXJlZnVsLg0KDQpQcmVzdW1hYmx5LCBpZiBJIGhhdmUgYW4g RUFJIHNlcnZlciwgYW5kIHVzZXJzIGdldCBFQUkgbWFpbCwgdGhlbiB0aGV5IHNob3VsZCBoYXZl IEVBSSBQT1AvU01UUCBjbGllbnRzLiAgSWYgdGhleSBkb24ndCwgdGhlbiB0aGV5IHByb2JhYmx5 IHJhcmVseSBnZXQgRUFJIG1haWwuICBJIHN1cHBvc2UgaXQncyBwb3NzaWJsZSB0aGF0IHRoZSBh ZG1pbiB1cGRhdGVzIHRoZSBzZXJ2ZXIsIGJ1dCB0aGUgY2xpZW50cyBhcmUgNSB5ZWFycyBvbGQs IGJ1dCB0aGF0IHNlZW1zIGxpa2UgYW4gb2RkIGVkZ2UgY2FzZS4NCg0KLVNoYXduDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBDIEtsZW5zaW4gW21haWx0bzpr bGVuc2luQGpjay5jb21dIA0KU2VudDogUG/Ku2Frb2x1LCBJYW51YWxpIDE5LCAyMDExIDEwOjI0 IGhvdXJzDQpUbzogU2hhd24gU3RlZWxlOyBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJ XSBDb25zZW5zdXMgSXNzdWUgIzE6IHBhcmFtZXRlciBvbiBNQUlMIEZST00/DQoNCkhtbS4NCg0K SXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBoYXZlIGFub3RoZXIsIG1vcmUgZnVuZGFtZW50YWwsIGlz c3VlDQpoZXJlLiAgIEknbSBub3QgdHJ5aW5nIHRvIGRvIGEgZm9ybWFsIGFwcHJhaXNhbCBvZiBj b25zZW5zdXMNCihKb3NlcGgncyBwcm9ibGVtKSwgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQgYW1v bmcgdGhvc2Ugd2hvIGhhdmUgYWR2b2NhdGVkIGEga2V5d29yZCAod2l0aG91dCBjb3VudGluZywg YXQgbGVhc3QgYSBtYWpvcml0eSBzbyBmYXIpLCB0aGVyZSBhcmUgdHdvIHNlcGFyYXRlIG9waW5p b25zIGFib3V0IHdoYXQgaXQgbWVhbnM6DQoNCgkoMSkgQSBoYW5kc2hha2UgYW5ub3VuY2VtZW50 IHRoYXQgdGhlIGNsaWVudCBpcw0KCUVBSS1jYXBhYmxlIChzZWUgU2hhd24ncyBub3RlIGJlbG93 IGFzIGFuIGV4YW1wbGUpDQoJDQoJKDIpIEFuIGFubm91bmNlbWVudCBmcm9tIHRoZSBjbGllbnQg dG8gdGhlIHNlcnZlciB0aGF0DQoJdGhlIG1lc3NhZ2UgYWN0dWFsbHkgcmVxdWlyZXMgKG9yIGF0 IGxlYXN0IHByb2JhYmx5DQoJcmVxdWlyZXMpIEVBSSBjYXBhYmlsaXRpZXMuDQoNCkZXSVcsIG5v dGUgdGhhdCB0aGUgX29ubHlfIHJlcGx5IHRleHQgdGhhdCByZXF1aXJlIEVBSS1jYXBhYmlsaXR5 IGFyZSB0aG9zZSB0byBWUkZZIGFuZCBFWFBOIGFuZCB0aGUgIm5ldyBhZGRyZXNzIg0KY29kZXMs IHdoaWNoIHdlIGhhdmUgbmVhcmx5LCBidXQgbm90IHF1aXRlLCBkZXByZWNhdGVkIGluIGJyb2Fk ZXIgSW50ZXJuZXQgY29udGV4dHMgKGUuZy4sIG5vbi1lbnRlcnByaXNlIG9uZXMpLiAgVGhvc2Ug dGhyZWUgY2FzZXMgbmVlZCB0byByZXR1cm4gYWRkcmVzc2VzLCBub3RoaW5nIGVsc2UgZG9lcy4N CkluY2x1c2lvbiBvZiBtYWlsYm94IG5hbWVzIGluIHJlcGxpZXMgdG8gTUFJTCwgUkNQVCwgb3Ig YW55IG90aGVyIGNvbW1hbmQgaXMgbm90IHJlcXVpcmVkIG9yIHN1Z2dlc3RlZCBpbiBSRkMgNTMy MSBhbmQsIGF0IGxlYXN0IGluIG15IGV4cGVyaWVuY2UsIGlzIHVuY29tbW9uLg0KDQpJZiB3ZSBn byB3aXRoIHRoZSAiaGFuZHNoYWtlIiBtb2RlbCwgdGhlbiB0aGVyZSBpcyBubyBpc3N1ZSB3aXRo IHJlcGxpZXMgY29udGFpbmluZyB0ZXh0IG5vdCBwZXJtaXR0ZWQgYnkgNTMyMSAoaS5lLiwgdGV4 dCBjb250YWluaW5nIFVuaWNvZGUgY2hhcmFjdGVycyB3aXRoIGNvZGUgcG9pbnRzIGFib3ZlIFUr MDA3RiwgZW5jb2RlZCBpbiBVVEYtOCkuICBCdXQgYSBzZXJ2ZXIgdGhhdCBhY3R1YWxseSBuZWVk cyB0byBrbm93IHdoZXRoZXIgYSBtZXNzYWdlIHJlcXVpcmVzIEVBSSBjYXBhYmlsaXRpZXMgKGUu Zy4sIHRvIGRlbGl2ZXIgaXQgdG8gYSBtZXNzYWdlIHN0b3JlIHdpdGggYXBwcm9wcmlhdGUgaW5m b3JtYXRpb24gZm9yIFBPUCBvciBJTUFQDQpjbGllbnRzKSBoYXMgdG8gcGFyc2UgdGhlIG1lc3Nh Z2UuDQoNCklmIHdlIGdvIHdpdGggdGhlICJhbm5vdW5jZW1lbnQiIG1vZGVsLCB0aGVuIHRoZSBw YXJzaW5nIHByb2JsZW0gaXMgZWxpbWluYXRlZCBidXQgdGhlcmUgaXMgbm8gcG9zc2liaWxpdHkg b2YgcmVwbGllcyB0aGF0IGFyZSBpbnZhbGlkIHVuZGVyIDUzMjEgd2hlbiB0aGUgYW5ub3VuY2Vt ZW50IGlzIG5vdCBtYWRlLCBpLmUuLCB3aGVuIHRoZSBtZXNzYWdlLCBoZWFkZXJzLCBhbmQgYWRk cmVzc2VzIGFyZSBzdHJpY3RseSA1MzIxLWNvbmZvcm1pbmcuDQoNClNwZWFraW5nIHBlcnNvbmFs bHksIEkgY291bGQgbGl2ZSB3aXRoIGVpdGhlciBkZWNpc2lvbiBhbHRob3VnaCBJIGhhdmUgYSBw cmVmZXJlbmNlLiAgQnV0IHdlIG5lZWQgdG8gcmVzb2x2ZSB0aGlzIGRpZmZlcmVuY2UgYW5kIGhh dmUgYW4gdW5hbWJpZ3VvdXMgaW50ZXJwcmV0YXRpb24gZm9yIHRoZSBhdXRob3JzIG9mIDUzMzZi aXMgdG8NCmNvbXBsZXRlIHRoZWlyIHdvcmsuICAgSSBhc3N1bWUgdGhhdCB3aWxsIHJlcXVpcmUg YSBzZXBhcmF0ZQ0KY29uc2Vuc3VzIGNhbGwgYnV0IGhvcGUgd2UgY2FuIGhhdmUgZW5vdWdoIGRp c2N1c3Npb24gZmlyc3QgdGhhdCBldmVyeW9uZSB1bmRlcnN0YW5kcyBib3RoIG9wdGlvbnMuDQoN CiAgICAgIGpvaG4NCg0KDQotLU9uIFdlZG5lc2RheSwgMTkgSmFudWFyeSwgMjAxMSAxODowMSAr MDAwMCBTaGF3biBTdGVlbGUgPFNoYXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0K PiBFeGFjdGx5PyAgSWYgSSdtIGFuIEVBSSBhd2FyZSBjbGllbnQgYW5kIEknbSBjb25uZWN0aW5n IHRvIGFuIEVBSSANCj4gYXdhcmUgc2VydmVyLCB0aGVuIEkgU0hPVUxEIHJlYWxseSB1c2UgdGhl IFVURjggTUFJTCBGUk9NLg0KPiANCj4gVGhlIHZhbHVlIG9mIE1BSUwgRlJPTSBpcyB0byBjb21w bGV0ZSB0aGUgaGFuZHNoYWtpbmcsIHNvIHRoZSBzZXJ2ZXIgDQo+IGtub3dzIHRoYXQgdGhlIGNs aWVudCBpcyBFQUkgYXdhcmUuICBOb2JvZHkgc2hvdWxkIGJlIGluc3BlY3RpbmcgZXZlcnkgDQo+ IG1lc3NhZ2UuDQo+IA0KPiBUaGUgb25lIGV4Y2VwdGlvbiBjb3VsZCBiZSBpZiBteSBFQUkgYXdh cmUgY2xpZW50IGlzIHBhc3NpbmcgYWxvbmcgYSANCj4gbWVzc2FnZSBpdCBnb3QgZnJvbSBhIG5v bi1FQUkgc291cmNlLCBpbiB3aGljaCBjYXNlIGl0IGNvdWxkIGF2b2lkIHRoZSANCj4gTUFJTCBG Uk9NIFVURjgsIHRvIGF2b2lkIHRoZSByaXNrIG9mIGFueSByZXNwb25zZSBicmVha2luZyB0aGUg cmV0dXJuIA0KPiBwYXRoLiAgQW55IG1lc3NhZ2VzIGdlbmVyYXRlZCBmcm9tIHRoZSBFQUkgYXdh cmUgc3lzdGVtIFNIT1VMRCB1c2UgdGhlIA0KPiBVVEY4IHRhZyB0aG91Z2guDQoNCg0KDQoNCg0K From Shawn.Steele@microsoft.com Wed Jan 19 16:25:07 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 44AB628C0E5 for ; Wed, 19 Jan 2011 16:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] 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 YqZfUm7BvxCg for ; Wed, 19 Jan 2011 16:25:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 38CB928C0E4 for ; Wed, 19 Jan 2011 16:25:04 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 16:27:45 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 16:27:45 -0800 From: Shawn Steele To: Ned Freed Thread-Topic: Consensus Issue #???: Media types that support multiple charsets SHOULD employ utf-8 Thread-Index: Acu4D1WuGevDOChpREyIJuxHER9LoQ== Date: Thu, 20 Jan 2011 00:27:44 +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.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #???: Media types that support multiple charsets SHOULD employ utf-8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:25:07 -0000 SSdkIGFncmVlIHRvIHRoaXMgcXVlc3Rpb24sIHRob3VnaCBJJ2Qgc3VnZ2VzdCAic2hvdWxkIGVt cGxveSBVVEYtOCIuDQoNCglNZWRpYSB0eXBlcyB0aGF0IHN1cHBvcnQgbXVsdGlwbGUgY2hhcnNl dHMgU0hPVUxEIGVtcGxveSBVVEYtOA0KDQotIG9yIC0NCglNZWRpYSB0eXBlcyB0aGF0IHN1cHBv cnQgbXVsdGlwbGUgY2hhcnNldHMgU0hPVUxEIGVtcGxveSBVVEYtOCBvciBBU0NJSS4NCg0KT3Ig aXMgdGhlcmUgc29tZXRoaW5nIHRoYXQncyByZXN0cmljdGVkIHRvIEFTQ0lJLW9ubHkgZm9yIGEg cmVhbGx5IGdvb2QgcmVhc29uPw0KDQotU2hhd24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE5lZCBGcmVlZCBbbWFpbHRvOm5lZC5mcmVlZEBtcm9jaGVrLmNvbV0gDQpTZW50 OiBQb8q7YWtvbHUsIElhbnVhbGkgMTksIDIwMTEgMTE6MDIgaG91cnMNClRvOiBTaGF3biBTdGVl bGUNCkNjOiBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgSXNzdWUg IzE6IHBhcmFtZXRlciBvbiBNQUlMIEZST00/DQoNCj4gTm90aGluZyByZXF1aXJlcyBVVEYtOCwg YnV0IHdlIGNlcnRhaW5seSBzdHJvbmdseSBzdWdnZXN0IHRoYXQgRUFJIA0KPiBtZXNzYWdlcyBh cmUgZW50aXJlbHkgVVRGLTguICBJTU8geW91J2QgYmUgYSBwcmV0dHkgdWdseSBFQUkgDQo+IGlt cGxlbWVudGF0aW9uIGlmIHRoYXQgd2Fzbid0IHlvdXIgZGVmYXVsdC4NCg0KSSB0aGluayB0aGlz IGlzIGEgdmVyeSBnb29kIHBvaW50IHdvcnRoeSBvZiBhIHNlcGFyYXRlIGNvbnNlbnN1cyBjYWxs IC0gdGhlIGZvcm1hdCBkb2N1bWVudCBuZWVkcyB0byBzYXkgc29tZXRoaW5nIGxpa2U6DQoNCiAg ICBNZWRpYSB0eXBlcyB0aGF0IHN1cHBvcnQgbXVsdGlwbGUgY2hhcnNldHMgU0hPVUxEIGVtcGxv eSBlaXRoZXINCiAgICB1dGYtOCBvciB1cy1hc2NpaS4NCg0KQXMgU2hvd24gd2VsbHMga25vd3Ms IHRoZSBjb250aW51ZWQgdXNlIG9mIGNoYXJzZXRzIG90aGVyIHRoYW4gdXRmLTgsIGVzcGVjaWFs bHkgc29tZSBvZiB0aGUgbXVsdGlieXRlIG9uZXMgd2hvc2UgZGVmaW5pdGlvbnMgdmFyeSBkZXBl bmRpbmcgb24gdGhlIHNvZnR3YXJlIHlvdSdyZSB1c2luZywgcmVwcmVzZW50IGEgc2lnbmlmaWNh bnQgb25nb2luZyBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW0gZm9yIGVtYWlsLiBHaXZlbiB0aGF0 IHlvdSBoYXZlIHRvIHN1cHBvcnQgdXRmLTggdG8gc3VwcG9ydCBFQUksIHRoZXJlIGlzIGFic29s dXRlbHkgbm8gcmVhc29uIGZvciBFQUkgdG8gY29uZG9uZSB0aGlzIG5vbnNlbnNlLg0KDQoJCQkJ TmVkDQoNCg== From duerst@it.aoyama.ac.jp Wed Jan 19 16:31:42 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 D8D3028C122 for ; Wed, 19 Jan 2011 16:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.266 X-Spam-Level: X-Spam-Status: No, score=-100.266 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 frV83qtvFdb4 for ; Wed, 19 Jan 2011 16:31:41 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 8612528C0CF for ; Wed, 19 Jan 2011 16:31:41 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0K0YIVU019490 for ; Thu, 20 Jan 2011 09:34:18 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1a8e_a6c5_0402dd66_242d_11e0_a4e6_001d096c5782; Thu, 20 Jan 2011 09:34:18 +0900 Received: from [IPv6:::1] ([133.2.210.1]:50409) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 20 Jan 2011 09:34:18 +0900 Message-ID: <4D378304.1010803@it.aoyama.ac.jp> Date: Thu, 20 Jan 2011 09:34:12 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:31:42 -0000 On 2011/01/20 2:37, Shawn Steele wrote: > IMO: An EAI compliant client shouldn't be sending "ASCII" mail, it should be sending "UTF-8" mail (even if it only contains ASCII range characters). Sure they're the same, but there's no reason the client, or the server, need to care because they're both EAI aware. I'm not sure about this. When a student of mine implemented the experimental version of eai a few years ago on a mail client, we realized that some of the counterparts of the user may be eai-capable, but others not. But the submission server will be eai-capable anyway. I think this will be a very frequent situation for quite some while. Let's say I have some correspondents in Japan and China where eai gets deployed quickly. And I have correspondents in the US or Europe where uptake is slower. There is absolutely no need to send all outgoing mail as eai and have the outgoing server check everything and backpaddle where necessary. So what we did was to assume eai was okay if there was at least one not-ascii-only (side-note: term carefully chosen to get past Dave :-) address. We also were looking at using other heuristics, such as "if I got an eai mail from somebody, it's okay to send one back" to be a bit more agressive with eai deployment/use and to hopefully close gaps where both sides are eai-capable but just don't know. But I'm not sure how far we got with implementing this. I think this approach is more prudent because it avoids unnecessary transformations of mail in transit (and thus the potential of generating garbage or mail not passing, and with that some bad press for eai), and reduces server load. At the very least, such an approach should be possible for clients (as far as I understand, it currently is, because the flag is on the MAIL command). Regards, Martin. > *IF* the recipient wants to forward the message, his end can worry about what to do with the encoding at that time. And if the server wants to send it on to a non-EAI server, then it can deal with it at that time. Forcing the client to parse and continue to support this information, forever, even after 99% of the servers support EAI, is a waste of effort. > > A system of EAI aware servers shouldn't care what range of characters is encoded within a UTF-8 encoded mail. > > -Shawn > > ------------------------------ > > Message: 4 > Date: Tue, 18 Jan 2011 10:25:50 -0800 > From: Bill McQuillan > Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? > To: IMA Discussion > Message-ID:<564971012.20110118102550@pobox.com> > Content-Type: text/plain; charset=us-ascii > > > On Tue, 2011-01-18, John C Klensin wrote: > > >> --On Tuesday, 18 January, 2011 16:02 +0000 John Levine >> wrote: > >>> ... >>> I suppose that's hypothetically true, but I do not ever want >>> to meet a mail client that sends a UTF-8 message but can't >>> accept UTF-8 in the responses. For EAI, you're either on the >>> bus or you aren't. >>> ... > >> And that should be a conformance issue elsewhere in the text. >> More generally, the WG has so far consistently taken the >> position that one is either EAI-conforming (i.e., fully >> i18n-email-capable) or not. I think that is consistent with the >> view John expresses above. > > That's certainly right. But NOT what I was concerned with. > > How does an EAI compliant client express that fact when sending a message > that is ASCII only? If it marks the message as UTF8, it may limit it's > propagation unnecessarily, and if the client *doesn't* mark it as UTF8, it > may miss out on some useful responses from the server. > > Case 0 - Non-EAI client; Message Header MUST be ASCII only > > Case 1 - EAI client; Message Header is ASCII only > > Case 2 - EAI client; Message Header is *not* ASCII only > > -- > Bill McQuillan > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Wed Jan 19 16:37:29 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 7937028C0CF for ; Wed, 19 Jan 2011 16:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.257 X-Spam-Level: X-Spam-Status: No, score=-100.257 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 uXk18HwnNB1r for ; Wed, 19 Jan 2011 16:37:28 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 513B13A6F57 for ; Wed, 19 Jan 2011 16:37:28 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0K0e9ID021448 for ; Thu, 20 Jan 2011 09:40:09 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 1d34_08ae_d54468c2_242d_11e0_b49c_001d096c566a; Thu, 20 Jan 2011 09:40:09 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53383) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 20 Jan 2011 09:40:09 +0900 Message-ID: <4D378464.5060001@it.aoyama.ac.jp> Date: Thu, 20 Jan 2011 09:40:04 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> <4D368CC8.6000300@it.aoyama.ac.jp> <8BFCED19C12258D99A1451A9@[192.168.1.6]> In-Reply-To: <8BFCED19C12258D99A1451A9@[192.168.1.6]> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: EAI WG Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:37:29 -0000 Hello John, On 2011/01/19 21:42, John C Klensin wrote: > --On Wednesday, 19 January, 2011 16:03 +0900 "\"Martin J. > Dürst\"" wrote: > >> On 2011/01/18 2:15, Joseph Yee wrote: >>> Issue #1: parameter on MAIL FROM? >>> http://trac.tools.ietf.org/wg/eai/trac/ticket/1 >>> >>> Description >>> --------------- >>> >>> Should the WG add parameter on MAIL FROM to start EAI >>> transaction and avoid the need for deep inspection? >> >> Yes. To the extent possible, the parameter should be short. > > Out of curiousity, because? Remember that this parameter is > part of the SMTP envelope only -- users never see these things; > most users would be unable to see them if they wanted to and > knew how to look for them (it requires either looking inside an > MTA or intercepting MTA-MTA transactions). I don't object to > "short", but am wondering why you think it is important. I'm sorry if that sounded more important than it was intended. I just wanted to express that I have a preference for something like UTF-8 or EAI or UTF8 over something long and convoluted. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Shawn.Steele@microsoft.com Wed Jan 19 16:39:41 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 1B4EC3A6F57 for ; Wed, 19 Jan 2011 16:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.3 X-Spam-Level: X-Spam-Status: No, score=-10.3 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+6q35Et-vSe for ; Wed, 19 Jan 2011 16:39:40 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D59A03A6E63 for ; Wed, 19 Jan 2011 16:39:39 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 16:42:21 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 16:42:21 -0800 From: Shawn Steele To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLt/+OL3gOcQrXbUSzW8PTBVNfP5PZiaEA//96dRA= Date: Thu, 20 Jan 2011 00:42:21 +0000 Message-ID: References: <4D378304.1010803@it.aoyama.ac.jp> In-Reply-To: <4D378304.1010803@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:39:41 -0000 SSBkb24ndCBtaW5kIGlmIGluZGl2aWR1YWwgbWVzc2FnZXMgYXJlIHRhZ2dlZCB3aXRoICJub3Qg bmVlZGluZyBFQUkiLiAgKEVnOiB0aGV5IGRvbid0IGhhdmUgdG8gdXNlIHRoZSBNQUlMIEZST00g Li4uIGZsYWcpLCBob3dldmVyIEkgdGhpbmsgdGhlIGV4dHJhIHN0YXRlIGlzIGEgYml0IG1vcmUg Y29tcGxleCB0byBtYW5hZ2UuDQoNCkVnOiBteSBjbGllbnQgc2VuZHMgYSBtZXNzYWdlIHRvIG15 IHN1Ym1pc3Npb24gc2VydmVyLiAgRG9lcyBteSBjbGllbnQgaGF2ZSB0byBkZWNsYXJlIHRoYXQg aXQgaXNuJ3QgYW4gRUFJIG1lc3NhZ2U/ICBXaXRoIGFsbCB0aGUgaGFuZCBvZmZzLCBkbyBJICJq dXN0IiByZW1lbWJlciBmb3IgZWFjaCBtZXNzYWdlIGlmIGl0IHJlcXVpcmVzIEVBSSBvciBub3Q/ ICBPciBkbyBJIG1hcmsgaXQgc29tZWhvdyBzbyBJIGNhbiBtb3JlIGVhc2lseSBmaWd1cmUgdGhh dCBvdXQ/ICAoRWc6IFgtTVlTT0ZUV0FSRS1LTk9XUy1USElTLVVTRVMtRUFJIGluIHRoZSBoZWFk ZXI/KSAgDQoNCihQcmVzdW1hYmx5IHRoZSBoZWFkZXIgaXMgdGhlICJvbmx5IiBpbnRlcmVzdGlu ZyB0aGluZyBoZXJlLCB0aGUgYm9keSBzaG91bGQgYmUgdGFnZ2VkIGNvcnJlY3RseSBhbmQgd29y ayBpbiBFQUkgb3Igbm9uLUVBSSBlbnZpcm9ubWVudHMsIHNvIHdlICJvbmx5IiBuZWVkIHRvIGhh dmUgdGhpcyBpbmZvcm1hdGlvbiBpZiB0aGVyZSdzIFVURi04IGluIHRoZSBoZWFkZXIpLg0KDQpJ IGFncmVlIHRoYXQgdGhlICJJJ20gc2VuZGluZyBtYWlsLCBhbmQgaXQnZCBiZSBuaWNlIGlmIGl0 IHdvcmtlZCBkb3dubGV2ZWwgd2l0aG91dCByZXRyeWluZyIgc2NlbmFyaW8gd29ya2VkIHJlYXNv bmFibHkgd2VsbC4gIEkganVzdCBmZWFyIHRoZXJlIGFyZSB0b28gbWFueSBwYXJ0cyB0byBkbyB0 aGF0IHZlcnkgZWZmZWN0aXZlbHkuICAoVW5sZXNzIHlvdSBhZGRlZCBhIFRISVMtTUFJTC1JUy1F QUkgaGVhZGVyLCB3aGljaCB3b3VsZCBzb3J0IG9mIGRlZmVhdCB0aGUgcHVycG9zZSwgc2luY2Ug SSBjb3VsZCBqdXN0IGFzIGVhc2lseSB0ZXN0IHRoZSBoZWFkZXIgZm9yIFVURi04ID4gQVNDSUkg Y29kZSBwb2ludHMpLg0KDQotU2hhd24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206ICJNYXJ0aW4gSi4gRMO8cnN0IiBbbWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMuanBdIA0K U2VudDogUG/Ku2Frb2x1LCBJYW51YWxpIDE5LCAyMDExIDQ6MzQgaG91cnMNClRvOiBTaGF3biBT dGVlbGUNCkNjOiBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgSXNz dWUgIzE6IHBhcmFtZXRlciBvbiBNQUlMIEZST00/DQoNCg0KDQpPbiAyMDExLzAxLzIwIDI6Mzcs IFNoYXduIFN0ZWVsZSB3cm90ZToNCj4gSU1POiBBbiBFQUkgY29tcGxpYW50IGNsaWVudCBzaG91 bGRuJ3QgYmUgc2VuZGluZyAiQVNDSUkiIG1haWwsIGl0IHNob3VsZCBiZSBzZW5kaW5nICJVVEYt OCIgbWFpbCAoZXZlbiBpZiBpdCBvbmx5IGNvbnRhaW5zIEFTQ0lJIHJhbmdlIGNoYXJhY3RlcnMp LiAgU3VyZSB0aGV5J3JlIHRoZSBzYW1lLCBidXQgdGhlcmUncyBubyByZWFzb24gdGhlIGNsaWVu dCwgb3IgdGhlIHNlcnZlciwgbmVlZCB0byBjYXJlIGJlY2F1c2UgdGhleSdyZSBib3RoIEVBSSBh d2FyZS4NCg0KSSdtIG5vdCBzdXJlIGFib3V0IHRoaXMuIFdoZW4gYSBzdHVkZW50IG9mIG1pbmUg aW1wbGVtZW50ZWQgdGhlIGV4cGVyaW1lbnRhbCB2ZXJzaW9uIG9mIGVhaSBhIGZldyB5ZWFycyBh Z28gb24gYSBtYWlsIGNsaWVudCwgd2UgcmVhbGl6ZWQgdGhhdCBzb21lIG9mIHRoZSBjb3VudGVy cGFydHMgb2YgdGhlIHVzZXIgbWF5IGJlIGVhaS1jYXBhYmxlLCBidXQgb3RoZXJzIG5vdC4gQnV0 IHRoZSBzdWJtaXNzaW9uIHNlcnZlciB3aWxsIGJlIGVhaS1jYXBhYmxlIGFueXdheS4NCg0KSSB0 aGluayB0aGlzIHdpbGwgYmUgYSB2ZXJ5IGZyZXF1ZW50IHNpdHVhdGlvbiBmb3IgcXVpdGUgc29t ZSB3aGlsZS4gDQpMZXQncyBzYXkgSSBoYXZlIHNvbWUgY29ycmVzcG9uZGVudHMgaW4gSmFwYW4g YW5kIENoaW5hIHdoZXJlIGVhaSBnZXRzIGRlcGxveWVkIHF1aWNrbHkuIEFuZCBJIGhhdmUgY29y cmVzcG9uZGVudHMgaW4gdGhlIFVTIG9yIEV1cm9wZSB3aGVyZSB1cHRha2UgaXMgc2xvd2VyLiBU aGVyZSBpcyBhYnNvbHV0ZWx5IG5vIG5lZWQgdG8gc2VuZCBhbGwgb3V0Z29pbmcgbWFpbCBhcyBl YWkgYW5kIGhhdmUgdGhlIG91dGdvaW5nIHNlcnZlciBjaGVjayBldmVyeXRoaW5nIGFuZCBiYWNr cGFkZGxlIHdoZXJlIG5lY2Vzc2FyeS4NCg0KU28gd2hhdCB3ZSBkaWQgd2FzIHRvIGFzc3VtZSBl YWkgd2FzIG9rYXkgaWYgdGhlcmUgd2FzIGF0IGxlYXN0IG9uZSBub3QtYXNjaWktb25seSAoc2lk ZS1ub3RlOiB0ZXJtIGNhcmVmdWxseSBjaG9zZW4gdG8gZ2V0IHBhc3QgRGF2ZSA6LSkgYWRkcmVz cy4gV2UgYWxzbyB3ZXJlIGxvb2tpbmcgYXQgdXNpbmcgb3RoZXIgaGV1cmlzdGljcywgc3VjaCBh cyAiaWYgSSBnb3QgYW4gZWFpIG1haWwgZnJvbSBzb21lYm9keSwgaXQncyBva2F5IHRvIHNlbmQg b25lIGJhY2siIHRvIGJlIGEgYml0IG1vcmUgYWdyZXNzaXZlIHdpdGggZWFpIGRlcGxveW1lbnQv dXNlIGFuZCB0byBob3BlZnVsbHkgY2xvc2UgZ2FwcyB3aGVyZSBib3RoIHNpZGVzIGFyZSBlYWkt Y2FwYWJsZSBidXQganVzdCBkb24ndCBrbm93LiBCdXQgSSdtIG5vdCBzdXJlIGhvdyBmYXIgd2Ug Z290IHdpdGggaW1wbGVtZW50aW5nIHRoaXMuDQoNCkkgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBt b3JlIHBydWRlbnQgYmVjYXVzZSBpdCBhdm9pZHMgdW5uZWNlc3NhcnkgdHJhbnNmb3JtYXRpb25z IG9mIG1haWwgaW4gdHJhbnNpdCAoYW5kIHRodXMgdGhlIHBvdGVudGlhbCBvZiBnZW5lcmF0aW5n IGdhcmJhZ2Ugb3IgbWFpbCBub3QgcGFzc2luZywgYW5kIHdpdGggdGhhdCBzb21lIGJhZCBwcmVz cyBmb3IgZWFpKSwgYW5kIHJlZHVjZXMgc2VydmVyIGxvYWQuDQoNCkF0IHRoZSB2ZXJ5IGxlYXN0 LCBzdWNoIGFuIGFwcHJvYWNoIHNob3VsZCBiZSBwb3NzaWJsZSBmb3IgY2xpZW50cyAoYXMgZmFy IGFzIEkgdW5kZXJzdGFuZCwgaXQgY3VycmVudGx5IGlzLCBiZWNhdXNlIHRoZSBmbGFnIGlzIG9u IHRoZSBNQUlMIGNvbW1hbmQpLg0KDQpSZWdhcmRzLCAgICBNYXJ0aW4uDQoNCj4gKklGKiB0aGUg cmVjaXBpZW50IHdhbnRzIHRvIGZvcndhcmQgdGhlIG1lc3NhZ2UsIGhpcyBlbmQgY2FuIHdvcnJ5 IGFib3V0IHdoYXQgdG8gZG8gd2l0aCB0aGUgZW5jb2RpbmcgYXQgdGhhdCB0aW1lLiAgQW5kIGlm IHRoZSBzZXJ2ZXIgd2FudHMgdG8gc2VuZCBpdCBvbiB0byBhIG5vbi1FQUkgc2VydmVyLCB0aGVu IGl0IGNhbiBkZWFsIHdpdGggaXQgYXQgdGhhdCB0aW1lLiAgRm9yY2luZyB0aGUgY2xpZW50IHRv IHBhcnNlIGFuZCBjb250aW51ZSB0byBzdXBwb3J0IHRoaXMgaW5mb3JtYXRpb24sIGZvcmV2ZXIs IGV2ZW4gYWZ0ZXIgOTklIG9mIHRoZSBzZXJ2ZXJzIHN1cHBvcnQgRUFJLCBpcyBhIHdhc3RlIG9m IGVmZm9ydC4NCj4NCj4gQSBzeXN0ZW0gb2YgRUFJIGF3YXJlIHNlcnZlcnMgc2hvdWxkbid0IGNh cmUgd2hhdCByYW5nZSBvZiBjaGFyYWN0ZXJzIGlzIGVuY29kZWQgd2l0aGluIGEgVVRGLTggZW5j b2RlZCBtYWlsLg0KPg0KPiAtU2hhd24NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+DQo+IE1lc3NhZ2U6IDQNCj4gRGF0ZTogVHVlLCAxOCBKYW4gMjAxMSAxMDoyNTo1MCAt MDgwMA0KPiBGcm9tOiBCaWxsIE1jUXVpbGxhbjxNY1F1aWxXUEBwb2JveC5jb20+DQo+IFN1Ympl Y3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgSXNzdWUgIzE6ICBwYXJhbWV0ZXIgb24gTUFJTCBGUk9N Pw0KPiBUbzogSU1BIERpc2N1c3Npb248aW1hQGlldGYub3JnPg0KPiBNZXNzYWdlLUlEOjw1NjQ5 NzEwMTIuMjAxMTAxMTgxMDI1NTBAcG9ib3guY29tPg0KPiBDb250ZW50LVR5cGU6IHRleHQvcGxh aW47IGNoYXJzZXQ9dXMtYXNjaWkNCj4NCj4NCj4gT24gVHVlLCAyMDExLTAxLTE4LCBKb2huIEMg S2xlbnNpbiB3cm90ZToNCj4NCj4NCj4+IC0tT24gVHVlc2RheSwgMTggSmFudWFyeSwgMjAxMSAx NjowMiArMDAwMCBKb2huIExldmluZSANCj4+IDxqb2hubEB0YXVnaC5jb20+ICB3cm90ZToNCj4N Cj4+PiAuLi4NCj4+PiBJIHN1cHBvc2UgdGhhdCdzIGh5cG90aGV0aWNhbGx5IHRydWUsIGJ1dCBJ IGRvIG5vdCBldmVyIHdhbnQgdG8gbWVldCANCj4+PiBhIG1haWwgY2xpZW50IHRoYXQgc2VuZHMg YSBVVEYtOCBtZXNzYWdlIGJ1dCBjYW4ndCBhY2NlcHQgVVRGLTggaW4gDQo+Pj4gdGhlIHJlc3Bv bnNlcy4gIEZvciBFQUksIHlvdSdyZSBlaXRoZXIgb24gdGhlIGJ1cyBvciB5b3UgYXJlbid0Lg0K Pj4+IC4uLg0KPg0KPj4gQW5kIHRoYXQgc2hvdWxkIGJlIGEgY29uZm9ybWFuY2UgaXNzdWUgZWxz ZXdoZXJlIGluIHRoZSB0ZXh0Lg0KPj4gTW9yZSBnZW5lcmFsbHksIHRoZSBXRyBoYXMgc28gZmFy IGNvbnNpc3RlbnRseSB0YWtlbiB0aGUgcG9zaXRpb24gDQo+PiB0aGF0IG9uZSBpcyBlaXRoZXIg RUFJLWNvbmZvcm1pbmcgKGkuZS4sIGZ1bGx5DQo+PiBpMThuLWVtYWlsLWNhcGFibGUpIG9yIG5v dC4gIEkgdGhpbmsgdGhhdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHZpZXcgDQo+PiBKb2huIGV4 cHJlc3NlcyBhYm92ZS4NCj4NCj4gVGhhdCdzIGNlcnRhaW5seSByaWdodC4gQnV0IE5PVCB3aGF0 IEkgd2FzIGNvbmNlcm5lZCB3aXRoLg0KPg0KPiBIb3cgZG9lcyBhbiBFQUkgY29tcGxpYW50IGNs aWVudCBleHByZXNzIHRoYXQgZmFjdCB3aGVuIHNlbmRpbmcgYSANCj4gbWVzc2FnZSB0aGF0IGlz IEFTQ0lJIG9ubHk/IElmIGl0IG1hcmtzIHRoZSBtZXNzYWdlIGFzIFVURjgsIGl0IG1heSANCj4g bGltaXQgaXQncyBwcm9wYWdhdGlvbiB1bm5lY2Vzc2FyaWx5LCBhbmQgaWYgdGhlIGNsaWVudCAq ZG9lc24ndCogbWFyayANCj4gaXQgYXMgVVRGOCwgaXQgbWF5IG1pc3Mgb3V0IG9uIHNvbWUgdXNl ZnVsIHJlc3BvbnNlcyBmcm9tIHRoZSBzZXJ2ZXIuDQo+DQo+IENhc2UgMCAtIE5vbi1FQUkgY2xp ZW50OyBNZXNzYWdlIEhlYWRlciBNVVNUIGJlIEFTQ0lJIG9ubHkNCj4NCj4gQ2FzZSAxIC0gRUFJ IGNsaWVudDsgTWVzc2FnZSBIZWFkZXIgaXMgQVNDSUkgb25seQ0KPg0KPiBDYXNlIDIgLSBFQUkg Y2xpZW50OyBNZXNzYWdlIEhlYWRlciBpcyAqbm90KiBBU0NJSSBvbmx5DQo+DQo+IC0tDQo+IEJp bGwgTWNRdWlsbGFuPE1jUXVpbFdQQHBvYm94LmNvbT4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4NCj4N Cg0KLS0NCiMtIyBNYXJ0aW4gSi4gRMO8cnN0LCBQcm9mZXNzb3IsIEFveWFtYSBHYWt1aW4gVW5p dmVyc2l0eQ0KIy0jIGh0dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpwICAgbWFpbHRvOmR1ZXJz dEBpdC5hb3lhbWEuYWMuanANCg0K From klensin@jck.com Wed Jan 19 17:10:11 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 A8C623A706E for ; Wed, 19 Jan 2011 17:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hHVQwsPMZDG for ; Wed, 19 Jan 2011 17:10:10 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B04903A6F64 for ; Wed, 19 Jan 2011 17:10:10 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pfj4y-0006Tg-FS; Wed, 19 Jan 2011 20:12:48 -0500 Date: Wed, 19 Jan 2011 20:12:48 -0500 From: John C Klensin To: Shawn Steele , =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <79F27437A5899A8F1BED3B9F@[192.168.1.6]> In-Reply-To: References: <4D378304.1010803@it.aoyama.ac.jp> 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] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:10:11 -0000 --On Thursday, 20 January, 2011 00:42 +0000 Shawn Steele wrote: >... > (Presumably the header is the "only" interesting thing here, > the body should be tagged correctly and work in EAI or non-EAI > environments, so we "only" need to have this information if > there's UTF-8 in the header). Or envelope although that case is presumably trivial. Note that it is possible to have an EAI requirement in the envelope but no such requirement in the headers, but the envelope requirement is easily determined by parsing. And it is not "header" but "headers" because one could have a main header that included "content-type: multipart/mixed" with no data that was not 5322-compliant and various of the subsidiary "MIME" headers having fields that would be UTF-8 and non-MIME compliant without EAI. john From klensin@jck.com Wed Jan 19 17:45:56 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 9089C28C123 for ; Wed, 19 Jan 2011 17:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BS4mOhQ5kfe for ; Wed, 19 Jan 2011 17:45:55 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id C4BB628C145 for ; Wed, 19 Jan 2011 17:45:54 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pfjdb-0007OS-64; Wed, 19 Jan 2011 20:48:35 -0500 Date: Wed, 19 Jan 2011 20:48:34 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <30EF3ED84638B542586BC59C@[192.168.1.6]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:45:56 -0000 --On Wednesday, 19 January, 2011 23:36 +0000 Shawn Steele wrote: > I agree with your analysis, but I think I reach a different > conclusion. I'm not sure that in practice it matters whether > an individual message announces UTF8SMTP or not. > > It seems likely that, at least some, clients will announce > UTF8 on MAIL FROM just because they can, or because it's easy, > or because of a bug, but, in any case, that the server will > get UTF8 declared messages containing only ASCII content. > Similarly, some mail servers don't going to trust that the > client implementations are perfect, and will probably check > for UTF8 even if the keyword is missing, just to be careful. That combination reinvents the argument for "just let them parse if they really want to know" and takes us back to nearly where we started. > Presumably, if I have an EAI server, and users get EAI mail, > then they should have EAI POP/SMTP clients. If they don't, > then they probably rarely get EAI mail. I suppose it's > possible that the admin updates the server, but the clients > are 5 years old, but that seems like an odd edge case. I fear it is quite a common case and is likely to be for some time. Remember an observation that folks from your company have probably made more strongly than anyone else: servers get upgraded and replaced according to need but Operating Systems and fundamental software (probably including non-web-client MUAs, including POP and IMAP clients) get upgraded only when computers are replaced. john From klensin@jck.com Wed Jan 19 20:33:56 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 5E76A28C120 for ; Wed, 19 Jan 2011 20:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 ouRfmy+sNTpx for ; Wed, 19 Jan 2011 20:33:55 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 50C5C28C0F6 for ; Wed, 19 Jan 2011 20:33:55 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PfmGA-000BTs-4p; Wed, 19 Jan 2011 23:36:34 -0500 Date: Wed, 19 Jan 2011 23:36:33 -0500 From: John C Klensin To: Shawn Steele , Ned Freed Message-ID: <48395489468C8DAA755D2A26@[192.168.1.6]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Consensus Issue #???: Media types that support multiple charsets SHOULD employ utf-8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 04:33:56 -0000 --On Thursday, 20 January, 2011 00:27 +0000 Shawn Steele wrote: >... > Or is there something that's restricted to ASCII-only for a > really good reason? We have a very general design rule that protocol elements of various sorts stay ASCII-only. They aren't seen by end users, the complexities of Unicode comparisons and collations aren't worth the trouble, nor is worrying about ambiguities brought about by font availability and rendering, etc. If one had a media type whose purpose was to transmit a collection of such protocol elements, we would certainly want it to be ASCII-only. john From chl@clerew.man.ac.uk Thu Jan 20 04:13:35 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 E7C4C3A6FDF for ; Thu, 20 Jan 2011 04:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 776SlUwRQIYp for ; Thu, 20 Jan 2011 04:13:34 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 9C9C83A6FD3 for ; Thu, 20 Jan 2011 04:13:33 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id A398522619 for ; Thu, 20 Jan 2011 12:16:15 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 12:16:15 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KCGEDq005581 for ; Thu, 20 Jan 2011 12:16:15 GMT Date: Thu, 20 Jan 2011 12:16:14 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d38278f.ec41-5e81-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:13:36 -0000 On Mon, 17 Jan 2011 17:15:40 -0000, Joseph Yee wrote: > Issue #1: parameter on MAIL FROM? > > Should the WG add parameter on MAIL FROM to start EAI transaction and > avoid the need for deep inspection? Yes. Ideally with the same syntax as for any other commands where we add parameters, and ideally using the same keyword (UTF8SMTPbis) as used in EHLO -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 04:19:50 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 C33BB3A6FCA for ; Thu, 20 Jan 2011 04:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.98 X-Spam-Level: X-Spam-Status: No, score=-3.98 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 V421yxoSevdv for ; Thu, 20 Jan 2011 04:19:49 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 939BE3A6FC0 for ; Thu, 20 Jan 2011 04:19:48 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id D062A22676 for ; Thu, 20 Jan 2011 12:22:30 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 12:22:30 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KCMUXa005960 for ; Thu, 20 Jan 2011 12:22:31 GMT Date: Thu, 20 Jan 2011 12:22:30 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d382906.142a7-674d-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:19:50 -0000 On Mon, 17 Jan 2011 17:15:42 -0000, Joseph Yee wrote: > Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? > > Should the new parameter to VRFY/EXPN only be permitted after the SMTP > client issued EHLO command and saw a response that included UTF8SMTPbis? Yes. But note that its use after the EHLO cannot be enforced by the server. It needs to take the form: "Clients MUST NOT use this parameter unless ..." If clients fail to heed that, then "garbage in - garbage out" will apply. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 04:25:13 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 035623A70D7 for ; Thu, 20 Jan 2011 04:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] 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 E1QpQYnlDAuP for ; Thu, 20 Jan 2011 04:25:11 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id C1FED3A70E1 for ; Thu, 20 Jan 2011 04:25:11 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id CBAA622698 for ; Thu, 20 Jan 2011 12:27:50 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 12:27:50 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KCRnNW006282 for ; Thu, 20 Jan 2011 12:27:50 GMT Date: Thu, 20 Jan 2011 12:27:49 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d382a46.13e35-5d05-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #3: remove repetition of normative text? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:25:13 -0000 On Mon, 17 Jan 2011 17:15:43 -0000, Joseph Yee wrote: > Issue #3: remove repetition of normative text? > Should the WG remove repetition of normative text from other documents > to the extent possible. Incorporate by reference and, where necessary, > note explicitly that tutorial / context-providing references are not > normative. Yes. But please replace removed syntax by NOTEs of the form " is defined in [RFCyyy] to be of the form: " so that readers can follow the intent of the documents without excessive switching between RFCs. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 04:26:57 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 006843A70FB for ; Thu, 20 Jan 2011 04:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 4isJvlpqP7Gk for ; Thu, 20 Jan 2011 04:26:56 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 063483A70E1 for ; Thu, 20 Jan 2011 04:26:55 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id DEC2C226A7 for ; Thu, 20 Jan 2011 12:29:35 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 12:29:35 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KCTZrg006389 for ; Thu, 20 Jan 2011 12:29:35 GMT Date: Thu, 20 Jan 2011 12:29:35 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <42E6F4BD-9570-4474-8910-3671CDB678C9@ca.afilias.info> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <42E6F4BD-9570-4474-8910-3671CDB678C9@ca.afilias.info> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d382aaf.101b4-5e59-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:26:57 -0000 On Mon, 17 Jan 2011 17:15:45 -0000, Joseph Yee wrote: > Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? > Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" > with new or different term s that precisely and accurately identify what > is intended? Yes. I have offered "UTF8-proper" as a possible term. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 04:29:22 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 CF5B63A70E1 for ; Thu, 20 Jan 2011 04:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.935 X-Spam-Level: X-Spam-Status: No, score=-3.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NAtpWo6WSQei for ; Thu, 20 Jan 2011 04:29:21 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id A15D33A70D7 for ; Thu, 20 Jan 2011 04:29:20 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 5CC37226BF for ; Thu, 20 Jan 2011 12:32:03 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 12:32:03 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KCVin4006522 for ; Thu, 20 Jan 2011 12:31:45 GMT To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <901FAFF275EADC2A13FBB129@[192.168.1.6]> Content-Transfer-Encoding: 8bit Date: Thu, 20 Jan 2011 12:31:44 -0000 Message-ID: In-Reply-To: <901FAFF275EADC2A13FBB129@[192.168.1.6]> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d382b43.5f65-633e-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #5: keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:29:22 -0000 On Tue, 18 Jan 2011 14:34:57 -0000, John C Klensin wrote: > Yes, keep message/global and move on. +1 -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 04:30:21 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 1A6B33A70FC for ; Thu, 20 Jan 2011 04:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.924 X-Spam-Level: X-Spam-Status: No, score=-3.924 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wQTi53XdwbHQ for ; Thu, 20 Jan 2011 04:30:19 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 932A03A6FF7 for ; Thu, 20 Jan 2011 04:30:17 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 7D0172268B for ; Thu, 20 Jan 2011 12:32:59 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 12:32:59 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KCWw0I006599 for ; Thu, 20 Jan 2011 12:32:59 GMT To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Date: Thu, 20 Jan 2011 12:32:58 -0000 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d382b7b.c165-5c16-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #6: current metalanguage model acceptable? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:30:21 -0000 On Mon, 17 Jan 2011 17:15:49 -0000, Joseph Yee wrote: > Issue #6: current metalanguage model acceptable? > Once errors are corrected, is the current metalanguage model (including > the 'u' prefixes) acceptable? ... Yes. > ... If not, should only those rules be included that are modified from > RFC 5321 or 5322 respectively, forcing the user to reference the > original documents for parts of substantially every rule? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 05:37:37 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 120DA3A711C for ; Thu, 20 Jan 2011 05:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.913 X-Spam-Level: X-Spam-Status: No, score=-3.913 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gV522JHjBz-j for ; Thu, 20 Jan 2011 05:37:35 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 8FDF93A6DAA for ; Thu, 20 Jan 2011 05:37:34 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 6359821E6B for ; Thu, 20 Jan 2011 13:40:16 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 13:40:16 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KDeFaA010652 for ; Thu, 20 Jan 2011 13:40:16 GMT Date: Thu, 20 Jan 2011 13:40:14 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <01NWRLLOJPBG007CHU@mauve.mrochek.com> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d383b40.2bcf-166c-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:37:37 -0000 On Tue, 18 Jan 2011 18:44:39 -0000, wrote: >> If there is to be a parameter on the MAIL FROM: command, it seems that >> it >> may have overloaded meanings: > >> 1 - The message immediately following has non-ASCII > > THat's not what the proposed parameter means. The proposed parameter is > an > indicator that the following *transaction* may contain utf-8 in several > new > places. The new places include not only header fields but also envelope > parameters. +1 However, it needs a NOTE to the efect that including this parameter in a message where it is not strictly necessary (that message is pure ASCII) MAY result in a more circuitous propagation path, or even in falure to deliver the message at all (e.g if the ultimate recipient does not advertise UTF8SMTPbis). >> 2 - The client is able to accept non-ASCII in responses to any >> commands >> related to the immediately following message > > You're making this sound like it is an independent thing. It's not. > It's a > direct consequence of sending utf-8 material (and addresses in > particular). +1 I don't think this meaning is perticularly important (and certainly not worth a second version of the parameter). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Thu Jan 20 05:42:23 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 CE3933A7209 for ; Thu, 20 Jan 2011 05:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 q7-dA8S5Qp1H for ; Thu, 20 Jan 2011 05:42:22 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 7DE903A7208 for ; Thu, 20 Jan 2011 05:42:21 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id B84CA21E7B for ; Thu, 20 Jan 2011 13:44:56 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 20 Jan 2011 13:44:56 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0KDitmq010936 for ; Thu, 20 Jan 2011 13:44:56 GMT Date: Thu, 20 Jan 2011 13:44:55 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <01NWT0CNL6QI007CHU@mauve.mrochek.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <01NWT0CNL6QI007CHU@mauve.mrochek.com> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d383c58.11fa9-63e1-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:42:23 -0000 On Wed, 19 Jan 2011 19:01:48 -0000, wrote: >> Nothing requires UTF-8, but we certainly strongly suggest that EAI >> messages >> are entirely UTF-8. IMO you'd be a pretty ugly EAI implementation if >> that >> wasn't your default. > > I think this is a very good point worthy of a separate consensus call - > the > format document needs to say something like: > > Media types that support multiple charsets SHOULD employ either > utf-8 or us-ascii. Not necessarily. If the body of the message cotains some long text in Chinese, then using some charset encoding other than UTF-8 might make good sense because than encoding may be more compact. UTF-8 can often use 3 (even 4) bytes to encode a character that other charsets can encode in 2 bytes. In headers, one can tolerate those extra bytes, but not so in long bodies. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From Claudio.Allocchio@garr.it Thu Jan 20 09:11: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 3ACF03A7037 for ; Thu, 20 Jan 2011 09:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvbMYdtR8Q5J for ; Thu, 20 Jan 2011 09:11:00 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 4071D3A7132 for ; Thu, 20 Jan 2011 09:10:56 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0KHDSrP011078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 18:13:29 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0KHDSrP011078 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=jqK16tYzycolZCsDEygLMTqczcYLrXfAf+6OsdfflDyRFHnnq+OaE5goirgX0UAkT rU/hrUx3EE0PnrpjJwp7722PQ5fV2du7AXHO3nVLCHmgoVYcHsAtg2stXjccEF2NJA9 qWCORTo8pNDWB+d5p1jIoWADG9Wg2U/9jMyRzn8= Date: Thu, 20 Jan 2011 18:13:28 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Barry Leiba In-Reply-To: Message-ID: References: <67C035C7-6D11-4D96-A067-1DDE8B644B86@ca.afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: EAI WG Subject: Re: [EAI] determining the question set for consensus call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:11:04 -0000 >> (5) Should the WG add additional text for gateways? > > I don't think that's in scope, so I'd say no. Follow-on informative > advice to gateways might be appropriate, as a separate effort. wherevet it is, there should be at least a short reference inside the document. > >> (6) Should the WG add additional text for ticket systems that interface with email >> address, internationalized string, log, and traces? > > I think my answer to that is the same as for (5). I wouldn't mind > brief text -- a paragraph, maybe -- that points out things to watch > for, but any significant treatment should be saved for follow-on > informative advice. same as above, and the Security consideration is the correct place for it, already in the document. ------------------------------------------------------------------------------ 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 tony@att.com Thu Jan 20 11:20:35 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 867703A67AD for ; Thu, 20 Jan 2011 11:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.896 X-Spam-Level: X-Spam-Status: No, score=-105.896 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh2y4RyQthlk for ; Thu, 20 Jan 2011 11:20:34 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 5D04F3A67AB for ; Thu, 20 Jan 2011 11:20:34 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1295551397!2944116!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 13295 invoked from network); 20 Jan 2011 19:23:17 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jan 2011 19:23:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0KJNdVH011929 for ; Thu, 20 Jan 2011 14:23:39 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0KJNYPs011832 for ; Thu, 20 Jan 2011 14:23:35 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0KJNCFu027430 for ; Thu, 20 Jan 2011 14:23:12 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0KJN4m7027160 for ; Thu, 20 Jan 2011 14:23:05 -0500 Received: from [135.70.213.81] (vpn-135-70-213-81.vpn.east.att.com[135.70.213.81]) by maillennium.att.com (mailgw1) with ESMTP id <20110120192304gw1004lko4e> (Authid: tony); Thu, 20 Jan 2011 19:23:04 +0000 X-Originating-IP: [135.70.213.81] Message-ID: <4D388B98.1000702@att.com> Date: Thu, 20 Jan 2011 14:23:04 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 CC: EAI WG References: <901FAFF275EADC2A13FBB129@[192.168.1.6]> In-Reply-To: <901FAFF275EADC2A13FBB129@[192.168.1.6]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [EAI] Consensus Issue #5: keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 19:20:35 -0000 On 1/18/2011 9:34 AM, John C Klensin wrote: > Yes, keep message/global and move on. +1 From Shawn.Steele@microsoft.com Thu Jan 20 11:40: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 25F693A67D2 for ; Thu, 20 Jan 2011 11:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] 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 GVzNrc4dRGl3 for ; Thu, 20 Jan 2011 11:40:02 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 57B2F3A67BD for ; Thu, 20 Jan 2011 11:40:02 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 11:42:40 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 11:42:40 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? Thread-Index: Acu42g6EMc4kD+KLQDaQmTwGgPpqKQ== Date: Thu, 20 Jan 2011 19:42:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 19:40:03 -0000 >> Issue #4: new reference and term for "ASCII", "non-ASCII", "UTF-8"? >> Should the WG replace references to "ASCII", "non-ASCII", and "UTF-8" =20 >> with new or different term s that precisely and accurately identify what= =20 >> is intended? > Yes. =20 > I have offered "UTF8-proper" as a possible term. FWIW: That's pretty unclear to me. I really think that there is no ready-m= ade term, particularly for non-ASCII, so whatever is used will need to be c= learly defined in the document. =09 From Shawn.Steele@microsoft.com Thu Jan 20 12:08:45 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 442403A67F5 for ; Thu, 20 Jan 2011 12:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqyqD1gw-Aib for ; Thu, 20 Jan 2011 12:08:44 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4240D3A67E2 for ; Thu, 20 Jan 2011 12:08:44 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 12:11:28 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 12:11:28 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: Acu43cWQXuQVh2F1RyK7OiCMykkWNA== Date: Thu, 20 Jan 2011 20:11:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 20:08:45 -0000 We're digressing, but it depends on whether or not you want the recipient t= o be able to be guaranteed to correctly decode the message. All of the CJK= encodings have encoding variations between platforms, vendors and systems.= Wikipedia lists some of them. Most of the problems around encodings have= to do with those types of inconsistencies. A few extra bytes is worth the= guarantee. (And if you attach a picture, then the size difference becomes= meaningless). In practice the size difference is probably only interestin= g for a text message on a satellite phone. -Shawn ------------------------------ Message: 2 Date: Thu, 20 Jan 2011 13:44:55 -0000 From: "Charles Lindsey" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: IMA Message-ID: Content-Type: text/plain; format=3Dflowed; delsp=3Dyes; charset=3Diso-8859-= 1 On Wed, 19 Jan 2011 19:01:48 -0000, wrote: >> Nothing requires UTF-8, but we certainly strongly suggest that EAI =20 >> messages >> are entirely UTF-8. IMO you'd be a pretty ugly EAI implementation if =20 >> that >> wasn't your default. > > I think this is a very good point worthy of a separate consensus call - = =20 > the > format document needs to say something like: > > Media types that support multiple charsets SHOULD employ either > utf-8 or us-ascii. Not necessarily. If the body of the message cotains some long text in Chinese, then using some charset encoding other than UTF-8 might make good = =20 sense because than encoding may be more compact. UTF-8 can often use 3 =20 (even 4) bytes to encode a character that other charsets can encode in 2 =20 bytes. In headers, one can tolerate those extra bytes, but not so in long = =20 bodies. --=20 Charles?H.?Lindsey?---------At?Home,?doing?my?own?thing--------------------= ---- Tel:?+44?161?436?6131? =20 ???Web:?http://www.cs.man.ac.uk/~chl Email:?chl@clerew.man.ac.uk??????Snail:?5?Clerewood?Ave,?CHEADLE,?SK8?3JU,?= U.K. PGP:?2C15F1A9??????Fingerprint:?73?6D?C2?51?93?A0?01?E7?65?E8?64?7E?14?A4?A= B?A5 From ned+ima@mrochek.com Thu Jan 20 14:07:06 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 1F9EE3A6844 for ; Thu, 20 Jan 2011 14:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsoA7MXAraHU for ; Thu, 20 Jan 2011 14:07:05 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 2C6993A6841 for ; Thu, 20 Jan 2011 14:07:05 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUL0WP79S00HGH9@mauve.mrochek.com> for ima@ietf.org; Thu, 20 Jan 2011 14:09:47 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRL7QI6DS007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 20 Jan 2011 14:09:45 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWUL0VNF98007CHU@mauve.mrochek.com> Date: Thu, 20 Jan 2011 09:12:02 -0800 (PST) In-reply-to: "Your message dated Thu, 20 Jan 2011 13:40:14 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed; DelSp=yes References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> To: Charles Lindsey DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295558331; bh=ucT/3ros8JdnujUvMmG7AjNY+OwUBLiK2fvEAhCTX7Y=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Dmm/fE5XB461FF1q5pQDDjxo403TYQxEKoV6PZAIM7tLltmhWLp7kf+WV0E3Fhw7Z I39QhOSztnHJvlSyz3oECU+LMuobLGQpQ2Jwje0Vk/nYrfOb2jyF6VNOVteHhybLr8 moSSWanAjuc/svn8ZPGUYUtoHLTfImK7uBL19xa4= Cc: IMA Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 22:07:06 -0000 > On Tue, 18 Jan 2011 18:44:39 -0000, wrote: > >> If there is to be a parameter on the MAIL FROM: command, it seems that > >> it > >> may have overloaded meanings: > > > >> 1 - The message immediately following has non-ASCII > > > > THat's not what the proposed parameter means. The proposed parameter is > > an > > indicator that the following *transaction* may contain utf-8 in several > > new > > places. The new places include not only header fields but also envelope > > parameters. > +1 > However, it needs a NOTE to the efect that including this parameter in a > message where it is not strictly necessary (that message is pure ASCII) > MAY result in a more circuitous propagation path, or even in falure to > deliver the message at all (e.g if the ultimate recipient does not > advertise UTF8SMTPbis). Yes, it would be a very good idea to include a statement like this. From ned+ima@mrochek.com Thu Jan 20 15:07:57 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 A4CFE3A686C for ; Thu, 20 Jan 2011 15:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8YctbvPJCdg for ; Thu, 20 Jan 2011 15:07:56 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 850813A6878 for ; Thu, 20 Jan 2011 15:07:56 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUN5D6EBK00E8JN@mauve.mrochek.com> for ima@ietf.org; Thu, 20 Jan 2011 15:10:39 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRL7QI6DS007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 20 Jan 2011 15:10:36 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWUN5BJ6XK007CHU@mauve.mrochek.com> Date: Thu, 20 Jan 2011 15:03:59 -0800 (PST) In-reply-to: "Your message dated Thu, 20 Jan 2011 20:11:27 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Shawn Steele DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295561983; bh=4zK8tCokZYoDGGkqGFshJ9q6aQb5d2NPp70Zm+ZaYy4=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=R8kxv4hKmOU+I79VruqQpTeMjhBhmXNDWWilVIzu5fZLDjmas/Vs6O3lJ+aMAgx7M itP9+Pw3Gw0YHTUmcmCNvGSKbAegqUyKdCE9ogGqq6ZKQW8PwSuj8UB1QtjsVgdjc/ Agzkxdr17PUcINSVORSXRhT706OH8ien4CAyvR2k= Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 23:07:57 -0000 > We're digressing, Again, I think this is sufficiently important it deserves to be called out as s separate issue to address. > but it depends on whether or not you want the recipient to > be able to be guaranteed to correctly decode the message. All of the CJK > encodings have encoding variations between platforms, vendors and systems. > Wikipedia lists some of them. UTF-8 is the exception here, which is why we need to encourage it's use. (OK, so is UTF-16, but it has other issues.) > Most of the problems around encodings have to do with those types of > inconsistencies. A few extra bytes is worth the guarantee. Almost always. But this is why I recommended a SHOULD, not a MUST. If a case arises where the increased size is really more of an issue than the myriad problems that arise from the generally crappy state of CJK encodings, then there's sufficient justification to be able to violate the SHOULD and still be able to claim compliance. > (And if you attach a picture, then the size difference becomes meaningless). > In practice the size difference is probably only interesting for a text message > on a satellite phone. Indeed. We spend WAY too much time overoptimizing this sort of thing. Ned From Shawn.Steele@microsoft.com Thu Jan 20 15:11:53 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 BDFDF3A687E for ; Thu, 20 Jan 2011 15:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h764ZGLyHfr2 for ; Thu, 20 Jan 2011 15:11:52 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D48033A687D for ; Thu, 20 Jan 2011 15:11:52 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 15:13:39 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 15:13:39 -0800 From: Shawn Steele To: Ned Freed Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: Acu43cWQXuQVh2F1RyK7OiCMykkWNAAGYqo3AAAUztA= Date: Thu, 20 Jan 2011 23:13:38 +0000 Message-ID: References: <01NWUN5BJ6XK007CHU@mauve.mrochek.com> In-Reply-To: <01NWUN5BJ6XK007CHU@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 23:11:53 -0000 SSB0aGluayBJIHNhaWQgU0hPVUxEPw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTmVkIEZyZWVkIFttYWlsdG86bmVkLmZyZWVkQG1yb2NoZWsuY29tXSANClNlbnQ6IFBvyrth aMSBLCBJYW51YWxpIDIwLCAyMDExIDM6MDQgaG91cnMNClRvOiBTaGF3biBTdGVlbGUNCkNjOiBp bWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgSXNzdWUgIzE6IHBhcmFt ZXRlciBvbiBNQUlMIEZST00/DQoNCj4gV2UncmUgZGlncmVzc2luZywNCg0KQWdhaW4sIEkgdGhp bmsgdGhpcyBpcyBzdWZmaWNpZW50bHkgaW1wb3J0YW50IGl0IGRlc2VydmVzIHRvIGJlIGNhbGxl ZCBvdXQgYXMgcyBzZXBhcmF0ZSBpc3N1ZSB0byBhZGRyZXNzLg0KDQo+IGJ1dCBpdCBkZXBlbmRz IG9uIHdoZXRoZXIgb3Igbm90IHlvdSB3YW50IHRoZSByZWNpcGllbnQgdG8gYmUgYWJsZSB0byAN Cj4gYmUgZ3VhcmFudGVlZCB0byBjb3JyZWN0bHkgZGVjb2RlIHRoZSBtZXNzYWdlLiAgQWxsIG9m IHRoZSBDSksgDQo+IGVuY29kaW5ncyBoYXZlIGVuY29kaW5nIHZhcmlhdGlvbnMgYmV0d2VlbiBw bGF0Zm9ybXMsIHZlbmRvcnMgYW5kIHN5c3RlbXMuDQo+IFdpa2lwZWRpYSBsaXN0cyBzb21lIG9m IHRoZW0uDQoNClVURi04IGlzIHRoZSBleGNlcHRpb24gaGVyZSwgd2hpY2ggaXMgd2h5IHdlIG5l ZWQgdG8gZW5jb3VyYWdlIGl0J3MgdXNlLiAoT0ssIHNvIGlzIFVURi0xNiwgYnV0IGl0IGhhcyBv dGhlciBpc3N1ZXMuKQ0KDQo+IE1vc3Qgb2YgdGhlIHByb2JsZW1zIGFyb3VuZCBlbmNvZGluZ3Mg aGF2ZSB0byBkbyB3aXRoIHRob3NlIHR5cGVzIG9mIA0KPiBpbmNvbnNpc3RlbmNpZXMuICBBIGZl dyBleHRyYSBieXRlcyBpcyB3b3J0aCB0aGUgZ3VhcmFudGVlLg0KDQpBbG1vc3QgYWx3YXlzLiBC dXQgdGhpcyBpcyB3aHkgSSByZWNvbW1lbmRlZCBhIFNIT1VMRCwgbm90IGEgTVVTVC4gSWYgYSBj YXNlIGFyaXNlcyB3aGVyZSB0aGUgaW5jcmVhc2VkIHNpemUgaXMgcmVhbGx5IG1vcmUgb2YgYW4g aXNzdWUgdGhhbiB0aGUgbXlyaWFkIHByb2JsZW1zIHRoYXQgYXJpc2UgZnJvbSB0aGUgZ2VuZXJh bGx5IGNyYXBweSBzdGF0ZSBvZiBDSksgZW5jb2RpbmdzLCB0aGVuIHRoZXJlJ3Mgc3VmZmljaWVu dCBqdXN0aWZpY2F0aW9uIHRvIGJlIGFibGUgdG8gdmlvbGF0ZSB0aGUgU0hPVUxEIGFuZCBzdGls bCBiZSBhYmxlIHRvIGNsYWltIGNvbXBsaWFuY2UuDQoNCj4gKEFuZCBpZiB5b3UgYXR0YWNoIGEg cGljdHVyZSwgdGhlbiB0aGUgc2l6ZSBkaWZmZXJlbmNlIGJlY29tZXMgbWVhbmluZ2xlc3MpLiAN Cj4gSW4gcHJhY3RpY2UgdGhlIHNpemUgZGlmZmVyZW5jZSBpcyBwcm9iYWJseSBvbmx5IGludGVy ZXN0aW5nIGZvciBhIA0KPiB0ZXh0IG1lc3NhZ2Ugb24gYSBzYXRlbGxpdGUgcGhvbmUuDQoNCklu ZGVlZC4gV2Ugc3BlbmQgV0FZIHRvbyBtdWNoIHRpbWUgb3Zlcm9wdGltaXppbmcgdGhpcyBzb3J0 IG9mIHRoaW5nLg0KDQoJCQkJTmVkDQoNCg== From ned+ima@mrochek.com Thu Jan 20 15:24:21 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 A46553A686C for ; Thu, 20 Jan 2011 15:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rADvDXY-NqYY for ; Thu, 20 Jan 2011 15:24:20 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 7F3CF3A6870 for ; Thu, 20 Jan 2011 15:24:20 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUNPOGXHS00G82H@mauve.mrochek.com> for ima@ietf.org; Thu, 20 Jan 2011 15:27:02 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWRL7QI6DS007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 20 Jan 2011 15:26:59 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWUNPN55P8007CHU@mauve.mrochek.com> Date: Thu, 20 Jan 2011 15:25:20 -0800 (PST) In-reply-to: "Your message dated Thu, 20 Jan 2011 23:13:38 +0000" References: <01NWUN5BJ6XK007CHU@mauve.mrochek.com> To: Shawn Steele DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295562966; bh=MrJeUx5T1W39gjF+ut3mOFrLCk9qdtvtwwJecmGSi2k=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:References:To; b=QnJXq5OgViQIHvyjamwdWXVDHje/Hlwedt1SNfQmhOP0de+VIlgzPalebVdy0UyRX RX1YN8kpU3GsNpDYmniS9WrApRLMKOO2NhA8WX+0hKfX6dWIHcfzAOsvXMHL4Fw86o pJV4zXrFw8lIAIx3ZsvCBN5Em5cN+5cyyYXVLsSY= Cc: Ned Freed , "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 23:24:21 -0000 > I think I said SHOULD? Yes; my point was that even if Charles' objection is legitimte, the necessary freedom to use other CJK encodings isn't being eliminated by what we're proposing. Ned > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: PoÊ»ahÄ, Ianuali 20, 2011 3:04 hours > To: Shawn Steele > Cc: ima@ietf.org > Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? > > We're digressing, > Again, I think this is sufficiently important it deserves to be called out as s separate issue to address. > > but it depends on whether or not you want the recipient to be able to > > be guaranteed to correctly decode the message. All of the CJK > > encodings have encoding variations between platforms, vendors and systems. > > Wikipedia lists some of them. > UTF-8 is the exception here, which is why we need to encourage it's use. (OK, so is UTF-16, but it has other issues.) > > Most of the problems around encodings have to do with those types of > > inconsistencies. A few extra bytes is worth the guarantee. > Almost always. But this is why I recommended a SHOULD, not a MUST. If a case arises where the increased size is really more of an issue than the myriad problems that arise from the generally crappy state of CJK encodings, then there's sufficient justification to be able to violate the SHOULD and still be able to claim compliance. > > (And if you attach a picture, then the size difference becomes meaningless). > > In practice the size difference is probably only interesting for a > > text message on a satellite phone. > Indeed. We spend WAY too much time overoptimizing this sort of thing. > Ned > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From dhc2@dcrocker.net Thu Jan 20 16:02: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 3A44B3A6891 for ; Thu, 20 Jan 2011 16:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojj6FlipSkTH for ; Thu, 20 Jan 2011 16:02:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id BA60B3A688C for ; Thu, 20 Jan 2011 16:02:01 -0800 (PST) Received: from [192.168.1.213] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0L04ehr030580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 20 Jan 2011 16:04:45 -0800 Message-ID: <4D38CD94.8050800@dcrocker.net> Date: Thu, 20 Jan 2011 16:04:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf-eai References: <4D370D51.7060801@bbiw.net> In-Reply-To: <4D370D51.7060801@bbiw.net> 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, 20 Jan 2011 16:04:46 -0800 (PST) Subject: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jan 2011 00:02:03 -0000 Folks, The answer to consensus call question 6 should be 'no'. Ned Freed, Pete Resnick and I have been discussing the working group's basic model for handling UTF-8 within a legacy, 7-bit world. The current approach is certainly in line with the long-standing IETF pressure (demand) to have changes of an existing system be designed in a way that protects and interworks with the installed base, such as by not damaging a legacy system that receives an enhanced form of data. And indeed, the working group's SMTP extension is an example of keeping the new object away from legacy-only systems. However, the model used in the case of RFC 5335 -- using new syntax elements instead of extending old ones -- has produced quite a bit of complexity. In this case, we believe the complexity is not serving the working group's goals all that well. That leads us to make a somewhat surprising suggestion to simplify things considerably. The premise behind the suggestion is that the world really does have extensive infrastructure for UTF-8 already and that we can rely on it. So, 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. This would create what essentially would be an independent, UTF-8 email world. Interworking with the legacy email world still needs to be specified, but it should be done separately. With the caveat that IDN handling in the spec still needs to be done, this produces a candidate to replace for Section 4.3, 4.4 and 4.5 from the existing draft: [[ -------------------------------------- This section specifies UTF-8 enhancements for the header of an Internet Mail message, as defined in [RFC5322]. ABNF used in this section is taken from that specification and the ABNF specification. This specification retains the [RFC5322] rules for defining header field names. The bodies of header fields are allowed to contain UTF-8 characters, but the header field names themselves must contain only ASCII characters. The following rules extend the corresponding rules in [RFC5322] and [RFC5234] in order to allow additional Unicode characters. VCHAR =/ UTF8-non-ascii ctext =/ UTF8-non-ascii atext =/ UTF8-non-ascii qtext =/ UTF8-non-ascii {{ how to add IDN to this? }} domain = dot-atom / domain-literal / obs-domain This means that all the [RFC5322] constructs that build upon these will permit UTF-8 characters, including comments and quoted strings. [RFC5322] has the rule which specifies permissible names for user-defined header fields. The current specification defines no changes to that rule. This ABNF enables Message-ID strings to be full UTF-8. However the specification directs that Message-ID strings SHOULD be restricted to ASCII. -------------------------------------- ]] The SMTP extension is essential to this, of course. In addition it's worth repeating that specification of UTF8-to-ASCII gatewaying is still needed, but we suggest it be moved to a separate specification. Since these are very basic ABNF rules, changes to them have an extensive effect that is not immediately obvious. So to aid the reader, it's worth adding an appendix that lists the other ABNF of RFC5322 that would be affected (ignoring the obs- rules)... [[ -------------------------------------- A. Changes to support UTF-8 This section provides a basic audit of the places in a message that now can permit UTF-8 rather than being restricted to ASCII, based on the changes to underlying ABNF. The audit ignores rules for "obsolete" constructs in RFC 5322. VCHAR: quoted-pair, unstructured > ccontent, qcontent > comment, quoted-string > word, local-part > phrase > display-name, keywords > name-addr > mailbox, group > address > address-list, mailbox-list > received-token, received > from, sender > reply-to, to, cc, bcc, resent-* > subject, comments, optional-field ctext: ccontent > comment > comments atext: atom, dot-atom-text > msg-id > local-part, domain > addr-spec > mailbox qtext: qcontent quoted-string -------------------------------------- ]] -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned+ima@mrochek.com Thu Jan 20 16:52:30 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 8C06E3A6884 for ; Thu, 20 Jan 2011 16:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSVSLgmay3s0 for ; Thu, 20 Jan 2011 16:52:29 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 788C43A6858 for ; Thu, 20 Jan 2011 16:52:29 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUQSXN7CW00G89L@mauve.mrochek.com> for ima@ietf.org; Thu, 20 Jan 2011 16:55:10 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUPO6UX5S007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 20 Jan 2011 16:55:05 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWUQSV2HH2007CHU@mauve.mrochek.com> Date: Thu, 20 Jan 2011 16:47:52 -0800 (PST) In-reply-to: "Your message dated Thu, 20 Jan 2011 12:22:30 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed; DelSp=yes References: To: Charles Lindsey DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295568254; bh=mW0+LPJtUUBhG6RmEbvp9ZradwcULBbFysFAaIH187A=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=TJkkzLJZvJqcA8H0+OXOJhDvjfeuX3lHq4xvI4J5oNCKOJmS+S8wjyIVBsUUhuqaJ ZF6ihOS1ataWCKL6T4J0Fd69qShCO0y0K8AbNtUJuuI770pixrC6UEbqKYQF1wHDyd BU7yipbzhxXaQcE1uocwu9aL9y9IYK2TeRhyaxyc= Cc: IMA Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 21 Jan 2011 00:52:30 -0000 > On Mon, 17 Jan 2011 17:15:42 -0000, Joseph Yee > wrote: > > Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? > > > > Should the new parameter to VRFY/EXPN only be permitted after the SMTP > > client issued EHLO command and saw a response that included UTF8SMTPbis? > Yes. > But note that its use after the EHLO cannot be enforced by the server. It > needs to take the form: Well, it could, since the server can in theory keep track of whether or not EHLO has been issued, and refuse to allow the parameter if no EHLO has been seen. But this opens up a can of worms. Suppose, for example, you want to further restrict use of UTF8SMTPbis to clients that have done a STARTTLS, or have authenticated with the correct identity, or whatever. (RFC 5321 makes it very clear that sites are free to impose these sorts of policy-based restrictions.) So it might be the case that the iniitial EHLO response the client got from the server didn't include UTF8SMTPbis but the one it got later did. So now the server has to track whether or not it sent back an EHLO response with the "right stuff" in it. This is added complexity for no tangible benefit, and is why I oppose saying "Servers MUST NOT accept VRFY/EXPN with the parameter without first having offered the extension in an EHLO response." > "Clients MUST NOT use this parameter unless ..." That's exactly the wording that I think needs to be used. > If clients fail to heed that, then "garbage in - garbage out" will apply. Yep. Ned From Shawn.Steele@microsoft.com Thu Jan 20 16:57:38 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 43AE53A6893 for ; Thu, 20 Jan 2011 16:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXxAXUCPnq76 for ; Thu, 20 Jan 2011 16:57:37 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 820A93A688C for ; Thu, 20 Jan 2011 16:57:37 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 17:00:21 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 17:00:21 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? Thread-Index: Acu5Bmdj3o7YIeppSum6/z1QPrA2BQ== Date: Fri, 21 Jan 2011 01:00:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 21 Jan 2011 00:57:38 -0000 > > But note that its use after the EHLO cannot be enforced by the server. = It > > needs to take the form: > Well, it could, since the server can in theory keep track of whether or n= ot > EHLO has been issued, and refuse to allow the parameter if no EHLO has be= en > seen. Well, but the server still couldn't "enforce" that the client not send it. = It could fail or something if the client went ahead and did it, but the se= rver can't prevent bad client behavior. -Shawn From johnl@iecc.com Thu Jan 20 17:30:31 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 ADD613A687C for ; Thu, 20 Jan 2011 17:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.051 X-Spam-Level: X-Spam-Status: No, score=-111.051 tagged_above=-999 required=5 tests=[AWL=0.148, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvfNKOEZA+uB for ; Thu, 20 Jan 2011 17:30:30 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id F27D03A680E for ; Thu, 20 Jan 2011 17:30:29 -0800 (PST) Received: (qmail 52922 invoked from network); 21 Jan 2011 01:33:13 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 21 Jan 2011 01:33:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=12d25.4d38e259.k1101; i=johnl@user.iecc.com; bh=5nuoK9djbgLePRE//smbQePrzdPpG++0eqRX6SSREBE=; b=EvtvD9eb+q8E0uDP0A2LWS9HmbiuqaBeXT8s9oErM0vurImPCGg34Hx3GZchKVUQcgGXzPSmKt1ww4652ofAv3s8lVL3CqzIS/Y2tjMDg0wS83uBwAPSMeuyqVfgJHRhresFUC9m9DAzdVbFAP3uXThFOvR3c2b/a2D1PkrLXok= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=12d25.4d38e259.k1101; olt=johnl@user.iecc.com; bh=5nuoK9djbgLePRE//smbQePrzdPpG++0eqRX6SSREBE=; b=SCW6b+N0GRi9dyneQeHgjJmfAeZ95CtHs5zjRUe6iSf5rr4G7aGNKzgLQQQ0IsQpEpPrpfzNeAPHR+yPGv5Xco2yizlNvCvGQnnISHAS+K2uFtcdXqKtr5Rao17o7t1LOAwQItcmccAPD+kclgc56ioDXlexNW4SsYlZftFJGvk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 21 Jan 2011 01:33:12 -0000 Message-ID: <20110121013312.77092.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <01NWUQSV2HH2007CHU@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 21 Jan 2011 01:30:31 -0000 >> But note that its use after the EHLO cannot be enforced by the server. Standards tell you how to write your code to interoperate with other systems that have implemented the same standard. The answer to questions about what happens if you do something other than what the standard says boil down to "Who knows?" and "Don't do that." So if you want your EAI VRFY to work, insofar as VRFY works at all, say EHLO first. >> "Clients MUST NOT use this parameter unless ..." > >That's exactly the wording that I think needs to be used. Right. R's, John From ned+ima@mrochek.com Thu Jan 20 17:43:15 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 3316F3A68A0 for ; Thu, 20 Jan 2011 17:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8-9axr2UeLk for ; Thu, 20 Jan 2011 17:43:14 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 30D8B3A689D for ; Thu, 20 Jan 2011 17:43:14 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUSKVSNQO00ERIG@mauve.mrochek.com> for ima@ietf.org; Thu, 20 Jan 2011 17:45:56 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUSHERALC007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 20 Jan 2011 17:45:53 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWUSKUI0G0007CHU@mauve.mrochek.com> Date: Thu, 20 Jan 2011 17:45:16 -0800 (PST) In-reply-to: "Your message dated Thu, 20 Jan 2011 12:16:14 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed; DelSp=yes References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> To: Charles Lindsey DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295571299; bh=AdEEJedl5bppuoDn40P+g6yC/6w4uexSgvyU+iI8pMA=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=PHBHOcyTAjrAxgn6xlx39j9OZ8bdjaVIvtJQoozSd1qqK9lCTP6pq2sLWv1uDe6YH WNjmm2L2DBZbFRvXlZ3tdTel+pchPzs/PAULFJcQTraWzp2jc2kPNepAqzkmRWXVWU Ft2SeMapKjHScAKVlXsxAy69DdnNxjLmU5Oml9mA= Cc: IMA Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 01:43:15 -0000 > On Mon, 17 Jan 2011 17:15:40 -0000, Joseph Yee > wrote: > > Issue #1: parameter on MAIL FROM? > > > > Should the WG add parameter on MAIL FROM to start EAI transaction and > > avoid the need for deep inspection? > Yes. Agreed. > Ideally with the same syntax as for any other commands where we add > parameters, and ideally using the same keyword (UTF8SMTPbis) as used in > EHLO I don't much care what the keyword is, but having it match is nice. Ned From ned+ima@mrochek.com Thu Jan 20 17:45:13 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 0BC363A6836 for ; Thu, 20 Jan 2011 17:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQxcGsWlATqH for ; Thu, 20 Jan 2011 17:45:12 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 25F253A689E for ; Thu, 20 Jan 2011 17:45:12 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUSNC1M6800ERIG@mauve.mrochek.com> for ima@ietf.org; Thu, 20 Jan 2011 17:47:55 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWUSHERALC007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 20 Jan 2011 17:47:52 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWUSNAZGYO007CHU@mauve.mrochek.com> Date: Thu, 20 Jan 2011 17:46:58 -0800 (PST) In-reply-to: "Your message dated Fri, 21 Jan 2011 01:00:21 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Shawn Steele DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295571418; bh=E6YOTkO+CAnO8ULcqsAzG1Hd8C8bjXvaMbRdFSOUj6c=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=gt5ZqgftzbPV8UalOwLWLVY3Lm85Jc+/3YfJUXHHOaueaxsQFtUtEsncJ7kiekf0C TDXw0nJB5JcOTcH2eh670czfAHKAxC0dYeBRCtYESga6MmNBpapBKZfUjE6if0qtvP +gw20lFLaWleYOpH4w/vgvQOTW1rr1fIGa8TXE5k= Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 21 Jan 2011 01:45:13 -0000 > > > But note that its use after the EHLO cannot be enforced by the server. It > > > needs to take the form: > > Well, it could, since the server can in theory keep track of whether or not > > EHLO has been issued, and refuse to allow the parameter if no EHLO has been > > seen. > Well, but the server still couldn't "enforce" that the client not send it. Ah, that makes more sense. Of course it can't. > It could fail or something if the client went ahead and did it, but the server > can't prevent bad client behavior. Very true. I just don't want servers to be required to check for it in this case. Ned From Shawn.Steele@microsoft.com Thu Jan 20 17:47:10 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 024B43A6836 for ; Thu, 20 Jan 2011 17:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHanuEF5lt7D for ; Thu, 20 Jan 2011 17:47:08 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 51E6B3A67D1 for ; Thu, 20 Jan 2011 17:47:08 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 17:49:52 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 17:49:52 -0800 From: Shawn Steele To: Ned Freed Thread-Topic: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? Thread-Index: Acu5Bmdj3o7YIeppSum6/z1QPrA2BQABvIqXAAAEwRA= Date: Fri, 21 Jan 2011 01:49:51 +0000 Message-ID: References: <01NWUSNAZGYO007CHU@mauve.mrochek.com> In-Reply-To: <01NWUSNAZGYO007CHU@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 21 Jan 2011 01:47:10 -0000 I figure new servers will probably check (since they sent it), and old serv= ers won't check :) -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com]=20 Sent: Thursday, January 20, 2011 5:47 PM To: Shawn Steele Cc: ima@ietf.org Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only afte= r EHLO with UTF8SMTPbis? > > > But note that its use after the EHLO cannot be enforced by the=20 > > > server. It needs to take the form: > > Well, it could, since the server can in theory keep track of whether=20 > > or not EHLO has been issued, and refuse to allow the parameter if no=20 > > EHLO has been seen. > Well, but the server still couldn't "enforce" that the client not send it= .=20 Ah, that makes more sense. Of course it can't. > It could fail or something if the client went ahead and did it, but=20 > the server can't prevent bad client behavior. Very true. I just don't want servers to be required to check for it in this= case. Ned From Claudio.Allocchio@garr.it Fri Jan 21 01:21:26 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 EC33E3A68FC for ; Fri, 21 Jan 2011 01:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIgThE12qo8y for ; Fri, 21 Jan 2011 01:21:25 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 9429F3A68F7 for ; Fri, 21 Jan 2011 01:21:20 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0L9O0wt060224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 10:24:01 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0L9O0wt060224 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=C6/rXeIl8BPEynqoi+sYVH0G8D17NhpGQcK+8hLdM/0S6m1IVV1+SMUNaLFN1qpBd RuHezzjr8TaPskKZhjUDhy9Qw5/BgDseKS4s53LnIrlGVLUR7UJEpaYTDXLRH9yyV5D Lpn0Igr2cu0PqQzA4BIEWOUvo0lcFRz3a/DHB6Y= Date: Fri, 21 Jan 2011 10:24:00 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: ned+ima@mrochek.com In-Reply-To: <01NWRXAXUKQU007CHU@mauve.mrochek.com> Message-ID: References: <20110118160214.45092.qmail@joyce.lan> <564971012.20110118102550@pobox.com> <38B4C798C12D3203B705ED86@[192.168.1.6]> <38B4C798C12D3203B705ED86@[192\.168\.1\.6]> <1033592644.20110118152356@pobox.com> <01NWRXAXUKQU007CHU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Bill McQuillan , IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 09:21:27 -0000 On Tue, 18 Jan 2011, ned+ima@mrochek.com wrote: >> I am concerned about the case where the client does NOT know that there is >> an EAI facility needed, but THERE IS a need! > > OK, now I see what you're getting at. My problem with this is that in my > experience the use of the address correction facilities in RFC 5321 is quite > rare, bordering on nonexistent. I'd like to see some evidence that such > facilities are not just in some code somewhere, but in such active use that the > costs of complicating this proposal are worth the added benefit of supporting > this capability for non-ASCII responses. I stepped into such (or nearly such) implementation only once (an old version of Communigate), which however was always resulting in a non delivery message ("no such user") to sender because all the clients in common use did not understand the answer (forwarding suggestion) correctly, even if the message was pure ASCII anyhow. In subsequest versions it seems this "feature" was replaced by a plain "accept, store, then re-deliver" approach when forwarding was in actions, and no more problems were reported (at least to my knowledge). Thus, +1 to Ned's comment. The complication is not worth the benefits. > The tradeoff here may seem to be similar to when we decide whether or not to > retain some obscure feature in some specification (like, say, all the obsolete > syntax in RFC 5322), but it really isn't. The difference is in fact rather > stark: Support costs versus deployment costs. > > Most of the support costs for obscure existing are, in one way or > another, sunk costs, e.g., if you have code that supports source routes, > you've already paid the price of developing that code. correct. it's already there *and working*, let it live. > Deployment costs are another matter. These are mostly future costs and > hence have a direct impact on deployability - the more complex and > costly this stuff is to implement and operate, the less people are going > to be willing to be early adopters. Raise the cost too high, and this > dog is not going to hunt. And that more than anything is my goal here - > I want this specification to be as simole and as easy to implement as > possible, because otherwise I think this group is going to be very > surprised at just how little large parts of the world care about having > the ability to put utf-8 in addresses. > >> For example, a client (which is EAI compliant) is handed a message (say, by >> SUBMISSION) which has no non-ASCII recipients or non-ASCII in its header. >> The client contacts the MX server for one or more of the recipients and >> begins a transaction with MAIL FROM: using *no* UTF8 parameter. > >> It then sends RCPT TO: commands until one of the recipients has a >> forwarding address and the MX server would like to return a 551 reply >> suggesting a . However, the is a non-ASCII >> address and the MX server has no way to return this to the client since the >> client must be presumed to be NON-EAI compliant due to the lack of a UTF8 >> parameter on the MAIL FROM: command. > >> This all presumes we are using the UTF8 parameter to both relieve the MX server >> from Deep-Analysis as well as informing it of the capabilities of the >> client. > > I think the avoidance of message inspection is vitally important, but > let's not forget this also facilities early rejection of messages on a > per-recipient basis as well. another +1 > > Ned > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 01:45:22 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 71A7B3A6904 for ; Fri, 21 Jan 2011 01:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Id3uCjBvHS6p for ; Fri, 21 Jan 2011 01:45:21 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 23AB23A68F0 for ; Fri, 21 Jan 2011 01:45:20 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0L9m1t0060874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 10:48:01 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0L9m1t0060874 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=aCgHWvLfhUgUPc4Kdw7A++M6RlLnSoalZwLh8ZsCmlPUHzVS78O4EiWzNrz1cduEy xqlaBXOAZ3dgE+nFYZyyCbCsjQoxtDFCFgV2pzLfvNyEltMWvaJDckAQ0mqXHsWJmMx 50TZGQ/0guOYgyscwILP+37ByLX5xWXKJ3x6wjE= Date: Fri, 21 Jan 2011 10:48:00 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: ned+ima@mrochek.com In-Reply-To: <01NWT0CNL6QI007CHU@mauve.mrochek.com> Message-ID: References: <01NWT0CNL6QI007CHU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 09:45:22 -0000 On Wed, 19 Jan 2011, ned+ima@mrochek.com wrote: >> Nothing requires UTF-8, but we certainly strongly suggest that EAI messages >> are entirely UTF-8. IMO you'd be a pretty ugly EAI implementation if that >> wasn't your default. > > I think this is a very good point worthy of a separate consensus call - the > format document needs to say something like: > > Media types that support multiple charsets SHOULD employ either > utf-8 or us-ascii. +1 +2 +3 !! > As Shown wells knows, the continued use of charsets other than utf-8, > especially some of the multibyte ones whose definitions vary depending > on the software you're using, represent a significant ongoing interoperability > problem for email. Given that you have to support utf-8 to support EAI, there > is absolutely no reason for EAI to condone this nonsense. just go back to the messages on the EAI ML where the "Rene'" :-) example was done, and you will see how many nonsense variations occured just in reporting the accented character. My old, and strict, PINE v4.64 client was continuosly struggling to undestand each variation :-) Of course other less primitive implementations always showed the accented "e" correctly, accepting many variants. > > Ned > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 01:56:10 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 C4C383A690A for ; Fri, 21 Jan 2011 01:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEHvXmHu375E for ; Fri, 21 Jan 2011 01:56:09 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 5B66E3A6902 for ; Fri, 21 Jan 2011 01:56:09 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0L9wotY061182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 10:58:51 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0L9wotY061182 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=mvB48osllMlzT0OnpCVhI0LQa9uUJXYFWvwUZ2R8/DTs82g2mxRYWmWUPTng5XVOn d849S6HmZZvlKN6OggmorRSDBHt4Oj3dZvuJiZbPrbPe3ZKGGADk6caQLjrOls47RVw H2CYXlqvmvr1NT/r7uQKMWY2O7eapUfqqYGJw3M= Date: Fri, 21 Jan 2011 10:58:48 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: John C Klensin In-Reply-To: <30EF3ED84638B542586BC59C@[192.168.1.6]> Message-ID: References: <30EF3ED84638B542586BC59C@[192.168.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 09:56:10 -0000 On Wed, 19 Jan 2011, John C Klensin wrote: > > I fear it is quite a common case and is likely to be for some > time. Remember an observation that folks from your company have > probably made more strongly than anyone else: servers get > upgraded and replaced according to need but Operating Systems > and fundamental software (probably including non-web-client > MUAs, including POP and IMAP clients) get upgraded only when > computers are replaced. "do not touch a working MUA and MTA" is a common message in nearly all environments... and unless you really know that an upgrade will solve you many problems, nobody will do upgrades (... or more specifically, nobody will be allowed to do an upgrade, just because of the - small - risk of having a non working e-mail system after it). Okay... we could start teling people that implementing EAI conformance will solve spam problems... and everybody will rush tu support it. But where do we hide ourselves when they discover it is not true? *the above sentence is a joke* > > john > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 02:01:27 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 4C25F3A690D for ; Fri, 21 Jan 2011 02:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfxZJgtnjUfj for ; Fri, 21 Jan 2011 02:01:26 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id DD51A3A6902 for ; Fri, 21 Jan 2011 02:01:25 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0LA461W061403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 11:04:07 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0LA461W061403 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=j0WC984pYQ5VDZk57rugOKcpfzOYofO8WBi+mpoRDybpVaXwlYe6146gcgv015FhQ zDdRQRKhxR5HP/0hqcbWhe8ReJkSN0MpjYgf2DYR41w5xopYaKbdlOBdNVm3VXoPSxM 9MECrBdvmhGpcL8eH7QwNkHa+VWkYNAHCkbdDJ0= Date: Fri, 21 Jan 2011 11:04:02 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: ned+ima@mrochek.com In-Reply-To: <01NWUL0VNF98007CHU@mauve.mrochek.com> Message-ID: References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> <01NWUL0VNF98007CHU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Charles Lindsey , IMA Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 10:01:27 -0000 >> However, it needs a NOTE to the efect that including this parameter in a >> message where it is not strictly necessary (that message is pure ASCII) >> MAY result in a more circuitous propagation path, or even in falure to >> deliver the message at all (e.g if the ultimate recipient does not >> advertise UTF8SMTPbis). > > Yes, it would be a very good idea to include a statement like this. True: requesting by default optional services when you do not need them either results in unecessary "costs", or potential risks. Thus we need to warn implementors (or users configuring things). ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 02:37:02 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 C4AB23A6902 for ; Fri, 21 Jan 2011 02:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 bEMcED0jWUTl for ; Fri, 21 Jan 2011 02:37:01 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 3B8403A6909 for ; Fri, 21 Jan 2011 02:37:00 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0LAdcKB062354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 11:39:39 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0LAdcKB062354 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=R6B2MZ6v9MtJkQ0RsvB/vL02Vz2CzQsE1A1V8At8H//VimV3qgL41liXmbxnZ/r3g O+D2xZv3gRhvifm5lmzuJeuVEflDX2ACy8sAQr5PK2kTI3cGh++CCuGRPvUjFLs63v5 Oevh+LVecDMTWirDbX6+vcZQtQXOS6bqjzgf+Pg= Date: Fri, 21 Jan 2011 11:39:38 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Charles Lindsey In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IMA Subject: Re: [EAI] Consensus Issue #3: remove repetition of normative text? 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, 21 Jan 2011 10:37:02 -0000 >> Issue #3: remove repetition of normative text? > >> Should the WG remove repetition of normative text from other documents to >> the extent possible. Incorporate by reference and, where necessary, note >> explicitly that tutorial / context-providing references are not normative. > YES! > But please replace removed syntax by NOTEs of the form > " is defined in [RFCyyy] to be of the form: > " > so that readers can follow the intent of the documents without excessive > switching between RFCs. As I said in my review, repetitions, AND summaries can be very dangerous, non only when the original specification gets an update, but because they can give the reader/implementor the false sense of complete understanding of the environment (and e-mail IS complex). I'm inclided to say yes to helpful examples, and no to brief syntax summaries. ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 03:06:33 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 DBB233A6924 for ; Fri, 21 Jan 2011 03:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgsByM8HTMkB for ; Fri, 21 Jan 2011 03:06:32 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 7529E3A6921 for ; Fri, 21 Jan 2011 03:06:31 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0LB924I063287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 12:09:04 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0LB924I063287 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=miXYeuMUQH+y8x2cU84ZxIhJs3/5LJA9zgzE8XRmJpJp2H/qG54nkCBjxqWDiPtpc x/JTDfz7HmyOjeABCsxtlXdht0GnGal7S/qOnGY0IZdysSAbHD8YNzte/UcSIc5znG2 meGjEMCLe1+jepZw0Ku++gcH7FGPCWHWj0OdDek= Date: Fri, 21 Jan 2011 12:09:02 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: dcrocker@bbiw.net In-Reply-To: <4D38CD94.8050800@dcrocker.net> Message-ID: References: <4D370D51.7060801@bbiw.net> <4D38CD94.8050800@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf-eai Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) 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, 21 Jan 2011 11:06:33 -0000 On Thu, 20 Jan 2011, Dave CROCKER wrote: > > Folks, > > > The answer to consensus call question 6 should be 'no'. the model used in current specificaions was one of my biggest worries in my review of the specification (see below); > Ned Freed, Pete Resnick and I have been discussing the working group's basic > model for handling UTF-8 within a legacy, 7-bit world. The current approach > is > certainly in line with the long-standing IETF pressure (demand) to have > changes > of an existing system be designed in a way that protects and interworks with > the > installed base, such as by not damaging a legacy system that receives an > enhanced form of data. And indeed, the working group's SMTP extension is an > example of keeping the new object away from legacy-only systems. which is correct. > However, the model used in the case of RFC 5335 -- using new syntax elements > instead of extending old ones -- has produced quite a bit of complexity. In > this > case, we believe the complexity is not serving the working group's goals all > that well. If we follow the current model, we will legitimate EAI-compliant systems to inject into the legacy installed base messages which are suppoused to be conformant, because we "updated" some specifications, instead of "extending them". As said earlier, however, we cannot expact the installed base to "update" so quickly, and this can result in serious problems, including loss of data (imagine a logging system which crashes because it receives someting which it cannot handle correctly, thus loosing the records still in memory). > > That leads us to make a somewhat surprising suggestion to simplify > things considerably. The premise behind the suggestion is that the > world really does have extensive infrastructure for UTF-8 already and > that we can rely on it. > > So, 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. > > This would create what essentially would be an independent, > UTF-8 email world. > > Interworking with the legacy email world still needs to be > specified, but it should be done separately. > +1 > With the caveat that IDN handling in the spec still needs to be done, this > produces a candidate to replace for Section 4.3, 4.4 and 4.5 from the > existing draft: > > > [[ -------------------------------------- > > > > This section specifies UTF-8 enhancements for the header of an > Internet Mail message, as defined in [RFC5322]. > > ABNF used in this section is taken from that specification and the > ABNF specification. > > This specification retains the [RFC5322] rules for defining header > field names. The bodies of header fields are allowed to contain UTF-8 > characters, but the header field names themselves must contain only > ASCII characters. > > The following rules extend the corresponding rules in [RFC5322] and > [RFC5234] in order to allow additional Unicode characters. > > VCHAR =/ UTF8-non-ascii > > ctext =/ UTF8-non-ascii > > atext =/ UTF8-non-ascii > > qtext =/ UTF8-non-ascii > > {{ how to add IDN to this? }} > domain = dot-atom / domain-literal / obs-domain > > This means that all the [RFC5322] constructs that build upon these > will permit UTF-8 characters, including comments and quoted strings. > > > > [RFC5322] has the rule which specifies > permissible names for user-defined header fields. The current > specification defines no changes to that rule. > > > > This ABNF enables Message-ID strings to be full UTF-8. > However the specification directs that Message-ID strings SHOULD be > restricted to ASCII. > > > -------------------------------------- ]] > > > > > The SMTP extension is essential to this, of course. In addition it's worth > repeating that specification of UTF8-to-ASCII gatewaying is still needed, but > we > suggest it be moved to a separate specification. > > Since these are very basic ABNF rules, changes to them have an > extensive effect that is not immediately obvious. So to aid the > reader, it's worth adding an appendix that lists the other ABNF of > RFC5322 that would be affected (ignoring the obs- rules)... another +1 > > > > > [[ -------------------------------------- > > A. Changes to support UTF-8 > > This section provides a basic audit of the places in a message that > now can permit UTF-8 rather than being restricted to ASCII, based on > the changes to underlying ABNF. The audit ignores rules for "obsolete" > constructs in RFC 5322. > > VCHAR: > quoted-pair, unstructured > > ccontent, qcontent > > comment, quoted-string > > word, local-part > > phrase > > display-name, keywords > > > name-addr > > mailbox, group > > address > > > address-list, mailbox-list > > > received-token, received > > > from, sender > > reply-to, to, cc, bcc, resent-* > > > subject, comments, optional-field > > > ctext: > ccontent > comment > comments > > > atext: > atom, dot-atom-text > > > msg-id > > > local-part, domain > > addr-spec > > mailbox > > > qtext: > qcontent quoted-string > > > -------------------------------------- ]] > > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 03:13:15 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 271663A691C for ; Fri, 21 Jan 2011 03:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 rRmUKtDWhTo1 for ; Fri, 21 Jan 2011 03:13:14 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 9D84D3A6921 for ; Fri, 21 Jan 2011 03:13:13 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0LBFsw5063525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 12:15:54 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0LBFsw5063525 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=NPnp35ORRIHDmbsg6pyTPHYfkgRcNpKFY4EAF2MNre+vYqRzkiJR52YmGnwicl37I o10isaOKhPyVNGfptbK+6ZrcCOrWABSaEI/1tcql2lmaDeQMdVld8jBkRJukLFrfRjd pnh5xbuoSClXyFevwR/0lwTZbMj3sMb0NXz1jHo= Date: Fri, 21 Jan 2011 12:15:54 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: John C Klensin In-Reply-To: <48395489468C8DAA755D2A26@[192.168.1.6]> Message-ID: References: <48395489468C8DAA755D2A26@[192.168.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ned Freed , Shawn Steele , ima@ietf.org Subject: Re: [EAI] Consensus Issue #???: Media types that support multiple charsets SHOULD employ utf-8 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, 21 Jan 2011 11:13:15 -0000 On Wed, 19 Jan 2011, John C Klensin wrote: > --On Thursday, 20 January, 2011 00:27 +0000 Shawn Steele > wrote: > >> ... >> Or is there something that's restricted to ASCII-only for a >> really good reason? > > We have a very general design rule that protocol elements of > various sorts stay ASCII-only. They aren't seen by end users, > the complexities of Unicode comparisons and collations aren't > worth the trouble, nor is worrying about ambiguities brought > about by font availability and rendering, etc. they are the IETF-style version of "binary" protocol elements, for the sake of human readability. Machines do not need to emulate humans complex behaviours :-) +1 > If one had a media type whose purpose was to transmit a > collection of such protocol elements, we would certainly want it > to be ASCII-only. > > john > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 Claudio.Allocchio@garr.it Fri Jan 21 03:20:46 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 88E053A6928 for ; Fri, 21 Jan 2011 03:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixOCQ45wGNsD for ; Fri, 21 Jan 2011 03:20:45 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 930073A6929 for ; Fri, 21 Jan 2011 03:20:44 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0LBNJWT063682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 12:23:19 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0LBNJWT063682 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=cVMEmtrn3oAFmYNvAlNiPqDaVI9lPQBe5IIDJOqaXjo+iNqckHGYIvAf3FPMwgWbY bww1WFT8tqnFB0w2MAYPKaIpOA238BwxL9r8MyoqaTSuV/iXl50o24JAONIxDM+0Rsb g7dDDOTQPvk8KK9nIC/CIHQNxARzgYrC/hphT6s= Date: Fri, 21 Jan 2011 12:23:19 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: ned+ima@mrochek.com In-Reply-To: <01NWUQSV2HH2007CHU@mauve.mrochek.com> Message-ID: References: <01NWUQSV2HH2007CHU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Charles Lindsey , IMA Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 21 Jan 2011 11:20:46 -0000 On Thu, 20 Jan 2011, ned+ima@mrochek.com wrote: >> On Mon, 17 Jan 2011 17:15:42 -0000, Joseph Yee >> wrote: > >>> Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? > >>> >>> Should the new parameter to VRFY/EXPN only be permitted after the SMTP >>> client issued EHLO command and saw a response that included UTF8SMTPbis? > >> Yes. YES! > >> But note that its use after the EHLO cannot be enforced by the server. It >> needs to take the form: > > Well, it could, since the server can in theory keep track of whether or not > EHLO has been issued, and refuse to allow the parameter if no EHLO has been > seen. > > But this opens up a can of worms. Suppose, for example, you want to further > restrict use of UTF8SMTPbis to clients that have done a STARTTLS, or have > authenticated with the correct identity, or whatever. (RFC 5321 makes it very > clear that sites are free to impose these sorts of policy-based > restrictions.) > So it might be the case that the iniitial EHLO response the client got from > the server didn't include UTF8SMTPbis but the one it got later did. > > So now the server has to track whether or not it sent back an EHLO response > with the "right stuff" in it. This is added complexity for no tangible > benefit, > and is why I oppose saying "Servers MUST NOT accept VRFY/EXPN with the > parameter without first having offered the extension in an EHLO response." > >> "Clients MUST NOT use this parameter unless ..." > > That's exactly the wording that I think needs to be used. > >> If clients fail to heed that, then "garbage in - garbage out" will apply. correct. Let's add "Clients MUST NOT use this parameter unless ..." > > Yep. > > Ned > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima ------------------------------------------------------------------------------ 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 Fri Jan 21 04:19:28 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 09D393A6944 for ; Fri, 21 Jan 2011 04:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 vwNV-IRHoQb1 for ; Fri, 21 Jan 2011 04:19:27 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 228F53A693B for ; Fri, 21 Jan 2011 04:19:27 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PgG0E-0008hM-Bi; Fri, 21 Jan 2011 07:22:06 -0500 Date: Fri, 21 Jan 2011 07:22:05 -0500 From: John C Klensin To: Claudio Allocchio Message-ID: <4A88CC91C4299790206CA699@PST.JCK.COM> In-Reply-To: References: <48395489468C8DAA755D2A26@[192.168.1.6]> 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: Ned Freed , Shawn Steele , ima@ietf.org Subject: Re: [EAI] Consensus Issue #???: Media types that support multiple charsets SHOULD employ utf-8 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, 21 Jan 2011 12:19:28 -0000 --On Friday, January 21, 2011 12:15 +0100 Claudio Allocchio wrote: >... >> We have a very general design rule that protocol elements of >> various sorts stay ASCII-only. They aren't seen by end users, >> the complexities of Unicode comparisons and collations aren't >> worth the trouble, nor is worrying about ambiguities brought >> about by font availability and rendering, etc. > > they are the IETF-style version of "binary" protocol elements, > for the sake of human readability. Machines do not need to > emulate humans complex behaviours :-) > > +1 Good analogy. Yes. john From klensin@jck.com Fri Jan 21 04:48:01 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 1A2E73A6968 for ; Fri, 21 Jan 2011 04:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 LHiq-UxbQup8 for ; Fri, 21 Jan 2011 04:48:00 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E6ECC3A6958 for ; Fri, 21 Jan 2011 04:47:59 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PgGRo-0009Sn-I7; Fri, 21 Jan 2011 07:50:36 -0500 Date: Fri, 21 Jan 2011 07:50:35 -0500 From: John C Klensin To: ned+ima@mrochek.com, Charles Lindsey Message-ID: <541FA852728BD37BCBA5C606@PST.JCK.COM> In-Reply-To: <01NWUL0VNF98007CHU@mauve.mrochek.com> References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> <01NWUL0VNF98007CHU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IMA Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 12:48:01 -0000 --On Thursday, January 20, 2011 09:12 -0800 ned+ima@mrochek.com wrote: >> However, it needs a NOTE to the efect that including this >> parameter in a message where it is not strictly necessary >> (that message is pure ASCII) MAY result in a more circuitous >> propagation path, or even in falure to deliver the message at >> all (e.g if the ultimate recipient does not advertise >> UTF8SMTPbis). > > Yes, it would be a very good idea to include a statement like > this. Sorry, folks, but I'm seeing a contradiction here, not just notes, and, if I were Jiankang, I'd have trouble knowing what to write. Option 1: Any EAI-capable client that is talking with a server that supports EAI extensions SHOULD send the parameter with MAIL, indicating that it is modern and that message envelope or headers might contain UTF-8 (restricted however we might restrict it, but not necessarily restricted to ASCII). That SHOULD might be accompanied by a note about exceptions. but the intent is "almost always". As I understand it, this is what Shawn is proposing. Option 2: In order to avoid requiring a subsequent analysis of headers before dealing with a server that cannot handle EAI extensions, an EAI-capable client talking with an EAI-capable server SHOULD send the parameter only if it has reason to believe that the message requires EAI support. "Reason to believe" allows exceptions and might be further noted, but the intent is that the parameter not be sent with ASCII-only (aka strictly 5321/5322-conforming) messages. As I understand it, this is what Charles and Ned are proposing. In practice, option 2 probably gradually becomes equivalent to option 1 as the EAI extensions are broadly deployed (just as support for 8BITMIME (without requiring downgrading) is now pretty general. But, in the reasonably short term, it does make a difference. So which is it? john From klensin@jck.com Fri Jan 21 05:00:29 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 D70A43A6967 for ; Fri, 21 Jan 2011 05:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcuRxJ8x2XIH for ; Fri, 21 Jan 2011 05:00:29 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id F02043A6952 for ; Fri, 21 Jan 2011 05:00:28 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PgGdr-0009gb-7O; Fri, 21 Jan 2011 08:03:03 -0500 Date: Fri, 21 Jan 2011 08:03:02 -0500 From: John C Klensin To: ned+ima@mrochek.com, Bill McQuillan Message-ID: <24E423C06E1E5FC839174074@PST.JCK.COM> In-Reply-To: <01NWRLLOJPBG007CHU@mauve.mrochek.com> References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IMA Discussion Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 13:00:30 -0000 --On Tuesday, January 18, 2011 10:44 -0800 ned+ima@mrochek.com wrote: >... > Indeed, it is easy to envision a different sort of extension > that lets the language of SMTP responses be negotiated. This > would almost certainly also require suport for utf-8 in SMTP > server responses. But it isn't what we're considering here. Indeed, there have been several proposals to do this over the years, none of which have assumed or required non-ASCII materials in either the headers or the envelope. With the exception of the possible requirement to return addresses that contain characters outside the ASCII in the responses to VRFY and EXPN, the two sets of extensions are almost completely orthogonal. john From Claudio.Allocchio@garr.it Fri Jan 21 05:06:47 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 973C23A6960 for ; Fri, 21 Jan 2011 05:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 t9ZbhCf266Jj for ; Fri, 21 Jan 2011 05:06:46 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 3AEF83A68F6 for ; Fri, 21 Jan 2011 05:06:45 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0LD9Ojr066491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 14:09:25 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0LD9Ojr066491 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=EHfS8qMwkbIDeiE/GzU4jEhaHLfFGnQmX2lCjFkjeerS/pd7fNE+tiknU64KluAY2 Si96tDW+8M5d40jPABtVf/F9UnUjvD64u/Rtqj2pT4s2lLoOxCMG25NTsJPMpYd76/R wdj38Er4VJOxN3bBY5EFpZChVgkgwDkprQijWhk= Date: Fri, 21 Jan 2011 14:09:24 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: John C Klensin In-Reply-To: <541FA852728BD37BCBA5C606@PST.JCK.COM> Message-ID: References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> <01NWUL0VNF98007CHU@mauve.mrochek.com> <541FA852728BD37BCBA5C606@PST.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Charles Lindsey , IMA Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 13:06:47 -0000 On Fri, 21 Jan 2011, John C Klensin wrote: > Option 1: Any EAI-capable client that is talking with a server > that supports EAI extensions SHOULD send the parameter with > MAIL, indicating that it is modern and that message envelope or > headers might contain UTF-8 (restricted however we might > restrict it, but not necessarily restricted to ASCII). That > SHOULD might be accompanied by a note about exceptions. but the > intent is "almost always". As I understand it, this is what > Shawn is proposing. > > Option 2: In order to avoid requiring a subsequent analysis of > headers before dealing with a server that cannot handle EAI > extensions, an EAI-capable client talking with an EAI-capable > server SHOULD send the parameter only if it has reason to > believe that the message requires EAI support. "Reason to > believe" allows exceptions and might be further noted, but the > intent is that the parameter not be sent with ASCII-only (aka > strictly 5321/5322-conforming) messages. As I understand it, > this is what Charles and Ned are proposing. I believe option 2 is safer and more pragmatic. > In practice, option 2 probably gradually becomes equivalent to > option 1 as the EAI extensions are broadly deployed (just as > support for 8BITMIME (without requiring downgrading) is now > pretty general. But, in the reasonably short term, it does make > a difference. > > So which is it? no. 2 > john > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 chl@clerew.man.ac.uk Fri Jan 21 08:50:35 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 932993A6A53 for ; Fri, 21 Jan 2011 08:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ScaRH6yzBJ8c for ; Fri, 21 Jan 2011 08:50:34 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 282F73A6A2B for ; Fri, 21 Jan 2011 08:50:33 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id ACC8022852 for ; Fri, 21 Jan 2011 12:24:17 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Fri, 21 Jan 2011 12:24:17 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0LCOGxT026552 for ; Fri, 21 Jan 2011 12:24:17 GMT Date: Fri, 21 Jan 2011 12:24:16 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <4D370D51.7060801@bbiw.net> <4D38CD94.8050800@dcrocker.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4D38CD94.8050800@dcrocker.net> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d397af1.887b-16ee-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) 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, 21 Jan 2011 16:50:35 -0000 On Fri, 21 Jan 2011 00:04:36 -0000, Dave CROCKER wrote: > Folks, > > > The answer to consensus call question 6 should be 'no'. > > > Ned Freed, Pete Resnick and I have been discussing the working group's > basic > model for handling UTF-8 within a legacy, 7-bit world. The current > approach is > certainly in line with the long-standing IETF pressure (demand) to have > changes > of an existing system be designed in a way that protects and interworks > with the > installed base, such as by not damaging a legacy system that receives an > enhanced form of data. And indeed, the working group's SMTP extension is > an > example of keeping the new object away from legacy-only systems. > > However, the model used in the case of RFC 5335 -- using new syntax > elements > instead of extending old ones -- has produced quite a bit of complexity. > In this > case, we believe the complexity is not serving the working group's goals > all > that well. -1 I find writing different syntax using, for example, in place of the 5332's leads to perfectly clear syntax with no possibility of confusion. We took just that approach in RFC 5536. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From Shawn.Steele@microsoft.com Fri Jan 21 10:34:21 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 06A323A6A80 for ; Fri, 21 Jan 2011 10:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.841 X-Spam-Level: X-Spam-Status: No, score=-9.841 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 dgfnbXMZ83f1 for ; Fri, 21 Jan 2011 10:34:20 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 23A103A6A6D for ; Fri, 21 Jan 2011 10:34:20 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 10:37:06 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Fri, 21 Jan 2011 10:37:06 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: AQHLuZo0mut0lG21DkOBSHdyj+W6NQ== Date: Fri, 21 Jan 2011 18:37:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 21 Jan 2011 18:34:21 -0000 The reason why I prefer #1 is because it is only required if the server has= a need to figure it out. Option #2 ALWAYS requires that the client figure= out the right thing to do, so it shifts the burden to the client. Since t= he client won't know when the "transition" is complete, #2 always has to ha= ppen "forever". At some point #1 can always stop the work. -Shawn ------------------------------ Message: 7 Date: Fri, 21 Jan 2011 07:50:35 -0500 From: John C Klensin Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: ned+ima@mrochek.com, Charles Lindsey Cc: IMA Message-ID: <541FA852728BD37BCBA5C606@PST.JCK.COM> Content-Type: text/plain; charset=3Dus-ascii --On Thursday, January 20, 2011 09:12 -0800 ned+ima@mrochek.com wrote: >> However, it needs a NOTE to the efect that including this >> parameter in a message where it is not strictly necessary >> (that message is pure ASCII) MAY result in a more circuitous >> propagation path, or even in falure to deliver the message at >> all (e.g if the ultimate recipient does not advertise >> UTF8SMTPbis). > > Yes, it would be a very good idea to include a statement like > this. Sorry, folks, but I'm seeing a contradiction here, not just notes, and, if I were Jiankang, I'd have trouble knowing what to write. Option 1: Any EAI-capable client that is talking with a server that supports EAI extensions SHOULD send the parameter with MAIL, indicating that it is modern and that message envelope or headers might contain UTF-8 (restricted however we might restrict it, but not necessarily restricted to ASCII). That SHOULD might be accompanied by a note about exceptions. but the intent is "almost always". As I understand it, this is what Shawn is proposing. Option 2: In order to avoid requiring a subsequent analysis of headers before dealing with a server that cannot handle EAI extensions, an EAI-capable client talking with an EAI-capable server SHOULD send the parameter only if it has reason to believe that the message requires EAI support. "Reason to believe" allows exceptions and might be further noted, but the intent is that the parameter not be sent with ASCII-only (aka strictly 5321/5322-conforming) messages. As I understand it, this is what Charles and Ned are proposing. In practice, option 2 probably gradually becomes equivalent to option 1 as the EAI extensions are broadly deployed (just as support for 8BITMIME (without requiring downgrading) is now pretty general. But, in the reasonably short term, it does make a difference. So which is it? john= From Shawn.Steele@microsoft.com Fri Jan 21 10:43:18 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 22A133A6A83 for ; Fri, 21 Jan 2011 10:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG8dQDVKNq36 for ; Fri, 21 Jan 2011 10:43:17 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D4ED63A6A6D for ; Fri, 21 Jan 2011 10:43:16 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 10:45:57 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Fri, 21 Jan 2011 10:45:58 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Why the transition will be pretty fast in some places. Thread-Index: Acu5mvCKtr6lwvWcQcCwHerUO/feOQ== Date: Fri, 21 Jan 2011 18:45:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A11C2B9C5TK5EX14MBXC141r_" MIME-Version: 1.0 Subject: [EAI] Why the transition will be pretty fast in some places. 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, 21 Jan 2011 18:43:18 -0000 --_000_E14011F8737B524BB564B05FF748464A11C2B9C5TK5EX14MBXC141r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQgbm93IGVtYWlsIGFkZHJlc3NlcyBpbiBub24tRW5nbGlzaCBzcGVha2luZyBjb3VudHJp ZXMgaXMgYW1hemluZ2x5IGxhbWUuICBGb3IgbWFueSB1c2VycyBpdCdzIG1lIHBpY2tpbmcgYW4g YXJhYmljIGFkZHJlc3M6IG1lYW5pbmdsZXNzLiAgT3IgbWF5YmUgbGlrZSBnZXR0aW5nIGEgcGhv bmUgIywgaXQncyBzb21ldGhpbmcgdG8gcmVtZW1iZXIgYnV0IGhhcyBubyBpbnRyaW5zaWMgbWVh bmluZy4NCg0KDQoNClNvOiBJTU8sIGluIG1hbnkgY291bnRyaWVzIHRoZXJlIHdpbGwgYmUgc3Ry b25nIGRlbWFuZCB0byBnZXQgYW4gRUFJIGFkZHJlc3MsIGV2ZW4gaWYganVzdCBmb3IgdGhlaXIg aG9tZSBhY2NvdW50LiAgT25jZSBhbnkgb2YgdGhlIHdlYm1haWwgaG9zdHMgcGljayB1cCBFQUks IGhvdyBhY2NlcHRhYmxlIHdpbGwgaXQgYmUgZm9yIGNvbXBhbmllcyB0byBoYXZlIGxlZ2FjeSBt YWlsPyAgVGhleSBhcmVuJ3QgZ29pbmcgdG8gd2FudCB0byBtaXNzIG1haWxzIGZyb20gY3VzdG9t ZXJzLiAgQW55IG5ldyBtYWlsIHN5c3RlbSBpbiB0aG9zZSBjb3VudHJpZXMgd2lsbCBoYXZlIEVB SSBhcyBhIHByb2N1cmVtZW50IHJlcXVpcmVtZW50LiAgU28gSSBleHBlY3Qgbm9uLVVTIGN1c3Rv bWVycyB0byBoYXZlIGZ1bGx5IGNvbXBsaWFudCBzeXN0ZW1zIHZlcnkgcXVpY2tseSAoY291cGxl IG9mIHllYXJzKS4NCg0KDQoNCk9mIGNvdXJzZSB0aGUgVVMgd2lsbCBzdGlsbCBiZSBpbiB0aGUg ZGFyayBhZ2VzIHNpbmNlIHRoZXkgd29uJ3QgaGF2ZSBhcyBiaWcgb2YgYW4gaW5jZW50aXZlLCBh bmQgSSB1bmRlcnN0YW5kIHRoYXQgX19fXyBwcm9iYWJseSBoYXMgc29tZSBtYWlsIGJhdGNoIGFj Y291bnQgZm9yIGhpcyBwcmludGVyIHRoYXQgaGUgY2FuIHN0aWxsIHNlbmQgSEVMTyAobm90IEVI TE8pIG1haWwgdG8gYW5kIHdvbid0IHVwZ3JhZGUgaW4gZm9yZXZlci4gIChUaGUgdHViZXMgaGF2 ZSBibG93biBhIGZldyB0aW1lcywgYW5kIHJlcGxhY2VtZW50cyBhcmUgZ2V0dGluZyBtb3JlIGRp ZmZpY3VsdCB0byBmaW5kLCBidXQgaGUgaGFzIGEgY2FjaGUgb2Ygc3BhcmVzLikgIDstKQ0KDQoN Cg0KV2hpY2ggaXMgd2F5IGRpZmZlcmVudCB0aGFuIElETiBhZG9wdGlvbiByYXRlcywgYnV0IElE TiBpc24ndCB0aGUgc2FtZSB0YXJnZXQgbWFya2V0Lg0KDQoNCi1TaGF3bg0KDQrvo6Lvo5Dvo6fv o5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUNCg0K --_000_E14011F8737B524BB564B05FF748464A11C2B9C5TK5EX14MBXC141r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgaWQ9Im93YVBhcmFT dHlsZSI+UCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBmUFN0eWxlPSIxIiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRp cmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhvbWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXpl OiAxMHB0OyI+DQo8ZGl2Pg0KPHA+UmlnaHQgbm93IGVtYWlsIGFkZHJlc3NlcyZuYnNwO2luIG5v bi1FbmdsaXNoIHNwZWFraW5nIGNvdW50cmllcyBpcyBhbWF6aW5nbHkgbGFtZS4mbmJzcDsgRm9y IG1hbnkgdXNlcnMgaXQncyBtZSBwaWNraW5nIGFuIGFyYWJpYyBhZGRyZXNzOiBtZWFuaW5nbGVz cy4mbmJzcDsgT3IgbWF5YmUgbGlrZSBnZXR0aW5nIGEgcGhvbmUgIywgaXQncyBzb21ldGhpbmcg dG8gcmVtZW1iZXIgYnV0IGhhcyBubyBpbnRyaW5zaWMgbWVhbmluZy48L3A+DQo8cD4mbmJzcDs8 L3A+DQo8cD5TbzogSU1PLCBpbiBtYW55IGNvdW50cmllcyB0aGVyZSB3aWxsIGJlIHN0cm9uZyBk ZW1hbmQgdG8gZ2V0IGFuIEVBSSBhZGRyZXNzLCBldmVuIGlmIGp1c3QgZm9yIHRoZWlyIGhvbWUg YWNjb3VudC4mbmJzcDsgT25jZSBhbnkgb2YgdGhlIHdlYm1haWwgaG9zdHMgcGljayB1cCBFQUks IGhvdyBhY2NlcHRhYmxlIHdpbGwgaXQgYmUgZm9yIGNvbXBhbmllcyB0byBoYXZlIGxlZ2FjeSBt YWlsPyZuYnNwOyBUaGV5IGFyZW4ndCBnb2luZyB0byB3YW50IHRvIG1pc3MNCiBtYWlscyBmcm9t IGN1c3RvbWVycy4mbmJzcDsgQW55IG5ldyBtYWlsIHN5c3RlbSBpbiB0aG9zZSBjb3VudHJpZXMg d2lsbCBoYXZlIEVBSSBhcyBhIHByb2N1cmVtZW50IHJlcXVpcmVtZW50LiZuYnNwOyBTbyBJIGV4 cGVjdCBub24tVVMgY3VzdG9tZXJzIHRvIGhhdmUgZnVsbHkgY29tcGxpYW50IHN5c3RlbXMgdmVy eSBxdWlja2x5IChjb3VwbGUgb2YgeWVhcnMpLjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPk9mIGNv dXJzZSB0aGUgVVMgd2lsbCBzdGlsbCBiZSBpbiB0aGUgZGFyayBhZ2VzIHNpbmNlIHRoZXkgd29u J3QgaGF2ZSBhcyBiaWcgb2YgYW4gaW5jZW50aXZlLCBhbmQgSSB1bmRlcnN0YW5kIHRoYXQmbmJz cDtfX19fIHByb2JhYmx5IGhhcyBzb21lIG1haWwgYmF0Y2ggYWNjb3VudCBmb3IgaGlzIHByaW50 ZXIgdGhhdCBoZSBjYW4gc3RpbGwgc2VuZCBIRUxPIChub3QgRUhMTykgbWFpbCB0byBhbmQgd29u J3QgdXBncmFkZSBpbiBmb3JldmVyLiZuYnNwOyAoVGhlDQogdHViZXMgaGF2ZSBibG93biBhIGZl dyB0aW1lcywgYW5kIHJlcGxhY2VtZW50cyBhcmUgZ2V0dGluZyBtb3JlIGRpZmZpY3VsdCB0byBm aW5kLCBidXQgaGUgaGFzIGEgY2FjaGUgb2Ygc3BhcmVzLikmbmJzcDsgOy0pPC9wPg0KPHA+Jm5i c3A7PC9wPg0KPHA+V2hpY2ggaXMgd2F5IGRpZmZlcmVudCB0aGFuIElETiBhZG9wdGlvbiByYXRl cywgYnV0IElETiBpc24ndCB0aGUgc2FtZSB0YXJnZXQgbWFya2V0LjwvcD4NCjxwPiZuYnNwOzwv cD4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBUYWhvbWE7IEZPTlQtU0laRTogMTNweCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tU2hhd248L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENv ZGUyMDAwIj7vo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZTwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E14011F8737B524BB564B05FF748464A11C2B9C5TK5EX14MBXC141r_-- From klensin@jck.com Fri Jan 21 11:18:53 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 9CD043A6A86 for ; Fri, 21 Jan 2011 11:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzG4Lz+rbfvP for ; Fri, 21 Jan 2011 11:18:52 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4AC403A6A7E for ; Fri, 21 Jan 2011 11:18:52 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PgMYE-000LDa-3K; Fri, 21 Jan 2011 14:21:38 -0500 Date: Fri, 21 Jan 2011 14:21:37 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Why the transition will be pretty fast in some places. 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, 21 Jan 2011 19:18:53 -0000 --On Friday, January 21, 2011 18:45 +0000 Shawn Steele wrote: > Right now email addresses in non-English speaking countries is > amazingly lame. For many users it's me picking an arabic > address: meaningless. Or maybe like getting a phone #, it's > something to remember but has no intrinsic meaning. > > So: IMO, in many countries there will be strong demand to get > an EAI address, even if just for their home account. Once any > of the webmail hosts pick up EAI, how acceptable will it be > for companies to have legacy mail? They aren't going to want > to miss mails from customers. Any new mail system in those > countries will have EAI as a procurement requirement. So I > expect non-US customers to have fully compliant systems very > quickly (couple of years). > > Of course the US will still be in the dark ages since they > won't have as big of an incentive, and I understand that ____ > probably has some mail batch account for his printer that he > can still send HELO (not EHLO) mail to and won't upgrade in > forever. (The tubes have blown a few times, and replacements > are getting more difficult to find, but he has a cache of > spares.) ;-) > > Which is way different than IDN adoption rates, but IDN isn't > the same target market. Shawn, At some level, this is pretty obvious. It even influenced some of our early design decisions to keep things simple so that implementation wasn't a big barrier. I would disagree only slightly with you about scope -- for Latin-based writing systems that require more than the ASCII subset, how important the additional characters are is a matter of the particular language and local culture and conventions: I'm very reluctant to assume that the US will be the only slow-adopter (and there will be folks in the US who absolutely insist on their right to use hearts and daggers in their user names). But that doesn't change things very much: -- We still need to design for a transition process, even if we have reason to believe it will be globally short (and especially short within particular communities). -- Folks who need to communicate between very different linguistic and writing system communities are likely to need to use ASCII for a long, long, time. Rows of little question marks are not useful as addresses (and that isn't all of the problem). -- Our track record in predicting speed of deployment is terrible. There are some reasons for that, some of which interact with the MUA issues that I and others have discussed. ASCII addresses for folks who don't use Latin-based characters are terrible, but many generations of people have learned to use addresses with no obvious linguistic meaning (e.g., I was happy to stop having to receive mail at something like M3418, but I lived with it for quite a while) and lots of people are now "used to" the meaningless strings. Faced with needing to change established addresses and/or to replace hardware to get a new MUA working... well, experience tells me to not predict how people will behave and then make engineering decisions on that basis. john From Shawn.Steele@microsoft.com Fri Jan 21 15:32:12 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 86CBC3A6846 for ; Fri, 21 Jan 2011 15:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuoiYJPW5ilX for ; Fri, 21 Jan 2011 15:32:11 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0722E3A67E4 for ; Fri, 21 Jan 2011 15:32:10 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 15:34:58 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.211]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Fri, 21 Jan 2011 15:34:57 -0800 From: Shawn Steele To: Dave CROCKER Thread-Topic: Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) Thread-Index: Acu5wG8jTG15kJxrRe6Tp9iAXXVdLw== Date: Fri, 21 Jan 2011 23:34:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) 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, 21 Jan 2011 23:32:13 -0000 IMO this is kind of the same conceptually as what the WG is trying to achie= ve. I need whatever gets us stable fastest :) Re: {{ how to add IDN to this? }} domain =3D dot-atom / domain-literal / obs-domain That should be: domain =3D/ UTF8-non-ascii encoded RFC5890 U-label There should be a note that a UTF-8 domain label MUST only contain valid RF= C5890 u-labels. -Shawn -------- Original Message -------- Subject: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: curren= t metalanguage model acceptable?) Date: Thu, 20 Jan 2011 16:04:36 -0800 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: ietf-eai Folks, The answer to consensus call question 6 should be 'no'. Ned Freed, Pete Resnick and I have been discussing the working group's basi= c model for handling UTF-8 within a legacy, 7-bit world. The current approach= is certainly in line with the long-standing IETF pressure (demand) to have cha= nges of an existing system be designed in a way that protects and interworks wit= h the installed base, such as by not damaging a legacy system that receives an enhanced form of data. And indeed, the working group's SMTP extension is an example of keeping the new object away from legacy-only systems. However, the model used in the case of RFC 5335 -- using new syntax element= s instead of extending old ones -- has produced quite a bit of complexity. In= this case, we believe the complexity is not serving the working group's goals al= l that well. That leads us to make a somewhat surprising suggestion to simplify things considerably. The premise behind the suggestion is that the world really does have extensive infrastructure for UTF-8 already and that we can rely on it. So, 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. This would create what essentially would be an independent, UTF-8 email world. Interworking with the legacy email world still needs to be specified, but it should be done separately. With the caveat that IDN handling in the spec still needs to be done, this produces a candidate to replace for Section 4.3, 4.4 and 4.5 from the exist= ing draft: [[ -------------------------------------- This section specifies UTF-8 enhancements for the header of an Internet Mail message, as defined in [RFC5322]. ABNF used in this section is taken from that specification and the ABNF specification. This specification retains the [RFC5322] rules for defining header field names. The bodies of header fields are allowed to contain UTF-8 characters, but the header field names themselves must contain only ASCII characters. The following rules extend the corresponding rules in [RFC5322] and [RFC5234] in order to allow additional Unicode characters. VCHAR =3D/ UTF8-non-ascii ctext =3D/ UTF8-non-ascii atext =3D/ UTF8-non-ascii qtext =3D/ UTF8-non-ascii {{ how to add IDN to this? }} domain =3D dot-atom / domain-literal / obs-domain This means that all the [RFC5322] constructs that build upon these will permit UTF-8 characters, including comments and quoted strings. [RFC5322] has the rule which specifies permissible names for user-defined header fields. The current specification defines no changes to that rule. This ABNF enables Message-ID strings to be full UTF-8. However the specification directs that Message-ID strings SHOULD be restricted to ASCII. -------------------------------------- ]] The SMTP extension is essential to this, of course. In addition it's worth repeating that specification of UTF8-to-ASCII gatewaying is still needed, b= ut we suggest it be moved to a separate specification. Since these are very basic ABNF rules, changes to them have an extensive effect that is not immediately obvious. So to aid the reader, it's worth adding an appendix that lists the other ABNF of RFC5322 that would be affected (ignoring the obs- rules)... [[ -------------------------------------- A. Changes to support UTF-8 This section provides a basic audit of the places in a message that now can permit UTF-8 rather than being restricted to ASCII, based on the changes to underlying ABNF. The audit ignores rules for "obsolete" constructs in RFC 5322. VCHAR: quoted-pair, unstructured > ccontent, qcontent > comment, quoted-string > word, local-part > phrase > display-name, keywords > name-addr > mailbox, group > address > address-list, mailbox-list > received-token, received > from, sender > reply-to, to, cc, bcc, resent-* > subject, comments, optional-field ctext: ccontent > comment > comments atext: atom, dot-atom-text > msg-id > local-part, domain > addr-spec > mailbox qtext: qcontent quoted-string -------------------------------------- ]] --=20 Dave Crocker Brandenburg InternetWorking bbiw.net From klensin@jck.com Sat Jan 22 03:13:50 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 56D7E3A6901 for ; Sat, 22 Jan 2011 03:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 eeQQHssdG4G2 for ; Sat, 22 Jan 2011 03:13:49 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 93E4C3A68FC for ; Sat, 22 Jan 2011 03:13:49 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PgbSK-000LkH-8q; Sat, 22 Jan 2011 06:16:32 -0500 Date: Sat, 22 Jan 2011 06:16:31 -0500 From: John C Klensin To: Joseph Yee , EAI WG Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #3: remove repetition of normative text? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 11:13:50 -0000 --On Monday, January 17, 2011 12:15 -0500 Joseph Yee wrote: > Issue #3: remove repetition of normative text? > > http://trac.tools.ietf.org/wg/eai/trac/ticket/3 > > Description > --------------- > > Should the WG remove repetition of normative text from other > documents to the extent possible. Incorporate by reference > and, where necessary, note explicitly that tutorial / > context-providing references are not normative. >... Yes, sort of. This solution is much more acceptable to me if a note along the lines that Charles suggests is added, but such notes need to distinguish carefully between "version in RFC as specified" and "version in RFC or its successor". john From klensin@jck.com Sat Jan 22 03:20:50 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 CA6343A6901 for ; Sat, 22 Jan 2011 03:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRIJirrQg-pT for ; Sat, 22 Jan 2011 03:20:50 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 673DB3A68F3 for ; Sat, 22 Jan 2011 03:20:48 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PgbZA-000Lss-4C; Sat, 22 Jan 2011 06:23:36 -0500 Date: Sat, 22 Jan 2011 06:23:35 -0500 From: John C Klensin To: dcrocker@bbiw.net, ietf-eai Message-ID: <0937A4434AE074AA3AFF740E@PST.JCK.COM> In-Reply-To: <4D38CD94.8050800@dcrocker.net> References: <4D370D51.7060801@bbiw.net> <4D38CD94.8050800@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 Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 11:20:50 -0000 --On Thursday, January 20, 2011 16:04 -0800 Dave CROCKER wrote: > > Folks, > > > The answer to consensus call question 6 should be 'no'. > > > Ned Freed, Pete Resnick and I have been discussing the working > group's basic > model for handling UTF-8 within a legacy, 7-bit world. The > current approach is > certainly in line with the long-standing IETF pressure > (demand) to have changes > of an existing system be designed in a way that protects and > interworks with the > installed base, such as by not damaging a legacy system that > receives an > enhanced form of data. And indeed, the working group's SMTP > extension is an > example of keeping the new object away from legacy-only > systems. > > However, the model used in the case of RFC 5335 -- using new > syntax elements > instead of extending old ones -- has produced quite a bit of > complexity. In this > case, we believe the complexity is not serving the working > group's goals all > that well. > > That leads us to make a somewhat surprising suggestion to > simplify > things considerably. The premise behind the suggestion is that > the > world really does have extensive infrastructure for UTF-8 > already and > that we can rely on it. > > So, 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. >... I can live with this approach. If it is adopted, I'll help sort out the domain name part. john From klensin@jck.com Sat Jan 22 03:24:35 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 5185A3A6901 for ; Sat, 22 Jan 2011 03:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyENo-RxUK7y for ; Sat, 22 Jan 2011 03:24:33 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2D3253A68F3 for ; Sat, 22 Jan 2011 03:24:33 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pgbcn-000Ly8-6a; Sat, 22 Jan 2011 06:27:21 -0500 Date: Sat, 22 Jan 2011 06:27:20 -0500 From: John C Klensin To: Joseph Yee , EAI WG Message-ID: <287E60837CE147709333ECA4@PST.JCK.COM> In-Reply-To: <06E3D341-001D-411C-9A07-21E2096C2F6C@ca.afilias.info> References: <06E3D341-001D-411C-9A07-21E2096C2F6C@ca.afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Issue #7: change definition of uAtom? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 11:24:35 -0000 --On Monday, January 17, 2011 12:15 -0500 Joseph Yee wrote: > Issue #7: change definition of uAtom? > > http://trac.tools.ietf.org/wg/eai/trac/ticket/7 > > Description > --------------- > > Do we need to tweak the definition of uAtom, and if yes, how? If we go with the approach Dave Crocker suggested, this question is OBE in the current form. The real question, for either ABNF approach, is, IMO, whether CO and C1 controls (and perhaps various other Unicode format control and metadata characters) should be permitted in addresses or email headers more generally. I believe the answer should be "no", but I believe it is much more important that we make a decision and be clear about it. john From johnl@iecc.com Sat Jan 22 11:58: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 B70A63A69F7 for ; Sat, 22 Jan 2011 11:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.058 X-Spam-Level: X-Spam-Status: No, score=-111.058 tagged_above=-999 required=5 tests=[AWL=0.141, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pHUbem37FK8 for ; Sat, 22 Jan 2011 11:58:03 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 55F613A69F3 for ; Sat, 22 Jan 2011 11:58:03 -0800 (PST) Received: (qmail 26453 invoked from network); 22 Jan 2011 20:00:51 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 22 Jan 2011 20:00:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=4a6c.4d3b3773.k1101; i=johnl@user.iecc.com; bh=f3viBqEgNaFaR3Acm+nphKuZ4AoZqYW8tmkhgApbBGU=; b=GrzSqpc0f9yPMyH0iDcXX9tm59TXnW1IrRof0NG7CRyJzeBVHYUKztMeIESgzEAeTVhr3R3WD8XNcNt22jIlFMz7LLLlLOd8KRZNXsYI62HVqvX7+k3JwK2toykJDhTjDzvaKr3PHA/0HWIPGlW4tlqzGrKE38xUnCnwry2T1vQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=4a6c.4d3b3773.k1101; olt=johnl@user.iecc.com; bh=f3viBqEgNaFaR3Acm+nphKuZ4AoZqYW8tmkhgApbBGU=; b=oNO1OSCz5mPkksLNz7DpAxJdi1BJ7mEcYHfrbtjjHIvVrz6ir3PoErRYB0Btztj5nkjp/LPwkRY4Mp3awE6Zl2XDcHJDrlYCMWk1WUDrOs2jAYGdj3ngZdGOnFG4YHFbJY7Dh+MIXIS86NRlUy7il6ZZpEqyELhUn0d66oIT35U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Jan 2011 20:00:51 -0000 Message-ID: <20110122200051.19051.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <0937A4434AE074AA3AFF740E@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 19:58:05 -0000 >> So, 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. >>... > >I can live with this approach. Same here. It seems to me that no matter what the ABNF says, once we allow UTF-8 in headers, people will put it everywhere so the ABNF might as well match the likely reality. R's, John From ned+ima@mrochek.com Sat Jan 22 14:15:46 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 802683A6B4F for ; Sat, 22 Jan 2011 14:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAKbzYMtectB for ; Sat, 22 Jan 2011 14:15:45 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 8BF083A6B4D for ; Sat, 22 Jan 2011 14:15:45 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWXDWD6H9C00FJNY@mauve.mrochek.com> for ima@ietf.org; Sat, 22 Jan 2011 14:18:30 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWP1MZKQSW007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 22 Jan 2011 14:18:22 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWXDW9I2KI007FL5@mauve.mrochek.com> Date: Sat, 22 Jan 2011 14:11:34 -0800 (PST) In-reply-to: "Your message dated Sat, 22 Jan 2011 20:00:51 +0000" <20110122200051.19051.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <0937A4434AE074AA3AFF740E@PST.JCK.COM> <20110122200051.19051.qmail@joyce.lan> To: John Levine DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295731646; bh=xiPAVsACeZx3kPOC6Jwxl8KiPDbyldr9Eqxik33hJxQ=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=T61iF/ivbeHCmOKbPCkf75iN9lLrDnCSPIljiEcsgiQze1emE9Okz+D0l1Kd4IpJe 3gVldkOV3+cTT6SulTREYRUi4fvFGLpnoz3zUclpoEvfTWfQ6F+riwhBz1XupuPUD+ uQ7ktSYIfZEzURw6HdZiI6rfd0dfQ0X2AMv2Wjas= Cc: ima@ietf.org Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 22:15:46 -0000 > >> So, 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. > >>... > > > >I can live with this approach. > Same here. It seems to me that no matter what the ABNF says, once we > allow UTF-8 in headers, people will put it everywhere so the ABNF might > as well match the likely reality. Bingo. Just as one example, message ids are often synthesized from available host and domain information. If that information contains UTF-8, there's going to be leakage into message ids from careless clients. One thing both the old and new ABNF refrains from doing is adding utf-8 to header labels. I think this is a defensible position and thus a reasonable place to draw the line, although there's bound to be a little leakage even there. Ned From Shawn.Steele@microsoft.com Sat Jan 22 14:49:23 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 7246C3A6B80 for ; Sat, 22 Jan 2011 14:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] 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 7udxcd0ykCEU for ; Sat, 22 Jan 2011 14:49:22 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 981443A6B7C for ; Sat, 22 Jan 2011 14:49:22 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 22 Jan 2011 14:52:12 -0800 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.191]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Sat, 22 Jan 2011 14:52:12 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #3: remove repetition of normative text? Thread-Index: Acu6hp548EjuuF2WQpyqR+bfrbfj5w== Date: Sat, 22 Jan 2011 22:52:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #3: remove repetition of normative text? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 22:49:23 -0000 > such notes need to distinguish carefully between "version in RFC as speci= fied" > and "version in RFC or its successor". I'm not sure which you're saying should be used :) I think that "or its su= ccessor" is sort of a given regardless of whether it's stated or not. (RFC= s update themselves and don't necessarily think about all of the other RFCs= that depend on them.) Either way, updates to the original RFC allow the risk that "something" wil= l change, breaking the dependent RFC. -Shawn From Shawn.Steele@microsoft.com Sat Jan 22 14:51:56 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 03FFE3A6B85 for ; Sat, 22 Jan 2011 14:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLykKiTJzCQl for ; Sat, 22 Jan 2011 14:51:54 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CA80A3A6B83 for ; Sat, 22 Jan 2011 14:51:54 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 22 Jan 2011 14:54:44 -0800 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.191]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0255.003; Sat, 22 Jan 2011 14:54:44 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) Thread-Index: Acu6hxUAc+fALDdBQse1ZNpvk87OWA== Date: Sat, 22 Jan 2011 22:54:44 +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] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 22:51:56 -0000 > > So, 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. > >... > I can live with this approach. If it is adopted, I'll help sort out the = domain name part. As mentioned, IMO, the domain part should "just" say UTF-8 as well, though = it's fair to point out the dependencies on existing RFCs that define DNS. = DNS is a bit trickier than the other headers because we explicitly want to = disallow the punycode I think, and require UTF-8 U-Labels instead. -Shawn From alexey.melnikov@isode.com Sat Jan 22 14:55: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 AD2363A6B6F for ; Sat, 22 Jan 2011 14:55:03 -0800 (PST) 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=[AWL=0.000, 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 YQfp4QxNNcNt for ; Sat, 22 Jan 2011 14:53:36 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B7D793A6B8E for ; Sat, 22 Jan 2011 14:53:35 -0800 (PST) Received: from [92.40.163.242] (92.40.163.242.sub.mbb.three.co.uk [92.40.163.242]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 22 Jan 2011 22:56:23 +0000 Message-ID: <4D3B6059.8000505@isode.com> Date: Sat, 22 Jan 2011 22:55:21 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: dcrocker@bbiw.net References: <4D370D51.7060801@bbiw.net> <4D38CD94.8050800@dcrocker.net> In-Reply-To: <4D38CD94.8050800@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-eai Subject: Re: [EAI] Proposal for Alternate ABNF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 22:55:03 -0000 Dave CROCKER wrote: > Folks, Hi Dave, Speaking as an individual participant (and not with my AD hat on): I think this is a big improvement and I generally support this direction. I do have one specific issue though, which, if agreed by others, can be thought of as a minor detail: [...] > A. Changes to support UTF-8 > > This section provides a basic audit of the places in a message that > now can permit UTF-8 rather than being restricted to ASCII, based on > the changes to underlying ABNF. The audit ignores rules for "obsolete" > constructs in RFC 5322. > > VCHAR: > quoted-pair, quoted-pair = ("\" (VCHAR / WSP)) / obs-qp I have to say that I am not happy about any changes to quoted-pair. I haven't been around IETF for that long (as compared to other people participating in this discussion), so if I am saying something stupid here, I plead forgiveness. My view is that any slash escaping mechanism needs to be left as is. It only allows escaping of one following octet and changing this to escape multioctet sequences is going to require changes to parsers of this field for no good reason. Besides non-ASCII UTF-8 sequences can already be included without escaping. > unstructured No objections to extending this one. From johnl@iecc.com Sat Jan 22 15:43:06 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 015EE3A6BB9 for ; Sat, 22 Jan 2011 15:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.06 X-Spam-Level: X-Spam-Status: No, score=-111.06 tagged_above=-999 required=5 tests=[AWL=0.139, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sYNknp3AIHo for ; Sat, 22 Jan 2011 15:43:04 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id A71063A67EB for ; Sat, 22 Jan 2011 15:43:04 -0800 (PST) Received: (qmail 71077 invoked from network); 22 Jan 2011 23:45:54 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 22 Jan 2011 23:45:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=12651.4d3b6c31.k1101; i=johnl@user.iecc.com; bh=hyLFotZ7vELe46C0xDn1OQq9ORcOBstMFBObpIf92P0=; b=TP+7uBevbGkDTJwVFUEPgJy1jfbH4Bhbf5MhT+DY+LMFXcQ+9cyjTMAV83AtK+Wx1Wi01lD9Ewv9UBFaweEJm58LN1mTeKv7R4KDhcHwTUNL9dVUg0SC1XTn/0FpK+qPDGl4I1p/zSPJaKmHWLWJ2qYJatI4VyuEQYj7mTNnvqs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=12651.4d3b6c31.k1101; olt=johnl@user.iecc.com; bh=hyLFotZ7vELe46C0xDn1OQq9ORcOBstMFBObpIf92P0=; b=YUlHbaMBAGj5bh4vEsB+Dnv4Khz9wrxWwex6DhO3HMld4l8KGuqhYS/4pFcJmCzggYP6oq4b0AFrMHxyfjvg1tabhBQVrHhS2Dh9XG/vgCOu8Ij45TLRviHx+5U8l2nXh9YmjG7mfBBEoTmeYUhjjXoUKB047C+JEj8AjIUP+4c= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Jan 2011 23:45:53 -0000 Message-ID: <20110122234553.75344.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D3B6059.8000505@isode.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] an helminthine cafeteria, was Proposal for Alternate ABNF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 23:43:06 -0000 > quoted-pair = ("\" (VCHAR / WSP)) / obs-qp > >I have to say that I am not happy about any changes to quoted-pair. I >haven't been around IETF for that long (as compared to other people >participating in this discussion), so if I am saying something stupid >here, I plead forgiveness. My view is that any slash escaping mechanism >needs to be left as is. It only allows escaping of one following octet >and changing this to escape multioctet sequences is going to require >changes to parsers of this field for no good reason. No matter what we do here, we'll open a can of worms, so a reasonable goal is to pick the smallest possible can. The argument about parsers is unpersuasive. A reasonable way to handle UTF-8 text is to make a prepass over it to turn the entire string into 16 or 32 bit Unicode characters, then parse those, particularly on computers like the IBM z/Series that have instructions to do the translatation at high speed. In that environment, the obvious thing to quote is a character, not a byte, and I would argue that the hackery involved to handle a quoted single byte in that environment is a lot worse than adjusting the code in a byte at a time system to handle a UTF-8 character. Adapting a header parser for EAI messages will introduce lots of changes to the byte at a time code to handle UTF-8, and this is just another one. More importantly, if you can quote an arbitrary byte, you now have the ability to introduce arbitrary things into the message that are not valid UTF-8. Those worms have large painful fangs, and I would just as soon not let them into my code or my messages. You're right that quoting a non-ASCII character doesn't do anything useful, but let's make sure it doesn't do anything awful, either. So a quoted pair is backslash and a character, not a backslash and a potentially not-a-character byte, and the ABNF change is correct. R's, John From ned+ima@mrochek.com Sat Jan 22 19:03:37 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 70AB73A6BCA for ; Sat, 22 Jan 2011 19:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-XUf4TubxP2 for ; Sat, 22 Jan 2011 19:03:36 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 528393A6878 for ; Sat, 22 Jan 2011 19:03:36 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWXNYCI3K000ITZA@mauve.mrochek.com> for ima@ietf.org; Sat, 22 Jan 2011 19:06:24 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWP1MZKQSW007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 22 Jan 2011 19:06:18 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NWXNY9FYDW007FL5@mauve.mrochek.com> Date: Sat, 22 Jan 2011 18:56:24 -0800 (PST) In-reply-to: "Your message dated Sat, 22 Jan 2011 22:55:21 +0000" <4D3B6059.8000505@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4D370D51.7060801@bbiw.net> <4D38CD94.8050800@dcrocker.net> <4D3B6059.8000505@isode.com> To: Alexey Melnikov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1295748920; bh=3dfkYC2/jrm5exLXfOihZFG4fIkHRbPiQPn76L0OWx0=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=XbqueV6T0U78poz9xp+n345CKPFPE1Vswbz1c2IlXu8qjKz+8eYfYuOHbINTD59nH 0OToLWbcPE6Q/rgISXRiiW5kpXFNMh7Lpc/GzWb1IP0D/l3I8X9C4ms2nT7c1jlEUt ecvkt54OuFHW+va9/tLGRSQHRXklV2pFE5Itb9f0= Cc: dcrocker@bbiw.net, ietf-eai Subject: Re: [EAI] Proposal for Alternate ABNF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 03:03:37 -0000 > Dave CROCKER wrote: > > Folks, > Hi Dave, > Speaking as an individual participant (and not with my AD hat on): I > think this is a big improvement and I generally support this direction. > I do have one specific issue though, which, if agreed by others, can be > thought of as a minor detail: > [...] > > A. Changes to support UTF-8 > > > > This section provides a basic audit of the places in a message that > > now can permit UTF-8 rather than being restricted to ASCII, based on > > the changes to underlying ABNF. The audit ignores rules for "obsolete" > > constructs in RFC 5322. > > > > VCHAR: > > quoted-pair, > quoted-pair = ("\" (VCHAR / WSP)) / obs-qp > I have to say that I am not happy about any changes to quoted-pair. I > haven't been around IETF for that long (as compared to other people > participating in this discussion), so if I am saying something stupid > here, I plead forgiveness. My view is that any slash escaping mechanism > needs to be left as is. It only allows escaping of one following octet > and changing this to escape multioctet sequences is going to require > changes to parsers of this field for no good reason. > Besides non-ASCII UTF-8 sequences can already be included without escaping. I have to say I share your concern here. > > unstructured > No objections to extending this one. Well, the problem is essentially a structural one in RFC 5321 - instead of defining a single character repetoire for unstructured (which would logically be called utext), the specification simply references VCHAR, which is a core ABNF production. THis is a case where an ABNF shortcut ended up having an undesireable coupling effect. Had unstructured been defined this way: unstructured = (*([FWS] utext) *WSP) / obs-unstruct utext = VCHAR we would not have this problem. So, while it isn't as clean, instead of extending VCHAR we could redefine unstructured this way. The only effect doing things this way changes is it gets rid of the effect on quoted-pair and obs-unstruct. This approach has two other advantages. One, we're not messing with a core ABNF production any more. Two, we're not modifying the obsolete syntax this way, which is the same as how ctext works so it's a bit more consistent. Ned From klensin@jck.com Sun Jan 23 02:56:30 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 473143A684C for ; Sun, 23 Jan 2011 02:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr5vmIm8K2wb for ; Sun, 23 Jan 2011 02:56:29 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B65C03A6849 for ; Sun, 23 Jan 2011 02:56:27 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pgxeu-0000gn-Rr; Sun, 23 Jan 2011 05:59:02 -0500 Date: Sun, 23 Jan 2011 05:58:50 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <8244D38A28FB919303079D4E@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 10:56:30 -0000 --On Saturday, January 22, 2011 22:54 +0000 Shawn Steele wrote: >> I can live with this approach. If it is adopted, I'll help >> sort out the domain name part. > > As mentioned, IMO, the domain part should "just" say UTF-8 as > well, though it's fair to point out the dependencies on > existing RFCs that define DNS. DNS is a bit trickier than the > other headers because we explicitly want to disallow the > punycode I think, and require UTF-8 U-Labels instead. Shawn, I know that you want to "disallow" punycode. In a perfect world, I would too, and that is part of what draft-iab-idn-encoding is about. But, realistically, while we can try to discourage its use, banning it is just impractical given that A-labels conform to the RFC 1035 "preferred syntax", the syntax requirements of RFCs 5321 and 5322, and even the rather careful rules in RFC 5892 about what does and does not need to be checked on lookup. john From dhc2@dcrocker.net Sun Jan 23 08:00:28 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 3CA9D3A690B for ; Sun, 23 Jan 2011 08:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Q82pShj7hU for ; Sun, 23 Jan 2011 08:00:27 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 25EA63A68FF for ; Sun, 23 Jan 2011 08:00:27 -0800 (PST) Received: from [192.168.1.225] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0NG3D6D016745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 23 Jan 2011 08:03:18 -0800 Message-ID: <4D3C5138.2040701@dcrocker.net> Date: Sun, 23 Jan 2011 08:03:04 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf-eai References: <4D370D51.7060801@bbiw.net> <4D38CD94.8050800@dcrocker.net> <4D3B6059.8000505@isode.com> <01NWXNY9FYDW007FL5@mauve.mrochek.com> In-Reply-To: <01NWXNY9FYDW007FL5@mauve.mrochek.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]); Sun, 23 Jan 2011 08:03:19 -0800 (PST) Subject: Re: [EAI] Proposal for Alternate ABNF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 23 Jan 2011 16:00:28 -0000 On 1/22/2011 6:56 PM, ned+ima@mrochek.com wrote: >> Dave CROCKER wrote: >> quoted-pair = ("\" (VCHAR / WSP)) / obs-qp > >> I have to say that I am not happy about any changes to quoted-pair. ... > I have to say I share your concern here. ... > Had unstructured been defined this way: > > unstructured = (*([FWS] utext) *WSP) / obs-unstruct > > utext = VCHAR > > we would not have this problem. So, while it isn't as clean, instead of > extending VCHAR we could redefine unstructured this way. The only effect > doing things this way changes is it gets rid of the effect on quoted-pair > and obs-unstruct. > > This approach has two other advantages. One, we're not messing with a core ABNF > production any more. Two, we're not modifying the obsolete syntax this way, > which is the same as how ctext works so it's a bit more consistent. I haven't formed my own opinion about how best to handle these concerns, yet. So this note is meant for exploration... Models for doing quoting vary between "provide an escape mechanism only for 'special' characters" versus "make the quoting mechanism generic and allow ANY character to be quoted'. There is, as noted, also the difference between escaping a collection of bits versus escaping "characters". The quoting mechanism in RFC 5322 chose the model of allowing any (visible) character to be quoted. And this did mean character, not "bag of bits", I believe. One major advantage of any vs. selective characters is that a user is free to use quoting without having to worry about whether it's a special character. So there's a usability benefit that's significant. However, in this case, the specification uses the human factors trick of "visibility". The fact that the existing mechanism is already limited to a subset of full ASCII means that continuing to restrict the set of characters that can be quoted would merely be a continuation of that model. It's also true that there is no "need" to quote other UTF-8 characters, I suppose. That said, I'm leaning towards having the mechanism require as little thought by the user as possible. Having to think about whether the character is below x07f or above it strikes me as poor human factors. The modification to define seems reasonable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sun Jan 23 08:13:32 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 59CCC3A690C for ; Sun, 23 Jan 2011 08:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR-BTOhcOwKd for ; Sun, 23 Jan 2011 08:13:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 6F57A3A690B for ; Sun, 23 Jan 2011 08:13:31 -0800 (PST) Received: from [192.168.1.225] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0NGGImP016976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 23 Jan 2011 08:16:23 -0800 Message-ID: <4D3C5449.4060606@dcrocker.net> Date: Sun, 23 Jan 2011 08:16:09 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ima@ietf.org" References: In-Reply-To: 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]); Sun, 23 Jan 2011 08:16:23 -0800 (PST) Subject: [EAI] ABNF for IDN in EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 23 Jan 2011 16:13:32 -0000 On 1/22/2011 2:54 PM, Shawn Steele wrote: > As mentioned, IMO, the domain part should "just" say UTF-8 as well, though > it's fair to point out the dependencies on existing RFCs that define DNS. > DNS is a bit trickier than the other headers because we explicitly want to > disallow the punycode I think, and require UTF-8 U-Labels instead. (disclaimer: I remain tentative aboout discussing anything in the IDN realm, so when -- not if -- I get an issue wrong, please be gentle...) I think the modification for domain name pertains to the rule. It's temping to do an incremental enhancement to it that is similar to the other proposed UTF-8 additions, but of course IDN is rather more complicated. So it's tempting to just do something like: dot-atom = if there were such an ABNF rule already defined. Worse, the definition of is not simple. It is another case of defining things as "not ASCII" rather than as "UTF-8". It's requirement that the string have at least one character above x07f makes it a less usable construct for our purposes than one might have expected. I have not found any ABNF that covers the legal domain name characters for "native" UTF-8. I believe that rule needs to be defined and then we should use it directly. Since we are specifying a relatively clean UTF-8 environment, we should probably try to avoid UTF8-over-ASCII encoding mechanisms, if that's reasonable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Sun Jan 23 18:53:27 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 E40163A6A1C for ; Sun, 23 Jan 2011 18:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35Uc4kVWmZ2n for ; Sun, 23 Jan 2011 18:53:26 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 68EC13A6A22 for ; Sun, 23 Jan 2011 18:53:26 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 23 Jan 2011 18:56:13 -0800 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.191]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Sun, 23 Jan 2011 18:56:13 -0800 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) Thread-Index: AQHLuuyEEuWyiH/110y72nEFzZFe0pPfbll2 Date: Mon, 24 Jan 2011 02:56:13 +0000 Message-ID: References: <8244D38A28FB919303079D4E@PST.JCK.COM> In-Reply-To: <8244D38A28FB919303079D4E@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) 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, 24 Jan 2011 02:53:28 -0000 WWVzLCBpdCdzIGxlZ2FsIGZvciB0aGUgZXhpc3RpbmcgUkZDcywgaG93ZXZlciB0aGUgZXhpc3Rp bmcgUkZDcyBkb24ndCBhbGxvdyB0aGUgdXNlIG9mIE1BSUwgRlJPTSBVVEY4U01UUC4gIFByZXN1 bWFibHkgaXQgY291bGQgYmUgYSByZXF1aXJlbWVudCB0aGF0IGlmIHlvdSdyZSB1c2luZyB0aGUg RUFJIFJGQywgdGhlbiBwdW55Y29kZSBjb3VsZCBiZSBpbGxlZ2FsLg0KDQpBdCB0aGUgdmVyeSBs ZWFzdCB1LWxhYmVscyBzaG91bGQgYmUgYSBTSE9VTEQuDQoNCi1TaGF3bg0KDQrvo6Lvo5Dvo6fv o5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKb2huIEMgS2xl bnNpbiBba2xlbnNpbkBqY2suY29tXQ0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDIzLCAyMDExIDI6 NTggQU0NClRvOiBTaGF3biBTdGVlbGU7IGltYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFQUld IFByb3Bvc2FsIGZvciBBbHRlcm5hdGUgQUJORiAod2FzOiBDb25zZW5zdXMgSXNzdWUgIzY6IGN1 cnJlbnQgbWV0YWxhbmd1YWdlIG1vZGVsIGFjY2VwdGFibGU/KQ0KDQotLU9uIFNhdHVyZGF5LCBK YW51YXJ5IDIyLCAyMDExIDIyOjU0ICswMDAwIFNoYXduIFN0ZWVsZQ0KPFNoYXduLlN0ZWVsZUBt aWNyb3NvZnQuY29tPiB3cm90ZToNCg0KPj4gSSBjYW4gbGl2ZSB3aXRoIHRoaXMgYXBwcm9hY2gu ICBJZiBpdCBpcyBhZG9wdGVkLCBJJ2xsIGhlbHANCj4+IHNvcnQgb3V0IHRoZSBkb21haW4gbmFt ZSBwYXJ0Lg0KPg0KPiBBcyBtZW50aW9uZWQsIElNTywgdGhlIGRvbWFpbiBwYXJ0IHNob3VsZCAi anVzdCIgc2F5IFVURi04IGFzDQo+IHdlbGwsIHRob3VnaCBpdCdzIGZhaXIgdG8gcG9pbnQgb3V0 IHRoZSBkZXBlbmRlbmNpZXMgb24NCj4gZXhpc3RpbmcgUkZDcyB0aGF0IGRlZmluZSBETlMuICBE TlMgaXMgYSBiaXQgdHJpY2tpZXIgdGhhbiB0aGUNCj4gb3RoZXIgaGVhZGVycyBiZWNhdXNlIHdl IGV4cGxpY2l0bHkgd2FudCB0byBkaXNhbGxvdyB0aGUNCj4gcHVueWNvZGUgSSB0aGluaywgYW5k IHJlcXVpcmUgVVRGLTggVS1MYWJlbHMgaW5zdGVhZC4NCg0KU2hhd24sDQoNCkkga25vdyB0aGF0 IHlvdSB3YW50IHRvICJkaXNhbGxvdyIgcHVueWNvZGUuICBJbiBhIHBlcmZlY3QNCndvcmxkLCBJ IHdvdWxkIHRvbywgYW5kIHRoYXQgaXMgcGFydCBvZiB3aGF0DQpkcmFmdC1pYWItaWRuLWVuY29k aW5nIGlzIGFib3V0LiAgQnV0LCByZWFsaXN0aWNhbGx5LCB3aGlsZSB3ZQ0KY2FuIHRyeSB0byBk aXNjb3VyYWdlIGl0cyB1c2UsIGJhbm5pbmcgaXQgaXMganVzdCBpbXByYWN0aWNhbA0KZ2l2ZW4g dGhhdCBBLWxhYmVscyBjb25mb3JtIHRvIHRoZSBSRkMgMTAzNSAicHJlZmVycmVkIHN5bnRheCIs DQp0aGUgc3ludGF4IHJlcXVpcmVtZW50cyBvZiBSRkNzIDUzMjEgYW5kIDUzMjIsIGFuZCBldmVu IHRoZQ0KcmF0aGVyIGNhcmVmdWwgcnVsZXMgaW4gUkZDIDU4OTIgYWJvdXQgd2hhdCBkb2VzIGFu ZCBkb2VzIG5vdA0KbmVlZCB0byBiZSBjaGVja2VkIG9uIGxvb2t1cC4NCg0KICAgIGpvaG4= From klensin@jck.com Sun Jan 23 19:45:41 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 B58823A6A37 for ; Sun, 23 Jan 2011 19:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEzwiKpYlqpL for ; Sun, 23 Jan 2011 19:45:36 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 664CB3A6A3D for ; Sun, 23 Jan 2011 19:45:32 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PhDPl-000OHx-2x; Sun, 23 Jan 2011 22:48:25 -0500 Date: Sun, 23 Jan 2011 22:48:24 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <8DE3F3A877E619DDC7CEA80B@PST.JCK.COM> In-Reply-To: References: <8244D38A28FB919303079D4E@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) 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, 24 Jan 2011 03:45:41 -0000 --On Monday, January 24, 2011 02:56 +0000 Shawn Steele wrote: > Yes, it's legal for the existing RFCs, however the existing > RFCs don't allow the use of MAIL FROM UTF8SMTP. Presumably it > could be a requirement that if you're using the EAI RFC, then > punycode could be illegal. > > At the very least u-labels should be a SHOULD. I don't see any problem with a SHOULD. But the ability to use an A-label anywhere that a U-label is permitted is fairly fundamental to the IDNA design. Unless you want to get the WG into the business of updating IDNA itself -- IMO, a bad idea and probably outside charter-- I don't see any practical way to go beyond a SHOULD. Note that, while we avoided RFC 2119 language (consistent with the IESG decision to process 4952bis as Informational), the Framework document already essentially has the SHOULD. In Section 7.1 of draft-eai-frmwrk-4952bis-10, general principle (1), we have: When the local part of the address includes characters outside the ASCII character repertoire, use of ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to promote consistent processing of characters throughout the address. "strongly discouraged" is pretty clear. And, slipping on my co-chair hat for a moment, since 4952bis has successfully been through WG and IETF Last Call and IESG signoff, in the absence of significant new issues, I consider this a settled matter that is not subject to further debate or discussion. Whatever text appears in 5336bis/5335bis needs to be consistent with that principle, but that should be an editorial matter, not a substantive one. john From chl@clerew.man.ac.uk Mon Jan 24 03:30:35 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 7B3553A685D for ; Mon, 24 Jan 2011 03:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rmRe1L+c8jaP for ; Mon, 24 Jan 2011 03:30:34 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id ED0D03A684B for ; Mon, 24 Jan 2011 03:30:33 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id E93DD2232C for ; Mon, 24 Jan 2011 11:33:16 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 24 Jan 2011 11:33:16 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0OBXFfX009291 for ; Mon, 24 Jan 2011 11:33:16 GMT Date: Mon, 24 Jan 2011 11:33:15 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <749808477.20110118012903@pobox.com> <01NWRLLOJPBG007CHU@mauve.mrochek.com> <01NWUL0VNF98007CHU@mauve.mrochek.com> <541FA852728BD37BCBA5C606@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <541FA852728BD37BCBA5C606@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d3d637c.16b3-1000-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 11:30:35 -0000 On Fri, 21 Jan 2011 12:50:35 -0000, John C Klensin wrote: > Option 2: In order to avoid requiring a subsequent analysis of > headers before dealing with a server that cannot handle EAI > extensions, an EAI-capable client talking with an EAI-capable > server SHOULD send the parameter only if it has reason to > believe that the message requires EAI support. "Reason to > believe" allows exceptions and might be further noted, but the > intent is that the parameter not be sent with ASCII-only (aka > strictly 5321/5322-conforming) messages. As I understand it, > this is what Charles and Ned are proposing. Most definitely #2. For sure that is what I have been assuming in all the comments I have posted. Now there may be reasons for toning down the wording a bit. I take Shawn's point that when everybody is using EAI there is little point in striving to maintain that SHOULD. And it may be just too much trouble for some MUAs or submission agents to make the necessary checks. So replacing "an EAI-capable client ... SHOULD send ..." by "an EAI-capable client ... would be well advised to send ...". Followed, of course, by that NOTE explaining the difficulties that might ensue of the advice is not taken. It is then up to each implementor to evaluate the warnings in the NOTE in the light of his own circumstances, and the then prevailing practice in the great big world outside. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From fujiwara@jprs.co.jp Mon Jan 24 04:02: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 CAB4D3A6AC4 for ; Mon, 24 Jan 2011 04:02:03 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wsG5RXeFHsl for ; Mon, 24 Jan 2011 04:02:03 -0800 (PST) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by core3.amsl.com (Postfix) with ESMTP id 5B89A3A6AC3 for ; Mon, 24 Jan 2011 04:02:02 -0800 (PST) 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 p0OC4tPT009908 for ; Mon, 24 Jan 2011 21:04:55 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 205433414 for ; Mon, 24 Jan 2011 21:04:55 +0900 (JST) X-AuditID: ca0b1172-0000000400000914-17-4d3d6ae638e0 Date: Mon, 24 Jan 2011 21:04:54 +0900 (JST) Message-Id: <20110124.210454.193718175.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.afilias.info> References: <53A3BDBF-F672-4989-A6CB-BE91CF3F112C@ca.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] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 12:02:03 -0000 > From: Joseph Yee > Issue #1: parameter on MAIL FROM? > http://trac.tools.ietf.org/wg/eai/trac/ticket/1 > > Description > --------------- > > Should the WG add parameter on MAIL FROM to start EAI transaction and avoid the need for deep inspection? Yes. A message may contain nested MIME structure and may contain UTF-8 filename in a MIME header field. Inspecting nested MIME structure and checking each MIME header field are too expensive to impliment in MTAs, I think. -- Kazunori Fujiwara, JPRS From johnl@iecc.com Mon Jan 24 07:47:28 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 7049B3A6B00 for ; Mon, 24 Jan 2011 07:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.064 X-Spam-Level: X-Spam-Status: No, score=-111.064 tagged_above=-999 required=5 tests=[AWL=0.135, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxK+iRoB5ieV for ; Mon, 24 Jan 2011 07:47:24 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 897C73A6AF0 for ; Mon, 24 Jan 2011 07:47:24 -0800 (PST) Received: (qmail 94194 invoked from network); 24 Jan 2011 15:50:18 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 24 Jan 2011 15:50:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=13b42.4d3d9fba.k1101; i=johnl@user.iecc.com; bh=yGotW+JD64WDkXRA1eP/MHWBSOm/BPNOjvGrtOrhWtg=; b=BqbfeR62oexLuy1CiySWC9gH65hn1ATjE5G3Vmk2wNwyEsMvKu20MejBmUvhaIdCvufByl8+olirsUdhG3pv6nYNb5hYQycPUpArb6e/OlBVcWVwgMGK/i55PVi8VjraSAmKryTR86SimzOq0ejDnXLWP7xyZM5XRdobPjPidd8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=13b42.4d3d9fba.k1101; olt=johnl@user.iecc.com; bh=yGotW+JD64WDkXRA1eP/MHWBSOm/BPNOjvGrtOrhWtg=; b=CYXUVW9iJoJMvgv7LKBtDE8WA/0PQ4RtQaZRnd73y8ED/fffTJebAJ3sXfXmiXog9LwuwGCWxMG80Yp0yX122KZsHJwutexWPM2xWfbgpR6br5uHOW/ZbhbJl1Vm2lkHCbqtXhZ2f1kPJFS3OYr+goDBRIFx5Eg+d5f1eu/m2o0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Jan 2011 15:50:18 -0000 Message-ID: <20110124155018.80705.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <541FA852728BD37BCBA5C606@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 15:47:28 -0000 >Option 1: Any EAI-capable client that is talking with a server >that supports EAI extensions SHOULD send the parameter with >MAIL, indicating that it is modern ... >Option 2: ... an EAI-capable client talking with an EAI-capable >server SHOULD send the parameter only if it has reason to >believe that the message requires EAI support. I think that King Canute may have some useful advice for us here. It is obviously the case that for a while, perhaps quite a while, #2 will make it more likely that your mail will get delivered to the many non-EAI destinations, and it's probably worth putting a note and a SHOULD about that. But particularly in areas where English is not the major language, people will do #1 and EAI mail hosts better be prepared to deal with it, for some definition of deal with it yet to be finalized. R's, John From klensin@jck.com Mon Jan 24 10:21:01 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 178B93A6B15 for ; Mon, 24 Jan 2011 10:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN-j0ZQZaEbC for ; Mon, 24 Jan 2011 10:21:00 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 017E03A6B0B for ; Mon, 24 Jan 2011 10:21:00 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PhR50-000LAl-HO; Mon, 24 Jan 2011 13:23:54 -0500 Date: Mon, 24 Jan 2011 13:23:53 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <7B64349778CD5CB2958D6D36@PST.JCK.COM> In-Reply-To: <20110124155018.80705.qmail@joyce.lan> References: <20110124155018.80705.qmail@joyce.lan> 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] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 18:21:01 -0000 --On Monday, January 24, 2011 15:50 +0000 John Levine wrote: >> Option 1: Any EAI-capable client that is talking with a server >> that supports EAI extensions SHOULD send the parameter with >> MAIL, indicating that it is modern ... > >> Option 2: ... an EAI-capable client talking with an >> EAI-capable server SHOULD send the parameter only if it has >> reason to believe that the message requires EAI support. > > I think that King Canute may have some useful advice for us > here. > > It is obviously the case that for a while, perhaps quite a > while, #2 will make it more likely that your mail will get > delivered to the many non-EAI destinations, and it's probably > worth putting a note and a SHOULD about that. But > particularly in areas where English is not the major language, > people will do #1 and EAI mail hosts better be prepared to > deal with it, for some definition of deal with it yet to be > finalized. That would be accomplished by either: (i) "MUST supply the parameter if the envelope or message requires EAI facilities and SHOULD NOT supply it if the client is EAI-capable but not using EAI facilities" or (ii) "MUST supply the parameter if the envelope or message requires EAI facilities and MAY supply it if the client is EAI-capable but not using EAI facilities" Either of those would be consistent with Option 2, the second is a lot weaker. john From johnl@taugh.com Mon Jan 24 10:25:22 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 7C48F3A6B23 for ; Mon, 24 Jan 2011 10:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.066 X-Spam-Level: X-Spam-Status: No, score=-11.066 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX8iXkvYTH3w for ; Mon, 24 Jan 2011 10:25:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 3F1423A698F for ; Mon, 24 Jan 2011 10:25:20 -0800 (PST) Received: (qmail 45652 invoked from network); 24 Jan 2011 18:28:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b252.4d3dc4bf.k1101; i=johnl@submit.iecc.com; bh=nZ1mNuPqEHr7E2HqzVzBISaIcDLjigr9DJgHF4t5WSQ=; b=XAxDVzL/PkTvtfhUMEvUKTVYJW/C1rb4vjk08gLIU7KzLjl7t9LrWDTDQ+Tkm7NpZyHkh3OTOICaWqHgeKjqUQsy8PaKF7TLVF8FsB1zRlQC6YyegK1u919tP2TxLlKNCYzoT7CX2dww9tOuSohhaYib6PR343JQxfc2rWv+y2o= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b252.4d3dc4bf.k1101; olt=johnl@submit.iecc.com; bh=nZ1mNuPqEHr7E2HqzVzBISaIcDLjigr9DJgHF4t5WSQ=; b=S2sqiXaTS073ndRr9VDFasNdC6QzHp5DfYnSNwDOdcF+f2hfGkPuL0JKmewv+lBM8v+GkMdcRAP4tvZOQWJgeWLEtYvfeNzikASpWENspAdljwzeI7ncmgfJStlVCL5Qv9xkKU8XFOlRUP8uV/zStKlMUE0giChGPCs6OPuFpGo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jan 2011 18:27:53 -0000 Date: 24 Jan 2011 13:28:13 -0500 Message-ID: From: "John R Levine" To: ima@ietf.org In-Reply-To: <7B64349778CD5CB2958D6D36@PST.JCK.COM> References: <20110124155018.80705.qmail@joyce.lan> <7B64349778CD5CB2958D6D36@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 18:25:22 -0000 > (i) "MUST supply the parameter if the envelope or message > requires EAI facilities and SHOULD NOT supply it if the client > is EAI-capable but not using EAI facilities" > > or > > (ii) "MUST supply the parameter if the envelope or message > requires EAI facilities and MAY supply it if the client is > EAI-capable but not using EAI facilities" I'd go with (ii) since that's likely to match what people really do. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From Shawn.Steele@microsoft.com Mon Jan 24 12:42:28 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 806BE3A696A for ; Mon, 24 Jan 2011 12:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-OcjTQkELyZ for ; Mon, 24 Jan 2011 12:42:27 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id BC7553A692C for ; Mon, 24 Jan 2011 12:42:27 -0800 (PST) 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; Mon, 24 Jan 2011 12:45:23 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Mon, 24 Jan 2011 12:45:23 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Issue #1: parameter on MAIL FROM? Thread-Index: Acu8B1zbkj2t7f2FRguvYJ7uOcujyw== Date: Mon, 24 Jan 2011 20:45:22 +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.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 20:42:28 -0000 In case it wasn't obvious, I also prefer (ii). Unfortunately that doesn't help the server "downgrade" a mail, it'd still h= ave to see if it could treat it as a legacy message. It does, however, hel= p the server realize that this situation might apply. -Shawn ------------------------------ Message: 7 Date: 24 Jan 2011 13:28:13 -0500 From: "John R Levine" Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? To: ima@ietf.org Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > (i) "MUST supply the parameter if the envelope or message > requires EAI facilities and SHOULD NOT supply it if the client > is EAI-capable but not using EAI facilities" > > or > > (ii) "MUST supply the parameter if the envelope or message > requires EAI facilities and MAY supply it if the client is > EAI-capable but not using EAI facilities" I'd go with (ii) since that's likely to match what people really do. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. ------------------------------ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima End of IMA Digest, Vol 66, Issue 35 *********************************** From johnl@iecc.com Mon Jan 24 15:11:38 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 54FF63A69A5 for ; Mon, 24 Jan 2011 15:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.068 X-Spam-Level: X-Spam-Status: No, score=-111.068 tagged_above=-999 required=5 tests=[AWL=0.131, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6Gbtyg5dCSD for ; Mon, 24 Jan 2011 15:11:37 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id AF5D83A6995 for ; Mon, 24 Jan 2011 15:11:36 -0800 (PST) Received: (qmail 28353 invoked from network); 24 Jan 2011 23:14:31 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 24 Jan 2011 23:14:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=7ef3.4d3e07d5.k1101; i=johnl@user.iecc.com; bh=BqQUjvvvmOaldepxLvSvnNO/tN5UJSTMyGJ92Mz3Fow=; b=rq+YAtoYBm8+VSde9QfNZDEEqPHU/FQ3t1ZnEDCf4a0B6U4m9oJDEbm3U/yXj3np8HVjw74lmyCHIFXyBP/CmwrFJRcpOf+upJOhw2QpuvrMjmfQJO56nFYFx4vpT6A+mQ1PVnV5gYcUcUaIwQvVrQJL4QVn988+TWWR/2A5gTE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=7ef3.4d3e07d5.k1101; olt=johnl@user.iecc.com; bh=BqQUjvvvmOaldepxLvSvnNO/tN5UJSTMyGJ92Mz3Fow=; b=lgoCVv67gaUAh1X3nSxPLrrCJU3nUvE7JRlsdv5kje/2fI6FVKdvSG6scprgkLc6Gc7kSyCz6Kojz3Eu8W8kaLMWnUieBMV84H/0dNoOfA7swIoVDOgJTikRb3kGuXUMiwBPTtl9SzQ3oCKflDJ8iCTLFy+f7YMsXLXoo6RGwo0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Jan 2011 23:14:29 -0000 Message-ID: <20110124231429.32498.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Shawn.Steele@microsoft.com Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 23:11:38 -0000 >Unfortunately that doesn't help the server "downgrade" a mail, it'd >still have to see if it could treat it as a legacy message. It does, >however, help the server realize that this situation might apply. Unless someone strongly objects, can we save the downgrade discussion for later? Lots of worms in that can, no matter what we decide at this point. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From Shawn.Steele@microsoft.com Mon Jan 24 15:13:22 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 732143A69BC for ; Mon, 24 Jan 2011 15:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGdKpwPloeWW for ; Mon, 24 Jan 2011 15:13:21 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DF1F53A69B9 for ; Mon, 24 Jan 2011 15:13:19 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Jan 2011 15:16:09 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Mon, 24 Jan 2011 15:16:09 -0800 From: Shawn Steele To: John Levine , "ima@ietf.org" Thread-Topic: [EAI] Consensus Issue #1: parameter on MAIL FROM? Thread-Index: Acu8B1zbkj2t7f2FRguvYJ7uOcujywAWCSaAABC9OYA= Date: Mon, 24 Jan 2011 23:16:08 +0000 Message-ID: References: <20110124231429.32498.qmail@joyce.lan> In-Reply-To: <20110124231429.32498.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM? 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, 24 Jan 2011 23:13:22 -0000 QmFkIGNob2ljZSBvZiB3b3Jkcywgc29ycnksIEkgbWVhbnQgYSBsZWdhY3kgbWVzc2FnZSwgd2hp Y2gsIGJ5IGRlZmluaXRpb24sIGNvdWxkIGJlIGZvcndhcmRlZCB3aXRob3V0IGNoYW5naW5nIGl0 Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBMZXZpbmUgW21haWx0 bzpqb2hubEB0YXVnaC5jb21dIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDExIDM6MTQg UE0NClRvOiBpbWFAaWV0Zi5vcmcNCkNjOiBTaGF3biBTdGVlbGUNClN1YmplY3Q6IFJlOiBbRUFJ XSBDb25zZW5zdXMgSXNzdWUgIzE6IHBhcmFtZXRlciBvbiBNQUlMIEZST00/DQoNCj5VbmZvcnR1 bmF0ZWx5IHRoYXQgZG9lc24ndCBoZWxwIHRoZSBzZXJ2ZXIgImRvd25ncmFkZSIgYSBtYWlsLCBp dCdkIA0KPnN0aWxsIGhhdmUgdG8gc2VlIGlmIGl0IGNvdWxkIHRyZWF0IGl0IGFzIGEgbGVnYWN5 IG1lc3NhZ2UuICBJdCBkb2VzLCANCj5ob3dldmVyLCBoZWxwIHRoZSBzZXJ2ZXIgcmVhbGl6ZSB0 aGF0IHRoaXMgc2l0dWF0aW9uIG1pZ2h0IGFwcGx5Lg0KDQpVbmxlc3Mgc29tZW9uZSBzdHJvbmds eSBvYmplY3RzLCBjYW4gd2Ugc2F2ZSB0aGUgZG93bmdyYWRlIGRpc2N1c3Npb24gZm9yIGxhdGVy PyAgTG90cyBvZiB3b3JtcyBpbiB0aGF0IGNhbiwgbm8gbWF0dGVyIHdoYXQgd2UgZGVjaWRlIGF0 IHRoaXMgcG9pbnQuDQoNClJlZ2FyZHMsDQpKb2huIExldmluZSwgam9obmxAaWVjYy5jb20sIFBy aW1hcnkgUGVycGV0cmF0b3Igb2YgIlRoZSBJbnRlcm5ldCBmb3IgRHVtbWllcyIsIFBsZWFzZSBj b25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHJlYWRpbmcgdGhpcyBlLW1haWwuIGh0dHA6 Ly9qbC5seQ0KDQo= From Internet-Drafts@ietf.org Mon Jan 24 19:00: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 B9DD23A6A1B; Mon, 24 Jan 2011 19:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 p-ytJaHj88Bs; Mon, 24 Jan 2011 19:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496DD3A699F; Mon, 24 Jan 2011 19:00:02 -0800 (PST) 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.10 Message-ID: <20110125030002.22957.27954.idtracker@localhost> Date: Mon, 24 Jan 2011 19:00:02 -0800 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-rfc5335bis-08.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: Tue, 25 Jan 2011 03:00: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 : Internationalized Email Headers Author(s) : . Yang, et al. Filename : draft-ietf-eai-rfc5335bis-08.txt Pages : 12 Date : 2011-01-24 Internet mail was originally limited to 7-bit ASCII. Recent enhancements support Unicode's UTF-8 encoding in portions of a message. Full internationalization of electronic mail requires additional enhancement, including support for UTF-8 in user-oriented header fields, such as in the To, From, and Subject fields. This document specifies an enhancement to Internet mail that permits native UTF-8 support in the header and body of a message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eai-rfc5335bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-24185811.I-D@ietf.org> --NextPart-- From alexey.melnikov@isode.com Tue Jan 25 03:04:01 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 5DD323A6B9D for ; Tue, 25 Jan 2011 03:04:01 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgtVIYkdVbxu for ; Tue, 25 Jan 2011 03:04:00 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8DA2F3A6B9F for ; Tue, 25 Jan 2011 03:03:59 -0800 (PST) Received: from [188.28.235.67] (188.28.235.67.threembb.co.uk [188.28.235.67]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 25 Jan 2011 11:06:55 +0000 Message-ID: <4D3EAEC6.20701@isode.com> Date: Tue, 25 Jan 2011 11:06:46 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org References: <20110125030002.22957.27954.idtracker@localhost> In-Reply-To: <20110125030002.22957.27954.idtracker@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [EAI] I-D Action:draft-ietf-eai-rfc5335bis-08.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: Tue, 25 Jan 2011 11:04:01 -0000 Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Email Address Internationalization Working Group of the IETF. > > > Title : Internationalized Email Headers > Author(s) : . Yang, et al. > Filename : draft-ietf-eai-rfc5335bis-08.txt > Pages : 12 > Date : 2011-01-24 > >Internet mail was originally limited to 7-bit ASCII. Recent >enhancements support Unicode's UTF-8 encoding in portions of a >message. Full internationalization of electronic mail requires >additional enhancement, including support for UTF-8 in user-oriented >header fields, such as in the To, From, and Subject fields. This >document specifies an enhancement to Internet mail that permits >native UTF-8 support in the header and body of a message. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-08.txt > This is not cool. I didn't authorize this version, I don't believe chairs have authorized it either. This version contains changes that are not yet officially agreed by the WG and also includes changes that weren't even discussed in the WG. I would ask editors to rollback the changes, unless chairs tell me that this version was actually authorized by at least one of them. Thanks, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From klensin@jck.com Tue Jan 25 05:55:15 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 1900F3A6BBB for ; Tue, 25 Jan 2011 05:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLr7Tr9PXEia for ; Tue, 25 Jan 2011 05:55:14 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1C67D3A6872 for ; Tue, 25 Jan 2011 05:55:14 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PhjPP-000NW3-3X; Tue, 25 Jan 2011 08:58:11 -0500 Date: Tue, 25 Jan 2011 08:58:10 -0500 From: John C Klensin To: Alexey Melnikov , ima@ietf.org Message-ID: In-Reply-To: <4D3EAEC6.20701@isode.com> References: <20110125030002.22957.27954.idtracker@localhost> <4D3EAEC6.20701@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] I-D Action:draft-ietf-eai-rfc5335bis-08.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: Tue, 25 Jan 2011 13:55:15 -0000 --On Tuesday, January 25, 2011 11:06 +0000 Alexey Melnikov wrote: > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> Email Address Internationalization Working Group of the IETF. >> >> >> Title : Internationalized Email Headers >> Author(s) : . Yang, et al. >> Filename : draft-ietf-eai-rfc5335bis-08.txt >> Pages : 12 >> Date : 2011-01-24 >... > This version contains changes that are not yet officially > agreed by the WG and also includes changes that weren't even > discussed in the WG. > > I would ask editors to rollback the changes, unless chairs > tell me that this version was actually authorized by at least > one of them. At least this co-chair was as surprised as you were. I thought we had an agreement that no more drafts were to be posted without an official announcement of consensus on the points covered. I'm assuming that Joseph will start posting such announcements relatively soon, but I haven't seen them. This is perhaps also an appropriate time to remind everyone that Editors are appointed by WG Chairs with the advice and consent of ADs, not by other editors. john From Shawn.Steele@microsoft.com Tue Jan 25 08:19:20 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 76AE23A67FF for ; Tue, 25 Jan 2011 08:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ug6ReTI5cmm for ; Tue, 25 Jan 2011 08:19:19 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0AED73A67EF for ; Tue, 25 Jan 2011 08:19:18 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Jan 2011 08:22:11 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Tue, 25 Jan 2011 08:22:11 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: The -08 draft Thread-Index: Acu8qNAgTZRDzg9aQFOqnW/RHGJ0GQ== Date: Tue, 25 Jan 2011 16:22:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A11C702EATK5EX14MBXC133r_" MIME-Version: 1.0 Subject: [EAI] The -08 draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:19:20 -0000 --_000_E14011F8737B524BB564B05FF748464A11C702EATK5EX14MBXC133r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBlcnJvciB3YXMgdW5pbnRlbnRpb25hbCBhbmQgdGhlIHJlc3VsdCBvZiBhIG1pc2NvbW11 bmljYXRpb24gYmV0d2VlbiBteXNlbGYgYW5kIFlhbmcuICBJdCBjYW4gYmUgcm9sbGVkIGJhY2ss IChpcyB0aGF0IHNvbWV0aGluZyBJIGNhbiBkbyBvciBkb2VzIEFiZWwgbmVlZCB0byBkbyBpdD8p IGFsdGhvdWdoIG5vdyBJIHN1cHBvc2UgdGhlIGlkZWFzIGFyZSBvdXQgdGhlcmUuDQoNCg0KDQpU aGlzIGRvY3VtZW50IHdhcyBpbnRlbmRlZCB0byBiZSBvZmZlcmVkIGFzIGEgcG9zc2libGUgc2lt cGxpZmljYXRpb24gdGhhdCBtaWdodCByZXNvbHZlIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHRoYXQg dGhlIHdvcmtpbmcgZ3JvdXAgaGFzLiAgSU1PLCBpdCBzZXJ2ZXMgdGhlIGludGVudCBvZiB3aGF0 IHdlJ3ZlIGJlZW4gdHJ5aW5nIHRvIGRvLiAgWW91J2xsIHJlY29nbml6ZSBzb21lIG9mIHRoZSB0 ZXh0IGFzIERhdmUncyB3b3JkaW5nLCBhbmQgdGhlIGFkZGl0aW9uYWwgbmFtZXMgd2VyZSBub3Qg aW50ZW50aW9uYWxseSBhZGRlZCB0byBhdm9pZCB0aGUgcHJvY2Vzc2VzLCBidXQgd2FzIHJhdGhl ciBhbiB1bmZvcnR1bmF0ZSBlcnJvciBhbmQgbWlzdW5kZXJzdGFuZGluZy4NCg0KDQoNCi0tLS0t LS0NCg0KDQoNClRoaXMgd29ya2luZyBncm91cCBpcyBjb21wb3NlZCBwcmltYXJpbHkgb2YgYSBs b3Qgb2YgcGVvcGxlIHdobyBkbyBOT1QgaGF2ZSBhICJoaXN0b3J5IiBpbiB0aGUgSUVURi4gIE15 c2VsZiBhbmQgb3RoZXJzIG1heSBhY2NpZGVudGFsbHkgbWFrZSBwcm9jZWR1cmFsIGVycm9ycyB3 aXRob3V0IGludGVuZGluZyBhbnkgc2xpZ2h0cy4gIFdlIGFsc28gZG9uJ3Qga25vdyBhYm91dCB0 aGUgcG9saXRpY3MgYW5kIGluZmlnaHRpbmcgd2l0aGluIHRoZSBJRVRGLiAgSSB0aGluayB0aGF0 IG1vc3Qgb2YgdGhlIG1lbWJlcnMgb2YgdGhlIHJhbmsgYW5kIGZpbGUgbWVtYmVycywgYW5kIGVk aXRvcnMsIG9mIHRoaXMgd29ya2luZyBncm91cCBhcmUgaW50ZXJlc3RlZCBwcmltYXJpbHkgaW4g c29sdmluZyBFQUksIGFuZCB3ZSBkb24ndCBwYXJ0aWN1bGFybHkgbGlrZSBiZWluZyBpbiB0aGUg bWlkZGxlIG9mIGV4dHJhbmVvdXMgSUVURiBwb2xpdGljcy4gIEkgZXhwZWN0IGNvbnRyaWJ1dGlv bnMgdG8gYmUgY29uc2lkZXJlZCBvbiB0aGVpciBvd24gbWVyaXRzLCBhbmQgbm90IG9uIHBlcnNv bmFsIGhpc3Rvcnkgb2YgdGhlIHBlcnNvbiB3aG8gaGFkIHRoZSBpZGVhLg0KDQoNCg0KRGF2ZSdz IG9yaWdpbmFsIGZlZWRiYWNrIHRvIHRoaXMgV0cgd2FzIHZlcnkgbWlzZ3VpZGVkIGFuZCBoZSBk aWRuJ3QgaGF2ZSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBTb21lIG9m IGhpcyBtb3JlIHJlY2VudCBpZGVhcyBzZWVtIHZlcnkgdXNlZnVsLCB3aXRob3V0IHNvbWUgb2Yg dGhlIHByZWNvbmNlcHRpb25zIHRoZSBXRyBoYXMgaGFkLCBhbmQgdmVyeSBtdWNoIGFsaWduZWQg d2l0aCB0aGUgcmVjZW50IGRpc2N1c3Npb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBUaGlzIHZl cnktbXVjaC1yZXZpc2VkIGRvY3VtZW50IGNvbnRhaW5zIGxvdHMgb2YgaGlzIHRoaW5raW5nLCBz byBpdCBzZWVtZWQgb25seSBmYWlyIHRvIGFkZCBoaXMgbmFtZS4gIEFiZWwgYW5kIEkgYXJlIGlu IGFncmVlbWVudCB0aGF0IHRoaXMgaXMgYSBkZWNlbnQgcHJvcG9zYWwsIHRob3VnaCB3ZSByZWFs aXplIHRoYXQgdGhlIFdHIGhhZCBpbnRlbmRlZCB0byB3YWl0IHRvIHBvc3QgYW5vdGhlciBkb2N1 bWVudCwgYW5kIHdlIHJlYWxpemUgdGhhdCB0aGUgY2hhbmdlcyBhcmUgYmlnIGVub3VnaCB0byB3 YXJyYW50IGZ1cnRoZXIgcmV2aWV3Lg0KDQoNCg0KV2UncmUgdHJ5aW5nIGhhcmQsIGJ1dCB3ZSdy ZSBnb2luZyB0byBtYWtlIG1pc3Rha2VzLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KDQpJIHdpbGwgZW5kZWF2b3IgdG8gcmVjdGlmeSBhbnkgcHJvY2VkdXJhbCBlcnJvcnMsIGJ1 dCwgc2luY2UgdGhlIGlkZWFzIGFyZSB2aXNpYmxlIGF0IHRoZSBtb21lbnQsIEknZCBhcHByZWNp YXRlIGFueSBjb21tZW50cyBvbiB0aGUgaWRlYXMgaW4gdGhlIG1pcy1wb3N0ZWQgZG9jdW1lbnQu ICBJZiBuZWNlc3NhcnksIHBsZWFzZSBwcmV0ZW5kIHRoYXQgdGhlIGFkZGl0aW9uYWwgbmFtZXMg YXJlIGFic2VudC4NCg0KDQoNCi1TaGF3bg0KDQoNCg0KLS1PbiBUdWVzZGF5LCBKYW51YXJ5IDI1 LCAyMDExIDExOjA2ICswMDAwIEFsZXhleSBNZWxuaWtvdg0KPGFsZXhleS5tZWxuaWtvdiBhdCBp c29kZS5jb20+IHdyb3RlOg0KDQo+IEludGVybmV0LURyYWZ0cyBhdCBpZXRmLm9yZyB3cm90ZToN Cj4NCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l DQo+PiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlDQo+PiBFbWFpbCBBZGRyZXNzIEludGVybmF0aW9uYWxpemF0aW9uIFdvcmtpbmcg R3JvdXAgb2YgdGhlIElFVEYuDQo+Pg0KPj4NCj4+IFRpdGxlICAgICAgICAgICA6IEludGVybmF0 aW9uYWxpemVkIEVtYWlsIEhlYWRlcnMNCj4+IEF1dGhvcihzKSAgICAgICA6ICAuIFlhbmcsIGV0 IGFsLg0KPj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1lYWktcmZjNTMzNWJpcy0wOC50 eHQNCj4+IFBhZ2VzICAgICAgICAgICA6IDEyDQo+PiBEYXRlICAgICAgICAgICAgOiAyMDExLTAx LTI0DQo+Li4uDQo+IFRoaXMgdmVyc2lvbiBjb250YWlucyBjaGFuZ2VzIHRoYXQgYXJlIG5vdCB5 ZXQgb2ZmaWNpYWxseQ0KPiBhZ3JlZWQgYnkgdGhlIFdHIGFuZCBhbHNvIGluY2x1ZGVzIGNoYW5n ZXMgdGhhdCB3ZXJlbid0IGV2ZW4NCj4gZGlzY3Vzc2VkIGluIHRoZSBXRy4NCj4NCj4gSSB3b3Vs ZCBhc2sgZWRpdG9ycyB0byByb2xsYmFjayB0aGUgY2hhbmdlcywgdW5sZXNzIGNoYWlycw0KPiB0 ZWxsIG1lIHRoYXQgdGhpcyB2ZXJzaW9uIHdhcyBhY3R1YWxseSBhdXRob3JpemVkIGJ5IGF0IGxl YXN0DQo+IG9uZSBvZiB0aGVtLg0KDQpBdCBsZWFzdCB0aGlzIGNvLWNoYWlyIHdhcyBhcyBzdXJw cmlzZWQgYXMgeW91IHdlcmUuICBJIHRob3VnaHQNCndlIGhhZCBhbiBhZ3JlZW1lbnQgdGhhdCBu byBtb3JlIGRyYWZ0cyB3ZXJlIHRvIGJlIHBvc3RlZA0Kd2l0aG91dCBhbiBvZmZpY2lhbCBhbm5v dW5jZW1lbnQgb2YgY29uc2Vuc3VzIG9uIHRoZSBwb2ludHMNCmNvdmVyZWQuICBJJ20gYXNzdW1p bmcgdGhhdCBKb3NlcGggd2lsbCBzdGFydCBwb3N0aW5nIHN1Y2gNCmFubm91bmNlbWVudHMgcmVs YXRpdmVseSBzb29uLCBidXQgSSBoYXZlbid0IHNlZW4gdGhlbS4NCg0KVGhpcyBpcyBwZXJoYXBz IGFsc28gYW4gYXBwcm9wcmlhdGUgdGltZSB0byByZW1pbmQgZXZlcnlvbmUgdGhhdA0KRWRpdG9y cyBhcmUgYXBwb2ludGVkIGJ5IFdHIENoYWlycyB3aXRoIHRoZSBhZHZpY2UgYW5kIGNvbnNlbnQN Cm9mIEFEcywgbm90IGJ5IG90aGVyIGVkaXRvcnMuDQoNCiAgICBqb2huDQoNCg0KDQotU2hhd24N Cg0K76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmQ0KaHR0cDovL2Jsb2dzLm1zZG4uY29tL3No YXduc3RlDQoNCg== --_000_E14011F8737B524BB564B05FF748464A11C702EATK5EX14MBXC133r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgaWQ9Im93YVBhcmFT dHlsZSI+UCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBmUFN0eWxlPSIxIiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRp cmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhvbWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXpl OiAxMHB0OyI+DQo8ZGl2Pg0KPHA+VGhpcyBlcnJvciB3YXMgdW5pbnRlbnRpb25hbCBhbmQgdGhl IHJlc3VsdCBvZiBhIG1pc2NvbW11bmljYXRpb24gYmV0d2VlbiBteXNlbGYgYW5kIFlhbmcuJm5i c3A7IEl0IGNhbiBiZSByb2xsZWQgYmFjaywmbmJzcDsoaXMgdGhhdCBzb21ldGhpbmcgSSBjYW4g ZG8gb3IgZG9lcyBBYmVsJm5ic3A7bmVlZCB0byBkbyBpdD8pJm5ic3A7YWx0aG91Z2ggbm93IEkg c3VwcG9zZSB0aGUgaWRlYXMgYXJlIG91dCB0aGVyZS48L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5U aGlzIGRvY3VtZW50IHdhcyBpbnRlbmRlZCB0byBiZSBvZmZlcmVkIGFzIGEgcG9zc2libGUgc2lt cGxpZmljYXRpb24gdGhhdCBtaWdodCByZXNvbHZlIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHRoYXQg dGhlIHdvcmtpbmcgZ3JvdXAgaGFzLiZuYnNwOyBJTU8sIGl0IHNlcnZlcyB0aGUgaW50ZW50IG9m IHdoYXQgd2UndmUgYmVlbiB0cnlpbmcgdG8gZG8uJm5ic3A7IFlvdSdsbCByZWNvZ25pemUgc29t ZSBvZiB0aGUgdGV4dCBhcyBEYXZlJ3Mgd29yZGluZywgYW5kDQogdGhlIGFkZGl0aW9uYWwgbmFt ZXMgd2VyZSBub3QgaW50ZW50aW9uYWxseSBhZGRlZCB0byBhdm9pZCB0aGUgcHJvY2Vzc2VzLCBi dXQgd2FzIHJhdGhlciBhbiB1bmZvcnR1bmF0ZSBlcnJvciBhbmQgbWlzdW5kZXJzdGFuZGluZy48 L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD4tLS0tLS0tPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+VGhp cyB3b3JraW5nIGdyb3VwIGlzIGNvbXBvc2VkIHByaW1hcmlseSBvZiBhIGxvdCBvZiBwZW9wbGUg d2hvIGRvIE5PVCBoYXZlIGEgJnF1b3Q7aGlzdG9yeSZxdW90OyBpbiB0aGUgSUVURi4mbmJzcDsg TXlzZWxmIGFuZCBvdGhlcnMgbWF5IGFjY2lkZW50YWxseSBtYWtlIHByb2NlZHVyYWwgZXJyb3Jz IHdpdGhvdXQgaW50ZW5kaW5nIGFueSBzbGlnaHRzLiZuYnNwOyBXZSBhbHNvIGRvbid0IGtub3cg YWJvdXQgdGhlIHBvbGl0aWNzIGFuZCBpbmZpZ2h0aW5nIHdpdGhpbiB0aGUNCiBJRVRGLiZuYnNw OyBJIHRoaW5rIHRoYXQgbW9zdCBvZiB0aGUgbWVtYmVycyBvZiB0aGUgcmFuayBhbmQgZmlsZSBt ZW1iZXJzLCBhbmQgZWRpdG9ycywgb2YgdGhpcyZuYnNwO3dvcmtpbmcgZ3JvdXAgYXJlIGludGVy ZXN0ZWQgcHJpbWFyaWx5IGluIHNvbHZpbmcgRUFJLCBhbmQgd2UgZG9uJ3QgcGFydGljdWxhcmx5 IGxpa2UgYmVpbmcgaW4gdGhlIG1pZGRsZSBvZiBleHRyYW5lb3VzIElFVEYgcG9saXRpY3MuJm5i c3A7IEkgZXhwZWN0IGNvbnRyaWJ1dGlvbnMgdG8gYmUNCiBjb25zaWRlcmVkIG9uIHRoZWlyIG93 biBtZXJpdHMsIGFuZCBub3Qgb24gcGVyc29uYWwgaGlzdG9yeSBvZiB0aGUgcGVyc29uIHdobyBo YWQgdGhlIGlkZWEuJm5ic3A7DQo8L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5EYXZlJ3Mgb3JpZ2lu YWwgZmVlZGJhY2sgdG8gdGhpcyBXRyB3YXMgdmVyeSBtaXNndWlkZWQgYW5kIGhlIGRpZG4ndCBo YXZlIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgd29ya2luZyBncm91cC4mbmJzcDsgU29tZSBvZiBo aXMgbW9yZSByZWNlbnQgaWRlYXMgc2VlbSB2ZXJ5IHVzZWZ1bCwgd2l0aG91dCBzb21lIG9mIHRo ZSZuYnNwO3ByZWNvbmNlcHRpb25zIHRoZSBXRyBoYXMgaGFkLCZuYnNwO2FuZCB2ZXJ5IG11Y2gg YWxpZ25lZCB3aXRoIHRoZSByZWNlbnQgZGlzY3Vzc2lvbg0KIG9mIHRoZSB3b3JraW5nIGdyb3Vw LiZuYnNwOyBUaGlzIHZlcnktbXVjaC1yZXZpc2VkIGRvY3VtZW50IGNvbnRhaW5zIGxvdHMgb2Yg aGlzIHRoaW5raW5nLCBzbyBpdCBzZWVtZWQgb25seSBmYWlyIHRvIGFkZCBoaXMgbmFtZS4mbmJz cDsgQWJlbCBhbmQgSSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgdGhpcyBpcyBhIGRlY2VudCBwcm9w b3NhbCwgdGhvdWdoIHdlIHJlYWxpemUgdGhhdCB0aGUgV0cgaGFkIGludGVuZGVkIHRvIHdhaXQg dG8gcG9zdCBhbm90aGVyIGRvY3VtZW50LA0KIGFuZCB3ZSByZWFsaXplIHRoYXQgdGhlIGNoYW5n ZXMgYXJlIGJpZyBlbm91Z2ggdG8gd2FycmFudCBmdXJ0aGVyIHJldmlldy48L3A+DQo8cD4mbmJz cDs8L3A+DQo8cD5XZSdyZSB0cnlpbmcgaGFyZCwgYnV0IHdlJ3JlIGdvaW5nIHRvIG1ha2UgbWlz dGFrZXMuPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9wPg0K PHA+Jm5ic3A7PC9wPg0KPHA+SSB3aWxsIGVuZGVhdm9yIHRvIHJlY3RpZnkgYW55IHByb2NlZHVy YWwgZXJyb3JzLCBidXQsIHNpbmNlIHRoZSBpZGVhcyBhcmUgdmlzaWJsZSBhdCB0aGUgbW9tZW50 LCBJJ2QgYXBwcmVjaWF0ZSBhbnkgY29tbWVudHMgb24gdGhlIGlkZWFzIGluIHRoZSZuYnNwO21p cy1wb3N0ZWQgZG9jdW1lbnQuJm5ic3A7IElmIG5lY2Vzc2FyeSwgcGxlYXNlIHByZXRlbmQgdGhh dCB0aGUgYWRkaXRpb25hbCBuYW1lcyBhcmUgYWJzZW50LjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxw Pi1TaGF3bjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPi0tT24gVHVlc2RheSwgSmFudWFyeSAyNSwg MjAxMSAxMTowNiAmIzQzOzAwMDAgQWxleGV5IE1lbG5pa292PGJyPg0KJmx0O2FsZXhleS5tZWxu aWtvdiBhdCBpc29kZS5jb20mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgSW50ZXJuZXQtRHJh ZnRzIGF0IGlldGYub3JnIHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmU8YnI+DQomZ3Q7Jmd0OyBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlPGJyPg0KJmd0OyZndDsgRW1haWwgQWRkcmVzcyBJbnRlcm5hdGlvbmFsaXphdGlvbiBXb3Jr aW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSW50ZXJuYXRpb25hbGl6ZWQgRW1haWwgSGVhZGVyczxicj4N CiZndDsmZ3Q7IEF1dGhvcihzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6 Jm5ic3A7IC4gWWFuZywgZXQgYWwuPGJyPg0KJmd0OyZndDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM1Ymlz LTA4LnR4dDxicj4NCiZndDsmZ3Q7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMTI8YnI+DQomZ3Q7Jmd0OyBEYXRlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogMjAxMS0wMS0yNDxicj4NCiZndDsuLi48YnI+DQomZ3Q7IFRoaXMgdmVyc2lvbiBj b250YWlucyBjaGFuZ2VzIHRoYXQgYXJlIG5vdCB5ZXQgb2ZmaWNpYWxseTxicj4NCiZndDsgYWdy ZWVkIGJ5IHRoZSBXRyBhbmQgYWxzbyBpbmNsdWRlcyBjaGFuZ2VzIHRoYXQgd2VyZW4ndCBldmVu PGJyPg0KJmd0OyBkaXNjdXNzZWQgaW4gdGhlIFdHLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdv dWxkIGFzayBlZGl0b3JzIHRvIHJvbGxiYWNrIHRoZSBjaGFuZ2VzLCB1bmxlc3MgY2hhaXJzPGJy Pg0KJmd0OyB0ZWxsIG1lIHRoYXQgdGhpcyB2ZXJzaW9uIHdhcyBhY3R1YWxseSBhdXRob3JpemVk IGJ5IGF0IGxlYXN0PGJyPg0KJmd0OyBvbmUgb2YgdGhlbS48YnI+DQo8YnI+DQpBdCBsZWFzdCB0 aGlzIGNvLWNoYWlyIHdhcyBhcyBzdXJwcmlzZWQgYXMgeW91IHdlcmUuJm5ic3A7IEkgdGhvdWdo dDxicj4NCndlIGhhZCBhbiBhZ3JlZW1lbnQgdGhhdCBubyBtb3JlIGRyYWZ0cyB3ZXJlIHRvIGJl IHBvc3RlZDxicj4NCndpdGhvdXQgYW4gb2ZmaWNpYWwgYW5ub3VuY2VtZW50IG9mIGNvbnNlbnN1 cyBvbiB0aGUgcG9pbnRzPGJyPg0KY292ZXJlZC4mbmJzcDsgSSdtIGFzc3VtaW5nIHRoYXQgSm9z ZXBoIHdpbGwgc3RhcnQgcG9zdGluZyBzdWNoPGJyPg0KYW5ub3VuY2VtZW50cyByZWxhdGl2ZWx5 IHNvb24sIGJ1dCBJIGhhdmVuJ3Qgc2VlbiB0aGVtLjxicj4NCjxicj4NClRoaXMgaXMgcGVyaGFw cyBhbHNvIGFuIGFwcHJvcHJpYXRlIHRpbWUgdG8gcmVtaW5kIGV2ZXJ5b25lIHRoYXQ8YnI+DQpF ZGl0b3JzIGFyZSBhcHBvaW50ZWQgYnkgV0cgQ2hhaXJzIHdpdGggdGhlIGFkdmljZSBhbmQgY29u c2VudDxicj4NCm9mIEFEcywgbm90IGJ5IG90aGVyIGVkaXRvcnMuPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IGpvaG48YnI+DQo8YnI+DQo8L3A+DQo8cD4mbmJzcDs8L3A+DQo8ZGl2IHN0 eWxlPSJGT05ULUZBTUlMWTogVGFob21hOyBGT05ULVNJWkU6IDEzcHgiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LVNoYXduPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb2RlMjAwMCI+76Oi 76OQ76On76ObIO+jou+jo++jl++jlO+jmTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5odHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E14011F8737B524BB564B05FF748464A11C702EATK5EX14MBXC133r_-- From klensin@jck.com Tue Jan 25 09:13:53 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 AD5DF3A6835 for ; Tue, 25 Jan 2011 09:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY5x1uxehkwY for ; Tue, 25 Jan 2011 09:13:52 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 785CD3A6817 for ; Tue, 25 Jan 2011 09:13:52 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PhmVY-00039y-6f; Tue, 25 Jan 2011 12:16:44 -0500 Date: Tue, 25 Jan 2011 12:16:43 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] The -08 draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 17:13:53 -0000 --On Tuesday, January 25, 2011 16:22 +0000 Shawn Steele wrote: > This error was unintentional and the result of a > miscommunication between myself and Yang. It can be rolled > back, (is that something I can do or does Abel need to do it?) > although now I suppose the ideas are out there. > > This document was intended to be offered as a possible > simplification that might resolve some of the concerns that > the working group has. IMO, it serves the intent of what > we've been trying to do. You'll recognize some of the text as > Dave's wording, and the additional names were not > intentionally added to avoid the processes, but was rather an > unfortunate error and misunderstanding. Shawn, To clarify this situation from my point of view -- Alexey and/or Joseph may feel differently -- there are two very separate sets of issues here: One was an explicit instruction to the author group -- from Alexey, Joseph, and myself-- to avoid posting new drafts until after Joseph announced decisions about the consensus calls. The reason for that instruction, which I think we explained at the time, was simply to avoid confusion in the WG about competing drafts, what text was assumed to represent consensus and what was draft text for consideration, what the relationship was between suggestions on the list and text in the drafts, etc. Those goals derive simply from a desire to clearly identify points of agreement and disagreement and make rapid progress. They have little or nothing to do with IETF-specific procedures although the ability and authority to give that sort of direction and expect it to be followed is integral to the ability of WG Chairs to manage WGs (and to ADs to manage the WGs and/or the Chairs). Anyone in the author group (or anyone in the WG) who didn't like those instructions was free to initiate a discussion with the co-Chairs or the AD, including filing an appeal if the disagreement could not be resolved. The second group of issues may or may not be tied up with subtle IETF procedures, whatever you believe or have been told about personal histories, etc. While some reactions along the lines of that second group of issues may be inevitable --we are, after all, dealing with people here-- I believe that the reactions you saw from Alexey and myself this morning were strictly derived from that first group and the desire to keep the WG moving forward rather than having it distracted by confusion about consensus, side-issues, competing drafts that address different topics, etc. At this point, I believe that it would be helpful if whomever of you or Abel did the actual posting were to drop a note to the Secretariat (at internet-drafts@ietf.org) indicating that the draft was posted by mistake and asking that it be taken down. Please copy Joseph, Alexey, and myself -- it will save time. Beyond that, I strongly recommend that we just move on to announcements about consensus, new drafts based on those announcements (which, if Joseph concludes the WG has reached consensus on the subject, should include these ABNF changes to 5335bis and corresponding changes to 5336bis), and then seeing if the WG is enough in agreement with those new drafts to progress them to the IESG. I see that as the fastest path to getting these documents finished and approved -- a goal on which I hope we all still agree. If you disagree with that as a strategy, we should discuss it --ideally on the WG list rather than a series of private discussions or negotiations-- rather than doing anything that appears to be preemptive (whether that was the intent or not). best, john From abelyang@twnic.net.tw Tue Jan 25 18:04:21 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 AF5333A6902 for ; Tue, 25 Jan 2011 18:04:21 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUfyAn5mYmcY for ; Tue, 25 Jan 2011 18:04:20 -0800 (PST) Received: from twnic.net.tw (unknown [IPv6:2001:288:4:1:21e:8cff:fe22:a99d]) by core3.amsl.com (Postfix) with ESMTP id 0D3023A68E7 for ; Tue, 25 Jan 2011 18:04:19 -0800 (PST) Received: from abelnb2 (pc094.twnic.net.tw [211.72.211.94]) by twnic.net.tw (8.14.3/8.14.3) with SMTP id p0Q27BUU021635; Wed, 26 Jan 2011 10:07:12 +0800 Message-ID: <41D675FCC9C749E6B7F963D7A55FEBD1@abelnb2> From: "Abel" To: "Alexey Melnikov" , References: <20110125030002.22957.27954.idtracker@localhost> <4D3EAEC6.20701@isode.com> In-Reply-To: <4D3EAEC6.20701@isode.com> Date: Wed, 26 Jan 2011 10:07:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3502.922 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3502.922 X-Scanned-By: MIMEDefang 2.67 on 211.72.210.250 Subject: Re: [EAI] I-D Action:draft-ietf-eai-rfc5335bis-08.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: Wed, 26 Jan 2011 02:04:21 -0000 Dear Alexey, I am very sorry that I updated the -08 draft yesterday directly and not authorized by chairs or your review at this stage. I apologized to you, chairs, and everyone affected by this in this working group. You must have been disappointed by my mistake. Hope that we can kindly solve this problem Shawn and I agreed to rollback, and Shawn have sent a rollback request. Again, we want to say sorry to each of you sincerely. Yours truly, Abel -----原始郵件----- From: Alexey Melnikov Sent: Tuesday, January 25, 2011 7:06 PM To: ima@ietf.org Subject: Re: [EAI] I-D Action:draft-ietf-eai-rfc5335bis-08.txt Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Email Address Internationalization Working >Group of the IETF. > > > Title : Internationalized Email Headers > Author(s) : . Yang, et al. > Filename : draft-ietf-eai-rfc5335bis-08.txt > Pages : 12 > Date : 2011-01-24 > >Internet mail was originally limited to 7-bit ASCII. Recent >enhancements support Unicode's UTF-8 encoding in portions of a >message. Full internationalization of electronic mail requires >additional enhancement, including support for UTF-8 in user-oriented >header fields, such as in the To, From, and Subject fields. This >document specifies an enhancement to Internet mail that permits >native UTF-8 support in the header and body of a message. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-08.txt > This is not cool. I didn't authorize this version, I don't believe chairs have authorized it either. This version contains changes that are not yet officially agreed by the WG and also includes changes that weren't even discussed in the WG. I would ask editors to rollback the changes, unless chairs tell me that this version was actually authorized by at least one of them. Thanks, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From yaojk@cnnic.cn Wed Jan 26 01:19:50 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 132223A63D2 for ; Wed, 26 Jan 2011 01:19:50 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[AWL=0.644, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBJuRb2TKluX for ; Wed, 26 Jan 2011 01:19:49 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id DD8243A63EC for ; Wed, 26 Jan 2011 01:19:47 -0800 (PST) Received: (eyou send program); Wed, 26 Jan 2011 17:22:44 +0800 Message-ID: <496033764.29055@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, 26 Jan 2011 17:22:44 +0800 Message-ID: From: "Jiankang YAO" To: , "ietf-eai" References: <4D370D51.7060801@bbiw.net> <495568295.28005@cnnic.cn> Date: Wed, 26 Jan 2011 17:23:29 +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] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 09:19:50 -0000 DQphZnRlciByZWFkaW5nIGl0IGFuZCB0aGUgZm9sbG93aW5nIGRpc2N1c3Npb24sDQoNCm15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCANCg0KUkZDNTMzNWJpcyBuZWVkIHRoZSBuZXcgbWV0YWxhbmd1 YWdlIG1vZGVsOw0KIA0KUkZDNTMzNmJpcyBjYW4gc3RpbGwga2VlcCB0aGUgY3VycmVudCBtZXRh bGFuZ3VhZ2UgbW9kZWwuDQoNCklzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCg0KDQoNCkpp YW5rYW5nIFlhbw0KDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJE YXZlIENST0NLRVIiIDxkaGMyQGRjcm9ja2VyLm5ldD4NClRvOiAiaWV0Zi1lYWkiIDxpbWFAaWV0 Zi5vcmc+DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjEsIDIwMTEgODowNCBBTQ0KU3ViamVjdDog W0VBSV0gUHJvcG9zYWwgZm9yIEFsdGVybmF0ZSBBQk5GICh3YXM6IENvbnNlbnN1cyBJc3N1ZSAj NjogY3VycmVudCBtZXRhbGFuZ3VhZ2UgbW9kZWwgYWNjZXB0YWJsZT8pDQoNCg0KPiANCj4gRm9s a3MsDQo+IA0KPiANCj4gVGhlIGFuc3dlciB0byBjb25zZW5zdXMgY2FsbCBxdWVzdGlvbiA2IHNo b3VsZCBiZSAnbm8nLg0KPiANCj4gDQo+IE5lZCBGcmVlZCwgUGV0ZSBSZXNuaWNrIGFuZCBJIGhh dmUgYmVlbiBkaXNjdXNzaW5nIHRoZSB3b3JraW5nIGdyb3VwJ3MgYmFzaWMNCj4gbW9kZWwgZm9y IGhhbmRsaW5nIFVURi04IHdpdGhpbiBhIGxlZ2FjeSwgNy1iaXQgd29ybGQuIFRoZSBjdXJyZW50 IGFwcHJvYWNoIGlzDQo+IGNlcnRhaW5seSBpbiBsaW5lIHdpdGggdGhlIGxvbmctc3RhbmRpbmcg SUVURiBwcmVzc3VyZSAoZGVtYW5kKSB0byBoYXZlIGNoYW5nZXMNCj4gb2YgYW4gZXhpc3Rpbmcg c3lzdGVtIGJlIGRlc2lnbmVkIGluIGEgd2F5IHRoYXQgcHJvdGVjdHMgYW5kIGludGVyd29ya3Mg d2l0aCB0aGUNCj4gaW5zdGFsbGVkIGJhc2UsIHN1Y2ggYXMgYnkgbm90IGRhbWFnaW5nIGEgbGVn YWN5IHN5c3RlbSB0aGF0IHJlY2VpdmVzIGFuDQo+IGVuaGFuY2VkIGZvcm0gb2YgZGF0YS4gQW5k IGluZGVlZCwgdGhlIHdvcmtpbmcgZ3JvdXAncyBTTVRQIGV4dGVuc2lvbiBpcyBhbg0KPiBleGFt cGxlIG9mIGtlZXBpbmcgdGhlIG5ldyBvYmplY3QgYXdheSBmcm9tIGxlZ2FjeS1vbmx5IHN5c3Rl bXMuDQo+IA0KPiBIb3dldmVyLCB0aGUgbW9kZWwgdXNlZCBpbiB0aGUgY2FzZSBvZiBSRkMgNTMz NSAtLSB1c2luZyBuZXcgc3ludGF4IGVsZW1lbnRzDQo+IGluc3RlYWQgb2YgZXh0ZW5kaW5nIG9s ZCBvbmVzIC0tIGhhcyBwcm9kdWNlZCBxdWl0ZSBhIGJpdCBvZiBjb21wbGV4aXR5LiBJbiB0aGlz DQo+IGNhc2UsIHdlIGJlbGlldmUgdGhlIGNvbXBsZXhpdHkgaXMgbm90IHNlcnZpbmcgdGhlIHdv cmtpbmcgZ3JvdXAncyBnb2FscyBhbGwNCj4gdGhhdCB3ZWxsLg0KPiANCj4gVGhhdCBsZWFkcyB1 cyB0byBtYWtlIGEgc29tZXdoYXQgc3VycHJpc2luZyBzdWdnZXN0aW9uIHRvIHNpbXBsaWZ5DQo+ IHRoaW5ncyBjb25zaWRlcmFibHkuIFRoZSBwcmVtaXNlIGJlaGluZCB0aGUgc3VnZ2VzdGlvbiBp cyB0aGF0IHRoZQ0KPiB3b3JsZCByZWFsbHkgZG9lcyBoYXZlIGV4dGVuc2l2ZSBpbmZyYXN0cnVj dHVyZSBmb3IgVVRGLTggYWxyZWFkeSBhbmQNCj4gdGhhdCB3ZSBjYW4gcmVseSBvbiBpdC4NCj4g DQo+ICAgICAgICAgU28sIHRoZSBjb3JlIHN1Z2dlc3Rpb24gaXMgdG8gaGF2ZSB0aGUgcmV2aXNp b24gZm9jdXMNCj4gICAgICAgICBvbmx5IG9uIHRoZSBleGlzdGluZywgYmFzaWMgNTMyMiBBQk5G IGNvbnN0cnVjdHMgYW5kDQo+ICAgICAgICAgc2ltcGx5IGF1Z21lbnQgdGhlbSB0byBzdXBwb3J0 IFVURi04Lg0KPiANCj4gICAgICAgICBUaGlzIHdvdWxkIGNyZWF0ZSB3aGF0IGVzc2VudGlhbGx5 IHdvdWxkIGJlIGFuIGluZGVwZW5kZW50LA0KPiAgICAgICAgIFVURi04IGVtYWlsIHdvcmxkLg0K PiANCj4gICAgICAgICBJbnRlcndvcmtpbmcgd2l0aCB0aGUgbGVnYWN5IGVtYWlsIHdvcmxkIHN0 aWxsIG5lZWRzIHRvIGJlDQo+ICAgICAgICAgc3BlY2lmaWVkLCBidXQgaXQgc2hvdWxkIGJlIGRv bmUgc2VwYXJhdGVseS4NCj4gDQo+IFdpdGggdGhlIGNhdmVhdCB0aGF0IElETiBoYW5kbGluZyBp biB0aGUgc3BlYyBzdGlsbCBuZWVkcyB0byBiZSBkb25lLCB0aGlzIA0KPiBwcm9kdWNlcyBhIGNh bmRpZGF0ZSB0byByZXBsYWNlIGZvciBTZWN0aW9uIDQuMywgNC40IGFuZCA0LjUgZnJvbSB0aGUg ZXhpc3RpbmcgDQo+IGRyYWZ0Og0KPiANCj4gDQo+ICAgICBbWyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IA0KPiBUaGlzIHNlY3Rpb24gc3BlY2lmaWVz IFVURi04IGVuaGFuY2VtZW50cyBmb3IgdGhlIGhlYWRlciBvZiBhbg0KPiBJbnRlcm5ldCBNYWls IG1lc3NhZ2UsIGFzIGRlZmluZWQgaW4gW1JGQzUzMjJdLg0KPiANCj4gQUJORiB1c2VkIGluIHRo aXMgc2VjdGlvbiBpcyB0YWtlbiBmcm9tIHRoYXQgc3BlY2lmaWNhdGlvbiBhbmQgdGhlDQo+IEFC TkYgc3BlY2lmaWNhdGlvbi4NCj4gDQo+IFRoaXMgc3BlY2lmaWNhdGlvbiByZXRhaW5zIHRoZSBb UkZDNTMyMl0gcnVsZXMgZm9yIGRlZmluaW5nIGhlYWRlcg0KPiBmaWVsZCBuYW1lcy4gVGhlIGJv ZGllcyBvZiBoZWFkZXIgZmllbGRzIGFyZSBhbGxvd2VkIHRvIGNvbnRhaW4gVVRGLTgNCj4gY2hh cmFjdGVycywgYnV0IHRoZSBoZWFkZXIgZmllbGQgbmFtZXMgdGhlbXNlbHZlcyBtdXN0IGNvbnRh aW4gb25seQ0KPiBBU0NJSSBjaGFyYWN0ZXJzLg0KPiANCj4gVGhlIGZvbGxvd2luZyBydWxlcyBl eHRlbmQgdGhlIGNvcnJlc3BvbmRpbmcgcnVsZXMgaW4gW1JGQzUzMjJdIGFuZA0KPiBbUkZDNTIz NF0gaW4gb3JkZXIgdG8gYWxsb3cgYWRkaXRpb25hbCBVbmljb2RlIGNoYXJhY3RlcnMuDQo+IA0K PiAgICBWQ0hBUiAgID0vICBVVEY4LW5vbi1hc2NpaQ0KPiANCj4gICAgY3RleHQgICA9LyAgVVRG OC1ub24tYXNjaWkNCj4gDQo+ICAgIGF0ZXh0ICAgPS8gIFVURjgtbm9uLWFzY2lpDQo+IA0KPiAg ICBxdGV4dCAgID0vICBVVEY4LW5vbi1hc2NpaQ0KPiANCj4gICAge3sgaG93IHRvIGFkZCBJRE4g dG8gdGhpcz8gfX0NCj4gICAgZG9tYWluICA9ICAgZG90LWF0b20gLyBkb21haW4tbGl0ZXJhbCAv IG9icy1kb21haW4NCj4gDQo+IFRoaXMgbWVhbnMgdGhhdCBhbGwgdGhlIFtSRkM1MzIyXSBjb25z dHJ1Y3RzIHRoYXQgYnVpbGQgdXBvbiB0aGVzZQ0KPiB3aWxsIHBlcm1pdCBVVEYtOCBjaGFyYWN0 ZXJzLCBpbmNsdWRpbmcgY29tbWVudHMgYW5kIHF1b3RlZCBzdHJpbmdzLg0KPiANCj4gICAgPGZp ZWxkLW5hbWU+DQo+IA0KPiAgICAgICAgICAgW1JGQzUzMjJdIGhhcyB0aGUgcnVsZSA8ZmllbGQt bmFtZT4gd2hpY2ggc3BlY2lmaWVzDQo+IHBlcm1pc3NpYmxlIG5hbWVzIGZvciB1c2VyLWRlZmlu ZWQgaGVhZGVyIGZpZWxkcy4gVGhlIGN1cnJlbnQNCj4gc3BlY2lmaWNhdGlvbiBkZWZpbmVzIG5v IGNoYW5nZXMgdG8gdGhhdCBydWxlLg0KPiANCj4gICAgPG1zZy1pZD4NCj4gDQo+ICAgICAgICAg ICBUaGlzIEFCTkYgZW5hYmxlcyBNZXNzYWdlLUlEIHN0cmluZ3MgdG8gYmUgZnVsbCBVVEYtOC4N Cj4gSG93ZXZlciB0aGUgc3BlY2lmaWNhdGlvbiBkaXJlY3RzIHRoYXQgTWVzc2FnZS1JRCBzdHJp bmdzIFNIT1VMRCBiZQ0KPiByZXN0cmljdGVkIHRvIEFTQ0lJLg0KPiANCj4gDQo+ICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gXV0NCj4gDQo+IA0KPiANCj4gDQo+ IFRoZSBTTVRQIGV4dGVuc2lvbiBpcyBlc3NlbnRpYWwgdG8gdGhpcywgb2YgY291cnNlLiBJbiBh ZGRpdGlvbiBpdCdzIHdvcnRoDQo+IHJlcGVhdGluZyB0aGF0IHNwZWNpZmljYXRpb24gb2YgVVRG OC10by1BU0NJSSBnYXRld2F5aW5nIGlzIHN0aWxsIG5lZWRlZCwgYnV0IHdlDQo+IHN1Z2dlc3Qg aXQgYmUgbW92ZWQgdG8gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLg0KPiANCj4gU2luY2UgdGhl c2UgYXJlIHZlcnkgYmFzaWMgQUJORiBydWxlcywgY2hhbmdlcyB0byB0aGVtIGhhdmUgYW4NCj4g ZXh0ZW5zaXZlIGVmZmVjdCB0aGF0IGlzIG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzLiAgU28gdG8g YWlkIHRoZQ0KPiByZWFkZXIsIGl0J3Mgd29ydGggYWRkaW5nIGFuIGFwcGVuZGl4IHRoYXQgbGlz dHMgdGhlIG90aGVyIEFCTkYgb2YNCj4gUkZDNTMyMiB0aGF0IHdvdWxkIGJlIGFmZmVjdGVkIChp Z25vcmluZyB0aGUgb2JzLSBydWxlcykuLi4NCj4gDQo+IA0KPiANCj4gDQo+ICAgICAgW1sgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEEuIENoYW5nZXMgdG8g c3VwcG9ydCBVVEYtOA0KPiANCj4gVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGEgYmFzaWMgYXVkaXQg b2YgdGhlIHBsYWNlcyBpbiBhIG1lc3NhZ2UgdGhhdA0KPiBub3cgY2FuIHBlcm1pdCBVVEYtOCBy YXRoZXIgdGhhbiBiZWluZyByZXN0cmljdGVkIHRvIEFTQ0lJLCBiYXNlZCBvbg0KPiB0aGUgY2hh bmdlcyB0byB1bmRlcmx5aW5nIEFCTkYuIFRoZSBhdWRpdCBpZ25vcmVzIHJ1bGVzIGZvciAib2Jz b2xldGUiDQo+IGNvbnN0cnVjdHMgaW4gUkZDIDUzMjIuDQo+IA0KPiBWQ0hBUjoNCj4gICAgIHF1 b3RlZC1wYWlyLCB1bnN0cnVjdHVyZWQNCj4gICAgID4gY2NvbnRlbnQsIHFjb250ZW50DQo+ICAg ICA+IGNvbW1lbnQsIHF1b3RlZC1zdHJpbmcNCj4gICAgID4gd29yZCwgbG9jYWwtcGFydA0KPiAg ICAgPiBwaHJhc2UNCj4gICAgID4gZGlzcGxheS1uYW1lLCBrZXl3b3Jkcw0KPiANCj4gICAgID4g bmFtZS1hZGRyDQo+ICAgICA+IG1haWxib3gsIGdyb3VwDQo+ICAgICA+IGFkZHJlc3MNCj4gDQo+ ICAgICA+IGFkZHJlc3MtbGlzdCwgbWFpbGJveC1saXN0DQo+IA0KPiAgICAgPiByZWNlaXZlZC10 b2tlbiwgcmVjZWl2ZWQNCj4gDQo+ICAgICA+IGZyb20sIHNlbmRlcg0KPiAgICAgPiByZXBseS10 bywgdG8sIGNjLCBiY2MsIHJlc2VudC0qDQo+IA0KPiAgICAgPiBzdWJqZWN0LCBjb21tZW50cywg b3B0aW9uYWwtZmllbGQNCj4gDQo+IA0KPiBjdGV4dDoNCj4gICAgIGNjb250ZW50ID4gY29tbWVu dCA+IGNvbW1lbnRzDQo+IA0KPiANCj4gYXRleHQ6DQo+ICAgICBhdG9tLCBkb3QtYXRvbS10ZXh0 DQo+IA0KPiAgICAgPiBtc2ctaWQNCj4gDQo+ICAgICA+IGxvY2FsLXBhcnQsIGRvbWFpbg0KPiAg ICAgPiBhZGRyLXNwZWMNCj4gICAgID4gbWFpbGJveA0KPiANCj4gDQo+IHF0ZXh0Og0KPiAgICAg cWNvbnRlbnQgcXVvdGVkLXN0cmluZw0KPiANCj4gDQo+ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gXV0NCj4gDQo+IA0KPiAtLSANCj4gDQo+ICAgRGF2ZSBDcm9j a2VyDQo+ICAgQnJhbmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nDQo+ICAgYmJpdy5uZXQNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxp bmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pbWE= From klensin@jck.com Wed Jan 26 05:57:20 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 8A28C3A69BE for ; Wed, 26 Jan 2011 05:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnkbfeIO1f9h for ; Wed, 26 Jan 2011 05:57:19 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A471E3A69BA for ; Wed, 26 Jan 2011 05:57:19 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pi5uw-000BGr-6P; Wed, 26 Jan 2011 09:00:14 -0500 Date: Wed, 26 Jan 2011 09:00:13 -0500 From: John C Klensin To: Jiankang YAO , dcrocker@bbiw.net, ietf-eai Message-ID: In-Reply-To: <496033764.29055@cnnic.cn>, References: <4D370D51.7060801@bbiw.net> <495568295.28005@cnnic.cn> <496033764.29055@cnnic.cn>, 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] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:57:20 -0000 --On Wednesday, January 26, 2011 17:23 +0800 Jiankang YAO wrote: > > after reading it and the following discussion, > > my understanding is that > > RFC5335bis need the new metalanguage model; > > RFC5336bis can still keep the current metalanguage model. > > Is my understanding correct? Speaking as an individual: having different metalanguage models in the two documents would be a bad idea and certain to make things harder for readers. If we are going to change the model or terminology in both documents, both (and 5337bis as appropriate) need to change. Speaking as co-chair: please see my note to the DT/author's list yesterday (for WG members not on that list, it summarized a plan, discussed at around the beginning of this consensus call cycle, for being sure drafts are aligned with announced WG consensus and coordinated wrt this sort of "changes to one require changes to others" situation). john From dhc2@dcrocker.net Wed Jan 26 06:57:48 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 A2E903A67B1 for ; Wed, 26 Jan 2011 06:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lJ3xEGz3Uth for ; Wed, 26 Jan 2011 06:57:47 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 034733A67B0 for ; Wed, 26 Jan 2011 06:57:46 -0800 (PST) Received: from [192.168.1.3] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0QF0dQ5017304 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 07:00:44 -0800 Message-ID: <4D40370A.7090405@dcrocker.net> Date: Wed, 26 Jan 2011 07:00:26 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jiankang YAO References: <4D370D51.7060801@bbiw.net> <495568295.28005@cnnic.cn> <496033764.29055@cnnic.cn> In-Reply-To: <496033764.29055@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, 26 Jan 2011 07:00:44 -0800 (PST) Cc: ietf-eai Subject: Re: [EAI] Proposal for Alternate ABNF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 14:57:48 -0000 On 1/26/2011 1:23 AM, Jiankang YAO wrote: > RFC5335bis need the new metalanguage model; > > RFC5336bis can still keep the current metalanguage model. > > Is my understanding correct? The current proposal is for changes to RFC5335bis. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@bbiw.net Wed Jan 26 10:27:17 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 4B8013A6834 for ; Wed, 26 Jan 2011 10:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.83 X-Spam-Level: X-Spam-Status: No, score=-6.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3OuTxpMaWAw for ; Wed, 26 Jan 2011 10:27:16 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 2D6603A67D8 for ; Wed, 26 Jan 2011 10:27:16 -0800 (PST) Received: from [192.168.1.3] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0QIU81a025146 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 10:30:14 -0800 Message-ID: <4D406823.1000705@bbiw.net> Date: Wed, 26 Jan 2011 10:29:55 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jiankang YAO References: <4D370D51.7060801@bbiw.net> <495568295.28005@cnnic.cn> <496033764.29055@cnnic.cn> In-Reply-To: <496033764.29055@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, 26 Jan 2011 10:30:15 -0800 (PST) Cc: ietf-eai Subject: [EAI] RFC5336bis (was Re: Proposal for Alternate ABNF) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:27:17 -0000 On 1/26/2011 1:23 AM, Jiankang YAO wrote: > my understanding is that > > RFC5335bis need the new metalanguage model; > > RFC5336bis can still keep the current metalanguage model. My other response to you query was to clarify what has so far been presented. This note is meant to cover the topic more broadly: 1. Two documents that share normative content should not repeat that content. One should cite the relevant portion(s) of the other. This was discussed earlier. Redundancy invites divergence and disparity. 2. The proposal for changes to RFC5336bis are being put forward first because it specifies the email object. It is therefore the core specification, IMO, and needs to be clarified first. 3. Issues with the ABNF in rfc5336bis are the same as with rfc5335bis. As the group settles on the revisions for the ABNF in rfc5335bis, then rfc5336bis should be modified to cite that ABNF. 4. The two of us who reviewed rfc5336bis made various recommendations. The handling of those is, I believe, separate from concerns about rfc5335bis. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yaojk@cnnic.cn Thu Jan 27 21:48:12 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 CFB543A6BB1 for ; Thu, 27 Jan 2011 21:48:12 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.12 X-Spam-Level: X-Spam-Status: No, score=-98.12 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7l1AVNaeJlg for ; Thu, 27 Jan 2011 21:48:12 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 332233A6BA5 for ; Thu, 27 Jan 2011 21:48:10 -0800 (PST) Received: (eyou send program); Fri, 28 Jan 2011 13:51:08 +0800 Message-ID: <496193868.07942@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, 28 Jan 2011 13:51:08 +0800 Message-ID: <7E64F1D0A89A4F499768E426B1A6741A@LENOVO47E041CF> From: "Jiankang YAO" To: "Dave CROCKER" References: <4D370D51.7060801@bbiw.net> <495568295.28005@cnnic.cn> <496033764.29055@cnnic.cn> <496066617.23897@cnnic.cn> Date: Fri, 28 Jan 2011 13:51:58 +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: ietf-eai Subject: Re: [EAI] RFC5336bis (was Re: Proposal for Alternate ABNF) 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, 28 Jan 2011 05:48:12 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRj cm9ja2VyQGJiaXcubmV0Pg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNj OiAiaWV0Zi1lYWkiIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNywg MjAxMSAyOjI5IEFNDQpTdWJqZWN0OiBSRkM1MzM2YmlzICh3YXMgUmU6IFtFQUldIFByb3Bvc2Fs IGZvciBBbHRlcm5hdGUgQUJORikNCg0KDQo+IA0KLi4uLg0KPiANCj4gICAgMy4gSXNzdWVzIHdp dGggdGhlIEFCTkYgaW4gcmZjNTMzNmJpcyBhcmUgdGhlIHNhbWUgYXMgd2l0aCByZmM1MzM1Ymlz LiAgQXMgDQo+IHRoZSBncm91cCBzZXR0bGVzIG9uIHRoZSByZXZpc2lvbnMgZm9yIHRoZSBBQk5G IGluIHJmYzUzMzViaXMsIHRoZW4gcmZjNTMzNmJpcyANCj4gc2hvdWxkIGJlIG1vZGlmaWVkIHRv IGNpdGUgdGhhdCBBQk5GLg0KPiANCg0KaWYgSSByZW1lbWJlciBpdCBjb3JyZWN0bHksIHlvdSBy ZWNvbW1lbmQgdGhhdCByZmM1MzM2YmlzIHNob3VsZCBub3QgY2l0ZSB0aGUgQUJORiBpbiBSRkM1 MzIyLCBhbmQgc2hvdWxkIGNpdGUgcmZjNTMyMSBvbmx5Lg0KDQpTaW5jZSByZmM1MzM2YmlzIGlz IGV4dGVuc2lvbiBvZiByZmM1MzIxLCBhbmQgcmZjNTMzNWJpcyBpcyBleHRlbnNpb24gb2YgcmZj NTMyMiwNCg0KaXQgaXMgbm90IHZlcnkgcHJvcGVyIHRvIG1pbmdsZSB0aGUgZGVmaW5pdGlvbiBv ZiBBQk5GIGluIHJmYzUzMzViaXMgYW5kIHJmYzUzMzZiaXMuDQoNCg0KdGhlIEFCTkYgaW4gcmZj NTMzNWJpcyAgbWFpbmx5IGZvY3VzIG9uIGVtYWlsIGVudmVsb3A7IHRoZSBBQk5GIGluIHJmYzUz MzZiaXMgbWFpbmx5IGZvY3VzIG9uIGVtYWlsIGhlYWRlcnMuDQoNCnRoZSBzYW1lIG5hbWUgdW5k ZXIgcmZjNTMzNWJpcyBhbmQgcmZjNTMzNmJpcywgcmZjNTMyMSBhbmQgcmZjNTMyMiBtYXkgaGF2 ZSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMuDQoNCmZvciBleGFtcGxlLA0KDQphcyB0aGUgcHJvYmxl bXMgcG9pbnRlZCBvdXQgYnkgQWxleGV5LA0KDQoiDQpkZWZpbml0aW9uIG9mIGRvdC1hdG9tLCBk b21haW4tbGl0ZXJhbCBhbmQgb2JzLWRvbWFpbiBmcm9tIFJGQyA1MzIyIA0KYXJlIGdvaW5nIHRv IGJlIHByb2JsZW1hdGljIGluIFNNVFA6DQoNCiAgIGRvbWFpbi1saXRlcmFsICA9ICAgW0NGV1Nd ICJbIiAqKFtGV1NdIGR0ZXh0KSBbRldTXSAiXSIgW0NGV1NdDQoNCiAgIG9icy1kb21haW4gICAg ICA9ICAgYXRvbSAqKCIuIiBhdG9tKQ0KDQogICBhdG9tICAgICAgICAgICAgPSAgIFtDRldTXSAx KmF0ZXh0IFtDRldTXQ0KDQogICBkb3QtYXRvbS10ZXh0ICAgPSAgIDEqYXRleHQgKigiLiIgMSph dGV4dCkNCg0KICAgZG90LWF0b20gICAgICAgID0gICBbQ0ZXU10gZG90LWF0b20tdGV4dCBbQ0ZX U10NCg0KYmVjYXVzZSBvZiBDRldTLg0KDQoiDQoNCg0Kc28gSSB0aGluayB0aGF0IGZvbGxvd2lu ZyB0aGUgQUJORiBkZWZpbml0aW9uIG1vZGUgb3IgcGF0dGVybiBpbiByZmM1MzIxIGFuZCByZmM1 MzIyIGlzIGEgYmV0dGVyIHdheSB0byBzb2x2ZSB0aGUgQUJORiBpc3N1ZXMgaW4gcmZjNTMzNWJp cyBhbmQgcmZjNTMzNmJpcy4gDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0K From jyee@ca.afilias.info Fri Jan 28 08:19:49 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 D85AC3A67C3 for ; Fri, 28 Jan 2011 08:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbKDu9grQL2S for ; Fri, 28 Jan 2011 08:19:47 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id B0CDD3A68CB for ; Fri, 28 Jan 2011 08:19:47 -0800 (PST) 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 1Pir66-0005yl-3l for ima@ietf.org; Fri, 28 Jan 2011 16:22:54 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Pir66-0000AM-3P for ima@ietf.org; Fri, 28 Jan 2011 16:22:54 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 11:22:53 -0500 Message-Id: <6F2D0009-68C4-452B-BACA-D78EB80BB6C1@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Result on Issue #7 - change definition of uAtom? 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, 28 Jan 2011 16:19:49 -0000 All, Following responses, this issue was overtaken by Dave Crocker's = proposal. For more details on Dave's proposal, please refer to the = message on 'Consensus Result on Issue #6'. Result will be documented at = issue tracker (http://trac.tools.ietf.org/wg/eai/trac/ticket/7) Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph= From jyee@ca.afilias.info Fri Jan 28 08:20:23 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 4D9D93A691E for ; Fri, 28 Jan 2011 08:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pEqHyo8RiNg for ; Fri, 28 Jan 2011 08:20:22 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 153413A68E6 for ; Fri, 28 Jan 2011 08:20:22 -0800 (PST) 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 1Pir6S-0005z5-3U for ima@ietf.org; Fri, 28 Jan 2011 16:23:16 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Pir6R-0000AM-6L for ima@ietf.org; Fri, 28 Jan 2011 16:23:16 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 11:23:15 -0500 Message-Id: <6572700D-8647-4B5F-A277-7F247A1458F5@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Result on Issue #6 - Current metalanguage model acceptable? And Dave Crocker's proposal 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, 28 Jan 2011 16:20:23 -0000 All, Following responses, this issue was overtaken by Dave Crocker's = proposal, and in rough consensus (with huge majority), Dave's proposal = is acceptable by the WG and few works needed (ie. IDN). Note, Dave's proposal is for RFC5335bis rather than RFC5336bis (which is = what's this issue about), discussion will follow on how to adopt it for = RFC5336bis (ie. confirm where contents are shared or different etc) Result will be documented at issue tracker = (http://trac.tools.ietf.org/wg/eai/trac/ticket/6) Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph= From jyee@ca.afilias.info Fri Jan 28 08:22:49 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 22DE63A68E6 for ; Fri, 28 Jan 2011 08:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.24 X-Spam-Level: X-Spam-Status: No, score=-106.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlBCeQrOAlmR for ; Fri, 28 Jan 2011 08:22:48 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 8059D3A6903 for ; Fri, 28 Jan 2011 08:22:46 -0800 (PST) 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 1Pir8z-0001yU-6m for ima@ietf.org; Fri, 28 Jan 2011 16:25:53 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Pir8y-0000GM-6R for ima@ietf.org; Fri, 28 Jan 2011 16:25:53 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 11:25:52 -0500 Message-Id: <4BFC89F3-8035-4100-A244-BE70D15319DE@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Result on Issue #2 - new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis? 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, 28 Jan 2011 16:22:49 -0000 All, Following responses, this issue reached an unanimous consensus that new = parameter to VRFY/EXPN permitted only after EHLO with UTF8SMTPbis. Result will be documented at issue tracker = (http://trac.tools.ietf.org/wg/eai/trac/ticket/2) Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph From jyee@ca.afilias.info Fri Jan 28 08:24:46 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 5D4293A68C0 for ; Fri, 28 Jan 2011 08:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.242 X-Spam-Level: X-Spam-Status: No, score=-106.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTL8AOTxGi4j for ; Fri, 28 Jan 2011 08:24:45 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 9B77B3A68F9 for ; Fri, 28 Jan 2011 08:24:45 -0800 (PST) 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 1PirAu-000659-3c for ima@ietf.org; Fri, 28 Jan 2011 16:27:52 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PirAu-0000Ik-3G for ima@ietf.org; Fri, 28 Jan 2011 16:27:52 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 11:27:51 -0500 Message-Id: <282C11A6-361B-4B63-B742-455E2A964F99@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Result on Issue #5 - Keep nested encodings for message/global? 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, 28 Jan 2011 16:24:46 -0000 All, Following responses, this issue reached the consensus of keep the nested = encoding for message/global. 7 people expressed their opinions: keep it:=20 John Klensin Shawn Steele John Levine Charles Lindsey Tony Hansen remove it: Dave Crocker undecided: Barry Leiba Result will be documented at issue tracker = (http://trac.tools.ietf.org/wg/eai/trac/ticket/5) Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph= From jyee@ca.afilias.info Fri Jan 28 08:25:45 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 F1D483A68CB for ; Fri, 28 Jan 2011 08:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, 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 RpKzNFg8vHmg for ; Fri, 28 Jan 2011 08:25:44 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 433EF3A68C0 for ; Fri, 28 Jan 2011 08:25:44 -0800 (PST) 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 1PirBq-000232-92 for ima@ietf.org; Fri, 28 Jan 2011 16:28:50 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PirBq-0000Ik-5R for ima@ietf.org; Fri, 28 Jan 2011 16:28:50 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 11:28:50 -0500 Message-Id: <21F50B57-12F4-4435-8F9C-80F004D952BE@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Result on Issue #3 - remove repetition of normative text? 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, 28 Jan 2011 16:25:45 -0000 All, Following responses, this issue reached an unanimous consensus to remove = repetition text from other documents to the extent possible. Result will be documented at issue tracker = (http://trac.tools.ietf.org/wg/eai/trac/ticket/3) Subsequent proposed questions Should the WG develop a template like wording to help referencing? = (YES/NO) If Yes, what should the text be? A separate email will focus on this discussion. Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph From jyee@ca.afilias.info Fri Jan 28 08:37: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 2D9313A68E6 for ; Fri, 28 Jan 2011 08:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.24 X-Spam-Level: X-Spam-Status: No, score=-106.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcHu54Q614yh for ; Fri, 28 Jan 2011 08:37:03 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 6CA103A68FF for ; Fri, 28 Jan 2011 08:36:58 -0800 (PST) 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 1PirMj-0006JW-3E for ima@ietf.org; Fri, 28 Jan 2011 16:40:05 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PirMi-0000f0-5w for ima@ietf.org; Fri, 28 Jan 2011 16:40:04 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 11:40:04 -0500 Message-Id: <35043619-DC64-4245-B024-E6D7DF2ADED8@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 28 Jan 2011 16:37:04 -0000 All, Following responses, this issue reached the consensus to add parameter = on MAIL FROM. The result will be documented at issue tracker = (http://trac.tools.ietf.org/wg/eai/trac/report/1). Subsequent proposed questions=20 1. What is the name of the parameter? 2. Does the parameter have value or not? What kind of value? New issues raised during the discussion 1. There are 2 different ideas of MAIL FROM interaction between MUA and = MTA.=20 1.1 MUA tells MTA that itself is EAI capable, hence all messages run = in "EAI-mode" (MUA always uses the parameter when available) 1.2 MUA tells MTA that the following message needs to run under = EAI-mode (the next message from MUA may not use the parameter, although = both are EAI capable, the interaction and message run under = RFC5321/5322) I will start a new thread for this discussion. =20 Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph= From dhc2@dcrocker.net Fri Jan 28 08:39:08 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 A317B3A68E6 for ; Fri, 28 Jan 2011 08:39:08 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOZ34oPIM1bA for ; Fri, 28 Jan 2011 08:39:07 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id B34383A6830 for ; Fri, 28 Jan 2011 08:39:07 -0800 (PST) Received: from [192.168.1.3] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0SGg89I001430 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 08:42:13 -0800 Message-ID: <4D42F1D7.6060207@dcrocker.net> Date: Fri, 28 Jan 2011 08:41:59 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joseph Yee References: <282C11A6-361B-4B63-B742-455E2A964F99@ca.afilias.info> In-Reply-To: <282C11A6-361B-4B63-B742-455E2A964F99@ca.afilias.info> 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]); Fri, 28 Jan 2011 08:42:13 -0800 (PST) Cc: EAI WG Subject: Re: [EAI] Consensus Result on Issue #5 - Keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jan 2011 16:39:08 -0000 On 1/28/2011 8:27 AM, Joseph Yee wrote: > Following responses, this issue reached the consensus of keep the nested encoding for message/global. > > 7 people expressed their opinions: > keep it: ... > remove it: > Dave Crocker Sorry my response was unclear. I meant that it should be kept, but should be renamed to message/utf8-rfc822. The purpose of renaming is to make it clear that this is a variation of an existing, important message type. In addition "global" is far too generic, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Fri Jan 28 08:42:32 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 C03133A68F5 for ; Fri, 28 Jan 2011 08:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 UheqGnjgZ+8P for ; Fri, 28 Jan 2011 08:42:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id DF8A93A68E1 for ; Fri, 28 Jan 2011 08:42:31 -0800 (PST) Received: from [192.168.1.3] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0SGjC8O001538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 08:45:17 -0800 Message-ID: <4D42F28F.5060403@dcrocker.net> Date: Fri, 28 Jan 2011 08:45:03 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joseph Yee References: <21F50B57-12F4-4435-8F9C-80F004D952BE@ca.afilias.info> In-Reply-To: <21F50B57-12F4-4435-8F9C-80F004D952BE@ca.afilias.info> 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]); Fri, 28 Jan 2011 08:45:17 -0800 (PST) Cc: EAI WG Subject: Re: [EAI] Consensus Result on Issue #3 - remove repetition of normative text? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jan 2011 16:42:32 -0000 On 1/28/2011 8:28 AM, Joseph Yee wrote: > Subsequent proposed questions > Should the WG develop a template like wording to help referencing? (YES/NO) If Yes, what should the text be? > A separate email will focus on this discussion. Excellent idea. Perhaps something like: The details for are covered in . where: x specifies the topic, issue, problem or the like that needs to be highlighted in the current draft; the wording of this characterizes the concern that warrants making the citation. y is as precise a citation as can be provided. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yaojk@cnnic.cn Fri Jan 28 23:11:51 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 D0D993A6A78 for ; Fri, 28 Jan 2011 23:11:47 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.099 X-Spam-Level: X-Spam-Status: No, score=-98.099 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqjiQT9ZikhN for ; Fri, 28 Jan 2011 23:11:43 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 948903A6A63 for ; Fri, 28 Jan 2011 23:11:40 -0800 (PST) Received: (eyou send program); Sat, 29 Jan 2011 15:14:45 +0800 Message-ID: <496285285.11868@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 29 Jan 2011 15:14:45 +0800 Message-ID: <64D9AE6F5FD943C4AAA57FB5E8DAFA0C@LENOVO47E041CF> From: "Jiankang YAO" To: "Joseph Yee" , "EAI WG" References: <496231963.07475@cnnic.cn> Date: Sat, 29 Jan 2011 15:15: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.5994 Subject: Re: [EAI] Consensus Result on Issue #2 - new parameter to VRFY/EXPNonly after EHLO with UTF8SMTPbis? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 07:11:54 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvc2VwaCBZZWUiIDxqeWVl QGNhLmFmaWxpYXMuaW5mbz4NClRvOiAiRUFJIFdHIiA8aW1hQGlldGYub3JnPg0KU2VudDogU2F0 dXJkYXksIEphbnVhcnkgMjksIDIwMTEgMTI6MjUgQU0NClN1YmplY3Q6IFtFQUldIENvbnNlbnN1 cyBSZXN1bHQgb24gSXNzdWUgIzIgLSBuZXcgcGFyYW1ldGVyIHRvIFZSRlkvRVhQTm9ubHkgYWZ0 ZXIgRUhMTyB3aXRoIFVURjhTTVRQYmlzPw0KDQoNCj4gQWxsLA0KPiANCj4gRm9sbG93aW5nIHJl c3BvbnNlcywgdGhpcyBpc3N1ZSByZWFjaGVkIGFuIHVuYW5pbW91cyBjb25zZW5zdXMgdGhhdCBu ZXcgcGFyYW1ldGVyIHRvIFZSRlkvRVhQTiBwZXJtaXR0ZWQgb25seSBhZnRlciBFSExPIHdpdGgg VVRGOFNNVFBiaXMuDQo+IA0KDQoNCnRoZSBuZXcgcGFyYW1ldGVyIGlzIFVURjhTTVRQYmlzPw0K DQpKaWFua2FuZyBZYW8NCg0KPg0KPiBSZXN1bHQgd2lsbCBiZSBkb2N1bWVudGVkIGF0IGlzc3Vl IHRyYWNrZXIgKGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2VhaS90cmFjL3RpY2tldC8y KQ0KPiANCj4gUGxlYXNlIG5vdGlmeSBtZSBvZiBhbnkgZXJyb3JzLCBtaXN1bmRlcnN0YW5kaW5n LCBvciBtaXNzZWQgb3BpbmlvbnMuDQo+IA0KPiBSZWdhcmRzLA0KPiBKb3NlcGgNCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEg bWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ltYQ== From yaojk@cnnic.cn Sat Jan 29 01:32:59 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 762C53A697A for ; Sat, 29 Jan 2011 01:32:59 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.079 X-Spam-Level: X-Spam-Status: No, score=-98.079 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_50=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOU2+Mhg8rAK for ; Sat, 29 Jan 2011 01:32:58 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id DDB403A69A8 for ; Sat, 29 Jan 2011 01:32:56 -0800 (PST) Received: (eyou send program); Sat, 29 Jan 2011 17:36:01 +0800 Message-ID: <496293761.11823@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 29 Jan 2011 17:36:01 +0800 Message-ID: <9FF9845C07064148A744813D30D40CF4@LENOVO47E041CF> From: "Jiankang YAO" To: "Joseph Yee" , "EAI WG" References: <496232816.07572@cnnic.cn> Date: Sat, 29 Jan 2011 17:36:51 +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] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 09:32:59 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvc2VwaCBZZWUiIDxqeWVl QGNhLmFmaWxpYXMuaW5mbz4NClRvOiAiRUFJIFdHIiA8aW1hQGlldGYub3JnPg0KU2VudDogU2F0 dXJkYXksIEphbnVhcnkgMjksIDIwMTEgMTI6NDAgQU0NClN1YmplY3Q6IFtFQUldIENvbnNlbnN1 cyBSZXN1bHQgb24gSXNzdWUgIzEgLSBQYXJhbWV0ZXIgb24gTUFJTCBGUk9NDQoNCg0KPiBBbGws DQo+IA0KPiBGb2xsb3dpbmcgcmVzcG9uc2VzLCB0aGlzIGlzc3VlIHJlYWNoZWQgdGhlIGNvbnNl bnN1cyB0byBhZGQgcGFyYW1ldGVyIG9uIE1BSUwgRlJPTS4gIFRoZSByZXN1bHQgd2lsbCBiZSBk b2N1bWVudGVkIGF0IGlzc3VlIHRyYWNrZXIgKGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L2VhaS90cmFjL3JlcG9ydC8xKS4NCj4gDQo+IFN1YnNlcXVlbnQgIHByb3Bvc2VkIHF1ZXN0aW9u cyANCj4gMS4gV2hhdCBpcyB0aGUgbmFtZSBvZiB0aGUgcGFyYW1ldGVyPw0KPiAyLiBEb2VzIHRo ZSBwYXJhbWV0ZXIgaGF2ZSB2YWx1ZSBvciBub3Q/ICBXaGF0IGtpbmQgb2YgdmFsdWU/DQo+IA0K Pg0KDQphbm90aGVyIHF1ZXN0aW9uIGFza2VkIG1heSBiZSB0aGF0ICJ0aGUgcGFyYW1ldGVyIGlz IHRvIGluZGljYXRlIHRoYXQgdGhlIFNNVFAgY2xpZW50IGlzIEVBSS1hd2FyZSBvciB0aGF0IA0K dGhlIG1lc3NhZ2Ugc2VudCBpcyBFQUkgbWVzc2FnZT8iOw0KDQppZiBvdXIgaW50ZW5zaW9uIGlz IHRoYXQgdGhlIHBhcmFtZXRlciBpcyB0byBpbmRpY2F0ZSB0aGF0ICB0aGUgbWVzc2FnZSBzZW50 IGlzIEVBSSBtZXNzYWdlLA0KdGhlbiBpdCBzZWVtcyB0aGF0IHRoZSBzbXRwIGNsaWVudHMgc3Rp bGwgaGF2ZSB0byBzY2FuIHRoZSBtZXNzYWdlIGhlYWRlcnMgdG8gZGVjaWRlIHdoZXRoZXIgdGhl IG1lc3NhZ2Ugc2VudCBpcw0KRUFJIG9yIG5vdCBpZiB0aGUgTVVBIGRvZXMgbm90IGluZGljYXRl IGl0Lg0KDQoNCkppYW5rYW5nIFlhbyANCg0KDQo+DQo+IE5ldyBpc3N1ZXMgcmFpc2VkIGR1cmlu ZyB0aGUgZGlzY3Vzc2lvbg0KPiAxLiBUaGVyZSBhcmUgMiBkaWZmZXJlbnQgaWRlYXMgb2YgTUFJ TCBGUk9NIGludGVyYWN0aW9uIGJldHdlZW4gTVVBIGFuZCBNVEEuIA0KPiAgICAxLjEgTVVBIHRl bGxzIE1UQSB0aGF0IGl0c2VsZiBpcyBFQUkgY2FwYWJsZSwgaGVuY2UgYWxsIG1lc3NhZ2VzIHJ1 biBpbiAiRUFJLW1vZGUiIChNVUEgYWx3YXlzIHVzZXMgdGhlIHBhcmFtZXRlciB3aGVuIGF2YWls YWJsZSkNCj4gICAgMS4yIE1VQSB0ZWxscyBNVEEgdGhhdCB0aGUgZm9sbG93aW5nIG1lc3NhZ2Ug bmVlZHMgdG8gcnVuIHVuZGVyIEVBSS1tb2RlICh0aGUgbmV4dCBtZXNzYWdlIGZyb20gTVVBIG1h eSBub3QgdXNlIHRoZSBwYXJhbWV0ZXIsIGFsdGhvdWdoIGJvdGggYXJlIEVBSSBjYXBhYmxlLCB0 aGUgaW50ZXJhY3Rpb24gYW5kIG1lc3NhZ2UgcnVuIHVuZGVyICBSRkM1MzIxLzUzMjIpDQo+IEkg d2lsbCBzdGFydCBhIG5ldyB0aHJlYWQgZm9yIHRoaXMgZGlzY3Vzc2lvbi4gICAgDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGlmeSBtZSBvZiBhbnkgZXJyb3JzLCBtaXN1bmRlcnN0YW5kaW5nLCBvciBt aXNzZWQgb3BpbmlvbnMuDQo+IA0KPiBSZWdhcmRzLA0KPiBKb3NlcGgNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0K PiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p bWE= From dhc2@dcrocker.net Sat Jan 29 08:53:44 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 703053A6823 for ; Sat, 29 Jan 2011 08:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2l6VCyn89Bq for ; Sat, 29 Jan 2011 08:53:43 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 60E013A67C3 for ; Sat, 29 Jan 2011 08:53:43 -0800 (PST) Received: from [192.168.1.4] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0TGuM4i001601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 29 Jan 2011 08:56:28 -0800 Message-ID: <4D4446A4.1080801@dcrocker.net> Date: Sat, 29 Jan 2011 08:56:04 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jiankang YAO References: <496232816.07572@cnnic.cn> <496293761.11823@cnnic.cn> In-Reply-To: <496293761.11823@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]); Sat, 29 Jan 2011 08:56:28 -0800 (PST) Cc: EAI WG Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 29 Jan 2011 16:53:44 -0000 On 1/29/2011 1:36 AM, Jiankang YAO wrote: > another question asked may be that "the parameter is to indicate that the SMTP client is EAI-aware or that > the message sent is EAI message?"; > > if our intension is that the parameter is to indicate that the message sent is EAI message, > then it seems that the smtp clients still have to scan the message headers to decide whether the message sent is > EAI or not if the MUA does not indicate it. This is a core question that we should answer carefully and clearly. I think there are two different issues that are actually independent: 1. Is the client submitting a message that should be treated as UTF-8 A message might be in UTF-8, even if it contains only ASCII characters. 2. Can the client handle responses that contain UTF-8? Even if the client is submitting a legacy ASCII message, the server might need to reply with information containing UTF-8. This has been mentioned on the list, but I don't remember seeing the group come to consensus on whether this needs to be supported. Note that the server cannot know whether the client supports UTF-8 replies, unless the client happens to signal that a message is in UTF-8. I suggest that the parameter on the MAIL command should only mean that the message is in UTF-8, and that a separate /explicit/ flag is needed for the session, to let the server know that the client can handle UTF-8 in replies. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sat Jan 29 11:29:45 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 577193A681C for ; Sat, 29 Jan 2011 11:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr3AtUvx5j2P for ; Sat, 29 Jan 2011 11:29:43 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id ABF5B3A6817 for ; Sat, 29 Jan 2011 11:29:43 -0800 (PST) Received: from [192.168.1.4] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0TJWlHI004916 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 29 Jan 2011 11:32:52 -0800 Message-ID: <4D446B4E.8050705@dcrocker.net> Date: Sat, 29 Jan 2011 11:32:30 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: EAI WG References: <496232816.07572@cnnic.cn> <496293761.11823@cnnic.cn> <4D4446A4.1080801@dcrocker.net> In-Reply-To: <4D4446A4.1080801@dcrocker.net> 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]); Sat, 29 Jan 2011 11:32:53 -0800 (PST) Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 29 Jan 2011 19:29:45 -0000 Follow-on thoughts... On 1/29/2011 8:56 AM, Dave CROCKER wrote: > 1. Is the client submitting a message that should be treated as UTF-8 > > A message might be in UTF-8, even if it contains only ASCII characters. > > 2. Can the client handle responses that contain UTF-8? The following presumes working group consensus to have a UTF8 parameter on the MAIL command... The current work really is designed for using UTF-8 in a "pure" UTF-8 environment. Although we all know that gatewaying between UTF-8 and the legacy ASCII environment is needed, that requirement is being moved for separate handling: The current effort is to define a pure UTF-8 world. As such, all messages from the client will label submitted messages as being in UTF-8. That is, the MAIL command will declare UTF-8. And that means that the server knows that UTF-8 in replies are acceptable. For now, we can ignore the possibility that a client might submit a legacy ASCII message but the server would want to return a response containing UTF-8. As for the meaning of the MAIL command parameter: >>> Option 1: Any EAI-capable client that is talking with a server >>> that supports EAI extensions SHOULD send the parameter with >>> MAIL, indicating that it is modern ... >> >>> Option 2: ... an EAI-capable client talking with an >>> EAI-capable server SHOULD send the parameter only if it has >>> reason to believe that the message requires EAI support. ... > > (i) "MUST supply the parameter if the envelope or message > requires EAI facilities and SHOULD NOT supply it if the client > is EAI-capable but not using EAI facilities" > > (ii) "MUST supply the parameter if the envelope or message > requires EAI facilities and MAY supply it if the client is > EAI-capable but not using EAI facilities" Unfortunately this type of language winds up requiring additional precise specification of the meaning of "requires EAI facilities" and "EAI-capable". A much simpler approach is to define the option in terms of data, declaring that all data (commands, responses and message) are in "network" UTF-8. That is, the version of UTF-8 defined in the ABNF specified by the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sat Jan 29 12:00:34 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 0B0453A6866 for ; Sat, 29 Jan 2011 12:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.075 X-Spam-Level: X-Spam-Status: No, score=-111.075 tagged_above=-999 required=5 tests=[AWL=0.124, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv+wKFuR9Ejk for ; Sat, 29 Jan 2011 12:00:32 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 33F113A686D for ; Sat, 29 Jan 2011 12:00:32 -0800 (PST) Received: (qmail 89629 invoked from network); 29 Jan 2011 20:03:40 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 29 Jan 2011 20:03:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=1855b.4d44729c.k1101; i=johnl@user.iecc.com; bh=XygTHQy+hEFBvoqw/XytcI3S8EzY6msdrylgvUc2yQc=; b=lRiBg2xcjsehwhz6xHTjDpUI4Qom3scGvAHZamiox46Pc7RqsiY6SF26zs18xq0DwrpMo3Ob9Ud6p6R+XJdMBhGdVgzRcu4WCr6yF8jfsAzzi6VJAG7AKWrU5OYxuORiWnr9R+cnKYbLzwtDCW2QXLwunUNwSbkNIgNdtaT3h/Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=1855b.4d44729c.k1101; olt=johnl@user.iecc.com; bh=XygTHQy+hEFBvoqw/XytcI3S8EzY6msdrylgvUc2yQc=; b=mKF3JZSTnxb17lSxlm6aohj/INrxLaGVG0FowKJlashdgxtd006l8fssGbGe+UM0jBO16abV+dcMO48RyCirQTbbjcuRskfopBhYfvWzbmLmzNa++TDaifXmzNHzUWkzW4rLPe8TDfLmOY1z123F3BrucyuGCk6WEL4MNncF4k4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Jan 2011 20:03:40 -0000 Message-ID: <20110129200340.99674.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D4446A4.1080801@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 20:00:34 -0000 > Even if the client is submitting a legacy ASCII message, the server > might need to reply with information containing UTF-8. This has > been mentioned on the list, but I don't remember seeing the group > come to consensus on whether this needs to be supported. If the client hasn't set the EAI flag on MAIL FROM, as far as the server is concerned, it's a legacy client sending an ASCII message. If a server can't return an ASCII response, it's not compatible with legacy clients. That seems like a really bad idea. Since EXPN and VRFY have their own flags, the only places I'm aware of that it might be desirable to have non-ASCII in response text is RCPT TO responses 251 and 551. If we're going to do anything about that tiny case, my suggestion would be non-normative advice to server operators that if they know where a message should go, just send it there and respond with 250 instead. All other response text from MAIL FROM, RCPT TO, and DATA is just cosmetic, so it doesn't matter. >I suggest that the parameter on the MAIL command should only mean >that the message is in UTF-8, and that a separate /explicit/ flag is >needed for the session, to let the server know that the client can >handle UTF-8 in replies. To avoid more incompatibility with legacy clients, please don't. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From Shawn.Steele@microsoft.com Sat Jan 29 13:18:58 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 E5E833A687E for ; Sat, 29 Jan 2011 13:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTMsU3XmZJCk for ; Sat, 29 Jan 2011 13:18:57 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B93AA3A683F for ; Sat, 29 Jan 2011 13:18:57 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 29 Jan 2011 13:22:07 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Sat, 29 Jan 2011 13:22:07 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM Thread-Index: AQHLv/qU/j/ETSXxuEuVqnoFlJPgkA== Date: Sat, 29 Jan 2011 21:22:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 21:18:59 -0000 I think that defining the flag as "UTF8 is enabled" is sufficient. If the client can send UTF-8, then the client can handle UTF8 responses. I= f UTF8 is permitted, it's sort of irrelevent if the message happens to be a= ll-ASCII, though it may be convenient to know that additional information. So I'd like to see the flag just mean "UTF8 is enabled." =20 Clearly if the sender knows the message is all-ascii, it could avoid the fl= ag if it wanted to. -Shawn ------------------------------ Message: 4 Date: Sat, 29 Jan 2011 11:32:30 -0800 From: Dave CROCKER Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM To: EAI WG Message-ID: <4D446B4E.8050705@dcrocker.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Follow-on thoughts... On 1/29/2011 8:56 AM, Dave CROCKER wrote: > 1. Is the client submitting a message that should be treated as UTF-8 > > A message might be in UTF-8, even if it contains only ASCII characters. > > 2. Can the client handle responses that contain UTF-8? The following presumes working group consensus to have a UTF8 parameter on = the MAIL command... The current work really is designed for using UTF-8 in a "pure" UTF-8 environment. Although we all know that gatewaying between UTF-8 and the le= gacy ASCII environment is needed, that requirement is being moved for separate handling: The current effort is to define a pure UTF-8 world. As such, all messages from the client will label submitted messages as bein= g in UTF-8. That is, the MAIL command will declare UTF-8. And that means that = the server knows that UTF-8 in replies are acceptable. For now, we can ignore the possibility that a client might submit a legacy = ASCII message but the server would want to return a response containing UTF-8. As for the meaning of the MAIL command parameter: >>> Option 1: Any EAI-capable client that is talking with a server >>> that supports EAI extensions SHOULD send the parameter with >>> MAIL, indicating that it is modern ... >> >>> Option 2: ... an EAI-capable client talking with an >>> EAI-capable server SHOULD send the parameter only if it has >>> reason to believe that the message requires EAI support. ... > > (i) "MUST supply the parameter if the envelope or message > requires EAI facilities and SHOULD NOT supply it if the client > is EAI-capable but not using EAI facilities" > > (ii) "MUST supply the parameter if the envelope or message > requires EAI facilities and MAY supply it if the client is > EAI-capable but not using EAI facilities" Unfortunately this type of language winds up requiring additional precise specification of the meaning of "requires EAI facilities" and "EAI-capable"= . A much simpler approach is to define the option in terms of data, declaring= that all data (commands, responses and message) are in "network" UTF-8. That is= , the version of UTF-8 defined in the ABNF specified by the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------------------------------ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima End of IMA Digest, Vol 66, Issue 40 ***********************************= From dhc2@dcrocker.net Sat Jan 29 14:04:05 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 5674E3A6890 for ; Sat, 29 Jan 2011 14:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKSA9lIw7KwZ for ; Sat, 29 Jan 2011 14:04:03 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 711213A680E for ; Sat, 29 Jan 2011 14:04:03 -0800 (PST) Received: from [192.168.1.4] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0TM77E2008058 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 29 Jan 2011 14:07:13 -0800 Message-ID: <4D448F7A.4090803@dcrocker.net> Date: Sat, 29 Jan 2011 14:06:50 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 29 Jan 2011 14:07:13 -0800 (PST) Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 29 Jan 2011 22:04:05 -0000 On 1/29/2011 1:22 PM, Shawn Steele wrote: > I think that defining the flag as "UTF8 is enabled" is sufficient. > > If the client can send UTF-8, then the client can handle UTF8 responses. If > UTF8 is permitted, it's sort of irrelevent if the message happens to be > all-ASCII, though it may be convenient to know that additional information. Except that it's not irrelevant. If the message is actually a UTF8 message, then the SMTP receiver is going to have to turn around and require support for UTF8 on the next hop. It needs to know whether that is required. So "enabled" is not sufficient. In fact, that's why the option needs to be used to label the character encoding of the message. The semantics need to mean that the message is actually UTF-8 and that it requires a UTF-8 path through to delivery. > Clearly if the sender knows the message is all-ascii, it could avoid the flag > if it wanted to. That's too casual. If the message is an ASCII message -- as opposed to a UTF-8 message that only consumed x07F and below -- then the UTF8 option MUST NOT be used. However if the message is UTF-8 -- even if it happens to consume only x07F and below -- then the option MUST be used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sat Jan 29 14:41:58 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 1194E3A68B0 for ; Sat, 29 Jan 2011 14:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrImvE43yMtM for ; Sat, 29 Jan 2011 14:41:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E26183A68B6 for ; Sat, 29 Jan 2011 14:41:55 -0800 (PST) Received: from [192.168.1.4] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0TMj0V1008651 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 29 Jan 2011 14:45:05 -0800 Message-ID: <4D44985A.6040505@dcrocker.net> Date: Sat, 29 Jan 2011 14:44:42 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Levine References: <20110129200340.99674.qmail@joyce.lan> In-Reply-To: <20110129200340.99674.qmail@joyce.lan> 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]); Sat, 29 Jan 2011 14:45:05 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] Gatewaying and Legacy support within EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 29 Jan 2011 22:41:58 -0000 On 1/29/2011 12:03 PM, John Levine wrote: >> Even if the client is submitting a legacy ASCII message, the server >> might need to reply with information containing UTF-8. This has >> been mentioned on the list, but I don't remember seeing the group >> come to consensus on whether this needs to be supported. > > If the client hasn't set the EAI flag on MAIL FROM, as far as the > server is concerned, it's a legacy client sending an ASCII message. That's correct. > If a server can't return an ASCII response, it's not compatible with > legacy clients. That seems like a really bad idea. What do you mean "a server can't return an ASCII response"? That would mean that it cannot support legacy traffic. If that's the case, we are far, far outside the IETF standards. If you mean that the server has UTF-8 data that it wants to include in a response, but it won't be able to, then yes that is correct. What are the actual, or expected, scenarios for which this is a major problem? What is the basis for believing they will occur with any great frequency? That is, how important are those scenarios to support and how do we know that? >> I suggest that the parameter on the MAIL command should only mean >> that the message is in UTF-8, and that a separate /explicit/ flag is >> needed for the session, to let the server know that the client can >> handle UTF-8 in replies. If the client is sending around UTF-8 messages, it has to support UTF-8 elsewhere in the session. Anything else would make little sense. The only issue occurs when a server wants to return UTF-8 data but the client has not added the UTF8 parameter to a command. > To avoid more incompatibility with legacy clients, please don't. And herein lies the core issue: The EAI work tried to maintain compatibility with legacy systems in its previous round of effort and it didn't work very well. For this round, it is trying to specify operation in a UTF8-clean environment. As already noted, gatewaying between legacy and UTF8 is certainly important, but it needs to be specified separately. Including it within the current work has apparently -- and not surprisingly -- consistently created confusion. (As I fear it is doing now.) Here's the overall system architecture, showing a number of different interoperability scenarios: +-----------+ +-----------+ | 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 concerns SMTP and the RFC5322 header, not the MIME mechanisms for supporting UTF-8.) The diagram shows an ASCII-clean service on top, with a UTF8-clean service below, and 3 points of gatewaying between them. Gatewaying might be in either direction. (Note that it is entirely possible for a single piece of software to support two or more of the functions shown above. But the chart is about network architecture, not software implementation.) The legacy service supports only MSA-ASCII/MTA-ASCII, MTA-ASCII/MTA-ASCII, and MTA-ASCII/MDA-ASCII interactions. The current specification is attempting ONLY to specify the MSA-UTF8/MTA-UTF8, MTA-UTF8/MTA-UTF8, and MTA-UTF8/MDA-UTF8 interactions. Additional effort -- in a separate specification -- is required to cover the /six/ gatewaying activities -- one for each direction, at each point of gatewaying. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Sat Jan 29 15:16:29 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 340D43A689C for ; Sat, 29 Jan 2011 15:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.077 X-Spam-Level: X-Spam-Status: No, score=-11.077 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC2O53FZjbL5 for ; Sat, 29 Jan 2011 15:16:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 853363A6892 for ; Sat, 29 Jan 2011 15:16:27 -0800 (PST) Received: (qmail 43618 invoked from network); 29 Jan 2011 23:19:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=aa61.4d44a088.k1101; i=johnl@submit.iecc.com; bh=2dY9dTG6qjBqeIw7W07HVkbOi1xt2tg+X73kCTECmtk=; b=PbNr/AdNp6Bw8n7P7Nl7vy84xI+6q1bNso+A+jh3SHYl37xjv3g/ApS995RncfIqVUxEckuM1s4YCuCmLwv+y8+UEYgcWtqMs+KMvDx/uGiSi74RuUPpdmzaqhyRogmV2saIygE0k+uUco8zso3jZ09daGLQWqw2rTlTK6uDJFQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=aa61.4d44a088.k1101; olt=johnl@submit.iecc.com; bh=2dY9dTG6qjBqeIw7W07HVkbOi1xt2tg+X73kCTECmtk=; b=VGtz3BPDs8UjVSGKvYLRPxzspYiR2t/CYNhBo4lMoJ52+w8TyqgV+BOyJXV+EyjBf963ci2sD+qzDYXmQkI07trvd0yWkHBiwXxNV4rGkvbmT+hxXKIGs9nJiDiSab7Ov5/b/vPk2v2B17bznfvw8b5I7Ey1nbA+diEvz/Pg0mI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jan 2011 23:19:13 -0000 Date: 29 Jan 2011 18:19:35 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <4D44985A.6040505@dcrocker.net> References: <20110129200340.99674.qmail@joyce.lan> <4D44985A.6040505@dcrocker.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ima@ietf.org Subject: Re: [EAI] Gatewaying and Legacy support within EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 23:16:29 -0000 >> If a server can't return an ASCII response, it's not compatible with >> legacy clients. That seems like a really bad idea. > > What do you mean "a server can't return an ASCII response"? I was referring to this: >>> I suggest that the parameter on the MAIL command should only mean >>> that the message is in UTF-8, and that a separate /explicit/ flag is >>> needed for the session, to let the server know that the client can >>> handle UTF-8 in replies. This suggests that there would be situtations where the server want to send UTF-8 replies, but the client couldn't handle them, which I think we agree could break legacy mail. If you meant it the other way around, that a client can send UTF-8 messages with UTF-8 addresses in the envelope, but not handle UTF-8 text in the SMTP responses, the right answer is still Don't Do That. Again, I'm trying to think of a plausible scenario in which that would be useful. Someone made all the changes for UTF-8 message headers, message/global bodies, and UTF-8 envelopes, but it was too hard to handle UTF-8 in the SMTP response comments? I don't get it. If the question is about relaying the text of the response back to a hypothetical prior link that doesn't do UTF-8, I don't see any reason to add extra complication to make that the server's problem rather than the client's. Maybe the server has alternate text available, maybe it doesn't. A client that needs to downcode has a variety of options without any help from the server, such as substituting a generic message appropriate for the response code. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From johnl@iecc.com Sat Jan 29 16:29:36 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 AF5493A6900 for ; Sat, 29 Jan 2011 16:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.078 X-Spam-Level: X-Spam-Status: No, score=-111.078 tagged_above=-999 required=5 tests=[AWL=0.121, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgauW2eVMkxX for ; Sat, 29 Jan 2011 16:29:35 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D200B3A68FC for ; Sat, 29 Jan 2011 16:29:34 -0800 (PST) Received: (qmail 58070 invoked from network); 30 Jan 2011 00:32:43 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 30 Jan 2011 00:32:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=10750.4d44b1ab.k1101; i=johnl@user.iecc.com; bh=I1hDzk0QOsNnOXCNah/HUyVQ4DD3ew8MI/dhC1BCORc=; b=abkoeqFmbtsECzphWKKPkoSiceGotOUHl/wc7CO5h2J6PI2BhMYC0z6SJSyDs6grJCmeX36YNMDg/5EYhyXjtT75ugJqmBtOmtOIgeENPryQiRB4H4dPGT3MpsAXIjyJacb29VEpupQjwUGS432C7N4dPwqdqg4sD6QD0jllIg0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=10750.4d44b1ab.k1101; olt=johnl@user.iecc.com; bh=I1hDzk0QOsNnOXCNah/HUyVQ4DD3ew8MI/dhC1BCORc=; b=rAPOBq4GGXl81EmegnrACH/TYMsCnYyOQNfNtKMh2DX/PP1XbE6mgv2ThlvZqrONgx2v9mqaC/RYirVo3JHPdBZR6aK39ukMKub8aRgQ97zLOKPoWwwiJ85vkuL00UP5+vjYt42SFUXWepTBwGJIC/nzEWgKXuvLHP4KV49xg7w= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Jan 2011 00:32:43 -0000 Message-ID: <20110130003243.67407.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D448F7A.4090803@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 00:29:37 -0000 >If the message is an ASCII message -- as opposed to a UTF-8 message that only >consumed x07F and below -- then the UTF8 option MUST NOT be used. >However if the message is UTF-8 -- even if it happens to consume only >x07F and below -- then the option MUST be used. Hi. King Canute here. For the benefit of all the MUA and MTA implemeters, can you explain in as few words as possible what the difference is between an ASCII message and a UTF-8 message where all the bytes are ASCII, and why it's important for them to maintain the distinction between the two? (I think I understand the difference, but I don't think I can explain it so as to make it sound like it's worth caring about.) It seems to me that no matter what we say, they're going to use simple hacks like scanning the headers and envelope to see if there's anything with the high bit set, or maybe even at setup time asking what the user's preferred character set is, and turning on the EAI flag if it's anything other than ASCII. At this point we can guess based on our limited experience what is likely to maximize backwards compatibility. But I expect that as soon as one or two of the big webmail systems support EAI, which is likely to be soon since they all operate all over the world, the normal answer to any question that includes words like downcode will be "just get a Gmail account and read your mail there." R's, John From yaojk@cnnic.cn Sat Jan 29 18:16:00 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 591F13A6B0C for ; Sat, 29 Jan 2011 18:16:00 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -97.46 X-Spam-Level: X-Spam-Status: No, score=-97.46 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_50=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onm7cCDeGWij for ; Sat, 29 Jan 2011 18:15:59 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 11A523A6B0A for ; Sat, 29 Jan 2011 18:15:55 -0800 (PST) Received: (eyou send program); Sun, 30 Jan 2011 10:19:05 +0800 Message-ID: <496353945.21997@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 30 Jan 2011 10:19:05 +0800 Message-ID: From: "Jiankang YAO" To: References: <496232816.07572@cnnic.cn> <496293761.11823@cnnic.cn> <496320228.28382@cnnic.cn> Date: Sun, 30 Jan 2011 10:19: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: EAI WG Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 02:16:00 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo YzJAZGNyb2NrZXIubmV0Pg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNj OiAiSm9zZXBoIFllZSIgPGp5ZWVAY2EuYWZpbGlhcy5pbmZvPjsgIkVBSSBXRyIgPGltYUBpZXRm Lm9yZz4NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAzMCwgMjAxMSAxMjo1NiBBTQ0KU3ViamVjdDog UmU6IFtFQUldIENvbnNlbnN1cyBSZXN1bHQgb24gSXNzdWUgIzEgLSBQYXJhbWV0ZXIgb24gTUFJ TCBGUk9NDQoNCg0KPiANCj4gDQouLi4NCj4gDQo+IEkgc3VnZ2VzdCB0aGF0IHRoZSBwYXJhbWV0 ZXIgb24gdGhlIE1BSUwgY29tbWFuZCBzaG91bGQgb25seSBtZWFuIHRoYXQgdGhlIA0KPiBtZXNz YWdlIGlzIGluIFVURi04LCBhbmQgdGhhdCBhIHNlcGFyYXRlIC9leHBsaWNpdC8gZmxhZyBpcyBu ZWVkZWQgZm9yIHRoZSANCj4gc2Vzc2lvbiwgdG8gbGV0IHRoZSBzZXJ2ZXIga25vdyB0aGF0IHRo ZSBjbGllbnQgY2FuIGhhbmRsZSBVVEYtOCBpbiByZXBsaWVzLg0KPiANCg0KQWN0dWFsbHksICBh IHNlcGFyYXRlIC9leHBsaWNpdC8gZmxhZyBpcyBub3QgbmVjZXNzYXJ5LiB3ZSBwcmVzdW1lIHRo YXQgd2UganVzdCBuZWVkIHRvIHVzZSBwYXJhbWV0ZXIgdG8gbWVhbiB3aGV0aGVyIHRoZSBtZXNz YWdlIHNlbnQgaXMgZWFpIG9yIG5vdC4NCmlmIHRoZSBzbXRwIGNsaWVudHMvc2VydmVycyBzdXBw b3J0IHRoZSBwYXJhbWV0ZXIgc3BlY2lmaWVkIGluIHJmYzUzMzZiaXMsICBpdCBpbmRpY2F0ZXMg dGhhdCB0aGV5IHN1cHBvcnQgRUFJLg0KDQoNCnNvIGZvciBleGFtcGxlLA0KDQppZiBtYWlsIGZy b20gdGVzdEBleGFtcGxlLmNvbSAgaGVhZGVyPWVhaSwgaXQgaW5kaWNhdGVzIHRoYXQgdGhlIGNs aWVudCBzdXBwb3J0cyBFQUk7DQoNCmlmIG1haWwgZnJvbSB0ZXN0QGV4YW1wbGUuY29tICBoZWFk ZXI9YXNjaWksIGl0IGluZGljYXRlcyB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMgRUFJIHRvbzsN Cg0KYW55IHNlcnZlci9jbGllbnQgd2hpY2ggZG9lcyBub3Qgc3VwcG9ydCByZmM1MzM2YmlzLCB3 aWxsIG5vdCBzdXBwb3J0IHRoaXMgcGFyYW1ldGVyLg0Kb25seSB0aGUgZWFpLWF3YXJlIHNlcnZl ci9jbGllbnQgY2FuIHNldCB0aGlzIHBhcmFtZXRlci4NCg0KDQpKaWFua2FuZyBZYW8NCg0KPiBk Lw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLSANCj4gDQo+ICAgRGF2ZSBDcm9ja2VyDQo+ ICAgQnJhbmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nDQo+ICAgYmJpdy5uZXQ= From McQuilWP@pobox.com Sat Jan 29 18:43:59 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 9B0EE3A69B8 for ; Sat, 29 Jan 2011 18:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9UTFIw0QSGU for ; Sat, 29 Jan 2011 18:43:58 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 928FE3A69B7 for ; Sat, 29 Jan 2011 18:43:57 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id AB29F1D62; Sat, 29 Jan 2011 21:47:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=d1qu8OeY8kGV /JLJw2eT2TZICLs=; b=tb2u7n0SNjJHzIP7PRnTrCVNII/HqZzKEHevH5NwBCoK chiRnPAXX+Yfz7vlPsv0j3wFZCagZqjJUW12BLhHGs2+akklsAjVKi43N5kvm8Vw sfpoMR1ZRIT4o2ssBYDzpz8WSPMi5nyZDGzf83+qXb+EPd2jPUK5npLoQnivg58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=WXvhGN w3+GHwtSgvU6KZtmJpnNcsMgg7/7aJyNyhqewRhKMqUKgMyzoVhi+dNl7hbayX6U ObYSrmD7r87Op3HrE575tvNkLot7CSJCToVIrfmNSCWOOuoXJp0pq3D8M5osaXtt Ukt1e84hEpjWZQ5JgLvkCbfrUfeJojCtacZJY= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 703321D61; Sat, 29 Jan 2011 21:47:03 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 97AD11D60; Sat, 29 Jan 2011 21:46:59 -0500 (EST) Date: Sat, 29 Jan 2011 18:46:57 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <5942262.20110129184657@pobox.com> To: IMA Discussion In-Reply-To: References: <496232816.07572@cnnic.cn> <496293761.11823@cnnic.cn> <496320228.28382@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 37DFCDCE-2C1B-11E0-8154-D3BDF791CF9A-02871704!b-pb-sasl-quonix.pobox.com Cc: dcrocker@bbiw.net Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 02:43:59 -0000 On Sat, 2011-01-29, Jiankang YAO wrote: > ----- Original Message ----- > From: "Dave CROCKER" > if mail from test@example.com header=eai, it indicates that the client supports EAI; > if mail from test@example.com header=ascii, it indicates that the client supports EAI too; > any server/client which does not support rfc5336bis, will not support this parameter. > only the eai-aware server/client can set this parameter. This syntax would certainly distinguish among the three cases we're talking about: 1-Legacy Client, 2-EAI Client & ASCII Message, 3-EAI Client & EAI Message. And I have already recommended something like this. However, if the desire is *only* to distinguish between a Legacy Client & an EAI Client without saying anything about each message, that is an attribute of the *session* and replicating the flag on every MAIL FROM: is bizarre! Unless, of course, we wish to accommodate clients that mutate their abilities during the course of a session. :-) -- Bill McQuillan From Claudio.Allocchio@garr.it Sun Jan 30 01:22:44 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 ACBEF3A68DF for ; Sun, 30 Jan 2011 01:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWPy6J0jsMqp for ; Sun, 30 Jan 2011 01:22:43 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 59A663A68D8 for ; Sun, 30 Jan 2011 01:22:42 -0800 (PST) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0U9PbwS035446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 10:25:38 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0U9PbwS035446 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Av4PxXGLPR0jaqwfUAKjUKrhrkn9DSGFjczcHcg2kMXVCL07Ja4TcPrQtSnBp+ZIZ y10CatX0gl0Xn2K58sDE6hCVxB9ylg002RFlGvIzjSkXNd/kO1tMW4yh3x713/4IxgT NHA17NdRzgNOgeAHfRRMh2GMQwopeFwdXNTEBhE= Date: Sun, 30 Jan 2011 10:25:37 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: dcrocker@bbiw.net In-Reply-To: <4D44985A.6040505@dcrocker.net> Message-ID: References: <20110129200340.99674.qmail@joyce.lan> <4D44985A.6040505@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Gatewaying and Legacy support within EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 09:22:44 -0000 +1 on all. (see some more below) On Sat, 29 Jan 2011, Dave CROCKER wrote: > > On 1/29/2011 12:03 PM, John Levine wrote: >>> Even if the client is submitting a legacy ASCII message, the server >>> might need to reply with information containing UTF-8. This has >>> been mentioned on the list, but I don't remember seeing the group >>> come to consensus on whether this needs to be supported. >> >> If the client hasn't set the EAI flag on MAIL FROM, as far as the >> server is concerned, it's a legacy client sending an ASCII message. > > That's correct. > > >> If a server can't return an ASCII response, it's not compatible with >> legacy clients. That seems like a really bad idea. > > What do you mean "a server can't return an ASCII response"? > > That would mean that it cannot support legacy traffic. If that's the case, > we are far, far outside the IETF standards. > > If you mean that the server has UTF-8 data that it wants to include in a > response, but it won't be able to, then yes that is correct. > > What are the actual, or expected, scenarios for which this is a major > problem? > > What is the basis for believing they will occur with any great frequency? > That is, how important are those scenarios to support and how do we know > that? > > >>> I suggest that the parameter on the MAIL command should only mean >>> that the message is in UTF-8, and that a separate /explicit/ flag is >>> needed for the session, to let the server know that the client can >>> handle UTF-8 in replies. > > If the client is sending around UTF-8 messages, it has to support UTF-8 > elsewhere in the session. Anything else would make little sense. > > The only issue occurs when a server wants to return UTF-8 data but the client > has not added the UTF8 parameter to a command. > > >> To avoid more incompatibility with legacy clients, please don't. > > And herein lies the core issue: > > The EAI work tried to maintain compatibility with legacy systems in its > previous round of effort and it didn't work very well. > > For this round, it is trying to specify operation in a UTF8-clean > environment. correct. This UTF8 scenario is an upgrade which cannot be compatible with the previous version, e.g. we cannot in any case expect that legacy e-mail will be able to transport "without any kind of getewaying action" UTF8 mail. > > As already noted, gatewaying between legacy and UTF8 is certainly important, > but it needs to be specified separately. Including it within the current > work has apparently -- and not surprisingly -- consistently created > confusion. (As I fear it is doing now.) many +1 ! As we also need (as discussed on the ML) a more detailed document (referenced from the current specifications) which dscribes gatewaying issues, both with legacy e-mail and other (non IETF) mail standards, there is a very good reason for keeping this separate, too. > > Here's the overall system architecture, showing a number of different > interoperability scenarios: > > +-----------+ +-----------+ > | MUA-ASCII | | MUA-ASCII | > +----+------+ +-----------+ > | ^ > v | > +-----------+ +-----------+ +-----------+ +----+------+ > | MSA-ASCII +--->| MTA-ASCII +--->| MTA-ASCII +--->| MDA-ASCII | > +-----------+ ^ +-----------+ ^ +-----------+ ^ +-----------+ > | | | > | | | and here is the gateway system....(with its specification) > | | | > +-----------+ V +-----------+ V +-----------+ V +-----------+ > | MSA-UTF8 |--->| MTA-UTF8 |--->| MTA-UTF8 |--->| MDA-UTF8 > +-----------+ +-----------+ +-----------+ +----+------+ > ^ | > | V > +-----------+ +-----------+ > | MUA-UTF8 | | MUA-UTF8 | > +-----------+ +-----------+ > > > (This concerns SMTP and the RFC5322 header, not the MIME mechanisms for > supporting UTF-8.) > > The diagram shows an ASCII-clean service on top, with a UTF8-clean service > below, and 3 points of gatewaying between them. Gatewaying might be in > either direction. > > (Note that it is entirely possible for a single piece of software to > support two or more of the functions shown above. But the chart is about > network architecture, not software implementation.) > > The legacy service supports only MSA-ASCII/MTA-ASCII, MTA-ASCII/MTA-ASCII, > and MTA-ASCII/MDA-ASCII interactions. > > The current specification is attempting ONLY to specify the > MSA-UTF8/MTA-UTF8, MTA-UTF8/MTA-UTF8, and MTA-UTF8/MDA-UTF8 interactions. > > Additional effort -- in a separate specification -- is required to cover the > /six/ gatewaying activities -- one for each direction, at each point of > gatewaying. and this is just for THIS kindof gateway (the most important and common one, of course). > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 Sun Jan 30 06:55:37 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 AA9043A6A6F for ; Sun, 30 Jan 2011 06:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z79KV+ncnqM for ; Sun, 30 Jan 2011 06:55:36 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2CD983A699E for ; Sun, 30 Jan 2011 06:55:36 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PjYja-000FyD-6D; Sun, 30 Jan 2011 09:58:34 -0500 X-Vipre-Scanned: 0823E413001DEB0823E560-TDI Date: Sun, 30 Jan 2011 09:58:33 -0500 From: John C Klensin To: dcrocker@bbiw.net, Shawn Steele Message-ID: In-Reply-To: <4D448F7A.4090803@dcrocker.net> References: <4D448F7A.4090803@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] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 14:55:37 -0000 --On Saturday, January 29, 2011 2:06 PM -0800 Dave CROCKER wrote: >... > If the message is an ASCII message -- as opposed to a UTF-8 > message that only consumed x07F and below -- then the UTF8 > option MUST NOT be used. > > However if the message is UTF-8 -- even if it happens to > consume only x07F and below -- then the option MUST be used. Dave, With the understanding that I personally favor sending a MAIL command announcement only if EAI capabilities are required, please explain what the second paragraph quoted above means. If I were taking the position I understand Shawn to be advocating, I would say "well, the client is EAI-capable, there is no way to distinguish between an ASCII message and a message that is UTF-8 but only contains characters in the ASCII code point range ('x07F and below') than I should send the parameter in all cases". john From dhc2@dcrocker.net Sun Jan 30 08:16:27 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 2E92A3A677E for ; Sun, 30 Jan 2011 08:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28TpcOwr+GwI for ; Sun, 30 Jan 2011 08:16:26 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 39B4E3A6407 for ; Sun, 30 Jan 2011 08:16:26 -0800 (PST) Received: from [192.168.1.5] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p0UGJWRh006512 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 08:19:38 -0800 Message-ID: <4D458F81.8000106@dcrocker.net> Date: Sun, 30 Jan 2011 08:19:13 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John C Klensin References: <4D448F7A.4090803@dcrocker.net> In-Reply-To: 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]); Sun, 30 Jan 2011 08:19:38 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 30 Jan 2011 16:16:27 -0000 On 1/30/2011 6:58 AM, John C Klensin wrote: >> However if the message is UTF-8 -- even if it happens to >> consume only x07F and below -- then the option MUST be used. > > Dave, > > With the understanding that I personally favor sending a MAIL > command announcement only if EAI capabilities are required, > please explain what the second paragraph quoted above means. > If I were taking the position I understand Shawn to be > advocating, I would say "well, the client is EAI-capable, there > is no way to distinguish between an ASCII message and a message > that is UTF-8 but only contains characters in the ASCII code > point range ('x07F and below') than I should send the parameter > in all cases". "should"? under what circumstances would it be acceptable not to? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Sun Jan 30 10:22:05 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 3BB603A684E for ; Sun, 30 Jan 2011 10:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns5k4KUI0l4d for ; Sun, 30 Jan 2011 10:22:04 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 187063A6965 for ; Sun, 30 Jan 2011 10:22:04 -0800 (PST) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 30 Jan 2011 10:25:16 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0270.002; Sun, 30 Jan 2011 10:25:15 -0800 From: Shawn Steele To: John C Klensin , "dcrocker@bbiw.net" Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM Thread-Index: AQHLv/qU/j/ETSXxuEuVqnoFlJPgkJPpB88AgAEaq4D//7FZsw== Date: Sun, 30 Jan 2011 18:25:15 +0000 Message-ID: References: <4D448F7A.4090803@dcrocker.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 18:22:05 -0000 IMO this cannot happen consistently enough to trust the values, however I w= elcome your response to John's question. ASCII messages and UTF-8 messages in the <=3D0x7f are identical and should = be allowed to be treated as such. Certainly, I'm typing a message now. It could be transmitted in either ASC= II or UTF-8 (Since I removed the Klingon from my signature). The client ha= s no clue whether the user intends ASCII or UTF-8, and it is irrelevent whe= ther this message is sent in ASCII or UTF-8. (Presumably it'll use whateve= r defaults OWA's giving me). If this messege is intended as ASCII and sent= with legacy SMTP, it'll behave. If it's intended as UTF-8 and sent with l= egacy SMTP, it'll also behave. Ditto for an EAI aware system. So there's = no need to care whether this message is ASCII or UTF-8. I do agree that some of the current drafts could be simpler by have "ASCII = encoded" (legacy) messages or "UTF-8 encoded" (EAI) messages, however, in p= ractice, it really doesn't matter if someone uses the UTF8 encoding for an = ASCII encoded message. That's part (probably most) of why UTF-8 was design= ed as a superset. If you're worried about "ASCII encoded" that happens to have data with the = 8th bit set, well, you're already in a broken place. That's illegal, there= 's no such thing as 8-bit ASCII with the 8th bit set, it must always be zer= o. That leads to the kind of ambiguity we have today when mail is sent wit= h system code pages. If such mail was sent as UTF-8, it must fail, which i= s great. -Shawn http://blogs.msdn.com/shawnste ________________________________________ From: John C Klensin [klensin@jck.com] Sent: Sunday, January 30, 2011 6:58 AM To: dcrocker@bbiw.net; Shawn Steele Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM --On Saturday, January 29, 2011 2:06 PM -0800 Dave CROCKER wrote: >... > If the message is an ASCII message -- as opposed to a UTF-8 > message that only consumed x07F and below -- then the UTF8 > option MUST NOT be used. > > However if the message is UTF-8 -- even if it happens to > consume only x07F and below -- then the option MUST be used. Dave, With the understanding that I personally favor sending a MAIL command announcement only if EAI capabilities are required, please explain what the second paragraph quoted above means. If I were taking the position I understand Shawn to be advocating, I would say "well, the client is EAI-capable, there is no way to distinguish between an ASCII message and a message that is UTF-8 but only contains characters in the ASCII code point range ('x07F and below') than I should send the parameter in all cases". john= From jyee@ca.afilias.info Sun Jan 30 12:59:43 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 A59013A6ABE for ; Sun, 30 Jan 2011 12:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 oS7IozNx0u1W for ; Sun, 30 Jan 2011 12:59:42 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id BE39C3A6872 for ; Sun, 30 Jan 2011 12:59:42 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Jan 2011 16:02:53 -0500 Message-Id: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@ca.afilias.info> To: EAI WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] Consensus Result on Issue #4 - new reference and term for "ASCII", "non-ASCII", "UTF-8"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 20:59:43 -0000 All, (First, sorry for late delivery on this one, somehow the original 'seems = lost', and thanks to JianKang to bring this to my attention) Following responses, this issue has not reach any consensus, due to lack = to participation (4 expressed opinions) and result evenly split. = Including opinions expressed prior consensus (during Dec, 2010 to Jan = 2010) the result remains the same. I will keep this question open until Feb 3 (Thursday) 9pm Pacific Time = for more opinions to determine whether a more definitive consensus could = be reached. =20 There is suggestion, from Barry, to contribute section of terminology to = be used by EAI. There are debates on whether it should be done at = larger scale, a RFC with the terminology meant for all drafts rather = than just EAI. I welcome the discussion but please address the question = of do we need new reference and term for "ASCII", "non-ASCII", "UTF-8" = first. Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph From jyee@ca.afilias.info Sun Jan 30 13:09:37 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 E8B1D3A6AF1 for ; Sun, 30 Jan 2011 13:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.12 X-Spam-Level: X-Spam-Status: No, score=-106.12 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5+1NZIvyZTL for ; Sun, 30 Jan 2011 13:09:37 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id EE6063A67F7 for ; Sun, 30 Jan 2011 13:09:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <4D42F1D7.6060207@dcrocker.net> Date: Sun, 30 Jan 2011 16:12:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <905C16E8-86E3-4D59-924F-17BEA1297234@ca.afilias.info> References: <282C11A6-361B-4B63-B742-455E2A964F99@ca.afilias.info> <4D42F1D7.6060207@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) X-Authenticated: True Cc: EAI WG Subject: Re: [EAI] Consensus Result on Issue #5 - Keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 21:09:38 -0000 Thanks for the clarification. I will wait until Wednesday Feb 2 (9pm Pacific) for comments regarding = result. The updated result: 7 people expressed their opinions: keep it:=20 John Klensin Shawn Steele John Levine Charles Lindsey Tony Hansen Dave Crocker remove it: undecided: Barry Leiba Regards, Joseph On 2011-01-28, at 11:41 AM, Dave CROCKER wrote: >=20 >=20 > On 1/28/2011 8:27 AM, Joseph Yee wrote: >> Following responses, this issue reached the consensus of keep the = nested encoding for message/global. >>=20 >> 7 people expressed their opinions: >> keep it: > ... >> remove it: >> Dave Crocker >=20 >=20 > Sorry my response was unclear. >=20 > I meant that it should be kept, but should be renamed to = message/utf8-rfc822. >=20 > The purpose of renaming is to make it clear that this is a variation = of an existing, important message type. In addition "global" is far too = generic, IMO. >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From Shawn.Steele@microsoft.com Sun Jan 30 18:50:26 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 C8DA93A67D3 for ; Sun, 30 Jan 2011 18:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.574 X-Spam-Level: X-Spam-Status: No, score=-9.574 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMgqdKugfw3v for ; Sun, 30 Jan 2011 18:50:25 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id DE2EF3A67C1 for ; Sun, 30 Jan 2011 18:50:25 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 30 Jan 2011 18:53:39 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Sun, 30 Jan 2011 18:53:38 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM Thread-Index: AQHLwPINH2i1PpEe0U2CAkqdm0RTWw== Date: Mon, 31 Jan 2011 02:53:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 31 Jan 2011 02:50:26 -0000 PiBpZiBtYWlsIGZyb20gdGVzdEBleGFtcGxlLmNvbSAgaGVhZGVyPWVhaSwgaXQgaW5kaWNhdGVz IHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyBFQUk7DQo+IGlmIG1haWwgZnJvbSB0ZXN0QGV4YW1w bGUuY29tICBoZWFkZXI9YXNjaWksIGl0IGluZGljYXRlcyB0aGF0IHRoZSBjbGllbnQgc3VwcG9y dHMgRUFJIHRvbzsNCg0KSSByZWFsbHkgZG9uJ3QgbGlrZSBhbnl0aGluZyB3aXRoIHRoZSA9ZWFp L2FzY2lpIHR5cGUgdGhpbmcuICBBRkFJSyBtYWlsIGRvZXNuJ3QgZG8gdGhpcyBhbnl3aGVyZS4g IElmIHdlIHJlYWxseSwgcmVhbGx5LCByZWFsbHkgaGFkIHRvIGhhdmUgdGhpcywgdGhlbiBpJ2Qg cHJlZmVyOg0KDQppZiBtYWlsIGZyb20gdGVzdEBleGFtcGxlLmNvbSAgVVRGOFNNVFAgQVNDSUlP TkxZLCBzdXBwb3J0cyBFQUksIGJ1dCBtZXNzYWdlIGlzIG9ubHkgQVNDSUkuDQppZiBtYWlsIGZy b20gdGVzdEBleGFtcGxlLmNvbSAgVVRGOFNNVFAsIHN1cHBvcnRzIEVBSSwgYnV0IG1lc3NhZ2Ug aXMgVVRGLTguDQoNCkkgaGF2ZSBubyBjbHVlIHdoZW4gSSdkIGV2ZXIgdXNlIHRoZSAxc3QgdGhv dWdoLiAgSXQncyBub3Qgd29ydGggdGhlIGNsaWVudCdzIGVmZm9ydCB0byBwYXJzZSB0aGUgbWVz c2FnZSB0byBmaWd1cmUgaXQgb3V0IChvciByZW1lbWJlciBpdCksIGFuZCB0aGVyZSdyZSBnb2lu ZyB0byBiZSBlcnJvcnMgd2hlbiB0aGUgY2xpZW50IHdhcyBmb3J3YXJkaW5nIHRoZSBtZXNzYWdl IGFuZCBzb21laG93IHRoZSBBU0NJSU9OTFkgKG9yIFVURjgpIGZsYWcgZ290IGZvcmdvdHRlbi4N Cg0KLVNoYXduDQoNCu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0dHA6Ly9ibG9ncy5t c2RuLmNvbS9zaGF3bnN0ZQ== From chl@clerew.man.ac.uk Mon Jan 31 03:24:24 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 02AA73A6903 for ; Mon, 31 Jan 2011 03:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] 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 WbOHtM6hfvOc for ; Mon, 31 Jan 2011 03:24:22 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 7595C3A690F for ; Mon, 31 Jan 2011 03:24:21 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id ED58C2209C for ; Mon, 31 Jan 2011 11:27:34 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 31 Jan 2011 11:27:34 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0VBRYkb024093 for ; Mon, 31 Jan 2011 11:27:35 GMT To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <496231963.07475@cnnic.cn> <496285285.11868@cnnic.cn> Content-Transfer-Encoding: 8bit Date: Mon, 31 Jan 2011 11:27:34 -0000 Message-ID: In-Reply-To: <496285285.11868@cnnic.cn> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d469ca6.174f9-5ce-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Result on Issue #2 - new parameter to VRFY/EXPNonly after EHLO with UTF8SMTPbis? 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, 31 Jan 2011 11:24:24 -0000 On Sat, 29 Jan 2011 07:15:34 -0000, Jiankang YAO wrote: > ----- Original Message ----- > From: "Joseph Yee" > To: "EAI WG" > Sent: Saturday, January 29, 2011 12:25 AM > Subject: [EAI] Consensus Result on Issue #2 - new parameter to > VRFY/EXPNonly after EHLO with UTF8SMTPbis? > > >> All, >> >> Following responses, this issue reached an unanimous consensus that new >> parameter to VRFY/EXPN permitted only after EHLO with UTF8SMTPbis. >> > > > the new parameter is UTF8SMTPbis? +1 -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Mon Jan 31 03:32:26 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 9D6A73A696D for ; Mon, 31 Jan 2011 03:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Sm+-FdFt5cjz for ; Mon, 31 Jan 2011 03:32:25 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id 15EAC3A6900 for ; Mon, 31 Jan 2011 03:32:21 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 1DFF4222B3 for ; Mon, 31 Jan 2011 11:35:35 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 31 Jan 2011 11:35:34 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0VBZXQf024574 for ; Mon, 31 Jan 2011 11:35:34 GMT Date: Mon, 31 Jan 2011 11:35:33 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <20110130003243.67407.qmail@joyce.lan> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20110130003243.67407.qmail@joyce.lan> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d469e86.180f0-897-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 31 Jan 2011 11:32:26 -0000 On Sun, 30 Jan 2011 00:32:43 -0000, John Levine wrote: > It seems to me that no matter what we say, they're going to use simple > hacks like scanning the headers and envelope to see if there's > anything with the high bit set, or maybe even at setup time asking > what the user's preferred character set is, and turning on the EAI > flag if it's anything other than ASCII. We are agreed that we DON'T want servers en route to be doing that. But clients and submission servers MIGHT do that (or get the information some other way). We don't insist that they do, nor do we insist that they don't. So at most it is a "MAY" - or rather it is "MAY include the UTF8 parameter on a pure ASCII message", but coupled with a NOTE (text already discussed) warning of the downside of doing so. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From chl@clerew.man.ac.uk Mon Jan 31 03:36:47 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 EE86E3A68A7 for ; Mon, 31 Jan 2011 03:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.837 X-Spam-Level: X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tXJr3YcGTyYE for ; Mon, 31 Jan 2011 03:36:47 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id E35323A63CA for ; Mon, 31 Jan 2011 03:36:46 -0800 (PST) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 66054222F2 for ; Mon, 31 Jan 2011 11:39:59 +0000 (GMT) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 31 Jan 2011 11:39:59 +0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p0VBdwVF024841 for ; Mon, 31 Jan 2011 11:39:59 GMT Date: Mon, 31 Jan 2011 11:39:57 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <4D448F7A.4090803@dcrocker.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d469f8f.a08-12e-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 31 Jan 2011 11:36:48 -0000 On Sun, 30 Jan 2011 18:25:15 -0000, Shawn Steele wrote: > I do agree that some of the current drafts could be simpler by have > "ASCII encoded" (legacy) messages or "UTF-8 encoded" (EAI) messages, > however, in practice, it really doesn't matter if someone uses the UTF8 > encoding for an ASCII encoded message. That's part (probably most) of > why UTF-8 was designed as a superset. Yes it DOES matter. Because the message would then be forwarded ONLY over routes that advertise UTF8SMTPbis, and there might not exist such a route to the intended destination, in which case it would bounce. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From Shawn.Steele@microsoft.com Mon Jan 31 12:53:17 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 B2F1B3A6C4D for ; Mon, 31 Jan 2011 12:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X1PTbMN5pHo for ; Mon, 31 Jan 2011 12:53:16 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6DEFC3A6AEB for ; Mon, 31 Jan 2011 12:53:16 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Jan 2011 12:56:31 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Mon, 31 Jan 2011 12:56:30 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Result on Issue #4 - new reference and term Thread-Index: AcvBiRzzWcIP5JzrSAqXFNIpoQJesg== Date: Mon, 31 Jan 2011 20:56:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #4 - new reference and term 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, 31 Jan 2011 20:53:17 -0000 I can't vote 2x, but I would prefer to keep the current terminology so we d= on't rathole. I think a section within the document defining our terms wou= ld be adequate. Another RFC for terminology is certainly out of scope for = the WG. ---------------------------------------------------------------------- Message: 1 Date: Sun, 30 Jan 2011 16:02:53 -0500 From: Joseph Yee Subject: [EAI] Consensus Result on Issue #4 - new reference and term for "ASCII", "non-ASCII", "UTF-8"? To: EAI WG Message-ID: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@ca.afilias.info> Content-Type: text/plain; charset=3Dus-ascii All, (First, sorry for late delivery on this one, somehow the original 'seems lo= st', and thanks to JianKang to bring this to my attention) Following responses, this issue has not reach any consensus, due to lack to= participation (4 expressed opinions) and result evenly split. Including o= pinions expressed prior consensus (during Dec, 2010 to Jan 2010) the result= remains the same. I will keep this question open until Feb 3 (Thursday) 9pm Pacific Time for = more opinions to determine whether a more definitive consensus could be rea= ched. =20 There is suggestion, from Barry, to contribute section of terminology to be= used by EAI. There are debates on whether it should be done at larger sca= le, a RFC with the terminology meant for all drafts rather than just EAI. = I welcome the discussion but please address the question of do we need new = reference and term for "ASCII", "non-ASCII", "UTF-8" first. Please notify me of any errors, misunderstanding, or missed opinions. Regards, Joseph From Shawn.Steele@microsoft.com Mon Jan 31 12:56:38 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 758243A6814 for ; Mon, 31 Jan 2011 12:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFjgzDXZfCtQ for ; Mon, 31 Jan 2011 12:56:37 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 822783A6856 for ; Mon, 31 Jan 2011 12:56:37 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Jan 2011 12:59:52 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Mon, 31 Jan 2011 12:59:52 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Result on Issue #1 - Parameter on MAIL Thread-Index: AcvBiYb7MN5ukFPKST66h5t1LmEtqQ== Date: Mon, 31 Jan 2011 20:59:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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, 31 Jan 2011 20:56:38 -0000 > Yes it DOES matter. Because the message would then be forwarded ONLY over= =20 > routes that advertise UTF8SMTPbis, and there might not exist such a route= =20 > to the intended destination, in which case it would bounce. I disagree. If the message could be sent in ASCII and reach the destinatio= n, then I have no problem with that message reaching the destination if it = happened to be encoded in UTF-8 but only used the lower 7 bits. In fact, t= he only way to tell the difference is if someone explicitly included additi= onal information, not in the message itself, that the message was "supposed= " to be UTF-8 or ASCII. Message routing shouldn't be dependent on informat= ion that isn't within the message. =20 -Shawn From eai@troystarr.net Mon Jan 31 13:48:39 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 993343A6885 for ; Mon, 31 Jan 2011 13:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv8CkIko-J2i for ; Mon, 31 Jan 2011 13:48:38 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id DA3593A67F7 for ; Mon, 31 Jan 2011 13:48:34 -0800 (PST) Received: from FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8]) by FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8%10]) with mapi; Mon, 31 Jan 2011 13:51:50 -0800 From: E-mail Address Internationalization To: "'ima@ietf.org'" Date: Mon, 31 Jan 2011 13:51:46 -0800 Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM Thread-Index: AcvBgfLXSr0Sqpn+RIqzdp+aBOzmCwACE+sg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 31 Jan 2011 21:48:39 -0000 SGkgU2hhd24gLQ0KDQo+ID4gaWYgbWFpbCBmcm9tIHRlc3RAZXhhbXBsZS5jb20gIGhlYWRlcj1l YWksIGl0IGluZGljYXRlcyB0aGF0IHRoZSANCj4gPiBjbGllbnQgc3VwcG9ydHMgRUFJOyBpZiBt YWlsIGZyb20gdGVzdEBleGFtcGxlLmNvbSAgaGVhZGVyPWFzY2lpLCBpdCANCj4gPiBpbmRpY2F0 ZXMgdGhhdCB0aGUgY2xpZW50IHN1cHBvcnRzIEVBSSB0b287DQo+IA0KPiBJIHJlYWxseSBkb24n dCBsaWtlIGFueXRoaW5nIHdpdGggdGhlID1lYWkvYXNjaWkgdHlwZSB0aGluZy4gIEFGQUlLIG1h aWwgZG9lc24ndCBkbyB0aGlzIGFueXdoZXJlLg0KDQpDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdo eSB5b3UgZG9uJ3QgbGlrZSBpdD8gIEknbSB0cnlpbmcgdG8gdGhpbmsgb2YgdGhlIHJlYXNvbnMg d2h5LCBidXQgSSdtIG5vdCBzdXJlIHdoYXQgSSdtIGNvbWluZyB1cCB3aXRoIG1hdGNoZXMgd2hh dCB5b3UncmUgdGhpbmtpbmcuICBIZXJlIGFyZSB0aGUgcG9zc2liaWxpdGllcyB0aGF0IEkndmUg Y29tZSB1cCB3aXRoOg0KDQoxLiBZb3UgZG9uJ3QgdGhpbmsgdGhhdCBNQUlMIHBhcmFtZXRlcnMg YXJlIGFsbG93ZWQgdG8gaGF2ZSB2YWx1ZXMsIHNvIHdlJ2QgYmUgbW9kaWZ5aW5nIHRoZSBNQUlM IHBhcmFtZXRlciBleHRlbnNpYmlsaXR5IG1lY2hhbmlzbS4gIEhvd2V2ZXIsIHRoYXQncyBub3Qg dGhlIGNhc2UuICBTZWN0aW9uIDQuMS4yIG9mIFJGQyA1MzIxIGRlZmluZXMgdGhlIHN5bnRheCBv ZiAiTWFpbC1wYXJhbWV0ZXJzIiwgd2hpY2ggcG9pbnRzIHRvICJlc210cC1wYXJhbSIsIHdoaWNo IGFsbG93cyBwYXJhbWV0ZXJzIHRvIGhhdmUgdmFsdWVzLg0KDQoyLiBZb3UgZG9uJ3QgdGhpbmsg dGhlcmUgYXJlIGFueSBwcmV2aW91cyBleHRlbnNpb25zIHRoYXQgdXNlIHZhbHVlcyB3aXRoIHBh cmFtZXRlcnMsIHNvIHdlJ2QgYmUgZG9pbmcgc29tZXRoaW5nIHVudXN1YWwuICBIb3dldmVyLCB0 aGF0J3MgYWxzbyBub3QgdGhlIGNhc2UuICBCb3RoIHRoZSBTSVpFIHBhcmFtZXRlciAoUkZDIDE4 NzApIGFuZCB0aGUgQk9EWSBwYXJhbWV0ZXIgKFJGQ3MgMTY1MiBhbmQgMzAzMCkgZm9yIHRoZSBN QUlMIGNvbW1hbmQgY2FuIGFuZCBkbyB0YWtlIHZhbHVlcy4NCg0KMy4gWW91IGZpbmQgc3BlY2lm eWluZyB0aGUgImxlZ2FjeSIgYmVoYXZpb3IgYW5kICJuZXciIGJlaGF2aW9yIHZpYSBwYXJhbWV0 ZXIgdmFsdWVzIHRvIGJlIHVudXN1YWwuICBIb3dldmVyLCB0aGlzIGhhcyBhbHNvIGhhcHBlbmVk IGJlZm9yZSwgYWdhaW4gd2l0aCB0aGUgQk9EWSBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBSRkMgMTY1 Mi4gIFRoZSA3QklUIHZhbHVlIHNpZ25pZmllcyBsZWdhY3kgYmVoYXZpb3IsIHdoaWxlIHRoZSA4 QklUIHZhbHVlIHNpZ25pZmllcyBuZXcgYmVoYXZpb3IuDQoNCklzIHRoZXJlIHNvbWUgb3RoZXIg dW5kZXJseWluZyByZWFzb24gdG8geW91ciBvYmplY3Rpb24gdGhhdCBJIGhhdmVuJ3QgdGhvdWdo dCBvZj8NCg0KPiBJZiB3ZSByZWFsbHksIHJlYWxseSwgcmVhbGx5IGhhZCB0byBoYXZlIHRoaXMs IHRoZW4gaSdkIHByZWZlcjoNCj4gDQo+IGlmIG1haWwgZnJvbSB0ZXN0QGV4YW1wbGUuY29tICBV VEY4U01UUCBBU0NJSU9OTFksIHN1cHBvcnRzIEVBSSwgYnV0IG1lc3NhZ2UgaXMgb25seSBBU0NJ SS4NCj4gaWYgbWFpbCBmcm9tIHRlc3RAZXhhbXBsZS5jb20gIFVURjhTTVRQLCBzdXBwb3J0cyBF QUksIGJ1dCBtZXNzYWdlIGlzIFVURi04Lg0KDQpUbyBiZSBob25lc3QsIEkgZG9uJ3QgbGlrZSB0 aGlzLiA6LSkgIFRoZSByZWFzb24gd2h5IGlzIHRoYXQgQVNDSUlPTkxZIGlzIGFub3RoZXIgd2F5 IG9mIHNheWluZyBOT1RVVEY4LCBhbmQgaXQgZmVlbHMgYXdrd2FyZCB0byBtZSBmcm9tIGEgcHJv dG9jb2wgZGVzaWduIHBvaW50IG9mIHZpZXcgdG8gYW5ub3VuY2UgdGhhdCB5b3UncmUgbm90IHVz aW5nIGEgZmVhdHVyZSB2aWEgYSBzdGFuZGFsb25lIHBhcmFtZXRlci4gIChBbmQgdG8gaGVhZCBv ZmYgYW55IHBvdGVudGlhbCB0YW5nZW50cyB0aGF0IEFTQ0lJICE9IE5PVFVURjgsIEkgZ2V0IHRo YXQsIGJ1dCBmcm9tIGEgMTAsMDAwIGZvb3QgdmlldyB0aGF0J3MgYmFzaWNhbGx5IHdoYXQgd2Un cmUgc2F5aW5nLikNCg0KSW4gYWRkaXRpb24sIEkgZmVlbCB0aGF0IHBhcmFtZXRlcnMgdGhhdCB3 ZSBjb21lIHVwIHdpdGggc2hvdWxkIGJlIGVhc3kgdG8gcGFyc2UgYW5kIHVuZGVyc3RhbmQgZnJv bSBib3RoIGEgY29tcHV0ZXIgYW5kIGh1bWFuIHBvaW50IG9mIHZpZXcuICBJIHdvdWxkbid0IGlt bWVkaWF0ZWx5IHVuZGVyc3RhbmQgd2hhdCBBU0NJSU9OTFkgaW1wbGllcyB1bmxlc3MgSSB3YXMg ZmFtaWxpYXIgd2l0aCB0aGlzIFJGQy4gIFdlIGNvdWxkIG1ha2UgaXQgbW9yZSBlYXNpbHkgdW5k ZXJzdG9vZCBieSBjYWxsaW5nIGl0IEFTQ0lJSEVBREVSUyBvciBzb21ldGhpbmcgc2ltaWxhciwg YnV0IHRoYXQgc3RpbGwgZmVlbHMgYXdrd2FyZCB0byBtZSBmb3IgdGhlIHJlYXNvbiBJIGdhdmUg YWJvdmUuICBVc2luZyBhIHBhcmFtZXRlcj12YWx1ZSBjb252ZW50aW9uIG9mIEhFQURFUlM9QVND SUkvVVRGOCAob3IgVVRGOFNNVFBiaXMgaWYgeW91J2QgcHJlZmVyKSBzZWVtcyB0byBlbGVnYW50 bHkgYW5kIHN1Y2NpbmN0bHkgY29tbXVuaWNhdGUgYm90aCB0aGF0IHRoZSBjbGllbnQgaXMgRUFJ LWNhcGFibGUgc2hvdWxkIHRoYXQgYmUgaW1wb3J0YW50LCBhbmQgd2hldGhlciB0aGlzIHNwZWNp ZmljIG1lc3NhZ2UgcmVxdWlyZXMgdGhhdCBjYXBhYmlsaXR5Lg0KDQo+IEkgaGF2ZSBubyBjbHVl IHdoZW4gSSdkIGV2ZXIgdXNlIHRoZSAxc3QgdGhvdWdoLiAgSXQncyBub3Qgd29ydGggdGhlIGNs aWVudCdzIGVmZm9ydCB0byBwYXJzZSB0aGUgbWVzc2FnZSB0byBmaWd1cmUgaXQgb3V0IChvciBy ZW1lbWJlciBpdCksIGFuZCB0aGVyZSdyZSBnb2luZyB0byBiZSBlcnJvcnMgd2hlbiB0aGUgY2xp ZW50IHdhcyBmb3J3YXJkaW5nIHRoZSBtZXNzYWdlIGFuZCBzb21laG93IHRoZSBBU0NJSU9OTFkg KG9yIFVURjgpIGZsYWcgZ290IGZvcmdvdHRlbi4NCg0KV2hlbiB5b3Ugc2F5IHRoZSBtZXNzYWdl LCBkbyB5b3UgbWVhbiB0aGUgb3JpZ2luYWwgbWVzc2FnZSB0aGF0IHRoZSB1c2VyIGlzIHRyeWlu ZyB0byBzZW5kIG9yIHBvdGVudGlhbCByZXNwb25zZXMgZnJvbSB0aGUgU01UUCBzZXJ2ZXI/ICBJ ZiBpdCdzIHRoZSBmb3JtZXIsIEknbSBoYXZpbmcgdHJvdWJsZSBmb2xsb3dpbmcgdGhpcyBsaW5l IG9mIHJlYXNvbmluZy4gIEkgYWdyZWUgdGhhdCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBzaXR1 YXRpb25zIGNvbW11bmljYXRpbmcgRUFJIGNhcGFiaWxpdHkgYnV0IG5vdCBhY3R1YWxseSB1c2lu ZyBFQUkgaXMgbmVjZXNzYXJ5LiAgVGhlIG9uZSBJJ3ZlIGhlYXJkIG9mIG9uIHRoaXMgbGlzdCBp cyBpZiB0aGUgU01UUCBzZXJ2ZXIgbm90aWZpZXMgdGhlIGNsaWVudCBvZiBhbiBFQUkgZm9yd2Fy ZGluZyBhZGRyZXNzIHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhlIGNsaWVudCB3aWxsIHRo ZW4gc2VuZCB0aGUgbWVzc2FnZSB0byB0aGF0IGFkZHJlc3MgaW5zdGVhZCBvZiB0aGUgU01UUCBz ZXJ2ZXIgZm9yd2FyZGluZyBpdCBvbiB0aGUgY2xpZW50J3MgYmVoYWxmLiAgSSBkb24ndCBoYXZl IGEgZ29vZCBmZWVsIGZvciB3aGV0aGVyIHRoYXQgYWN0dWFsbHkgaGFwcGVucywgdGhvdWdoLiAg TXkgZ3V0IHRlbGxzIG1lIGl0IGRvZXNuJ3QsIGJ1dCBJJ20gaGFwcHkgdG8gYmUgcHJvdmVuIHdy b25nLiAgSW4gdGVybXMgb2Ygd2hldGhlciBpdCdzIHdvcnRoIHRoZSBjbGllbnQncyBlZmZvcnQg dG8gcGFyc2UgdGhpcyBtZXNzYWdlLCBJIGZ1bmRhbWVudGFsbHkgZGlzYWdyZWUuICBUaGUgcG9p bnQgb2YgaGF2aW5nIGEgTUFJTCBwYXJhbWV0ZXIgYXQgYWxsIGlzIHRvIG1vdmUgdGhlICJoZWF2 eSBsaWZ0aW5nIiBvZiBkZXRlcm1pbmluZyB3aGV0aGVyIHRoaXMgaXMgYW4gRUFJIG1lc3NhZ2Ug dG8gdGhlIE1VQSAoYW5kIHBvc3NpYmx5IHRoZSBNU0EpIGFuZCBhd2F5IGZyb20gdGhlIE1UQS4g IEkga25vdyB0aGF0IHlvdSBwcmVmZXIgYWx3YXlzIGFkZGluZyB0aGlzIHBhcmFtZXRlciBpZiBi b3RoIHRoZSBjbGllbnQgYW5kIHNlcnZlciBzdXBwb3J0IEVBSSByZWdhcmRsZXNzIG9mIHdoZXRo ZXIgdGhlIG1lc3NhZ2UgcmVxdWlyZXMgaXQsIGJ1dCB0aGF0IHdvdWxkIGJlIG1vcmUgbGlrZWx5 IHRvIGNhdXNlIG1lc3NhZ2VzIHRvIGJlIHJldHVybmVkIHVuZGVsaXZlcmFibGUgaWYgdGhlIGZp cnN0IGhvcCBvbiB0aGUgU01UUCBjaGFpbiBzdXBwb3J0ZWQgRUFJLCBidXQgdGhlIG5leHQgaG9w IGRpZG4ndCwgZXZlbiBpZiBFQUkgd2Fzbid0IG5lY2Vzc2FyeSBmb3IgdGhhdCBtZXNzYWdlLiAg VGhpcyBtb2RlbCBkZXBlbmRzIG9uIHRoZSBjbGllbnQgbWFraW5nIHRoYXQgZGV0ZXJtaW5hdGlv biBzbyB0aGF0IGl0IGNhbiBnaXZlIHRoZSBtZXNzYWdlIHRoZSBiZXN0IGNoYW5jZSBvZiBzdWNj ZXNzZnVsIGRlbGl2ZXJ5IGlmIEVBSSBpcyBub3QgcmVxdWlyZWQuICBJIGFsc28gaGF2ZSBhIGhh cmQgdGltZSBiZWxpZXZpbmcgdGhhdCB0aGUgQVNDSUkvVVRGOCBmbGFnIHdvdWxkIGJlIGZvcmdv dHRlbiwgYWx0aG91Z2ggd2UgY291bGQgaW5jbHVkZSB0ZXh0IHRvIHJlbWluZCBpbXBsZW1lbnRl cnMgb2YgdGhlIGZvcndhcmRpbmcgcG9zc2liaWxpdHkgc28gdGhhdCB0aGV5IGRvbid0IGZvcmdl dC4NCg0KSWYgaXQncyB0aGUgbGF0dGVyLCB0aGUgcG9zc2liaWxpdHkgaXMgcmV0dXJuaW5nIGh1 bWFuIHJlYWRhYmxlIHRleHQgd2l0aCB0aGUgcmVzcG9uc2UgY29kZXMgaW4gdGhlIG5hdGl2ZSBs YW5ndWFnZSBmb3IgdGhhdCBTTVRQIHNlcnZlciB2aWEgVVRGLTgsIHdoYXRldmVyIHRoYXQgbGFu Z3VhZ2UgbWF5IGJlLiAgRW5oYW5jZWQgc3RhdHVzIGNvZGVzIGhvcGVmdWxseSBtYWtlIHRoaXMg bGVzcyBvZiBhbiBpc3N1ZSwgYnV0IEkgY2FuIHNlZSBzb21lIHZhbHVlIGluIGNvbW11bmljYXRp bmcgdGhhdCBodW1hbiByZWFkYWJsZSB0ZXh0IGJhY2sgdG8gdGhlIHVzZXIsIGJ1dCBpdCdzIHVw IHRvIHRoZSBTTVRQIHNlcnZlciBhbmQgbWFpbCBjbGllbnQgdG8gYWN0dWFsbHkgY29tbXVuaWNh dGUgdGhhdCByZXNwb25zZSB0ZXh0IGJhY2sgdG8gdGhlIHVzZXIuDQoNCkluIHRoZSBlbmQsIGl0 J3Mgc3RpbGwgdW5jbGVhciB0byBtZSB0aGF0IHdlIG5lZWQgdG8gaW5kaWNhdGUgRUFJIGNhcGFi aWxpdHkgaWYgd2UncmUgbm90IGFjdHVhbGx5IHNlbmRpbmcgYSBtZXNzYWdlIHRoYXQgcmVxdWly ZXMgRUFJLiAgSWYgd2UgZG9uJ3QgbmVlZCB0aGlzIGNhcGFiaWxpdHksIHRoZW4gSSB3b3VsZCBi ZSBmaW5lIHdpdGggYSB2YWx1ZWxlc3MgcGFyYW1ldGVyIHN1Y2ggYXMgVVRGOFNNVFBiaXMuICBI b3dldmVyLCBpZiB0aGUgV0cgZW5kcyB1cCBkZWNpZGluZyB0aGF0IGl0IGlzIGltcG9ydGFudCBm b3IgdGhlIGNsaWVudCB0byBjb21tdW5pY2F0ZSBFQUkgY2FwYWJpbGl0eSBldmVuIGlmIGEgc3Bl Y2lmaWMgbWVzc2FnZSBkb2Vzbid0IHJlcXVpcmUgaXQsIHRoZW4gSSB3b3VsZCBmYXIgcHJlZmVy IGEgcGFyYW1ldGVyIHdpdGggYSB2YWx1ZSB0aGF0IHN1Y2NpbmN0bHkgY29tbXVuaWNhdGVzIHRo aXMgdGhhbiBhIG11bHRpdHVkZSBvZiBwYXJhbWV0ZXJzLg0KDQotIFRyb3kgU3RhcnINCg== From ned+ima@mrochek.com Mon Jan 31 14:17:27 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 671353A6B20 for ; Mon, 31 Jan 2011 14:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwp0hwz6aLPi for ; Mon, 31 Jan 2011 14:17:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 2D2A13A69B8 for ; Mon, 31 Jan 2011 14:17:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX9YM6GBOG00JLG7@mauve.mrochek.com> for ima@ietf.org; Mon, 31 Jan 2011 14:20:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX5VCDTMLC007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 31 Jan 2011 14:20:37 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NX9YM5F93S007FL5@mauve.mrochek.com> Date: Mon, 31 Jan 2011 14:03:09 -0800 (PST) In-reply-to: "Your message dated Mon, 31 Jan 2011 11:39:57 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed; DelSp=yes References: <4D448F7A.4090803@dcrocker.net> To: Charles Lindsey DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296509344; bh=ovdDWNzfWKVK9tQW4XKLrWOQ9NBw2JUnHvVCqIQuzVw=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Rj7Rww/fnOxaKO7cg62E7y3LJeULI+NI81wVXAjg0epj3/zXUZbvNNGsJ9bxwnWVa nB+K8Zswvjw2OWBYlYxlJ9NzIxHVPYcBK0iP0UmgXH/iLfXal19lFun4HuiZUZsOMW +nFj91IX3gNbCRuQpqFyT4/KBFIelMnofWW4NSDk= Cc: IMA Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 31 Jan 2011 22:17:27 -0000 > On Sun, 30 Jan 2011 18:25:15 -0000, Shawn Steele > wrote: > > I do agree that some of the current drafts could be simpler by have > > "ASCII encoded" (legacy) messages or "UTF-8 encoded" (EAI) messages, > > however, in practice, it really doesn't matter if someone uses the UTF8 > > encoding for an ASCII encoded message. That's part (probably most) of > > why UTF-8 was designed as a superset. > Yes it DOES matter. Because the message would then be forwarded ONLY over > routes that advertise UTF8SMTPbis, and there might not exist such a route > to the intended destination, in which case it would bounce. Exactly right. A client that marks non-EAI messages as being EAI messages is going to see those message bounce when they attempt to cross over into the non-EAI-extended world - which right now is "everywhere". And to those who think this is going to deploy so quickly that this won't be an issue... dream on. Although John is quite correct when he says that we suck at predicting how quickly things will deploy, the notion that this will happen overnight flies in the face of every bit of experience we have from having spent the past three decades updating email infrastructure. The best you can hope for - and I think this is still completely unrealistic - is a transition period of several years. OTOH, we tried something similar to this in MIME when we said that clients SHOULD "minimize" use of more complex charsets, e.g., don't use iso-8859-1 when US-ASCII suffices. Some clients followed this recommendation but a lot did not, and the users of those clients got a markedly inferior user experience as a result. Additionally, handling this really well at the client level is not as simple as keeping track of EAI usage with a flag. Consider the case where you have multiple recipients for a message, some with EAI addresses and others not, and for whatever reason with the recipient addresses not appearing in the header. A straightforward client would send a single message copy to all recipients with the EAI flag set. But a more sophisticated client might notice that it can send a non-EAI message to the non-EAI recipients without any content loss. And if those recipients are in the non-EAI-extended world, this may be the only approach that works in thie case. So at its heart this is really a client quality issue. Absent near-universal EAI-deployment, clients that take the trouble to check and only label actual EAI messages as EAI will provide a superior user experience to ones that blindly label everything they send as EAI. And those that don't will provide gainful employnment for lots of call center staff. Ned From eai@troystarr.net Mon Jan 31 14:46:23 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 C4E343A6B20 for ; Mon, 31 Jan 2011 14:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KMtLTMo716s for ; Mon, 31 Jan 2011 14:46:23 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id A67123A6B16 for ; Mon, 31 Jan 2011 14:46:22 -0800 (PST) Received: from FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8]) by FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8%10]) with mapi; Mon, 31 Jan 2011 14:49:37 -0800 From: Troy Starr To: "'ima@ietf.org'" Importance: low X-Priority: 5 Date: Mon, 31 Jan 2011 14:49:36 -0800 Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM Thread-Index: AcvBgfLXSr0Sqpn+RIqzdp+aBOzmCwACE+sgAAONOIA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL FROM 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, 31 Jan 2011 22:46:23 -0000 SGkgZm9sa3MgLQ0KDQo+IEZyb206IEUtbWFpbCBBZGRyZXNzIEludGVybmF0aW9uYWxpemF0aW9u DQoNClNvcnJ5IGFib3V0IHRoYXQgLSBJIGhhZCByZW5hbWVkIHRoZSBkaXNwbGF5IG5hbWUgb2Yg bXkgYWRkcmVzcyBmb3IgdGhlIEVBSSBtYWlsaW5nIGxpc3QgZm9yIGVhc2llciBzb3J0aW5nIGFu ZCBmb3Jnb3QgdGhhdCBpdCB3b3VsZCBhbHNvIGNoYW5nZSBteSBkaXNwbGF5IG5hbWUgb24gZS1t YWlsIHRoYXQgSSBzZW5kIG91dC4gIEkndmUgY29ycmVjdGVkIHRoaXMgc28gbXkgYWN0dWFsIG5h bWUgd2lsbCBhcHBlYXIgZnJvbSBub3cgb24uDQoNCi0gVHJveSBTdGFycg0K From johnl@iecc.com Mon Jan 31 16:36:01 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 42B363A6C97 for ; Mon, 31 Jan 2011 16:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.08 X-Spam-Level: X-Spam-Status: No, score=-111.08 tagged_above=-999 required=5 tests=[AWL=0.119, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+smi1LyPwHP for ; Mon, 31 Jan 2011 16:36:00 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 1F3ED3A6CB0 for ; Mon, 31 Jan 2011 16:35:57 -0800 (PST) Received: (qmail 7085 invoked from network); 1 Feb 2011 00:39:12 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 1 Feb 2011 00:39:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=c7d0.4d475630.k1101; i=johnl@user.iecc.com; bh=F63Hf7NvkDy1Vr70pw2ejNKkYEceGDX695WnzwHOnMw=; b=Y3L/aLNa74VUjxjrYh519huBjXbcs+tt1OfnIgJNCwHP0ZA6VML6zisjcOq/q2KaXlAKv9xB67MvdO1dxk7hVCO8JX1PDxzQTKCRP5/u8Mrl0jPM3j1bNDjWRC/EsovclRcqqJl4OPz0obQPKIH2t44v5oroDwtMm1sTpYF7xqU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=c7d0.4d475630.k1101; olt=johnl@user.iecc.com; bh=F63Hf7NvkDy1Vr70pw2ejNKkYEceGDX695WnzwHOnMw=; b=RweguVXUkDO/xmIP0RYa9vbZ4NdQ0DKbdDnBt8Ql3WyF3mFG8hd/tAyX2Bf+XXSWmfR47CJ21OUh8GtK/vpXYdLi/dXoKmfd6sIEY+6rhFlL46+yP1fWj3s76pxeL1XIdR1OBpqqh4oF+fVOFxcoSOI4aEvu9ijyOBTkHrLVhjA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Feb 2011 00:39:12 -0000 Message-ID: <20110201003912.51151.qmail@joyce.lan> From: John Levine To: ima@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Parameter(s) on MAIL options X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:36:01 -0000 It seems to me there are three separate features here: A) Messages with UTF-8 headers B) Envelopes with UTF-8 addresses C) SMTP responses with UTF-8 text The current proposal is to have one flag that enables (ABC). Dave, as I understand it, wants one flag for (AB) and a separate flag for (C). I suppose one could separate them out further. For reasons I think I've explained about as well as I can, I don't see much utility in more than one flag, and a lot of opportunity for confusion and broken implementations. I also agree with Ned that it's a quality of implementation issue whether a client only sets the flag for messages and/or envelopes that need it, or for everything. And it's debatably a quality of implementation issue for a server whether it passes along the flag that came with a message on a subsequent hop, or inspects it to see whether it needs the flag. So perhaps we can say something about it as a MAY or SHOULD, but don't mandate finicky rules that implementors are likely to ignore. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ned+ima@mrochek.com Mon Jan 31 17:20:17 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 33CB73A6CAD for ; Mon, 31 Jan 2011 17:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J84VQZ-kSrqa for ; Mon, 31 Jan 2011 17:20:15 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 72FA03A68EA for ; Mon, 31 Jan 2011 17:20:15 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXA4ZUPW1S00JB34@mauve.mrochek.com> for ima@ietf.org; Mon, 31 Jan 2011 17:23:29 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX5VCDTMLC007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 31 Jan 2011 17:23:26 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXA4ZTJM1E007FL5@mauve.mrochek.com> Date: Mon, 31 Jan 2011 16:44:29 -0800 (PST) In-reply-to: "Your message dated Tue, 01 Feb 2011 00:39:12 +0000" <20110201003912.51151.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110201003912.51151.qmail@joyce.lan> To: John Levine DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296520312; bh=4APnGsyTle33NJcYKNP2aAlN6fJBoBVlfuSV5vcQy5E=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=ry5Bpr7hYa7LXWBb1rU6HgA5p/walzqR4Xs2+OHXNEiXx5ziiO5+r/oeQfz2Utomj 3zZmIbnM7g6EYCmt2haNuE/kk9IguUA2B4NYynjxD5KFV3xaPagZZ76S7BBDWl8ohw LNlc479ljKxFiBPulOsx+eadi92bh7AqAtdcyf/s= Cc: ima@ietf.org Subject: Re: [EAI] Parameter(s) on MAIL options X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 01:20:17 -0000 > It seems to me there are three separate features here: > A) Messages with UTF-8 headers > B) Envelopes with UTF-8 addresses > C) SMTP responses with UTF-8 text > The current proposal is to have one flag that enables (ABC). Dave, as > I understand it, wants one flag for (AB) and a separate flag for (C). > I suppose one could separate them out further. > For reasons I think I've explained about as well as I can, I don't see > much utility in more than one flag, and a lot of opportunity for > confusion and broken implementations. I agree. > I also agree with Ned that it's a quality of implementation issue > whether a client only sets the flag for messages and/or envelopes that > need it, or for everything. And it's debatably a quality of > implementation issue for a server whether it passes along the flag > that came with a message on a subsequent hop, or inspects it to see > whether it needs the flag. So perhaps we can say something about it > as a MAY or SHOULD, but don't mandate finicky rules that implementors > are likely to ignore. I think, as a practical matter, that this is the most reasonable approach. Ned From Shawn.Steele@microsoft.com Mon Jan 31 17:52:27 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 5FB543A6CAA for ; Mon, 31 Jan 2011 17:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlqBNCtLKOhV for ; Mon, 31 Jan 2011 17:52:26 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6EAD63A6C38 for ; Mon, 31 Jan 2011 17:52:26 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Jan 2011 17:55:41 -0800 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.63]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Mon, 31 Jan 2011 17:55:41 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Result on Issue #1 - Parameter on MAI LFROM Thread-Index: AcvBsbglpG/BMGHgQkuHQ0WXkYLPnQ== Date: Tue, 1 Feb 2011 01:55:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAI LFROM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 01:52:27 -0000 I had a longer reply, but: > It seems to me there are three separate features here: > A) Messages with UTF-8 headers > B) Envelopes with UTF-8 addresses > C) SMTP responses with UTF-8 text > The current proposal is to have one flag that enables (ABC). =20 > For reasons I think I've explained about as well as I can, I don't > see much utility in more than one flag, and a lot of opportunity > for confusion and broken implementations. I agree with Ned and John. I think one flag is sufficient, and that SHOULD= or MAY is sufficient for further tweaking the use cases. -Shawn From dhc2@dcrocker.net Mon Jan 31 18:26:12 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 F30713A6CBD for ; Mon, 31 Jan 2011 18:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfCNLJOUWkno for ; Mon, 31 Jan 2011 18:26:11 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 3807A3A68EA for ; Mon, 31 Jan 2011 18:26:11 -0800 (PST) Received: from [192.168.1.7] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p112TL13020789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 18:29:26 -0800 Message-ID: <4D476FED.1000409@dcrocker.net> Date: Mon, 31 Jan 2011 18:29:01 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Levine References: <20110201003912.51151.qmail@joyce.lan> In-Reply-To: <20110201003912.51151.qmail@joyce.lan> 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, 31 Jan 2011 18:29:27 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Parameter(s) on MAIL options X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 02:26:12 -0000 On 1/31/2011 4:39 PM, John Levine wrote: > It seems to me there are three separate features here: > > A) Messages with UTF-8 headers > B) Envelopes with UTF-8 addresses > C) SMTP responses with UTF-8 text > > The current proposal is to have one flag that enables (ABC). Dave, as > I understand it, wants one flag for (AB) and a separate flag for (C). > I suppose one could separate them out further. I cited distinctions, along the lines of your list above. That recitation was not to indicate my own preference but to clarify the possibilities. After thinking it through, my observation was (and remains) that having a single MAIL command flag that declares a message to be in UTF-8 is all that it is needed: It specifies the type of the message AND implies the capabilities of the client. There does not seem to be any need for handling the differential scenarios that would be enabled by having additional flags. > And it's debatably a quality of > implementation issue for a server whether it passes along the flag > that came with a message on a subsequent hop, or inspects it to see > whether it needs the flag. This would move the protocol specification into the realm of heuristics. Protocols should not involve guessing. If a message is changed from UTF-8 to ASCII or vice-versa, then it has gone through a gateway, not a relay. That sort of cleverness is the distinction between MTA relaying and translation gatewaying. The current specification seeks to provide details for MTA relaying of a UTF-8 message. Don't confuse that task with the details for gatewaying. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Mon Jan 31 19:05:41 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 857A43A6CBD for ; Mon, 31 Jan 2011 19:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.081 X-Spam-Level: X-Spam-Status: No, score=-11.081 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZGoMFHGwq2O for ; Mon, 31 Jan 2011 19:05:40 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 3FDB23A68F1 for ; Mon, 31 Jan 2011 19:05:40 -0800 (PST) Received: (qmail 36273 invoked from network); 1 Feb 2011 03:08:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=8daf.4d477947.k1101; i=johnl@submit.iecc.com; bh=2SKqWvlUvmASWQE9eHO9HQ19oyAexeUk349nl1a3sxk=; b=a281FeAHeDCViL/6RvW8XHz+BX9ZPv2aRU1BbwuBIBSqrQdQ0S0cD3FCT9LSvMvL0gnexwgWyN7nUC9sKC2vGXi15Jmcmqj7XnWX3Mq77Nr5PgH/HgX2XhkupRkU5ym4jMKUbX9r4MNiwjXHSu2fIcORZnU+2FrynxI93g/AeLE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=8daf.4d477947.k1101; olt=johnl@submit.iecc.com; bh=2SKqWvlUvmASWQE9eHO9HQ19oyAexeUk349nl1a3sxk=; b=kmo6/YeDRE+nILW+PvfrSaPIDirHNb2Yj0cvvk6+YKat9W8V9azKiiVfkwqRMto+bBSsxO6DlfMzjD1YEYHby72ovAwGOWlyu+8F5XUaRqIdVuTVUpOriUG6aAdgHF/LUBoSyNadcZRBJJ4lm/hBVC6kPKdkq3FZCrKY1p2V4uU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Feb 2011 03:08:32 -0000 Date: 31 Jan 2011 22:08:54 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <4D476FED.1000409@dcrocker.net> References: <20110201003912.51151.qmail@joyce.lan> <4D476FED.1000409@dcrocker.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Parameter(s) on MAIL options X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 03:05:41 -0000 >> And it's debatably a quality of implementation issue for a server >> whether it passes along the flag that came with a message on a >> subsequent hop, or inspects it to see whether it needs the flag. > This would move the protocol specification into the realm of heuristics. > Protocols should not involve guessing. The specific scenario I have in mind is one where a client sends a message with the EAI flag set, then the server relays it, and it turns out that the next hop doesn't need the flag. There are a variety of sub-scenarios here, e.g., client was lazy and set the flag on an ASCII message, client sent to a mix of EAI and ASCII addresses, client sent to EAI address which server relays to an ASCII address. The behavior is entirely algorithmic, but it's not clear what the ideal algorithm would be. I am specifically NOT suggesting that we try to solve this problem here, nor that we mandate what the client do beyond requiring that it set the EAI flag if the message or envelope is non-ASCII. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From dhc2@dcrocker.net Mon Jan 31 19:52:25 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 D2E2A3A69EB for ; Mon, 31 Jan 2011 19:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys8nh0SGik2M for ; Mon, 31 Jan 2011 19:52:24 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id D53733A67D3 for ; Mon, 31 Jan 2011 19:52:24 -0800 (PST) Received: from [192.168.1.7] (adsl-68-122-35-253.dsl.pltn13.pacbell.net [68.122.35.253]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p113tZBN022258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 19:55:40 -0800 Message-ID: <4D478423.3010907@dcrocker.net> Date: Mon, 31 Jan 2011 19:55:15 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John R Levine References: <20110201003912.51151.qmail@joyce.lan> <4D476FED.1000409@dcrocker.net> In-Reply-To: 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, 31 Jan 2011 19:55:41 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Parameter(s) on MAIL options X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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, 01 Feb 2011 03:52:26 -0000 On 1/31/2011 7:08 PM, John R Levine wrote: ... > There are a variety of sub-scenarios here, e.g., client > was lazy and set the flag on an ASCII message, client sent to a mix of EAI and > ASCII addresses, client sent to EAI address which server relays to an ASCII > address. The behavior is entirely algorithmic, but it's not clear what the ideal > algorithm would be. Having a system along the handling sequence impose a change on a message might be algorithmic in a software sense, but it is a heuristic in terms of justification, absent a formal standards specification dictating the change. > I am specifically NOT suggesting that we try to solve this problem here, nor > that we mandate what the client do beyond requiring that it set the EAI flag if > the message or envelope is non-ASCII. Then I do not understand how this foray into the topic has aided deciding on the details of the parameter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Mon Jan 31 20:02:12 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 A2A753A6B53 for ; Mon, 31 Jan 2011 20:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.083 X-Spam-Level: X-Spam-Status: No, score=-11.083 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4t3LxKQLCSC for ; Mon, 31 Jan 2011 20:02:11 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 1989A3A6B60 for ; Mon, 31 Jan 2011 20:02:09 -0800 (PST) Received: (qmail 47492 invoked from network); 1 Feb 2011 04:05:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b983.4d478685.k1101; i=johnl@submit.iecc.com; bh=ze/rfECtZ6vwXWMPNx78uNYfgvfC5dJ7kihcOuNt/mE=; b=Cf7Vn25ApLLeSyKQbR9p2Vv7nYCk2+A2oISv4RzuBPcjfducgSUaMES0Tpr5a/sPKB7nhsEBMhKQmwHgGD4qMZNihL7QS4CKbVZrYEvIN6tdOx99OK2+WVoVYNgNwE2gCs4XJYTo34f1lTen+44oYefj3dNQSCTtCB8uRqCb/Ko= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b983.4d478685.k1101; olt=johnl@submit.iecc.com; bh=ze/rfECtZ6vwXWMPNx78uNYfgvfC5dJ7kihcOuNt/mE=; b=qM9Ex6P1cfMcVXaTRhqAYgjtN9oTEhnCq97yo5yH53Cbl8zm4sbDIPQYttAxJcxnsZX88XxuAPjURyodsn9ZB0HymIDafI/l2ohHTL4eZzGl5Ubi4AhYwRHfsaJ0RHHQ8s++9oVxm0Osbe2Ai5Ep1i1/CyZZz2O30bX8Gc8gNTk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Feb 2011 04:05:03 -0000 Date: 31 Jan 2011 23:05:24 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <4D478423.3010907@dcrocker.net> References: <20110201003912.51151.qmail@joyce.lan> <4D476FED.1000409@dcrocker.net> <4D478423.3010907@dcrocker.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ima@ietf.org Subject: Re: [EAI] Parameter(s) on MAIL options X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 04:02:12 -0000 > Having a system along the handling sequence impose a change on a message > might be algorithmic in a software sense, but it is a heuristic in terms of > justification, absent a formal standards specification dictating the change. Well, gee, this is hardly a new problem. You had a somewhat analogous situation with 8BITMIME, where some relay MTAs were (and, I suppose, still are) better than others at recoding messages or noticing that a message didn't really need it. >> I am specifically NOT suggesting that we try to solve this problem >> here, nor that we mandate what the client do beyond requiring that it >> set the EAI flag if the message or envelope is non-ASCII. > Then I do not understand how this foray into the topic has aided deciding on > the details of the parameter. Pick the simplest possible version, since extra complication won't help. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.