From klensin@jck.com Wed Feb 2 07:36: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 B2B593A6CD9 for ; Wed, 2 Feb 2011 07:36:34 -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 TefknBTZ-fq4 for ; Wed, 2 Feb 2011 07:36:33 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 97CFF3A6BA3 for ; Wed, 2 Feb 2011 07:36:33 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PkeoC-000Pma-T6 for ima@ietf.org; Wed, 02 Feb 2011 10:39:53 -0500 Date: Wed, 02 Feb 2011 10:39:52 -0500 From: John C Klensin To: 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] SMTP replies containing non-ASCII text (was: Re: 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: Wed, 02 Feb 2011 15:36:34 -0000 (personal opinion, although one based on considerable experience) except for the last paragraph) A few people have commented about use of a parameter to enable reply messages that contain non-ASCII characters. We have been down the path that leads in that direction multiple times. RFC 5321 and its predecessors make it very clear that message or address-specific text is needed only for the replies to VRFY and EXPN and the little-used and problematic 251 and 551 responses to RCPT (see Section 3.4 of RFC 5321). Over the years, the community has considered and rejected multiple "reply language" proposals. In its earlier life, this WG looked at the possibility of non-ASCII reply text and decided to not include it in the model. In each case, the primary reason has been the same as the primary reason for not internationalizing header field names (and a specific case of a design principle that goes back to the early ARPANET). If we use a common language (and, to the extent possible, standardized text) in field names and replies, it is relatively easy for user agents to translate from that language to whatever is appropriate locally. If we put material in arbitrary languages (even if all in UTF-8) on the wire, then every user agent that wants to accept or report localized text has to understand every language that might be encountered. The latter is an interoperability disaster. At least as serious, since the language (not just the CCS and encoding) have to be known in order to do translations, one needs a way to transmit and process language information, not just charset (CCS and encoding) information. In case it isn't obvious, neither address information nor free text (as in Subject header fields or display names) need language information because there is no real expectation of translation. That is not the case for replies. VRFY and EXPN are necessarily dealt with separately. If we really need non-ASCII support for addresses in 251 and 551 replies, then let's confine ourselves to the bracketed addresses in those replies and not start encouraging arbitrary text in arbitrary languages My strong personal preference is that we not reopen the issue of internationalized replies on the wire. If we must do so, let's keep it separate from other issues to the extent possible rather than assuming that an EAI-capable client can accept and process non-ASCII replies (even restricted to Unicode in UTF-8) and that it is reasonable for servers to send them. As a co-chair who has been charged by the WG to make this process go as quickly as possible, I should add that reopening the issue and getting into a long discussion of non-ASCII reply text is inconsistent with anything resembling speed. From klensin@jck.com Wed Feb 2 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 03AD83A6D0B for ; Wed, 2 Feb 2011 08:00:28 -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 Xg3QeBNBq8Nq for ; Wed, 2 Feb 2011 08:00:23 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 840AF3A6D56 for ; Wed, 2 Feb 2011 08:00:23 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PkfBG-00005y-Nd for ima@ietf.org; Wed, 02 Feb 2011 11:03:42 -0500 Date: Wed, 02 Feb 2011 11:03:42 -0500 From: John C Klensin To: ima@ietf.org Message-ID: <1DE6D9C69DF35A8C6F0B6C5C@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] 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: Wed, 02 Feb 2011 16:00:28 -0000 Hi. Because I really don't have any strong feeling about this issue other than: (i) When 5336bis is revised to reflect the parameter, it must be absolutely clear and precise about what the parameter means. That implies specifying exactly both when a client is expected (or required) to supply the parameter and how a server is expected to interpret its presence (or absence). (ii) We need to keep this as simple as possible (but, in Wirth's words, no simpler). I think that an arrangement involving either multiple parameters or a single parameter with multiple alternate values should require a lot of justification. While we may be looking at the issue differently, I think that aligns me with those who oppose lots of "finicky rules that implementers will ignore". All comments below are strictly personal opinions. One observation to try to find out whether we are really one the same page, then a suggestion to see if we can converge. (1) --On Monday, January 31, 2011 20:59 +0000 Shawn Steele wrote: > Message routing shouldn't be > dependent on information that isn't within the message. Interesting observation because we do it all the time and it is the norm rather than the exception. Note that we route messages based on addresses in the envelope and that there is no requirement whatsoever that those addresses appear in the headers. For the very common case of distribution from mailing lists, the forward-pointing envelope (delivery) addresses rarely appear in any header field. Or did you mean something else? (2) Over the years, there have been many occasions with email specifications on which we could agree on the right thing to do even if we could not agree on the reasoning or theory to justify that choice. I think what I'm hearing (again, personal opinion and proposal, not a consensus declaration) is that some text along the lines of the following might be acceptable to most of us as requiring the parameter where it is required but not trying to impose a requirement for high-quality client behavior: If the envelope or message being sent requires the capabilities of these EAI extensions, the client MUST supply the UTF8SMTPbis parameter with the MAIL command. If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command. This specification does not require that the client inspect the message or otherwise go to extraordinary lengths to assure itself whether these EAI capabilities are required for the particular message. However, in mixed or transitional environments in which EAI is not completely deployed, more precision on the part of the client (sender) may prevent unnecessary message rejections. The exact text should be determined to match the style of the editors, but please note that the text above talks about "EAI capabilities" and does not use any terminology specifically associated with coded character sets, encodings, or language. Is there any chance that would work for people? And, if not, what do you think needs to be changed and why. john From chl@clerew.man.ac.uk Wed Feb 2 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 E6F893A6D65 for ; Wed, 2 Feb 2011 08:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.831 X-Spam-Level: X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 td5yD8Rapi7e for ; Wed, 2 Feb 2011 08:22:17 -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 546AD3A6D08 for ; Wed, 2 Feb 2011 08:22:16 -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 3A93F225F7 for ; Wed, 2 Feb 2011 16:25: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; Wed, 02 Feb 2011 16:25: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 p12GPYY8015661 for ; Wed, 2 Feb 2011 16:25:35 GMT Date: Wed, 02 Feb 2011 16:25:34 -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: 4d49857f.4f3d-504a-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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 02 Feb 2011 16:22:19 -0000 On Mon, 31 Jan 2011 20:59:51 -0000, Shawn Steele wrote: >> 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. > > I disagree. If the message could be sent in ASCII and reach the > destination, 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, the only way to tell the difference is if > someone explicitly included additional information, not in the message > itself, that the message was "supposed" to be UTF-8 or ASCII. Message > routing shouldn't be dependent on information that isn't within the > message. But that is not how our drafts are written. If the message claims (rightly or wrongly) to be a UTF8SMTPbis message, then MTAs MUST NOT forward it to any server that does not advertise UTF8SMTPbis in its EHLO response. If an MTA can find some alternative server that is believed to route it to its final destination via some all-UFT8SMTPbis path, then good luck to it. Otherwise it gets bounced. So our protocol DOES specify that the presence of this parameter may well affect the routeing. -- 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 johnl@iecc.com Wed Feb 2 09:24: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 795533A6D2C for ; Wed, 2 Feb 2011 09:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.086 X-Spam-Level: X-Spam-Status: No, score=-111.086 tagged_above=-999 required=5 tests=[AWL=0.113, 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 g-ksBwamPUF2 for ; Wed, 2 Feb 2011 09:24:54 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 2C2C33A6BC0 for ; Wed, 2 Feb 2011 09:24:53 -0800 (PST) Received: (qmail 48715 invoked from network); 2 Feb 2011 17:28:13 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 2 Feb 2011 17:28:13 -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=1152a.4d49942d.k1102; i=johnl@user.iecc.com; bh=DMDbAkKNYtzGytFWe1iXJuxfcpL8igcyuY0jHPEwc9o=; b=n5zQZ+x5pVM6rXvAe8FuzRFVkABdqbCaoGmHKKBmmslo/KxHz1h0zmqXFOf83qWuy+nexCaY49kar01OzL0jZzL6x3f7uj4YVaoqZhPORJLMs/HrZiI0QGcciqW3wbj6IfSRjtejnNLhNy7QgVynvL6Vujy+m/IDLZYk3ycVbOs= 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=1152a.4d49942d.k1102; olt=johnl@user.iecc.com; bh=DMDbAkKNYtzGytFWe1iXJuxfcpL8igcyuY0jHPEwc9o=; b=iC/XO4gDGGEJaUWPs0iaLseLUExEW8nmr/WaHEzIFJ7iqQEEW7F6c+BKBbTzFjDzcjrwwizmFimTyQL7nhNKmb1Ncs7radsuW1fiySsjdoVdYehwttQU+2XbOrPt38y7fOoExdxMt4bIXJdKFs90FgSvJajN/yrYh1iJAgQqxzE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Feb 2011 17:28:13 -0000 Message-ID: <20110202172813.70953.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 Subject: Re: [EAI] SMTP replies containing non-ASCII text (was: Re: 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: Wed, 02 Feb 2011 17:24:55 -0000 >My strong personal preference is that we not reopen the issue of >internationalized replies on the wire. As the author of an MTA that's been known to respond 550 Message Accepted I entirely agree with this sentiment. R's, John From klensin@jck.com Wed Feb 2 10:04: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 45DFA3A6DC1 for ; Wed, 2 Feb 2011 10:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 mPRgaithzS9H for ; Wed, 2 Feb 2011 10:04:49 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 402333A6DB2 for ; Wed, 2 Feb 2011 10:04:49 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pkh7g-0003zt-Tt; Wed, 02 Feb 2011 13:08:09 -0500 Date: Wed, 02 Feb 2011 13:08:08 -0500 From: John C Klensin To: Joseph Yee , EAI WG Message-ID: <90D3E0A8D0BC28666D7BFBB4@PST.JCK.COM> In-Reply-To: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@ca.afilias.info> References: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@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 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: Wed, 02 Feb 2011 18:04:50 -0000 --On Sunday, January 30, 2011 16:02 -0500 Joseph Yee wrote: > 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. Joseph, Three observations: (1) I believe that, despite the apparent imprecision, the terminology we are now using is quite common in i18n work, both inside and outside the IETF and that we risk at least as much confusion by trying to adopt terminology that is unique to EAI as we do by sticking with terminology now in the documents, checking that terminology for accurate use as needed. (2) I think we know from experience that trying to rearrange the terminology in late-stage documents (I hope that these are late-stage, at least wrt the underlying protocols) often introduces errors and inconsistencies. That is a fairly high price to pay for what appears to me to be a small marginal improvement in clarity (again, the terminology used in these specs is, in general, the same as that used in the IETF and elsewhere in i18n contexts). (3) In our respective copious spare time, Paul Hoffman and I are working on an update to RFC 3536. That update will both fold in some newer terminology and will update some of the old definitions to be explicit about possible ambiguities and the problems they may introduce. > 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. See (3) above. Note that such a draft should, IMO, not become the responsibility of this WG although I would hope that EAI WG participants would have a look at it and comment. So I guess my answer to the consensus question is "no change needed". john From Shawn.Steele@microsoft.com Wed Feb 2 12:48: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 E0E483A6846 for ; Wed, 2 Feb 2011 12:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 CQh-kngMgOle for ; Wed, 2 Feb 2011 12:48:28 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 9E2EC3A6DAC for ; Wed, 2 Feb 2011 12:48:26 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Feb 2011 12:51:46 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Wed, 2 Feb 2011 12:51:46 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Result on Issue #1 - Parameter on MAIL Thread-Index: AcvDGodqNLUBb817Rk+IJcpJf8lthg== Date: Wed, 2 Feb 2011 20:51:45 +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: Wed, 02 Feb 2011 20:48:29 -0000 This works for me. "If the client is aware" is a funny qualifier for SHOUL= D NOT, though the rest explains the logic fine and I can't think of a bette= r way to say it. -Shawn ------------------------------ Message: 2 Date: Wed, 02 Feb 2011 11:03:42 -0500 From: John C Klensin Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL To: ima@ietf.org Message-ID: <1DE6D9C69DF35A8C6F0B6C5C@PST.JCK.COM> Content-Type: text/plain; charset=3Dus-ascii ... If the envelope or message being sent requires the capabilities of these EAI extensions, the client MUST supply the UTF8SMTPbis parameter with the MAIL command. If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command. This specification does not require that the client inspect the message or otherwise go to extraordinary lengths to assure itself whether these EAI capabilities are required for the particular message. However, in mixed or transitional environments in which EAI is not completely deployed, more precision on the part of the client (sender) may prevent unnecessary message rejections. =20 From klensin@jck.com Wed Feb 2 13:40: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 DE3993A6DE1 for ; Wed, 2 Feb 2011 13:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 wV-rNThT9yUl for ; Wed, 2 Feb 2011 13:40:32 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 13D2A3A6DAF for ; Wed, 2 Feb 2011 13:40:31 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PkkUR-0009tK-HA; Wed, 02 Feb 2011 16:43:51 -0500 Date: Wed, 02 Feb 2011 16:43:50 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <9C4A82507D37FB7685D7E603@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] 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: Wed, 02 Feb 2011 21:40:33 -0000 --On Wednesday, February 02, 2011 20:51 +0000 Shawn Steele wrote: > This works for me. "If the client is aware" is a funny > qualifier for SHOULD NOT, though the rest explains the logic > fine and I can't think of a better way to say it. We have already done much the same thing in the discussion in IDNA2008 as to whether one is required to validate an A-label that one receives somehow (or can just look it up). The situations are a bit different and so are the convolutions, but the principle is the same: if you know, you are obligated to behave in a certain way but, if you have been able to avoid knowing, there is no obligation to find out. john From ned+ima@mrochek.com Wed Feb 2 13:56:54 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 ABD523A6DE1 for ; Wed, 2 Feb 2011 13:56:54 -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 FUAQLedN6pwD for ; Wed, 2 Feb 2011 13:56:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 8A9743A6ABE for ; Wed, 2 Feb 2011 13:56:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXCQHI5NHS00JKP5@mauve.mrochek.com> for ima@ietf.org; Wed, 2 Feb 2011 14:00:13 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXCMC4DDE800H4Y3@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 2 Feb 2011 14:00:09 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXCQHGU8VK00H4Y3@mauve.mrochek.com> Date: Wed, 02 Feb 2011 13:59:55 -0800 (PST) In-reply-to: "Your message dated Wed, 02 Feb 2011 20:51:45 +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=1296680900; bh=/nwhNE4+CBDElFxr5KilJ+Ww/rpS2Llq5YPruyjU6+Y=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=AL3HNHRhgAYe0gFzJb5PqUWU/mdyAlhPFslDc14eYJucXBR8yNIR0M++Jagmrwo4T 4BIvTQcSa+CPZY6iHUOdSlrajcMOayP7sbdu2J0vTcNV93QxGgMg80ovLe2/F0Y4tt oPWJJs3/4Y6mNGx/++T6pKP0JQdjz2exl0ahIvt4= Cc: "ima@ietf.org" 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: Wed, 02 Feb 2011 21:56:54 -0000 > This works for me. "If the client is aware" is a funny qualifier for SHOULD > NOT, though the rest explains the logic fine and I can't think of a better way > to say it. This works for me as well. Ned > -Shawn > ------------------------------ > Message: 2 > Date: Wed, 02 Feb 2011 11:03:42 -0500 > From: John C Klensin > Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL > To: ima@ietf.org > Message-ID: <1DE6D9C69DF35A8C6F0B6C5C@PST.JCK.COM> > Content-Type: text/plain; charset=us-ascii > ... > If the envelope or message being sent requires the > capabilities of these EAI extensions, the client MUST > supply the UTF8SMTPbis parameter with the MAIL command. > If the client is aware that the envelope or message > being sent does not require any of the EAI extension > capabilities, it SHOULD NOT supply the UTF8SMTPbis > parameter with the MAIL command. This specification > does not require that the client inspect the message or > otherwise go to extraordinary lengths to assure itself > whether these EAI capabilities are required for the > particular message. However, in mixed or transitional > environments in which EAI is not completely deployed, > more precision on the part of the client (sender) may > prevent unnecessary message rejections. > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From ned+ima@mrochek.com Wed Feb 2 14:01: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 58C553A6E14 for ; Wed, 2 Feb 2011 14:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 BgryqpObXRAd for ; Wed, 2 Feb 2011 14:01:20 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 9CCAD3A6E15 for ; Wed, 2 Feb 2011 14:01:19 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXCQMZSY4W00J5WD@mauve.mrochek.com> for ima@ietf.org; Wed, 2 Feb 2011 14:04:38 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXCMC4DDE800H4Y3@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 2 Feb 2011 14:04:35 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXCQMYNXBS00H4Y3@mauve.mrochek.com> Date: Wed, 02 Feb 2011 14:03:57 -0800 (PST) In-reply-to: "Your message dated Wed, 02 Feb 2011 13:08:08 -0500" <90D3E0A8D0BC28666D7BFBB4@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@ca.afilias.info> <90D3E0A8D0BC28666D7BFBB4@PST.JCK.COM> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296681166; bh=QHMB9Zy1YsTEsAN86RslAcCRedU0J5lHTgFlqsKNR8g=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=tMbeS+5xSeNOTdjj0CXueA7Ef63K7lD71gl6LXC0tOUaTU0TvaB8Ue8R43+ig/IeM s69QnaLIMlJ+INqJYF/qI+cY21xxWcEoSjglslnnFRsw4xy0670BV2bDwUOh7Gm5iu fMMsRhLJNeM6HjLIhZsOSOqbxGyYwUYgBDH/INt8= Cc: EAI WG Subject: Re: [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: Wed, 02 Feb 2011 22:01:21 -0000 I generally agree and I'm not happy with any of the proposed alternatives, so I guess my answer is "no change needed" as well. Ned > --On Sunday, January 30, 2011 16:02 -0500 Joseph Yee > wrote: > > 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. > Joseph, > Three observations: > (1) I believe that, despite the apparent imprecision, the > terminology we are now using is quite common in i18n work, both > inside and outside the IETF and that we risk at least as much > confusion by trying to adopt terminology that is unique to EAI > as we do by sticking with terminology now in the documents, > checking that terminology for accurate use as needed. > (2) I think we know from experience that trying to rearrange the > terminology in late-stage documents (I hope that these are > late-stage, at least wrt the underlying protocols) often > introduces errors and inconsistencies. That is a fairly high > price to pay for what appears to me to be a small marginal > improvement in clarity (again, the terminology used in these > specs is, in general, the same as that used in the IETF and > elsewhere in i18n contexts). > (3) In our respective copious spare time, Paul Hoffman and I are > working on an update to RFC 3536. That update will both fold > in some newer terminology and will update some of the old > definitions to be explicit about possible ambiguities and the > problems they may introduce. > > 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. > See (3) above. Note that such a draft should, IMO, not become > the responsibility of this WG although I would hope that EAI WG > participants would have a look at it and comment. > So I guess my answer to the consensus question is "no change > needed". > john > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From johnl@iecc.com Wed Feb 2 18:29: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 DC35D3A67A7 for ; Wed, 2 Feb 2011 18:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.087 X-Spam-Level: X-Spam-Status: No, score=-111.087 tagged_above=-999 required=5 tests=[AWL=0.112, 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 ZAPplgcjpW4v for ; Wed, 2 Feb 2011 18:29:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id E52B43A659A for ; Wed, 2 Feb 2011 18:29:26 -0800 (PST) Received: (qmail 71516 invoked from network); 3 Feb 2011 02:32:46 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 3 Feb 2011 02:32:46 -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=206f.4d4a13ce.k1102; i=johnl@user.iecc.com; bh=Vew4LVEwdwcdXq7jBI7e0LK7R1RUVCHrZVtneI2MhVQ=; b=qxrKjBDmE927vxuneXrUBdQ2muBtMD8tGdM/Y2pMZVntsRb5ucy5PUmtV6NbMq5L9WtJ4Gxz/FGXu7vl6It+0S+AnzIDjupwLu26TBJ9rcdr82oAD1Fw8KUad+RbFxGgkdd7KPImhSIC6XgyVk8nS3tvpk3sPGXR7pvBj96q/go= 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=206f.4d4a13ce.k1102; olt=johnl@user.iecc.com; bh=Vew4LVEwdwcdXq7jBI7e0LK7R1RUVCHrZVtneI2MhVQ=; b=OAqpgsT5//5hxBv0r6mZLG+YiuoAe3P8U2ImZrLhu2gBpvgsqiRdYde71ufBMAtufBY2LvuSRJtPsUVZLYmxa0zClIqnuE7TS036w//NcIZQBjhxWEOj+n51HDhSvCuoNruiBFWW0nHnR80qNHeNQeYal3sUov7/pm3Yi/68yLI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Feb 2011 02:32:46 -0000 Message-ID: <20110203023246.8302.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <1DE6D9C69DF35A8C6F0B6C5C@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 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: Thu, 03 Feb 2011 02:29:29 -0000 > If the envelope or message being sent requires the > capabilities of these EAI extensions, the client MUST > supply the UTF8SMTPbis parameter with the MAIL command. > > If the client is aware that the envelope or message > being sent does not require any of the EAI extension > capabilities, it SHOULD NOT supply the UTF8SMTPbis > parameter with the MAIL command. This specification > does not require that the client inspect the message or > otherwise go to extraordinary lengths to assure itself > whether these EAI capabilities are required for the > particular message. However, in mixed or transitional > environments in which EAI is not completely deployed, > more precision on the part of the client (sender) may > prevent unnecessary message rejections. OK by me, reflects both good practice and the limits of what we can demand that coders do. R's, John From dhc2@dcrocker.net Wed Feb 2 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 731A93A6778 for ; Wed, 2 Feb 2011 19:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 rLIJ3v4lPoCu for ; Wed, 2 Feb 2011 19:05:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 80E4A3A65A5 for ; Wed, 2 Feb 2011 19:05:40 -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 p1338u91002510 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 2 Feb 2011 19:09:01 -0800 Message-ID: <4D4A1C30.7030204@dcrocker.net> Date: Wed, 02 Feb 2011 19:08:32 -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: <1DE6D9C69DF35A8C6F0B6C5C@PST.JCK.COM> In-Reply-To: <1DE6D9C69DF35A8C6F0B6C5C@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]); Wed, 02 Feb 2011 19:09:01 -0800 (PST) Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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: Thu, 03 Feb 2011 03:05:41 -0000 On 2/2/2011 8:03 AM, John C Klensin wrote: > If the client is aware that the envelope or message > being sent does not require any of the EAI extension > capabilities, it SHOULD NOT supply the UTF8SMTPbis > parameter with the MAIL command. This specification > does not require that the client inspect the message or > otherwise go to extraordinary lengths to assure itself > whether these EAI capabilities are required for the > particular message. However, in mixed or transitional > environments in which EAI is not completely deployed, > more precision on the part of the client (sender) may > prevent unnecessary message rejections. So, the goal is to guarantee that no environment can ever be certain of operating in a simplified, "pure" UTF-8 mode? As phrased, this language requires permanent support for legacy ASCII mode. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From eai@troystarr.net Wed Feb 2 19: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 62C643A67B4 for ; Wed, 2 Feb 2011 19:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 N9e0glIy4Qyf for ; Wed, 2 Feb 2011 19:26:33 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id CA1263A67A1 for ; Wed, 2 Feb 2011 19:26:31 -0800 (PST) Received: from FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8]) by FORGE.foundry.home ([fe80::ad0e:5a01:9a0:c9a8%10]) with mapi; Wed, 2 Feb 2011 19:29:52 -0800 From: Troy Starr To: 'John C Klensin' , "'ima@ietf.org'" Date: Wed, 2 Feb 2011 19:29:50 -0800 Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL Thread-Index: AcvDFEhFbhcWdxESTVO+IILp/cVYEwAOk+0w Message-ID: References: <1DE6D9C69DF35A8C6F0B6C5C@PST.JCK.COM> In-Reply-To: <1DE6D9C69DF35A8C6F0B6C5C@PST.JCK.COM> 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 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: Thu, 03 Feb 2011 03:26:34 -0000 Hi John - > If the envelope or message being sent requires the > capabilities of these EAI extensions, the client MUST > supply the UTF8SMTPbis parameter with the MAIL command. >=20 > If the client is aware that the envelope or message > being sent does not require any of the EAI extension > capabilities, it SHOULD NOT supply the UTF8SMTPbis > parameter with the MAIL command. This specification > does not require that the client inspect the message or > otherwise go to extraordinary lengths to assure itself > whether these EAI capabilities are required for the > particular message. However, in mixed or transitional > environments in which EAI is not completely deployed, > more precision on the part of the client (sender) may > prevent unnecessary message rejections. I agree with the MUST in the first paragraph and the SHOULD NOT in the seco= nd paragraph. In the first sentence of the second paragraph, I don't think we want "or" s= ince you would only omit the UTF8SMTPbis parameter if neither the envelope = nor the message required EAI capabilities. So I would use a neither/nor co= mbination, or just switch the "or" to "and" to make it clear that both cond= itions must be satisfied to omit the UTF8SMTPbis parameter. I'm a little iffy about "This specification does not require that the clien= t inspect the message or otherwise go to extraordinary lengths to assure it= self whether these EAI capabilities are required for the particular message= ." This sentence might suggest that I don't need to be sure that this is a= n EAI message, and therefore I don't need to add the UTF8SMTPbis parameter = to the MAIL command. Even though we had the MUST in the first paragraph, I= think this could create some ambiguity. I think we could make this cleare= r by stating that the client isn't required to verify that this isn't an EA= I message. Something along the lines of: This specification does not require that the client inspect the message or = otherwise go to extraordinary lengths to assure itself that EAI capabilitie= s are not required for the particular message. - Troy Starr From johnl@iecc.com Wed Feb 2 20:44: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 5A8BB3A67A2 for ; Wed, 2 Feb 2011 20:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.09 X-Spam-Level: X-Spam-Status: No, score=-111.09 tagged_above=-999 required=5 tests=[AWL=0.109, 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 0gtaGctwZLET for ; Wed, 2 Feb 2011 20:44:15 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 18E3A3A6778 for ; Wed, 2 Feb 2011 20:44:14 -0800 (PST) Received: (qmail 93481 invoked from network); 3 Feb 2011 04:47:35 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 3 Feb 2011 04:47:35 -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=a4b0.4d4a3367.k1102; i=johnl@user.iecc.com; bh=b5UX3Y5jVZK/dSM34pMAJCsPfbV2BiBebsFCnV3HhNI=; b=jIBhf3zlTEK5tB7OwWfOOsQARGA937Q6+3NOGWfBFo8FDqh4f5f1ybpjJOkCNAtz4zZR7vo1SFqSCdWq4iVzI0fZquFes4+kuRyyi18YO/yZ1ppJIRIwHfbmifxphW++OBS3gNLRYEJC2jb/uClw/qNSwTnt0M0ka0jt/O+P6/o= 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=a4b0.4d4a3367.k1102; olt=johnl@user.iecc.com; bh=b5UX3Y5jVZK/dSM34pMAJCsPfbV2BiBebsFCnV3HhNI=; b=nSGHfi1NYYDtWVl8Y2BfvQj8GeecP0ijJUa5Gacm8LPiHVXCnQ5V9PQu6x9W08H3jVHedoGXYPG+1VEdUB1V0LeSzuSMPjp1RxIpLvOSa3MILRTr/+k6TIWxlXukQzHANY+Wr5+M1GkgFcKkl1maNSwzWnhGtSXMFcEU1FXApGg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Feb 2011 04:47:35 -0000 Message-ID: <20110203044735.42159.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D4A1C30.7030204@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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Feb 2011 04:44:16 -0000 >So, the goal is to guarantee that no environment can ever be certain of >operating in a simplified, "pure" UTF-8 mode? > >As phrased, this language requires permanent support for legacy ASCII mode. I'm having trouble understanding the objection here. In the far off day when everyone does EAI, since ASCII messages are a subset of UTF-8 messages, a server that does not care about the distinction between them can ignore the flag and treat all messages as EAI, and a client that doesn't care can set the flag on everything. Unless you're proposing a server "send EAI or else" flag, I don't see what you want to change. R's, John From Claudio.Allocchio@garr.it Thu Feb 3 00:19: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 53FA53A68A6 for ; Thu, 3 Feb 2011 00:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 xZpUKVRR2dP7 for ; Thu, 3 Feb 2011 00:19:31 -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 74E5E3A68A4 for ; Thu, 3 Feb 2011 00:19:30 -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 p138MkgF043590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 09:22:47 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p138MkgF043590 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Q5v4QhrlkQjh3FSgAqtGkZO9vSrVYTscZ8mZWMAQgk15G1eO8/4YoAa5zVO8Sp/oq 0AicPJ5hzm+XX/6HAQa83GVTn0jJhyqSn6sGi+zLpKi0iR+4toA12F49DMT0QA6ZH/j nEVtIjHjafMfsU2dIvyElNE5/aZ2VYItjM5ExI0= Date: Thu, 3 Feb 2011 09:22:46 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: John Levine In-Reply-To: <20110203023246.8302.qmail@joyce.lan> Message-ID: References: <20110203023246.8302.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org 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: Thu, 03 Feb 2011 08:19:32 -0000 On Thu, 3 Feb 2011, John Levine wrote: >> If the envelope or message being sent requires the >> capabilities of these EAI extensions, the client MUST >> supply the UTF8SMTPbis parameter with the MAIL command. +1 >> >> If the client is aware that the envelope or message >> being sent does not require any of the EAI extension >> capabilities, it SHOULD NOT supply the UTF8SMTPbis >> parameter with the MAIL command. +1 to keep alive an ASCII only legacy world forever. "MAY NOT" if we wish the UTF-8 environment gradually become the legacy situation. It is not a nit, it is a phylosophical assesment. >> This specification >> does not require that the client inspect the message or >> otherwise go to extraordinary lengths to assure itself >> whether these EAI capabilities are required for the >> particular message. However, in mixed or transitional >> environments in which EAI is not completely deployed, >> more precision on the part of the client (sender) may >> prevent unnecessary message rejections. > mmmhhhh... it is an attempt to explain why, but... do we really to phrase it like this? I share aother comments doubts here. ------------------------------------------------------------------------------ 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 Thu Feb 3 02:20: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 A8C843A68B1 for ; Thu, 3 Feb 2011 02:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.825 X-Spam-Level: X-Spam-Status: No, score=-3.825 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 ifnsGNRA+97h for ; Thu, 3 Feb 2011 02:20: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 0911A3A68EF for ; Thu, 3 Feb 2011 02:20: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 AB0CD221A8 for ; Thu, 3 Feb 2011 10:24:09 +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, 03 Feb 2011 10:24:09 +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 p13AO88v013610 for ; Thu, 3 Feb 2011 10:24:09 GMT Date: Thu, 03 Feb 2011 10:24:08 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <1DE6D9C69DF35A8C6F0B6C5C@PST.JCK.COM> <4D4A1C30.7030204@dcrocker.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4D4A1C30.7030204@dcrocker.net> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d4a8249.104a4-1681-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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Feb 2011 10:20:51 -0000 On Thu, 03 Feb 2011 03:08:32 -0000, Dave CROCKER wrote: > On 2/2/2011 8:03 AM, John C Klensin wrote: >> If the client is aware that the envelope or message >> being sent does not require any of the EAI extension >> capabilities, it SHOULD NOT supply the UTF8SMTPbis >> parameter with the MAIL command. This specification >> does not require that the client inspect the message or >> otherwise go to extraordinary lengths to assure itself >> whether these EAI capabilities are required for the >> particular message. However, in mixed or transitional >> environments in which EAI is not completely deployed, >> more precision on the part of the client (sender) may >> prevent unnecessary message rejections. > > > So, the goal is to guarantee that no environment can ever be certain of > operating in a simplified, "pure" UTF-8 mode? > > As phrased, this language requires permanent support for legacy ASCII > mode. Then I suggest s/it SHOULD NOT supply .../ it MAY omit the UTF8SMTPbis parameter with the MAIL command. Indeed it is advisable to do so for reasons yadda yadda yadda/ Where the "Indeed ..." sentence might be better as a NOTE, and the "yadda yadda yadda" should cover the "extraordinary lengths" and "mixed or transitional environments" stuff, suitably reworded. -- 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 yaojk@cnnic.cn Thu Feb 3 02:37: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 C5A243A68B1 for ; Thu, 3 Feb 2011 02:37:33 -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.901 X-Spam-Level: X-Spam-Status: No, score=-98.901 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, STOX_REPLY_TYPE=0.001, 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 yW91d5k1Aszo for ; Thu, 3 Feb 2011 02:37:33 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 997AE3A6898 for ; Thu, 3 Feb 2011 02:37:32 -0800 (PST) Received: (eyou send program); Thu, 03 Feb 2011 18:40:51 +0800 Message-ID: <496729651.05410@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 03 Feb 2011 18:40:51 +0800 Message-ID: <005d01cbc38e$d4780980$cb01a8c0@YaoJK> From: "Yao Jiankang" To: "John C Klensin" , References: <496662674.26134@cnnic.cn> Date: Thu, 3 Feb 2011 18:40:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 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: Thu, 03 Feb 2011 10:37:34 -0000 ----- Original Message ----- From: "John C Klensin" To: Sent: Thursday, February 03, 2011 12:03 AM Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL > Hi. > > Because I really don't have any strong feeling about this issue > other than: > > (i) When 5336bis is revised to reflect the parameter, it > must be absolutely clear and precise about what the > parameter means. > +1 > > (ii) We need to keep this as simple as possible (but, in > Wirth's words, no simpler). > +1 I strongly support the two principles above. Jiankang Yao From klensin@jck.com Thu Feb 3 05:28: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 0516B3A6923 for ; Thu, 3 Feb 2011 05:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 msNoAB2xtOcT for ; Thu, 3 Feb 2011 05:28:13 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EE9C53A68F8 for ; Thu, 3 Feb 2011 05:28:12 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PkzHZ-0004YR-NK; Thu, 03 Feb 2011 08:31:33 -0500 Date: Thu, 03 Feb 2011 08:31:33 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: In-Reply-To: <20110203044735.42159.qmail@joyce.lan> References: <20110203044735.42159.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] 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: Thu, 03 Feb 2011 13:28:14 -0000 --On Thursday, February 03, 2011 04:47 +0000 John Levine wrote: >> So, the goal is to guarantee that no environment can ever be >> certain of operating in a simplified, "pure" UTF-8 mode? >> >> As phrased, this language requires permanent support for >> legacy ASCII mode. > I'm having trouble understanding the objection here. In the > far off day when everyone does EAI, since ASCII messages are a > subset of UTF-8 messages, a server that does not care about > the distinction between them can ignore the flag and treat all > messages as EAI, and a client that doesn't care can set the > flag on everything. Or, put differently, a server that does not care can ignore the flag, making it completely irrelevant what the client does. So, if the client happens to know and care, it is careful about sending the flag and, if it has been updated to know that no server cares any more, it just sends it always. That said, we've still got clients and servers who are operating in pure 821 mode, i.e., sending only HELO and accepting only HELO. A few of the clients aren't even spammers or bots. That has been 18 years and, while I think we are in the tail of that curve, we aren't going to see the end of the asymptote any time soon. Remembering that clients have to support pure-ASCII mode (and, for the older cases, pure-821 mode) to have any hope or getting mail to such servers and that servers have to support it (independent of whatever "only spammers are that retarded" scores they assign) in order to have any hope of receiving mail from such clients, I just can't visualize the point at which it will be possible to remove all code for ASCII-only situations. > Unless you're proposing a server "send EAI or else" flag, I > don't see what you want to change. Indeed. john From klensin@jck.com Thu Feb 3 05:51: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 D904E3A6940 for ; Thu, 3 Feb 2011 05:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 y+Ye73iP5ke8 for ; Thu, 3 Feb 2011 05:51:01 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B812B3A690B for ; Thu, 3 Feb 2011 05:51:00 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pkzdc-0005F0-77; Thu, 03 Feb 2011 08:54:20 -0500 Date: Thu, 03 Feb 2011 08:54:19 -0500 From: John C Klensin To: Claudio Allocchio , John Levine Message-ID: <27874413A115F12BA73F8E05@PST.JCK.COM> In-Reply-To: References: <20110203023246.8302.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: ima@ietf.org 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: Thu, 03 Feb 2011 13:51:08 -0000 --On Thursday, February 03, 2011 09:22 +0100 Claudio Allocchio wrote: >... >>> If the client is aware that the envelope or message >>> being sent does not require any of the EAI extension >>> capabilities, it SHOULD NOT supply the UTF8SMTPbis >>> parameter with the MAIL command. > > +1 to keep alive an ASCII only legacy world forever. > > "MAY NOT" if we wish the UTF-8 environment gradually become > the legacy situation. It is not a nit, it is a phylosophical > assesment. I don't think it is a nit, but I was trying to summarize what I saw on the list (I may not have gotten that right). I do see this as an operational issue: especially in the short-term environment in which there are going to be lots more non-EAI-capable servers around than EAI-capable ones, being careful about that parameter will make the difference between whether ASCII-only (i.e., 5321/5322 conforming) messages are delivered or rejected. It seems to me to be clearly advantageous to have more, rather than fewer messages delivered and to avoid unnecessary rejections. Remember that messages that are claimed to require EAI MUST NOT be sent unless the server advertises the capability. So, if a relay receives a message that appears to require EAI (parameter sent to it on the MAIL command) and the next hop doesn't advertise the capability, that relay must either - reject the message as stated to require EAI functionality but having no host to which it can be delivered - scan the envelope and message to determine whether it can safely drop the flag - risk violating 5321/5322 by sending a message that potentially requires the EAI extensions without getting a server OK for using those extensions. Whatever me might think of the third, we cannot specify it as an acceptable option. The choice between the first two seems to me to be an implementation or operational choice, not one that we should try to specify in a standard (but I can easily imagine a "how sure do you want to be before sending the parameter" knob for locally tuning an implementation). In environments in which clients know that all, or substantially all, servers support EAI, MAY may be more appropriate but, if their users communicate outside that environment, they will still probably want to do the checking and be careful about what functions they claim they require. My own personal sense is that we are better off with SHOULD NOT now. When these specs are revised or updated in the future, the state of the network and EAI deployment should be assessed and the language changed to MAY (and the explanation retuned) as needed. While I think it would confuse more than it would help, one could also add an explanation of how the operational reading of "SHOULD NOT" might evolve with increasing EIA deployment. >>> This specification >>> does not require that the client inspect the message or >>> otherwise go to extraordinary lengths to assure itself >>> whether these EAI capabilities are required for the >>> particular message. However, in mixed or transitional >>> environments in which EAI is not completely deployed, >>> more precision on the part of the client (sender) may >>> prevent unnecessary message rejections. > mmmhhhh... it is an attempt to explain why, but... do we > really to phrase it like this? I share aother comments doubts > here. FWIW, it was intended less as an explanation of why than as an relatively brief explanation of when one would want to ignore the SHOULD. I was remembering an earlier comment from Dave asking why one would not want to send the parameter and therefore why the statement would not be "EAI-capable clients talking with EAI-capable servers MUST always send the parameter". He and I are in agreement that SHOULD statements should (sic) almost always be accompanied of an explanation of when it was reasonable to make an exception, so I was trying to supply one. john p.s. I did not intend my language to be inserted into the document, so nit-picking it (again, I don't consider the SHOULD/MAY distinction to be a nit) is probably not useful. If we can agree on the intent, let's see what the authors come up with. From Claudio.Allocchio@garr.it Thu Feb 3 06:09: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 DC0213A6961 for ; Thu, 3 Feb 2011 06:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 QoNa-d9dKmJy for ; Thu, 3 Feb 2011 06:09:23 -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 BC6AF3A6962 for ; Thu, 3 Feb 2011 06:09:22 -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 p13ECa2Y056599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 15:12:36 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p13ECa2Y056599 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=sL723RuTsMfCVKoNEBM9nSit1y2ATeyyDQD8rTCX0PYvkrPid5bkBouBka6Ky/+wh qRGZy9AagZ9/J2h1tcHe7NuLkZ1WcpW6e1ZVFf+7Q6BQLpKGulIWzEVeuqbBV9UgKWt nWipzadNjVQIIIjzGf7+z9l4B67y17J0As+6tQU= Date: Thu, 3 Feb 2011 15:12:35 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: John C Klensin In-Reply-To: <27874413A115F12BA73F8E05@PST.JCK.COM> Message-ID: References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Claudio Allocchio , ima@ietf.org 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: Thu, 03 Feb 2011 14:09:25 -0000 On Thu, 3 Feb 2011, John C Klensin wrote: > > > --On Thursday, February 03, 2011 09:22 +0100 Claudio Allocchio > wrote: > >> ... >>>> If the client is aware that the envelope or message >>>> being sent does not require any of the EAI extension >>>> capabilities, it SHOULD NOT supply the UTF8SMTPbis >>>> parameter with the MAIL command. >> >> +1 to keep alive an ASCII only legacy world forever. >> >> "MAY NOT" if we wish the UTF-8 environment gradually become >> the legacy situation. It is not a nit, it is a phylosophical >> assesment. > > I don't think it is a nit, but I was trying to summarize what I > saw on the list (I may not have gotten that right). I do see > this as an operational issue: especially in the short-term > environment in which there are going to be lots more > non-EAI-capable servers around than EAI-capable ones, being > careful about that parameter will make the difference between > whether ASCII-only (i.e., 5321/5322 conforming) messages are > delivered or rejected. It seems to me to be clearly > advantageous to have more, rather than fewer messages delivered > and to avoid unnecessary rejections. > > Remember that messages that are claimed to require EAI MUST NOT > be sent unless the server advertises the capability. So, if a > relay receives a message that appears to require EAI (parameter > sent to it on the MAIL command) and the next hop doesn't > advertise the capability, that relay must either > > - reject the message as stated to require EAI > functionality but having no host to which it can be > delivered > > - scan the envelope and message to determine whether it > can safely drop the flag > > - risk violating 5321/5322 by sending a message that > potentially requires the EAI extensions without getting > a server OK for using those extensions. > > Whatever me might think of the third, we cannot specify it as an > acceptable option. The choice between the first two seems to me > to be an implementation or operational choice, not one that we > should try to specify in a standard (but I can easily imagine a > "how sure do you want to be before sending the parameter" knob > for locally tuning an implementation). > > In environments in which clients know that all, or substantially > all, servers support EAI, MAY may be more appropriate but, if > their users communicate outside that environment, they will > still probably want to do the checking and be careful about what > functions they claim they require. > > My own personal sense is that we are better off with SHOULD NOT > now. When these specs are revised or updated in the future, the > state of the network and EAI deployment should be assessed and > the language changed to MAY (and the explanation retuned) as > needed. While I think it would confuse more than it would help, > one could also add an explanation of how the operational reading > of "SHOULD NOT" might evolve with increasing EIA deployment. yes, SHOULD NOT is better for current situation, and MAY NOT will become more appropriate with time. And we can always change it during the document updates. >>>> This specification >>>> does not require that the client inspect the message or >>>> otherwise go to extraordinary lengths to assure itself >>>> whether these EAI capabilities are required for the >>>> particular message. However, in mixed or transitional >>>> environments in which EAI is not completely deployed, >>>> more precision on the part of the client (sender) may >>>> prevent unnecessary message rejections. > >> mmmhhhh... it is an attempt to explain why, but... do we >> really to phrase it like this? I share aother comments doubts >> here. > > FWIW, it was intended less as an explanation of why than as an > relatively brief explanation of when one would want to ignore > the SHOULD. I was remembering an earlier comment from Dave > asking why one would not want to send the parameter and > therefore why the statement would not be "EAI-capable clients > talking with EAI-capable servers MUST always send the > parameter". He and I are in agreement that SHOULD statements > should (sic) almost always be accompanied of an explanation of > when it was reasonable to make an exception, so I was trying to > supply one. ok. But the language at first read did not seem to convey that (at least to me...). that was my objection. > > john > > p.s. I did not intend my language to be inserted into the > document, so nit-picking it (again, I don't consider the > SHOULD/MAY distinction to be a nit) is probably not useful. If > we can agree on the intent, let's see what the authors come up > with. > > > > ------------------------------------------------------------------------------ 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 Thu Feb 3 08:03: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 95A6C3A69A1 for ; Thu, 3 Feb 2011 08:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.561, 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 nOV+uZAWD+Gy for ; Thu, 3 Feb 2011 08:03:55 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 866703A69F0 for ; Thu, 3 Feb 2011 08:03:55 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pl1iE-0008wP-TI; Thu, 03 Feb 2011 11:07:15 -0500 Date: Thu, 03 Feb 2011 11:07:14 -0500 From: John C Klensin To: Claudio Allocchio Message-ID: <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> In-Reply-To: References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@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: ima@ietf.org 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: Thu, 03 Feb 2011 16:03:56 -0000 --On Thursday, February 03, 2011 15:12 +0100 Claudio Allocchio wrote: >... >> My own personal sense is that we are better off with SHOULD >> NOT now. When these specs are revised or updated in the >> future, the state of the network and EAI deployment should be >> assessed and the language changed to MAY (and the explanation >> retuned) as needed. While I think it would confuse more than >> it would help, one could also add an explanation of how the >> operational reading of "SHOULD NOT" might evolve with >> increasing EIA deployment. > > yes, SHOULD NOT is better for current situation, and MAY NOT > will become more appropriate with time. And we can always > change it during the document updates. I don't know how others in the WG --especially those who are likely to have to do the work-- feel about this but my preference is that we try to get a complete and competent protocol spec out as quickly as we can now, focusing on what people should do in the short term/ early transition phrase as appropriate. We should then move to revise as soon as we have implementations and deployment experience. In other words, I think we will need to revise in a few years or less anyway and should not spend energy now trying to make sure we have all the language exactly correct. Again, that is mostly personal opinion, but it is more consistent with the objective to get things done quickly than a lot of fine-tuning. >>>>> This specification >>>>> does not require that the client inspect the message or >>>>> otherwise go to extraordinary lengths to assure itself >... >> FWIW, it was intended less as an explanation of why than as an >> relatively brief explanation of when one would want to ignore >> the SHOULD. I was remembering an earlier comment from Dave >> asking why one would not want to send the parameter and >> therefore why the statement would not be "EAI-capable clients >> talking with EAI-capable servers MUST always send the >> parameter". He and I are in agreement that SHOULD statements >> should (sic) almost always be accompanied of an explanation of >> when it was reasonable to make an exception, so I was trying >> to supply one. > > ok. But the language at first read did not seem to convey that > (at least to me...). that was my objection. On second reading, I agree that might not be clear enough. Let's see if we can reach agreement on intent (so far, Dave's objection is the only one I remember seeing and both John L and I have wondered about its implications) and then have the authors/editors propose specific language... which we can then tune to the extent needed. best, john From McQuilWP@pobox.com Thu Feb 3 09:39: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 AF1323A6A3C for ; Thu, 3 Feb 2011 09:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 Ul9kqbzinM9p for ; Thu, 3 Feb 2011 09:39:11 -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 838FE3A6A39 for ; Thu, 3 Feb 2011 09:39:11 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 9BA801C03; Thu, 3 Feb 2011 12:42:33 -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=wRxUeiaYF5XI XMKN3SM6uFDRrBY=; b=HWNWiy2XkCmBbYyz9r3H5ilR2U6zDrfgdWCR6h/awH9w QwTEpGOwmVA4QBTde5K6z1dBqxyCTciORPoKajCheIuzuBc1syXdr1z9pqyIVh9Z y97Myq/07jqTnuo3UPf4IFk2+XsqFADx6Zfn3scV/RZpTSCsTF5KJ9SGDj1QpkM= 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=RrwKjI GdPTGHwvhIkMOs9j0pe1ORaOC4ydP5IXzWD737e89TDYahhVT7HWDJqkffedoEOi 65lCRwEQj8yKRBIzWjDaO4GLwPo5+Ik/4karYOG8b//F4N8z9orrAiDX0GExTEs4 XZLascCGid6ycwsubCU4/TfxG4VVyJzU7bhzQ= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 85C671C02; Thu, 3 Feb 2011 12:42:32 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id F2C991C01; Thu, 3 Feb 2011 12:42:30 -0500 (EST) Date: Thu, 3 Feb 2011 09:42:28 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1293330888.20110203094228@pobox.com> To: IMA Discussion In-Reply-To: <27874413A115F12BA73F8E05@PST.JCK.COM> References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 X-Pobox-Relay-ID: FA8F1E0C-2FBC-11E0-B364-CB67DEC31506-02871704!b-pb-sasl-quonix.pobox.com Content-Transfer-Encoding: quoted-printable 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: Thu, 03 Feb 2011 17:39:12 -0000 On Thu, 2011-02-03, John C Klensin wrote: > Remember that messages that are claimed to require EAI MUST NOT > be sent unless the server advertises the capability. So, if a > relay receives a message that appears to require EAI (parameter > sent to it on the MAIL command) and the next hop doesn't > advertise the capability, that relay must either=20 > - reject the message as stated to require EAI > functionality but having no host to which it can be > delivered =09 > - scan the envelope and message to determine whether it > can safely drop the flag =09 > - risk violating 5321/5322 by sending a message that > potentially requires the EAI extensions without getting > a server OK for using those extensions. It seems to me that this raises another concern for the maximum reliabili= ty of message propagation. The fact that, while the message itself will not change with respect to whether it requires EAI of not, The *envelope* may as it progresses from hop to hop. For instance, a mailing list message with ASCII only content is to be distributed to a number of subscribers, some of which have EAI addresses.= A simple-minded mailer would send MAIL FROM: with the EAI flag set and then= a bunch of RCPT TO: commands with a few containing EAI-requiring addresses. Note that as the message is forwarded to subsequent MTAs, eventually some of the message copies will have only recipients with ASCII addresses. Who is responsible for noting that the EAI flag is no longer needed? Maybe the correct way to handle this is to have the original mailer segregate the EAI-requiring recipients into a separate transaction. Is it appropriate for this spec to mention this advice? --=20 Bill McQuillan From Shawn.Steele@microsoft.com Thu Feb 3 10:11: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 F2E5B3A6A4B for ; Thu, 3 Feb 2011 10:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.85 X-Spam-Level: X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=-0.491, 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 5L4Rx2ttIpRV for ; Thu, 3 Feb 2011 10:11:39 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4AE563A69F3 for ; Thu, 3 Feb 2011 10:11:39 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Feb 2011 10:15:01 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 10:15:01 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Should/may Thread-Index: AQHLw85Fpzt/w9NFYUakDGNm8FxP1w== Date: Thu, 3 Feb 2011 18:15: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.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Feb 2011 18:11:42 -0000 Pj4gICAgICBJZiB0aGUgY2xpZW50IGlzIGF3YXJlIHRoYXQgdGhlIGVudmVsb3BlIG9yIG1lc3Nh Z2UNCj4+ICAgICAgYmVpbmcgc2VudCBkb2VzIG5vdCByZXF1aXJlIGFueSBvZiB0aGUgRUFJIGV4 dGVuc2lvbg0KPj4gICAgICBjYXBhYmlsaXRpZXMsIGl0IFNIT1VMRCBOT1Qgc3VwcGx5IHRoZSBV VEY4U01UUGJpcw0KPj4gICAgICBwYXJhbWV0ZXIgd2l0aCB0aGUgTUFJTCBjb21tYW5kLg0KDQpJ J2QgYWxzbyBsZWFuIHRvd2FyZCBNQVkgTk9ULCBob3dldmVyIEknbSBub3QgdGhhdCBjb25jZXJu ZWQgYWJvdXQgaXQuICBJIGJlbGlldmUgdGhlIHByYWN0aWNhbCBpbXBsaWNhdGlvbiBpcyBsb3cu ICANCg0KKE1BWSBOT1QgaXMgbW9yZSBpbnRlcmVzdGluZyBpbiB0aGUgZnV0dXJlIHdoZW4gbW9y ZSBtYWlsIGlzIFVURi04LiAgVGhhdCBpbmNyZWFzZXMgdGhlIG9kZHMgdGhhdCB0aGUgY2xpZW50 IGlzIHVuYXdhcmUsIGluIHdoaWNoIFNIT1VMRCBOT1QgaXMgc3VmZmljaWVudC4gIElNTyAiTUFZ IE5PVCIgaGludHMgdGhhdCB0aGlzIG1pZ2h0IGJlIG1vcmUgY29tbW9uIGFuZCBzbyBpcyB1bnJl bGlhYmxlLiAgU0hPVUxEIE5PVCBhbHNvIGFsbG93cyB0aGUgInVuYXdhcmUiIGJlaGF2aW9yLCBh bmQgc28gdGhhdCB3b3JrcyB0b28sIGhvd2V2ZXIgaXQgZG9lc24ndCBwcm92aWRlIHRoZSBoaW50 IHRvIGRldmVsb3BlcnMgb2Ygc2VydmVycyB0aGF0IE1BWSBOT1QgcHJvdmlkZXMpLg0KDQpCdXQg SSBkb24ndCBjYXJlIG5lYXJseSBlbm91Z2ggdG8gcmF0aG9sZSBvbiB0aGlzLiAgRWl0aGVyIHdv cmtzIGZvciBtZS4NCg0KLVNoYXduDQoNCu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0 dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0KDQoiTUFZIE5PVCIgaWYgd2Ugd2lzaCB0aGUg VVRGLTggZW52aXJvbm1lbnQgZ3JhZHVhbGx5IGJlY29tZSB0aGUgbGVnYWN5DQpzaXR1YXRpb24u IEl0IGlzIG5vdCBhIG5pdCwgaXQgaXMgYSBwaHlsb3NvcGhpY2FsIGFzc2VzbWVudC4NCg0KDQo+ PiAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbg0KPj4gICAgICBkb2VzIG5vdCByZXF1aXJlIHRoYXQg dGhlIGNsaWVudCBpbnNwZWN0IHRoZSBtZXNzYWdlIG9yDQo+PiAgICAgIG90aGVyd2lzZSBnbyB0 byBleHRyYW9yZGluYXJ5IGxlbmd0aHMgdG8gYXNzdXJlIGl0c2VsZg0KPj4gICAgICB3aGV0aGVy IHRoZXNlIEVBSSBjYXBhYmlsaXRpZXMgYXJlIHJlcXVpcmVkIGZvciB0aGUNCj4+ICAgICAgcGFy dGljdWxhciBtZXNzYWdlLiAgSG93ZXZlciwgaW4gbWl4ZWQgb3IgdHJhbnNpdGlvbmFsDQo+PiAg ICAgIGVudmlyb25tZW50cyBpbiB3aGljaCBFQUkgaXMgbm90IGNvbXBsZXRlbHkgZGVwbG95ZWQs DQo+PiAgICAgIG1vcmUgcHJlY2lzaW9uIG9uIHRoZSBwYXJ0IG9mIHRoZSBjbGllbnQgKHNlbmRl cikgbWF5DQo+PiAgICAgIHByZXZlbnQgdW5uZWNlc3NhcnkgbWVzc2FnZSByZWplY3Rpb25zLg0K Pg0KDQptbW1oaGhoLi4uIGl0IGlzIGFuIGF0dGVtcHQgdG8gZXhwbGFpbiB3aHksIGJ1dC4uLiBk byB3ZSByZWFsbHkgdG8gcGhyYXNlDQppdCBsaWtlIHRoaXM/IEkgc2hhcmUgYW90aGVyIGNvbW1l bnRzIGRvdWJ0cyBoZXJlLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNsYXVkaW8gQWxsb2Nj aGlvICAgICAgICAgICAgIEcgICBBICAgUiAgIFIgICAgICAgICAgQ2xhdWRpby5BbGxvY2NoaW9A Z2Fyci5pdA0KICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmlvciBUZWNobmljYWwgT2ZmaWNl cg0KdGVsOiArMzkgMDQwIDM3NTg1MjMgICAgICBJdGFsaWFuIEFjYWRlbWljIGFuZCAgICAgICBH PUNsYXVkaW87IFM9QWxsb2NjaGlvOw0KZmF4OiArMzkgMDQwIDM3NTg1NjUgICAgICAgIFJlc2Vh cmNoIE5ldHdvcmsgICAgICAgICBQPWdhcnI7IEE9Z2FycjsgQz1pdDsNCg0KICAgICAgICAgICAg UEdQIEtleTogaHR0cDovL3d3dy5jZXJ0LmdhcnIuaXQvUEdQL2tleXMucGhwMyNjYQ0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAyDQpEYXRlOiBUaHUsIDAz IEZlYiAyMDExIDEwOjI0OjA4IC0wMDAwDQpGcm9tOiAiQ2hhcmxlcyBMaW5kc2V5IiA8Y2hsQGNs ZXJldy5tYW4uYWMudWs+DQpTdWJqZWN0OiBSZTogW0VBSV0gQ29uc2Vuc3VzIFJlc3VsdCBvbiBJ c3N1ZSAjMSAtIFBhcmFtZXRlciBvbiBNQUlMDQpUbzogSU1BIDxpbWFAaWV0Zi5vcmc+DQpNZXNz YWdlLUlEOiA8b3AudnFib2lpYTE2aGw4bm1AY2xlcmV3Lm1hbi5hYy51az4NCkNvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgZm9ybWF0PWZsb3dlZDsgZGVsc3A9eWVzOyBjaGFyc2V0PWlzby04ODU5 LTENCg0KT24gVGh1LCAwMyBGZWIgMjAxMSAwMzowODozMiAtMDAwMCwgRGF2ZSBDUk9DS0VSIDxk aGMyQGRjcm9ja2VyLm5ldD4gd3JvdGU6DQoNCj4gT24gMi8yLzIwMTEgODowMyBBTSwgSm9obiBD IEtsZW5zaW4gd3JvdGU6DQo+PiAgICAgIElmIHRoZSBjbGllbnQgaXMgYXdhcmUgdGhhdCB0aGUg ZW52ZWxvcGUgb3IgbWVzc2FnZQ0KPj4gICAgICBiZWluZyBzZW50IGRvZXMgbm90IHJlcXVpcmUg YW55IG9mIHRoZSBFQUkgZXh0ZW5zaW9uDQo+PiAgICAgIGNhcGFiaWxpdGllcywgaXQgU0hPVUxE IE5PVCBzdXBwbHkgdGhlIFVURjhTTVRQYmlzDQo+PiAgICAgIHBhcmFtZXRlciB3aXRoIHRoZSBN QUlMIGNvbW1hbmQuICBUaGlzIHNwZWNpZmljYXRpb24NCj4+ICAgICAgZG9lcyBub3QgcmVxdWly ZSB0aGF0IHRoZSBjbGllbnQgaW5zcGVjdCB0aGUgbWVzc2FnZSBvcg0KPj4gICAgICBvdGhlcndp c2UgZ28gdG8gZXh0cmFvcmRpbmFyeSBsZW5ndGhzIHRvIGFzc3VyZSBpdHNlbGYNCj4+ICAgICAg d2hldGhlciB0aGVzZSBFQUkgY2FwYWJpbGl0aWVzIGFyZSByZXF1aXJlZCBmb3IgdGhlDQo+PiAg ICAgIHBhcnRpY3VsYXIgbWVzc2FnZS4gIEhvd2V2ZXIsIGluIG1peGVkIG9yIHRyYW5zaXRpb25h bA0KPj4gICAgICBlbnZpcm9ubWVudHMgaW4gd2hpY2ggRUFJIGlzIG5vdCBjb21wbGV0ZWx5IGRl cGxveWVkLA0KPj4gICAgICBtb3JlIHByZWNpc2lvbiBvbiB0aGUgcGFydCBvZiB0aGUgY2xpZW50 IChzZW5kZXIpIG1heQ0KPj4gICAgICBwcmV2ZW50IHVubmVjZXNzYXJ5IG1lc3NhZ2UgcmVqZWN0 aW9ucy4NCj4NCj4NCj4gU28sIHRoZSBnb2FsIGlzIHRvIGd1YXJhbnRlZSB0aGF0IG5vIGVudmly b25tZW50IGNhbiBldmVyIGJlIGNlcnRhaW4gb2YNCj4gb3BlcmF0aW5nIGluIGEgc2ltcGxpZmll ZCwgInB1cmUiIFVURi04IG1vZGU/DQo+DQo+IEFzIHBocmFzZWQsIHRoaXMgbGFuZ3VhZ2UgcmVx dWlyZXMgcGVybWFuZW50IHN1cHBvcnQgZm9yIGxlZ2FjeSBBU0NJSQ0KPiBtb2RlLg0KDQpUaGVu IEkgc3VnZ2VzdCBzL2l0IFNIT1VMRCBOT1Qgc3VwcGx5IC4uLi8NCiAgICAgICBpdCBNQVkgb21p dCB0aGUgVVRGOFNNVFBiaXMgcGFyYW1ldGVyIHdpdGggdGhlIE1BSUwgY29tbWFuZC4NCiAgICAg ICBJbmRlZWQgaXQgaXMgYWR2aXNhYmxlIHRvIGRvIHNvIGZvciByZWFzb25zIHlhZGRhIHlhZGRh IHlhZGRhLw0KDQpXaGVyZSB0aGUgIkluZGVlZCAuLi4iIHNlbnRlbmNlIG1pZ2h0IGJlIGJldHRl ciBhcyBhIE5PVEUsIGFuZCB0aGUgInlhZGRhDQp5YWRkYSB5YWRkYSIgc2hvdWxkIGNvdmVyIHRo ZSAiZXh0cmFvcmRpbmFyeSBsZW5ndGhzIiBhbmQgIm1peGVkIG9yDQp0cmFuc2l0aW9uYWwgZW52 aXJvbm1lbnRzIiBzdHVmZiwgc3VpdGFibHkgcmV3b3JkZWQuDQoNCi0tDQpDaGFybGVzP0guP0xp bmRzZXk/LS0tLS0tLS0tQXQ/SG9tZSw/ZG9pbmc/bXk/b3duP3RoaW5nLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpUZWw6Pys0ND8xNjE/NDM2PzYxMzE/DQo/Pz9XZWI6P2h0dHA6Ly93d3cuY3Mu bWFuLmFjLnVrL35jaGwNCkVtYWlsOj9jaGxAY2xlcmV3Lm1hbi5hYy51az8/Pz8/P1NuYWlsOj81 P0NsZXJld29vZD9BdmUsP0NIRUFETEUsP1NLOD8zSlUsP1UuSy4NClBHUDo/MkMxNUYxQTk/Pz8/ Pz9GaW5nZXJwcmludDo/NzM/NkQ/QzI/NTE/OTM/QTA/MDE/RTc/NjU/RTg/NjQ/N0U/MTQ/QTQ/ QUI/QTUNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTWVzc2FnZTogMw0K RGF0ZTogVGh1LCAzIEZlYiAyMDExIDE4OjQwOjUyICswODAwDQpGcm9tOiAiWWFvIEppYW5rYW5n IiA8eWFvamtAY25uaWMuY24+DQpTdWJqZWN0OiBSZTogW0VBSV0gQ29uc2Vuc3VzIFJlc3VsdCBv biBJc3N1ZSAjMSAtIFBhcmFtZXRlciBvbiBNQUlMDQpUbzogIkpvaG4gQyBLbGVuc2luIiA8a2xl bnNpbkBqY2suY29tPiwgPGltYUBpZXRmLm9yZz4NCk1lc3NhZ2UtSUQ6IDw0OTY3Mjk2NTEuMDU0 MTBAY25uaWMuY24+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGZvcm1hdD1mbG93ZWQ7IGNo YXJzZXQ9Imlzby04ODU5LTEiOw0KICAgICAgICByZXBseS10eXBlPW9yaWdpbmFsDQoNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8a2xlbnNp bkBqY2suY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MDMsIDIwMTEgMTI6MDMgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgUmVzdWx0IG9u IElzc3VlICMxIC0gUGFyYW1ldGVyIG9uIE1BSUwNCg0KDQo+IEhpLg0KPg0KPiBCZWNhdXNlIEkg cmVhbGx5IGRvbid0IGhhdmUgYW55IHN0cm9uZyBmZWVsaW5nIGFib3V0IHRoaXMgaXNzdWUNCj4g b3RoZXIgdGhhbjoNCj4NCj4gKGkpIFdoZW4gNTMzNmJpcyBpcyByZXZpc2VkIHRvIHJlZmxlY3Qg dGhlIHBhcmFtZXRlciwgaXQNCj4gbXVzdCBiZSBhYnNvbHV0ZWx5IGNsZWFyIGFuZCBwcmVjaXNl IGFib3V0IHdoYXQgdGhlDQo+IHBhcmFtZXRlciBtZWFucy4NCj4NCg0KKzENCg0KPg0KPiAoaWkp IFdlIG5lZWQgdG8ga2VlcCB0aGlzIGFzIHNpbXBsZSBhcyBwb3NzaWJsZSAoYnV0LCBpbg0KPiBX aXJ0aCdzIHdvcmRzLCBubyBzaW1wbGVyKS4NCj4NCg0KKzENCg0KSSBzdHJvbmdseSBzdXBwb3J0 IHRoZSB0d28gcHJpbmNpcGxlcyBhYm92ZS4NCg0KSmlhbmthbmcgWWFvDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDQNCkRhdGU6IFRodSwgMDMgRmViIDIw MTEgMDg6MzE6MzMgLTA1MDANCkZyb206IEpvaG4gQyBLbGVuc2luIDxrbGVuc2luQGpjay5jb20+ DQpTdWJqZWN0OiBSZTogW0VBSV0gQ29uc2Vuc3VzIFJlc3VsdCBvbiBJc3N1ZSAjMSAtIFBhcmFt ZXRlciBvbiBNQUlMDQpUbzogSm9obiBMZXZpbmUgPGpvaG5sQHRhdWdoLmNvbT4sIGltYUBpZXRm Lm9yZw0KQ2M6IGRjcm9ja2VyQGJiaXcubmV0DQpNZXNzYWdlLUlEOiA8RDRCODE1QTE0NUExN0I3 QUZCRkRFOTMyQFBTVC5KQ0suQ09NPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0 PXVzLWFzY2lpDQoNCg0KDQotLU9uIFRodXJzZGF5LCBGZWJydWFyeSAwMywgMjAxMSAwNDo0NyAr MDAwMCBKb2huIExldmluZQ0KPGpvaG5sQHRhdWdoLmNvbT4gd3JvdGU6DQoNCj4+IFNvLCB0aGUg Z29hbCBpcyB0byBndWFyYW50ZWUgdGhhdCBubyBlbnZpcm9ubWVudCBjYW4gZXZlciBiZQ0KPj4g Y2VydGFpbiBvZiAgb3BlcmF0aW5nIGluIGEgc2ltcGxpZmllZCwgInB1cmUiIFVURi04IG1vZGU/ DQo+Pg0KPj4gQXMgcGhyYXNlZCwgdGhpcyBsYW5ndWFnZSByZXF1aXJlcyBwZXJtYW5lbnQgc3Vw cG9ydCBmb3INCj4+IGxlZ2FjeSBBU0NJSSBtb2RlLg0KDQo+IEknbSBoYXZpbmcgdHJvdWJsZSB1 bmRlcnN0YW5kaW5nIHRoZSBvYmplY3Rpb24gaGVyZS4gIEluIHRoZQ0KPiBmYXIgb2ZmIGRheSB3 aGVuIGV2ZXJ5b25lIGRvZXMgRUFJLCBzaW5jZSBBU0NJSSBtZXNzYWdlcyBhcmUgYQ0KPiBzdWJz ZXQgb2YgVVRGLTggbWVzc2FnZXMsIGEgc2VydmVyIHRoYXQgZG9lcyBub3QgY2FyZSBhYm91dA0K PiB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGVtIGNhbiBpZ25vcmUgdGhlIGZsYWcgYW5kIHRy ZWF0IGFsbA0KPiBtZXNzYWdlcyBhcyBFQUksIGFuZCBhIGNsaWVudCB0aGF0IGRvZXNuJ3QgY2Fy ZSBjYW4gc2V0IHRoZQ0KPiBmbGFnIG9uIGV2ZXJ5dGhpbmcuDQoNCk9yLCBwdXQgZGlmZmVyZW50 bHksIGEgc2VydmVyIHRoYXQgZG9lcyBub3QgY2FyZSBjYW4gaWdub3JlIHRoZQ0KZmxhZywgbWFr aW5nIGl0IGNvbXBsZXRlbHkgaXJyZWxldmFudCB3aGF0IHRoZSBjbGllbnQgZG9lcy4gIFNvLA0K aWYgdGhlIGNsaWVudCBoYXBwZW5zIHRvIGtub3cgYW5kIGNhcmUsIGl0IGlzIGNhcmVmdWwgYWJv dXQNCnNlbmRpbmcgdGhlIGZsYWcgYW5kLCBpZiBpdCBoYXMgYmVlbiB1cGRhdGVkIHRvIGtub3cg dGhhdCBubw0Kc2VydmVyIGNhcmVzIGFueSBtb3JlLCBpdCBqdXN0IHNlbmRzIGl0IGFsd2F5cy4N Cg0KVGhhdCBzYWlkLCB3ZSd2ZSBzdGlsbCBnb3QgY2xpZW50cyBhbmQgc2VydmVycyB3aG8gYXJl IG9wZXJhdGluZw0KaW4gcHVyZSA4MjEgbW9kZSwgaS5lLiwgc2VuZGluZyBvbmx5IEhFTE8gYW5k IGFjY2VwdGluZyBvbmx5DQpIRUxPLiAgQSBmZXcgb2YgdGhlIGNsaWVudHMgYXJlbid0IGV2ZW4g c3BhbW1lcnMgb3IgYm90cy4NClRoYXQgaGFzIGJlZW4gMTggeWVhcnMgYW5kLCB3aGlsZSBJIHRo aW5rIHdlIGFyZSBpbiB0aGUgdGFpbCBvZg0KdGhhdCBjdXJ2ZSwgd2UgYXJlbid0IGdvaW5nIHRv IHNlZSB0aGUgZW5kIG9mIHRoZSBhc3ltcHRvdGUgYW55DQp0aW1lIHNvb24uICBSZW1lbWJlcmlu ZyB0aGF0IGNsaWVudHMgaGF2ZSB0byBzdXBwb3J0IHB1cmUtQVNDSUkNCm1vZGUgKGFuZCwgZm9y IHRoZSBvbGRlciBjYXNlcywgcHVyZS04MjEgbW9kZSkgdG8gaGF2ZSBhbnkgaG9wZQ0Kb3IgZ2V0 dGluZyBtYWlsIHRvIHN1Y2ggc2VydmVycyBhbmQgdGhhdCBzZXJ2ZXJzIGhhdmUgdG8gc3VwcG9y dA0KaXQgKGluZGVwZW5kZW50IG9mIHdoYXRldmVyICJvbmx5IHNwYW1tZXJzIGFyZSB0aGF0IHJl dGFyZGVkIg0Kc2NvcmVzIHRoZXkgYXNzaWduKSBpbiBvcmRlciB0byBoYXZlIGFueSBob3BlIG9m IHJlY2VpdmluZyBtYWlsDQpmcm9tIHN1Y2ggY2xpZW50cywgSSBqdXN0IGNhbid0IHZpc3VhbGl6 ZSB0aGUgcG9pbnQgYXQgd2hpY2ggaXQNCndpbGwgYmUgcG9zc2libGUgdG8gcmVtb3ZlIGFsbCBj b2RlIGZvciBBU0NJSS1vbmx5IHNpdHVhdGlvbnMuDQoNCj4gVW5sZXNzIHlvdSdyZSBwcm9wb3Np bmcgYSBzZXJ2ZXIgInNlbmQgRUFJIG9yIGVsc2UiIGZsYWcsIEkNCj4gZG9uJ3Qgc2VlIHdoYXQg eW91IHdhbnQgdG8gY2hhbmdlLg0KDQpJbmRlZWQuDQogICAgam9obg0KDQoNCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDUNCkRhdGU6IFRodSwgMDMg RmViIDIwMTEgMDg6NTQ6MTkgLTA1MDANCkZyb206IEpvaG4gQyBLbGVuc2luIDxrbGVuc2luQGpj ay5jb20+DQpTdWJqZWN0OiBSZTogW0VBSV0gQ29uc2Vuc3VzIFJlc3VsdCBvbiBJc3N1ZSAjMSAt IFBhcmFtZXRlciBvbiBNQUlMDQpUbzogQ2xhdWRpbyBBbGxvY2NoaW8gPENsYXVkaW8uQWxsb2Nj aGlvQGdhcnIuaXQ+LCAgICAgIEpvaG4gTGV2aW5lDQogICAgICAgIDxqb2hubEB0YXVnaC5jb20+ DQpDYzogaW1hQGlldGYub3JnDQpNZXNzYWdlLUlEOiA8Mjc4NzQ0MTNBMTE1RjEyQkE3M0Y4RTA1 QFBTVC5KQ0suQ09NPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lp DQoNCg0KDQotLU9uIFRodXJzZGF5LCBGZWJydWFyeSAwMywgMjAxMSAwOToyMiArMDEwMCBDbGF1 ZGlvIEFsbG9jY2hpbw0KPENsYXVkaW8uQWxsb2NjaGlvQGdhcnIuaXQ+IHdyb3RlOg0KDQo+Li4u DQo+Pj4gICAgIElmIHRoZSBjbGllbnQgaXMgYXdhcmUgdGhhdCB0aGUgZW52ZWxvcGUgb3IgbWVz c2FnZQ0KPj4+ICAgICBiZWluZyBzZW50IGRvZXMgbm90IHJlcXVpcmUgYW55IG9mIHRoZSBFQUkg ZXh0ZW5zaW9uDQo+Pj4gICAgIGNhcGFiaWxpdGllcywgaXQgU0hPVUxEIE5PVCBzdXBwbHkgdGhl IFVURjhTTVRQYmlzDQo+Pj4gICAgIHBhcmFtZXRlciB3aXRoIHRoZSBNQUlMIGNvbW1hbmQuDQo+ DQo+ICsxIHRvIGtlZXAgYWxpdmUgYW4gQVNDSUkgb25seSBsZWdhY3kgd29ybGQgZm9yZXZlci4N Cj4NCj4gIk1BWSBOT1QiIGlmIHdlIHdpc2ggdGhlIFVURi04IGVudmlyb25tZW50IGdyYWR1YWxs eSBiZWNvbWUNCj4gdGhlIGxlZ2FjeSBzaXR1YXRpb24uIEl0IGlzIG5vdCBhIG5pdCwgaXQgaXMg YSBwaHlsb3NvcGhpY2FsDQo+IGFzc2VzbWVudC4NCg0KSSBkb24ndCB0aGluayBpdCBpcyBhIG5p dCwgYnV0IEkgd2FzIHRyeWluZyB0byBzdW1tYXJpemUgd2hhdCBJDQpzYXcgb24gdGhlIGxpc3Qg KEkgbWF5IG5vdCBoYXZlIGdvdHRlbiB0aGF0IHJpZ2h0KS4gIEkgZG8gc2VlDQp0aGlzIGFzIGFu IG9wZXJhdGlvbmFsIGlzc3VlOiBlc3BlY2lhbGx5IGluIHRoZSBzaG9ydC10ZXJtDQplbnZpcm9u bWVudCBpbiB3aGljaCB0aGVyZSBhcmUgZ29pbmcgdG8gYmUgbG90cyBtb3JlDQpub24tRUFJLWNh cGFibGUgc2VydmVycyBhcm91bmQgdGhhbiBFQUktY2FwYWJsZSBvbmVzLCBiZWluZw0KY2FyZWZ1 bCBhYm91dCB0aGF0IHBhcmFtZXRlciB3aWxsIG1ha2UgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbg0K d2hldGhlciBBU0NJSS1vbmx5IChpLmUuLCA1MzIxLzUzMjIgY29uZm9ybWluZykgbWVzc2FnZXMg YXJlDQpkZWxpdmVyZWQgb3IgcmVqZWN0ZWQuICAgSXQgc2VlbXMgdG8gbWUgdG8gYmUgY2xlYXJs eQ0KYWR2YW50YWdlb3VzIHRvIGhhdmUgbW9yZSwgcmF0aGVyIHRoYW4gZmV3ZXIgbWVzc2FnZXMg ZGVsaXZlcmVkDQphbmQgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcmVqZWN0aW9ucy4NCg0KUmVtZW1i ZXIgdGhhdCBtZXNzYWdlcyB0aGF0IGFyZSBjbGFpbWVkIHRvIHJlcXVpcmUgRUFJIE1VU1QgTk9U DQpiZSBzZW50IHVubGVzcyB0aGUgc2VydmVyIGFkdmVydGlzZXMgdGhlIGNhcGFiaWxpdHkuICBT bywgaWYgYQ0KcmVsYXkgcmVjZWl2ZXMgYSBtZXNzYWdlIHRoYXQgYXBwZWFycyB0byByZXF1aXJl IEVBSSAocGFyYW1ldGVyDQpzZW50IHRvIGl0IG9uIHRoZSBNQUlMIGNvbW1hbmQpIGFuZCB0aGUg bmV4dCBob3AgZG9lc24ndA0KYWR2ZXJ0aXNlIHRoZSBjYXBhYmlsaXR5LCB0aGF0IHJlbGF5IG11 c3QgZWl0aGVyDQoNCiAgICAgICAgLSByZWplY3QgdGhlIG1lc3NhZ2UgYXMgc3RhdGVkIHRvIHJl cXVpcmUgRUFJDQogICAgICAgIGZ1bmN0aW9uYWxpdHkgYnV0IGhhdmluZyBubyBob3N0IHRvIHdo aWNoIGl0IGNhbiBiZQ0KICAgICAgICBkZWxpdmVyZWQNCg0KICAgICAgICAtIHNjYW4gdGhlIGVu dmVsb3BlIGFuZCBtZXNzYWdlIHRvIGRldGVybWluZSB3aGV0aGVyIGl0DQogICAgICAgIGNhbiBz YWZlbHkgZHJvcCB0aGUgZmxhZw0KDQogICAgICAgIC0gcmlzayB2aW9sYXRpbmcgNTMyMS81MzIy IGJ5IHNlbmRpbmcgYSBtZXNzYWdlIHRoYXQNCiAgICAgICAgcG90ZW50aWFsbHkgcmVxdWlyZXMg dGhlIEVBSSBleHRlbnNpb25zIHdpdGhvdXQgZ2V0dGluZw0KICAgICAgICBhIHNlcnZlciBPSyBm b3IgdXNpbmcgdGhvc2UgZXh0ZW5zaW9ucy4NCg0KV2hhdGV2ZXIgbWUgbWlnaHQgdGhpbmsgb2Yg dGhlIHRoaXJkLCB3ZSBjYW5ub3Qgc3BlY2lmeSBpdCBhcyBhbg0KYWNjZXB0YWJsZSBvcHRpb24u ICBUaGUgY2hvaWNlIGJldHdlZW4gdGhlIGZpcnN0IHR3byBzZWVtcyB0byBtZQ0KdG8gYmUgYW4g aW1wbGVtZW50YXRpb24gb3Igb3BlcmF0aW9uYWwgY2hvaWNlLCBub3Qgb25lIHRoYXQgd2UNCnNo b3VsZCB0cnkgdG8gc3BlY2lmeSBpbiBhIHN0YW5kYXJkIChidXQgSSBjYW4gZWFzaWx5IGltYWdp bmUgYQ0KImhvdyBzdXJlIGRvIHlvdSB3YW50IHRvIGJlIGJlZm9yZSBzZW5kaW5nIHRoZSBwYXJh bWV0ZXIiIGtub2INCmZvciBsb2NhbGx5IHR1bmluZyBhbiBpbXBsZW1lbnRhdGlvbikuDQoNCklu IGVudmlyb25tZW50cyBpbiB3aGljaCBjbGllbnRzIGtub3cgdGhhdCBhbGwsIG9yIHN1YnN0YW50 aWFsbHkNCmFsbCwgc2VydmVycyBzdXBwb3J0IEVBSSwgTUFZIG1heSBiZSBtb3JlIGFwcHJvcHJp YXRlIGJ1dCwgaWYNCnRoZWlyIHVzZXJzIGNvbW11bmljYXRlIG91dHNpZGUgdGhhdCBlbnZpcm9u bWVudCwgdGhleSB3aWxsDQpzdGlsbCBwcm9iYWJseSB3YW50IHRvIGRvIHRoZSBjaGVja2luZyBh bmQgYmUgY2FyZWZ1bCBhYm91dCB3aGF0DQpmdW5jdGlvbnMgdGhleSBjbGFpbSB0aGV5IHJlcXVp cmUuDQoNCk15IG93biBwZXJzb25hbCBzZW5zZSBpcyB0aGF0IHdlIGFyZSBiZXR0ZXIgb2ZmIHdp dGggU0hPVUxEIE5PVA0Kbm93LiAgV2hlbiB0aGVzZSBzcGVjcyBhcmUgcmV2aXNlZCBvciB1cGRh dGVkIGluIHRoZSBmdXR1cmUsIHRoZQ0Kc3RhdGUgb2YgdGhlIG5ldHdvcmsgYW5kIEVBSSBkZXBs b3ltZW50IHNob3VsZCBiZSBhc3Nlc3NlZCBhbmQNCnRoZSBsYW5ndWFnZSBjaGFuZ2VkIHRvIE1B WSAoYW5kIHRoZSBleHBsYW5hdGlvbiByZXR1bmVkKSBhcw0KbmVlZGVkLiAgV2hpbGUgSSB0aGlu ayBpdCB3b3VsZCBjb25mdXNlIG1vcmUgdGhhbiBpdCB3b3VsZCBoZWxwLA0Kb25lIGNvdWxkIGFs c28gYWRkIGFuIGV4cGxhbmF0aW9uIG9mIGhvdyB0aGUgb3BlcmF0aW9uYWwgcmVhZGluZw0Kb2Yg IlNIT1VMRCBOT1QiIG1pZ2h0IGV2b2x2ZSB3aXRoIGluY3JlYXNpbmcgRUlBIGRlcGxveW1lbnQu DQoNCj4+PiAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbg0KPj4+ICAgICBkb2VzIG5vdCByZXF1aXJl IHRoYXQgdGhlIGNsaWVudCBpbnNwZWN0IHRoZSBtZXNzYWdlIG9yDQo+Pj4gICAgIG90aGVyd2lz ZSBnbyB0byBleHRyYW9yZGluYXJ5IGxlbmd0aHMgdG8gYXNzdXJlIGl0c2VsZg0KPj4+ICAgICB3 aGV0aGVyIHRoZXNlIEVBSSBjYXBhYmlsaXRpZXMgYXJlIHJlcXVpcmVkIGZvciB0aGUNCj4+PiAg ICAgcGFydGljdWxhciBtZXNzYWdlLiAgSG93ZXZlciwgaW4gbWl4ZWQgb3IgdHJhbnNpdGlvbmFs DQo+Pj4gICAgIGVudmlyb25tZW50cyBpbiB3aGljaCBFQUkgaXMgbm90IGNvbXBsZXRlbHkgZGVw bG95ZWQsDQo+Pj4gICAgIG1vcmUgcHJlY2lzaW9uIG9uIHRoZSBwYXJ0IG9mIHRoZSBjbGllbnQg KHNlbmRlcikgbWF5DQo+Pj4gICAgIHByZXZlbnQgdW5uZWNlc3NhcnkgbWVzc2FnZSByZWplY3Rp b25zLg0KDQo+IG1tbWhoaGguLi4gaXQgaXMgYW4gYXR0ZW1wdCB0byBleHBsYWluIHdoeSwgYnV0 Li4uIGRvIHdlDQo+IHJlYWxseSB0byBwaHJhc2UgaXQgbGlrZSB0aGlzPyBJIHNoYXJlIGFvdGhl ciBjb21tZW50cyBkb3VidHMNCj4gaGVyZS4NCg0KRldJVywgaXQgd2FzIGludGVuZGVkIGxlc3Mg YXMgYW4gZXhwbGFuYXRpb24gb2Ygd2h5IHRoYW4gYXMgYW4NCnJlbGF0aXZlbHkgYnJpZWYgZXhw bGFuYXRpb24gb2Ygd2hlbiBvbmUgd291bGQgd2FudCB0byBpZ25vcmUNCnRoZSBTSE9VTEQuICAg IEkgd2FzIHJlbWVtYmVyaW5nIGFuIGVhcmxpZXIgY29tbWVudCBmcm9tIERhdmUNCmFza2luZyB3 aHkgb25lIHdvdWxkIG5vdCB3YW50IHRvIHNlbmQgdGhlIHBhcmFtZXRlciBhbmQNCnRoZXJlZm9y ZSB3aHkgdGhlIHN0YXRlbWVudCB3b3VsZCBub3QgYmUgIkVBSS1jYXBhYmxlIGNsaWVudHMNCnRh bGtpbmcgd2l0aCBFQUktY2FwYWJsZSBzZXJ2ZXJzIE1VU1QgYWx3YXlzIHNlbmQgdGhlDQpwYXJh bWV0ZXIiLiAgIEhlIGFuZCBJIGFyZSBpbiBhZ3JlZW1lbnQgdGhhdCBTSE9VTEQgc3RhdGVtZW50 cw0Kc2hvdWxkIChzaWMpIGFsbW9zdCBhbHdheXMgYmUgYWNjb21wYW5pZWQgb2YgYW4gZXhwbGFu YXRpb24gb2YNCndoZW4gaXQgd2FzIHJlYXNvbmFibGUgdG8gbWFrZSBhbiBleGNlcHRpb24sIHNv IEkgd2FzIHRyeWluZyB0bw0Kc3VwcGx5IG9uZS4NCg0KICAgIGpvaG4NCg0KcC5zLiBJIGRpZCBu b3QgaW50ZW5kIG15IGxhbmd1YWdlIHRvIGJlIGluc2VydGVkIGludG8gdGhlDQpkb2N1bWVudCwg c28gbml0LXBpY2tpbmcgaXQgKGFnYWluLCBJIGRvbid0IGNvbnNpZGVyIHRoZQ0KU0hPVUxEL01B WSBkaXN0aW5jdGlvbiB0byBiZSBhIG5pdCkgaXMgcHJvYmFibHkgbm90IHVzZWZ1bC4gIElmDQp3 ZSBjYW4gYWdyZWUgb24gdGhlIGludGVudCwgbGV0J3Mgc2VlIHdoYXQgdGhlIGF1dGhvcnMgY29t ZSB1cA0Kd2l0aC4NCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K TWVzc2FnZTogNg0KRGF0ZTogVGh1LCAzIEZlYiAyMDExIDE1OjEyOjM1ICswMTAwIChDRVQpDQpG cm9tOiBDbGF1ZGlvIEFsbG9jY2hpbyA8Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdD4NClN1Ympl Y3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgUmVzdWx0IG9uIElzc3VlICMxIC0gUGFyYW1ldGVyIG9u IE1BSUwNClRvOiBKb2huIEMgS2xlbnNpbiA8a2xlbnNpbkBqY2suY29tPg0KQ2M6IENsYXVkaW8g QWxsb2NjaGlvIDxDbGF1ZGlvLkFsbG9jY2hpb0BnYXJyLml0PiwgaW1hQGlldGYub3JnDQpNZXNz YWdlLUlEOg0KICAgICAgICA8UGluZS5PU1guNC42NC4xMTAyMDMxNTA5NTkwLjUzMDRAbWFjLWFs bG9jY2hpbzMuZWxldHRyYS50cmllc3RlLml0Pg0KQ29udGVudC1UeXBlOiBURVhUL1BMQUlOOyBj aGFyc2V0PVVTLUFTQ0lJOyBmb3JtYXQ9Zmxvd2VkDQoNCg0KT24gVGh1LCAzIEZlYiAyMDExLCBK b2huIEMgS2xlbnNpbiB3cm90ZToNCg0KPg0KPg0KPiAtLU9uIFRodXJzZGF5LCBGZWJydWFyeSAw MywgMjAxMSAwOToyMiArMDEwMCBDbGF1ZGlvIEFsbG9jY2hpbw0KPiA8Q2xhdWRpby5BbGxvY2No aW9AZ2Fyci5pdD4gd3JvdGU6DQo+DQo+PiAuLi4NCj4+Pj4gICAgSWYgdGhlIGNsaWVudCBpcyBh d2FyZSB0aGF0IHRoZSBlbnZlbG9wZSBvciBtZXNzYWdlDQo+Pj4+ICAgIGJlaW5nIHNlbnQgZG9l cyBub3QgcmVxdWlyZSBhbnkgb2YgdGhlIEVBSSBleHRlbnNpb24NCj4+Pj4gICAgY2FwYWJpbGl0 aWVzLCBpdCBTSE9VTEQgTk9UIHN1cHBseSB0aGUgVVRGOFNNVFBiaXMNCj4+Pj4gICAgcGFyYW1l dGVyIHdpdGggdGhlIE1BSUwgY29tbWFuZC4NCj4+DQo+PiArMSB0byBrZWVwIGFsaXZlIGFuIEFT Q0lJIG9ubHkgbGVnYWN5IHdvcmxkIGZvcmV2ZXIuDQo+Pg0KPj4gIk1BWSBOT1QiIGlmIHdlIHdp c2ggdGhlIFVURi04IGVudmlyb25tZW50IGdyYWR1YWxseSBiZWNvbWUNCj4+IHRoZSBsZWdhY3kg c2l0dWF0aW9uLiBJdCBpcyBub3QgYSBuaXQsIGl0IGlzIGEgcGh5bG9zb3BoaWNhbA0KPj4gYXNz ZXNtZW50Lg0KPg0KPiBJIGRvbid0IHRoaW5rIGl0IGlzIGEgbml0LCBidXQgSSB3YXMgdHJ5aW5n IHRvIHN1bW1hcml6ZSB3aGF0IEkNCj4gc2F3IG9uIHRoZSBsaXN0IChJIG1heSBub3QgaGF2ZSBn b3R0ZW4gdGhhdCByaWdodCkuICBJIGRvIHNlZQ0KPiB0aGlzIGFzIGFuIG9wZXJhdGlvbmFsIGlz c3VlOiBlc3BlY2lhbGx5IGluIHRoZSBzaG9ydC10ZXJtDQo+IGVudmlyb25tZW50IGluIHdoaWNo IHRoZXJlIGFyZSBnb2luZyB0byBiZSBsb3RzIG1vcmUNCj4gbm9uLUVBSS1jYXBhYmxlIHNlcnZl cnMgYXJvdW5kIHRoYW4gRUFJLWNhcGFibGUgb25lcywgYmVpbmcNCj4gY2FyZWZ1bCBhYm91dCB0 aGF0IHBhcmFtZXRlciB3aWxsIG1ha2UgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbg0KPiB3aGV0aGVy IEFTQ0lJLW9ubHkgKGkuZS4sIDUzMjEvNTMyMiBjb25mb3JtaW5nKSBtZXNzYWdlcyBhcmUNCj4g ZGVsaXZlcmVkIG9yIHJlamVjdGVkLiAgIEl0IHNlZW1zIHRvIG1lIHRvIGJlIGNsZWFybHkNCj4g YWR2YW50YWdlb3VzIHRvIGhhdmUgbW9yZSwgcmF0aGVyIHRoYW4gZmV3ZXIgbWVzc2FnZXMgZGVs aXZlcmVkDQo+IGFuZCB0byBhdm9pZCB1bm5lY2Vzc2FyeSByZWplY3Rpb25zLg0KPg0KPiBSZW1l bWJlciB0aGF0IG1lc3NhZ2VzIHRoYXQgYXJlIGNsYWltZWQgdG8gcmVxdWlyZSBFQUkgTVVTVCBO T1QNCj4gYmUgc2VudCB1bmxlc3MgdGhlIHNlcnZlciBhZHZlcnRpc2VzIHRoZSBjYXBhYmlsaXR5 LiAgU28sIGlmIGENCj4gcmVsYXkgcmVjZWl2ZXMgYSBtZXNzYWdlIHRoYXQgYXBwZWFycyB0byBy ZXF1aXJlIEVBSSAocGFyYW1ldGVyDQo+IHNlbnQgdG8gaXQgb24gdGhlIE1BSUwgY29tbWFuZCkg YW5kIHRoZSBuZXh0IGhvcCBkb2Vzbid0DQo+IGFkdmVydGlzZSB0aGUgY2FwYWJpbGl0eSwgdGhh dCByZWxheSBtdXN0IGVpdGhlcg0KPg0KPiAgICAgICAtIHJlamVjdCB0aGUgbWVzc2FnZSBhcyBz dGF0ZWQgdG8gcmVxdWlyZSBFQUkNCj4gICAgICAgZnVuY3Rpb25hbGl0eSBidXQgaGF2aW5nIG5v IGhvc3QgdG8gd2hpY2ggaXQgY2FuIGJlDQo+ICAgICAgIGRlbGl2ZXJlZA0KPg0KPiAgICAgICAt IHNjYW4gdGhlIGVudmVsb3BlIGFuZCBtZXNzYWdlIHRvIGRldGVybWluZSB3aGV0aGVyIGl0DQo+ ICAgICAgIGNhbiBzYWZlbHkgZHJvcCB0aGUgZmxhZw0KPg0KPiAgICAgICAtIHJpc2sgdmlvbGF0 aW5nIDUzMjEvNTMyMiBieSBzZW5kaW5nIGEgbWVzc2FnZSB0aGF0DQo+ICAgICAgIHBvdGVudGlh bGx5IHJlcXVpcmVzIHRoZSBFQUkgZXh0ZW5zaW9ucyB3aXRob3V0IGdldHRpbmcNCj4gICAgICAg YSBzZXJ2ZXIgT0sgZm9yIHVzaW5nIHRob3NlIGV4dGVuc2lvbnMuDQo+DQo+IFdoYXRldmVyIG1l IG1pZ2h0IHRoaW5rIG9mIHRoZSB0aGlyZCwgd2UgY2Fubm90IHNwZWNpZnkgaXQgYXMgYW4NCj4g YWNjZXB0YWJsZSBvcHRpb24uICBUaGUgY2hvaWNlIGJldHdlZW4gdGhlIGZpcnN0IHR3byBzZWVt cyB0byBtZQ0KPiB0byBiZSBhbiBpbXBsZW1lbnRhdGlvbiBvciBvcGVyYXRpb25hbCBjaG9pY2Us IG5vdCBvbmUgdGhhdCB3ZQ0KPiBzaG91bGQgdHJ5IHRvIHNwZWNpZnkgaW4gYSBzdGFuZGFyZCAo YnV0IEkgY2FuIGVhc2lseSBpbWFnaW5lIGENCj4gImhvdyBzdXJlIGRvIHlvdSB3YW50IHRvIGJl IGJlZm9yZSBzZW5kaW5nIHRoZSBwYXJhbWV0ZXIiIGtub2INCj4gZm9yIGxvY2FsbHkgdHVuaW5n IGFuIGltcGxlbWVudGF0aW9uKS4NCj4NCj4gSW4gZW52aXJvbm1lbnRzIGluIHdoaWNoIGNsaWVu dHMga25vdyB0aGF0IGFsbCwgb3Igc3Vic3RhbnRpYWxseQ0KPiBhbGwsIHNlcnZlcnMgc3VwcG9y dCBFQUksIE1BWSBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZSBidXQsIGlmDQo+IHRoZWlyIHVzZXJz IGNvbW11bmljYXRlIG91dHNpZGUgdGhhdCBlbnZpcm9ubWVudCwgdGhleSB3aWxsDQo+IHN0aWxs IHByb2JhYmx5IHdhbnQgdG8gZG8gdGhlIGNoZWNraW5nIGFuZCBiZSBjYXJlZnVsIGFib3V0IHdo YXQNCj4gZnVuY3Rpb25zIHRoZXkgY2xhaW0gdGhleSByZXF1aXJlLg0KPg0KPiBNeSBvd24gcGVy c29uYWwgc2Vuc2UgaXMgdGhhdCB3ZSBhcmUgYmV0dGVyIG9mZiB3aXRoIFNIT1VMRCBOT1QNCj4g bm93LiAgV2hlbiB0aGVzZSBzcGVjcyBhcmUgcmV2aXNlZCBvciB1cGRhdGVkIGluIHRoZSBmdXR1 cmUsIHRoZQ0KPiBzdGF0ZSBvZiB0aGUgbmV0d29yayBhbmQgRUFJIGRlcGxveW1lbnQgc2hvdWxk IGJlIGFzc2Vzc2VkIGFuZA0KPiB0aGUgbGFuZ3VhZ2UgY2hhbmdlZCB0byBNQVkgKGFuZCB0aGUg ZXhwbGFuYXRpb24gcmV0dW5lZCkgYXMNCj4gbmVlZGVkLiAgV2hpbGUgSSB0aGluayBpdCB3b3Vs ZCBjb25mdXNlIG1vcmUgdGhhbiBpdCB3b3VsZCBoZWxwLA0KPiBvbmUgY291bGQgYWxzbyBhZGQg YW4gZXhwbGFuYXRpb24gb2YgaG93IHRoZSBvcGVyYXRpb25hbCByZWFkaW5nDQo+IG9mICJTSE9V TEQgTk9UIiBtaWdodCBldm9sdmUgd2l0aCBpbmNyZWFzaW5nIEVJQSBkZXBsb3ltZW50Lg0KDQp5 ZXMsIFNIT1VMRCBOT1QgaXMgYmV0dGVyIGZvciBjdXJyZW50IHNpdHVhdGlvbiwgYW5kIE1BWSBO T1Qgd2lsbCBiZWNvbWUNCm1vcmUgYXBwcm9wcmlhdGUgd2l0aCB0aW1lLiBBbmQgd2UgY2FuIGFs d2F5cyBjaGFuZ2UgaXQgZHVyaW5nIHRoZQ0KZG9jdW1lbnQgdXBkYXRlcy4NCg0KPj4+PiAgICAg IFRoaXMgc3BlY2lmaWNhdGlvbg0KPj4+PiAgICBkb2VzIG5vdCByZXF1aXJlIHRoYXQgdGhlIGNs aWVudCBpbnNwZWN0IHRoZSBtZXNzYWdlIG9yDQo+Pj4+ICAgIG90aGVyd2lzZSBnbyB0byBleHRy YW9yZGluYXJ5IGxlbmd0aHMgdG8gYXNzdXJlIGl0c2VsZg0KPj4+PiAgICB3aGV0aGVyIHRoZXNl IEVBSSBjYXBhYmlsaXRpZXMgYXJlIHJlcXVpcmVkIGZvciB0aGUNCj4+Pj4gICAgcGFydGljdWxh ciBtZXNzYWdlLiAgSG93ZXZlciwgaW4gbWl4ZWQgb3IgdHJhbnNpdGlvbmFsDQo+Pj4+ICAgIGVu dmlyb25tZW50cyBpbiB3aGljaCBFQUkgaXMgbm90IGNvbXBsZXRlbHkgZGVwbG95ZWQsDQo+Pj4+ ICAgIG1vcmUgcHJlY2lzaW9uIG9uIHRoZSBwYXJ0IG9mIHRoZSBjbGllbnQgKHNlbmRlcikgbWF5 DQo+Pj4+ICAgIHByZXZlbnQgdW5uZWNlc3NhcnkgbWVzc2FnZSByZWplY3Rpb25zLg0KPg0KPj4g bW1taGhoaC4uLiBpdCBpcyBhbiBhdHRlbXB0IHRvIGV4cGxhaW4gd2h5LCBidXQuLi4gZG8gd2UN Cj4+IHJlYWxseSB0byBwaHJhc2UgaXQgbGlrZSB0aGlzPyBJIHNoYXJlIGFvdGhlciBjb21tZW50 cyBkb3VidHMNCj4+IGhlcmUuDQo+DQo+IEZXSVcsIGl0IHdhcyBpbnRlbmRlZCBsZXNzIGFzIGFu IGV4cGxhbmF0aW9uIG9mIHdoeSB0aGFuIGFzIGFuDQo+IHJlbGF0aXZlbHkgYnJpZWYgZXhwbGFu YXRpb24gb2Ygd2hlbiBvbmUgd291bGQgd2FudCB0byBpZ25vcmUNCj4gdGhlIFNIT1VMRC4gICAg SSB3YXMgcmVtZW1iZXJpbmcgYW4gZWFybGllciBjb21tZW50IGZyb20gRGF2ZQ0KPiBhc2tpbmcg d2h5IG9uZSB3b3VsZCBub3Qgd2FudCB0byBzZW5kIHRoZSBwYXJhbWV0ZXIgYW5kDQo+IHRoZXJl Zm9yZSB3aHkgdGhlIHN0YXRlbWVudCB3b3VsZCBub3QgYmUgIkVBSS1jYXBhYmxlIGNsaWVudHMN Cj4gdGFsa2luZyB3aXRoIEVBSS1jYXBhYmxlIHNlcnZlcnMgTVVTVCBhbHdheXMgc2VuZCB0aGUN Cj4gcGFyYW1ldGVyIi4gICBIZSBhbmQgSSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgU0hPVUxEIHN0 YXRlbWVudHMNCj4gc2hvdWxkIChzaWMpIGFsbW9zdCBhbHdheXMgYmUgYWNjb21wYW5pZWQgb2Yg YW4gZXhwbGFuYXRpb24gb2YNCj4gd2hlbiBpdCB3YXMgcmVhc29uYWJsZSB0byBtYWtlIGFuIGV4 Y2VwdGlvbiwgc28gSSB3YXMgdHJ5aW5nIHRvDQo+IHN1cHBseSBvbmUuDQoNCm9rLiBCdXQgdGhl IGxhbmd1YWdlIGF0IGZpcnN0IHJlYWQgZGlkIG5vdCBzZWVtIHRvIGNvbnZleSB0aGF0IChhdCBs ZWFzdA0KdG8gbWUuLi4pLiB0aGF0IHdhcyBteSBvYmplY3Rpb24uDQoNCg0KPg0KPiAgICBqb2hu DQo+DQo+IHAucy4gSSBkaWQgbm90IGludGVuZCBteSBsYW5ndWFnZSB0byBiZSBpbnNlcnRlZCBp bnRvIHRoZQ0KPiBkb2N1bWVudCwgc28gbml0LXBpY2tpbmcgaXQgKGFnYWluLCBJIGRvbid0IGNv bnNpZGVyIHRoZQ0KPiBTSE9VTEQvTUFZIGRpc3RpbmN0aW9uIHRvIGJlIGEgbml0KSBpcyBwcm9i YWJseSBub3QgdXNlZnVsLiAgSWYNCj4gd2UgY2FuIGFncmVlIG9uIHRoZSBpbnRlbnQsIGxldCdz IHNlZSB3aGF0IHRoZSBhdXRob3JzIGNvbWUgdXANCj4gd2l0aC4NCj4NCj4NCj4NCj4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpDbGF1ZGlvIEFsbG9jY2hpbyAgICAgICAgICAgICBHICAgQSAg IFIgICBSICAgICAgICAgIENsYXVkaW8uQWxsb2NjaGlvQGdhcnIuaXQNCiAgICAgICAgICAgICAg ICAgICAgICAgICBTZW5pb3IgVGVjaG5pY2FsIE9mZmljZXINCnRlbDogKzM5IDA0MCAzNzU4NTIz ICAgICAgSXRhbGlhbiBBY2FkZW1pYyBhbmQgICAgICAgRz1DbGF1ZGlvOyBTPUFsbG9jY2hpbzsN CmZheDogKzM5IDA0MCAzNzU4NTY1ICAgICAgICBSZXNlYXJjaCBOZXR3b3JrICAgICAgICAgUD1n YXJyOyBBPWdhcnI7IEM9aXQ7DQoNCiAgICAgICAgICAgIFBHUCBLZXk6IGh0dHA6Ly93d3cuY2Vy dC5nYXJyLml0L1BHUC9rZXlzLnBocDMjY2ENCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KTWVzc2FnZTogNw0KRGF0ZTogVGh1LCAwMyBGZWIgMjAxMSAxMTowNzoxNCAtMDUw MA0KRnJvbTogSm9obiBDIEtsZW5zaW4gPGtsZW5zaW5AamNrLmNvbT4NClN1YmplY3Q6IFJlOiBb RUFJXSBDb25zZW5zdXMgUmVzdWx0IG9uIElzc3VlICMxIC0gUGFyYW1ldGVyIG9uIE1BSUwNClRv OiBDbGF1ZGlvIEFsbG9jY2hpbyA8Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdD4NCkNjOiBpbWFA aWV0Zi5vcmcNCk1lc3NhZ2UtSUQ6IDwxQ0U2OTk2RjcyRjBDQTRBMkZCMENGQzdAUFNULkpDSy5D T00+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkNCg0KDQoNCi0t T24gVGh1cnNkYXksIEZlYnJ1YXJ5IDAzLCAyMDExIDE1OjEyICswMTAwIENsYXVkaW8gQWxsb2Nj aGlvDQo8Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdD4gd3JvdGU6DQoNCj4uLi4NCj4+IE15IG93 biBwZXJzb25hbCBzZW5zZSBpcyB0aGF0IHdlIGFyZSBiZXR0ZXIgb2ZmIHdpdGggU0hPVUxEDQo+ PiBOT1Qgbm93LiAgV2hlbiB0aGVzZSBzcGVjcyBhcmUgcmV2aXNlZCBvciB1cGRhdGVkIGluIHRo ZQ0KPj4gZnV0dXJlLCB0aGUgc3RhdGUgb2YgdGhlIG5ldHdvcmsgYW5kIEVBSSBkZXBsb3ltZW50 IHNob3VsZCBiZQ0KPj4gYXNzZXNzZWQgYW5kIHRoZSBsYW5ndWFnZSBjaGFuZ2VkIHRvIE1BWSAo YW5kIHRoZSBleHBsYW5hdGlvbg0KPj4gcmV0dW5lZCkgYXMgbmVlZGVkLiAgV2hpbGUgSSB0aGlu ayBpdCB3b3VsZCBjb25mdXNlIG1vcmUgdGhhbg0KPj4gaXQgd291bGQgaGVscCwgb25lIGNvdWxk IGFsc28gYWRkIGFuIGV4cGxhbmF0aW9uIG9mIGhvdyB0aGUNCj4+IG9wZXJhdGlvbmFsIHJlYWRp bmcgb2YgIlNIT1VMRCBOT1QiIG1pZ2h0IGV2b2x2ZSB3aXRoDQo+PiBpbmNyZWFzaW5nIEVJQSBk ZXBsb3ltZW50Lg0KPg0KPiB5ZXMsIFNIT1VMRCBOT1QgaXMgYmV0dGVyIGZvciBjdXJyZW50IHNp dHVhdGlvbiwgYW5kIE1BWSBOT1QNCj4gd2lsbCBiZWNvbWUgbW9yZSBhcHByb3ByaWF0ZSB3aXRo IHRpbWUuIEFuZCB3ZSBjYW4gYWx3YXlzDQo+IGNoYW5nZSBpdCBkdXJpbmcgdGhlIGRvY3VtZW50 IHVwZGF0ZXMuDQoNCkkgZG9uJ3Qga25vdyBob3cgb3RoZXJzIGluIHRoZSBXRyAtLWVzcGVjaWFs bHkgdGhvc2Ugd2hvIGFyZQ0KbGlrZWx5IHRvIGhhdmUgdG8gZG8gdGhlIHdvcmstLSBmZWVsIGFi b3V0IHRoaXMgYnV0IG15DQpwcmVmZXJlbmNlIGlzIHRoYXQgd2UgdHJ5IHRvIGdldCBhIGNvbXBs ZXRlIGFuZCBjb21wZXRlbnQNCnByb3RvY29sIHNwZWMgb3V0IGFzIHF1aWNrbHkgYXMgd2UgY2Fu IG5vdywgZm9jdXNpbmcgb24gd2hhdA0KcGVvcGxlIHNob3VsZCBkbyBpbiB0aGUgc2hvcnQgdGVy bS8gZWFybHkgdHJhbnNpdGlvbiBwaHJhc2UgYXMNCmFwcHJvcHJpYXRlLiAgV2Ugc2hvdWxkIHRo ZW4gbW92ZSB0byByZXZpc2UgYXMgc29vbiBhcyB3ZSBoYXZlDQppbXBsZW1lbnRhdGlvbnMgYW5k IGRlcGxveW1lbnQgZXhwZXJpZW5jZS4gIEluIG90aGVyIHdvcmRzLCBJDQp0aGluayB3ZSB3aWxs IG5lZWQgdG8gcmV2aXNlIGluIGEgZmV3IHllYXJzIG9yIGxlc3MgYW55d2F5IGFuZA0Kc2hvdWxk IG5vdCBzcGVuZCBlbmVyZ3kgbm93IHRyeWluZyB0byBtYWtlIHN1cmUgd2UgaGF2ZSBhbGwgdGhl DQpsYW5ndWFnZSBleGFjdGx5IGNvcnJlY3QuDQoNCkFnYWluLCB0aGF0IGlzIG1vc3RseSBwZXJz b25hbCBvcGluaW9uLCBidXQgaXQgaXMgbW9yZQ0KY29uc2lzdGVudCB3aXRoIHRoZSBvYmplY3Rp dmUgdG8gZ2V0IHRoaW5ncyBkb25lIHF1aWNrbHkgdGhhbiBhDQpsb3Qgb2YgZmluZS10dW5pbmcu DQoNCj4+Pj4+ICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uDQo+Pj4+PiAgIGRvZXMgbm90IHJlcXVp cmUgdGhhdCB0aGUgY2xpZW50IGluc3BlY3QgdGhlIG1lc3NhZ2Ugb3INCj4+Pj4+ICAgb3RoZXJ3 aXNlIGdvIHRvIGV4dHJhb3JkaW5hcnkgbGVuZ3RocyB0byBhc3N1cmUgaXRzZWxmDQo+Li4uDQo+ PiBGV0lXLCBpdCB3YXMgaW50ZW5kZWQgbGVzcyBhcyBhbiBleHBsYW5hdGlvbiBvZiB3aHkgdGhh biBhcyBhbg0KPj4gcmVsYXRpdmVseSBicmllZiBleHBsYW5hdGlvbiBvZiB3aGVuIG9uZSB3b3Vs ZCB3YW50IHRvIGlnbm9yZQ0KPj4gdGhlIFNIT1VMRC4gICAgSSB3YXMgcmVtZW1iZXJpbmcgYW4g ZWFybGllciBjb21tZW50IGZyb20gRGF2ZQ0KPj4gYXNraW5nIHdoeSBvbmUgd291bGQgbm90IHdh bnQgdG8gc2VuZCB0aGUgcGFyYW1ldGVyIGFuZA0KPj4gdGhlcmVmb3JlIHdoeSB0aGUgc3RhdGVt ZW50IHdvdWxkIG5vdCBiZSAiRUFJLWNhcGFibGUgY2xpZW50cw0KPj4gdGFsa2luZyB3aXRoIEVB SS1jYXBhYmxlIHNlcnZlcnMgTVVTVCBhbHdheXMgc2VuZCB0aGUNCj4+IHBhcmFtZXRlciIuICAg SGUgYW5kIEkgYXJlIGluIGFncmVlbWVudCB0aGF0IFNIT1VMRCBzdGF0ZW1lbnRzDQo+PiBzaG91 bGQgKHNpYykgYWxtb3N0IGFsd2F5cyBiZSBhY2NvbXBhbmllZCBvZiBhbiBleHBsYW5hdGlvbiBv Zg0KPj4gd2hlbiBpdCB3YXMgcmVhc29uYWJsZSB0byBtYWtlIGFuIGV4Y2VwdGlvbiwgc28gSSB3 YXMgdHJ5aW5nDQo+PiB0byBzdXBwbHkgb25lLg0KPg0KPiBvay4gQnV0IHRoZSBsYW5ndWFnZSBh dCBmaXJzdCByZWFkIGRpZCBub3Qgc2VlbSB0byBjb252ZXkgdGhhdA0KPiAoYXQgbGVhc3QgdG8g bWUuLi4pLiB0aGF0IHdhcyBteSBvYmplY3Rpb24uDQoNCk9uIHNlY29uZCByZWFkaW5nLCBJIGFn cmVlIHRoYXQgbWlnaHQgbm90IGJlIGNsZWFyIGVub3VnaC4NCg0KTGV0J3Mgc2VlIGlmIHdlIGNh biByZWFjaCBhZ3JlZW1lbnQgb24gaW50ZW50IChzbyBmYXIsIERhdmUncw0Kb2JqZWN0aW9uIGlz IHRoZSBvbmx5IG9uZSBJIHJlbWVtYmVyIHNlZWluZyBhbmQgYm90aCBKb2huIEwgYW5kDQpJIGhh dmUgd29uZGVyZWQgYWJvdXQgaXRzIGltcGxpY2F0aW9ucykgYW5kIHRoZW4gaGF2ZSB0aGUNCmF1 dGhvcnMvZWRpdG9ycyBwcm9wb3NlIHNwZWNpZmljIGxhbmd1YWdlLi4uIHdoaWNoIHdlIGNhbiB0 aGVuDQp0dW5lIHRvIHRoZSBleHRlbnQgbmVlZGVkLg0KDQpiZXN0LA0KICAgam9obg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpJTUEgbWFpbGluZyBsaXN0DQpJTUFAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQoNCg0KRW5kIG9mIElN QSBEaWdlc3QsIFZvbCA2NywgSXNzdWUgNA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg== From Shawn.Steele@microsoft.com Thu Feb 3 10:16: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 B11903A67CC for ; Thu, 3 Feb 2011 10:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.844 X-Spam-Level: X-Spam-Status: No, score=-9.844 tagged_above=-999 required=5 tests=[AWL=-0.485, 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 mTjwjCyBZx9e for ; Thu, 3 Feb 2011 10:16:17 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id DCC3A3A67B8 for ; Thu, 3 Feb 2011 10:16:17 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Feb 2011 10:19:40 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 10:19:40 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Getting done quick Thread-Index: AQHLw87rBDGn1HmsOUSvGZiu65lMcQ== Date: Thu, 3 Feb 2011 18:19: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.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Getting done quick X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Feb 2011 18:16:18 -0000 PiBJIGRvbid0IGtub3cgaG93IG90aGVycyBpbiB0aGUgV0cgLS1lc3BlY2lhbGx5IHRob3NlIHdo byBhcmUNCj4gbGlrZWx5IHRvIGhhdmUgdG8gZG8gdGhlIHdvcmstLSBmZWVsIGFib3V0IHRoaXMg YnV0IG15DQo+IHByZWZlcmVuY2UgaXMgdGhhdCB3ZSB0cnkgdG8gZ2V0IGEgY29tcGxldGUgYW5k IGNvbXBldGVudA0KPiBwcm90b2NvbCBzcGVjIG91dCBhcyBxdWlja2x5IGFzIHdlIGNhbiBub3cs IGZvY3VzaW5nIG9uIHdoYXQNCj4gcGVvcGxlIHNob3VsZCBkbyBpbiB0aGUgc2hvcnQgdGVybS8g ZWFybHkgdHJhbnNpdGlvbiBwaHJhc2UgYXMNCj4gYXBwcm9wcmlhdGUuICBXZSBzaG91bGQgdGhl biBtb3ZlIHRvIHJldmlzZSBhcyBzb29uIGFzIHdlIGhhdmUNCj4gaW1wbGVtZW50YXRpb25zIGFu ZCBkZXBsb3ltZW50IGV4cGVyaWVuY2UuICBJbiBvdGhlciB3b3JkcywgSQ0KPiB0aGluayB3ZSB3 aWxsIG5lZWQgdG8gcmV2aXNlIGluIGEgZmV3IHllYXJzIG9yIGxlc3MgYW55d2F5IGFuZA0KPiBz aG91bGQgbm90IHNwZW5kIGVuZXJneSBub3cgdHJ5aW5nIHRvIG1ha2Ugc3VyZSB3ZSBoYXZlIGFs bCB0aGUNCj4gbGFuZ3VhZ2UgZXhhY3RseSBjb3JyZWN0Lg0KPiBBZ2FpbiwgdGhhdCBpcyBtb3N0 bHkgcGVyc29uYWwgb3BpbmlvbiwgYnV0IGl0IGlzIG1vcmUNCj4gY29uc2lzdGVudCB3aXRoIHRo ZSBvYmplY3RpdmUgdG8gZ2V0IHRoaW5ncyBkb25lIHF1aWNrbHkgdGhhbiBhDQo+IGxvdCBvZiBm aW5lLXR1bmluZy4NCg0KKyAxMDAwLiAgSSB2ZXJ5IHN0cm9uZ2x5IGFncmVlLiAgV2UgaGF2ZSBh IHRlbmRlbmN5IHRvIGRpc2N1c3MgZGV0YWlscyB0aGF0LCByZWFsaXN0aWNhbGx5LCBhcmVuJ3Qg cmVhbGx5IGdvaW5nIHRvIGJlY29tZSBvYnZpb3VzIHVudGlsIEVBSSBoYXMgc29tZSBicm9hZCBk ZXBsb3ltZW50LCBhdCB3aGljaCB0aW1lIHRoZSBSRkMgY2FuIGJlIHVwZGF0ZWQgaWYgbmVjZXNh cnkuICANCg0KV2UgY2Fubm90IGJlIHBlcmZlY3QgaGVyZSwgc28gSSdkIHJhdGhlciBhdm9pZCBm aW5lLXR1bmluZy4gIEluIHByYWN0aWNlLCA5OSUgb2YgdGhlIHRoaW5ncyB3ZSd2ZSBiZWVuIGRp c2N1c3NpbmcgaGF2ZSBubyBpbXBhY3Qgb24gdGhlIGV4cGVyaW1lbnRhbCBpbXBsZW1lbnRhdGlv bnMgd2UgKE1pY3Jvc29mdCkgaGF2ZSBiZWVuIHBsYXlpbmcgd2l0aC4NCg0KLVNoYXduDQoNCu+j ou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0 ZQ== From Shawn.Steele@microsoft.com Thu Feb 3 10:23: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 384363A67A8 for ; Thu, 3 Feb 2011 10:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 3EtxO3RDAtwY for ; Thu, 3 Feb 2011 10:23:33 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5C2B73A6452 for ; Thu, 3 Feb 2011 10:23:33 -0800 (PST) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Feb 2011 10:26:56 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 10:26:56 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: IMA Digest, Vol 67, Issue 3 Thread-Index: AQHLw12DPwl/l58m2k+/5kUHgx5HgpPwF1fX Date: Thu, 3 Feb 2011 18:26:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] IMA Digest, Vol 67, Issue 3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Feb 2011 18:23:37 -0000 > So, the goal is to guarantee that no environment can ever be certain of > operating in a simplified, "pure" UTF-8 mode? I wouldn't say that. A "pure" UTF-8 environment would be unaware of ASCII = or not, it'd never have any reason to check, so it would always send the fl= ag... (Eg: I type in my UTF-8 mail client, and it doesn't ever check for A= SCII (why would it?), so then nobody ever has a reason to become aware. > As phrased, this language requires permanent support for legacy ASCII mod= e. Theoretically. In practice I think that this is a very minor thing. I get= that John doesn't want to break mail, but our mail starts in a Unicode env= ironment, and it's going to stay that way unless it hits a roadblock of a n= on-EAI aware server. At that time we may have to resubmit or something (wh= en Exchange is the MSA it's kind of a non-issue anyway, it just has to pick= which "right thing" to do.).=20 As John also pointed out, we could also tighten the language if it turned o= ut we were only sending UTF-8 mail. -Shawn = From ajs@crankycanuck.ca Thu Feb 3 10:42: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 C90BB3A6A9C for ; Thu, 3 Feb 2011 10:42:51 -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 kIhpgqZio07W for ; Thu, 3 Feb 2011 10:42:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 13E7E3A6A98 for ; Thu, 3 Feb 2011 10:42:51 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8BD791ECB420 for ; Thu, 3 Feb 2011 18:46:13 +0000 (UTC) Date: Thu, 3 Feb 2011 13:46:11 -0500 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20110203184611.GT23365@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [EAI] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Feb 2011 18:42:51 -0000 On Thu, Feb 03, 2011 at 06:15:00PM +0000, Shawn Steele wrote: > >> If the client is aware that the envelope or message > >> being sent does not require any of the EAI extension > >> capabilities, it SHOULD NOT supply the UTF8SMTPbis > >> parameter with the MAIL command. > > I'd also lean toward MAY NOT, however I'm not that concerned about it. I believe the practical implication is low. > MAY NOT is not an RFC 2119 term. In English, it has almost the same meaning as MUST NOT. Is that what you intended? A -- Andrew Sullivan ajs@crankycanuck.ca From dhc2@dcrocker.net Thu Feb 3 12:37: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 56E403A6AF1 for ; Thu, 3 Feb 2011 12:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 db16d9NL7IiO for ; Thu, 3 Feb 2011 12:37:43 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 634E93A6AE4 for ; Thu, 3 Feb 2011 12:37:43 -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 p13Kf0ep000838 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 3 Feb 2011 12:41:06 -0800 Message-ID: <4D4B12C5.3060402@dcrocker.net> Date: Thu, 03 Feb 2011 12:40:37 -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 Discussion References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1293330888.20110203094228@pobox.com> In-Reply-To: <1293330888.20110203094228@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]); Thu, 03 Feb 2011 12:41:06 -0800 (PST) Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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: Thu, 03 Feb 2011 20:37:45 -0000 Folks, > If the envelope or message being sent requires the capabilities of these EAI > extensions Algorithmically, what does this language mean? How will an implementation know that it "requires" that it must invoke the extension? As used here, "requires" is actually not a clear and precise meaning. The challenge in using this style of specification language is that it implies calculations and criteria that are not explicitly stated. It even hints at knowing 'intent'. By comparison, note the simplification of saying If the envelope or message contain UTF-8 text, then this extension MUST be used. To the extent that the criterion listed in that alternative text is not sufficient, then add the other concrete, direct and simple criteria that are needed. For example: If the envelope or message contain UTF-8 text or if the client anticipates the need for UTF-8 support in command replies, then this extension MUST be used.[1] > If the client is aware that the envelope or message being sent does not > require any of the EAI extension capabilities, it SHOULD NOT supply the > UTF8SMTPbis parameter with the MAIL command. Effectively, this permanently excludes 0x7f and below from ever being handled as UTF-8, except by going outside of this specification. As I understand the goal of this working group, the simplifications sought by the working group are to permit direct handling of UTF-8. That is, to make UTF-8 'native' to email. By saying that 0x7f and below are not to be handled as native UTF-8, this text requires ALL implementation to forever support both ASCII and UTF-8 mechanisms, rather than ever being able to support only UTF-8. Much of the benefit of 'pure' handling of UTF-8 is thereby lost. In fact, for places wishing to operate in a pure-UTF-8 mode, this encourages violating the specification. The issue is not some 'far off day' when no one is using ASCII and a pure-UTF-8 mode is possible, but the present day, where gateways can handle the translation, if sites wish to operate that way.[2] The limitations of such a mode are real, but so are the benefits. The current proposed language places such an operation outside the scope of the specification. Doing an important infrastructure specification in a way that encourages its violation is typically counter-productive.[3] If indeed folk expect to have ASCII support present in all systems forever, then it would have been far easier and safer to have Unicode support be defined as a UTF-4 (or somesuch equivalent) /overlay/ to the existing ASCII infrastructure, since it avoids ever having to worry about damage from 'raw' UTF-8 escaping into the ASCII world. Some folk seem to be postulating a future time when this extension will be deprecated as if that will be easy to do, with a quick and easy transition. Another thought that has been expressed is for later changing the SHOULD NOT to something milder or specifying some varying interpretation of the SHOULD NOT. We've already seen notes that postulate some presence of ASCII forever. It is also clear that specifications which invite ambiguity -- that is, variable interpretation -- invite non-interoperability. So it would be useful to folks who are relying on later changes to explain the likelihood, timing and effort for these changes. I do not recall any historical precedent upon which we can base any predictions, other than, probably... never. At the least, my guess is that predictions need to be in terms of decades. Alternative language seems as if it will supply adequate guidance, without prohibiting a pure-UTF8 environment: If the envelope and message contain only ASCII, then the client MAY decline to use the UTF8SMTPbis extension. Ned Freed cited benefits in staying in ASCII-only mode where possible. Adding language that cites those benefits would be helpful, here. So: NOTE: Because there is no guarantee that a next-hop SMTP server will support the UTF8SMTPbis extension, use of the extension always carries a risk of transmission failure. Hence there is a distinct advantage for ASCII-only messages to be sent without using this extension. d/ [1] It occurs to me that it might be helpful to define an SMTP response -- or at least some proposed text to include in ASCII responses -- along the lines of "I have UTF-8 data to return to you, but you did not provide a UTF8SMTPbis parameter that permits me to include it"... [2] Note that messages might "escape" their pure environments without going through a proper gateway. However by using this extension (forever), the damage from that anomoly is small; or rather it is isolated to the environment with the configuration option error that permitted the escape, rather than imposing a UTF-8 message on a site which is unable to deal with it. [3] When considering who will have the implement this extension, in order to achieve global success, please remember that it is not merely some of the folk in this working group. It is every person who writes SMTP code around the world, which includes a rather large number of programmers who are not present for this discussion and will not know of this group's implied interpretations. -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Thu Feb 3 13:13:09 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 793CD3A6B01 for ; Thu, 3 Feb 2011 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 xjbDtvM8Ag89 for ; Thu, 3 Feb 2011 13:13:08 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 96DCE3A6AC8 for ; Thu, 3 Feb 2011 13:13:08 -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 p13LGOrI002048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 13:16:30 -0800 Message-ID: <4D4B1B11.40104@dcrocker.net> Date: Thu, 03 Feb 2011 13:16: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 C Klensin References: <20110203044735.42159.qmail@joyce.lan> 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]); Thu, 03 Feb 2011 13:16:31 -0800 (PST) Cc: ima@ietf.org, dcrocker@bbiw.net Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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: Thu, 03 Feb 2011 21:13:09 -0000 On 2/3/2011 5:31 AM, John C Klensin wrote: > --On Thursday, February 03, 2011 04:47 +0000 John Levine > wrote: >> I'm having trouble understanding the objection here. In the >> far off day when everyone does EAI, since ASCII messages are a >> subset of UTF-8 messages, a server that does not care about >> the distinction between them can ignore the flag and treat all >> messages as EAI, and a client that doesn't care can set the >> flag on everything. > > Or, put differently, a server that does not care can ignore the > flag, making it completely irrelevant what the client does. I do not understand what that sentence means. Please clarify. What flag is the server to 'ignore' and what is the difference in behavior. For that matter, if the server has advertised UTF8SMTPbis, how is it legal for the server to then fail to conform to the extension when requested to? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Thu Feb 3 13:16: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 0E2453A698F for ; Thu, 3 Feb 2011 13:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 FmVgrh7WHgyS for ; Thu, 3 Feb 2011 13:16:38 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 1B4583A687D for ; Thu, 3 Feb 2011 13:16:38 -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 p13LJulE002179 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 13:20:01 -0800 Message-ID: <4D4B1BE4.9090601@dcrocker.net> Date: Thu, 03 Feb 2011 13:19:32 -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: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> In-Reply-To: <1CE6996F72F0CA4A2FB0CFC7@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, 03 Feb 2011 13:20:01 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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: Thu, 03 Feb 2011 21:16:39 -0000 On 2/3/2011 8:07 AM, John C Klensin wrote: > I don't know how others in the WG --especially those who are > likely to have to do the work-- feel about this but my > preference is that we try to get a complete and competent > protocol spec out as quickly as we can now, focusing on what > people should do in the short term/ early transition phrase as > appropriate. We should then move to revise as soon as we have > implementations and deployment experience. In other words, I > think we will need to revise in a few years or less anyway and > should not spend energy now trying to make sure we have all the > language exactly correct. Sorry. I had completely missed the "few years or less" reference. In terms of IETF and Internet timeframes, the expectation of having to make changes within a few years qualifies the work as "experimental". d/ ps. There is a cliche "I did not have time to do the work correctly, but I will have plenty of time to fix it later.". The cost of that model tends to be quite high. -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned+ima@mrochek.com Thu Feb 3 18:32: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 1D6A33A679F for ; Thu, 3 Feb 2011 18:32:24 -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 QZbn6Oqc2hPg for ; Thu, 3 Feb 2011 18:32:22 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 06B533A67A5 for ; Thu, 3 Feb 2011 18:32:21 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXEEEDYXW000IQFY@mauve.mrochek.com> for ima@ietf.org; Thu, 3 Feb 2011 18:35:41 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXE3IXGOXS00H4Y3@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 3 Feb 2011 18:35:36 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXEEEB5M4600H4Y3@mauve.mrochek.com> Date: Thu, 03 Feb 2011 18:13:37 -0800 (PST) In-reply-to: "Your message dated Thu, 03 Feb 2011 09:42:28 -0800" <1293330888.20110203094228@pobox.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1293330888.20110203094228@pobox.com> To: Bill McQuillan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296783823; bh=bEjpqShiCozUYOUU7acDwz4ejkIeZyaUfOSkJj6bRrw=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=YV0jl7P+CvmsfXZqnhvTGEVrVihIHip2qvhNDmDv9BIiEWhwB1pilljzaIZXnCX6D aKIma6DVhbByOP0TbfjPYhghm3BG2aawOu3C1OVMfd3YTiVkgDAPRO5hDaa0R85IF8 AmyoW/BhJn6cO56mpLCAuKgHZqkmo0TqXhdvffiQ= Cc: IMA Discussion 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: Fri, 04 Feb 2011 02:32:24 -0000 > On Thu, 2011-02-03, John C Klensin wrote: > > Remember that messages that are claimed to require EAI MUST NOT > > be sent unless the server advertises the capability. So, if a > > relay receives a message that appears to require EAI (parameter > > sent to it on the MAIL command) and the next hop doesn't > > advertise the capability, that relay must either > > - reject the message as stated to require EAI > > functionality but having no host to which it can be > > delivered > > - scan the envelope and message to determine whether it > > can safely drop the flag > > - risk violating 5321/5322 by sending a message that > > potentially requires the EAI extensions without getting > > a server OK for using those extensions. > It seems to me that this raises another concern for the maximum reliability > of message propagation. The fact that, while the message itself will not > change with respect to whether it requires EAI of not, The *envelope* may > as it progresses from hop to hop. And so can the header. List expanders routinely modify headers in various ways, and this will include EAI material. (Purists don't like this of course, but like it or not it's how things are done.) So a list expander may turn a non-EAI message into an EAI message, or vice-versa, either through envelope modification, header modification, or both. > For instance, a mailing list message with ASCII only content is to be > distributed to a number of subscribers, some of which have EAI addresses. A > simple-minded mailer would send MAIL FROM: with the EAI flag set and then a > bunch of RCPT TO: commands with a few containing EAI-requiring addresses. > Note that as the message is forwarded to subsequent MTAs, eventually some > of the message copies will have only recipients with ASCII addresses. Who > is responsible for noting that the EAI flag is no longer needed? The answer to that is ... nobody. Removing the EAI flag from a message that no longer needs it should be legal, but not required. What does need to be required, however, is setting the EAI flag when a non-EAI message is converted to an EAI one. > Maybe the correct way to handle this is to have the original mailer > segregate the EAI-requiring recipients into a separate transaction. Is it > appropriate for this spec to mention this advice? As I tried to explain a couple of days back, I think the answer to this is "no". The problem with trying to explain this particular tactic is it gets really ugly really fast. For example, consider the case of a client attempting to submit a message to a group of recipients, some EAI and some not, where nothing in the message content requires EAI. The transaction part isn't the problem - clients alreayd have to be able to split groups of recipients in order to cope with recipient limits. No, the problem is what to put into the header - if you list the EAI recipients in a recipient field, you've converted the message to EAI irrespective of the type of recipient. So can you avoid putting in the recipients? Well, that becomes a complex question of intent, of what information the client has available, and even what sequence of operations the client uses to constrcut the message (which varies wildly from one client to another). Issues with list expansion may be a little simpler, but nevertheless have the same general flavor. So I think the correct approach is to clearly define what the EAI flag means and when it has to be set, and a suggestion as to when it should not be set. The rest is going to be a matter of client quality. And if past experience in MIME is any indication, what we actually say about this behond the actual hard restrictions is going to matter a lot less than we'd probably like to believe. Ned From Shawn.Steele@microsoft.com Thu Feb 3 20:08: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 500993A6A11 for ; Thu, 3 Feb 2011 20:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 7RrHDmGTxLzD for ; Thu, 3 Feb 2011 20:08:35 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id EC8EF3A697A for ; Thu, 3 Feb 2011 20:08:34 -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; Thu, 3 Feb 2011 20:11:57 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 20:11:57 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Should/may Thread-Index: AcvEIU7ShQMMY52rTWW5UiDBAEZ/jg== Date: Fri, 4 Feb 2011 04:11: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.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 04:08:36 -0000 I'd intended "MAY", however that sounded funny in the sentence the way John= had it. (it was backwards). So this is more along the lines of my intent: > >> If the client is aware that the envelope or message > >> being sent does not require any of the EAI extension > >> capabilities, it MAY choose to not supply the UTF8SMTPbis > >> parameter with the MAIL command. Although that doesn't make it any easier to read :) As mentioned, I'm happy with either MAY or SHOULD, however MUST NOT is not = acceptable. --------------------------- Message: 3 Date: Thu, 3 Feb 2011 13:46:11 -0500 From: Andrew Sullivan Subject: Re: [EAI] Should/may To: ima@ietf.org Message-ID: <20110203184611.GT23365@shinkuro.com> Content-Type: text/plain; charset=3Dus-ascii On Thu, Feb 03, 2011 at 06:15:00PM +0000, Shawn Steele wrote: > >> If the client is aware that the envelope or message > >> being sent does not require any of the EAI extension > >> capabilities, it SHOULD NOT supply the UTF8SMTPbis > >> parameter with the MAIL command. >=20 > I'd also lean toward MAY NOT, however I'm not that concerned about it. I= believe the practical implication is low. =20 >=20 MAY NOT is not an RFC 2119 term. In English, it has almost the same meanin= g as MUST NOT. Is that what you intended? A -- Andrew Sullivan ajs@crankycanuck.ca ------------------------------ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima End of IMA Digest, Vol 67, Issue 6 ********************************** From Claudio.Allocchio@garr.it Fri Feb 4 00:33: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 ED2933A6B75 for ; Fri, 4 Feb 2011 00:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.569, 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 el7+r4x1g1SY for ; Fri, 4 Feb 2011 00:33:10 -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 D30BF3A6B7E for ; Fri, 4 Feb 2011 00:33:06 -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 p148aFii027505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 09:36:16 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p148aFii027505 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=L9NshMIxjknUHFJf6mu1EbcCRgLGdXTRJnC+dTqaDCGzPgSUp2rvDRpsO/A1RKYM9 imTMdbI3lJVb/yqpP3BHKGtAx/goVluwbHQD68pMXv9XDqrLGk5UEBBBNcCvbkxoiry jH8wCeyKCGKwl790uyxbiF2Dtw9HTxkLaL2EQfo= Date: Fri, 4 Feb 2011 09:36:14 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: dcrocker@bbiw.net In-Reply-To: <4D4B1BE4.9090601@dcrocker.net> Message-ID: References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> <4D4B1BE4.9090601@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org 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: Fri, 04 Feb 2011 08:33:12 -0000 On Thu, 3 Feb 2011, Dave CROCKER wrote: > > > On 2/3/2011 8:07 AM, John C Klensin wrote: >> I don't know how others in the WG --especially those who are >> likely to have to do the work-- feel about this but my >> preference is that we try to get a complete and competent >> protocol spec out as quickly as we can now, focusing on what >> people should do in the short term/ early transition phrase as >> appropriate. We should then move to revise as soon as we have >> implementations and deployment experience. In other words, I >> think we will need to revise in a few years or less anyway and >> should not spend energy now trying to make sure we have all the >> language exactly correct. > > > Sorry. I had completely missed the "few years or less" reference. > > In terms of IETF and Internet timeframes, the expectation of having to make > changes within a few years qualifies the work as "experimental". and this is not experimental, however... > > d/ > > ps. There is a cliche "I did not have time to do the work correctly, but I > will have plenty of time to fix it later.". The cost of that model tends to > be quite high. ... however, the difference here, IMHO, is that we are trying to drive (or guess) deployment trend of UTF-8 mail world, describing how the transistion should work into a standard specification. Do we agree that the goal is to maximise mail messages successful deliveries? is so: - Shall we go for the "quick deploymnet scenario"? then it is a MAY. - otherwise it's a SHOULD. In any case I do not think we can guess it... even most major sw developers are here on this list... there are so many other implementations around, which will just "read" what we tell them and hopefully do it right. PS: sorry for the "MAY NOT", it' of course wrong text. :-) > > -- > > 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 Fri Feb 4 05:03: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 B87FF3A695F for ; Fri, 4 Feb 2011 05:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.560, 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 IF-WgI9MY95D for ; Fri, 4 Feb 2011 05:03:14 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 868763A6BBA for ; Fri, 4 Feb 2011 05:03:14 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PlLN0-000BVE-KK; Fri, 04 Feb 2011 08:06:38 -0500 Date: Fri, 04 Feb 2011 08:06:37 -0500 From: John C Klensin To: dcrocker@bbiw.net Message-ID: <43D2529E6D43AAF0053C87E0@PST.JCK.COM> In-Reply-To: <4D4B1BE4.9090601@dcrocker.net> References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> <4D4B1BE4.9090601@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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 13:03:15 -0000 --On Thursday, February 03, 2011 13:19 -0800 Dave CROCKER wrote: > > > On 2/3/2011 8:07 AM, John C Klensin wrote: >> I don't know how others in the WG --especially those who are >> likely to have to do the work-- feel about this but my >> preference is that we try to get a complete and competent >> protocol spec out as quickly as we can now, focusing on what >> people should do in the short term/ early transition phrase as >> appropriate. We should then move to revise as soon as we have >> implementations and deployment experience. In other words, I >> think we will need to revise in a few years or less anyway and >> should not spend energy now trying to make sure we have all >> the language exactly correct. > > > Sorry. I had completely missed the "few years or less" > reference. > > In terms of IETF and Internet timeframes, the expectation of > having to make changes within a few years qualifies the work > as "experimental". > ps. There is a cliche "I did not have time to do the work > correctly, but I will have plenty of time to fix it later.". > The cost of that model tends to be quite high. Dave, First, we have been through "experimental". Complete specs were published, implementations were produced, tests were performed, we learned some things from the experiments, and work now should be focused on the needed changes/ improvements from those original documents. The long-term participants in the WG are at least somewhat justified in taking the position that we should not revisit _any_ of the issues that were discussed at length in the first round of work (the one that produced the experimental specs) and that were not shown to be problematic in testing unless significant new arguments are introduced. Second and perhaps more important, please try to read what I (and others) are actually writing rather than picking up on a few words and going on the attack. I am trying to avoid speculating on your motivations, but I know that it is causing significant delay to progress in the WG without, as far as I can tell, improving protocol quality. As examples, consider the text you quoted above: (i) I said "complete and competent protocol spec". That has nothing to do with "no time to do the work correctly" or "experimental". It is actually a higher standard than the "no known technical omissions" requirement for Proposed Standard. When combined with the history of publishing experimental documents, having independent implementations, performing interoperability tests on them, and learning from those tests, it is a reasonable expectation that the protocols will be _much_ more developed --and that we will be much more sure of them-- than the IETF norm for Proposed Standards. (ii) Similarly, if you read all of "revise in a few years or less anyway and should not spend energy now trying to make sure we have all the language exactly correct" completely and in context, it will be clear that I was not talking about the quality or completeness of the protocol, but only about how very fine details of the language in which the specifications are written are sorted out. I also note that the intent for Proposed Standards, as described in RFC 2026, is that documents remain at that level for between six months and two years. While the "update or expire" provision of that document has proven ineffective, the expectation of review and revision within that period is completely consistent with my suggestion of publication, implementation, review, and revision as necessary. It is hard to reconcile it with your apparent belief that any spec that is expected to be revised within a few years is necessarily either experimental or unstable/incomplete. regards, john From ajs@crankycanuck.ca Fri Feb 4 05:13: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 991993A691A for ; Fri, 4 Feb 2011 05:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 ffjtPlUtZxx7 for ; Fri, 4 Feb 2011 05:13:20 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E23403A68E4 for ; Fri, 4 Feb 2011 05:13:19 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 925F41ECB41F for ; Fri, 4 Feb 2011 13:16:44 +0000 (UTC) Date: Fri, 4 Feb 2011 08:16:42 -0500 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20110204131642.GE33857@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [EAI] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 13:13:20 -0000 On Fri, Feb 04, 2011 at 04:11:56AM +0000, Shawn Steele wrote: > I'd intended "MAY", however that sounded funny in the sentence the way John had it. (it was backwards). > > So this is more along the lines of my intent: > > > >> If the client is aware that the envelope or message > > >> being sent does not require any of the EAI extension > > >> capabilities, it MAY choose to not supply the UTF8SMTPbis > > >> parameter with the MAIL command. > > Although that doesn't make it any easier to read :) Does this make it easier? If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it MAY choose to leave out the UTF8SMTPbis parameter to the MAIL command. A -- Andrew Sullivan ajs@crankycanuck.ca From chl@clerew.man.ac.uk Fri Feb 4 05:54:09 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 189993A6BB9 for ; Fri, 4 Feb 2011 05:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 Cey+7UWqy931 for ; Fri, 4 Feb 2011 05:54:07 -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 50F183A6BB4 for ; Fri, 4 Feb 2011 05:54:05 -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 E476E22700 for ; Fri, 4 Feb 2011 13:57:26 +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, 04 Feb 2011 13:57:26 +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 p14DvPYN006899 for ; Fri, 4 Feb 2011 13:57:26 GMT Date: Fri, 04 Feb 2011 13:57:25 -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: 4d4c05c6.165ef-57f4-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 13:54:09 -0000 On Fri, 04 Feb 2011 04:11:56 -0000, Shawn Steele wrote: > I'd intended "MAY", however that sounded funny in the sentence the way > John had it. (it was backwards). > > So this is more along the lines of my intent: > >> >> If the client is aware that the envelope or message >> >> being sent does not require any of the EAI extension >> >> capabilities, it MAY choose to not supply the UTF8SMTPbis >> >> parameter with the MAIL command. > > Although that doesn't make it any easier to read :) s/not supply/omit/ -- 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 Fri Feb 4 05:56: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 29B9E3A6965 for ; Fri, 4 Feb 2011 05:56:24 -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.215, 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 58Ojo8YvPzVV for ; Fri, 4 Feb 2011 05:56:23 -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 349C93A6923 for ; Fri, 4 Feb 2011 05:56:22 -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 0723422713 for ; Fri, 4 Feb 2011 13:59: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; Fri, 04 Feb 2011 13:59:42 +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 p14Dxfoc007038 for ; Fri, 4 Feb 2011 13:59:42 GMT Date: Fri, 04 Feb 2011 13:59:41 -0000 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1293330888.20110203094228@pobox.com> <4D4B12C5.3060402@dcrocker.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4D4B12C5.3060402@dcrocker.net> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d4c064f.156-582b-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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 13:56:24 -0000 On Thu, 03 Feb 2011 20:40:37 -0000, Dave CROCKER wrote: > Ned Freed cited benefits in staying in ASCII-only mode where possible. > Adding > language that cites those benefits would be helpful, here. So: > > NOTE: Because there is no guarantee that a next-hop SMTP > server will > support the UTF8SMTPbis extension, use of the extension > always > carries a risk of transmission failure. Hence there is > a > distinct advantage for ASCII-only messages to be sent > without > using this extension. > Nice wording! Would work well together with some of the suggested "MAY" language. -- 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 Fri Feb 4 07:05: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 22D1B3A68E9 for ; Fri, 4 Feb 2011 07:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 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 dl853t9bEyC9 for ; Fri, 4 Feb 2011 07:05:13 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4B1E23A697D for ; Fri, 4 Feb 2011 07:05:12 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PlNH2-000EiN-FM; Fri, 04 Feb 2011 10:08:36 -0500 Date: Fri, 04 Feb 2011 10:08:35 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <13EB9880E04BF520DF5974AA@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] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 15:05:14 -0000 Shawn (and Charles), --On Friday, February 04, 2011 04:11 +0000 Shawn Steele wrote: > I'd intended "MAY", however that sounded funny in the sentence > the way John had it. (it was backwards). > > So this is more along the lines of my intent: > >> >> If the client is aware that the envelope or message >> >> being sent does not require any of the EAI extension >> >> capabilities, it MAY choose to not supply the >> >> UTF8SMTPbis parameter with the MAIL command. > > Although that doesn't make it any easier to read :) > > As mentioned, I'm happy with either MAY or SHOULD, however > MUST NOT is not acceptable. To the best of my knowledge, no one has proposed MUST NOT, although even that wouldn't be very strong in the presence of the deliberate weasel-wording about what the client is or is not "aware" of. The reasoning that caused me to select "SHOULD NOT supply the parameter" was... (1) If the client knows that the message doesn't require EAI capabilities, it can safely omit the parameter and, given the motivation of getting as many messages delivered as possible, probably should omit it. (2) If the client treats everything as EAI (i.e., as containing UTF-8, whether that UTF-8 is ASCII or not) then, almost by definition, it won't know (won't "be aware"). Such clients are likely to be common in Unicode-native environments but may exist in other ones. As we have discussed many times before, the logical upgrade to EAI for such clients (and the corresponding servers) is to support the EHLO reply and recognize any parameters the WG decides to require, disable any checks that exist today to enforce ASCII-only restrictions, and otherwise just go about their business. The analogy to support for 8BITMIME in clients and servers that are 8bit-clean is pretty obvious and we have a lot of experience with that case and how well it works. But the important thing is that such clients can reasonably claim to be unaware of whether the message is restricted to ASCII or not. If they are not aware of whether the message and envelope are ASCII-only, then the provision is simply irrelevant -- whether it says MAY, SHOULD, or MUST makes no difference at all (now or in the future). (3) I agree with Ned's comment that what we say about this sort of thing is likely to have a lot less effect than perhaps we would like to think. That combination is one of the situations about which I was trying to comment in my exchange with Dave about trying to be sure that the protocol spec is "complete and competent" but that we should not waste a lot of time fine-tuning language. If a client is designed to act as much as possible as if each message is EAI-compliant, then it won't be aware of anything else and whether the text that applies only when the client is aware says MAY or SHOULD NOT is completely irrelevant. If a server is designed to act as much as possible as if each message is EAI-compliant, it must still be able to handle ASCII-only messages -- not only because those are EAI-compliant anyway (except that the MAIL command parameter may not appear) but because it is still required to be 5321-compliant and behave well for 5321 (only)-compliant messages. And, if it tries to relay and encounters a server (or other system) that doesn't handle messages that require EAI capability, then it has three choices: (i) If the envelope it received does not contain the UTF8SMTPbis parameter on the MAIL command, then it proceeds to handle the situation as a 5321-compliant situation... EAI is irrelevant. (ii) If the envelope it received contains the UTF8SMTPbis parameter to the MAIL command, it can simply reject (or bounce) the message. (iii) If the envelope it received contains the UTF8SMTPbis parameter, it can do whatever it needs to do to determine whether it can safely forward the message to the next, presumably not-EAI-capable, system. Of course, if it does that, it must not include the MAIL command parameter because the next-hop system will have not advertised the availability of the extension. And, again, that is pretty much true regardless of what we say (we could eliminate the third case by saying "MUST REJECT", but we would be ignored). So, again consistent with my earlier note, can we possibly minimize the time we spend debating particular wording differences that are unlikely to have any effect on implementations? john From Shawn.Steele@microsoft.com Fri Feb 4 10:50: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 C73DD3A68F0 for ; Fri, 4 Feb 2011 10:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 PJO2rYWjLj0N for ; Fri, 4 Feb 2011 10:50:31 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id BD3AF3A67CC for ; Fri, 4 Feb 2011 10:50:30 -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; Fri, 4 Feb 2011 10:53:56 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Fri, 4 Feb 2011 10:53:55 -0800 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] Should/may Thread-Index: AcvEIU7ShQMMY52rTWW5UiDBAEZ/jgAnyQKA//+4sc0= Date: Fri, 4 Feb 2011 18:53:55 +0000 Message-ID: References: , <13EB9880E04BF520DF5974AA@PST.JCK.COM> In-Reply-To: <13EB9880E04BF520DF5974AA@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] Should/may X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 18:50:34 -0000 WWVzLCBzb3JyeSB0aGF0IEkgY29udHJpYnV0ZWQgYW55dGhpbmcgdGhhdCBtaWdodCBiZSBjYXVz aW5nIG1vcmUgZGVsYXkgOikgIChJIHdhcyB0cnlpbmcgdG8gY2F1c2UgbGVzcyBkZWxheSA6KA0K DQoNCi1TaGF3bg0KDQrvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3Mu bXNkbi5jb20vc2hhd25zdGUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBKb2huIEMgS2xlbnNpbiBba2xlbnNpbkBqY2suY29tXQ0KU2VudDogRnJp ZGF5LCBGZWJydWFyeSAwNCwgMjAxMSA3OjA4IEFNDQpUbzogU2hhd24gU3RlZWxlOyBpbWFAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSBTaG91bGQvbWF5DQoNClNoYXduIChhbmQgQ2hhcmxl cyksDQoNCi0tT24gRnJpZGF5LCBGZWJydWFyeSAwNCwgMjAxMSAwNDoxMSArMDAwMCBTaGF3biBT dGVlbGUNCjxTaGF3bi5TdGVlbGVAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCj4gSSdkIGludGVu ZGVkICJNQVkiLCBob3dldmVyIHRoYXQgc291bmRlZCBmdW5ueSBpbiB0aGUgc2VudGVuY2UNCj4g dGhlIHdheSBKb2huIGhhZCBpdC4gIChpdCB3YXMgYmFja3dhcmRzKS4NCj4NCj4gU28gdGhpcyBp cyBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZiBteSBpbnRlbnQ6DQo+DQo+PiA+PiAgICAgIElmIHRo ZSBjbGllbnQgaXMgYXdhcmUgdGhhdCB0aGUgZW52ZWxvcGUgb3IgbWVzc2FnZQ0KPj4gPj4gICAg ICBiZWluZyBzZW50IGRvZXMgbm90IHJlcXVpcmUgYW55IG9mIHRoZSBFQUkgZXh0ZW5zaW9uDQo+ PiA+PiAgICAgIGNhcGFiaWxpdGllcywgaXQgTUFZIGNob29zZSB0byBub3Qgc3VwcGx5IHRoZQ0K Pj4gPj4gICAgICBVVEY4U01UUGJpcyBwYXJhbWV0ZXIgd2l0aCB0aGUgTUFJTCBjb21tYW5kLg0K Pg0KPiBBbHRob3VnaCB0aGF0IGRvZXNuJ3QgbWFrZSBpdCBhbnkgZWFzaWVyIHRvIHJlYWQgOikN Cj4NCj4gQXMgbWVudGlvbmVkLCBJJ20gaGFwcHkgd2l0aCBlaXRoZXIgTUFZIG9yIFNIT1VMRCwg aG93ZXZlcg0KPiBNVVNUIE5PVCBpcyBub3QgYWNjZXB0YWJsZS4NCg0KVG8gdGhlIGJlc3Qgb2Yg bXkga25vd2xlZGdlLCBubyBvbmUgaGFzIHByb3Bvc2VkIE1VU1QgTk9ULA0KYWx0aG91Z2ggZXZl biB0aGF0IHdvdWxkbid0IGJlIHZlcnkgc3Ryb25nIGluIHRoZSBwcmVzZW5jZSBvZg0KdGhlIGRl bGliZXJhdGUgd2Vhc2VsLXdvcmRpbmcgYWJvdXQgd2hhdCB0aGUgY2xpZW50IGlzIG9yIGlzIG5v dA0KImF3YXJlIiBvZi4gIFRoZSByZWFzb25pbmcgdGhhdCBjYXVzZWQgbWUgdG8gc2VsZWN0ICJT SE9VTEQgTk9UDQpzdXBwbHkgdGhlIHBhcmFtZXRlciIgd2FzLi4uDQoNCigxKSBJZiB0aGUgY2xp ZW50IGtub3dzIHRoYXQgdGhlIG1lc3NhZ2UgZG9lc24ndCByZXF1aXJlIEVBSQ0KY2FwYWJpbGl0 aWVzLCBpdCBjYW4gc2FmZWx5IG9taXQgdGhlIHBhcmFtZXRlciBhbmQsIGdpdmVuIHRoZQ0KbW90 aXZhdGlvbiBvZiBnZXR0aW5nIGFzIG1hbnkgbWVzc2FnZXMgZGVsaXZlcmVkIGFzIHBvc3NpYmxl LA0KcHJvYmFibHkgc2hvdWxkIG9taXQgaXQuDQoNCigyKSBJZiB0aGUgY2xpZW50IHRyZWF0cyBl dmVyeXRoaW5nIGFzIEVBSSAoaS5lLiwgYXMgY29udGFpbmluZw0KVVRGLTgsIHdoZXRoZXIgdGhh dCBVVEYtOCBpcyBBU0NJSSBvciBub3QpIHRoZW4sIGFsbW9zdCBieQ0KZGVmaW5pdGlvbiwgaXQg d29uJ3Qga25vdyAod29uJ3QgImJlIGF3YXJlIikuICAgU3VjaCBjbGllbnRzIGFyZQ0KbGlrZWx5 IHRvIGJlIGNvbW1vbiBpbiBVbmljb2RlLW5hdGl2ZSBlbnZpcm9ubWVudHMgYnV0IG1heSBleGlz dA0KaW4gb3RoZXIgb25lcy4gIEFzIHdlIGhhdmUgZGlzY3Vzc2VkIG1hbnkgdGltZXMgYmVmb3Jl LCB0aGUNCmxvZ2ljYWwgdXBncmFkZSB0byBFQUkgZm9yIHN1Y2ggY2xpZW50cyAoYW5kIHRoZSBj b3JyZXNwb25kaW5nDQpzZXJ2ZXJzKSBpcyB0byBzdXBwb3J0IHRoZSBFSExPIHJlcGx5IGFuZCBy ZWNvZ25pemUgYW55DQpwYXJhbWV0ZXJzIHRoZSBXRyBkZWNpZGVzIHRvIHJlcXVpcmUsIGRpc2Fi bGUgYW55IGNoZWNrcyB0aGF0DQpleGlzdCB0b2RheSB0byBlbmZvcmNlIEFTQ0lJLW9ubHkgcmVz dHJpY3Rpb25zLCBhbmQgb3RoZXJ3aXNlDQpqdXN0IGdvIGFib3V0IHRoZWlyIGJ1c2luZXNzLiAg VGhlIGFuYWxvZ3kgdG8gc3VwcG9ydCBmb3INCjhCSVRNSU1FIGluIGNsaWVudHMgYW5kIHNlcnZl cnMgdGhhdCBhcmUgOGJpdC1jbGVhbiBpcyBwcmV0dHkNCm9idmlvdXMgYW5kIHdlIGhhdmUgYSBs b3Qgb2YgZXhwZXJpZW5jZSB3aXRoIHRoYXQgY2FzZSBhbmQgaG93DQp3ZWxsIGl0IHdvcmtzLg0K DQpCdXQgdGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0IHN1Y2ggY2xpZW50cyBjYW4gcmVhc29u YWJseQ0KY2xhaW0gdG8gYmUgdW5hd2FyZSBvZiB3aGV0aGVyIHRoZSBtZXNzYWdlIGlzIHJlc3Ry aWN0ZWQgdG8NCkFTQ0lJIG9yIG5vdC4gIElmIHRoZXkgYXJlIG5vdCBhd2FyZSBvZiB3aGV0aGVy IHRoZSBtZXNzYWdlIGFuZA0KZW52ZWxvcGUgYXJlIEFTQ0lJLW9ubHksIHRoZW4gdGhlIHByb3Zp c2lvbiBpcyBzaW1wbHkgaXJyZWxldmFudA0KLS0gd2hldGhlciBpdCBzYXlzIE1BWSwgU0hPVUxE LCBvciBNVVNUIG1ha2VzIG5vIGRpZmZlcmVuY2UgYXQNCmFsbCAobm93IG9yIGluIHRoZSBmdXR1 cmUpLg0KDQooMykgSSBhZ3JlZSB3aXRoIE5lZCdzIGNvbW1lbnQgdGhhdCB3aGF0IHdlIHNheSBh Ym91dCB0aGlzIHNvcnQNCm9mIHRoaW5nIGlzIGxpa2VseSB0byBoYXZlIGEgbG90IGxlc3MgZWZm ZWN0IHRoYW4gcGVyaGFwcyB3ZQ0Kd291bGQgbGlrZSB0byB0aGluay4NCg0KVGhhdCBjb21iaW5h dGlvbiBpcyBvbmUgb2YgdGhlIHNpdHVhdGlvbnMgYWJvdXQgd2hpY2ggSSB3YXMNCnRyeWluZyB0 byBjb21tZW50IGluIG15IGV4Y2hhbmdlIHdpdGggRGF2ZSBhYm91dCB0cnlpbmcgdG8gYmUNCnN1 cmUgdGhhdCB0aGUgcHJvdG9jb2wgc3BlYyBpcyAiY29tcGxldGUgYW5kIGNvbXBldGVudCIgYnV0 IHRoYXQNCndlIHNob3VsZCBub3Qgd2FzdGUgYSBsb3Qgb2YgdGltZSBmaW5lLXR1bmluZyBsYW5n dWFnZS4gIElmIGENCmNsaWVudCBpcyBkZXNpZ25lZCB0byBhY3QgYXMgbXVjaCBhcyBwb3NzaWJs ZSBhcyBpZiBlYWNoIG1lc3NhZ2UNCmlzIEVBSS1jb21wbGlhbnQsIHRoZW4gaXQgd29uJ3QgYmUg YXdhcmUgb2YgYW55dGhpbmcgZWxzZSBhbmQNCndoZXRoZXIgdGhlIHRleHQgdGhhdCBhcHBsaWVz IG9ubHkgd2hlbiB0aGUgY2xpZW50IGlzIGF3YXJlIHNheXMNCk1BWSBvciBTSE9VTEQgTk9UIGlz IGNvbXBsZXRlbHkgaXJyZWxldmFudC4NCg0KSWYgYSBzZXJ2ZXIgaXMgZGVzaWduZWQgdG8gYWN0 IGFzIG11Y2ggYXMgcG9zc2libGUgYXMgaWYgZWFjaA0KbWVzc2FnZSBpcyBFQUktY29tcGxpYW50 LCBpdCBtdXN0IHN0aWxsIGJlIGFibGUgdG8gaGFuZGxlDQpBU0NJSS1vbmx5IG1lc3NhZ2VzIC0t IG5vdCBvbmx5IGJlY2F1c2UgdGhvc2UgYXJlIEVBSS1jb21wbGlhbnQNCmFueXdheSAoZXhjZXB0 IHRoYXQgdGhlIE1BSUwgY29tbWFuZCBwYXJhbWV0ZXIgbWF5IG5vdCBhcHBlYXIpDQpidXQgYmVj YXVzZSBpdCBpcyBzdGlsbCByZXF1aXJlZCB0byBiZSA1MzIxLWNvbXBsaWFudCBhbmQgYmVoYXZl DQp3ZWxsIGZvciA1MzIxIChvbmx5KS1jb21wbGlhbnQgbWVzc2FnZXMuICBBbmQsIGlmIGl0IHRy aWVzIHRvDQpyZWxheSBhbmQgZW5jb3VudGVycyBhIHNlcnZlciAob3Igb3RoZXIgc3lzdGVtKSB0 aGF0IGRvZXNuJ3QNCmhhbmRsZSBtZXNzYWdlcyB0aGF0IHJlcXVpcmUgRUFJIGNhcGFiaWxpdHks IHRoZW4gaXQgaGFzIHRocmVlDQpjaG9pY2VzOg0KDQogICAgICAgIChpKSBJZiB0aGUgZW52ZWxv cGUgaXQgcmVjZWl2ZWQgZG9lcyBub3QgY29udGFpbiB0aGUNCiAgICAgICAgVVRGOFNNVFBiaXMg cGFyYW1ldGVyIG9uIHRoZSBNQUlMIGNvbW1hbmQsIHRoZW4gaXQNCiAgICAgICAgcHJvY2VlZHMg dG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gYXMgYSA1MzIxLWNvbXBsaWFudA0KICAgICAgICBzaXR1 YXRpb24uLi4gRUFJIGlzIGlycmVsZXZhbnQuDQoNCiAgICAgICAgKGlpKSBJZiB0aGUgZW52ZWxv cGUgaXQgcmVjZWl2ZWQgY29udGFpbnMgdGhlDQogICAgICAgIFVURjhTTVRQYmlzIHBhcmFtZXRl ciB0byB0aGUgTUFJTCBjb21tYW5kLCBpdCBjYW4gc2ltcGx5DQogICAgICAgIHJlamVjdCAob3Ig Ym91bmNlKSB0aGUgbWVzc2FnZS4NCg0KICAgICAgICAoaWlpKSBJZiB0aGUgZW52ZWxvcGUgaXQg cmVjZWl2ZWQgY29udGFpbnMgdGhlDQogICAgICAgIFVURjhTTVRQYmlzIHBhcmFtZXRlciwgaXQg Y2FuIGRvIHdoYXRldmVyIGl0IG5lZWRzIHRvIGRvDQogICAgICAgIHRvIGRldGVybWluZSB3aGV0 aGVyIGl0IGNhbiBzYWZlbHkgZm9yd2FyZCB0aGUgbWVzc2FnZQ0KICAgICAgICB0byB0aGUgbmV4 dCwgcHJlc3VtYWJseSBub3QtRUFJLWNhcGFibGUsIHN5c3RlbS4gIE9mDQogICAgICAgIGNvdXJz ZSwgaWYgaXQgZG9lcyB0aGF0LCBpdCBtdXN0IG5vdCBpbmNsdWRlIHRoZSBNQUlMDQogICAgICAg IGNvbW1hbmQgcGFyYW1ldGVyIGJlY2F1c2UgdGhlIG5leHQtaG9wIHN5c3RlbSB3aWxsIGhhdmUN CiAgICAgICAgbm90IGFkdmVydGlzZWQgdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUgZXh0ZW5zaW9u Lg0KDQpBbmQsIGFnYWluLCB0aGF0IGlzIHByZXR0eSBtdWNoIHRydWUgcmVnYXJkbGVzcyBvZiB3 aGF0IHdlIHNheQ0KKHdlIGNvdWxkIGVsaW1pbmF0ZSB0aGUgdGhpcmQgY2FzZSBieSBzYXlpbmcg Ik1VU1QgUkVKRUNUIiwgYnV0DQp3ZSB3b3VsZCBiZSBpZ25vcmVkKS4NCg0KU28sIGFnYWluIGNv bnNpc3RlbnQgd2l0aCBteSBlYXJsaWVyIG5vdGUsIGNhbiB3ZSBwb3NzaWJseQ0KbWluaW1pemUg dGhlIHRpbWUgd2Ugc3BlbmQgZGViYXRpbmcgcGFydGljdWxhciB3b3JkaW5nDQpkaWZmZXJlbmNl cyB0aGF0IGFyZSB1bmxpa2VseSB0byBoYXZlIGFueSBlZmZlY3Qgb24NCmltcGxlbWVudGF0aW9u cz8NCg0KICAgIGpvaG4= From jyee@ca.afilias.info Fri Feb 4 11:13: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 C73D53A69CF for ; Fri, 4 Feb 2011 11:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.136 X-Spam-Level: X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=0.129, 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 hGnar-HE8der for ; Fri, 4 Feb 2011 11:13:46 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id ACEF43A694A for ; Fri, 4 Feb 2011 11:13:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: Date: Fri, 4 Feb 2011 14:17:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2301887E-F490-4E2D-9C83-0C3D81FD2102@ca.afilias.info> References: <496231963.07475@cnnic.cn> <496285285.11868@cnnic.cn> To: Charles Lindsey X-Mailer: Apple Mail (2.1082) X-Authenticated: True Cc: IMA 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: Fri, 04 Feb 2011 19:13:48 -0000 On 2011-01-31, at 6:27 AM, Charles Lindsey wrote: > On Sat, 29 Jan 2011 07:15:34 -0000, Jiankang YAO = wrote: >=20 >> ----- 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? >>=20 >>=20 >>> All, >>>=20 >>> Following responses, this issue reached an unanimous consensus that = new parameter to VRFY/EXPN permitted only after EHLO with UTF8SMTPbis. >>>=20 >>=20 >>=20 >> the new parameter is UTF8SMTPbis? >=20 > +1 The WG expressed the want to keep it the same (or consistent), so yes, = the new parameter is UTF8SMTPbis. Of course, the parameter is subject = to change because the new SMTP keyword may change. Regards, Joseph >=20 > --=20 > Charles H. Lindsey ---------At Home, doing my own = thing------------------------ > Tel: +44 161 436 6131 Web: = http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 = 3JU, U.K. > PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 = A4 AB A5 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From jyee@ca.afilias.info Fri Feb 4 11:13: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 8AE853A694A for ; Fri, 4 Feb 2011 11:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.073 X-Spam-Level: X-Spam-Status: No, score=-106.073 tagged_above=-999 required=5 tests=[AWL=0.040, 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 z37bfoThX5Wh for ; Fri, 4 Feb 2011 11:13:56 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 9FE913A6A3A for ; Fri, 4 Feb 2011 11:13:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@ca.afilias.info> Date: Fri, 4 Feb 2011 14:17:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0657CFD7-AFC7-4C97-8C06-FCBF05980E1B@ca.afilias.info> References: <1E79AEE4-A8B9-4BFF-B14B-8C459DA85C2C@ca.afilias.info> To: IMA WG X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: Re: [EAI] Consensus Result on Issue #4 - new reference and term for "ASCII", "non-ASCII", "UTF-8"? -- update X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 19:13:57 -0000 All, Observed from further comments from John Klensin and participants who = supported not to change, the consensus for issues #4 is no change to = references. Regards, Joseph On 2011-01-30, at 4:02 PM, Joseph Yee wrote: > All, >=20 > (First, sorry for late delivery on this one, somehow the original = 'seems lost', and thanks to JianKang to bring this to my attention) >=20 > 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. >=20 > 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 >=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. >=20 > Please notify me of any errors, misunderstanding, or missed opinions. >=20 > Regards, > Joseph >=20 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Shawn.Steele@microsoft.com Fri Feb 4 12:16: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 571203A69E3 for ; Fri, 4 Feb 2011 12:16:46 -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.135, 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 iVDVGOnpqeja for ; Fri, 4 Feb 2011 12:16:45 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4C6783A69D3 for ; Fri, 4 Feb 2011 12:16:45 -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; Fri, 4 Feb 2011 12:20:10 -0800 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.170]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0270.002; Fri, 4 Feb 2011 12:20:10 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: OOF for a 10 days Thread-Index: AcvEqJd1Ipx5BBLWQ6apo93wdoPJVw== Date: Fri, 4 Feb 2011 20:20:10 +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: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A11D1E926TK5EX14MBXC137r_" MIME-Version: 1.0 Subject: [EAI] OOF for a 10 days X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Feb 2011 20:16:46 -0000 --_000_E14011F8737B524BB564B05FF748464A11D1E926TK5EX14MBXC137r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gZ29pbmcgdG8gYmUgb3V0IGZvciBhIHdoaWxlLCBzbyBtYXkgbm90IHJlc3BvbmQuICBJ 4oCZbGwgcHJvYmFibHkgY2hlY2sgbWFpbCwgYnV0IEnigJlkIGxpa2UgdGhlIFdHIHRvIGNvbnRp bnVlIHRvIG1vdmUgZm9yd2FyZCBldmVuIGlmIEkgZG9u4oCZdCByZXBseSDimLogIEkgZG9u4oCZ dCB0aGluayB0aGVyZeKAmXJlIGFueSBhdXRob3JzL3Blb3BsZSB3YWl0aW5nIGZvciBteSBpbnB1 dCBvbiBzb21ldGhpbmcsIGJ1dCBpZiBzb21lb25l4oCZcyB3YWl0aW5nIGZvciBtZSB0byByZXBs eSB0byBzb21ldGhpbmcsIHBsZWFzZSBsZXQgbWUga25vdy4NCg0KDQotIFNoYXduDQoNCu+jou+j kO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0K KFNlbGZob3N0IDc5MTYpDQoNCg== --_000_E14011F8737B524BB564B05FF748464A11D1E926TK5EX14MBXC137r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb2RlMjAwMDsNCglwYW5vc2UtMToyIDAg NiAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQ29kZTIwMDAi Ow0KCXBhbm9zZS0xOjIgMCA2IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBnb2luZyB0byBiZSBv dXQgZm9yIGEgd2hpbGUsIHNvIG1heSBub3QgcmVzcG9uZC4mbmJzcDsgSeKAmWxsIHByb2JhYmx5 IGNoZWNrIG1haWwsIGJ1dCBJ4oCZZCBsaWtlIHRoZSBXRyB0byBjb250aW51ZSB0byBtb3ZlIGZv cndhcmQgZXZlbiBpZiBJIGRvbuKAmXQgcmVwbHkNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpX aW5nZGluZ3MiPko8L3NwYW4+Jm5ic3A7IEkgZG9u4oCZdCB0aGluayB0aGVyZeKAmXJlIGFueSBh dXRob3JzL3Blb3BsZSB3YWl0aW5nIGZvciBteSBpbnB1dCBvbiBzb21ldGhpbmcsIGJ1dCBpZiBz b21lb25l4oCZcyB3YWl0aW5nIGZvciBtZSB0byByZXBseSB0byBzb21ldGhpbmcsIHBsZWFzZSBs ZXQgbWUga25vdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4tIFNoYXduPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpKQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNvZGUyMDAwO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj7vo6Lvo5Dvo6fvo5sg76Oi76Oj 76OX76OU76OZPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvZGUyMDAwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibHVlIj5odHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGU8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFNlbGZob3N0IDc5MTYpPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_E14011F8737B524BB564B05FF748464A11D1E926TK5EX14MBXC137r_-- From Claudio.Allocchio@garr.it Sat Feb 5 06:06:09 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 5B15B3A68FE for ; Sat, 5 Feb 2011 06:06:09 -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 5Mb1vrvqbhie for ; Sat, 5 Feb 2011 06:06:07 -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 3D5A43A68F1 for ; Sat, 5 Feb 2011 06:06:05 -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 p15E9Jge017566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Feb 2011 15:09:21 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p15E9Jge017566 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=ZT0Vr/CvReAN7h2nqPx3S3TgSiAHNYvfoYct3OdEI42wRfgwUaCzqtupbUiVm3fFB TNud3SfoWVO7/uH0lxM4kabE5OLr46fuM23sOEIS4OBaPTYK7HdtYyX6yogQD0tmLKt ReRpK5XOErYhIjsQlBruH+e0R+DgDHcSEKLWqLs= Date: Sat, 5 Feb 2011 15:09:18 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: John C Klensin In-Reply-To: <43D2529E6D43AAF0053C87E0@PST.JCK.COM> Message-ID: References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> <4D4B1BE4.9090601@dcrocker.net> <43D2529E6D43AAF0053C87E0@PST.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dcrocker@bbiw.net, ima@ietf.org 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: Sat, 05 Feb 2011 14:06:09 -0000 Hi, On Fri, 4 Feb 2011, John C Klensin wrote: > Dave, > > First, we have been through "experimental". Complete specs were > published, implementations were produced, tests were performed, > we learned some things from the experiments, and work now should > be focused on the needed changes/ improvements from those > original documents. The long-term participants in the WG are at > least somewhat justified in taking the position that we should > not revisit _any_ of the issues that were discussed at length in > the first round of work (the one that produced the experimental > specs) and that were not shown to be problematic in testing > unless significant new arguments are introduced. It seems you (Dave and John) are talking somhow about different thigns here. The experimental period has done the necessary experimentation in terms of technically working specification, but I do not know if it really "hit" too many times the interaction with the legacy email systems. As an example, I've many many correspondents which live in UTF-8 languages area (and indeed Italian is also UTF-8 to be exact!), I receive hundreds of emails per day... and I never saw one trying to implements the EAI specs. Dave is advocating the effects of interactions between the EAI specifications and legacy systems, and this is a different, but also important, story, which was probably not addressed in the experimental period, or at least did not make enough challegnes. We all are trying to fix also this second interaction, before moving to standards tracks the specification, and I personally believe we have identified a good path to do this. We have identified that (ad least IMHO) that in order to be safe, UTF-8 is just not a simple harmless extension to legacy e-mail, but it is somehow a separte scenario which needs to coexist and correctly interact with legacy email. There is the concept of downgrading, and soft-gatewaying in this. This is why there is some re-focusing on some aspects, which we are discussing in the WG (see issue #1!). > > Second and perhaps more important, please try to read what I > (and others) are actually writing rather than picking up on a > few words and going on the attack. I am trying to avoid > speculating on your motivations, but I know that it is causing > significant delay to progress in the WG without, as far as I can > tell, improving protocol quality. As examples, consider the > text you quoted above: > > (i) I said "complete and competent protocol spec". That has > nothing to do with "no time to do the work correctly" or > "experimental". It is actually a higher standard than the "no > known technical omissions" requirement for Proposed Standard. > When combined with the history of publishing experimental > documents, having independent implementations, performing > interoperability tests on them, and learning from those tests, > it is a reasonable expectation that the protocols will be _much_ > more developed --and that we will be much more sure of them-- > than the IETF norm for Proposed Standards. > (ii) Similarly, if you read all of "revise in a few years or > less anyway and should not spend energy now trying to make sure > we have all the language exactly correct" completely and in > context, it will be clear that I was not talking about the > quality or completeness of the protocol, but only about how very > fine details of the language in which the specifications are > written are sorted out. > > I also note that the intent for Proposed Standards, as described > in RFC 2026, is that documents remain at that level for between > six months and two years. While the "update or expire" > provision of that document has proven ineffective, the > expectation of review and revision within that period is > completely consistent with my suggestion of publication, > implementation, review, and revision as necessary. It is hard > to reconcile it with your apparent belief that any spec that is > expected to be revised within a few years is necessarily either > experimental or unstable/incomplete. as an opinion to all the above points... we are a bit diverging from the main topi... - giving it is anyhow a "lusly separated" email system with downgrading and gatewaying; - giving it also needs further specs to be added for this - giving that we try to optimise the delivery of messages, in this mixed environment then, let's be very pragmatic, and choose some way forward NOW. We are not talking about "wrong specs" which needs correction (but also in this case, we can just re-issue a Proposes Standard, instead of moving to Draft), we are guessing about deploymnent trends, there is no way to be 100% sure about it. > > regards, > 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 ned+ima@mrochek.com Sat Feb 5 08:44: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 ADD6C3A6902 for ; Sat, 5 Feb 2011 08:44:35 -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 Q7ty8nnIgJGd for ; Sat, 5 Feb 2011 08:44:12 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 0C2043A697E for ; Sat, 5 Feb 2011 08:44:12 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXGMFY843400JZQO@mauve.mrochek.com> for ima@ietf.org; Sat, 5 Feb 2011 08:47:36 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXFMPFUM5C007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 5 Feb 2011 08:47:31 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXGMFW1PDG007FL5@mauve.mrochek.com> Date: Sat, 05 Feb 2011 08:27:25 -0800 (PST) In-reply-to: "Your message dated Sat, 05 Feb 2011 15:09:18 +0100 (CET)" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> <4D4B1BE4.9090601@dcrocker.net> <43D2529E6D43AAF0053C87E0@PST.JCK.COM> To: Claudio Allocchio DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296921330; bh=9pmsZXfD1mGwm2DzjRxYVm3uPjxJdynCBPi/AicJwdo=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=jGvq0fUGSM+p+03SI6DBmbDx0/Zms+Ws4gJTg1CfwCPwPjXDh3g8SW11mxd3uw/ps MxkotBp/TBlwn4Oz4rrOHbEIOHR5573nU+ugWejzCnO/mt5/loILcx4iYjxREfHzno 2CEB4IBSzSh1TQsqRf/0wz6jUHevI+UAGOIvhLAU= Cc: dcrocker@bbiw.net, ima@ietf.org 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: Sat, 05 Feb 2011 16:44:35 -0000 > Hi, > On Fri, 4 Feb 2011, John C Klensin wrote: > > > Dave, > > > > First, we have been through "experimental". Complete specs were > > published, implementations were produced, tests were performed, > > we learned some things from the experiments, and work now should > > be focused on the needed changes/ improvements from those > > original documents. The long-term participants in the WG are at > > least somewhat justified in taking the position that we should > > not revisit _any_ of the issues that were discussed at length in > > the first round of work (the one that produced the experimental > > specs) and that were not shown to be problematic in testing > > unless significant new arguments are introduced. > It seems you (Dave and John) are talking somhow about different thigns > here. The experimental period has done the necessary experimentation in > terms of technically working specification, but I do not know if it really > "hit" too many times the interaction with the legacy email systems. That's an excellent point. I'll add that even if there was some interaction, somwhere, the email world isn't exactly homogeneuous. Different geographies, communities, and type of organizations do things very differently, and have very different approaches to solving problems that come up. When MIME first deployed, we were fooled any number of times into thinking we'd seen all the variations out there. > As an > example, I've many many correspondents which live in UTF-8 languages area > (and indeed Italian is also UTF-8 to be exact!), I receive hundreds of > emails per day... and I never saw one trying to implements the EAI specs. FWIW, neither did I. And there was bound to be at least some leakkage had the experiment truly been that widespread. > Dave is advocating the effects of interactions between the EAI > specifications and legacy systems, and this is a different, but also > important, story, which was probably not addressed in the experimental > period, or at least did not make enough challegnes. Exactly. And let's not forget that the experiment was testing a much more radical approach. It would have been foolish had the more radical aspects *not* been the focus, as opposed to more mundane deployment considerations. > We all are trying to fix also this second interaction, before moving to > standards tracks the specification, and I personally believe we have > identified a good path to do this. I agree. > We have identified that (ad least IMHO) that in order to be safe, UTF-8 is > just not a simple harmless extension to legacy e-mail, but it is somehow a > separte scenario which needs to coexist and correctly interact with legacy > email. There is the concept of downgrading, and soft-gatewaying in this. > This is why there is some re-focusing on some aspects, which we are > discussing in the WG (see issue #1!). > > > Second and perhaps more important, please try to read > what I > (and others) are actually writing rather than picking up on a > > few words and going on the attack. I am trying to avoid > > speculating on your motivations, but I know that it is causing > > significant delay to progress in the WG without, as far as I can > > tell, improving protocol quality. As examples, consider the > > text you quoted above: > > (i) I said "complete and competent protocol spec". That has > > nothing to do with "no time to do the work correctly" or > > "experimental". It is actually a higher standard than the "no > > known technical omissions" requirement for Proposed Standard. > > When combined with the history of publishing experimental > > documents, having independent implementations, performing > > interoperability tests on them, and learning from those tests, > > it is a reasonable expectation that the protocols will be _much_ > > more developed --and that we will be much more sure of them-- > > than the IETF norm for Proposed Standards. Yes, but when the goals are as ambitious as they are here ... even this level of robustness may be insufficient. EAI versus some brand new protocol in a completely new niche is really an apples to oranges comparison. > > (ii) Similarly, if you read all of "revise in a few years or > > less anyway and should not spend energy now trying to make sure > > we have all the language exactly correct" completely and in > > context, it will be clear that I was not talking about the > > quality or completeness of the protocol, but only about how very > > fine details of the language in which the specifications are > > written are sorted out. I personally am much more concerned about the interaction of EAI with legacy systems. Document wording... not so much. As I've said, I think the original documents got some of this stuff wrong, and because of the nature of the experimental deployment those issues weren't seen for what they were at the time. As a result these specifications - and I'm talking about the actual content, not the prose - are well designed and developed overall but have a few fairly significant glitches here and there. > > I also note that the intent for Proposed Standards, as described > > in RFC 2026, is that documents remain at that level for between > > six months and two years. While the "update or expire" > > provision of that document has proven ineffective, the > > expectation of review and revision within that period is > > completely consistent with my suggestion of publication, > > implementation, review, and revision as necessary. It is hard > > to reconcile it with your apparent belief that any spec that is > > expected to be revised within a few years is necessarily either > > experimental or unstable/incomplete. > as an opinion to all the above points... we are a bit diverging from the > main topi... Agreed. > - giving it is anyhow a "lusly separated" email system with downgrading > and gatewaying; > - giving it also needs further specs to be added for this > - giving that we try to optimise the delivery of messages, in this mixed > environment > then, let's be very pragmatic, and choose some way forward NOW. We are not > talking about "wrong specs" which needs correction (but also in this case, > we can just re-issue a Proposes Standard, instead of moving to Draft), we > are guessing about deploymnent trends, there is no way to be 100% sure > about it. +1 Ned From ned+ima@mrochek.com Sat Feb 5 14:51: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 E8A183A6C11 for ; Sat, 5 Feb 2011 14:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrwuHdEwXGYO for ; Sat, 5 Feb 2011 14:51:13 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id F16023A6C00 for ; Sat, 5 Feb 2011 14:51:12 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXGZ4PFXTC00HICF@mauve.mrochek.com> for ima@ietf.org; Sat, 5 Feb 2011 14:51:09 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXFMPFUM5C007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 5 Feb 2011 14:51:04 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXGZ4MTL7A007FL5@mauve.mrochek.com> Date: Sat, 05 Feb 2011 14:50:24 -0800 (PST) In-reply-to: "Your message dated Thu, 03 Feb 2011 15:12:35 +0100 (CET)" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> To: Claudio Allocchio DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296943143; bh=QFiMW054qzsg67UKysdjgA5TwNh39//G9eNtJ2qyYWk=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=FMBM8t8oHmepuIOSt+MKgZFeE4S978x1DknNO5rVn+43lcawwEXFK5KiZevfcdGeH ydR9H7nYWbXeM2u0Mce6/9ScdayRMJiFw8DlEkwd2nUsb2Dx87EOS3o3VDXOVPQChV TJjgMl0dvEfcO/ThwgH3IBg29/58swkV9ComUN5o= Cc: Claudio Allocchio , ima@ietf.org 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: Sat, 05 Feb 2011 22:51:14 -0000 > > My own personal sense is that we are better off with SHOULD NOT > > now. When these specs are revised or updated in the future, the > > state of the network and EAI deployment should be assessed and > > the language changed to MAY (and the explanation retuned) as > > needed. While I think it would confuse more than it would help, > > one could also add an explanation of how the operational reading > > of "SHOULD NOT" might evolve with increasing EIA deployment. > yes, SHOULD NOT is better for current situation, and MAY NOT will become > more appropriate with time. And we can always change it during the > document updates. I also prefer SHOULD NOT. Ned From dhc2@dcrocker.net Sun Feb 6 11:37: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 78F163A6970 for ; Sun, 6 Feb 2011 11:37:05 -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 fDe75-W9WLJh for ; Sun, 6 Feb 2011 11:37:03 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id D33C33A6949 for ; Sun, 6 Feb 2011 11:37:03 -0800 (PST) Received: from [192.168.1.11] (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 p16Jb05V029432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 11:37:05 -0800 Message-ID: <4D4EF85C.7050508@dcrocker.net> Date: Sun, 06 Feb 2011 11:37: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: ned+ima@mrochek.com References: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <01NXGZ4MTL7A007FL5@mauve.mrochek.com> In-Reply-To: <01NXGZ4MTL7A007FL5@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, 06 Feb 2011 11:37:06 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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, 06 Feb 2011 19:37:05 -0000 On 2/5/2011 2:50 PM, ned+ima@mrochek.com wrote: >> > My own personal sense is that we are better off with SHOULD NOT >> > now. When these specs are revised or updated in the future, the >> > state of the network and EAI deployment should be assessed and >> > the language changed to MAY (and the explanation retuned) as >> > needed. While I think it would confuse more than it would help, >> > one could also add an explanation of how the operational reading >> > of "SHOULD NOT" might evolve with increasing EIA deployment. > >> yes, SHOULD NOT is better for current situation, and MAY NOT will become >> more appropriate with time. And we can always change it during the >> document updates. > > I also prefer SHOULD NOT. One view that has been expressed is that it does not really matter whether the specification says MAY or SHOULD, since implementers will do whatever they want. That raises a basic question about pursuing standardization at all, but certainly calls to question having the specification say /anything/ about this specific issue. A MAY essential means that the action will not break anything. A SHOULD says that an exception requires knowing exactly when and why the action will not break anything. The statements of preference, here, seem to hinge on near-term, versus long-term, expectations. Whichever normative term is chosen, I strongly suggest that the text contain an explanation of a) the concern that motivates the choice, and b) the expected conditions under which an exception is likely to be acceptable. That is, when is it likely to be safe to ignore the normative directive. For reference, here are the long-term systems implication of the two choices: MAY (This repeats the one I sent earlier) +-----------+ +-----------+ | MUA-ASCII | | MUA-ASCII | +----+------+ +-----------+ | ^ v | +-----------+ +-----------+ +-----------+ +----+------+ | MSA-ASCII +--->| MTA-ASCII +--->| MTA-ASCII +--->| MDA-ASCII | +-----------+ ^ +-----------+ ^ +-----------+ ^ +-----------+ | | | | Gateway | | | | | +-----------+ V +-----------+ V +-----------+ V +-----------+ | MSA-UTF8 |--->| MTA-UTF8 |--->| MTA-UTF8 |--->| MDA-UTF8 +-----------+ +-----------+ +-----------+ +----+------+ ^ | | V +-----------+ +-----------+ | MUA-UTF8 | | MUA-UTF8 | +-----------+ +-----------+ SHOULD NOT: +-----------+ +-----------+ | MUA-ASCII | | MUA-ASCII | +----+------+ +-----------+ | ^ v | +-----------+ +-----------+ +-----------+ +----+------+ | MSA-ASCII +--->| MTA-ASCII +--->| MTA-ASCII +--->| MDA-ASCII | +-----------+ +-----------+ ^ +-----------+ +-----------+ | |ASCII/ASCII | +-----------+ +-----------+ V +-----------+ +-----------+ | MSA-UTF8 |--->| MTA-UTF8 |--->| MTA-UTF8 |--->| MDA-UTF8 | | ---- | | ---- | | ---- | | ---- | | ASCII | | ASCII | | ASCII | | ASCII | +-----------+ +-----------+ +-----------+ +----+------+ ^ | | V +-----------+ +-----------+ | MUA-UTF8 | | MUA-UTF8 | | ---- | | ---- | | ASCII | | ASCII | +-----------+ +-----------+ That is, anything in ASCII stays in ASCII, everywhere and forever, within the scope of this specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sun Feb 6 11:45: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 195E03A69E0 for ; Sun, 6 Feb 2011 11:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 veT30vEKPZLb for ; Sun, 6 Feb 2011 11:45:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E7F1D3A697E for ; Sun, 6 Feb 2011 11:45:46 -0800 (PST) Received: from [192.168.1.11] (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 p16JjhQo029702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 11:45:49 -0800 Message-ID: <4D4EFA67.6020802@dcrocker.net> Date: Sun, 06 Feb 2011 11:45:43 -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: <20110203023246.8302.qmail@joyce.lan> <27874413A115F12BA73F8E05@PST.JCK.COM> <1CE6996F72F0CA4A2FB0CFC7@PST.JCK.COM> <4D4B1BE4.9090601@dcrocker.net> <43D2529E6D43AAF0053C87E0@PST.JCK.COM> In-Reply-To: <43D2529E6D43AAF0053C87E0@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, 06 Feb 2011 11:45:49 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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, 06 Feb 2011 19:45:48 -0000 On 2/4/2011 5:06 AM, John C Klensin wrote: > --On Thursday, February 03, 2011 13:19 -0800 Dave CROCKER > wrote: >> On 2/3/2011 8:07 AM, John C Klensin wrote: >>> I don't know how others in the WG --especially those who are >>> likely to have to do the work-- feel about this but my >>> preference is that we try to get a complete and competent >>> protocol spec out as quickly as we can now, focusing on what >>> people should do in the short term/ early transition phrase as >>> appropriate. We should then move to revise as soon as we have >>> implementations and deployment experience. In other words, I >>> think we will need to revise in a few years or less anyway and >>> should not spend energy now trying to make sure we have all >>> the language exactly correct. ... >> In terms of IETF and Internet timeframes, the expectation of >> having to make changes within a few years qualifies the work >> as "experimental". ... > First, we have been through "experimental". That is why your current expectation of making changes in only a few years is so surprising. Note that the criterion I cited was only the premise of instability that you offered. It does not matter what the previous classification was, nor does it matter what the IETF formal rule on time is. Propagation of changes to the email infrastructure takes quite a few years. So an expected timeframe for making significant changes to a critical specification in less that 10 years invites the view that the specification is unstable. I cited IETF and Internet cultures concerning change. If you have evidence that making significant normative changes 'within a few years' of getting published does not constitute instability, please provide it. > (ii) Similarly, if you read all of "revise in a few years or > less anyway and should not spend energy now trying to make sure > we have all the language exactly correct" completely and in > context, it will be clear that I was not talking about the > quality or completeness of the protocol, but only about how very > fine details of the language in which the specifications are > written are sorted out. So, your view is that the difference between a specification's containing a normative SHOULD NOT versus MAY is merely fine-tuning? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Feb 6 12:46: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 A77533A69DA for ; Sun, 6 Feb 2011 12:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.785 X-Spam-Level: X-Spam-Status: No, score=-108.785 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 1aJMjGYOOh7S for ; Sun, 6 Feb 2011 12:46:23 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 535F13A69AE for ; Sun, 6 Feb 2011 12:46:22 -0800 (PST) Received: (qmail 43052 invoked from network); 6 Feb 2011 20:46:24 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 6 Feb 2011 20:46:24 -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=6a08.4d4f08a0.k1102; i=johnl@user.iecc.com; bh=8K6KUEymzGYPPgwlxKDXTHpc38cCJJnQ7lwWvzDbgvo=; b=EsG0QR/oaeyMajfMyuH8W45xuy09mC8EmxWV/TIBCBvXiGiEF7yAKeA5pSDvl9oK5TqlQdcSM3LuRjtrSsHpWMO29sLJ7vhlKbMVjzxHssQCQ6ZEGXFnX6dv99c5UOQ9uh4Rz8PxWafJZ5nYOOHk0lvsx5nMo0tG3qCzD3LfgIY= 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=6a08.4d4f08a0.k1102; olt=johnl@user.iecc.com; bh=8K6KUEymzGYPPgwlxKDXTHpc38cCJJnQ7lwWvzDbgvo=; b=hPDDH+FfkXB0nxsjTzndct4xZzaRfPdrhOPmai5bg+Tsh+At34RljVeDzMgYkVbQqTBASA9xtJ7RwKghc2SkqdtOnRMmm2VFQ1MDcXQVm1dbRA29w51Im4suw1YdJQFMZUelsHVxYK0AtzAf7PVdz/EH6LmG7+lDY8qdSrPK6JU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Feb 2011 20:46:24 -0000 Message-ID: <20110206204624.27143.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D4EF85C.7050508@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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Feb 2011 20:46:24 -0000 >Whichever normative term is chosen, I strongly suggest that the text >contain an explanation of a) the concern that motivates the choice, >and b) the expected conditions under which an exception is likely to >be acceptable. That is, when is it likely to be safe to ignore the >normative directive. Could you send text, please? I get the impression that you expect something very bad to happen if clients and servers are sloppy about what they label EAI, but I personally don't understand what the badness is. We abandoned all the complicated downgrade stuff, so I think everyone understands that whenever you send a message with the EAI flag set, there's some chance it won't be delivered unless you happen to know that there's an EAI path to all the recipients. 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 Sun Feb 6 13:45: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 9B3BE3A6A3B for ; Sun, 6 Feb 2011 13:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 aT0IGNSnuzhh for ; Sun, 6 Feb 2011 13:45:07 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 5B3773A6B0A for ; Sun, 6 Feb 2011 13:45:07 -0800 (PST) Received: from [192.168.1.11] (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 p16Lj4WB032648 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 13:45:09 -0800 Message-ID: <4D4F1660.1040006@dcrocker.net> Date: Sun, 06 Feb 2011 13:45: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: John Levine References: <20110206204624.27143.qmail@joyce.lan> In-Reply-To: <20110206204624.27143.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]); Sun, 06 Feb 2011 13:45:09 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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, 06 Feb 2011 21:45:10 -0000 On 2/6/2011 12:46 PM, John Levine wrote: >> Whichever normative term is chosen, I strongly suggest that the text >> contain an explanation of a) the concern that motivates the choice, >> and b) the expected conditions under which an exception is likely to >> be acceptable. That is, when is it likely to be safe to ignore the >> normative directive. > > Could you send text, please? I get the impression that you expect > something very bad to happen if clients and servers are sloppy about > what they label EAI, but I personally don't understand what the > badness is. As you know from the DKIM working group, I make it a point to offer candidate text, when I raise an issue and think I understand the details and preferences well enough. This time, I can see the issue, but don't believe I understand what is in other participants' minds about the issue. So I'm asking those who believe they do to offer text. > We abandoned all the complicated downgrade stuff, so I think everyone > understands that whenever you send a message with the EAI flag set, > there's some chance it won't be delivered unless you happen to know > that there's an EAI path to all the recipients. "everyone understands"? really? you mean the guy who hasn't been a member of the working group, has no prior history with EAI and probably does not have much experience with this domain -- in other words, an average programmer or system administrator, in a typical implementation scenario -- and has the task of writing software or deploying it is inherently going to understand the implications? IETF specs are not written for working group participants. They are supposed to be written for non-participants. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Tue Feb 8 05:48:54 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 138F83A7141 for ; Tue, 8 Feb 2011 05:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 nzxo32MIL5Pl for ; Tue, 8 Feb 2011 05:48:53 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 41D1D3A6D8A for ; Tue, 8 Feb 2011 05:48:53 -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; Tue, 8 Feb 2011 05:48:59 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.130]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 05:48:59 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Consensus Result on Issue #1 - Parameter on MAIL Thread-Index: AcvHlkVPlAy3Nyp8QkGlF72Fi70ogA== Date: Tue, 8 Feb 2011 13:48:58 +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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 08 Feb 2011 13:48:54 -0000 > So, your view is that the difference between a specification's containing > a normative SHOULD NOT versus MAY is merely fine-tuning? In general, no. In this case there's little practical difference I think. Either way the b= ehavior requires pretty much exactly the same logic on the server, and the = client isn't forced to look up if it doesn't know. (But if it does know, t= hen it can (SHOULD or MAY) provide the hint to the server). Sorry, I can't= get excited about what's basically a philosophical difference in a technic= al standard, where the technical impact is the same behavior. This is very likely a higher level of detail than most implementations can = or will be able to distinguish between. -Shawn From johnl@iecc.com Tue Feb 8 07:32: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 1EF0E3A67C3 for ; Tue, 8 Feb 2011 07:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.992 X-Spam-Level: X-Spam-Status: No, score=-109.992 tagged_above=-999 required=5 tests=[AWL=1.207, 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 3ANSM7NEW7Ur for ; Tue, 8 Feb 2011 07:32:49 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B96EF3A6765 for ; Tue, 8 Feb 2011 07:32:48 -0800 (PST) Received: (qmail 31561 invoked from network); 8 Feb 2011 15:32:51 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 8 Feb 2011 15:32: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=3fba.4d516222.k1102; i=johnl@user.iecc.com; bh=ZuraVsiP9wRnqNc7brwZeOGoXwESzhmonwrHDuE08SY=; b=svPj0sZk80cC3T3GOc3XJj9GThakKuGmToRhn5iDPFSCkcoQmwbLpcnJWxI5osvNxRfW2JZxGTqY47S4+CNpswIxq+iJMrKTqSV6W9u2/cHpoEVgEl1CsmAafK0eYeaeVsIHn8Af9JF4xwBFodZvdNR2kvswwpNat37XhyKmuXY= 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=3fba.4d516222.k1102; olt=johnl@user.iecc.com; bh=ZuraVsiP9wRnqNc7brwZeOGoXwESzhmonwrHDuE08SY=; b=DjraHTBNziwTNZf9yz2OG0orQ+Pb0kVVZfUc7i3tB+Tza+oEpXKhpX4iudX5aXD5XGnR0n/nj/5p6t12oCPOi/IXrsU9fFAw0mq+Yw5yoUAU0vOGSDv4mWChF5jYEArNkGPH5nfwZ8vpr3KnOUAfxl8h6v/RDirfZ1Mx0jOaQt8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Feb 2011 15:32:50 -0000 Message-ID: <20110208153250.16313.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 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: Tue, 08 Feb 2011 15:32:50 -0000 >This is very likely a higher level of detail than most implementations can or will be able to distinguish between. Agreed. I think I'm hearing that everyone but one thinks the current language is fine, give or take minor tweaks. So unless someone has different text for people to consider, we appear to be done. 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 Tue Feb 8 11:12: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 D5D513A6828 for ; Tue, 8 Feb 2011 11:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 gUoP3rbEE3f7 for ; Tue, 8 Feb 2011 11:12:56 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 9040D3A6825 for ; Tue, 8 Feb 2011 11:12:56 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Feb 2011 11:13:02 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.130]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 11:13:01 -0800 From: Shawn Steele To: John Levine , "ima@ietf.org" Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL Thread-Index: AcvHlkVPlAy3Nyp8QkGlF72Fi70ogAAUjpwA//+3abQ= Date: Tue, 8 Feb 2011 19:13:01 +0000 Message-ID: References: , <20110208153250.16313.qmail@joyce.lan> In-Reply-To: <20110208153250.16313.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] 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: Tue, 08 Feb 2011 19:12:57 -0000 I agree - Shawn Sent from my Windows Phone 7 -----Original Message----- From: John Levine Sent: Tuesday, February 08, 2011 10:34 AM To: ima@ietf.org Cc: Shawn Steele Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL >This is very likely a higher level of detail than most implementations can or will be able to distinguish between. Agreed. I think I'm hearing that everyone but one thinks the current language is fine, give or take minor tweaks. So unless someone has different text for people to consider, we appear to be done. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummi= es", Please consider the environment before reading this e-mail. http://jl.ly From dhc2@dcrocker.net Tue Feb 8 16:05: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 93D523A68B1 for ; Tue, 8 Feb 2011 16:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 VM-FeukAEwyc for ; Tue, 8 Feb 2011 16:05:32 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 760323A6837 for ; Tue, 8 Feb 2011 16:05:32 -0800 (PST) Received: from [192.168.1.8] (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 p1905ZDG011466 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 8 Feb 2011 16:05:40 -0800 Message-ID: <4D51DA4E.8070905@dcrocker.net> Date: Tue, 08 Feb 2011 16:05:34 -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]); Tue, 08 Feb 2011 16:05:40 -0800 (PST) Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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, 09 Feb 2011 00:05:33 -0000 On 2/8/2011 5:48 AM, Shawn Steele wrote: >> So, your view is that the difference between a specification's containing a >> normative SHOULD NOT versus MAY is merely fine-tuning? > > In general, no. > > In this case there's little practical difference I think. Either way the > behavior requires pretty much exactly the same logic on the server, and the > client isn't forced to look up if it doesn't know. (But if it does know, > then it can (SHOULD or MAY) provide the hint to the server). Sorry, I can't > get excited about what's basically a philosophical difference in a technical > standard, where the technical impact is the same behavior. > > This is very likely a higher level of detail than most implementations can or > will be able to distinguish between. The default that implementations choose for handling ASCII data -- that is, casting it as ASCII vs. casting it as UTF-8 -- is going to have a very significant effect on interoperability between UTF-8 and legacy systems. That's not a small point. I'm fascinated by the certitude some folks appear to have about how deployment and operation is going to work for EAI. I had not realized that we could be so sure of such specifics, for something like this... But Shawn's comment essentially reduces down to saying that a normative statement, here, does not matter. I think that Ned's examples from similar cases have similar implications. If a normative statement is not going to be followed, then it should not be a normative statement. So I suggest that the normative statement instead be a non-normative discussion, such as: Legacy ASCII vs. UTF-8 Messages containing only characters <= 0x7f can be treated as legacy ASCII or can be cast as UTF-8. Different operational environments will prefer one over the other. Moving between ASCII-only and UTF-8-only environments requires a gateway. Because there is no guarantee that a next-hop SMTP server will support the UTF8SMTPbis extension, use of the extension always carries a risk of transmission failure. In fact during the early stages of deployment for the extension, the risk will be quite high. Hence there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting 0x7f and below as UTF-8 is that it permits pure-Unicode environments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jason@exchange.microsoft.com Tue Feb 8 19:42: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 BB2B03A685B for ; Tue, 8 Feb 2011 19:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz8N1skQTrlR for ; Tue, 8 Feb 2011 19:42:03 -0800 (PST) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id D4A383A682E for ; Tue, 8 Feb 2011 19:42:03 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.1.218.15; Tue, 8 Feb 2011 19:42:11 -0800 Received: from DF-M14-06.exchange.corp.microsoft.com ([169.254.3.74]) by DF-H14-01.exchange.corp.microsoft.com ([157.54.78.139]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 19:42:11 -0800 From: Jason Nelson To: "dcrocker@bbiw.net" , "ima@ietf.org" Thread-Topic: [EAI] Consensus Result on Issue #1 - Parameter on MAIL Thread-Index: AcvHlkVPlAy3Nyp8QkGlF72Fi70ogAAmds4AAAmBYaA= Date: Wed, 9 Feb 2011 03:41:05 +0000 Message-ID: <6CE0D5FA2297784CB7A6F5F09865C8954CBFCF71@DF-M14-06.exchange.corp.microsoft.com> References: <4D51DA4E.8070905@dcrocker.net> In-Reply-To: <4D51DA4E.8070905@dcrocker.net> 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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 09 Feb 2011 03:42:04 -0000 Agreed on these points. While I hope that the idea that this will be deplo= yed like wildfire and the days of legacy MTAs will fade into memory, I am c= oncerned interop during the decade in-between the release of these RFCs and= when they reach the furthest corners of the internet. Full legacy interop= is a goal (and in my opinion, a reachable one) but in the mean time, your = adjustments to the text look good to me. -----Original Message----- From: ima-bounces@ietf.org [mailto:ima-bounces@ietf.org] On Behalf Of Dave = CROCKER Sent: Tuesday, February 08, 2011 4:06 PM To: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL > The default that implementations choose for handling ASCII data -- that i= s, casting it as ASCII vs. casting it as UTF-8 -- is going to have a very s= ignificant effect on interoperability between UTF-8 and legacy systems. Th= at's not a small point. > I'm fascinated by the certitude some folks appear to have about how deplo= yment and operation is going to work for EAI. I had not realized that we c= ould be so sure of such specifics, for something like this... From johnl@iecc.com Tue Feb 8 21:53: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 EC60F3A6901 for ; Tue, 8 Feb 2011 21:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.596 X-Spam-Level: X-Spam-Status: No, score=-110.596 tagged_above=-999 required=5 tests=[AWL=0.603, 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 daHR2EHaQF+2 for ; Tue, 8 Feb 2011 21:53:48 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id E3B103A68F5 for ; Tue, 8 Feb 2011 21:53:47 -0800 (PST) Received: (qmail 33526 invoked from network); 9 Feb 2011 05:53:51 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Feb 2011 05:53: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=7f5b.4d522bef.k1102; i=johnl@user.iecc.com; bh=hbvWaXWsr2kEVH6P91ye6bbJ6pGNCnAqoHHiQM6w/Bw=; b=BsXuMice9EN69bP1PuLrFoWQsceBN03j5vpZQPda2yNtkq43lrfmj1wA/9jugTEPaxLZoPsIoFh8qvIT2sW5Oj1GGLzHIQitQISW4/Ozh6abKtBPSeOE02PiNUnDYdPUWSsu/CwO/XAcZdXDaE08LIP9DrrgA37hauNxV9pJH2Y= 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=7f5b.4d522bef.k1102; olt=johnl@user.iecc.com; bh=hbvWaXWsr2kEVH6P91ye6bbJ6pGNCnAqoHHiQM6w/Bw=; b=njRvSelUe+FMTe0fCe6AVpp2PxlQ/s+YcpKjdCHRdVEzvN+WzQanqjVEJdVz+r8qD+AvYDQvkKWZ4CU2cFGJ0pWNb5V3OYWOoc5Rmbukr13XrxfvGLfZZeochekAg6XT17qzdBgIGEkOEKLzlWmSJxP+haMRNuLQTjBx0RpzWcc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Feb 2011 05:53:51 -0000 Message-ID: <20110209055351.32602.qmail@joyce.lan> From: John Levine To: ima@ietf.org In-Reply-To: <4D51DA4E.8070905@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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 09 Feb 2011 05:53:50 -0000 >The default that implementations choose for handling ASCII data -- >that is, casting it as ASCII vs. casting it as UTF-8 -- is going to >have a very significant effect on interoperability between UTF-8 and >legacy systems. That's not a small point. Maybe, maybe not. Some MTAs may use the EAI flag that the client sends with a message to decide whether they can relay it to non-EAI destinations. Other MTAs may find that it's so cheap to scan a message for high bits (perhaps as it checks for viruses, or just as it shovels the bytes from the SMTP session into a spool file), and the various combinations of EAI and non-EAI envelope addresses are hard enough to predict, that it's easiest to ignore the client's EAI flag and figure out as each message is about to be relayed whether it needs EAI for the next hop. > I'm fascinated by the certitude some folks appear to have about how > deployment and operation is going to work for EAI. Me, too. At this point, I have no idea how MTAs will implement EAI relay, and I don't think anyone else does, either. So while it's perfectly reasonable that clients SHOULD make the flag match the message if they can, I don't see any basis for adding paragraphs of threats about all the bad things that might happen if they don't. R's, John From dhc2@dcrocker.net Wed Feb 9 09:22: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 421803A67B5 for ; Wed, 9 Feb 2011 09:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 UVk8Z5n0CXSO for ; Wed, 9 Feb 2011 09:22:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 5075A3A67A5 for ; Wed, 9 Feb 2011 09:22:31 -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 p19HMZG1006548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 09:22:41 -0800 Message-ID: <4D52CD58.4050600@dcrocker.net> Date: Wed, 09 Feb 2011 09:22:32 -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: <20110209055351.32602.qmail@joyce.lan> In-Reply-To: <20110209055351.32602.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]); Wed, 09 Feb 2011 09:22:41 -0800 (PST) Cc: ima@ietf.org Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL 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, 09 Feb 2011 17:22:32 -0000 On 2/8/2011 9:53 PM, John Levine wrote: > I don't see any basis for adding > paragraphs of threats about all the bad things that might happen if > they don't. I don't either, which is why the text has no 'threats'. (I'm assuming your were not merely engaging in dismissive hyperbole to circumvent serious discussion.) If you think otherwise, please indicate what text you see as having threats and how it qualifies as threats. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chl@clerew.man.ac.uk Fri Feb 11 06:46: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 622B33A6999 for ; Fri, 11 Feb 2011 06:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 M5-K6KmELdI5 for ; Fri, 11 Feb 2011 06:46:00 -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 EB72D3A694F for ; Fri, 11 Feb 2011 06:45:59 -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 8F81522193 for ; Fri, 11 Feb 2011 14:46:13 +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, 11 Feb 2011 14:46:13 +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 p1BEkCej008769 for ; Fri, 11 Feb 2011 14:46:13 GMT To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <4D51DA4E.8070905@dcrocker.net> Content-Transfer-Encoding: 8bit Date: Fri, 11 Feb 2011 14:46:12 -0000 Message-ID: In-Reply-To: <4D51DA4E.8070905@dcrocker.net> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4d554bb5.dadc-46b8-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 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 11 Feb 2011 14:46:01 -0000 On Wed, 09 Feb 2011 00:05:34 -0000, Dave CROCKER wrote: > So I suggest that the normative statement instead be a non-normative > discussion, such as: > > > Legacy ASCII vs. UTF-8 > > Messages containing only characters <= 0x7f can be treated as > legacy ASCII or can be cast as UTF-8. Different operational environments > will prefer one over the other. Moving between ASCII-only and UTF-8-only > environments requires a gateway. > > Because there is no guarantee that a next-hop SMTP server will > support the UTF8SMTPbis extension, use of the extension always carries a > risk of transmission failure. In fact during the early stages of > deployment for the extension, the risk will be quite high. Hence there > is a distinct near-term advantage for ASCII-only messages to be sent > without using this extension. The long-term advantage of casting 0x7f > and below as UTF-8 is that it permits pure-Unicode environments. +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 ned+ima@mrochek.com Sun Feb 13 13:36: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 A54583A6878 for ; Sun, 13 Feb 2011 13:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LpAkWkZ1LSk for ; Sun, 13 Feb 2011 13:36:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 69A223A6997 for ; Sun, 13 Feb 2011 13:36:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXS2VFK3R400HQMP@mauve.mrochek.com> for ima@ietf.org; Sun, 13 Feb 2011 13:36:55 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXPN84OCUO007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 13 Feb 2011 13:36:52 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXS2VE861E007FL5@mauve.mrochek.com> Date: Sun, 13 Feb 2011 13:35:45 -0800 (PST) In-reply-to: "Your message dated Tue, 08 Feb 2011 16:05:34 -0800" <4D51DA4E.8070905@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4D51DA4E.8070905@dcrocker.net> To: Dave CROCKER DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1297629445; bh=xliXFR4ieg2Vi5IfUuIYodM6Dm407XgNmx1tgBc/NUQ=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Y3Nb04TK6QM77S+iHrWnn1GcgSdwYR5VpRTrXW0WxZeWaUFSUF1mCvAFB54cuWeuA mjte/FueKBWEwSZf6fEG3Qztf4rwLsO/G+L8rc4SSNoSW40hwz0x7eV22usm0Zqkp+ Rs7KFnEnBAfd2HVjxalfFjWKjDQCwDEHfsT0GuPc= Cc: "ima@ietf.org" 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: Sun, 13 Feb 2011 21:36:36 -0000 > On 2/8/2011 5:48 AM, Shawn Steele wrote: > >> So, your view is that the difference between a specification's containing a > >> normative SHOULD NOT versus MAY is merely fine-tuning? > > > > In general, no. > > > > In this case there's little practical difference I think. Either way the > > behavior requires pretty much exactly the same logic on the server, and the > > client isn't forced to look up if it doesn't know. (But if it does know, > > then it can (SHOULD or MAY) provide the hint to the server). Sorry, I can't > > get excited about what's basically a philosophical difference in a technical > > standard, where the technical impact is the same behavior. > > > > This is very likely a higher level of detail than most implementations can or > > will be able to distinguish between. > The default that implementations choose for handling ASCII data -- that is, > casting it as ASCII vs. casting it as UTF-8 -- is going to have a very > significant effect on interoperability between UTF-8 and legacy systems. That's > not a small point. > I'm fascinated by the certitude some folks appear to have about how deployment > and operation is going to work for EAI. I had not realized that we could be so > sure of such specifics, for something like this... > But Shawn's comment essentially reduces down to saying that a normative > statement, here, does not matter. I think that Ned's examples from similar > cases have similar implications. > If a normative statement is not going to be followed, > then it should not be a normative statement. > So I suggest that the normative statement instead be a non-normative discussion, > such as: > Legacy ASCII vs. UTF-8 > Messages containing only characters <= 0x7f can be treated as legacy ASCII > or can be cast as UTF-8. Different operational environments will prefer one over > the other. Moving between ASCII-only and UTF-8-only environments requires a > gateway. > Because there is no guarantee that a next-hop SMTP server will support the > UTF8SMTPbis extension, use of the extension always carries a risk of > transmission failure. In fact during the early stages of deployment for the > extension, the risk will be quite high. Hence there is a distinct near-term > advantage for ASCII-only messages to be sent without using this extension. The > long-term advantage of casting 0x7f and below as UTF-8 is that it permits > pure-Unicode environments. I prefer SHOULD NOT language, but this language is also acceptable. Ned From yaojk@cnnic.cn Mon Feb 14 00:32: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 35AFC3A6AB3 for ; Mon, 14 Feb 2011 00:32:30 -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.629 X-Spam-Level: X-Spam-Status: No, score=-97.629 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 WZu58gtz4z8r for ; Mon, 14 Feb 2011 00:32:29 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id C663B3A6971 for ; Mon, 14 Feb 2011 00:32:28 -0800 (PST) Received: (eyou send program); Mon, 14 Feb 2011 16:32:51 +0800 Message-ID: <497672371.07432@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, 14 Feb 2011 16:32:51 +0800 Message-ID: From: "Jiankang YAO" To: "Joseph Yee" , "EAI WG" References: <496232816.07572@cnnic.cn> Date: Mon, 14 Feb 2011 16:32:53 +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: [EAI] is it time for chairs to give a conclusion for Issue #1 ? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Feb 2011 08:32:30 -0000 RGVhciBhbGwsDQoNCg0KICAgIGl0IHNlZW1zIHRoYXQgd2UgaGF2ZSBhIGxvdCBvZiBkaXNjdXNz aW9uIGFib3V0IHRoaXMgaXNzdWUuDQoNCiAgICBpcyBpdCB0aW1lIGZvciBjaGFpcnMgdG8gZ2l2 ZSBhIGNvbmNsdXNpb24gZm9yICBJc3N1ZSAjMSA/DQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvc2VwaCBZZWUiIDxqeWVlQGNh LmFmaWxpYXMuaW5mbz4NClRvOiAiRUFJIFdHIiA8aW1hQGlldGYub3JnPg0KU2VudDogU2F0dXJk YXksIEphbnVhcnkgMjksIDIwMTEgMTI6NDAgQU0NClN1YmplY3Q6IFtFQUldIENvbnNlbnN1cyBS ZXN1bHQgb24gSXNzdWUgIzEgLSBQYXJhbWV0ZXIgb24gTUFJTCBGUk9NDQoNCg0KPiBBbGwsDQo+ IA0KPiBGb2xsb3dpbmcgcmVzcG9uc2VzLCB0aGlzIGlzc3VlIHJlYWNoZWQgdGhlIGNvbnNlbnN1 cyB0byBhZGQgcGFyYW1ldGVyIG9uIE1BSUwgRlJPTS4gIFRoZSByZXN1bHQgd2lsbCBiZSBkb2N1 bWVudGVkIGF0IGlzc3VlIHRyYWNrZXIgKGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2Vh aS90cmFjL3JlcG9ydC8xKS4NCj4gDQo+IFN1YnNlcXVlbnQgIHByb3Bvc2VkIHF1ZXN0aW9ucyAN Cj4gMS4gV2hhdCBpcyB0aGUgbmFtZSBvZiB0aGUgcGFyYW1ldGVyPw0KPiAyLiBEb2VzIHRoZSBw YXJhbWV0ZXIgaGF2ZSB2YWx1ZSBvciBub3Q/ICBXaGF0IGtpbmQgb2YgdmFsdWU/DQo+IA0KPiBO ZXcgaXNzdWVzIHJhaXNlZCBkdXJpbmcgdGhlIGRpc2N1c3Npb24NCj4gMS4gVGhlcmUgYXJlIDIg ZGlmZmVyZW50IGlkZWFzIG9mIE1BSUwgRlJPTSBpbnRlcmFjdGlvbiBiZXR3ZWVuIE1VQSBhbmQg TVRBLiANCj4gICAgMS4xIE1VQSB0ZWxscyBNVEEgdGhhdCBpdHNlbGYgaXMgRUFJIGNhcGFibGUs IGhlbmNlIGFsbCBtZXNzYWdlcyBydW4gaW4gIkVBSS1tb2RlIiAoTVVBIGFsd2F5cyB1c2VzIHRo ZSBwYXJhbWV0ZXIgd2hlbiBhdmFpbGFibGUpDQo+ICAgIDEuMiBNVUEgdGVsbHMgTVRBIHRoYXQg dGhlIGZvbGxvd2luZyBtZXNzYWdlIG5lZWRzIHRvIHJ1biB1bmRlciBFQUktbW9kZSAodGhlIG5l eHQgbWVzc2FnZSBmcm9tIE1VQSBtYXkgbm90IHVzZSB0aGUgcGFyYW1ldGVyLCBhbHRob3VnaCBi b3RoIGFyZSBFQUkgY2FwYWJsZSwgdGhlIGludGVyYWN0aW9uIGFuZCBtZXNzYWdlIHJ1biB1bmRl ciAgUkZDNTMyMS81MzIyKQ0KPiBJIHdpbGwgc3RhcnQgYSBuZXcgdGhyZWFkIGZvciB0aGlzIGRp c2N1c3Npb24uICAgIA0KPiANCj4gDQo+IFBsZWFzZSBub3RpZnkgbWUgb2YgYW55IGVycm9ycywg bWlzdW5kZXJzdGFuZGluZywgb3IgbWlzc2VkIG9waW5pb25zLg0KPiANCj4gUmVnYXJkcywNCj4g Sm9zZXBoDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaW1h From eai@troystarr.net Mon Feb 14 12:33: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 4A5913A6C51 for ; Mon, 14 Feb 2011 12:33:04 -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 mBbPrprepoiS for ; Mon, 14 Feb 2011 12:33:03 -0800 (PST) Received: from remote.troystarr.net (remote.troystarr.net [173.160.129.13]) by core3.amsl.com (Postfix) with ESMTP id 7B23B3A6C4E for ; Mon, 14 Feb 2011 12:33:03 -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, 14 Feb 2011 12:33:26 -0800 From: Troy Starr To: 'Jiankang YAO' , 'Joseph Yee' , 'EAI WG' Date: Mon, 14 Feb 2011 12:33:20 -0800 Thread-Topic: [EAI] is it time for chairs to give a conclusion for Issue #1 ? Thread-Index: AcvMgdjPjO9eeVfvTK2RKKlXp/hWzQAAB1ng Message-ID: References: <496232816.07572@cnnic.cn> 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] is it time for chairs to give a conclusion for Issue #1 ? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Feb 2011 20:33:04 -0000 Hi Jiankang - > it seems that we have a lot of discussion about this issue. >=20 > is it time for chairs to give a conclusion for Issue #1 ? Yes, I think so. I'd like to see the actual proposed text based on these c= onclusions be available for review for a reasonable but finite (and pre-ann= ounced) amount of time, i.e. "here's the actual text we want to insert into= the document, please provide your feedback about it by [now + 1 or 2 week= s], at which point the authors will review the feedback and accept or rejec= t each of the suggestions and incorporate the final text." Perhaps the typ= ical procedure is to simply insert some proposed text into the document and= then present the entire document for review, and if so, that's fine with m= e. In either case, I think we do need a review period for new text where the b= ar for feedback isn't extremely high, but to make that period be limited so= that we can see the glide path for landing the RFC. I say this because ma= ny of the comments provided so far seem to be different ways to communicate= similar concepts. I think that's been a valuable exercise in terms of nor= mative vs. informative, SHOULD/MAY, etc. But future comments at this stage= might be spinning our wheels. Actual proposed text would let us move forw= ard. - Troy Starr From jyee@ca.afilias.info Tue Feb 15 22:29: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 1260E3A6D8C for ; Tue, 15 Feb 2011 22:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[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 jEzgWaldIqIz for ; Tue, 15 Feb 2011 22:29:27 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id E8E1A3A6D91 for ; Tue, 15 Feb 2011 22:29:26 -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: Wed, 16 Feb 2011 01:29:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <75F14E72-A17A-46CE-9C8E-1B438C6C48A8@ca.afilias.info> References: <282C11A6-361B-4B63-B742-455E2A964F99@ca.afilias.info> <4D42F1D7.6060207@dcrocker.net> To: Dave CROCKER , EAI WG X-Mailer: Apple Mail (2.1082) X-Authenticated: True 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: Wed, 16 Feb 2011 06:29:28 -0000 The WG went through rounds to determine name selection for poll then = poll to determine the actual name in 2007. Names in various = 'message/rfc2822' extensions had been suggested and the WG consensus = preferred name not in the format of extension. The WG will not reopen the issue regarding name change to = 'message/global'. Regards, Joseph, co-chair EAI 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 jyee@ca.afilias.info Tue Feb 15 22:29: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 0F52A3A6DA1 for ; Tue, 15 Feb 2011 22:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.187 X-Spam-Level: X-Spam-Status: No, score=-106.187 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 Uzn9Kd2C6qQR for ; Tue, 15 Feb 2011 22:29:31 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 2E2C83A6D8C for ; Tue, 15 Feb 2011 22:29:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <4D42F28F.5060403@dcrocker.net> Date: Wed, 16 Feb 2011 01:29:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21F50B57-12F4-4435-8F9C-80F004D952BE@ca.afilias.info> <4D42F28F.5060403@dcrocker.net> To: EAI WG , Dave CROCKER X-Mailer: Apple Mail (2.1082) X-Authenticated: True 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 List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 06:29:32 -0000 For lack of discussion, and seeing it not necessary. With the consensus = made to remove repetition, editors will make their best judgement how to = reference normative text. Regards, Joseph, co-chair EAI On 2011-01-28, at 11:45 AM, Dave CROCKER wrote: >=20 >=20 > 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. >=20 >=20 > Excellent idea. >=20 >=20 > Perhaps something like: >=20 > The details for are covered in . >=20 > where: >=20 > 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. >=20 > y is as precise a citation as can be provided. >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From jyee@ca.afilias.info Tue Feb 15 22:32: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 B4C673A6D91 for ; Tue, 15 Feb 2011 22:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.039, 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 B68dqUfm9gc3 for ; Tue, 15 Feb 2011 22:32:09 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id BD2D83A6DA2 for ; Tue, 15 Feb 2011 22:32:07 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 01:32:34 -0500 Message-Id: To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] consensus text and parameter of 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, 16 Feb 2011 06:32:12 -0000 All, Below are consensus text and parameter regarding MAIL FROM after = discussion on: (1) determining the meaning the parameter (2) the text to use to explain the usage (3) the parameter syntax -------- (1) the meaning the parameter Through out the discussion, the WG agreed that the parameter intends to = tell MTA that the following message needs to run under EAI-mode. --------- (2) consensus text If the envelope or message being sent requires the capabilities of these = EAI extensions, the client MUST supply the UTF8SMTPbis parameter with = the MAIL command. If the client is aware that the envelope or message being sent does not = require any of the EAI extension capabilities, it SHOULD NOT supply the = UTF8SMTPbis parameter with the MAIL command. Because there is no = guarantee that a next-hop SMTP server will support the UTF8SMTPbis = extension, use of the extension always carries a risk of transmission = failure. In fact during the early stages of deployment for the = extension, the risk will be quite high. Hence there is a distinct = near-term advantage for ASCII-only messages to be sent without using = this extension. The long-term advantage of casting 0x7f and below as = UTF-8 is that it permits pure-Unicode environments. This specification = does not require that the client inspect the message or otherwise go to = extraordinary lengths to assure itself that EAI capabilities are not = required for the particular message. =20 -- Note: - 'SHOULD NOT' was kept, with text explaining the reason behind and the = long term desire - Interop is important, however making gateway as necessity deployment = in order for ASCII mail exchange between 2 different platforms makes = adoption more complicate. This also requires more text to explain = gateway. Gateway is optional in current standard and will remain the = same in EAI. Gateway text is not acceptable in this regard. - The detail explaining of EAI extensions is less likely needed once the = text integrates with the rest of RFC5336bis content. Editors can = determine to expand it if necessary. ---------- (3) parameter syntax The consensus agreed that that parameter will not make distinction of = which part of message (envelop, header, etc) contains UTF-8 characters, = nor will it make distinction whether the message is UTF-8 or below 0x7f. = The presence of the parameter itself is the only indication needed to = notify MTA to process the message under EAI-mode. There is only keyword, and no value(s) assigned. The keyword is = 'UTF8SMTPbis', same as SMTP EHLO keyword and the parameter of VRFY/EXPN. = It is subject to change when the new keyword named. ---------- With this and rest of issues closed (EAI Trac issue#1 - issue#7), = editors should have the clarity needed for draft revision. Regards, Joseph, co-chair EAI= From jyee@ca.afilias.info Tue Feb 15 22:39: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 37FE13A6D81 for ; Tue, 15 Feb 2011 22:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=0.026, 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 2Th1eHqSNmfr for ; Tue, 15 Feb 2011 22:39:38 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 5F47D3A6DA9 for ; Tue, 15 Feb 2011 22:39:38 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 01:40:04 -0500 Message-Id: <0E12029A-F6C3-4D33-B74A-266A2FDAD77C@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] EAI session request for Prague meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 16 Feb 2011 06:39:40 -0000 All, Session request made for EAI meeting in Prague, details below. Agenda = to be determined, we need new revision of the draft for agenda and = meeting :) Reminder of few important dates 2011-02-24 (Thursday): Preliminary agenda published for comment. 2011-02-28 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (01:00 Tuesday, March 1 UTC). 2011-02-28 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (01:00 Tuesday, March = 1 UTC). 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT = (01:00 Tuesday, March 15 UTC) Regards, Joseph=20 --------------------------------------------------------- Working Group Name: eai Area Name: Applications Area Session Requester: Joseph Yee Number of Sessions: 1 Length of Session(s): 2.5 hours Number of Attendees: 50 Conflicts to Avoid: First Priority: apparea iri morg sieve yam marf dnsext dkim hybi = httpbis vwrap precis ftpext2 urnbis kitten abfab Second Priority: enum dnsop vcarddav decade Special Requests: additional 2nd priority conflict to avoid: all other APP area WGs and = BOFs We need WebEx so that co-chair (John Klensin) can participate and = chairing process. Thanks ---------------------------------------------------------= From chl@clerew.man.ac.uk Wed Feb 16 03:03: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 EE18A3A6C9C for ; Wed, 16 Feb 2011 03:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 59QmNbQmOJUz for ; Wed, 16 Feb 2011 03:03:32 -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 8ED7A3A6DF4 for ; Wed, 16 Feb 2011 03:03:31 -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 66A8222604 for ; Wed, 16 Feb 2011 11:03: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; Wed, 16 Feb 2011 11:03: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 p1GB3vBo013852 for ; Wed, 16 Feb 2011 11:03:58 GMT Date: Wed, 16 Feb 2011 11:03:57 -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: 4d5baf1f.966f-2824-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] consensus text and parameter of 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, 16 Feb 2011 11:03:34 -0000 On Wed, 16 Feb 2011 06:32:34 -0000, Joseph Yee wrote: > If the client is aware that the envelope or message being sent does not > require any of the EAI extension capabilities, it SHOULD NOT supply the > UTF8SMTPbis parameter with the MAIL command. Because there is no > guarantee that a next-hop SMTP server will support the UTF8SMTPbis > extension, use of the extension always carries a risk of transmission > failure. In fact during the early stages of deployment for the > extension, the risk will be quite high. Hence there is a distinct > near-term advantage for ASCII-only messages to be sent without using > this extension. The long-term advantage of casting 0x7f and below as > UTF-8 is that it permits pure-Unicode environments. This specification > does not require that the client inspect the message or otherwise go to > extraordinary lengths to assure itself that EAI capabilities are not > required for the particular message. s/use of the extension always carries/unnecessary use of the extension always carries/ > > -- > Note: > - 'SHOULD NOT' was kept, with text explaining the reason behind and the > long term desire Not my preference, but if that is the consensus then OK. -- 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 Feb 16 03:12: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 047D73A6E05 for ; Wed, 16 Feb 2011 03:12: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 Xme1jXY4IXlW for ; Wed, 16 Feb 2011 03:12:13 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 3AA153A6DFD for ; Wed, 16 Feb 2011 03:12:13 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PpfJI-0007IP-IP; Wed, 16 Feb 2011 06:12:40 -0500 Date: Wed, 16 Feb 2011 06:12:39 -0500 From: John C Klensin To: Joseph Yee , IMA WG Message-ID: <0551231C095F0DB436D4AAF8@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] consensus text and parameter of 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, 16 Feb 2011 11:12:15 -0000 Joseph, Thanks for getting these posted. WG participants, In order to make progress, I believe we should consider these matters closed, with no further discussion of them unless (1) Clarification of Joseph's statements or intent is required (2) Really new information appears or difficulties that have not been raised previously are discovered. thanks, john From jyee@ca.afilias.info Thu Feb 17 11:52: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 0D19F3A6D4C for ; Thu, 17 Feb 2011 11:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[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 dSCDKieCaazb for ; Thu, 17 Feb 2011 11:52:15 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id C45283A6D50 for ; Thu, 17 Feb 2011 11:52:14 -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 1Pq9uA-0005S5-3P for ima@ietf.org; Thu, 17 Feb 2011 19:52: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 1Pq9u9-0007M8-69 for ima@ietf.org; Thu, 17 Feb 2011 19:52:45 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 14:52:44 -0500 Message-Id: <8DF7410B-7B68-4B8D-9215-A11CE12B7CA6@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] RFC5335bis review and poll X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 17 Feb 2011 19:52:17 -0000 Hi all, On reviewing the changes proposed for RFC5335bis, there are several = questions to ask the WG. Each question will have its own thread, the question will also log in = issue tracker. I will send them out today and take 1 week (until Feb = 23) for conclusion. The following questions (very brief here) are to ask WG to consider: 1. Is the new text in Abstract acceptable? 2. Is the new text in Introduction acceptable? (Note, this is asking = the text in section 1, excluding section 1.1 and 1.2. I will put the = exact text in the poll) 3. The text in section 1.1 and the text in section 1.2 (Relations to = Other Standards) in version -07 of the doc would need some review and = edit. I will try to make the first cut for the WG to consider. Exact = text will be included in poll for clarity. Additional issues, no need of poll: 4. The consensus of no change to terminology applied to RFC5335bis. = There is no need to refine nor redefine any term specific for the draft. 5. The new ABNF suggestion is generally well received. We will use it = as base and to address any issues. 6. "Message Labeling" in section 4 is out of scope. They need to be = removed on next revision. Best Regards, Joseph, co-chair EAI =20= From trac@tools.ietf.org Thu Feb 17 11:26: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 D09543A6E4A for ; Thu, 17 Feb 2011 11:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 VU+jy5yDFjOM for ; Thu, 17 Feb 2011 11:26:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C355E3A6DE3 for ; Thu, 17 Feb 2011 11:26:07 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pq9Us-00056T-V1; Thu, 17 Feb 2011 11:26:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Thu, 17 Feb 2011 19:26:38 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/3#comment:1 Message-ID: <070.60ab99e596628e9c59f30a5b5892dde9@tools.ietf.org> References: <061.1698c56fcd82d27b0dc42d51da9dbf85@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <061.1698c56fcd82d27b0dc42d51da9dbf85@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Thu, 17 Feb 2011 17:20:40 -0800 Cc: ima@ietf.org Subject: Re: [EAI] [eai] rfc5336bis #3 (closed): consensus question: remove repetition of normative text? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 19:26:08 -0000 #3: consensus question: remove repetition of normative text? Changes (by jyee@…): * status: new => closed * resolution: => fixed Comment: consensus: remove repetition of normative text -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: closed Priority: major | Milestone: Component: rfc5336bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: consensus | ----------------------------------+----------------------------------------- Ticket URL: eai From trac@tools.ietf.org Thu Feb 17 11:27: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 174493A6E52 for ; Thu, 17 Feb 2011 11:27:06 -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.029, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Z7AV-PCZD-FG for ; Thu, 17 Feb 2011 11:27:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 52CAC3A6D31 for ; Thu, 17 Feb 2011 11:27:05 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pq9Vp-0006vh-7o; Thu, 17 Feb 2011 11:27:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Thu, 17 Feb 2011 19:27:37 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/5#comment:1 Message-ID: <070.74041da768e2212ad60a9669d9514548@tools.ietf.org> References: <061.8ceafd231f4edefbe3acc56c1ef2f215@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <061.8ceafd231f4edefbe3acc56c1ef2f215@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Thu, 17 Feb 2011 17:20:41 -0800 Cc: ima@ietf.org Subject: Re: [EAI] [eai] rfc5336bis #5 (closed): consensus question: keep nested encodings for message/global? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 19:27:06 -0000 #5: consensus question: keep nested encodings for message/global? Changes (by jyee@…): * status: new => closed * resolution: => fixed Comment: consensus: keep nested encodings for message/global -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: closed Priority: major | Milestone: Component: rfc5336bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: eai From yaojk@cnnic.cn Thu Feb 17 19:49: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 C29A93A6C24 for ; Thu, 17 Feb 2011 19:49:37 -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.836 X-Spam-Level: X-Spam-Status: No, score=-98.836 tagged_above=-999 required=5 tests=[AWL=1.207, 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 H3VQ1d3HA+Hf for ; Thu, 17 Feb 2011 19:49:36 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id CFD753A6C21 for ; Thu, 17 Feb 2011 19:49:35 -0800 (PST) Received: (eyou send program); Fri, 18 Feb 2011 11:50:04 +0800 Message-ID: <498001004.06798@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, 18 Feb 2011 11:50:04 +0800 Message-ID: <4FAE78DFE3B342BD98C0CF237896B53F@LENOVO47E041CF> From: "Jiankang YAO" To: "Joseph Yee" , "IMA WG" References: <497972377.24712@cnnic.cn> Date: Fri, 18 Feb 2011 11:47:36 +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] RFC5335bis review and poll X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 03:49:37 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvc2VwaCBZZWUiIDxqeWVl QGNhLmFmaWxpYXMuaW5mbz4NClRvOiAiSU1BIFdHIiA8aW1hQGlldGYub3JnPg0KU2VudDogRnJp ZGF5LCBGZWJydWFyeSAxOCwgMjAxMSAzOjUyIEFNDQpTdWJqZWN0OiBbRUFJXSBSRkM1MzM1Ymlz IHJldmlldyBhbmQgcG9sbA0KDQoNCj4gSGkgYWxsLA0KPiANCj4gT24gcmV2aWV3aW5nIHRoZSBj aGFuZ2VzIHByb3Bvc2VkIGZvciBSRkM1MzM1YmlzLCB0aGVyZSBhcmUgc2V2ZXJhbCBxdWVzdGlv bnMgdG8gYXNrIHRoZSBXRy4NCj4gDQo+IEVhY2ggcXVlc3Rpb24gd2lsbCBoYXZlIGl0cyBvd24g dGhyZWFkLCB0aGUgcXVlc3Rpb24gd2lsbCBhbHNvIGxvZyBpbiBpc3N1ZSB0cmFja2VyLiAgSSB3 aWxsIHNlbmQgdGhlbSBvdXQgdG9kYXkgYW5kIHRha2UgMSB3ZWVrICh1bnRpbCBGZWIgMjMpIGZv ciBjb25jbHVzaW9uLg0KPiANCj4gVGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgKHZlcnkgYnJpZWYg aGVyZSkgYXJlIHRvIGFzayBXRyB0byBjb25zaWRlcjoNCj4gDQo+IDEuIElzIHRoZSBuZXcgdGV4 dCBpbiBBYnN0cmFjdCBhY2NlcHRhYmxlPw0KPiANCg0KY291bGQgeW91IGtpbmRseSBsaXN0IHdo YXQgdGhlIG5ldyB0ZXh0IGlzID8NCkkgdGhpbmsgdGhhdCBpdCB3aWxsIGhlbHAgd2cgdG8gYW5z d2VyIHRoZSBxdWVzdGlvbi4NCg0KPiAyLiBJcyB0aGUgbmV3IHRleHQgaW4gSW50cm9kdWN0aW9u IGFjY2VwdGFibGU/ICAoTm90ZSwgdGhpcyBpcyBhc2tpbmcgdGhlIHRleHQgaW4gc2VjdGlvbiAx LCBleGNsdWRpbmcgc2VjdGlvbiAxLjEgYW5kIDEuMi4gIEkgd2lsbCBwdXQgdGhlIGV4YWN0IHRl eHQgaW4gdGhlIHBvbGwpDQo+IA0KDQpzYW1lIGFib3ZlLg0KDQp0aGFua3MuDQoNCkppYW5rYW5n IFlhbw0KDQoNCj4gMy4gVGhlIHRleHQgaW4gc2VjdGlvbiAxLjEgYW5kIHRoZSB0ZXh0IGluIHNl Y3Rpb24gMS4yIChSZWxhdGlvbnMgdG8gT3RoZXIgU3RhbmRhcmRzKSBpbiB2ZXJzaW9uIC0wNyBv ZiB0aGUgZG9jIHdvdWxkIG5lZWQgc29tZSByZXZpZXcgYW5kIGVkaXQuICBJIHdpbGwgdHJ5IHRv IG1ha2UgdGhlIGZpcnN0IGN1dCBmb3IgdGhlIFdHIHRvIGNvbnNpZGVyLiAgRXhhY3QgdGV4dCB3 aWxsIGJlIGluY2x1ZGVkIGluIHBvbGwgZm9yIGNsYXJpdHkuDQo+IA0KPiBBZGRpdGlvbmFsIGlz c3Vlcywgbm8gbmVlZCBvZiBwb2xsOg0KPiANCj4gNC4gVGhlIGNvbnNlbnN1cyBvZiBubyBjaGFu Z2UgdG8gdGVybWlub2xvZ3kgYXBwbGllZCB0byBSRkM1MzM1YmlzLiAgVGhlcmUgaXMgbm8gbmVl ZCB0byByZWZpbmUgbm9yIHJlZGVmaW5lIGFueSB0ZXJtIHNwZWNpZmljIGZvciB0aGUgZHJhZnQu DQo+IA0KPiA1LiBUaGUgbmV3IEFCTkYgc3VnZ2VzdGlvbiBpcyBnZW5lcmFsbHkgd2VsbCByZWNl aXZlZC4gIFdlIHdpbGwgdXNlIGl0IGFzIGJhc2UgYW5kIHRvIGFkZHJlc3MgYW55IGlzc3Vlcy4N Cj4gDQo+IDYuICJNZXNzYWdlIExhYmVsaW5nIiBpbiBzZWN0aW9uIDQgaXMgb3V0IG9mIHNjb3Bl LiAgVGhleSBuZWVkIHRvIGJlIHJlbW92ZWQgb24gbmV4dCByZXZpc2lvbi4NCj4gDQo+IEJlc3Qg UmVnYXJkcywNCj4gSm9zZXBoLCBjby1jaGFpciBFQUkNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1B QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From trac@tools.ietf.org Thu Feb 17 21:30: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 363813A6CB6 for ; Thu, 17 Feb 2011 21:30:10 -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.029, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 7MxVdqY5g0m5 for ; Thu, 17 Feb 2011 21:30:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0DD363A6A9D for ; Thu, 17 Feb 2011 21:30:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PqIvP-00028Q-Em; Thu, 17 Feb 2011 21:30:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Fri, 18 Feb 2011 05:30:39 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/8 Message-ID: <061.7ec4029a1a8bfcd35fb70a71da9f27ba@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: ima@ietf.org Subject: [EAI] [eai] rfc5335bis #8 (new): POLL: new text in Abstract section in RFC5335bis to replace the original X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:30:10 -0000 #8: POLL: new text in Abstract section in RFC5335bis to replace the original POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? new text -------- Abstract 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. -------- -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: new Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Keywords: poll ----------------------------------+----------------------------------------- Ticket URL: eai From trac@tools.ietf.org Thu Feb 17 21:35: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 7DF2B3A6B77 for ; Thu, 17 Feb 2011 21:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 KEuoaGuw888A for ; Thu, 17 Feb 2011 21:35:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9F1713A6A9D for ; Thu, 17 Feb 2011 21:35:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PqJ0s-000074-74; Thu, 17 Feb 2011 21:36:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Fri, 18 Feb 2011 05:36:18 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/9 Message-ID: <061.f6dd7ddac0864b015aa8d8a42d505635@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: ima@ietf.org Subject: [EAI] [eai] rfc5335bis #9 (new): POLL: new text in Introduction in RFC5335bis to replace the original X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:35:47 -0000 #9: POLL: new text in Introduction in RFC5335bis to replace the original POLL: Is the new text in Introduction section in RFC5335bis good to replace the original? new text -------- 1. Introduction Internet mail distinguishes a message from its transport and further divides a message between a header and a body [RFC5598]. Internet mail header fields contain a variety of strings that are intended to be user-visible. The range of supported characters for these strings was originally limited to a subset of [ASCII]; globalization of the Internet requires support of the much larger set contained in UTF-8 [RFC5198]. Complex encoding alternatives to UTF-8, as an overlay to the existing ASCII base, would introduce inefficiencies as well as opportunities for processing errors. Native support for UTF-8 encoding [RFC3629] is widely available among systems now used over the Internet. Hence supporting this encoding directly within email is desired. This document specifies an enhancement to Internet mail that permits the use of UTF-8 encoding, rather than only ASCII, as the base form for header fields. This specification is based on a model of native, end-to-end support for UTF-8, which uses an "8-bit clean" environment . Support for carriage across legacy, 7-bit infrastructure and for processing by 7-bit receivers requires additional mechanisms that are not provided by this specification. -------- original text -------- 1.1. Role of This Specification Full internationalization of electronic mail requires several capabilities: o The capability to transmit non-ASCII content, provided for as part of the basic MIME specification [RFC2045], [RFC2046]. o The capability to use international characters in envelope addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and specified in [I-D.ietf-eai-rfc5336bis]. o The capability to express those addresses, and information related to them and based on them, in mail header fields, defined in this document. This document specifies a variant of Internet mail that permits the use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the base form for Internet email header fields. This form is permitted in transmission, if authorized by the SMTP extension specified in [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of processing it. -------- -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: new Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Keywords: poll ----------------------------------+----------------------------------------- Ticket URL: eai From trac@tools.ietf.org Thu Feb 17 21:36: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 7F5713A6A9D for ; Thu, 17 Feb 2011 21:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 easvmAhUY-ee for ; Thu, 17 Feb 2011 21:36:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9E3AD3A6B77 for ; Thu, 17 Feb 2011 21:36:49 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PqJ1u-0001oi-L8; Thu, 17 Feb 2011 21:37:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Fri, 18 Feb 2011 05:37:22 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/8#comment:1 Message-ID: <070.f92fd56f891631481867899a596dc57f@tools.ietf.org> References: <061.7ec4029a1a8bfcd35fb70a71da9f27ba@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <061.7ec4029a1a8bfcd35fb70a71da9f27ba@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: ima@ietf.org Subject: Re: [EAI] [eai] rfc5335bis #8 (new): POLL: new text in Abstract section in RFC5335bis to replace the original X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:36:50 -0000 #8: POLL: new text in Abstract section in RFC5335bis to replace the original Description changed by jyee@…: Old description: > POLL: Is the new text in Abstract section in RFC5335bis good to replace > the original? > > new text > -------- > Abstract > > 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. > > -------- New description: POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? new text -------- Abstract 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. -------- original text -------- Abstract Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies a variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification updates Section 6.4 of [RFC2045] to conform with the requirements. -------- -- -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: new Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Keywords: poll ----------------------------------+----------------------------------------- Ticket URL: eai From trac@tools.ietf.org Thu Feb 17 21:49: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 89E083A6AA9 for ; Thu, 17 Feb 2011 21:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 cPHtjp8fGrrY for ; Thu, 17 Feb 2011 21:49:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B343F3A6862 for ; Thu, 17 Feb 2011 21:49:46 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PqJEQ-00061B-Tp; Thu, 17 Feb 2011 21:50:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Fri, 18 Feb 2011 05:50:18 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/10 Message-ID: <061.b8d85652120b4a3876444913cb96953e@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: ima@ietf.org Subject: [EAI] [eai] rfc5335bis #10 (new): POLL: new text to insert as subsection (1.x) under section Introduction X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:49:47 -0000 #10: POLL: new text to insert as subsection (1.x) under section Introduction POLL: Is the new text good to insert as subsection (1.1) under the Introduction section, replacing section 1.2 under version 07 and section 1.1 under version 08 of RFC5335bis suggested text -------- 1.1 Brief Overview of Changes This document updates email header [RFC5322] and MIME header [RFC2045]. Email header value extends beyond ASCII, allowing UTF-8 encoding. MIME header lifts the prohibition against using content-transfer-encoding on all subtypes under composite-type "message/". Appendix A documents the derived ABNF rules that inherit support UTF-8, due to the update of ABNF introduces from this document. [Editor notes will be removed before Last Call] [Editor Note 1: This revision (-08 and up) changed the ABNF approach compared to previous revision (-07 and before). ] [Editor Note 2: pending -- ABF to support IDN] [Editor Note 3: Discuss with WG whether some fields, like Trace header, have issues if UTF-8 encoding allowed in values] -------- -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: new Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Keywords: poll ----------------------------------+----------------------------------------- Ticket URL: eai From jyee@ca.afilias.info Thu Feb 17 21:56: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 C7D693A6C4E for ; Thu, 17 Feb 2011 21:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.246 X-Spam-Level: X-Spam-Status: No, score=-106.246 tagged_above=-999 required=5 tests=[AWL=0.019, 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 6+e4MZL0voVO for ; Thu, 17 Feb 2011 21:56:04 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 094563A69D0 for ; Thu, 17 Feb 2011 21:56:03 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 00:56:33 -0500 Message-Id: <40D8C5BF-09CA-48F2-8822-25FF111D37F6@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 05:56:04 -0000 POLL: Is the new text in Abstract section in RFC5335bis good to replace = the original? Please reply to this thread, poll will close at Feb 23, 23:59 Pacific = Time. (Poll also logged at issue tracker = http://trac.tools.ietf.org/wg/eai/trac/ticket/8) -------- new text Abstract 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. -------- original text Abstract Full internationalization of electronic mail requires not only the = capabilities to transmit non-ASCII content, to encode selected = information in specific header fields, and to use non-ASCII characters = in envelope addresses. It also requires being able to express those = addresses and the information based on them in mail header fields. This = document specifies a variant of Internet mail that permits the use of = Unicode encoded in UTF-8, rather than ASCII, as the base form for = Internet email header field. This form is permitted in transmission only = if authorized by an SMTP extension, as specified in an associated = specification. This specification updates Section 6.4 of [RFC2045] to = conform with the requirements.= From jyee@ca.afilias.info Thu Feb 17 21:56: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 391343A69D0 for ; Thu, 17 Feb 2011 21:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.016, 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 KYEHS427Wyks for ; Thu, 17 Feb 2011 21:56:04 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 518C13A6AA9 for ; Thu, 17 Feb 2011 21:56:04 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 00:56:36 -0500 Message-Id: <19944E42-79D9-44C2-84E1-828432D4D19A@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] POLL: Is the new text in Introduction section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 05:56:05 -0000 POLL: Is the new text in Introduction section in RFC5335bis good to = replace the original? Please reply to this thread, poll will close at Feb 23, 23:59 Pacific = Time. (Poll also logged at issue tracker = http://trac.tools.ietf.org/wg/eai/trac/ticket/9) -------- new text 1. Introduction Internet mail distinguishes a message from its transport and further = divides a message between a header and a body [RFC5598]. Internet mail = header fields contain a variety of strings that are intended to be = user-visible. The range of supported characters for these strings was = originally limited to a subset of [ASCII]; globalization of the Internet = requires support of the much larger set contained in UTF-8 [RFC5198]. = Complex encoding alternatives to UTF-8, as an overlay to the existing = ASCII base, would introduce inefficiencies as well as opportunities for = processing errors. Native support for UTF-8 encoding [RFC3629] is widely = available among systems now used over the Internet. Hence supporting = this encoding directly within email is desired. This document specifies = an enhancement to Internet mail that permits the use of UTF-8 encoding, = rather than only ASCII, as the base form for header fields. This specification is based on a model of native, end-to-end support for = UTF-8, which uses an "8-bit clean" environment . Support for carriage = across legacy, 7-bit infrastructure and for processing by 7-bit = receivers requires additional mechanisms that are not provided by this = specification. -------- original text 1.1. Role of This Specification Full internationalization of electronic mail requires several = capabilities: o The capability to transmit non-ASCII content, provided for as part of the basic MIME specification [RFC2045], [RFC2046]. o The capability to use international characters in envelope addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and specified in = [I-D.ietf-eai-rfc5336bis]. o The capability to express those addresses, and information related to them and based on them, in mail header fields, defined in this = document. This document specifies a variant of Internet mail that permits the use = of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the base = form for Internet email header fields. This form is permitted in = transmission, if authorized by the SMTP extension specified in = [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of = processing it.= From jyee@ca.afilias.info Thu Feb 17 21:56: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 32BF43A69D0 for ; Thu, 17 Feb 2011 21:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.252 X-Spam-Level: X-Spam-Status: No, score=-106.252 tagged_above=-999 required=5 tests=[AWL=0.013, 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 CAi-G5B+I8tJ for ; Thu, 17 Feb 2011 21:56:06 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 67DD03A6E0C for ; Thu, 17 Feb 2011 21:56:06 -0800 (PST) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 00:56:38 -0500 Message-Id: <927F5C7C-647B-4F7B-AF29-3690052111E3@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Authenticated: True Subject: [EAI] POLL: Is the new text good to insert as subsection (1.1) under the Introduction section, replacing section 1.2 under version 07 and section 1.1 under version 08 of RFC5335bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 05:56:07 -0000 POLL: Is the new text good to insert as subsection (1.1) under the = Introduction section, replacing section 1.2 under version 07 and section = 1.1 under version 08 of RFC5335bis Please reply to this thread, poll will close at Feb 23, 23:59 Pacific = Time. (Poll also logged at issue tracker = http://trac.tools.ietf.org/wg/eai/trac/ticket/10) suggested text 1.1 Brief Overview of Changes This document updates email header [RFC5322] and MIME header [RFC2045]. = Email header value extends beyond ASCII, allowing UTF-8 encoding. MIME = header lifts the prohibition against using content-transfer-encoding on = all subtypes under composite-type "message/". Appendix A documents the derived ABNF rules that inherit support UTF-8, = due to the update of ABNF introduces from this document. [Editor notes will be removed before Last Call] [Editor Note 1: This revision (-08 and up) changed the ABNF approach = compared to previous revision (-07 and before). ] [Editor Note 2: pending -- ABF to support IDN] [Editor Note 3: Discuss with WG whether some fields, like Trace header, = have issues if UTF-8 encoding allowed in values]= From ned+ima@mrochek.com Fri Feb 18 12:17: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 B23E53A6FCA for ; Fri, 18 Feb 2011 12:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 FX76CbbRDdI9 for ; Fri, 18 Feb 2011 12:17:13 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 0176D3A6F46 for ; Fri, 18 Feb 2011 12:17:13 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXYZK0KSRK00L7S7@mauve.mrochek.com> for ima@ietf.org; Fri, 18 Feb 2011 12:17:45 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXPN84OCUO007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 18 Feb 2011 12:17:42 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NXYZJYX2GI007FL5@mauve.mrochek.com> Date: Fri, 18 Feb 2011 11:11:09 -0800 (PST) In-reply-to: "Your message dated Fri, 18 Feb 2011 00:56:33 -0500" <40D8C5BF-09CA-48F2-8822-25FF111D37F6@ca.afilias.info> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <40D8C5BF-09CA-48F2-8822-25FF111D37F6@ca.afilias.info> To: Joseph Yee DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1298056619; bh=kD2FdALwBrINjE3VlFDYPJvteRSV+ATcxZFmuFWHWxs=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=QlQ+21OHiBPyyoDbKabrQP9dqcaxmV534D/Hn1eozsOD5xdZ55NlP+X3dlYm7BkUL 21trCQ7Muil07cO6+4Tlj0P7iXTK+i4hyBxksfT5dpMafMuhIgUhoW7LUzChxkvgaJ X41l8VRE1etq17WiOEb3j4EqOY8NJ14qpDO8muBQ= Cc: IMA WG Subject: Re: [EAI] POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 20:17:13 -0000 > POLL: Is the new text in Abstract section in RFC5335bis good to replace the > original? The new text is somewhat improved, but still needs work. In particular, see the last sentence This document specifies an enhancement to Internet mail that permits native UTF-8 support in the header and body of a message. First of all, this says nothing about extending envelope fields - a HUGE omission. Second, use of the term "body" here is incorrect. This proposal does not provide a general mechanism to put UTF-8 in bodies. MIME does that. Rather, what this proposal does is allow use of UTF-8 in headers (both message and MIME) and envelope address fields. So the sentence needs to be something like: This document specifies an enhancement to Internet mail that permits native UTF-8 support in envlope address, message header and MIME header fields. Ned From dhc2@dcrocker.net Fri Feb 18 12:40: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 76F3E3A6F9B for ; Fri, 18 Feb 2011 12:40:55 -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 B91WooOBLufc for ; Fri, 18 Feb 2011 12:40:54 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 78A0F3A6E4D for ; Fri, 18 Feb 2011 12:40:54 -0800 (PST) Received: from [192.168.1.7] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p1IKfNPt008007 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 12:41:28 -0800 Message-ID: <4D5ED966.7030708@dcrocker.net> Date: Fri, 18 Feb 2011 12:41:10 -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: ned+ima@mrochek.com References: <40D8C5BF-09CA-48F2-8822-25FF111D37F6@ca.afilias.info> <01NXYZJYX2GI007FL5@mauve.mrochek.com> In-Reply-To: <01NXYZJYX2GI007FL5@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]); Fri, 18 Feb 2011 12:41:29 -0800 (PST) Cc: IMA WG Subject: Re: [EAI] POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? 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, 18 Feb 2011 20:40:55 -0000 On 2/18/2011 11:11 AM, ned+ima@mrochek.com wrote: > First of all, this says nothing about extending envelope fields - a HUGE > omission. Second, use of the term "body" here is incorrect. This proposal does > not provide a general mechanism to put UTF-8 in bodies. MIME does that. Rather, > what this proposal does is allow use of UTF-8 in headers (both message and > MIME) and envelope address fields. So the sentence needs to be something > like: > > This document specifies an enhancement to Internet mail that > permits native UTF-8 support in envlope address, message header and > MIME header fields. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Fri Feb 18 13:27: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 737953A6EA5 for ; Fri, 18 Feb 2011 13:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Stym4zf1SaRE for ; Fri, 18 Feb 2011 13:27:02 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 8EF703A6AAE for ; Fri, 18 Feb 2011 13:27:02 -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; Fri, 18 Feb 2011 13:27:36 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.130]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Fri, 18 Feb 2011 13:27:36 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: #8 New text in Abstract Thread-Index: AcvPsqcvzFQXzdeyS6KZz66JuLQ7BQ== Date: Fri, 18 Feb 2011 21:27:35 +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.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] #8 New text in Abstract X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 21:27:03 -0000 I'm happy with the new text. -Shawn ------------------------------ Message: 4 Date: Fri, 18 Feb 2011 05:30:39 -0000 From: "eai issue tracker" Subject: [EAI] [eai] rfc5335bis #8 (new): POLL: new text in Abstract section in RFC5335bis to replace the original To: jyee@ca.afilias.info Cc: ima@ietf.org Message-ID: <061.7ec4029a1a8bfcd35fb70a71da9f27ba@tools.ietf.org> Content-Type: text/plain; charset=3D"utf-8" #8: POLL: new text in Abstract section in RFC5335bis to replace the origina= l POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? new text -------- Abstract 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. -------- --=20 From Shawn.Steele@microsoft.com Fri Feb 18 13:28: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 925723A6EA5 for ; Fri, 18 Feb 2011 13:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 QwDIv5F7HQ+k for ; Fri, 18 Feb 2011 13:28:37 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F39E73A6FB1 for ; Fri, 18 Feb 2011 13:28:36 -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, 18 Feb 2011 13:29:11 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.130]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0270.002; Fri, 18 Feb 2011 13:29:11 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: #9 new text in Introduction of 5335bis Thread-Index: AcvPstLz1iEBRxRyT6WPJf1VGJPA/g== Date: Fri, 18 Feb 2011 21:29:10 +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.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] #9 new text in Introduction of 5335bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 21:28:38 -0000 I'm also happy with the new introduction text. -Shawn ------------------------------ Message: 5 Date: Fri, 18 Feb 2011 05:36:18 -0000 From: "eai issue tracker" Subject: [EAI] [eai] rfc5335bis #9 (new): POLL: new text in Introduction in RFC5335bis to replace the original To: jyee@ca.afilias.info Cc: ima@ietf.org Message-ID: <061.f6dd7ddac0864b015aa8d8a42d505635@tools.ietf.org> Content-Type: text/plain; charset=3D"utf-8" #9: POLL: new text in Introduction in RFC5335bis to replace the original POLL: Is the new text in Introduction section in RFC5335bis good to replace the original? new text -------- 1. Introduction Internet mail distinguishes a message from its transport and further divides a message between a header and a body [RFC5598]. Internet mail header fields contain a variety of strings that are intended to be user-visible. The range of supported characters for these strings was originally limited to a subset of [ASCII]; globalization of the Internet requires support of the much larger set contained in UTF-8 [RFC5198]. Complex encoding alternatives to UTF-8, as an overlay to the existing ASCII base, would introduce inefficiencies as well as opportunities for processing errors. Native support for UTF-8 encoding [RFC3629] is widely available among systems now used over the Internet. Hence supporting this encoding directly within email is desired. This document specifies an enhancement to Internet mail that permits the use of UTF-8 encoding, rather than only ASCII, as the base form for header fields. This specification is based on a model of native, end-to-end support for UTF-8, which uses an "8-bit clean" environment . Support for carriage across legacy, 7-bit infrastructure and for processing by 7-bit receivers requires additional mechanisms that are not provided by this specification. -------- original text -------- 1.1. Role of This Specification Full internationalization of electronic mail requires several capabilities: o The capability to transmit non-ASCII content, provided for as part of the basic MIME specification [RFC2045], [RFC2046]. o The capability to use international characters in envelope addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and specified in [I-D.ietf-eai-rfc5336bis]. o The capability to express those addresses, and information related to them and based on them, in mail header fields, defined in this document. This document specifies a variant of Internet mail that permits the use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the base form for Internet email header fields. This form is permitted in transmission, if authorized by the SMTP extension specified in [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of processing it. -------- From Shawn.Steele@microsoft.com Fri Feb 18 13:30:04 2011 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3B93A6AAE for ; Fri, 18 Feb 2011 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 pyVyEa62GAGB for ; Fri, 18 Feb 2011 13:30:03 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5EA2A3A6ECB for ; Fri, 18 Feb 2011 13:29:59 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 18 Feb 2011 13:30:33 -0800 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.130]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Fri, 18 Feb 2011 13:30:33 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: #10 - new text to insert as subsection (1.x) under section Introduction Thread-Index: AcvPsxDGhC8QMS0US/m3/xwO9gggKg== Date: Fri, 18 Feb 2011 21:30:33 +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.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] #10 - new text to insert as subsection (1.x) under section Introduction X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 21:30:04 -0000 I'm also fine with this -Shawn ------------------------------ Message: 7 Date: Fri, 18 Feb 2011 05:50:18 -0000 From: "eai issue tracker" Subject: [EAI] [eai] rfc5335bis #10 (new): POLL: new text to insert as subsection (1.x) under section Introduction To: jyee@ca.afilias.info Cc: ima@ietf.org Message-ID: <061.b8d85652120b4a3876444913cb96953e@tools.ietf.org> Content-Type: text/plain; charset=3D"utf-8" #10: POLL: new text to insert as subsection (1.x) under section Introductio= n POLL: Is the new text good to insert as subsection (1.1) under the Introduction section, replacing section 1.2 under version 07 and section 1.1 under version 08 of RFC5335bis suggested text -------- 1.1 Brief Overview of Changes This document updates email header [RFC5322] and MIME header [RFC2045]. Email header value extends beyond ASCII, allowing UTF-8 encoding. MIME header lifts the prohibition against using content-transfer-encoding on all subtypes under composite-type "message/". Appendix A documents the derived ABNF rules that inherit support UTF-8, due to the update of ABNF introduces from this document. [Editor notes will be removed before Last Call] [Editor Note 1: This revision (-08 and up) changed the ABNF approach compared to previous revision (-07 and before). ] [Editor Note 2: pending -- ABF to support IDN] [Editor Note 3: Discuss with WG whether some fields, like Trace header, have issues if UTF-8 encoding allowed in values] -------- --=20 ----------------------------------+----------------------------------------= - Reporter: jyee@? | Owner: =20 Type: state | Status: new=20 Priority: major | Milestone: =20 Component: rfc5335bis | Version: =20 Severity: Active WG Document | Keywords: poll ----------------------------------+----------------------------------------= - Ticket URL: eai ------------------------------ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima End of IMA Digest, Vol 67, Issue 20 *********************************** From stpeter@stpeter.im Fri Feb 18 15:08: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 99FE73A6EDE for ; Fri, 18 Feb 2011 15:08:59 -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 B4eAr2YDI2gI for ; Fri, 18 Feb 2011 15:08:58 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A7B753A6EDA for ; Fri, 18 Feb 2011 15:08:58 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9FEE140D41 for ; Fri, 18 Feb 2011 16:27:52 -0700 (MST) Message-ID: <4D5EFC2B.5040106@stpeter.im> Date: Fri, 18 Feb 2011 16:09:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ima@ietf.org References: <40D8C5BF-09CA-48F2-8822-25FF111D37F6@ca.afilias.info> <01NXYZJYX2GI007FL5@mauve.mrochek.com> <4D5ED966.7030708@dcrocker.net> In-Reply-To: <4D5ED966.7030708@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090604080306000803000800" Subject: Re: [EAI] POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 18 Feb 2011 23:08:59 -0000 This is a cryptographically signed message in MIME format. --------------ms090604080306000803000800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/18/11 1:41 PM, Dave CROCKER wrote: >=20 >=20 > On 2/18/2011 11:11 AM, ned+ima@mrochek.com wrote: >> First of all, this says nothing about extending envelope fields - a HU= GE >> omission. Second, use of the term "body" here is incorrect. This >> proposal does >> not provide a general mechanism to put UTF-8 in bodies. MIME does >> that. Rather, >> what this proposal does is allow use of UTF-8 in headers (both message= >> and >> MIME) and envelope address fields. So the sentence needs to be somethi= ng >> like: >> >> This document specifies an enhancement to Internet mail that >> permits native UTF-8 support in envlope address, message header and= >> MIME header fields. >=20 > +1 Agreed, that's better. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090604080306000803000800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx ODIzMDkzMVowIwYJKoZIhvcNAQkEMRYEFPCgJTOgNqB6QVSLg4ZuoIKYS+ADMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBdSkT7dW7AcCHZjttmWSjDwy/XeAcgzR/Cv6CSLLwrLlvJiLr0KIFuLF4G DcZAk2u9RahRLawck84BwRFczEhBm5thdcqHsTYsID/DSatYlbH2RCOr0SsLgenURWBMZuD4 0mTm8fNtjkLzFo/mdpggJ1S24CoDfBJ1atO4sR2Ye5jVTxp2cgTkhnTg/B+U9wMI1kb4anT4 bvrnvrLaiLyiC0NzGZjLujL7BnHbYkiN2CMCjN6Av9+gk6o/vt/Q1d8XjmcLICAf1luJzv6s IwXQRSqojaBtFbYtwzJi9unQxD8joRBFd2P6FqnDYdVK6XvdyOHqRLVBJ1t5XXojjgIkAAAA AAAA --------------ms090604080306000803000800-- From ned+ima@mrochek.com Sat Feb 19 18:12: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 E86613A6EDA for ; Sat, 19 Feb 2011 18:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 mdfrW-QRGWkw for ; Sat, 19 Feb 2011 18:12:02 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id BDE393A6CFE for ; Sat, 19 Feb 2011 18:12:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NY0Q9C7GSW00G9CF@mauve.mrochek.com> for ima@ietf.org; Sat, 19 Feb 2011 18:12:38 -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 <01NXPN84OCUO007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 19 Feb 2011 18:12:35 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NY0Q9AZFOU007FL5@mauve.mrochek.com> Date: Sat, 19 Feb 2011 18:09:03 -0800 (PST) In-reply-to: "Your message dated Fri, 18 Feb 2011 05:36:18 +0000" <061.f6dd7ddac0864b015aa8d8a42d505635@tools.ietf.org> References: <061.f6dd7ddac0864b015aa8d8a42d505635@tools.ietf.org> To: eai issue tracker DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1298164307; bh=pWpiXL2ISzq98O3dYCXSvVLo7xfMekyFmsM0JAI1SCQ=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:References:To; b=F1XvbH0s7t0A2h0qhp/RkelXAysy/C+jQoXmP9GvvV7VzJNGEnaJ9EGa3DCRsC5v4 7p3Oloc/oTAYvSSigZk4eGfabnMPmjvViWe78sIkYZsO1voUWHnzK0tLwPYXXXghaB 8b5XkxgobJ1V6E2jQ0tKZFd+JZSFg4GXN5Poh+PI= Cc: ima@ietf.org Subject: Re: [EAI] [eai] rfc5335bis #9 (new): POLL: new text in Introduction in RFC5335bis to replace the original X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 20 Feb 2011 02:12:04 -0000 > #9: POLL: new text in Introduction in RFC5335bis to replace the original > POLL: Is the new text in Introduction section in RFC5335bis good to > replace > the original? I'm sorry to have to say it, but in this case the old text is actually considerably better. The new text has all of the sae problems as the proposed new abstract text - in particular it fails to mention envelope address fields - but here it's worse. It's essentialt that the introduction state exactly what parts of the syntax of messages are being changed. The old text did that, the new text does not. I strongly recommend going back to the original text and if necessary tweaking the terminology it uses. Ned > new text > -------- > 1. Introduction > Internet mail distinguishes a message from its transport and further > divides a message between a header and a body [RFC5598]. Internet > mail header fields contain a variety of strings that are intended to > be user-visible. The range of supported characters for these strings > was originally limited to a subset of [ASCII]; globalization of the > Internet requires support of the much larger set contained in UTF-8 > [RFC5198]. Complex encoding alternatives to UTF-8, as an overlay to > the existing ASCII base, would introduce inefficiencies as well as > opportunities for processing errors. Native support for UTF-8 > encoding [RFC3629] is widely available among systems now used over > the Internet. Hence supporting this encoding directly within email > is desired. This document specifies an enhancement to Internet mail > that permits the use of UTF-8 encoding, rather than only ASCII, as > the base form for header fields. > This specification is based on a model of native, end-to-end support > for UTF-8, which uses an "8-bit clean" environment . Support for > carriage across legacy, 7-bit infrastructure and for processing by > 7-bit receivers requires additional mechanisms that are not provided > by this specification. > -------- > original text > -------- > 1.1. Role of This Specification > Full internationalization of electronic mail requires several > capabilities: > o The capability to transmit non-ASCII content, provided for as part > of the basic MIME specification [RFC2045], [RFC2046]. > o The capability to use international characters in envelope > addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and > specified in [I-D.ietf-eai-rfc5336bis]. > o The capability to express those addresses, and information related > to them and based on them, in mail header fields, defined in this > document. > This document specifies a variant of Internet mail that permits the > use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the > base form for Internet email header fields. This form is permitted > in transmission, if authorized by the SMTP extension specified in > [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of > processing it. > -------- > -- > ----------------------------------+----------------------------------------- > Reporter: jyee@… | Owner: > Type: state | Status: new > Priority: major | Milestone: > Component: rfc5335bis | Version: > Severity: Active WG Document | Keywords: poll > ----------------------------------+----------------------------------------- > Ticket URL: > eai > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From ned+ima@mrochek.com Sat Feb 19 18:17: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 C8FD03A6D35 for ; Sat, 19 Feb 2011 18:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 kC3occmZLxTi for ; Sat, 19 Feb 2011 18:17:50 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 4324D3A6CFE for ; Sat, 19 Feb 2011 18:17:50 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NY0QGJLSIO00JKYH@mauve.mrochek.com> for ima@ietf.org; Sat, 19 Feb 2011 18:18:27 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXPN84OCUO007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 19 Feb 2011 18:18:24 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NY0QGI9W08007FL5@mauve.mrochek.com> Date: Sat, 19 Feb 2011 18:16:17 -0800 (PST) In-reply-to: "Your message dated Wed, 16 Feb 2011 01:32:34 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Joseph Yee DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1298164655; bh=JY3rC0JdDWK6SjFXMpR/JSLAwWk93KeJ8bbk3hGoLQM=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=jgGh6pyhygvW08KDBvHjOeKUFY8K5wlIT84QiyriAdzNIuwiv6//l02kJ1tr7uGCY 5fKZvQOEjWBviHZrTeecd4Gn2zRvKdO0HQ1O4q2UuJ1fZq93quLg1kaO05u1FlvmqH 47lPk+z4IiVVEpyXXD/EGDghEW03VfHmXXFa7GyE= Cc: IMA WG Subject: Re: [EAI] consensus text and parameter of 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, 20 Feb 2011 02:17:51 -0000 > All, > Below are consensus text and parameter regarding MAIL FROM after discussion on: > (1) determining the meaning the parameter > (2) the text to use to explain the usage > (3) the parameter syntax +1 on everything except the actual parameter name - it's ugly. However, since I have nothing better to propose, I suggest retaining it unless someone else has an alternate, clearly superior name to suggest. Ned > -------- > (1) the meaning the parameter > Through out the discussion, the WG agreed that the parameter intends to tell MTA that the following message needs to run under EAI-mode. > --------- > (2) consensus text > If the envelope or message being sent requires the capabilities of these EAI extensions, the client MUST supply the UTF8SMTPbis parameter with the MAIL command. > If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command. Because there is no guarantee that a next-hop SMTP server will support the UTF8SMTPbis extension, use of the extension always carries a risk of transmission failure. In fact during the early stages of deployment for the extension, the risk will be quite high. Hence there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting 0x7f and below as UTF-8 is that it permits pure-Unicode environments. This specification does not require that the client inspect the message or otherwise go to extraordinary lengths to assure itself that EAI capabilities are not required for the particular message. > -- > Note: > - 'SHOULD NOT' was kept, with text explaining the reason behind and the long term desire > - Interop is important, however making gateway as necessity deployment in order for ASCII mail exchange between 2 different platforms makes adoption more complicate. This also requires more text to explain gateway. Gateway is optional in current standard and will remain the same in EAI. Gateway text is not acceptable in this regard. > - The detail explaining of EAI extensions is less likely needed once the text integrates with the rest of RFC5336bis content. Editors can determine to expand it if necessary. > ---------- > (3) parameter syntax > The consensus agreed that that parameter will not make distinction of which part of message (envelop, header, etc) contains UTF-8 characters, nor will it make distinction whether the message is UTF-8 or below 0x7f. The presence of the parameter itself is the only indication needed to notify MTA to process the message under EAI-mode. > There is only keyword, and no value(s) assigned. The keyword is 'UTF8SMTPbis', same as SMTP EHLO keyword and the parameter of VRFY/EXPN. It is subject to change when the new keyword named. > ---------- > With this and rest of issues closed (EAI Trac issue#1 - issue#7), editors should have the clarity needed for draft revision. > Regards, > Joseph, co-chair EAI > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From ned+ima@mrochek.com Sat Feb 19 18:19: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 8A2073A6CFE for ; Sat, 19 Feb 2011 18:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 XZz9SYhOxB5W for ; Sat, 19 Feb 2011 18:19:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 95FA53A6C77 for ; Sat, 19 Feb 2011 18:19:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NY0QJ655OG00LBOC@mauve.mrochek.com> for ima@ietf.org; Sat, 19 Feb 2011 18:20:34 -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 <01NXPN84OCUO007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 19 Feb 2011 18:20:30 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01NY0QJ4HWEU007FL5@mauve.mrochek.com> Date: Sat, 19 Feb 2011 18:20:01 -0800 (PST) In-reply-to: "Your message dated Fri, 18 Feb 2011 05:50:18 +0000" <061.b8d85652120b4a3876444913cb96953e@tools.ietf.org> References: <061.b8d85652120b4a3876444913cb96953e@tools.ietf.org> To: eai issue tracker DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1298164782; bh=HxHLVQXHVgc6YXsQasyWQa36z5utHrMw37glE/adVUk=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:References:To; b=ZitQiFZY2O+yzuExZ+yq8hg68whKmE5PSWuMzGypaJbRGvNaqkIFtaZ7RRK9GUpip VdNsmrZgJMbHgUFNKgISzciRztZ6KACd/xstxqBXiaHNG/9OHTjYWV5JB5OD8dxIps N+k54Jley+H9A3rPp9+azKjZcxsr1lU8cHr7ZN54= Cc: ima@ietf.org Subject: Re: [EAI] [eai] rfc5335bis #10 (new): POLL: new text to insert as subsection (1.x) under section Introduction X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 20 Feb 2011 02:19:58 -0000 > #10: POLL: new text to insert as subsection (1.x) under section Introduction > POLL: Is the new text good to insert as subsection (1.1) under the > Introduction section, replacing section 1.2 under version 07 and section > 1.1 under version 08 of RFC5335bis I suggest deferring this until we're done with everything else. That will determine what belongs here. Ned > suggested text > -------- > 1.1 Brief Overview of Changes > This document updates email header [RFC5322] and MIME header [RFC2045]. > Email header value extends beyond ASCII, allowing UTF-8 encoding. MIME > header lifts the prohibition against using content-transfer-encoding on > all subtypes under composite-type "message/". > Appendix A documents the derived ABNF rules that inherit support UTF-8, > due to the update of ABNF introduces from this document. > [Editor notes will be removed before Last Call] > [Editor Note 1: This revision (-08 and up) changed the ABNF approach > compared to previous revision (-07 and before). ] > [Editor Note 2: pending -- ABF to support IDN] > [Editor Note 3: Discuss with WG whether some fields, like Trace header, > have issues if UTF-8 encoding allowed in values] > -------- > -- > ----------------------------------+----------------------------------------- > Reporter: jyee@… | Owner: > Type: state | Status: new > Priority: major | Milestone: > Component: rfc5335bis | Version: > Severity: Active WG Document | Keywords: poll > ----------------------------------+----------------------------------------- > Ticket URL: > eai > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Claudio.Allocchio@garr.it Sun Feb 20 10:03: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 282583A6E09 for ; Sun, 20 Feb 2011 10:03:33 -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 l9V1iU8LhE1V for ; Sun, 20 Feb 2011 10:03: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 BAFA03A6D04 for ; Sun, 20 Feb 2011 10:03:31 -0800 (PST) Received: from mac-allocchio3.homenet.telecomitalia.it (host34-144-static.63-82-b.business.telecomitalia.it [82.63.144.34]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p1KI3gMt067533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 19:03:43 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p1KI3gMt067533 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=IEAbViFjxmWzEA4daM2OvVrSXue0SumznDPhY2mqokv//htnnID6U33zQy4gqv9an +irs/czjkCBryyMl32CtJP4E6HCDuac722TH0MdXdqHSlDsXnAupBF3i6D6So6PUKqZ +tTfQ4H5plFq+eK4fPCtpFtC9hWO53XCVqEonzg= Date: Sun, 20 Feb 2011 19:03:42 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.homenet.telecomitalia.it To: ned+ima@mrochek.com In-Reply-To: <01NXYZJYX2GI007FL5@mauve.mrochek.com> Message-ID: References: <40D8C5BF-09CA-48F2-8822-25FF111D37F6@ca.afilias.info> <01NXYZJYX2GI007FL5@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IMA WG Subject: Re: [EAI] POLL: Is the new text in Abstract section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 20 Feb 2011 18:03:33 -0000 On Fri, 18 Feb 2011, ned+ima@mrochek.com wrote: >> POLL: Is the new text in Abstract section in RFC5335bis good to replace the >> original? > > The new text is somewhat improved, but still needs work. In particular, see > the last sentence > > This document specifies an enhancement to Internet mail that > permits native UTF-8 support in the header and body of a message. > > First of all, this says nothing about extending envelope fields - a HUGE > omission. true! > Second, use of the term "body" here is incorrect. This proposal does > not provide a general mechanism to put UTF-8 in bodies. MIME does that. Rather, > what this proposal does is allow use of UTF-8 in headers (both message and > MIME) and envelope address fields. So the sentence needs to be something > like: > > This document specifies an enhancement to Internet mail that > permits native UTF-8 support in envlope address, message header and > MIME header fields. +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 Sun Feb 20 10:06: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 BC1F03A6F42 for ; Sun, 20 Feb 2011 10:06:13 -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 XN-Gq1R2TsEx for ; Sun, 20 Feb 2011 10:06:12 -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 055063A6D04 for ; Sun, 20 Feb 2011 10:06:11 -0800 (PST) Received: from mac-allocchio3.homenet.telecomitalia.it (host34-144-static.63-82-b.business.telecomitalia.it [82.63.144.34]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p1KI6ijo067610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 19:06:46 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p1KI6ijo067610 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=FZ1Nt2hwk5PF0NxOmUghlTo9fSr29bo4c5XwV2JLj4CZNQ0kseC/ZJURHp8gJlkFG z47dQnoPcbMj1F410dgSpJcCS7rJKFhgOR3NV7B3uREYNwiixwYuTUAYFeCnTDWEc40 VKAfiXCdkraJqmxNK3Ol9M/HwElI1pAeTOGoeq0= Date: Sun, 20 Feb 2011 19:06:45 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.homenet.telecomitalia.it To: ned+ima@mrochek.com In-Reply-To: <01NY0QGI9W08007FL5@mauve.mrochek.com> Message-ID: References: <01NY0QGI9W08007FL5@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IMA WG Subject: Re: [EAI] consensus text and parameter of 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, 20 Feb 2011 18:06:13 -0000 On Sat, 19 Feb 2011, ned+ima@mrochek.com wrote: >> All, > >> Below are consensus text and parameter regarding MAIL FROM after discussion on: >> (1) determining the meaning the parameter >> (2) the text to use to explain the usage >> (3) the parameter syntax > > +1 on everything except the actual parameter name - it's ugly. However, since I > have nothing better to propose, I suggest retaining it unless someone else has > an alternate, clearly superior name to suggest. +1 as well. the parameter name is indeed ugly... but it will be seen only by machines, who still do not have a senso ob beauty. Thus I do not care about its name. > > Ned > >> -------- >> (1) the meaning the parameter > >> Through out the discussion, the WG agreed that the parameter intends to tell MTA that the following message needs to run under EAI-mode. > >> --------- >> (2) consensus text > >> If the envelope or message being sent requires the capabilities of these EAI extensions, the client MUST supply the UTF8SMTPbis parameter with the MAIL command. > >> If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command. Because there is no guarantee that a next-hop SMTP server will support the UTF8SMTPbis extension, use of the extension always carries a risk of transmission failure. In fact during the early stages of deployment for the extension, the risk will be quite high. Hence there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting 0x7f and below as UTF-8 is that it permits pure-Unicode environments. This specification does not require that the client inspect the message or otherwise go to extraordinary lengths to assure itself that EAI capabilities are not required for the particular message. > >> -- >> Note: >> - 'SHOULD NOT' was kept, with text explaining the reason behind and the long term desire >> - Interop is important, however making gateway as necessity deployment in order for ASCII mail exchange between 2 different platforms makes adoption more complicate. This also requires more text to explain gateway. Gateway is optional in current standard and will remain the same in EAI. Gateway text is not acceptable in this regard. >> - The detail explaining of EAI extensions is less likely needed once the text integrates with the rest of RFC5336bis content. Editors can determine to expand it if necessary. > >> ---------- >> (3) parameter syntax > >> The consensus agreed that that parameter will not make distinction of which part of message (envelop, header, etc) contains UTF-8 characters, nor will it make distinction whether the message is UTF-8 or below 0x7f. The presence of the parameter itself is the only indication needed to notify MTA to process the message under EAI-mode. > >> There is only keyword, and no value(s) assigned. The keyword is 'UTF8SMTPbis', same as SMTP EHLO keyword and the parameter of VRFY/EXPN. It is subject to change when the new keyword named. > >> ---------- > >> With this and rest of issues closed (EAI Trac issue#1 - issue#7), editors should have the clarity needed for draft revision. > > >> Regards, >> Joseph, co-chair EAI >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ 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 jyee@ca.afilias.info Fri Feb 25 09:57: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 52F833A67F2 for ; Fri, 25 Feb 2011 09:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 lqz44J0qIT8F for ; Fri, 25 Feb 2011 09:57:00 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 87D933A67ED for ; Fri, 25 Feb 2011 09:57:00 -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 1Pt1vM-0004aa-5A for ima@ietf.org; Fri, 25 Feb 2011 17:57: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 1Pt1vM-0006Gf-4n for ima@ietf.org; Fri, 25 Feb 2011 17:57:52 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 12:57:51 -0500 Message-Id: <4AFBBC4D-6DA5-4B5F-AF64-C156BF5861FD@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] Meeting in Prague X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 25 Feb 2011 17:57:01 -0000 Hi all, Below are meeting details of our meeting in Prague which is still = subject to change. Please let the chairs know for any want of the = meeting to discuss drafts or other topics. https://datatracker.ietf.org/meeting/80/agenda.html Few dates reminder: - 2011-02-28 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT=20 - 2011-03-16 (Wednesday): Draft Working Group agendas due by 17:00 PT = (01:00 Thursday, March 17 UTC) - 2011-03-21 (Monday): Revised Working Group agendas due by 17:00 PT = (01:00 Tuesday, March 22 UTC) Regards, Joseph EAI Session 1 (2.5 hours) Tuesday, Morning Session I 0900-1130 Room Name: Barcelona ----------------------------------------------= From klensin@jck.com Mon Feb 28 11:09: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 594E93A6C0C for ; Mon, 28 Feb 2011 11:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=-0.121, 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 B5b9sxeWOscM for ; Mon, 28 Feb 2011 11:09:01 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7E88C3A6A27 for ; Mon, 28 Feb 2011 11:09:01 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pu8Tg-0002jN-CW; Mon, 28 Feb 2011 14:09:52 -0500 Date: Mon, 28 Feb 2011 14:09:51 -0500 From: John C Klensin To: Claudio Allocchio , ned+ima@mrochek.com Message-ID: <0B526A95E133568167727D2A@PST.JCK.COM> In-Reply-To: References: <01NY0QGI9W08007FL5@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 WG Subject: Re: [EAI] consensus text and parameter of 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, 28 Feb 2011 19:09:02 -0000 --On Sunday, February 20, 2011 19:06 +0100 Claudio Allocchio wrote: >... >> +1 on everything except the actual parameter name - it's >> ugly. However, since I have nothing better to propose, I >> suggest retaining it unless someone else has an alternate, >> clearly superior name to suggest. > > +1 as well. > > the parameter name is indeed ugly... but it will be seen only > by machines, who still do not have a senso ob beauty. Thus I > do not care about its name. Folks, please remember that "UTF8SMTPbis" isn't a proposed parameter name and never has been. It is just a placeholder that reflects an explicit WG decision to avoid assigning a final name until after all (other) protocol issues were resolved. The intention of deferring it was to prevent any implementer from getting ahead of the WG and deploying something that would use the same parameter for a slightly different collection of features... a sure guarantee of interoperability problems. john From jyee@ca.afilias.info Mon Feb 28 12:35: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 01C513A6C99 for ; Mon, 28 Feb 2011 12:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[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 VVPH-amBbV6b for ; Mon, 28 Feb 2011 12:35:44 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 2C6ED3A6C98 for ; Mon, 28 Feb 2011 12:35: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 1Pu9pk-0007jd-6K for ima@ietf.org; Mon, 28 Feb 2011 20:36: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 1Pu9pk-00037y-60 for ima@ietf.org; Mon, 28 Feb 2011 20:36:44 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 15:36:44 -0500 Message-Id: To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] POLL RESULT: Is the new text good to insert as subsection (1.1) under the Introduction section, replacing section 1.2 under version 07 and section 1.1 under version 08 of RFC5335bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 28 Feb 2011 20:35:45 -0000 POLL: Is the new text good to insert as subsection (1.1) under the = Introduction section, replacing section 1.2 under version 07 and section = 1.1 under version 08 of RFC5335bis RESULT: With lack of discussion, and suggestions from the WG to defer = this. The consensus is to hold discussion of text at section 1.1. (Poll result also logged at issue tracker = http://trac.tools.ietf.org/wg/eai/trac/ticket/10) Regards Joseph= From jyee@ca.afilias.info Mon Feb 28 12:43: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 AF3BA3A6C58 for ; Mon, 28 Feb 2011 12:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Uatxd1F6v9It for ; Mon, 28 Feb 2011 12:43:24 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id D41A03A6A14 for ; Mon, 28 Feb 2011 12:43:24 -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 1Pu9xC-0006ZD-6W for ima@ietf.org; Mon, 28 Feb 2011 20:44:26 +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 1Pu9xB-0004tS-8s for ima@ietf.org; Mon, 28 Feb 2011 20:44:25 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 15:44:24 -0500 Message-Id: <2BC1F1F4-D940-4D34-9CF5-44B191C953C5@ca.afilias.info> To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] POLL RESULT: Is the new text in Abstract section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 28 Feb 2011 20:43:25 -0000 POLL: Is the new text in Abstract section in RFC5335bis good to replace = the original? (Poll result also logged at issue tracker = http://trac.tools.ietf.org/wg/eai/trac/ticket/8) RESULT: Ned suggested new text and we got several people from the WG = considered it good. The WG will use the following text as follow. Abstract 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=20 specifies an enhancement to Internet mail that permits native UTF-8=20= support in envlope address, message header and MIME header fields. Regards, Joseph= From jyee@ca.afilias.info Mon Feb 28 13:03: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 EDD263A6A25 for ; Mon, 28 Feb 2011 13:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[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 qrZSn11oDJfF for ; Mon, 28 Feb 2011 13:03:20 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 2A8753A6A14 for ; Mon, 28 Feb 2011 13:03:20 -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 1PuAGT-0000BV-4F for ima@ietf.org; Mon, 28 Feb 2011 21:04:21 +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 1PuAGT-0003wR-3s for ima@ietf.org; Mon, 28 Feb 2011 21:04:21 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 16:04:20 -0500 Message-Id: To: IMA WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [EAI] POLL RESULT: Is the new text in Introduction section in RFC5335bis good to replace the original? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 28 Feb 2011 21:03:21 -0000 POLL: Is the new text in Introduction section in RFC5335bis good to = replace the original? (Poll result also logged at issue tracker = http://trac.tools.ietf.org/wg/eai/trac/ticket/9) RESULT: There is lack of discussion, and there is suggestion to keep the = original text and modify as needed. Editors will keep the original text = for introduction section and modify where needed. Suggestions of text = are welcomed. Regards, Joseph=