From Shawn.Steele@microsoft.com Thu Mar 1 14:23:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2321E8389 for ; Thu, 1 Mar 2012 14:23:52 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-FhpL+Cu6Rp for ; Thu, 1 Mar 2012 14:23:51 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF021E836D for ; Thu, 1 Mar 2012 14:23:26 -0800 (PST) Received: from mail97-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Mar 2012 22:23:26 +0000 Received: from mail97-ch1 (localhost [127.0.0.1]) by mail97-ch1-R.bigfish.com (Postfix) with ESMTP id 1189660124 for ; Thu, 1 Mar 2012 22:23:26 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zz9371I1b0bM179dN542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail97-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail97-ch1 (localhost.localdomain [127.0.0.1]) by mail97-ch1 (MessageSwitch) id 1330640604488298_23374; Thu, 1 Mar 2012 22:23:24 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail97-ch1.bigfish.com (Postfix) with ESMTP id 69ADA2A0048 for ; Thu, 1 Mar 2012 22:23:24 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Mar 2012 22:23:23 +0000 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.137]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Thu, 1 Mar 2012 22:22:50 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Draft on IDN Tables in XML Thread-Index: Acz335zs1Yu8XCUKSFa1bpD/NZtV0QAGfwlA Importance: low X-Priority: 5 Date: Thu, 1 Mar 2012 22:22:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [EAI] FW: Draft on IDN Tables in XML X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:23:52 -0000 Hmm, sort of an FYI: if it's interesting for IDN Zone admins to declare th= e rules they use, maybe something similar is interesting for email admins t= o declare how they assign EAI addresses? -Shawn -----Original Message----- From: idna-update-bounces@alvestrand.no [mailto:idna-update-bounces@alvestr= and.no] On Behalf Of Kim Davies Sent: Thursday, March 01, 2012 11:15 AM To: vip@icann.org; idna-update@alvestrand.no Subject: Draft on IDN Tables in XML Colleagues, I have posted a first draft regarding a format that could be used for repre= senting IDN Tables in XML to the I-D Repository: https://datatracker.ietf.org/doc/draft-davies-idntables/ After discussion with a number of folks that felt this would be good work t= o undertake, I've put together a first cut which is not comprehensive, but = I think goes some way toward a potential format. Unless there is interest in this being a more formal activity, my assumptio= n is to aim to publish the final result independently as an Informational R= FC. However, the mechanism of publication is secondary to coming up with so= mething useful that would benefit TLD registries and other implementors. A = list of design goals, from the document, is as follows: * MUST be in a format that can be implemented in a reasonably straightforw= ard manner in software; * The format SHOULD be able to be checked for formatting errors, such that= common mistakes can be caught; * An IDN Table MUST be able to express the set of valid code points that a= re allowed for registration under a specific zone administrator's policies; * MUST be able to express computed alternatives to a given domain name bas= ed on a one-to-one, or one-to-many relationship. These computed alternative= s are commonly known as "IDN variants"; * IDN Variants SHOULD be able to be tagged with specific categories, such = that the categories can be used to support registry policy (such as whether= to list the computed variant in the zone, or to merely block it from regis= tration); * IDN Variants MUST be able to stipulated based on contextual information.= For example, specific variants may only be applicable when they follow ano= ther specific code point, or when the code point is displayed in a specific= presentation form; * The data contained within the table MUST be unambiguous, such that indep= endent implementations that utilise the contents will arrive at the same re= sults; * IDN Tables SHOULD be suitable for comparison and re-use, such that one c= ould easily compare the contents of two or more to see the differences, to = merge them, and so on. * As many existing IDN Tables are practicable SHOULD be able to be migrate= d to the new format with all applicable logic retained. It is explicitly NOT the goal of this format to: * Stipulate what code points should be listed in an IDN Table by a zone ad= ministrator. What registration policies are used for a particular zone is o= utside the scope of this memo. * Stipulate what a consumer of an IDN Table must do when they determine a = particular domain is valid or invalid; or arrive at a set of computed IDN v= ariants. IDN Tables are only used to describe rules for computing code poin= ts, but does not prescribe how registries and other parties utilise them. I'd appreciate any feedback. cheers, kim _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update From klensin@jck.com Fri Mar 2 07:02:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAF021F85A1 for ; Fri, 2 Mar 2012 07:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPqSIRWadxJ8 for ; Fri, 2 Mar 2012 07:02:35 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5F21F8594 for ; Fri, 2 Mar 2012 07:02:35 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S3Tvq-000OdN-9c; Fri, 02 Mar 2012 09:58:06 -0500 Date: Fri, 02 Mar 2012 10:02:28 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <115B4A435668785F5D9B33CC@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] FW: Draft on IDN Tables in XML X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:02:36 -0000 --On Thursday, March 01, 2012 22:22 +0000 Shawn Steele wrote: > Hmm, sort of an FYI: if it's interesting for IDN Zone admins > to declare the rules they use, maybe something similar is > interesting for email admins to declare how they assign EAI > addresses? Maybe, although we have never tried to standardize that in 40 years or so. Some people would undoubtedly consider disclosing their assignment system as an invitation to attacks. And, perhaps worse, the assignment rule in many places has been approximately FCFS with a few restrictions. For example, how would you describe the current assignment model for Hotmail? john From internet-drafts@ietf.org Fri Mar 2 07:22:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8436E21F8636; Fri, 2 Mar 2012 07:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8gxuRIg4EhH; Fri, 2 Mar 2012 07:22:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D4421F8624; Fri, 2 Mar 2012 07:22:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302152204.21599.74106.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 07:22:04 -0800 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-simpledowngrade-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:22:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Wo= rking Group of the IETF. Title : EAI: Simplified POP/IMAP downgrading Author(s) : Arnt Gulbrandsen Filename : draft-ietf-eai-simpledowngrade-00.txt Pages : 5 Date : 2012-03-02 This document specifies a method for IMAP and POP servers to serve EAI messages to non-EAI clients. The specification is simple, easy to implement and provides only rudimentary results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-00.txt From Shawn.Steele@microsoft.com Fri Mar 2 07:51:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3821F8669 for ; Fri, 2 Mar 2012 07:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgiqJt60DPOl for ; Fri, 2 Mar 2012 07:51:28 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8021F866D for ; Fri, 2 Mar 2012 07:51:28 -0800 (PST) Received: from mail32-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Mar 2012 15:51:28 +0000 Received: from mail32-tx2 (localhost [127.0.0.1]) by mail32-tx2-R.bigfish.com (Postfix) with ESMTP id 151403C06E5; Fri, 2 Mar 2012 15:51:28 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371I1b0bM179dN542M98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail32-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail32-tx2 (localhost.localdomain [127.0.0.1]) by mail32-tx2 (MessageSwitch) id 1330703487338465_10519; Fri, 2 Mar 2012 15:51:27 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.241]) by mail32-tx2.bigfish.com (Postfix) with ESMTP id 4E02618004A; Fri, 2 Mar 2012 15:51:27 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Mar 2012 15:51:23 +0000 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.42]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Fri, 2 Mar 2012 15:51:06 +0000 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] FW: Draft on IDN Tables in XML Thread-Index: AQHM+IWo6ZaiZ3UBekqDdMGdmQsyEpZXJwYQ Date: Fri, 2 Mar 2012 15:51:05 +0000 Message-ID: References: <115B4A435668785F5D9B33CC@PST.JCK.COM> In-Reply-To: <115B4A435668785F5D9B33CC@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [EAI] FW: Draft on IDN Tables in XML X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:51:29 -0000 One could say the same about zones :) I'm not for the idea, I just saw a p= ossible correlation. (I actually don't see much need for it for IDN either= , there's already a way to ask if someone else's name's valid: DNS, so this= seems limited to specialized apps). -Shawn -----Original Message----- From: John C Klensin [mailto:klensin@jck.com]=20 Sent: Friday, March 02, 2012 7:02 AM To: Shawn Steele; ima@ietf.org Subject: Re: [EAI] FW: Draft on IDN Tables in XML --On Thursday, March 01, 2012 22:22 +0000 Shawn Steele wrote: > Hmm, sort of an FYI: if it's interesting for IDN Zone admins to=20 > declare the rules they use, maybe something similar is interesting for=20 > email admins to declare how they assign EAI addresses? Maybe, although we have never tried to standardize that in 40 years or so. = Some people would undoubtedly consider disclosing their assignment system = as an invitation to attacks. And, perhaps worse, the assignment rule in ma= ny places has been approximately FCFS with a few restrictions. For example= , how would you describe the current assignment model for Hotmail? john From arnt@gulbrandsen.priv.no Fri Mar 2 07:54:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611EA21F867E for ; Fri, 2 Mar 2012 07:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x41nRS7kWMt for ; Fri, 2 Mar 2012 07:54:18 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C02FC21F867D for ; Fri, 2 Mar 2012 07:54:18 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 7EB3BF8CFE3; Fri, 2 Mar 2012 15:54:14 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330703653-12195-12195/10/25; Fri, 2 Mar 2012 15:54:13 +0000 Message-Id: <4F50ED61.4080706@gulbrandsen.priv.no> Date: Fri, 2 Mar 2012 16:55:13 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=iso-8859-1 Subject: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:54:19 -0000 Hi, I cleaned up the protodraft I posted and Josepth just approved it, so you should see a new WG draft in your next-door mirror very soon. Just what you needed to start the weekend: The shortest, simplest draft you've seen in weeks. There's one open issue: How to explain the relationship between this document and the two other alternatives. One alternative is Fujiwara's draft. His draft is complex and provides a high-fidelity rendering of EAI messages, at the cost of requiring much implementation and testing. Mine is much simpler, requires little testing, and provides only the most important information. Choosing between those is really a matter of preference. The other alternative is no downgrade at all, and this is where I have problems. I believe that no downgrading is harmful for two reasons. One is that without downgrade, nervous admins might not want to enable EAI until they know all clients work, and IMP and POP don't make gathering that information simple. The other, and more important, reason is that once an IMAP server has revealed the existence of a message, it cannot really deny the user access to that message. So either it has to downgrade by creating a monster (e.g. just-send-utf8 addresses, which hopefully will not cause the MUA to misdirect an reply) or go to some effort to never reveal the EAI messages, or deal with the possible infinite loops if it suppresses the content of revealed messages. All of those three need code in servers. IMO it's quite likely that a cheap downgrade can be simpler to implement than those three, and that cheap downgrade is what my document aims for. The best that can be done at near-zero implementation cost. Somehow I can't wrangle the previous two paragraphs into RFC shape. I tried, but the result was either much too short or a wretched digression, or even both. Arnt From klensin@jck.com Fri Mar 2 08:28:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5821F8758 for ; Fri, 2 Mar 2012 08:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOUoLxS7Ohbb for ; Fri, 2 Mar 2012 08:28:40 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C321F8757 for ; Fri, 2 Mar 2012 08:28:40 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S3VH9-000Oji-UX; Fri, 02 Mar 2012 11:24:11 -0500 Date: Fri, 02 Mar 2012 11:28:34 -0500 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: <802A088257D49FF5454B5B2C@PST.JCK.COM> In-Reply-To: <4F50ED61.4080706@gulbrandsen.priv.no> References: <4F50ED61.4080706@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:28:41 -0000 --On Friday, March 02, 2012 16:55 +0100 Arnt Gulbrandsen wrote: > Hi, > > I cleaned up the protodraft I posted and Josepth just approved > it, so you should see a new WG draft in your next-door mirror > very soon. Just what you needed to start the weekend: The > shortest, simplest draft you've seen in weeks. > > There's one open issue: How to explain the relationship > between this document and the two other alternatives. Note that some discussion of this went into the most recent version of draft-ietf-eai-popimap-downgrade. I'm guilty of supplying most of that text (if you don't like it, definitely blame me and not Kazunori), but the decision about what to do about it, and whether more or less should be said, belongs to the WG. > One alternative is Fujiwara's draft. His draft is complex and > provides a high-fidelity rendering of EAI messages, at the > cost of requiring much implementation and testing. Mine is > much simpler, requires little testing, and provides only the > most important information. Choosing between those is really a > matter of preference. > The other alternative is no downgrade at all, and this is > where I have problems. > > I believe that no downgrading is harmful for two reasons. One > is that without downgrade, nervous admins might not want to > enable EAI until they know all clients work, and IMP and POP > don't make gathering that information simple. The other, and > more important, reason is that once an IMAP server has > revealed the existence of a message, it cannot really deny the > user access to that message. So either it has to downgrade by > creating a monster (e.g. just-send-utf8 addresses, which > hopefully will not cause the MUA to misdirect an reply) or go > to some effort to never reveal the EAI messages, or deal with > the possible infinite loops if it suppresses the content of > revealed messages. Different perspective --speaking strictly as an individual participant: There are going to be situations in which it is possible to convert/upgrade all POP, IMAP (and other) clients before turning on SMTPUTF8 in the delivery server. The most obvious case is one in which a central IT department controls all of the desktop and other client machines and can force-push changes onto them, but there are others. There is no issue of the POP or IMAP server having to discover penetration of upgrades because that is handled in another way. For that case, a "no downgrades and we are not going to spend time worrying about it" strategy is no more risky that hundreds of other types of operational failures. Presumably, if a user's IMAP or POP client fails to advertise the needed capabilities, either that machine gets immediately and forcefully upgraded or the user is instructed to report for a spanking. From our point of view, those are administrative issues, not technical ones -- no IMAP/POP server code required. The other "no downgrade" cases are, as you note, harder, but I continue to think that it ought to be plausible to generate something that looks a lot like a DSN whose content is "there is this message that you can't get until you either upgrade your client, access it through an upgraded client, or figure out another way to get at it". One of many options would be for the notification message to contain a URI that points to the UTF-8 form of the message as a text file or equivalent (hmm... an application for message/external-body? :-) ). That is very different from "deny the user access to the message", especially in the very common case environments in which one might imagine, e.g., web access capability to complement the POP or IMAP capability. I suppose we might explicitly advise anyone going down that path to be sure that there is some alternate mechanism for letting the user of legacy clients to get to those messages. What I don't know is whether the WG needs (or wants) to try exploring and writing up that "DSN and warnings about support structure" option or whether we would be ok just mentioning the possibility (which the text in draft-ietf-eai-popimap-downgrade sort of does although improvements are probably needed). > All of those three need code in servers. IMO it's quite likely > that a cheap downgrade can be simpler to implement than those > three, and that cheap downgrade is what my document aims for. > The best that can be done at near-zero implementation cost. Whether that is true relative to some "tell the user she doesn't get the message until..." strategy depends on what variant of that strategy is decided upon and how whatever structure is needed to support the strategy is counted. Certainly just generating a pseudo-DSN wouldn't take much code. Fortunately, I think our job is to identify the alternatives; we don't need to answer that question. > Somehow I can't wrangle the previous two paragraphs into RFC > shape. I tried, but the result was either much too short or a > wretched digression, or even both. See if any of the above helps. I'm trying really hard to resist the feeling that we are going to need some sort of separate "downgrading tradeoffs and issues" document so that we could leave the other specifications to deal with the relevant protocol issues alone but, as long as we can get it written and reviewed, it would not be the worst possible outcome. Having all of the information, but having it split in fairly arbitrary ways across two or three different protocol specs might well be worse. best, john From arnt@gulbrandsen.priv.no Fri Mar 2 08:32:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9040F21F8666 for ; Fri, 2 Mar 2012 08:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM7TU4LgKPuB for ; Fri, 2 Mar 2012 08:32:15 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 01BB621F864A for ; Fri, 2 Mar 2012 08:32:15 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 80E67F8CF65; Fri, 2 Mar 2012 16:32:13 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330705932-12195-12195/10/28; Fri, 2 Mar 2012 16:32:12 +0000 Message-Id: <4F50F648.8060102@gulbrandsen.priv.no> Date: Fri, 2 Mar 2012 17:33:12 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <4F50ED61.4080706@gulbrandsen.priv.no> <802A088257D49FF5454B5B2C@PST.JCK.COM> In-Reply-To: <802A088257D49FF5454B5B2C@PST.JCK.COM> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:32:15 -0000 On 03/02/2012 05:28 PM, John C Klensin wrote: > 'm trying really hard to resist > the feeling that we are going to need some sort of separate > "downgrading tradeoffs and issues" document RFC 1925, 6a From klensin@jck.com Fri Mar 2 08:47:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA67F21F86B2 for ; Fri, 2 Mar 2012 08:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfqpQ6dZ9azn for ; Fri, 2 Mar 2012 08:47:20 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EC19821F86AF for ; Fri, 2 Mar 2012 08:47:19 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S3VZD-000OlA-Re for ima@ietf.org; Fri, 02 Mar 2012 11:42:51 -0500 Date: Fri, 02 Mar 2012 11:47:14 -0500 From: John C Klensin To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Status of the EAI effort X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:47:20 -0000 EAI participants, As has already been mentioned on the list, the four "core" documents are done and published as RFC 6530 - RFC 6533. Unless we can now make significant progress in moving other work forward, we should conclude the the WG has run out of steam and either suspend it until there is more experience or kill it and recharter when appropriate (in practice, those two options aren't different enough to worry about). My personal preference would be to get the two clusters of documents outlined below done before we suspend/ shut down, but I can't either do the work or supply the energy if the WG isn't able to show that it is willing and able to put in the effort. I believe that the current agenda for specifications is: (1) Mailing lists. There has been substantially zero discussion of draft-ietf-eai-mailinglistbis-01 since it was posted and not much more discussion of its predecessor. We need to get reviews of this document and discussion of whether the WG is ready to work on it and move it forward or whether we want to try to devise an explanation for the IESG as to why it isn't necessary at this point. I think we are obligated to do one or the other. As to the latter option, I think the only viable position is that people should not try to use mailing lists with non-ASCII addresses (the address to which mail for the list is sent) or distribution addresses (the backward-pointing address for traffic distributed from the list), and that people should not send to such lists from non-ASCII addresses, at least until SMTPUTF8 is much more broadly supported and the issue can be reviewed. That would be a specific special case of one of the cases covered by draft-ietf-eai-mailinglistbis. I would predict it would make no one happy, but it would at least be very easy to do. How does the WG want to proceed and, in particular, who intends to review and work on that document? (2) POP and IMAP. The key issue here is downgrading. We believe that the base POP and IMAP documents are ready to go modulo some tuning after we make the downgrading decisions. Anyone who disagrees with that belief should speak up very quickly. My impression from the mailing list discussions is that we have general agreement that, when a message in a mail store requires SMTPUTF8 capability and an IMAP or POP client is only ASCII-capable, different strategies may be appropriate in different circumstances. If people disagree with that conclusion and want a formal consensus call, please speak up soon. A new version of draft-ietf-eai-popimap-downgrade was posted on Monday that reflects that view of different strategies for different purposes. A number of other sections have been clarified and some explicit questions asked. We need to see reviews and comments on that draft --the general strategy and the specific comments-- in order to move forward. A lot of work went into making this version more readable and accessible; please reinforce that effort by reading it now and helping to find both substantive issues that need discussion and areas of text that need further editorial or clarification work. Similarly, Arnt has posted a first draft of what the "minimal downgrading" approach as draft-ietf-eai-simpledowngrade-00. People who are more sympathetic to that strategy should review it and _at least_ the revised introduction to draft-ietf-eai-popimap-downgrade and get comments onto the list. We also need to decide whether the variants on "no downgrade" need to be written up and, if so, in what form and who is going to do the work. Suggestions welcome, especially if they contain words like "I volunteer". If there are none, Joseph and I will try to figure out a way to avoid doing that work. Finally, a comment/inquiry about an EAI meeting at IETF 83 in Paris. IETF meeting time is limited and valuable and, at least IMO, we have often not used it very well. Those who think that a meeting in Paris would be useful should explain why on the list and should include references to particular discussions of particular documents that have occurred on the list and that would benefit from face to face discussion to move forward. To be explicit about that, if there are no discussions on the list about any of the topics identified above, there will be no meeting in Paris. There will be a meeting iff there are such discussion, they cannot be resolved on-list, and someone can make a persuasive case that f2f time would help. If not, and after some discussion with Joseph and Pete, we'd rather keep things on the mailing list and, if necessary, schedule one or more topic-specific interims with WebEx or Jabber chat, rather than taking up time in Paris. thanks to all, john From arnt@gulbrandsen.priv.no Fri Mar 2 08:50:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18E221F865C for ; Fri, 2 Mar 2012 08:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWWSckv1ZtMM for ; Fri, 2 Mar 2012 08:50:27 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8721F861A for ; Fri, 2 Mar 2012 08:50:24 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id C27FBF8CF69; Fri, 2 Mar 2012 16:50:22 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330707021-12195-12195/10/29; Fri, 2 Mar 2012 16:50:21 +0000 Message-Id: <4F50FA89.50405@gulbrandsen.priv.no> Date: Fri, 2 Mar 2012 17:51:21 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <4F50ED61.4080706@gulbrandsen.priv.no> In-Reply-To: <4F50ED61.4080706@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:50:28 -0000 There has been a little offlist discussion of what "no downgrade" might mean in concrete terms. Here's one way which should work fairly well in real life, except that the ALERT response code is frequently rerouted to /dev/null by today's clients. Personally I don't like this very much. It holds people's mail hostage. Arnt 2. IMAP When an IMAP server is required to send an EAI-specific response, it sends nil in the relevant part of the response. For example C: a UID FETCH 42 ENVELOPE S: * 1 FETCH (UID 42 ENVELOPE NIL) The IMAP server MUST send the ALERT response code along with the command's tagged response. Continuing the previous example: S: a OK [ALERT] One or more messages requires internationalisation and cannot be displayed IMAP clients commonly request partial information about a message, so a client may well ask for only ASCII information in an EAI message. The server MAY send null responses even if this is the case for a particular command. An IMAP server MUST NOT set the \deleted flag or expunge an EAI message when instructed to by a non-EAI client. 3. POP When a POP server is required to send an EAI-specific response, it sends an empty message. A POP server MUST NOT mark such a message as deleted, no matter what the client does. From chris.newman@oracle.com Fri Mar 2 14:27:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB821E804A for ; Fri, 2 Mar 2012 14:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.741 X-Spam-Level: X-Spam-Status: No, score=-105.741 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bE0NRrJhTY3 for ; Fri, 2 Mar 2012 14:27:57 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81621E802D for ; Fri, 2 Mar 2012 14:27:57 -0800 (PST) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id q22MRVXC017530; Fri, 2 Mar 2012 22:27:43 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id q22MRUT4009156; Fri, 2 Mar 2012 22:27:30 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.03 64bit (built Oct 25 2011)) with ESMTPA id <0M0A00K5B3PP9Y00@gotmail.us.oracle.com>; Fri, 02 Mar 2012 14:27:30 -0800 (PST) Date: Fri, 02 Mar 2012 14:27:25 -0800 From: Chris Newman To: Arnt Gulbrandsen , ima@ietf.org Message-id: <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> In-reply-to: <4F50ED61.4080706@gulbrandsen.priv.no> References: <4F50ED61.4080706@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 22:27:58 -0000 I have reviewed this document and I like this general approach, particularly the use of the .invalid TLD. I believe having a standards-compliant simple downgrade option like this will increase the odds that SMTPUTF8 will deploy successfully. Some specific comments on this draft: Section 2.1: Irregular email addresses (anything to which one cannot send mail, such as "unknown:;") are silently excised. I suggest changing "are" to "MAY be". It's better usability to leave such things in the address list so they should only be excised if it makes the implementation simpler. The affected header fields are Bcc, Cc, From, ReplyTo, ResentBcc, ResentCc, ResentFrom, ResentSender, ResentTo, ReturnPath, Sender and To. Any addresses present in other header fields are not regarded as addresses by this specification. The "-" delimiters disappeared from this list, please fix (e.g. ReplyTo should be Reply-To, ReturnPath should be Return-Path, ResentTo should be Resent-To, etc). I was going to suggest adding Disposition-Notification-To to the list, then I realized it's actually better to omit it from the list. Section 2.2: Any mime field (whether in the message header or a bodypart header) which cannot be presented as-is to the client is silently excised along with its name. This isn't clear to me, perhaps because it's not using precise language (did you mean MIME parameter?, your example suggests that's the case). It also doesn't mention comments although they are mentioned in the section title. Here's one alternative I'd suggest: If the Content-Type [RFC2045] or Content-Disposition [RFC2183] MIME header fields contain [RFC6532], the following two steps are performed on the relevant header field(s): 1. Any RFC 5322 comment containing such characters is excised. 2. Any MIME parameter attribute/value pair containing such characters is excised along with the ";" delimiter. Here's another alternative: If either the Content-Type [RFC2045] or Content-Disposition [RFC2183] header field contains [RFC6532] then any field content following a ";" delimiter is excised. That's a lot easier to implement, but I worry a bit about the impact of dropping charset and boundary parameters so I lean slightly towards the more complex algorithm over this one. Before Section 2.3: The Received header can't be excised without losing critical diagnostic information. The simplest algorithm I can suggest is to replace any sequence of characters in a Received header that contains one or more characters and ASCII alpha-numeric characters with the string "invalid". Next best I can come up with is to excise any received-token (as defined in RFC 5322) containing non-ASCII. The former is easier to implement, the latter easier to specify. Either is fine with me. Section 2.3: There needs to be a prohibition from excising Received header fields here. Unfortunately, humans tend to encode a lot of useful information in the subject header (sometimes it's the only useful information in the entire message). So I think this needs to be called out as an important quality-of-implementation choice. I suggest adding this sentence: If the Subject header field contains , it MAY be encoded using Message Header Extensions for Non-ASCII Text [RFC2047] instead of being excised. Section 3: This will require an "updates RFC 3501" in the RFC boilerplate. I like this approach. Section 5 is missing. - Chris --On March 2, 2012 16:55:13 +0100 Arnt Gulbrandsen wrote: > Hi, > > I cleaned up the protodraft I posted and Josepth just approved it, so > you should see a new WG draft in your next-door mirror very soon. Just > what you needed to start the weekend: The shortest, simplest draft > you've seen in weeks. > > There's one open issue: How to explain the relationship between this > document and the two other alternatives. > > One alternative is Fujiwara's draft. His draft is complex and provides a > high-fidelity rendering of EAI messages, at the cost of requiring much > implementation and testing. Mine is much simpler, requires little > testing, and provides only the most important information. Choosing > between those is really a matter of preference. > > The other alternative is no downgrade at all, and this is where I have > problems. > > I believe that no downgrading is harmful for two reasons. One is that > without downgrade, nervous admins might not want to enable EAI until > they know all clients work, and IMP and POP don't make gathering that > information simple. The other, and more important, reason is that once > an IMAP server has revealed the existence of a message, it cannot really > deny the user access to that message. So either it has to downgrade by > creating a monster (e.g. just-send-utf8 addresses, which hopefully will > not cause the MUA to misdirect an reply) or go to some effort to never > reveal the EAI messages, or deal with the possible infinite loops if it > suppresses the content of revealed messages. > > All of those three need code in servers. IMO it's quite likely that a > cheap downgrade can be simpler to implement than those three, and that > cheap downgrade is what my document aims for. The best that can be done > at near-zero implementation cost. > > Somehow I can't wrangle the previous two paragraphs into RFC shape. I > tried, but the result was either much too short or a wretched > digression, or even both. > > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From arnt@gulbrandsen.priv.no Sun Mar 4 07:52:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105EB21F8631 for ; Sun, 4 Mar 2012 07:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nGofpG+7U24 for ; Sun, 4 Mar 2012 07:52:55 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 068E421F862F for ; Sun, 4 Mar 2012 07:52:55 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 54506F8D0E6; Sun, 4 Mar 2012 15:52:52 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330876371-9866-9866/10/5; Sun, 4 Mar 2012 15:52:51 +0000 Message-Id: <4F539012.90404@gulbrandsen.priv.no> Date: Sun, 4 Mar 2012 16:53:54 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: Chris Newman References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> In-Reply-To: <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 15:52:56 -0000 Hi, On 03/02/2012 11:27 PM, Chris Newman wrote: > I have reviewed this document and I like this general approach, > particularly the use of the .invalid TLD. I believe having a > standards-compliant simple downgrade option like this will increase the > odds that SMTPUTF8 will deploy successfully. >=20 > Some specific comments on this draft: >=20 > Section 2.1: >=20 > Irregular email addresses (anything to which one cannot send mail, > such as "unknown:;") are silently excised. >=20 > I suggest changing "are" to "MAY be". I deleted the parapgraph. The rule didn't really carry its load. > The affected header fields are Bcc, Cc, From, ReplyTo, ResentBcc, > ResentCc, ResentFrom, ResentSender, ResentTo, ReturnPath, Sender and > To. Any addresses present in other header fields are not regarded as > addresses by this specification. >=20 > The "-" delimiters disappeared from this list, Oh, search and destroy. Fixed. > Section 2.2: >=20 > Any mime field (whether in the message header or a bodypart header) > which cannot be presented as-is to the client is silently excised > along with its name. >=20 > This isn't clear to me, perhaps because it's not using precise language > (did you mean MIME parameter?, your example suggests that's the case). Mind thinks x, fingers type y ;) > It also doesn't mention comments although they are mentioned in the > section title. I wrote the heading and body text, then while searching for a credible example I decided that comments don't matter enough to warrant special treatment. So I deleted the body text =97 and forgot the heading. Do you have a credible example, perhaps? > 1. Any RFC 5322 comment containing such characters is excised. > 2. Any MIME parameter attribute/value pair containing such characters = is > excised along with the ";" delimiter. >=20 > Here's another alternative: >=20 > If either the Content-Type [RFC2045] or Content-Disposition [RFC2183] > header field contains [RFC6532] then any field content > following a ";" delimiter is excised. >=20 > That's a lot easier to implement, but I worry a bit about the impact of > dropping charset and boundary parameters so I lean slightly towards the > more complex algorithm over this one. Boundary is IMO vitally necessary, and reason enough to require the per-parameter rule. I don't like it, but there it is. > Before Section 2.3: >=20 > The Received header can't be excised without losing critical diagnostic > information. The simplest algorithm I can suggest is to replace any > sequence of characters in a Received header that contains one or more > characters and ASCII alpha-numeric characters with the > string "invalid". Next best I can come up with is to excise any > received-token (as defined in RFC 5322) containing non-ASCII. The = former > is easier to implement, the latter easier to specify. Either is fine > with me. >=20 > Section 2.3: >=20 > There needs to be a prohibition from excising Received header fields = here. Really? Consider: This is about EAI messages. So we're talking about the need to read Received when either a) EAI mail is sent to someone who can't read it at all or b) it's sent to someone who can read it, but is at the moment using an EAI-ignorant MUA. I feel that in case b), reading Received using a different MUA is sufficient. It tends to be done for debugging, and debugging is best done using the original message, not a degraded version. I do not particularly want to cater to doing debugging badly. So the argument is about a). Is that something to care about enough to add a rule? > Unfortunately, humans tend to encode a lot of useful information in the > subject header (sometimes it's the only useful information in the = entire > message). So I think this needs to be called out as an important > quality-of-implementation choice. I suggest adding this sentence: >=20 > If the Subject header field contains , it MAY be = encoded > using Message Header Extensions for Non-ASCII Text [RFC2047] instead of > being excised. You're the second person to point that out, and it's not any more deniable this time than the first time. I added that as simple 'is encoded', no MAY about it. Arnt From internet-drafts@ietf.org Sun Mar 4 08:01:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5B21F8639; Sun, 4 Mar 2012 08:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHzGX3O9xKhU; Sun, 4 Mar 2012 08:01:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D521F851E; Sun, 4 Mar 2012 08:01:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304160125.16094.35141.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2012 08:01:25 -0800 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-simpledowngrade-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 16:01:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Wo= rking Group of the IETF. Title : EAI: Simplified POP/IMAP downgrading Author(s) : Arnt Gulbrandsen Filename : draft-ietf-eai-simpledowngrade-01.txt Pages : 5 Date : 2012-03-04 This document specifies a method for IMAP and POP servers to serve EAI messages to non-EAI clients. The specification is simple, easy to implement and provides only rudimentary results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-01.txt From arnt@gulbrandsen.priv.no Sun Mar 4 08:01:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F4121F8658 for ; Sun, 4 Mar 2012 08:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn6ls8XNE1+n for ; Sun, 4 Mar 2012 08:01:55 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6821F8655 for ; Sun, 4 Mar 2012 08:01:54 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 63711F8D0E7; Sun, 4 Mar 2012 16:01:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330876912-9866-9866/10/6; Sun, 4 Mar 2012 16:01:52 +0000 Message-Id: <4F539230.3080808@gulbrandsen.priv.no> Date: Sun, 4 Mar 2012 17:02:56 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> In-Reply-To: <4F539012.90404@gulbrandsen.priv.no> Content-Type: text/plain; charset=windows-1252 Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 16:01:55 -0000 I made a -01 after addressing blah. Should be out now. Arnt From klensin@jck.com Sun Mar 4 09:57:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912AB21F86B1 for ; Sun, 4 Mar 2012 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwqDphNTurnI for ; Sun, 4 Mar 2012 09:57:55 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C221F86B0 for ; Sun, 4 Mar 2012 09:57:55 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S4FcV-00028n-NP; Sun, 04 Mar 2012 12:53:19 -0500 Date: Sun, 04 Mar 2012 12:57:45 -0500 From: John C Klensin To: Arnt Gulbrandsen , Chris Newman Message-ID: In-Reply-To: <4F539012.90404@gulbrandsen.priv.no> References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> 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] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 17:57:56 -0000 --On Sunday, March 04, 2012 16:53 +0100 Arnt Gulbrandsen wrote: >... >> There needs to be a prohibition from excising Received header >> fields here. > > Really? > > Consider: This is about EAI messages. So we're talking about > the need to read Received when either a) EAI mail is sent to > someone who can't read it at all or b) it's sent to someone > who can read it, but is at the moment using an EAI-ignorant > MUA. > > I feel that in case b), reading Received using a different MUA > is sufficient. It tends to be done for debugging, and > debugging is best done using the original message, not a > degraded version. I do not particularly want to cater to doing > debugging badly. > > So the argument is about a). Is that something to care about > enough to add a rule? As one of the longer-term advocates of preservation and accessibility of Received fields, I think I nonetheless have to agree with Arnt on this. The very idea of lightweight or partial downgrading implies that there has to be another MUA or other mechanism out there somewhere. Moreover, having messages in the mail store that require SMTPUPTF8 capability without having at least a way to inspect them for debugging purposes would border on "really stupid". So it seems to me to be plausible to push off complex Received headers to those mechanisms. I would like to see something that says "some Received header fields discarded because...", but that is a different matter. Also, from my point of view, the WG pretty much accepted the possibility of rrace fields being discarded the moment it decided that domain names in those fields should be represented with U-labels rather than A-labels when that choice occurred. john From arnt@gulbrandsen.priv.no Sun Mar 4 13:01:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF821F8562 for ; Sun, 4 Mar 2012 13:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gT7w2YLZnXC for ; Sun, 4 Mar 2012 13:01:05 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 026B921F853D for ; Sun, 4 Mar 2012 13:01:05 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0BCB0F8D075; Sun, 4 Mar 2012 21:01:03 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330894862-9866-9866/10/7; Sun, 4 Mar 2012 21:01:02 +0000 Message-Id: <4F53D84E.6070709@gulbrandsen.priv.no> Date: Sun, 4 Mar 2012 22:02:06 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:01:05 -0000 On 03/04/2012 06:57 PM, John C Klensin wrote: > I would like to see something that says "some > Received header fields discarded because...", but that is a > different matter. I thought about it, but I don't see a simple IMAPish way, and doing it only for POP isn't worth the bother IMO. Take a hypothetical header field X-Pseudo-Field-Listing-Downgrades. IMAP says that message content, once cached, never changes. Since it's common for for IMAP clients to ask for partial information about messages, IMAP servers to try to handle that efficiently, and an IMAP server may or may not have a complete picture of what downgrades should be performed for a particular message, or even which ones it has performed. Generating that pseudo thing might not be very simple, and making the client show the latest version... no idea. Personally I think clients should upgrade to support EAI and only EAI, so any solution involving client changes is out of scope. Arnt From McQuilWP@pobox.com Sun Mar 4 18:56:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A7D21F86C2 for ; Sun, 4 Mar 2012 18:56:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwPu73w6yrMP for ; Sun, 4 Mar 2012 18:56:51 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56EB521F86C1 for ; Sun, 4 Mar 2012 18:56:51 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id C081F651E; Sun, 4 Mar 2012 21:56:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=2DUztx9601U7 dMHoO5vnDG1gz1E=; b=u/6swkkm8XIDeJ0UZfzlcFd+UrpErLvadsRX9hGop6B0 kBCDL2ZZSOfd2WDMnsjnfyIvGi7dnN6HZhLWdDUmZyDXUYUlhdLuUCjGTmF637iI AqBpz3WuX8vE/FS5lLhxQ8Ic/MiGikJFYHQBz7T6bNOx1m2t0JKwV33UBthK8lA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=Tl7yYx 5QYnlsaOuDKvgQAujU4h68+8qexLFKhgmEK3rl16rXjttCyCMV3dIQvDnEMB3hKK jf2XYl1JdN+xzrX7toKurOaVGqKPjPDuEeDZhkkAUfPWN3TNVGEqFZ1idIcqH/pV F/3txU3fEirF6vmqetOrOA44Vze6zCwTYdOwQ= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id B78C0651D; Sun, 4 Mar 2012 21:56:49 -0500 (EST) Received: from [192.168.0.3] (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 27D8C651C; Sun, 4 Mar 2012 21:56:49 -0500 (EST) Date: Sun, 4 Mar 2012 18:56:47 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1183273491.20120304185647@pobox.com> To: IMA Discussion In-Reply-To: <4F53D84E.6070709@gulbrandsen.priv.no> References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F53D84E.6070709@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: DA6A8154-666E-11E1-8B9C-9DB42E706CDE-02871704!b-pb-sasl-quonix.pobox.com Cc: Arnt Gulbrandsen Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 02:56:52 -0000 On Sun, 2012-03-04, Arnt Gulbrandsen wrote: > On 03/04/2012 06:57 PM, John C Klensin wrote: >> I would like to see something that says "some >> Received header fields discarded because...", but that is a >> different matter. > I thought about it, but I don't see a simple IMAPish way, and doing it > only for POP isn't worth the bother IMO. How about the IMAP (or POP) server substituting a single ASCII character (e.g."?") for each octet outside of the range 0-127? This would maintain byte counts and could be done on the fly during the download process. The stored message would not change, merely this client's current view of it. This allows header fields that are for human consumption (most of them IMO, including Received:) to be interpreted by eyes and brains. I often scan through the Received fields to see the hops and notice if there are loops. A partially munged hostname is quite easy to manage in this sort of human conducted scan. The issues I see are the possibility of changing an email address local part to a different, valid local part, and the possibility of messing up an existing encoded word. The email address local part could be noticed and converted to *all* "?" chars to make it a clearly unusable address. Merely my $0.02. -- Bill McQuillan From yaojk@cnnic.cn Sun Mar 4 19:39:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54F421F865F for ; Sun, 4 Mar 2012 19:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.29 X-Spam-Level: X-Spam-Status: No, score=-100.29 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLHiBK8-eIQL for ; Sun, 4 Mar 2012 19:39:07 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 515A621F8655 for ; Sun, 4 Mar 2012 19:38:59 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 05 Mar 2012 11:38:52 +0800 Message-ID: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> From: "Jiankang YAO" To: Date: Mon, 5 Mar 2012 11:38:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 03:39:08 -0000 RGVhciBhbGwsDQoNCiAgIFRoaXMgZHJhZnQgd2FzIHRyaWdnZXJlZCBieSAgZW1haWwgc29mdHdh cmUgcHJvdmlkZXJzIHdoZW4gd2UgZGlzY3Vzc2VkIHRoZSBlYWkgaW1wbGVtZW50YXRpb24gd2l0 aCB0aGVtLg0KICAgQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQoNCkppYW5rYW5nIFlhbw0K DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPg0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1h cmNoIDA1LCAyMDEyIDEwOjU3IEFNDQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC15YW8tZWFp LWRucy0wMC50eHQNCg0KDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IA0KPiBUaXRs ZSAgICAgICAgICAgOiBTTVRQVVRGOCBDYXBhYmlsaXR5IEluZGljYXRvcg0KPiBBdXRob3Iocykg ICAgICAgOiBKaWFua2FuZyBZYW8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFNodW8gU2hl bg0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC15YW8tZWFpLWRucy0wMC50eHQNCj4gUGFnZXMg ICAgICAgICAgIDogNg0KPiBEYXRlICAgICAgICAgICAgOiAyMDEyLTAzLTA0DQo+IA0KPiAgIEtl eSBSRkNzIGZvciBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRyZXNzZXMgc3BlY2lmeSB0aGUg YmFzaWMNCj4gICBwcm90b2NvbHMgZm9yIHVzaW5nIHRoZW0uICBUaGUgU01UUCBjbGllbnQgY2Fu IG9ubHkga25vdyB0aGUgU01UUA0KPiAgIHNlcnZlcidzIGFiaWxpdHkgYnkgRUhMTyBjb21tYW5k LiAgSW4gb3JkZXIgdG8gaGVscCB0aGUNCj4gICBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRy ZXNzIGRlbGl2ZXJ5LCB0aGlzIGRvY3VtZW50IHN1Z2dlc3RzIHRvDQo+ICAgYWRkIHRoZSBuZXcg RE5TIFJSIHR5cGUgZm9yIGludGVybmF0aW9uYWxpemVkIGVtYWlsIHByb3RvY29scy4NCj4gICBU aHJvdWdoIHRoaXMgUlIgdHlwZSwgdGhlIFNNVFAgY2xpZW50IGNhbiBrbm93IHdoZXRoZXIgdGhl DQo+ICAgZGVzdGluYXRpb24gU01UUCBzZXJ2ZXIgY2FuIHN1cHBvcnQgdGhlIFNNVFBVVEY4IGFi aWxpdHkgYmVmb3JlDQo+ICAgc2VuZGluZyB0aGUgRUhMTyBjb21tYW5kIHRvIHRoZSBzZXJ2ZXIu DQo+IA0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlhby1lYWktZG5zLTAwLnR4dA0KPiAN Cj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gVGhpcyBJbnRl cm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXlhby1lYWktZG5zLTAwLnR4dA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxp bmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3Jp ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYu b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ= From ned+ima@mrochek.com Sun Mar 4 21:30:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9480421F85FC for ; Sun, 4 Mar 2012 21:30:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFchJ7O7-D5h for ; Sun, 4 Mar 2012 21:29:59 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BE50721F85EE for ; Sun, 4 Mar 2012 21:29:59 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCQDKWWIJK007G2D@mauve.mrochek.com> for ima@ietf.org; Sun, 4 Mar 2012 21:29:58 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 4 Mar 2012 21:29:55 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> Date: Sun, 04 Mar 2012 20:20:44 -0800 (PST) In-reply-to: "Your message dated Mon, 05 Mar 2012 11:38:51 +0800" <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> To: Jiankang YAO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1330925404; bh=OyLegix3PX9J22Bq83bVNXGqpkCwB8qE2YIaaaXLgzA=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=eq965/dDD2aIzcNKiXExUaIezSAW+o3ADmWgWXmlLHxqrSK2prI0EPiXP4Nj7WK3b TytEqfonLzNgZyasnBatQMPXBMLTEQ04O8IkUxRQF/xBKzr1ekv28n8zd3fCG0LFvU SnnHej5Ko8uoJnxhKQB4BPLzzIjJPMh3tmpDdOx4= Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 05:30:00 -0000 > Dear all, > This draft was triggered by email software providers when we discussed the eai implementation with them. > Any comments are welcome. First, I have to say that given the present state of play of the DNS, I am extremely skeptical that a new RRTYPE can actually deploy soon enough to be useful. And that's assuming you are able to get it through the process quickly, which is also unlikely. Sadly, the DNS folks are in total denial as to the issues and AFAICT see no value in working on mechanisms that would improve the situation. And even if this were to change, you're at best talking about improving the situation for RRTYPEs developed years from now. Second, the text you have is very confusing; at one point you say the record returns a list of domains, at another point you imply they are actually host names. Wordsmithing definitely needed. Third, if I understand the proposal (and I may not), I also have to say that the semantics are more than a little ugly. You look up a domain and either get back "all", which is fine, "no", also fine, or a list of EAI-suppporting hosts - ick. You are then supposed to intersect that list with the list you get back from from your MX query, correct? That's going to be a fair bit of work and I suspect a lot of implementations won't bother. It would be much better to use SRV for this, making it an alternative to MX for the EAI case. And it avoids having to compute the intersection; you just specify the EAI-capable hosts, done. The "all" and "no" case are served by not having an entry; then you try the MX and either succeed or fail. And SRV has the huge advantage of being deployed. And if you stick with the intersection approach, I don't think a list of domain names packed into a single string is the way to do it. Multiple records containing name fields fields are a better bet because they support compression, and compression can make a big difference when there's lots of repetition in the names, as seems likely. (I note in passing that you get this for free with SRV.) This is also one case where TXT records really do not make sense as an alternative, again because of compression issues. If you're going to overload something, overload SRV - it's actually designed to be overload in this way. Ned From klensin@jck.com Mon Mar 5 07:17:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334421F8799 for ; Mon, 5 Mar 2012 07:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSUKagxwx+xD for ; Mon, 5 Mar 2012 07:17:00 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 838E321F879A for ; Mon, 5 Mar 2012 07:17:00 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S4ZaK-0003sT-FJ; Mon, 05 Mar 2012 10:12:24 -0500 Date: Mon, 05 Mar 2012 10:16:52 -0500 From: John C Klensin To: Jiankang YAO Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:17:01 -0000 --On Sunday, March 04, 2012 20:20 -0800 ned+ima@mrochek.com wrote: >> Dear all, > >> This draft was triggered by email software providers when >> we discussed the eai implementation with them. Any >> comments are welcome. > > First, I have to say that given the present state of play of > the DNS, I am extremely skeptical that a new RRTYPE can > actually deploy soon enough to be useful. And that's assuming > you are able to get it through the process quickly, which is > also unlikely. > > Sadly, the DNS folks are in total denial as to the issues and > AFAICT see no value in working on mechanisms that would > improve the situation. >... I agree with Ned, but want to add two additional comments (speaking for myself only): (1) Whether done with a new RRTYPE or with SRV, this is a major protocol change. The right time to suggest it would have been well before RFC 6531, and the EAI core more generally, were approved so that any relevant requirements could be built into the base protocol if the WG agreed that it were a good way to go. Whether it is desirable or necessary should have been something determined during the experimental protocol period, not put into a draft right after the core standards documents were published. Certainly we have known since RFC 4952 was published in 2007 that there were disadvantages of having to await an EHLO response before knowing whether the server was EAI-capable. As part of that protocol change, it very significantly updates RFC 6531 (and the model in RFC 6530) by changing the expected DNS lookup model from "just like 5321" to "use different RRTYPEs in different ways". It should certainly say that. At this point, any suggestion of this change, such as that in the current document, requires a very careful analysis of the various cases that might be relevant. The few sentences in the Security Considerations of this draft are completely inadequate in that regard. In addition, if we were going to do this, there are other dependencies that should be explored. For example, the model that the WG adopted for VRFY and EXPN in order to deal with the fact that those commands can be issued outside a mail session is really fairly ugly and may turn out to be too delicate. If one could know without going through SMTP extension handshaking (i.e., the EHLO response) whether the server supported SMTPUTF8 capability, then one could hugely simplify the VRFY/EXPN model from what is specified in RFC 6531. It seems to me that this document is not complete unless it at least examines that issue. (2) We've tried to use DNS entries to definitively advertise capabilities since the WKS record when the domain name system was initially designed. Our success rate has been terrible: misconfiguration, different types of relationships between operators of application servers and DNS zone operators, and plain sloppy behavior and mistakes have contributed to both Type I and Type II errors, causing problems severe enough that WKS was formally deprecated. Substituting SRV for an indicator plus MX, as Ned suggests, would presumably help with the problem, but, if SMTPUTF8 is deployed before this suggestion is fully approved, the situation would still require that clients get a sequence of tests correct which, as Ned suggests, is likely to lead to nasty failures. FWIW, when the SMTP extension model was being considered, several types of pre-HELO capability announcements, including trying to go back to DNS announcements, were considered. The EHLO model, despite some disadvantages --including the one to which you are now reacting-- was chosen as the best alternative. Moving to a DNS announcement model would, IMO, create an alternate SMTP extension model. At least IMO, having such alternatives is never a good thing unless there is really no other choice. In addition, speaking as co-chair... (3) To ask a blunt question, if you consider this capability important, would you suggest that people defer implementing the capabilities in RFCs 6531-6533 until this proposal can be approved in the IETF? If the answer is "yes", consider that, even if one ignores the DNS deployment issues, an AD would need to be mildly insane to consider it for approval without getting the EAI WG to process it. Now consider what that would mean given EAI's general speed and efficiency. This draft would have to be improved to the point that the WG could actually consider it. The WG would have to decide to consider it and, in the process, decide whether to defer POP and IMAP and the supporting documents until after this was either approved or definitively rejected (i18n for POP and IMAP is pretty useless if messages cannot be delivered). Given EAI's track record --and your track record for document updates-- I think it would be wildly optimistic to believe that this would result in less than several years delay in SMTPUTF8 deployment. Do you think that is worthwhile? john From klensin@jck.com Mon Mar 5 07:21:30 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D566221F8789 for ; Mon, 5 Mar 2012 07:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJxrGAnzPJll for ; Mon, 5 Mar 2012 07:21:29 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2078121F8780 for ; Mon, 5 Mar 2012 07:21:29 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S4Zeh-0003sg-HI; Mon, 05 Mar 2012 10:16:55 -0500 Date: Mon, 05 Mar 2012 10:21:23 -0500 From: John C Klensin To: Bill McQuillan , IMA Discussion Message-ID: <6460D6F10E8524EB361CA57D@PST.JCK.COM> In-Reply-To: <1183273491.20120304185647@pobox.com> References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F53D84E.6070709@gulbrandsen.priv.no> <1183273491.20120304185647@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Arnt Gulbrandsen Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:21:30 -0000 --On Sunday, March 04, 2012 18:56 -0800 Bill McQuillan wrote: >... > The issues I see are the possibility of changing an email > address local part to a different, valid local part, and the > possibility of messing up an existing encoded word. The email > address local part could be noticed and converted to *all* "?" > chars to make it a clearly unusable address. FWIW, note that "?????@example.com" is a perfectly valid mailbox name with "?????" as a local-part. I'd assume that every SMTP server and web-based submission client that is stupid enough to claim that "+"-based subaddresses are invalid wouldn't accept it either, but that doesn't make it invalid. john From arnt@gulbrandsen.priv.no Mon Mar 5 07:33:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1226021F8796 for ; Mon, 5 Mar 2012 07:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfQzfAWGysCj for ; Mon, 5 Mar 2012 07:33:28 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06021F8792 for ; Mon, 5 Mar 2012 07:33:28 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5F0C2F8D160; Mon, 5 Mar 2012 15:33:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330961604-9866-9866/10/12; Mon, 5 Mar 2012 15:33:24 +0000 Message-Id: <4F54DD04.5000903@gulbrandsen.priv.no> Date: Mon, 5 Mar 2012 16:34:28 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: IMA Discussion References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F53D84E.6070709@gulbrandsen.priv.no> <1183273491.20120304185647@pobox.com> <6460D6F10E8524EB361CA57D@PST.JCK.COM> In-Reply-To: <6460D6F10E8524EB361CA57D@PST.JCK.COM> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:33:29 -0000 On 03/05/2012 04:21 PM, John C Klensin wrote: > FWIW, note that "?????@example.com" is a perfectly valid mailbox > name with "?????" as a local-part. The same applies to any number of cases, mime parameters and blah. I'm decidedly nervous about changing valid syntax into other valid syntax without even parsing it. Besides, I think that ????@gulbrandsen.priv.no does not communicate invalidity clearly. I can pay with a credit card displayed as ???? ???? ???? 1234, so why can't I send mail to McQuilWP@?????.com? Arnt From klensin@jck.com Mon Mar 5 10:52:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEE021F8832 for ; Mon, 5 Mar 2012 10:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNGFu0pd+JBk for ; Mon, 5 Mar 2012 10:52:05 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A9E6721F882E for ; Mon, 5 Mar 2012 10:52:05 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S4cwU-0004Jk-4r; Mon, 05 Mar 2012 13:47:30 -0500 Date: Mon, 05 Mar 2012 13:51:58 -0500 From: John C Klensin To: Arnt Gulbrandsen , IMA Discussion Message-ID: <364065435F8E93692516CEA5@PST.JCK.COM> In-Reply-To: <4F54DD04.5000903@gulbrandsen.priv.no> References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F53D84E.6070709@gulbrandsen.priv.no> <1183273491.20120304185647@pobox.com> <6460D6F10E8524EB361CA57D@PST.JCK.COM> <4F54DD04.5000903@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:52:06 -0000 --On Monday, March 05, 2012 16:34 +0100 Arnt Gulbrandsen wrote: > On 03/05/2012 04:21 PM, John C Klensin wrote: >> FWIW, note that "?????@example.com" is a perfectly valid >> mailbox name with "?????" as a local-part. > > The same applies to any number of cases, mime parameters and > blah. I'm decidedly nervous about changing valid syntax into > other valid syntax without even parsing it. > > Besides, I think that ????@gulbrandsen.priv.no does not > communicate invalidity clearly. I can pay with a credit card > displayed as ???? ???? ???? 1234, so why can't I send mail to > McQuilWP@?????.com? Indeed. I think we are in violent agreement. Substituting a standardized syntactically-valid string for another (or for a UTF-8 form) loses a tremendous amount of information including the fact that the substitution was made. Bad idea, IMO. john From Shawn.Steele@microsoft.com Mon Mar 5 11:24:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D71021F878B for ; Mon, 5 Mar 2012 11:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP3IU0-ZfIZu for ; Mon, 5 Mar 2012 11:24:26 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC5E21F8729 for ; Mon, 5 Mar 2012 11:24:25 -0800 (PST) Received: from mail99-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Mar 2012 19:24:25 +0000 Received: from mail99-tx2 (localhost [127.0.0.1]) by mail99-tx2-R.bigfish.com (Postfix) with ESMTP id F10DA401A7 for ; Mon, 5 Mar 2012 19:24:24 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail99-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2 (MessageSwitch) id 1330975462410682_24917; Mon, 5 Mar 2012 19:24:22 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.240]) by mail99-tx2.bigfish.com (Postfix) with ESMTP id 576EE200049 for ; Mon, 5 Mar 2012 19:24:22 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Mar 2012 19:24:21 +0000 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.241]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0283.004; Mon, 5 Mar 2012 19:24:07 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Fw: I-D Action: draft-yao-eai-dns-00.txt Thread-Index: Acz7BQG5U7/efMQ8RT6rO+A+uQNzLg== Date: Mon, 5 Mar 2012 19:24:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:24:27 -0000 > This draft was triggered by email software providers when we discussed= the eai implementation with them. > Any comments are welcome. Do you have any more information about what problems the email providers we= re experiencing that this is trying to solve? IMO, this information doesn't seem very helpful. I'd still have to query s= omething (DNS in this case), and there'd be a (great) risk of the DNS recor= ds becoming out-of-sync with the actual behavior supported by the SMTP serv= er. Best case, it'd be an early indicator of whether I could tell the user= they'd need to provide another address, but I'll figure that out a couple = seconds/minutes after they hit "send" anyway :) If you have more info about what it's solving maybe I'd have a different co= nclusion. -Shawn From ned+ima@mrochek.com Mon Mar 5 15:11:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256AB21E8017 for ; Mon, 5 Mar 2012 15:11:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ImpteFhtHv8 for ; Mon, 5 Mar 2012 15:11:21 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CB43021F87E6 for ; Mon, 5 Mar 2012 15:11:20 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCRENQ93N4005U4L@mauve.mrochek.com> for ima@ietf.org; Mon, 5 Mar 2012 15:11:17 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 5 Mar 2012 15:11:12 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCRENNJXLY00ZUIL@mauve.mrochek.com> Date: Mon, 05 Mar 2012 15:06:56 -0800 (PST) In-reply-to: "Your message dated Mon, 05 Mar 2012 10:16:52 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1330989084; bh=LiXAW0ehYidB2KeRFDqpBBz1oRf/h8wyIlUNeLues6Q=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=E/ePCm0C/tA9IoTZKiNGvFF/682yh2mgpx/jXPyWOhEPRBgUup6SDb6/upt2wYAQ9 QBNO74lrfav6vOzP4h+/SbfT8ZmGvmd9O8Ai1mVfD6DpwEGDlcjkmEUXlTy22S7Ggg vbSkUmDST/H+fm/64yIAr88RlWSYIkrvgBpy9HpE= Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:11:22 -0000 > --On Sunday, March 04, 2012 20:20 -0800 ned+ima@mrochek.com > wrote: > >> Dear all, > > > >> This draft was triggered by email software providers when > >> we discussed the eai implementation with them. Any > >> comments are welcome. > > > > First, I have to say that given the present state of play of > > the DNS, I am extremely skeptical that a new RRTYPE can > > actually deploy soon enough to be useful. And that's assuming > > you are able to get it through the process quickly, which is > > also unlikely. > > > > Sadly, the DNS folks are in total denial as to the issues and > > AFAICT see no value in working on mechanisms that would > > improve the situation. > >... > I agree with Ned, but want to add two additional comments > (speaking for myself only): > (1) Whether done with a new RRTYPE or with SRV, this is a major > protocol change. The right time to suggest it would have been > well before RFC 6531, and the EAI core more generally, were > approved so that any relevant requirements could be built into > the base protocol if the WG agreed that it were a good way to > go. Whether it is desirable or necessary should have been > something determined during the experimental protocol period, > not put into a draft right after the core standards documents > were published. Certainly we have known since RFC 4952 was > published in 2007 that there were disadvantages of having to > await an EHLO response before knowing whether the server was > EAI-capable. > As part of that protocol change, it very significantly updates > RFC 6531 (and the model in RFC 6530) by changing the expected > DNS lookup model from "just like 5321" to "use different RRTYPEs > in different ways". It should certainly say that. My previous comments were focused on the technical details; in terms of the broader picture I completely agree with John's assessment here. > At this point, any suggestion of this change, such as that in > the current document, requires a very careful analysis of the > various cases that might be relevant. The few sentences in the > Security Considerations of this draft are completely inadequate > in that regard. Correct as well. > In addition, if we were going to do this, there are other > dependencies that should be explored. For example, the model > that the WG adopted for VRFY and EXPN in order to deal with the > fact that those commands can be issued outside a mail session is > really fairly ugly and may turn out to be too delicate. If one > could know without going through SMTP extension handshaking > (i.e., the EHLO response) whether the server supported SMTPUTF8 > capability, then one could hugely simplify the VRFY/EXPN model > from what is specified in RFC 6531. It seems to me that this > document is not complete unless it at least examines that issue. Agreed, although deciding not to address it may be sufficient. > (2) We've tried to use DNS entries to definitively advertise > capabilities since the WKS record when the domain name system > was initially designed. Our success rate has been terrible: > misconfiguration, different types of relationships between > operators of application servers and DNS zone operators, and > plain sloppy behavior and mistakes have contributed to both Type > I and Type II errors, causing problems severe enough that WKS > was formally deprecated. Substituting SRV for an indicator plus > MX, as Ned suggests, would presumably help with the problem, > but, if SMTPUTF8 is deployed before this suggestion is fully > approved, the situation would still require that clients get a > sequence of tests correct which, as Ned suggests, is likely to > lead to nasty failures. Agreed as well. > FWIW, when the SMTP extension model was being considered, > several types of pre-HELO capability announcements, including > trying to go back to DNS announcements, were considered. The > EHLO model, despite some disadvantages --including the one to > which you are now reacting-- was chosen as the best alternative. > Moving to a DNS announcement model would, IMO, create an > alternate SMTP extension model. At least IMO, having such > alternatives is never a good thing unless there is really no > other choice. I share your opinion on this. > In addition, speaking as co-chair... > (3) To ask a blunt question, if you consider this capability > important, would you suggest that people defer implementing the > capabilities in RFCs 6531-6533 until this proposal can be > approved in the IETF? If the answer is "yes", consider that, > even if one ignores the DNS deployment issues, an AD would need > to be mildly insane to consider it for approval without getting > the EAI WG to process it. Now consider what that would mean > given EAI's general speed and efficiency. This draft would have > to be improved to the point that the WG could actually consider > it. The WG would have to decide to consider it and, in the > process, decide whether to defer POP and IMAP and the supporting > documents until after this was either approved or definitively > rejected (i18n for POP and IMAP is pretty useless if messages > cannot be delivered). Given EAI's track record --and your track > record for document updates-- I think it would be wildly > optimistic to believe that this would result in less than > several years delay in SMTPUTF8 deployment. > Do you think that is worthwhile? Speaking for myself, given this assessment, the answer is no, I don't. Ned From johnl@iecc.com Mon Mar 5 17:13:43 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B175421F8807 for ; Mon, 5 Mar 2012 17:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.189 X-Spam-Level: X-Spam-Status: No, score=-110.189 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VokPjXjGqTRa for ; Mon, 5 Mar 2012 17:13:43 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E774421F87B0 for ; Mon, 5 Mar 2012 17:13:42 -0800 (PST) Received: (qmail 83886 invoked from network); 6 Mar 2012 01:13:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Mar 2012 01:13:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5564c4.xn--yuvv84g.k1203; i=johnl@user.iecc.com; bh=usyBAaHDETUaBIDW0T1FX+LRkvu/URibiPkK+FsKqFI=; b=EOrON0ruelwi9FO0FMIyzmXZfhkZt4Epc+FfXE+biNUfd4gPd+qscX9BDLtsUyOxZv58fq3T0Vn8GHRWIvgThAS3HYcZZf68rW4nMnzlbWRqEFZqdQ2vf08V5IgMMxDqcKhVQz7hqfsPn+FGXeXdV/fStyI3Kg42scmv0Di5Rjc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5564c4.xn--yuvv84g.k1203; olt=johnl@user.iecc.com; bh=usyBAaHDETUaBIDW0T1FX+LRkvu/URibiPkK+FsKqFI=; b=W8DovSTJz8OufE0sn25AItLE1bo3KweWMFIEz09N6I8PFviX3RB1W3mng5hDy5WHivIY/CzWr5Ats3EhgIInNx8KP/6RCi+NlfJ5WZnnzMHFQ0WtcsNQgSmej6YC5DldoaUx93ceMPLICQuHdjcMhS1MdeF7Xz4wKnoF4P0AOfU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2012 01:13:18 -0000 Message-ID: <20120306011318.80679.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:13:43 -0000 > This draft was triggered by email software providers when we discussed the eai implementation with them. > Any comments are welcome. The normal way to find out who accepts EAI mail is to look up the MX records and corresponding A and AAAA records, connect in the usual way, and see whether the response to EHLO includes SMTPUTF8. It would be quite reasonable to keep a local cache that remembered for each A and AAAA, whether the it does SMTPUTF8 or not. That could help avoid useless EAI connections to hosts that don't support it. Can you explain why the software providers you talked to aren't willing to do this? As other people have noted, doing anything else would be a major change to the way that mail works. R's, John From yaojk@cnnic.cn Mon Mar 5 19:25:35 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADE21E8045 for ; Mon, 5 Mar 2012 19:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.129 X-Spam-Level: X-Spam-Status: No, score=-101.129 tagged_above=-999 required=5 tests=[AWL=1.470, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt3og8uSn5Q8 for ; Mon, 5 Mar 2012 19:25:34 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id E4C6421F8687 for ; Mon, 5 Mar 2012 19:25:33 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 06 Mar 2012 11:25:31 +0800 Message-ID: <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> From: "Jiankang YAO" To: References: <20120306011318.80679.qmail@joyce.lan> Date: Tue, 6 Mar 2012 11:25:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:25:35 -0000 DQpUaGFua3MgYSBsb3QgZm9yICBhbGwgY29tbWVudHMgZnJvbSB0aGUgd2cgbWVtYmVycy4NCkhl cmUgYXJlIHNvbWUgY2xhcmlmaWNhdGlvbnM6DQoNCjEpIG15IGludGVudGlvbiBpcyB0byBoZWxw IHRoZSBkZXBsb3ltZW50IG9mIGVhaSBwcm90b2NvbHMuIA0KMikgSW4gRmViLiAyMDEyLCBJIHRh bGtlZCB3aXRoIG1hbnkgZW1haWwgc29mdHdhcmUgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIGluIENo aW5hLiAgc29tZSBzb2Z0d2FyZSBwcm92aWRlcnMgaW4gQ2hpbmEgaGF2ZSBwcm9taXNlZCB0byBp bXBsZW1lbnQgYW5kIGRlcGxveSByZmM2NTMxIGFuZCByZmM2NTMyLg0KMykgdGhlIGlkZWEgaW4g dGhlIGRyYWZ0IHdhcyBkaXNjdXNzZWQgZHVyaW5nIEZlYi4gMjAxMiB3aGVuIEkgdGFrbGVkIHdp dGggdGhlbS4gVGhleSB0aG91Z2h0IHRoYXQgc29tZSBtZWNoYW5pc21zIHdpdGggYW4gZWFybHkg aW5kaWNhdG9yIG9mIHdoZXRoZXIgdGhlIGRlc3RpbmF0aW9uIHNlcnZlciBzdXBwb3J0IFNNVFBV VEY4IHdvdWxkIGhlbHAgdGhlIGRlcGxveW1lbnQgb2YgUkZDNjUzMSBhbmQgUkZDNjUyIGR1cmlu ZyB0aGUgZWFybHkgZGVwbG95bWVudCBvZiBFQUkuDQo0KSB0aGlzIGRyYWZ0IGlzIG1haW5seSBm b3IgZGlzY3Vzc2lvbiBhYm91dCBob3cgd2UgY2FuIGhlbHAgdGhlIGRlcGxveW1lbnQgb2YgRUFJ LiBJZiB0aGUgV0cgdGhpbmtzIHRoYXQgaXQgaXMgbm90IGdvb2QgaWRlYSwgd2UgY2FuIGp1c3Qg ZGlzY2FyZCBpdC4NCjUpIHRoZSBzY2VuYXJpbyB3aGljaCB0aGUgZW1haWwgc29mdHdhcmUgb3Ig c2VydmljZSBwcm92aWRlcnMgd291bGQgbGlrZSB0byBhZGRyZXNzIGlzIHRoYXQgZWFpIHVzZXJz IHNlbmQgdGhlIGVhaSBtZXNzYWdlIHRvIG1hbnkgdXNlcnMgaW5jbHVkaW5nIGVhaSB1c2VyIGFu ZCBhc2NpaSB1c2VyLg0KDQogRm9yIGV4YW1wbGUsIGlmIGFuIGludGVybmF0aW9uYWxpemVkIG1l c3NhZ2UgaXMgc2VudCB0byAxMCB1c2VycyBvbmUgb2Ygd2hpY2ggaXMgYW4gQVNDSUkgdXNlciwg dGhlIE1TQSBtYXkgaGF2ZQ0KICAgdG8gc2F5IEVITE8gMTAgdGltZXMgYmVmb3JlIGRlY2lkaW5n IHRvIHJlamVjdCB0aGUgbWVzc2FnZS4gIFRoaXMNCiAgIHByb2NlZHVyZSBvZiBqdWRnaW5nIHdo ZXRoZXIgdGhlIFNNVFAgc2VydmVyIGlzIFNNVFBVVEY4LWF3YXJlIGlzDQogICB0aW1lLWNvbnN1 bWluZy4gDQoNCmVhaUBpZG4uY29tIHNlbmRzIHRoZSBlYWkgbWVzc2FnZSB0bw0KDQoxKSB0ZXN0 QGlkbjEuY29tDQoyKSB0ZXN0QGlkbjIuY29tDQozKSB0ZXN0QGlkbjMuY29tDQo0KSB0ZXN0QGlk bjQuY29tDQo1KSB0ZXN0QGlkbjUuY29tDQo2KSB0ZXN0QGlkbjYuY29tDQo3KSB0ZXN0QGlkbjcu Y29tDQo4KSB0ZXN0QGlkbjguY29tDQo5KSB0ZXN0QGlkbjkuY29tDQoxMCkgdGVzdEBhc2NpaTEw LmNvbQ0KDQoNCmlmIGFsbCB0ZW4gdXNlcnMgc3VwcG9ydCBzbXRwdXRmOCBhbmQgdGhlIE1TQSBr bm93IGl0IGluIGFkdmFuY2UsIHRoZSBtZXNzYWdlIHdpbGwgYmUgc2VudCBvbmUgYnkgb25lIGZy b20gMSkgdG8gMTApLg0KDQppZiB1c2VyIDEwKSB0ZXN0QGFzY2lpMTAuY29tIGRvZXMgbm90IHN1 cHBvcnQgc210cHV0ZjgsIGJ1dCBvdGhlciBuaW5lIHVzZXJzIHN1cHBvcnQgc210cHV0ZjgsIA0K dGhlIE1TQSBtYXkgc2F5IGVobG8gdG8gIHRoZSBkZXN0aW5hdGlvbiBzZXJ2ZXIgb25lIGJ5IG9u ZSBmcm9tIDEpIHRvIDEwKSwgICBhbmQgZmluYWxseSBkZWNpZGUgdG8gcmVqZWN0IGl0Lg0KDQpv ZiBjb3Vyc2UsIHRoZXJlIGFyZSBtYW55IHNvbHV0aW9ucyB0byB0aGlzIGlzc3VlIHN1Y2ggYXMg Sm9obiBsZXZpbmUncyBjYWNoZWQgbWVjaGFuaXNtLg0KDQpJIGp1c3QgYnJpbmcgc29tZSBkZXBs b3ltZW50IGlzc3VlcyBoZXJlLiAgSWYgdGhlIHdnIHRoaW5rIHRoYXQgaXQgaXMgbm90IHdvcnRo LCAgcGxzIGp1c3QgZGlzY2FyZCBpdC4NCg0KSmlhbmthbmcgWWFvDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gTGV2aW5lIiA8am9obmxAdGF1Z2guY29tPg0KVG86 IDxpbWFAaWV0Zi5vcmc+DQpDYzogPHlhb2prQGNubmljLmNuPg0KU2VudDogVHVlc2RheSwgTWFy Y2ggMDYsIDIwMTIgOToxMyBBTQ0KU3ViamVjdDogUmU6IFtFQUldIEZ3OiBJLUQgQWN0aW9uOiBk cmFmdC15YW8tZWFpLWRucy0wMC50eHQNCg0KDQo+PiAgIFRoaXMgZHJhZnQgd2FzIHRyaWdnZXJl ZCBieSAgZW1haWwgc29mdHdhcmUgcHJvdmlkZXJzIHdoZW4gd2UgZGlzY3Vzc2VkIHRoZSBlYWkg aW1wbGVtZW50YXRpb24gd2l0aCB0aGVtLg0KPj4gICBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUu DQo+IA0KPiBUaGUgbm9ybWFsIHdheSB0byBmaW5kIG91dCB3aG8gYWNjZXB0cyBFQUkgbWFpbCBp cyB0byBsb29rIHVwIHRoZSBNWA0KPiByZWNvcmRzIGFuZCBjb3JyZXNwb25kaW5nIEEgYW5kIEFB QUEgcmVjb3JkcywgY29ubmVjdCBpbiB0aGUgdXN1YWwNCj4gd2F5LCBhbmQgc2VlIHdoZXRoZXIg dGhlIHJlc3BvbnNlIHRvIEVITE8gaW5jbHVkZXMgU01UUFVURjguICBJdCB3b3VsZA0KPiBiZSBx dWl0ZSByZWFzb25hYmxlIHRvIGtlZXAgYSBsb2NhbCBjYWNoZSB0aGF0IHJlbWVtYmVyZWQgZm9y IGVhY2ggQQ0KPiBhbmQgQUFBQSwgd2hldGhlciB0aGUgaXQgZG9lcyBTTVRQVVRGOCBvciBub3Qu ICBUaGF0IGNvdWxkIGhlbHAgYXZvaWQNCj4gdXNlbGVzcyBFQUkgY29ubmVjdGlvbnMgdG8gaG9z dHMgdGhhdCBkb24ndCBzdXBwb3J0IGl0Lg0KPiANCj4gQ2FuIHlvdSBleHBsYWluIHdoeSB0aGUg c29mdHdhcmUgcHJvdmlkZXJzIHlvdSB0YWxrZWQgdG8gYXJlbid0DQo+IHdpbGxpbmcgdG8gZG8g dGhpcz8gIEFzIG90aGVyIHBlb3BsZSBoYXZlIG5vdGVkLCBkb2luZyBhbnl0aGluZw0KPiBlbHNl IHdvdWxkIGJlIGEgbWFqb3IgY2hhbmdlIHRvIHRoZSB3YXkgdGhhdCBtYWlsIHdvcmtzLg0KPiAN Cj4gUidzLA0KPiBKb2hu From ajs@crankycanuck.ca Mon Mar 5 19:29:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8876821F8768 for ; Mon, 5 Mar 2012 19:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR8YH+Xn7rKS for ; Mon, 5 Mar 2012 19:29:59 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 03A1921F861B for ; Mon, 5 Mar 2012 19:29:59 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 154251ECB41D for ; Tue, 6 Mar 2012 03:29:58 +0000 (UTC) Date: Mon, 5 Mar 2012 22:29:56 -0500 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20120306032955.GN76465@crankycanuck.ca> References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:29:59 -0000 Hi, On Sun, Mar 04, 2012 at 08:20:44PM -0800, ned+ima@mrochek.com wrote: > First, I have to say that given the present state of play of the DNS, I am > extremely skeptical that a new RRTYPE can actually deploy soon enough to be > useful. And that's assuming you are able to get it through the process quickly, > which is also unlikely. > > Sadly, the DNS folks are in total denial as to the issues and AFAICT see no > value in working on mechanisms that would improve the situation. Just so that we're clear here: are you talking about the much-complained-of problem that provisioning systems are brain-dead with respect to unknown RRTYPEs (a complaint that I understand and sympathise with), or some other problem? For the DNS RRTYPE proposed in the draft could have its typecode within a matter of weeks, even though I happen to think that the proposal is a bad idea and would waste a perfectly code typecode. (Indeed, last year we allocated two such typecodes.) I find it a little hard to believe that an organization willing to go to the effort of deploying a fairly significant extension to SMTP, including all the surrounding infrastructure, is going to balk at upgrades to their DNS provisioning tools. Compared to, for instance, the validation rules behind every single mail-address box on every web form in the known universe, DNS provisioning tools at the site turning on EAI have got to be low on the "hard to fix" list. If the problem is that applications can't use unknown RRTYPEs, then I beg to differ: we see them implemented all the time, particularly at the level where systems that are communicating over SMTP are. I don't think it helps anyone to make sweeping generalizations about "DNS folks" and their collective state of mind. I carry no water for the draft in question -- I agree with the other concerns that have been raised -- but I don't see how the supposed difficulty in coping with the DNS has anything to do with the problems here. Best, A -- Andrew Sullivan ajs@crankycanuck.ca From ned+ima@mrochek.com Mon Mar 5 22:08:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87EC21E8073 for ; Mon, 5 Mar 2012 22:08:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9zEWOPEspgV for ; Mon, 5 Mar 2012 22:08:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B971B21E8045 for ; Mon, 5 Mar 2012 22:08:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCRT8DSZTC015YW0@mauve.mrochek.com> for ima@ietf.org; Mon, 5 Mar 2012 22:08:47 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 5 Mar 2012 22:08:42 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCRT8AX3NG00ZUIL@mauve.mrochek.com> Date: Mon, 05 Mar 2012 21:27:41 -0800 (PST) In-reply-to: "Your message dated Mon, 05 Mar 2012 22:29:56 -0500" <20120306032955.GN76465@crankycanuck.ca> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> <20120306032955.GN76465@crankycanuck.ca> To: Andrew Sullivan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331014135; bh=lB8+SoiOB2lPubTTIkvp5MqAOQ5bIGdbALgemzq8MDg=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=phYU05fiTtpBRubddFb3xVe1UV5J0gYas9lXFLVWvKoldyn9tuoDSO9ssesEvNBIa OjXpuJEZ2/HWR0XdHX7h4eH/CWEpbKBARPeg2Ypx4OlitdWeuNZoZz9Rt0bgGSR2Ix ukskp3dRJlZlzDgMInklR0cCYRJTsSJkqiGzYjUY= Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:08:54 -0000 > Hi, > On Sun, Mar 04, 2012 at 08:20:44PM -0800, ned+ima@mrochek.com wrote: > > First, I have to say that given the present state of play of the DNS, I am > > extremely skeptical that a new RRTYPE can actually deploy soon enough to be > > useful. And that's assuming you are able to get it through the process quickly, > > which is also unlikely. > > > > Sadly, the DNS folks are in total denial as to the issues and AFAICT see no > > value in working on mechanisms that would improve the situation. > Just so that we're clear here: are you talking about the > much-complained-of problem that provisioning systems are brain-dead > with respect to unknown RRTYPEs (a complaint that I understand and > sympathise with), or some other problem? I'm talking about the refusal to lift a finger to address the parts of the problem we do have control over. (We can't solve the braindead provisioning problem, but we can sure as hell make it a lot easier to write non-braindead provisioning systems.) I'm talking about posting frank nonsense like the assertion that adding an entry to a configuration file isn't materially different from patching or upgrading a piece of critical infrastructure software to a new version. I could go on and list other examples, but since this is largely irrelevant in this forum I think this suffices. > For the DNS RRTYPE proposed > in the draft could have its typecode within a matter of weeks, even > though I happen to think that the proposal is a bad idea and would > waste a perfectly code typecode. (Indeed, last year we allocated two > such typecodes.) I agree that this draft is a bad idea for other reasons. Nevertheless, I stand by my assertion that new RRTYPEs would be a problem if this draft were to go forward in the present form. > I find it a little hard to believe that an organization willing to go > to the effort of deploying a fairly significant extension to SMTP, > including all the surrounding infrastructure, is going to balk at > upgrades to their DNS provisioning tools. I can assure you, based on 20+ years of experience dealing with exactly these sorts of sites on pretty much a daily basis, that it is 100% true. Part of the problem is that these are large organizations and different services are provided by different parts of the organization. The folks who control DNS provisioning and upgrades are not the same as the ones who operate the email systems. In a lot of cases a request to upgrade critical infrastructure to a new version that doesn't coincide with their own schedule will be met with, "Stick it where the sun don't shine." Or worse. Heck, only today we were having an internal argument about the feasibility of using SRV records for some internal purposes - and they have been around for many years. (In this case I was the one arguing that they are now feasible to use due to various services like SIP and XMPP that depend on them having deployed, others in our organization with significant technical competence disagree and think we should avoid them. And it's possible I'm wrong and they are right.) > Compared to, for instance, > the validation rules behind every single mail-address box on every web > form in the known universe, Well, you're significantly overstating the difficulty of constructing rules for what I'll call the useful subset of email addresses, but that's not really relevant to the matter at hand. > DNS provisioning tools at the site turning > on EAI have got to be low on the "hard to fix" list. I disagree, but even if you're right technical difficulty is not the only, nor in many cases the most important, factor. > If the problem is that applications can't use unknown RRTYPEs, then I > beg to differ: we see them implemented all the time, particularly at > the level where systems that are communicating over SMTP are. > I don't think it helps anyone to make sweeping generalizations about > "DNS folks" and their collective state of mind. That's your opinion. I don't share it. I'm sick and tired of their crap, and in this forum I'm not going to mince words about my opinion of it. > I carry no water for the draft in question -- I agree with the other concerns > that have been raised -- but I don't see how the supposed difficulty in coping > with the DNS has anything to do with the problems here. Spend a few years writing and supporting software for the folks running mail systems at large ISPs, and I can assure you your position would change. Ned From ned+ima@mrochek.com Mon Mar 5 23:57:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC421E808C for ; Mon, 5 Mar 2012 23:57:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtKTdxlkVzRW for ; Mon, 5 Mar 2012 23:57:01 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA221E8020 for ; Mon, 5 Mar 2012 23:56:43 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCRX04PYSW014JSZ@mauve.mrochek.com> for ima@ietf.org; Mon, 5 Mar 2012 23:56:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 5 Mar 2012 23:56:34 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCRX01EWDW00ZUIL@mauve.mrochek.com> Date: Mon, 05 Mar 2012 23:18:56 -0800 (PST) In-reply-to: "Your message dated Tue, 06 Mar 2012 11:25:33 +0800" <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> To: Jiankang YAO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331020608; bh=H1NGUlb5Vlh7yDMH+DFCqTjRfuW7Xd44GkuCJzhwldw=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=BGJ7M5nVoDNBoAuwVip+Q7SzrgLYtY4bjBG3dJppakHwFAfIyJaViAOwVNDbFtPe/ kzweAK8GjRr88wvPc2VI2UZXTrKXsBwuScIbX/KFXsg6tcmkdBRgMyP2S1+wyD7sH3 fa/+82D3g+Nx57Z+CjfD4AXsHm9pFGF1VfcOqdDw= Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:57:02 -0000 > Thanks a lot for all comments from the wg members. > Here are some clarifications: > 1) my intention is to help the deployment of eai protocols. > 2) In Feb. 2012, I talked with many email software and service providers in China. some software providers in China have promised to implement and deploy rfc6531 and rfc6532. > 3) the idea in the draft was discussed during Feb. 2012 when I takled with them. They thought that some mechanisms with an early indicator of whether the destination server support SMTPUTF8 would help the deployment of RFC6531 and RFC652 during the early deployment of EAI. > 4) this draft is mainly for discussion about how we can help the deployment of EAI. If the WG thinks that it is not good idea, we can just discard it. > 5) the scenario which the email software or service providers would like to address is that eai users send the eai message to many users including eai user and ascii user. > For example, if an internationalized message is sent to 10 users one of which is an ASCII user, the MSA may have > to say EHLO 10 times before deciding to reject the message. Say what? I would expect in this case for the message to be delivered to the first 9 recipients and for the 10th to generate a DSN. That's the only sensible outcome, and moreover, the idea of having to get responses from multiple systems before deciding whether or not to reject the message in toto is both an implementation nightmare as well as operationally infeasible. What if one of the systems you have never talked to before is down for a prolonged period longer than the MSA or MTA's queue timeout? Do you seriously think it's a good idea to have a message sit in the queue for a week and then time out and bounce for all recipients because of that? I also note that nothing in the EAI document set requires, or for that matter even encourages, such behavior. > This > procedure of judging whether the SMTP server is SMTPUTF8-aware is > time-consuming. No, it really isn't. Modern MTAs at a minimum split such messages by destination host and perform deliveries in parallel. (Note that this is the minimum they do; there are many additional optimizations that can be performed, with varying degrees of effectiveness.) > eai@idn.com sends the eai message to > 1) test@idn1.com > 2) test@idn2.com > 3) test@idn3.com > 4) test@idn4.com > 5) test@idn5.com > 6) test@idn6.com > 7) test@idn7.com > 8) test@idn8.com > 9) test@idn9.com > 10) test@ascii10.com > if all ten users support smtputf8 and the MSA know it in advance, the message > will be sent one by one from 1) to 10). Again, your understanding of how modern MTAs work is incorrect. It is very likely, in fact nearly certain, that the message will go out with some degree of parallelism. And the results of delivery to one recipient are not coupled to the results of others. I will also point out that as a practical matter, you cannot possibly guarantee these sorts of results no matter what implementors do. What if one of the systems says it supports EAI but then rejects the recipient during the SMTP dialogue because that _recipient_ doesn't support it? Or what if the system accepts the message but decides to reject it later because that recipient is later determined to not support EAI? Either way you've lost your "all succeed or all fail" capability. And having such behavior in some cases but not others violates the least astonishment principle. > if user 10) test@ascii10.com does not support smtputf8, but other nine users > support smtputf8, the MSA may say ehlo to the destination server one by one > from 1) to 10), and finally decide to reject it. I doubt very much any MSA will implement that strategy, for reasons given above. And it certainly isn't required that they do so. > of course, there are many solutions to this issue such as John levine's > cached mechanism. I'm afraid most of the problems you're attempting to address here are based on a misunderstanding of how this is going to work. As for caching EHLO repsonses, that actually makes me a little nervous. Caching positive responses is fine but not particularly useful, caching negative ones OTOH for any length of time risks the the possibility that the system will be upgraded and messages will get bounced for no good reason. Ned From yaojk@cnnic.cn Tue Mar 6 00:40:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159A121F8777 for ; Tue, 6 Mar 2012 00:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.057 X-Spam-Level: X-Spam-Status: No, score=-100.057 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-y0E2zoqkcc for ; Tue, 6 Mar 2012 00:40:45 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id B2E1221F8762 for ; Tue, 6 Mar 2012 00:40:42 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 06 Mar 2012 16:40:36 +0800 Message-ID: <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> From: "Jiankang YAO" To: "Ned Freed" References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> <01OCRX01EWDW00ZUIL@mauve.mrochek.com> Date: Tue, 6 Mar 2012 16:40:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:40:46 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk5lZCBGcmVlZCIgPG5lZC5m cmVlZEBtcm9jaGVrLmNvbT4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+DQpD YzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDEyIDM6MTggUE0N ClN1YmplY3Q6IFJlOiBbRUFJXSBGdzogSS1EIEFjdGlvbjogZHJhZnQteWFvLWVhaS1kbnMtMDAu dHh0DQoNCg0KPj4gVGhhbmtzIGEgbG90IGZvciAgYWxsIGNvbW1lbnRzIGZyb20gdGhlIHdnIG1l bWJlcnMuDQo+PiBIZXJlIGFyZSBzb21lIGNsYXJpZmljYXRpb25zOg0KPiANCj4+IDEpIG15IGlu dGVudGlvbiBpcyB0byBoZWxwIHRoZSBkZXBsb3ltZW50IG9mIGVhaSBwcm90b2NvbHMuDQo+PiAy KSBJbiBGZWIuIDIwMTIsIEkgdGFsa2VkIHdpdGggbWFueSBlbWFpbCBzb2Z0d2FyZSBhbmQgc2Vy dmljZSBwcm92aWRlcnMgaW4gQ2hpbmEuICBzb21lIHNvZnR3YXJlIHByb3ZpZGVycyBpbiBDaGlu YSBoYXZlIHByb21pc2VkIHRvIGltcGxlbWVudCBhbmQgZGVwbG95IHJmYzY1MzEgYW5kIHJmYzY1 MzIuDQo+PiAzKSB0aGUgaWRlYSBpbiB0aGUgZHJhZnQgd2FzIGRpc2N1c3NlZCBkdXJpbmcgRmVi LiAyMDEyIHdoZW4gSSB0YWtsZWQgd2l0aCB0aGVtLiBUaGV5IHRob3VnaHQgdGhhdCBzb21lIG1l Y2hhbmlzbXMgd2l0aCBhbiBlYXJseSBpbmRpY2F0b3Igb2Ygd2hldGhlciB0aGUgZGVzdGluYXRp b24gc2VydmVyIHN1cHBvcnQgU01UUFVURjggd291bGQgaGVscCB0aGUgZGVwbG95bWVudCBvZiBS RkM2NTMxIGFuZCBSRkM2NTIgZHVyaW5nIHRoZSBlYXJseSBkZXBsb3ltZW50IG9mIEVBSS4NCj4+ IDQpIHRoaXMgZHJhZnQgaXMgbWFpbmx5IGZvciBkaXNjdXNzaW9uIGFib3V0IGhvdyB3ZSBjYW4g aGVscCB0aGUgZGVwbG95bWVudCBvZiBFQUkuIElmIHRoZSBXRyB0aGlua3MgdGhhdCBpdCBpcyBu b3QgZ29vZCBpZGVhLCB3ZSBjYW4ganVzdCBkaXNjYXJkIGl0Lg0KPj4gNSkgdGhlIHNjZW5hcmlv IHdoaWNoIHRoZSBlbWFpbCBzb2Z0d2FyZSBvciBzZXJ2aWNlIHByb3ZpZGVycyB3b3VsZCBsaWtl IHRvIGFkZHJlc3MgaXMgdGhhdCBlYWkgdXNlcnMgc2VuZCB0aGUgZWFpIG1lc3NhZ2UgdG8gbWFu eSB1c2VycyBpbmNsdWRpbmcgZWFpIHVzZXIgYW5kIGFzY2lpIHVzZXIuDQo+IA0KPj4gIEZvciBl eGFtcGxlLCBpZiBhbiBpbnRlcm5hdGlvbmFsaXplZCBtZXNzYWdlIGlzIHNlbnQgdG8gMTAgdXNl cnMgb25lIG9mIHdoaWNoIGlzIGFuIEFTQ0lJIHVzZXIsIHRoZSBNU0EgbWF5IGhhdmUNCj4+ICAg IHRvIHNheSBFSExPIDEwIHRpbWVzIGJlZm9yZSBkZWNpZGluZyB0byByZWplY3QgdGhlIG1lc3Nh Z2UuDQo+IA0KPiBTYXkgd2hhdD8gSSB3b3VsZCBleHBlY3QgaW4gdGhpcyBjYXNlIGZvciB0aGUg bWVzc2FnZSB0byBiZSBkZWxpdmVyZWQgdG8gdGhlDQo+IGZpcnN0IDkgcmVjaXBpZW50cyBhbmQg Zm9yIHRoZSAxMHRoIHRvIGdlbmVyYXRlIGEgRFNOLiBUaGF0J3MgdGhlIG9ubHkgc2Vuc2libGUN Cj4gb3V0Y29tZSANCj4NCg0KdGhlcmUgaXMgYSBwcm9ibGVtIGhlcmUuDQoNCldoZW4geW91IHNl bmQgYSBtZXNzYWdlIHRvIDEwIHVzZXJzLCA5IHVzZXJzKEEgQiBDIEQgRSBGIEcgSCBJKSByZWNp ZXZlIHRoZSBtZXNzYWdlLiAxIHVzZXIgKEspIGNhbiBub3QgcmVjZWl2ZSBpdC4NCg0KcXVlc3Rp b24gMSApIHdoYXQgaXMgeW91ciBuZXh0IHN0ZXAgdG8gZGVhbCB3aXRoIHRoZSB1c2VyIHdobyBj YW4gbm90IHJlY2VpdmUgaXQ/DQoNCjEpIHlvdSB1c2UgeW91ciBhc2NpaSBhZGRyZXNzIHRvIHNl bmQgdGhlIG1lc3NhZ2UgcHJpdmF0ZWx5IHRvIHRoZSB1c2VyIChLKSB3aG8gY2FuIG5vdCByZWNl aXZlIGl0DQoNCjIpanVzdCBpZ25vcmUgaXQgYW5kIGRvIG5vdGhpbmcNCg0KcXVlc3Rpb24gMikg aG93IDkgdXNlcnMoQSBCIEMgRCBFIEYgRyBIIEkpIHJlcGx5IHRoZSBtZXNzYWdlIHJlY2VpdmVk Pw0KDQp0aGUgcHJvYmxlbSBpcyB0aGF0IHVzZXIgKEspIGlzIGluIHRoZSByZWNpcGllbnRzIGxp c3QgYnV0IG5ldmVyIHJlY2lldmUgdGhlIG1lc3NhZ2UgdW5sZXNzIHRoZSBzZW5kZXIgZm9yd2Fy ZHMgb3IgcmVzZW5kcyB0aGUgbWVzc2FnZSBwcml2YXRlbHkgdG8gdXNlciAoSykuDQoNCg0KSmlh bmthbmcgWWFvDQo= From arnt@gulbrandsen.priv.no Tue Mar 6 00:49:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B41E21F8674 for ; Tue, 6 Mar 2012 00:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgOLQZbHtRJ3 for ; Tue, 6 Mar 2012 00:49:55 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id D82F621F8670 for ; Tue, 6 Mar 2012 00:49:54 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 50245F8CA80; Tue, 6 Mar 2012 08:49:52 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1331023791-9866-9866/10/13; Tue, 6 Mar 2012 08:49:51 +0000 Message-Id: <4F55CFF1.7000901@gulbrandsen.priv.no> Date: Tue, 6 Mar 2012 09:50:57 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> <01OCRX01EWDW00ZUIL@mauve.mrochek.com> <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> In-Reply-To: <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:49:55 -0000 On 03/06/2012 09:40 AM, Jiankang YAO wrote: > there is a problem here. >=20 > When you send a message to 10 users, 9 users(A B C D E F G H I) = recieve the message. 1 user (K) can not receive it. We've had this problem for thirty years. It's not an EAI problem. EAI just adds one more case in which it can happen. Arnt From klensin@jck.com Tue Mar 6 02:04:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C630A21F86A6 for ; Tue, 6 Mar 2012 02:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4NFoMkQFpNv for ; Tue, 6 Mar 2012 02:04:45 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id AC80921F85C9 for ; Tue, 6 Mar 2012 02:04:45 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S4rBh-0005aS-JE; Tue, 06 Mar 2012 05:00:09 -0500 Date: Tue, 06 Mar 2012 05:04:37 -0500 From: John C Klensin To: ned+ima@mrochek.com, Andrew Sullivan Message-ID: <06F0D344C5C7C66943B4688F@PST.JCK.COM> In-Reply-To: <01OCRT8AX3NG00ZUIL@mauve.mrochek.com> References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> <20120306032955.GN76465@crankycanuck.ca> <01OCRT8AX3NG00ZUIL@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@ietf.org Subject: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:04:46 -0000 Andrew, FWIW, my experience agrees with Ned's. Even in a centralized environment in which responsibility for applications services (SMTP servers in this case) and responsibility for infrastructure ones like DNS servers lies with the same group, there are innumerable reasons why upgrade schedules for one might be quite different from upgrade schedules for another or why there might be much more reluctance to upgrade one than the other. For example, because an SMTP server affects only a single application, changing it might require only signoff from the SMTP subgroup or person but, because a DNS server affects many applications, changes might require multiple signoffs. Even if we were able to agree that many or most of those reasons for differences were wrong-headed, that agreement would make absolutely no difference in practice. Along those same lines, the argument that "all one has to is to change some tables and recompile" is likely to be treated as utter nonsense by someone who can easily resist pressure to upgrade things but who can get fired for creating instability (whether the local capability for rebuilding and recompiling actually exists in practice is also irrelevant in many cases). I've worked in environments in which the commitment to absolute stability of any application seen by the user is strong enough that simple recompilation with unchanged source code is not considered a safe transformation. Unless the compilers are provably bug-free (good luck with that!), that concern is real unless one can guarantee that the recompilation uses the same version of the compiler and all relevant supporting tools. You or others might believe that level of concern is excessive. On some days, I might agree. But our beliefs are worth just about nothing. FWIW, if I were responsible for significant DNS server software or designing new RRTYPEs, and were serious about making new RRTYPEs easy to deploy, I'd skip fairy tales like "you can easily recompile" in favor of thinking through the question of what would constitute a minimal description language for RRTYPEs that could be interpreted (if it needed to be more complex than LR(0), I'd suggest we are in serious trouble) such that while known (older) RRTYPEs could be optimized into code, new ones could be tested and added with an absolutely minimal risk of bad consequences to anything else by adding a new rule to an interpreted table (or a new table to a set). If the server code then shipped with configuration options to either locate the table(s) or disable lookup and interpretation for new RRTYPEs, we'd be having a rather different discussion, IMO. Such interpretative rules are not rocket science and would overcome most (although definitely not all) of the practical objections to "just deploy a new RRTYPE" that Ned, myself, and others are raising. But while it seems obvious, no one seems to want to do that. Possibly computing the amount of thrust needed to get a pig airborne is more interesting :-( john --On Monday, March 05, 2012 21:27 -0800 ned+ima@mrochek.com wrote: >> Hi, > >> On Sun, Mar 04, 2012 at 08:20:44PM -0800, ned+ima@mrochek.com >> wrote: > >> > First, I have to say that given the present state of play >> > of the DNS, I am extremely skeptical that a new RRTYPE can >> > actually deploy soon enough to be useful. And that's >> > assuming you are able to get it through the process quickly, >> > which is also unlikely. >> > >> > Sadly, the DNS folks are in total denial as to the issues >> > and AFAICT see no value in working on mechanisms that would >> > improve the situation. > >> Just so that we're clear here: are you talking about the >> much-complained-of problem that provisioning systems are >> brain-dead with respect to unknown RRTYPEs (a complaint that >> I understand and sympathise with), or some other problem? > > I'm talking about the refusal to lift a finger to address the > parts of the problem we do have control over. (We can't solve > the braindead provisioning problem, but we can sure as hell > make it a lot easier to write non-braindead provisioning > systems.) I'm talking about posting frank nonsense like the > assertion that adding an entry to a configuration file isn't > materially different from patching or upgrading a piece of > critical infrastructure software to a new version. > > I could go on and list other examples, but since this is > largely irrelevant in this forum I think this suffices. > >> For the DNS RRTYPE proposed >> in the draft could have its typecode within a matter of >> weeks, even though I happen to think that the proposal is a >> bad idea and would waste a perfectly code typecode. (Indeed, >> last year we allocated two such typecodes.) > > I agree that this draft is a bad idea for other reasons. > Nevertheless, I stand by my assertion that new RRTYPEs would > be a problem if this draft were to go forward in the present > form. > >> I find it a little hard to believe that an organization >> willing to go to the effort of deploying a fairly significant >> extension to SMTP, including all the surrounding >> infrastructure, is going to balk at upgrades to their DNS >> provisioning tools. > > I can assure you, based on 20+ years of experience dealing > with exactly these sorts of sites on pretty much a daily > basis, that it is 100% true. > > Part of the problem is that these are large organizations and > different services are provided by different parts of the > organization. The folks who control DNS provisioning and > upgrades are not the same as the ones who operate the email > systems. In a lot of cases a request to upgrade critical > infrastructure to a new version that doesn't coincide with > their own schedule will be met with, "Stick it where the sun > don't shine." Or worse. > > Heck, only today we were having an internal argument about the > feasibility of using SRV records for some internal purposes - > and they have been around for many years. (In this case I was > the one arguing that they are now feasible to use due to > various services like SIP and XMPP that depend on them having > deployed, others in our organization with significant > technical competence disagree and think we should avoid them. > And it's possible I'm wrong and they are right.) > >> Compared to, for instance, >> the validation rules behind every single mail-address box on >> every web form in the known universe, > > Well, you're significantly overstating the difficulty of > constructing rules for what I'll call the useful subset of > email addresses, but that's not really relevant to the matter > at hand. > >> DNS provisioning tools at the site turning >> on EAI have got to be low on the "hard to fix" list. > > I disagree, but even if you're right technical difficulty is > not the only, nor in many cases the most important, factor. > >> If the problem is that applications can't use unknown >> RRTYPEs, then I beg to differ: we see them implemented all >> the time, particularly at the level where systems that are >> communicating over SMTP are. > >> I don't think it helps anyone to make sweeping >> generalizations about "DNS folks" and their collective state >> of mind. > > That's your opinion. I don't share it. I'm sick and tired of > their crap, and in this forum I'm not going to mince words > about my opinion of it. > >> I carry no water for the draft in question -- I agree with >> the other concerns that have been raised -- but I don't see >> how the supposed difficulty in coping with the DNS has >> anything to do with the problems here. > > Spend a few years writing and supporting software for the > folks running mail systems at large ISPs, and I can assure you > your position would change. > > Ned > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Tue Mar 6 02:18:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344A21F8852 for ; Tue, 6 Mar 2012 02:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9keg20jgptV for ; Tue, 6 Mar 2012 02:18:37 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 76AEA21F8850 for ; Tue, 6 Mar 2012 02:18:37 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S4rP8-0005bJ-Tt; Tue, 06 Mar 2012 05:14:02 -0500 Date: Tue, 06 Mar 2012 05:18:31 -0500 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: <2072935811759DBE83E93F06@PST.JCK.COM> In-Reply-To: <4F55CFF1.7000901@gulbrandsen.priv.no> References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> <01OCRX01EWDW00ZUIL@mauve.mrochek.com> <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> <4F55CFF1.7000901@gulbrandsen.priv.no> 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] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:18:38 -0000 --On Tuesday, March 06, 2012 09:50 +0100 Arnt Gulbrandsen wrote: > On 03/06/2012 09:40 AM, Jiankang YAO wrote: >> there is a problem here. >> >> When you send a message to 10 users, 9 users(A B C D E F G H >> I) recieve the message. 1 user (K) can not receive it. > > We've had this problem for thirty years. It's not an EAI > problem. EAI just adds one more case in which it can happen. More as an aside than because it has direct relevance here, but I remember conversations about this issue a very long time ago, perhaps in the context of email systems that existed prior to, or in parallel with, RFC821/822. It is very attractive to try to design a system so that, if A sees a message whose headers show herself and B C D E F G H I K as recipients, she should be able to know that all of them received and saw the message. It has been a long time but, if I recall, VRFY came into our world partially because of a desire to be able to validate all ten recipient mailboxes and then send the message to all of them with some assurance of deliverability. The difficulty is that, as soon as one considers recipients on multiple target systems, it is basically impossible for the reasons Arnt and Ned point out (and some others). Even in a single target system that is that same one on which the sender's mailbox and submission server are located, there is the possibility of race conditions with "mailbox full" or even "account deleted" after the VRFY process completes. That possibility would exist even if VRFY reported presumably-temporary conditions like "mailbox full", which it does not. It is perhaps also worth noting that the guarantee of delivery to everyone doesn't exist with postal mail either. If I address a postal letter to a recipient and indicate that I'm copying several other, then put copies of the letter into separate envelopes and mail/post them, there are no guarantees that all of them will be delivered and failures can occur for a rather large variety of reasons: the "cc" list is a statement of intent, nothing more. There _is_ a reason why some idea like establishing capabilities in the DNS might be attractive if it would actually work and be provisioned correctly in the vast majority of cases and that is for the submission server (or even the originating MUA) to be able to find out if the recipient can accept SMTPUTF8 messages even if no direct connectivity exists. That has nothing to do with the multiple-recipient delivery situation but could be useful in determining whether a message would need downgrading or remapping in the submission server or earlier. But getting all of the submission bits correct would not be straightforward and, if the advice we've given about capabilities in MX-specified relay hosts is followed, the marginal value is probably far outweighed by the need for sender code to deal with a more complex environment and likelihood of misconfiguration. So, Jiankang, I think your colleagues are thinking about the problem incorrectly, or at least naively, and the reasons go far beyond the particular properties of SMTP (much less EAI)/SMTPUTF8). best, john From ned+ima@mrochek.com Tue Mar 6 07:29:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34621F8977 for ; Tue, 6 Mar 2012 07:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLCCUkZbT7+z for ; Tue, 6 Mar 2012 07:29:17 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4021F8976 for ; Tue, 6 Mar 2012 07:29:17 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCSCT6Y1FK00UMY6@mauve.mrochek.com> for ima@ietf.org; Tue, 6 Mar 2012 07:29:13 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 6 Mar 2012 07:29:06 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCSCT3AOYA00ZUIL@mauve.mrochek.com> Date: Tue, 06 Mar 2012 07:08:18 -0800 (PST) In-reply-to: "Your message dated Tue, 06 Mar 2012 16:40:34 +0800" <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=gb2312 References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> <01OCRX01EWDW00ZUIL@mauve.mrochek.com> <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> To: Jiankang YAO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331047761; bh=KjaN1nsiQFWwMsfY3Hsz405OQXMv3SqovTx2+mLZiHs=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=OXhDOx8Kkkq902JIrzMbkdY5zBpuLQ/RNFMxH3dPkQ7Sdz5UVll9CTD6YYqeIMvaX wCEG4w7m7gYlGwK95KCn9aR3ZRUYEtGn+t/lZa6HtibjCqwm5w6uj7OvlXE+Z8wBAm 4v7NwLYwR/66PkPFdKZOT3wctjAmI9r+OTL/Hi/A= Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:29:18 -0000 > ----- Original Message ----- > From: "Ned Freed" > To: "Jiankang YAO" > Cc: > Sent: Tuesday, March 06, 2012 3:18 PM > Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt > >> Thanks a lot for all comments from the wg members. > >> Here are some clarifications: > > > >> 1) my intention is to help the deployment of eai protocols. > >> 2) In Feb. 2012, I talked with many email software and service providers in China. some software providers in China have promised to implement and deploy rfc6531 and rfc6532. > >> 3) the idea in the draft was discussed during Feb. 2012 when I takled with them. They thought that some mechanisms with an early indicator of whether the destination server support SMTPUTF8 would help the deployment of RFC6531 and RFC652 during the early deployment of EAI. > >> 4) this draft is mainly for discussion about how we can help the deployment of EAI. If the WG thinks that it is not good idea, we can just discard it. > >> 5) the scenario which the email software or service providers would like to address is that eai users send the eai message to many users including eai user and ascii user. > > > >> For example, if an internationalized message is sent to 10 users one of which is an ASCII user, the MSA may have > >> to say EHLO 10 times before deciding to reject the message. > > > > Say what? I would expect in this case for the message to be delivered to the > > first 9 recipients and for the 10th to generate a DSN. That's the only sensible > > outcome > > > there is a problem here. I'm sorry, but there really isn't - at least there's no new problem that users don't already face all on a regular basis. > When you send a message to 10 users, 9 users(A B C D E F G H I) recieve the > message. 1 user (K) can not receive it. > question 1 ) what is your next step to deal with the user who can not receive > it? The same as whatever you do when one of the users you sent to can't receive your mail now: Redo your message, so it's acceptable, call them on the phone, IM them, ignore the problem, whatever. This happens *all* *the* *time*, and when, say, your message is larger than the limit that site accepts, the condition may be every bit as permanent as if you tried to send them an EAI mail and they don't support that. This is has always been how email has worked. Users have been coping with it for decades. They don't seem to have a problem doing so. > 1) you use your ascii address to send the message privately to the user (K) > who can not receive it > 2)just ignore it and do nothing And there are plenty of other options, as shown above. One option that would be really nice is if the user's client would correlate the failure with that address and would warn the user the next time they try and send that person an EAI message. This sort of correlation is entirely doable given the structured response format defined in NOTARY, but to date I have yet to see a single solitary client actually do this sort of thing. > question 2) how 9 users(A B C D E F G H I) reply the message received? They also get a DSN. and have to cope with it. I currently have this happen to me about once a week when someone sends me a message with one or more invalid recipient addresses in the header. No EAI is necessary for this to happen. Sometimes I know what the correct address is, other times I do not. Sometimes I cannot even figure out which of the addresses the message is being sent to is failing, so I don't even know which address to remove when I reply the next time. I have no choice but to live with the DSNs in that case. > the problem is that user (K) is in the recipients list but never recieve the > message unless the sender forwards or resends the message privately to user > (K). Yup. And that's how email works right now. EAI changes nothing except to add another possible failure case. The experimental documents already explored the option of trying to mandate fallback addresses everywhere so that downgrading was possible in the transport infrastructure, which is the only way you can possibly address this failure in the EAI case. It failed. One of the unavoidable consequences of that failure is that EAI joins the long, long list of other sources of these issues. And there isn't a single solitary thing you can do about it. Your proposed DNS hackery cannot possibly address the issue, for the reasons I have already outlined. Again, some, but by no means all, of these issues can be mitigated to some extent by using a smarter client. But I'm very skeptical that the folks building clients will actually engage in any mitigation of these issues. They have never done so in the past, despite our providing them with every tool they need - NOTARY in particular - to make it possible. If this is coming as a late surprise to you I'm sorry, but it's been implicit in the approach we've taken from the get-go. Ned From johnl@iecc.com Tue Mar 6 08:25:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F0121F86A3 for ; Tue, 6 Mar 2012 08:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEI9CMQ2jB2w for ; Tue, 6 Mar 2012 08:25:53 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1032521F868A for ; Tue, 6 Mar 2012 08:25:52 -0800 (PST) Received: (qmail 38237 invoked from network); 6 Mar 2012 16:25:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Mar 2012 16:25:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f563a8f.xn--9vv.k1203; i=johnl@user.iecc.com; bh=Ii+0HkiAnrpZnF04YDBCkeQ0WWJ8sc/fp1P/Ir3BFNU=; b=hN5y7q39PbwlpmywHHuy0HKbNqEWbQEeb23YHAf72YF5lJFx+XBgfKEFzlSSD8sCSu/CO3INie7ftE29apCivSrefzjmrWl8417jW2j7iMx40J5ENscFjp8700aAm/F/qp7RQpYAOz+zNuKeuhz8yX8+0c1BZa3vs3xXJzgQqPs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f563a8f.xn--9vv.k1203; olt=johnl@user.iecc.com; bh=Ii+0HkiAnrpZnF04YDBCkeQ0WWJ8sc/fp1P/Ir3BFNU=; b=TI05ciyeDTYh2EwiTKPvEzw85Tmqtv/K3EChILdfjc0BculxM8MA1RYK0ic9MrVnNDcIcg+3M+w9SfxW3eo3U0Cpq2vZgZWYQLcY7mrHTDDL9xncGIsYfvjMeQovYZ0LYMGz0OZSneRBI+Z6f6r4QPZ52HS9iFOSTiwY9WsVd3o= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2012 16:25:29 -0000 Message-ID: <20120306162529.13566.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <01OCRX01EWDW00ZUIL@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:25:54 -0000 >As for caching EHLO repsonses, that actually makes me a little nervous. Caching >positive responses is fine but not particularly useful, caching negative ones >OTOH for any length of time risks the the possibility that the system will be >upgraded and messages will get bounced for no good reason. I was assuming you'd cache them for the TTL of the MX or A that points to it, not forever. R's, John From fanf2@hermes.cam.ac.uk Tue Mar 6 09:39:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C2721F85E1 for ; Tue, 6 Mar 2012 09:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUKe7aFfifB1 for ; Tue, 6 Mar 2012 09:39:45 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BA21F85D0 for ; Tue, 6 Mar 2012 09:39:44 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41904) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1S4yMN-0006Xo-X6 (Exim 4.72) (return-path ); Tue, 06 Mar 2012 17:39:39 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S4yMN-0000lR-7A (Exim 4.67) (return-path ); Tue, 06 Mar 2012 17:39:39 +0000 Date: Tue, 6 Mar 2012 17:39:39 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: ned+ima@mrochek.com In-Reply-To: <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> Message-ID: References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:39:46 -0000 ned+ima@mrochek.com wrote: > > And if you stick with the intersection approach, I don't think a list of domain > names packed into a single string is the way to do it. Multiple records > containing name fields fields are a better bet because they support > compression, and compression can make a big difference when there's lots of > repetition in the names, as seems likely. (I note in passing that you get this > for free with SRV.) While I very much agree with this, compression is not the reason: only RR types mentioned in RFC 1035 are subject to compression, and that doesn't include SRV. See RFC 3597 "Handling of Unknown DNS Resource Record (RR) Types". Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: North 5 or 6. Moderate or rough. Fair. Moderate or good. From fanf2@hermes.cam.ac.uk Tue Mar 6 10:46:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8764321F8525 for ; Tue, 6 Mar 2012 10:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7qLY5qsKPB3 for ; Tue, 6 Mar 2012 10:46:36 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 849A321F8518 for ; Tue, 6 Mar 2012 10:46:36 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46690) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1S4zP8-0006UC-G6 (Exim 4.72) (return-path ); Tue, 06 Mar 2012 18:46:35 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S4zP8-0003VV-VF (Exim 4.67) (return-path ); Tue, 06 Mar 2012 18:46:34 +0000 Date: Tue, 6 Mar 2012 18:46:34 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Jiankang YAO In-Reply-To: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> Message-ID: References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:46:37 -0000 I think this might be a little bit useful when receiving messages. My servers check the DNS for remote domains when receiving mail from them as a basic sanity check. It might be helpful when receiving mail from an EAI address to be able to perform a lightweight check that the domain's server is in fact internationalized. Tony. -- f.anthony.n.finch http://dotat.at/ Humber, Thames, Dover, Wight, Portland: Variable, becoming southwest, 3 or 4, increasing 6 to gale 8, perhaps severe gale 9 later in Dover and Thames, then veering northwest 5 to 7 later. Slight, becoming moderate or rough. Rain and drizzle for a time. Good, occasionally poor. From yaojk@cnnic.cn Tue Mar 6 20:00:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6C21E8019 for ; Tue, 6 Mar 2012 20:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.07 X-Spam-Level: X-Spam-Status: No, score=-100.07 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETUqOfYop3nQ for ; Tue, 6 Mar 2012 20:00:37 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2749221E8013 for ; Tue, 6 Mar 2012 20:00:35 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 07 Mar 2012 12:00:23 +0800 Message-ID: From: "Jiankang YAO" To: "Ned Freed" References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> <01OCRX01EWDW00ZUIL@mauve.mrochek.com> <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> <01OCSCT3AOYA00ZUIL@mauve.mrochek.com> Date: Wed, 7 Mar 2012 12:00:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 04:00:37 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk5lZCBGcmVlZCIgPG5lZC5m cmVlZEBtcm9jaGVrLmNvbT4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+DQpD YzogIk5lZCBGcmVlZCIgPG5lZC5mcmVlZEBtcm9jaGVrLmNvbT47IDxpbWFAaWV0Zi5vcmc+DQpT ZW50OiBUdWVzZGF5LCBNYXJjaCAwNiwgMjAxMiAxMTowOCBQTQ0KU3ViamVjdDogUmU6IFtFQUld IEZ3OiBJLUQgQWN0aW9uOiBkcmFmdC15YW8tZWFpLWRucy0wMC50eHQNCg0KDQo+IA0KPj4gLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4gRnJvbTogIk5lZCBGcmVlZCIgPG5lZC5mcmVl ZEBtcm9jaGVrLmNvbT4NCj4+IFRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+DQo+ PiBDYzogPGltYUBpZXRmLm9yZz4NCj4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDEyIDM6 MTggUE0NCj4+IFN1YmplY3Q6IFJlOiBbRUFJXSBGdzogSS1EIEFjdGlvbjogZHJhZnQteWFvLWVh aS1kbnMtMDAudHh0DQo+IA0KPiANCj4+ID4+IFRoYW5rcyBhIGxvdCBmb3IgIGFsbCBjb21tZW50 cyBmcm9tIHRoZSB3ZyBtZW1iZXJzLg0KPj4gPj4gSGVyZSBhcmUgc29tZSBjbGFyaWZpY2F0aW9u czoNCj4+ID4NCj4+ID4+IDEpIG15IGludGVudGlvbiBpcyB0byBoZWxwIHRoZSBkZXBsb3ltZW50 IG9mIGVhaSBwcm90b2NvbHMuDQo+PiA+PiAyKSBJbiBGZWIuIDIwMTIsIEkgdGFsa2VkIHdpdGgg bWFueSBlbWFpbCBzb2Z0d2FyZSBhbmQgc2VydmljZSBwcm92aWRlcnMgaW4gQ2hpbmEuICBzb21l IHNvZnR3YXJlIHByb3ZpZGVycyBpbiBDaGluYSBoYXZlIHByb21pc2VkIHRvIGltcGxlbWVudCBh bmQgZGVwbG95IHJmYzY1MzEgYW5kIHJmYzY1MzIuDQo+PiA+PiAzKSB0aGUgaWRlYSBpbiB0aGUg ZHJhZnQgd2FzIGRpc2N1c3NlZCBkdXJpbmcgRmViLiAyMDEyIHdoZW4gSSB0YWtsZWQgd2l0aCB0 aGVtLiBUaGV5IHRob3VnaHQgdGhhdCBzb21lIG1lY2hhbmlzbXMgd2l0aCBhbiBlYXJseSBpbmRp Y2F0b3Igb2Ygd2hldGhlciB0aGUgZGVzdGluYXRpb24gc2VydmVyIHN1cHBvcnQgU01UUFVURjgg d291bGQgaGVscCB0aGUgZGVwbG95bWVudCBvZiBSRkM2NTMxIGFuZCBSRkM2NTIgZHVyaW5nIHRo ZSBlYXJseSBkZXBsb3ltZW50IG9mIEVBSS4NCj4+ID4+IDQpIHRoaXMgZHJhZnQgaXMgbWFpbmx5 IGZvciBkaXNjdXNzaW9uIGFib3V0IGhvdyB3ZSBjYW4gaGVscCB0aGUgZGVwbG95bWVudCBvZiBF QUkuIElmIHRoZSBXRyB0aGlua3MgdGhhdCBpdCBpcyBub3QgZ29vZCBpZGVhLCB3ZSBjYW4ganVz dCBkaXNjYXJkIGl0Lg0KPj4gPj4gNSkgdGhlIHNjZW5hcmlvIHdoaWNoIHRoZSBlbWFpbCBzb2Z0 d2FyZSBvciBzZXJ2aWNlIHByb3ZpZGVycyB3b3VsZCBsaWtlIHRvIGFkZHJlc3MgaXMgdGhhdCBl YWkgdXNlcnMgc2VuZCB0aGUgZWFpIG1lc3NhZ2UgdG8gbWFueSB1c2VycyBpbmNsdWRpbmcgZWFp IHVzZXIgYW5kIGFzY2lpIHVzZXIuDQo+PiA+DQo+PiA+PiAgRm9yIGV4YW1wbGUsIGlmIGFuIGlu dGVybmF0aW9uYWxpemVkIG1lc3NhZ2UgaXMgc2VudCB0byAxMCB1c2VycyBvbmUgb2Ygd2hpY2gg aXMgYW4gQVNDSUkgdXNlciwgdGhlIE1TQSBtYXkgaGF2ZQ0KPj4gPj4gICAgdG8gc2F5IEVITE8g MTAgdGltZXMgYmVmb3JlIGRlY2lkaW5nIHRvIHJlamVjdCB0aGUgbWVzc2FnZS4NCj4+ID4NCj4+ ID4gU2F5IHdoYXQ/IEkgd291bGQgZXhwZWN0IGluIHRoaXMgY2FzZSBmb3IgdGhlIG1lc3NhZ2Ug dG8gYmUgZGVsaXZlcmVkIHRvIHRoZQ0KPj4gPiBmaXJzdCA5IHJlY2lwaWVudHMgYW5kIGZvciB0 aGUgMTB0aCB0byBnZW5lcmF0ZSBhIERTTi4gVGhhdCdzIHRoZSBvbmx5IHNlbnNpYmxlDQo+PiA+ IG91dGNvbWUNCj4+ID4NCj4gDQo+PiB0aGVyZSBpcyBhIHByb2JsZW0gaGVyZS4NCj4gDQo+IEkn bSBzb3JyeSwgYnV0IHRoZXJlIHJlYWxseSBpc24ndCAtIGF0IGxlYXN0IHRoZXJlJ3Mgbm8gbmV3 IHByb2JsZW0gdGhhdCB1c2Vycw0KPiBkb24ndCBhbHJlYWR5IGZhY2UgYWxsIG9uIGEgcmVndWxh ciBiYXNpcy4NCj4gDQo+PiBXaGVuIHlvdSBzZW5kIGEgbWVzc2FnZSB0byAxMCB1c2VycywgOSB1 c2VycyhBIEIgQyBEIEUgRiBHIEggSSkgcmVjaWV2ZSB0aGUNCj4+IG1lc3NhZ2UuIDEgdXNlciAo SykgY2FuIG5vdCByZWNlaXZlIGl0Lg0KPiANCj4+IHF1ZXN0aW9uIDEgKSB3aGF0IGlzIHlvdXIg bmV4dCBzdGVwIHRvIGRlYWwgd2l0aCB0aGUgdXNlciB3aG8gY2FuIG5vdCByZWNlaXZlDQo+PiBp dD8NCj4gDQo+IFRoZSBzYW1lIGFzIHdoYXRldmVyIHlvdSBkbyB3aGVuIG9uZSBvZiB0aGUgdXNl cnMgeW91IHNlbnQgdG8gY2FuJ3QgcmVjZWl2ZQ0KPiB5b3VyIG1haWwgbm93OiBSZWRvIHlvdXIg bWVzc2FnZSwgc28gaXQncyBhY2NlcHRhYmxlLCBjYWxsIHRoZW0gb24gdGhlIHBob25lLA0KPiBJ TSB0aGVtLCBpZ25vcmUgdGhlIHByb2JsZW0sIHdoYXRldmVyLiBUaGlzIGhhcHBlbnMgKmFsbCog KnRoZSogKnRpbWUqLCBhbmQNCj4gd2hlbiwgc2F5LCB5b3VyIG1lc3NhZ2UgaXMgbGFyZ2VyIHRo YW4gdGhlIGxpbWl0IHRoYXQgc2l0ZSBhY2NlcHRzLCB0aGUNCj4gY29uZGl0aW9uIG1heSBiZSBl dmVyeSBiaXQgYXMgcGVybWFuZW50IGFzIGlmIHlvdSB0cmllZCB0byBzZW5kIHRoZW0gYW4gRUFJ DQo+IG1haWwgYW5kIHRoZXkgZG9uJ3Qgc3VwcG9ydCB0aGF0Lg0KPiANCj4gVGhpcyBpcyBoYXMg YWx3YXlzIGJlZW4gaG93IGVtYWlsIGhhcyB3b3JrZWQuIFVzZXJzIGhhdmUgYmVlbiBjb3Bpbmcg d2l0aCBpdA0KPiBmb3IgZGVjYWRlcy4gVGhleSBkb24ndCBzZWVtIHRvIGhhdmUgYSBwcm9ibGVt IGRvaW5nIHNvLg0KPiANCg0KSSB0aGluayB0aGF0IHRoZXJlIGhhcyBhIGxpdHRsZSBkaWZmZXJl bmNlIGhlcmUuDQoNCkluIHRoZSBwdXJlIEFTQ0lJIGVtYWlsIHdvcmxkLCBzb21lIHVzZXJzIGlu IHRoZSByZWNpcGllbnRzIGxpc3QgbWF5IGxvc3QgdGhlIG1haWwgZHVlIHRvIG9uZSBvciBhbm90 aGVyIHJlYXNvbi4gYnV0IGFmdGVyIGFkanVzdGluZyBzb21ldGhpbmcsDQp0aGV5IGhhdmUgYSBi aWcgY2hhbmNlIHRvIHJlY2VpdmUgdGhlIG1lc3NhZ2UuIFNvIGluIHRoZSBtb3N0IGNhc2VzLCB0 aGUgbWVzc2FnZSBsb3NpbmcgaXMgdGVtcG9yYXJ5Lg0KDQp3aGVuIEVBSSBlbWFpbCB3b3JkIGlu dGVyYWN0cyB3aXRoIHRoZSBBU0NJSSBlbWFpbCB3b3JsZCwgc29tZSB1c2VycyBpbiB0aGUgcmVj aXBpZW50cyBsaXN0IG1heSBuZXZlciByZWNlaXZlIHRoZSBtYWlsIHNlbnQgdG8gdGhlbS4NCg0K SSB0aGluayB0aGF0IG1vc3QgdXNlcnMgY2FuIGJlYXIgdGhlIHRlbXBvcmFyeSBmYWlsdXJlIG9m IG1lc3NhZ2UgZGVsaXZlcnksIGJ1dCBpcyB1bmxpa2VseSB0byBiZWFyIHRoZSBwZXJtYW5lbnQg ZmFpbHVyZSBvZiBtZXNzYWdlIGRlbGl2ZXJ5Lg0KDQoNCkppYW5rYW5nIFlhbw0KDQoNCg0K From ned+ima@mrochek.com Tue Mar 6 20:09:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9921F8596 for ; Tue, 6 Mar 2012 20:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpcmd1b6mvFd for ; Tue, 6 Mar 2012 20:09:22 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C835821F8595 for ; Tue, 6 Mar 2012 20:09:21 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCT3CKTXKG00Y7CF@mauve.mrochek.com> for ima@ietf.org; Tue, 6 Mar 2012 20:09:18 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 6 Mar 2012 20:09:12 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCT3CHIPKS00ZUIL@mauve.mrochek.com> Date: Tue, 06 Mar 2012 19:29:02 -0800 (PST) In-reply-to: "Your message dated Tue, 06 Mar 2012 05:04:37 -0500" <06F0D344C5C7C66943B4688F@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> <20120306032955.GN76465@crankycanuck.ca> <01OCRT8AX3NG00ZUIL@mauve.mrochek.com> <06F0D344C5C7C66943B4688F@PST.JCK.COM> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331093367; bh=dWJdeGOoSriLAlsu7ywmHvJUdgDdsOamry8KTJ//SHk=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Yl9QbZzMZAXP9+3vq6F7S05RbdC9tXYxHwuu7vqoYtAI1DFN2UkwSAgJ+NgrtY4iC +ovkuye0ozPhJWohBPxoDyzUmNWp9MLo568VmP9FgLjvzYRhSv37hJMFGZE6AewjYy m+eEz0WUKahsZ0a3K1aNvkluWhdloe9fKUMdYwTM= Cc: ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 04:09:23 -0000 (This is almost entirely off topic for EAI, but I think increased awareness of the work I'm going to describe would be good, so I'm going to post this one last reply to the EAI list.) > FWIW, if I were responsible for significant DNS server software > or designing new RRTYPEs, and were serious about making new > RRTYPEs easy to deploy, I'd skip fairy tales like "you can > easily recompile" in favor of thinking through the question of > what would constitute a minimal description language for RRTYPEs > that could be interpreted This is exactly what John Levine is attempting to do in draft-levine-dnsextlang-02.txt. He went through the entire list of previously defined RRTYPEs to come up with a list of all the binary data formats and their associated presentation format in standard zone files that are used in DNS records. He ignored the ones that have complex interactions with the server itself, e.g., the ones associated with DNSSEC. It turns out the list is actually pretty short: integers (1, 2, or 4 bytes), IPv4 and IPv6 addresses, domain names (compressed or uncompressed, qualified by whether or not the server should fetch associated A records), stirngs (short, long, multiple), base64 (counted or uncounted), and hex. That's it. He then devised a very simple language for describing this that can be used to define new records. There's also a way to add new types, if that's ever necessary. This language could be used by servers to extend them to handle new record types without the need for any upgrades. It can even be consumed by web interfaces and used to build web forms automatically. IMO this would address at least some of the issues involved in getting new records deployed. There is often a HUGE difference in doing upgrades versus adding an entry to a configuration file. Mind you, it's not going to address the more draconian corporate policies, but at least it can help get us past the "we're not upgrading on your schedule" thing. In fact it was the huge collective yawn from I heard multiple DNSop folks this proposal received that spurred me into my earlier rant. No, this doesn't solve every problem. But it's a step in the right direction. > (if it needed to be more complex than > LR(0), I'd suggest we are in serious trouble) such that while > known (older) RRTYPEs could be optimized into code, new ones > could be tested and added with an absolutely minimal risk of bad > consequences to anything else by adding a new rule to an > interpreted table (or a new table to a set). Exactly the intent here. I suggested adding a type that would allow either an IPv4 or an IPv6 address; John Levine pushed back on it, saying that no existing type uses such a mechanism and he wants to limit this to tried and true data and presentation formats, in part to be able to make a legitimate claim to minimal risk. > If the server code > then shipped with configuration options to either locate the > table(s) or disable lookup and interpretation for new RRTYPEs, > we'd be having a rather different discussion, IMO. Such > interpretative rules are not rocket science and would overcome > most (although definitely not all) of the practical objections > to "just deploy a new RRTYPE" that Ned, myself, and others are > raising. *exactly* > But while it seems obvious, no one seems to want to do that. > Possibly computing the amount of thrust needed to get a pig > airborne is more interesting :-( That's exactly the problem - we have yet to convince people of the value of this sort of scheme. (I actually think the biggest problem with it is that we didn't do it 15 years ago.) Anyway, if people think this is a good idea, they need to speak up on the main IETF list. And preferably review the draft and comment. Ned From ned+ima@mrochek.com Tue Mar 6 22:07:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADC121E8048 for ; Tue, 6 Mar 2012 22:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6t-ts8g4MfK for ; Tue, 6 Mar 2012 22:07:38 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7256121E8036 for ; Tue, 6 Mar 2012 22:07:38 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCT7H7GLLS00Y7JJ@mauve.mrochek.com> for ima@ietf.org; Tue, 6 Mar 2012 22:07:34 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 6 Mar 2012 22:07:29 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCT7H4SK0800ZUIL@mauve.mrochek.com> Date: Tue, 06 Mar 2012 21:45:46 -0800 (PST) In-reply-to: "Your message dated Wed, 07 Mar 2012 12:00:23 +0800" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120306011318.80679.qmail@joyce.lan> <11D606EFFCDE4AC7BB32163BF83C9ECC@LENOVO47E041CF> <01OCRX01EWDW00ZUIL@mauve.mrochek.com> <29FF3B1066964846B8A2032EC2888F56@LENOVO47E041CF> <01OCSCT3AOYA00ZUIL@mauve.mrochek.com> To: Jiankang YAO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331100463; bh=7G39+zt+iYX05Kicn2Lbuo7t4tcpjJw8C8ymUJLfZ4w=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=YGV5qoGjvic0WSio4XEF7w8Yt3YRTAzz42WpqX1kw6wErvK7sm09gHIXvkN30zktS wseZvKFDU6WmMD5Tz62S5/KTtV/s9rdXV8+dYXJu3x3pp5QyCoMuyjQ2pL5Ue60wct 562e6LXRuh/tcWVBzMoBW+aMuona4pp59+fOoeIo= Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 06:07:39 -0000 > I think that there has a little difference here. There is, but it's the opposite of what you think. > In the pure ASCII email world, We left pure ASCII behind 20 years ago. Calling it that misstates the situation substantially. > some users in the recipients list may lost the > mail due to one or another reason. but after adjusting something, they have > a big chance to receive the message. Depends on what the problem is. As a practical matter, these days the most likely cause of mail rejection is incorrect labelling as spam, and a common cause for that is improper blacklisting of the sender's mail server. Such blacklisting is usually something the sender can do nothing about. And there are plenty of other reasons, such as the recipient being over quota, that the sender can do nothing about. In fact these days I rarely get DSNs for conditions I have any option of fixing. > So in the most cases, the message losing is temporary. Sorry, that's simply incorrect. > when EAI email word interacts with the ASCII email world, some users in the > recipients list may never receive the mail sent to them. Actually, in this case the sender has the option of sending a non-EAI message to that recipient. MIME gives them almost every capability they need except for being able to include EAI recipients in that message. They certainly aren't forced to use ASCII. We solved that problem 20 years ago. So this is actually the temporary case. And let's review the steps: The sender sends an EAI message to 10 people, one of them bounces with a clear indication of why and no confusing list of other recipients to sort through, they now construct a non-EAI message for that one recipient, done. But let's assume for the moment that were were actually able to implement your proposed solution of rejecting all recipients. (We cannot possibly do that, but let's suppose.) Now what? The sender is actually left in a much worse place. They send a message to 10 recipients, they get back an error that they have to read very, very carefully in order to figure out what to do next. (In my experience the chances of most users doing this are nil.) Now the sender either has to one version of the message to the 9 EAI recipients, which in many UI is a major pain, and send another to the remaining recipient. This is exactly the same result they would have gotten from how things are defined to work now, except the sender and not the system had to do all the work. The alternative is to try and figure out non-EAI addresses for the 9 others, which may well be impossible, in order to send a non-EAI message to all 10. This is far beyond the capacity of most people to do. > I think that most users can bear the temporary failure of message delivery, > but is unlikely to bear the permanent failure of message delivery. That's not really true, but if it were you've just excluded your own proposal from consideration. Ned From fanf2@hermes.cam.ac.uk Wed Mar 7 05:53:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E5C21F87D1 for ; Wed, 7 Mar 2012 05:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4wK+-96kMBl for ; Wed, 7 Mar 2012 05:53:12 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7D22521F87C6 for ; Wed, 7 Mar 2012 05:53:12 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48478) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1S5HIc-0000ci-Rq (Exim 4.72) (return-path ); Wed, 07 Mar 2012 13:53:02 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S5HIc-0003XK-I6 (Exim 4.67) (return-path ); Wed, 07 Mar 2012 13:53:02 +0000 Date: Wed, 7 Mar 2012 13:53:02 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: ned+ima@mrochek.com In-Reply-To: <01OCT3CHIPKS00ZUIL@mauve.mrochek.com> Message-ID: References: <79CB91401EEC406EB118EC9A017905BF@LENOVO47E041CF> <01OCQDKVL2ZQ00ZUIL@mauve.mrochek.com> <20120306032955.GN76465@crankycanuck.ca> <01OCRT8AX3NG00ZUIL@mauve.mrochek.com> <06F0D344C5C7C66943B4688F@PST.JCK.COM> <01OCT3CHIPKS00ZUIL@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 13:53:13 -0000 ned+ima@mrochek.com wrote: > (This is almost entirely off topic for EAI, but I think increased awareness of > the work I'm going to describe would be good, so I'm going to post this one > last reply to the EAI list.) ... snipped ... I've been talking to John Levine about this. I have a concrete application in mind which is a web <-> DNS UPDATE gateway ... > This is exactly what John Levine is attempting to do in > draft-levine-dnsextlang-02.txt. He went through the entire list of > previously defined RRTYPEs to come up with a list of all the binary data > formats and their associated presentation format in standard zone files > that are used in DNS records. [...] It turns out the list is actually > pretty short: integers (1, 2, or 4 bytes), IPv4 and IPv6 addresses, > domain names (compressed or uncompressed, qualified by whether or not > the server should fetch associated A records), stirngs (short, long, > multiple), base64 (counted or uncounted), and hex. That's it. Sadly there are a few RR types which are a bit more complicated, and not all of them can be ignored. LOC, APL, IPSECKEY, HIP. I would quite like to be able to use John's language to be able to translate back and forth between wire format and master file format for all RR types including the baroque DNSSEC ones - though that will need some type-specific code - as well as being able to auto-generate a user interface for the simple cases and future types. > Exactly the intent here. I suggested adding a type that would allow either an > IPv4 or an IPv6 address; John Levine pushed back on it, saying that no existing > type uses such a mechanism and he wants to limit this to tried and true data > and presentation formats, in part to be able to make a legitimate claim to > minimal risk. IPSECKEY RRs are a counterexample. Really it should have been three RR types, sigh. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth, Tyne, West Dogger: Westerly 5 to 7, perhaps gale 8 later in Cromarty. Moderate or rough, occasionally very rough in Forties. Wintry showers. Good. From klensin@jck.com Wed Mar 7 11:59:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6804521E8017 for ; Wed, 7 Mar 2012 11:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwpqAa-Um3Tz for ; Wed, 7 Mar 2012 11:59:16 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7715711E8097 for ; Wed, 7 Mar 2012 11:59:16 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5MwS-0008T0-V3; Wed, 07 Mar 2012 14:54:32 -0500 Date: Wed, 07 Mar 2012 14:59:04 -0500 From: John C Klensin To: Tony Finch , ned+ima@mrochek.com Message-ID: <9398EB240E232C9A424DD5DA@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] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:59:17 -0000 Hi. As Ned and others have suggested, let's move this discussion to the IETF list, where the real action on the subject is occurring (I know I haven't posted there yet, but that is temporary :-) ). An observation or two inline below... --On Wednesday, March 07, 2012 13:53 +0000 Tony Finch wrote: >... > Sadly there are a few RR types which are a bit more > complicated, and not all of them can be ignored. LOC, APL, > IPSECKEY, HIP. The model I had in mind was quite different from what John came up with, largely because I was looking for an abstraction that could accommodate any plausible future type while John based his approach on examination of existing types and extrapolating. Inserting one of the usual observations about the difference between theory and practice here, John's approach is probably better. But I think we should recognize that such a description language could also be immensely useful as a brake on complexity: if we have a language that covers all of the reasonable cases, then, if someone comes along with something so complex that it cannot reasonably be described, then those who propose it have to accept the costs of slow deployment. I rather like that tradeoff as an element of the design process. > I would quite like to be able to use John's language to be > able to translate back and forth between wire format and > master file format for all RR types including the baroque > DNSSEC ones - though that will need some type-specific code - > as well as being able to auto-generate a user interface for > the simple cases and future types. Seems like a good idea in principle but the best may be the enemy of the good. Remember that, for any of this to be useful in solving the "slow deployment" problem, people have to be willing to install/ deploy a DNS software package version that incorporates John's language and the needed interpreter. The experiences Ned and I have been talking about don't suggest that will be easy. For the subset of cases in which the question is "what will this do for me and what might it do to me", I'd much rather be able to explain it in terms of affecting new RRTYPEs and only new RRTYPEs, rather than changing how existing types are handled in the code. In many cases, it will make no difference and we will just need to wait. However, in others, contained risk is a fairly powerful argument that we should not give up lightly. >> Exactly the intent here. I suggested adding a type that would >> allow either an IPv4 or an IPv6 address; John Levine pushed >> back on it, saying that no existing type uses such a >> mechanism and he wants to limit this to tried and true data >> and presentation formats, in part to be able to make a >> legitimate claim to minimal risk. > > IPSECKEY RRs are a counterexample. Really it should have been > three RR types, sigh. And, while there are arguments against using multiple interlaced RR types for the same general function (I'll leave explanations to others, probably on the IETF list), that case may sort of prove my argument for a slightly less rich description language that makes it easier to identify and push back on complexity. john From sm@resistor.net Wed Mar 7 12:41:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDFF21F86BB for ; Wed, 7 Mar 2012 12:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfWD1jkN-d6s for ; Wed, 7 Mar 2012 12:41:54 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BADE21F86BA for ; Wed, 7 Mar 2012 12:41:53 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q27Kfi1B002064; Wed, 7 Mar 2012 12:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331152909; i=@resistor.net; bh=jU5P3+zvfc/xMbutXr4H8z+lwzXUq5CA/Ref4DPrilk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=FaS/H9hmO+yA9gd4g2Z5EVXv0g/edbVrU0kCHuPl72ciVhf+6LvbkcLsLBAODjhWR HGdQKd5Q1Gy3DIlbxfHJfyS0Da+tPEgVFuuklQgrXm+1rz5J+91j+WjnS8+wMDiCJa HkQZ67qO1FWRUBsH7AneNEMot8jcnhyhTMzcp08Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331152909; i=@resistor.net; bh=jU5P3+zvfc/xMbutXr4H8z+lwzXUq5CA/Ref4DPrilk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=bZ8UF4FPGqYv3EdxN0v+8TTmRY+sSc+1dEUgYLDHamBK9R7Ot9RVoztHBRtRyPuK4 M0RwvUAvycirbX6TGc7ic5GSfwHGYXQ9WzXVW4Xeo4JmFW6prHd9lKkJaEFMqvvawe ubD+fzpFHMJ3AqSR2aVHJ/uINNGz9FTm9UtFx8IQ= Message-Id: <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Mar 2012 12:20:33 -0800 To: John C Klensin From: SM In-Reply-To: <9398EB240E232C9A424DD5DA@PST.JCK.COM> References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:41:59 -0000 Hi John, At 11:59 07-03-2012, John C Klensin wrote: >As Ned and others have suggested, let's move this discussion to >the IETF list, where the real action on the subject is occurring >(I know I haven't posted there yet, but that is temporary :-) ). I am not optimistic about whether there will be a meaningful conclusion to the real action. >Seems like a good idea in principle but the best may be the >enemy of the good. Remember that, for any of this to be useful >in solving the "slow deployment" problem, people have to be >willing to install/ deploy a DNS software package version that >incorporates John's language and the needed interpreter. The There will be a "slow deployment" problem in deploying the solution to the "slow deployment" problem. :-) BTW, there has been discussions about this topic on four IETF mailing lists. Regards, -sm From klensin@jck.com Wed Mar 7 15:17:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F4A11E8088 for ; Wed, 7 Mar 2012 15:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9VeLcZSileT for ; Wed, 7 Mar 2012 15:17:44 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 22A6D11E8072 for ; Wed, 7 Mar 2012 15:17:44 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5Q2c-0008gx-Ib; Wed, 07 Mar 2012 18:13:06 -0500 Date: Wed, 07 Mar 2012 18:17:37 -0500 From: John C Klensin To: SM Message-ID: <594BEBB58EF0FA808925B0C7@PST.JCK.COM> In-Reply-To: <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> <6.2.5.6.2.20120307120952.0a0b5f70@resistor.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] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:17:44 -0000 --On Wednesday, March 07, 2012 12:20 -0800 SM wrote: > Hi John, > At 11:59 07-03-2012, John C Klensin wrote: >> As Ned and others have suggested, let's move this discussion >> to the IETF list, where the real action on the subject is >> occurring (I know I haven't posted there yet, but that is >> temporary :-) ). > > I am not optimistic about whether there will be a meaningful > conclusion to the real action. I'm not either. If a meaningful conclusion required IETF consensus, I would be even less optimistic. However, getting the contrast between strategies and a well-thought-out alternative on the table has benefits in itself. Perhaps equally important, if one adopts a lightweight view of the description language and interpreter issue (rather than the more comprehensive approach that Tony suggested), no standardization would be required because whether a new type is implemented by table or code modification and recompilation or by putting a rule into a configuration file is an implementation detail that does not change the RRTYPE itself. It would take changes to a _very_ small number of implementations to make the interpretation model available to a rather large fraction of the servers on the Internet. Now it wouldn't take many of the people to whose attitude several of us have been objecting to prevent those implementations from happening, but that is a rather different problem. >> Seems like a good idea in principle but the best may be the >> enemy of the good. Remember that, for any of this to be >> useful in solving the "slow deployment" problem, people have >> to be willing to install/ deploy a DNS software package >> version that incorporates John's language and the needed >> interpreter. The > > There will be a "slow deployment" problem in deploying the > solution to the "slow deployment" problem. :-) Sure. But that solution needs to be deployed only once, rather than once per time someone proposes a new RRTYPE. > BTW, there has > been discussions about this topic on four IETF mailing lists. Yes. And so? best, john From sm@resistor.net Wed Mar 7 16:20:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F49711E8094 for ; Wed, 7 Mar 2012 16:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N39ESaP04GIx for ; Wed, 7 Mar 2012 16:20:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB6B11E8072 for ; Wed, 7 Mar 2012 16:20:17 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q280K9Z3003563; Wed, 7 Mar 2012 16:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331166017; i=@resistor.net; bh=bj2KwwqyV4klyIwWLNQxaGlC6orTC5QKLrGCLyug3Pg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ZM74VwbwbKlwTWZ/VNOj4wtQvkenSphDV4uyOEfpWJr5EWDHxcANxnovJZcf4Nb/X zYhVx3ifQVGSH7Sc54/T4Aa81DfYMEyAD397Y185wrdsVtbCH9UaBkybD9N5byPbKl /6K1qtbvluneaT05MvNLV/n73p7mhf+6Efvz7GFk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331166017; i=@resistor.net; bh=bj2KwwqyV4klyIwWLNQxaGlC6orTC5QKLrGCLyug3Pg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Ux0NwMqFTdaYIfraW02eRC2Aguz634Kp+nhYFqn2I84rSFHABmUS7aHAUhiy4iXfK GhSo7e+haRQgJOaJH78APXNmFEObWUKaKhMmjBzN6NuMJREvG5mHBXS8FZOLj34Kp1 zc2hwfJkS4xG8vpZaThN5f3o0EB2eqeqV0SGwIyg= Message-Id: <6.2.5.6.2.20120307155330.094efb40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Mar 2012 16:19:15 -0800 To: John C Klensin From: SM In-Reply-To: <594BEBB58EF0FA808925B0C7@PST.JCK.COM> References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> <594BEBB58EF0FA808925B0C7@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:20:21 -0000 Hi John, At 15:17 07-03-2012, John C Klensin wrote: >I'm not either. If a meaningful conclusion required IETF >consensus, I would be even less optimistic. However, getting >the contrast between strategies and a well-thought-out >alternative on the table has benefits in itself. Perhaps It might help if there was a draft discussing about the different strategies. >equally important, if one adopts a lightweight view of the >description language and interpreter issue (rather than the more >comprehensive approach that Tony suggested), no standardization >would be required because whether a new type is implemented by >table or code modification and recompilation or by putting a >rule into a configuration file is an implementation detail that There is an argument for having it as a rule in a configuration file instead of hard coding. >does not change the RRTYPE itself. It would take changes to a >_very_ small number of implementations to make the >interpretation model available to a rather large fraction of the >servers on the Internet. Now it wouldn't take many of the >people to whose attitude several of us have been objecting to >prevent those implementations from happening, but that is a >rather different problem. It is going to take years for the changes to find its way into the servers out there. However, if we do not start somewhere, it is improbable that things will change. At the end of the day, it is about providing the incentive to make it happen. >Yes. And so? It's unusual to see the same topic discussed on several mailing lists at the same time when it is not a cross-post. Regards, -sm From fanf2@hermes.cam.ac.uk Thu Mar 8 03:52:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD721F869E for ; Thu, 8 Mar 2012 03:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3TOJToFmxvN for ; Thu, 8 Mar 2012 03:52:30 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4538A21F8699 for ; Thu, 8 Mar 2012 03:52:30 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45601) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1S5btC-0002OF-SE (Exim 4.72) (return-path ); Thu, 08 Mar 2012 11:52:10 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S5btC-0008U9-M8 (Exim 4.67) (return-path ); Thu, 08 Mar 2012 11:52:10 +0000 Date: Thu, 8 Mar 2012 11:52:10 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John C Klensin In-Reply-To: <9398EB240E232C9A424DD5DA@PST.JCK.COM> Message-ID: References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: John Levine , ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:52:31 -0000 John C Klensin wrote: > > But I think we should recognize that such a description language > could also be immensely useful as a brake on complexity: if we > have a language that covers all of the reasonable cases, then, > if someone comes along with something so complex that it cannot > reasonably be described, then those who propose it have to > accept the costs of slow deployment. I rather like that > tradeoff as an element of the design process. I very much agree! > > I would quite like to be able to use John's language to be > > able to translate back and forth between wire format and > > master file format for all RR types including the baroque > > DNSSEC ones - though that will need some type-specific code - > > as well as being able to auto-generate a user interface for > > the simple cases and future types. > > Seems like a good idea in principle but the best may be the > enemy of the good. Remember that, for any of this to be useful > in solving the "slow deployment" problem, people have to be > willing to install/ deploy a DNS software package version that > incorporates John's language and the needed interpreter. The > experiences Ned and I have been talking about don't suggest that > will be easy. For the subset of cases in which the question is > "what will this do for me and what might it do to me", I'd much > rather be able to explain it in terms of affecting new RRTYPEs > and only new RRTYPEs, rather than changing how existing types > are handled in the code. In many cases, it will make no > difference and we will just need to wait. However, in others, > contained risk is a fairly powerful argument that we should not > give up lightly. I think you are right. > > IPSECKEY RRs are a counterexample. Really it should have been > > three RR types, sigh. > > And, while there are arguments against using multiple interlaced > RR types for the same general function (I'll leave explanations > to others, probably on the IETF list), that case may sort of > prove my argument for a slightly less rich description language > that makes it easier to identify and push back on complexity. I'll just mention A and AAAA :-) Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet, Irish Sea: West backing southwest 4 or 5, increasing 6 at times. Very rough or high in Sole and southwest Fastnet, otherwise moderate or rough. Fair then occasional rain or drizzle. Moderate or good. From klensin@jck.com Thu Mar 8 04:03:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A992121F86E3 for ; Thu, 8 Mar 2012 04:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3aR94TpnTCe for ; Thu, 8 Mar 2012 04:03:28 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3621F86E2 for ; Thu, 8 Mar 2012 04:03:28 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5bzd-000ANu-Gp; Thu, 08 Mar 2012 06:58:49 -0500 Date: Thu, 08 Mar 2012 07:03:22 -0500 From: John C Klensin To: SM Message-ID: In-Reply-To: <6.2.5.6.2.20120307155330.094efb40@resistor.net> References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> <594BEBB58EF0FA808925B0C7@PST.JCK.COM> <6.2.5.6.2.20120307155330.094efb40@resistor.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] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:03:28 -0000 --On Wednesday, March 07, 2012 16:19 -0800 SM wrote: > Hi John, > At 15:17 07-03-2012, John C Klensin wrote: >> I'm not either. If a meaningful conclusion required IETF >> consensus, I would be even less optimistic. However, getting >> the contrast between strategies and a well-thought-out >> alternative on the table has benefits in itself. Perhaps > > It might help if there was a draft discussing about the > different strategies. Maybe. I don't have time to do anything about that. I believe that substantially all of the issues and strategies have been described in notes to this list in the last week or two. If someone wanted to draw those comments together into an I-D, I think all of us who have contributed perspectives would be happy with lavish acknowledgments :-) I personally suspect that this problem is going to get solved, if at all, by an implementation or two taking the initiative, producing running code, and thereby putting competitive pressure on the other implementations to do something. >> equally important, if one adopts a lightweight view of the >> description language and interpreter issue (rather than the >> more comprehensive approach that Tony suggested), no >> standardization would be required because whether a new type >> is implemented by table or code modification and >> recompilation or by putting a rule into a configuration file >> is an implementation detail that > There is an argument for having it as a rule in a > configuration file instead of hard coding. Yes. And that argument has now been made several times on this list alone. See above. >> does not change the RRTYPE itself. It would take changes to a >> _very_ small number of implementations to make the >> interpretation model available to a rather large fraction of >> the servers on the Internet. Now it wouldn't take many of the >> people to whose attitude several of us have been objecting to >> prevent those implementations from happening, but that is a >> rather different problem. > It is going to take years for the changes to find its way into > the servers out there. However, if we do not start somewhere, > it is improbable that things will change. At the end of the > day, it is about providing the incentive to make it happen. Any decision to deploy a new version of DNS server software (like just about anything else) is either made as a side-effect of operating system software upgrades (i.e., without the DNS changes being the major consideration) or is made by considering the tradeoffs between incentive (benefits), disruption risk, and costs and other priorities. In that context, some of the comments Ned and I have been making amount to organization perceptions that the risks of disruption are a cost and the costs and risk of cost are perceived as huge. Thinking about that as incentive alone is a sort of "if you build it, they will come" argument, which rarely works in practice. The balance is especially relevant, and likely to be especially unfavorable, if the driver is a handful of RRTYPEs that are relevant only to a few sub-applications, especially if those sub-applications are as disliked in some quarters as they are favored in others (SPF is a perfect example of that part of the problem). >> Yes. And so? > > It's unusual to see the same topic discussed on several > mailing lists at the same time when it is not a cross-post. Yes. Under normal circumstances, it would be the job of some responsible AD to notice that and try to draw things together, perhaps by organizing the I-D that is hypothesized above. I haven't noticed that happening, but perhaps that identifies where the point should be made. john From fanf2@hermes.cam.ac.uk Thu Mar 8 04:07:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8116921F86E5 for ; Thu, 8 Mar 2012 04:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoU4Qj317NwV for ; Thu, 8 Mar 2012 04:07:51 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id DA91721F86E4 for ; Thu, 8 Mar 2012 04:07:50 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42092) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1S5c8L-0006WR-R7 (Exim 4.72) (return-path ); Thu, 08 Mar 2012 12:07:49 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S5c8L-0002zA-Bj (Exim 4.67) (return-path ); Thu, 08 Mar 2012 12:07:49 +0000 Date: Thu, 8 Mar 2012 12:07:49 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John C Klensin In-Reply-To: <594BEBB58EF0FA808925B0C7@PST.JCK.COM> Message-ID: References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> <594BEBB58EF0FA808925B0C7@PST.JCK.COM> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:07:51 -0000 John C Klensin wrote: > Perhaps equally important, if one adopts a lightweight view of the > description language and interpreter issue (rather than the more > comprehensive approach that Tony suggested), no standardization would be > required because whether a new type is implemented by table or code > modification and recompilation or by putting a rule into a configuration > file is an implementation detail that does not change the RRTYPE itself. > It would take changes to a _very_ small number of implementations to > make the interpretation model available to a rather large fraction of > the servers on the Internet. It's the user interfaces that need better support for new RR types much more than the servers. Tony. -- f.anthony.n.finch http://dotat.at/ South Biscay: Easterly or northeasterly 3 or 4, increasing 5 or 6 in southwest. Rough or very rough. Fair. Good. From klensin@jck.com Thu Mar 8 04:20:03 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24E21F84B6 for ; Thu, 8 Mar 2012 04:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bidkyedKd7Ie for ; Thu, 8 Mar 2012 04:20:03 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EE8AA21F84AE for ; Thu, 8 Mar 2012 04:20:02 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5cFe-000AP9-JS; Thu, 08 Mar 2012 07:15:22 -0500 Date: Thu, 08 Mar 2012 07:19:55 -0500 From: John C Klensin To: Tony Finch Message-ID: <8127B38D7EA84CB3A2C80585@PST.JCK.COM> In-Reply-To: References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> <594BEBB58EF0FA808925B0C7@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] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:20:03 -0000 --On Thursday, March 08, 2012 12:07 +0000 Tony Finch wrote: > John C Klensin wrote: > >> Perhaps equally important, if one adopts a lightweight view >> of the description language and interpreter issue (rather >> than the more comprehensive approach that Tony suggested), no >> standardization would be required because whether a new type >> is implemented by table or code modification and >> recompilation or by putting a rule into a configuration file >> is an implementation detail that does not change the RRTYPE >> itself. It would take changes to a _very_ small number of >> implementations to make the interpretation model available to >> a rather large fraction of the servers on the Internet. > > It's the user interfaces that need better support for new RR > types much more than the servers. Absolutely. But it is hard to think about how to change the user interfaces without the server support. At the risk of starting another subthread, note the difference between this and ICANN's plans to deploy hundreds (or more) new TLDs in the relatively near future. Whatever the UIs decide to do about them (checking, display, adjustment to DNS completion,...) there is no evidence yet that any DNS server changes are needed. However one intends to support new RRTYPEs, it is going to require DNS server changes to either code those in, compile them in, or interpret them from tables. So, on a critical path basis,... john From fanf2@hermes.cam.ac.uk Thu Mar 8 04:51:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B53221F86DE for ; Thu, 8 Mar 2012 04:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysgmVGlkFaVk for ; Thu, 8 Mar 2012 04:51:14 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD3F21F86C7 for ; Thu, 8 Mar 2012 04:51:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45617) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1S5coC-0002p9-Qo (Exim 4.72) (return-path ); Thu, 08 Mar 2012 12:51:04 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S5coC-000276-7W (Exim 4.67) (return-path ); Thu, 08 Mar 2012 12:51:04 +0000 Date: Thu, 8 Mar 2012 12:51:04 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John C Klensin In-Reply-To: <8127B38D7EA84CB3A2C80585@PST.JCK.COM> Message-ID: References: <9398EB240E232C9A424DD5DA@PST.JCK.COM> <6.2.5.6.2.20120307120952.0a0b5f70@resistor.net> <594BEBB58EF0FA808925B0C7@PST.JCK.COM> <8127B38D7EA84CB3A2C80585@PST.JCK.COM> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ima@ietf.org Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:51:16 -0000 John C Klensin wrote: > > It's the user interfaces that need better support for new RR > > types much more than the servers. > > Absolutely. But it is hard to think about how to change the > user interfaces without the server support. If the user interface can translate a new RR into either wire format (if it talks to the back end using DNS QUERY and UPDATE messages) or into TYPEnnn format (for master files) or some proprietary RDATA blob format, then no special server support is necessary, provided it conforms to RFC 3597 (handling of unknown RR types). I don't mean to argue that server support for John's language is unimportant, just that it isn't a prerequisite. Tony. -- f.anthony.n.finch http://dotat.at/ North FitzRoy: Variable 4 in east at first, otherwise southerly 4 or 5. Very rough or high. Mainly fair. Moderate or good. From arnt@gulbrandsen.priv.no Thu Mar 8 06:30:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190E521F852A for ; Thu, 8 Mar 2012 06:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_05=-1.11, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-0gvdyZeKtG for ; Thu, 8 Mar 2012 06:30:41 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 204BB21F8527 for ; Thu, 8 Mar 2012 06:30:41 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 347C6F8D180; Thu, 8 Mar 2012 14:30:38 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1331217037-19852-19852/11/6; Thu, 8 Mar 2012 14:30:37 +0000 User-Agent: Kaiten Mail Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----641HPA7WHRMS3B0M2LJMT5Y4VG6NPD From: Arnt Gulbrandsen Date: Thu, 8 Mar 2012 15:30:35 +0100 To: ima@ietf.org Message-Id: <66cd551f-530f-48d3-96cc-0acf16f04777@email.android.com> Subject: [EAI] Simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:30:42 -0000 ------641HPA7WHRMS3B0M2LJMT5Y4VG6NPD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Any more comments? If not we might as well get a document shepherd. It's = now or later, and there is nothing to be gained by mere delay. Except... A review or two? Arnt ------641HPA7WHRMS3B0M2LJMT5Y4VG6NPD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

Any more comments? If not we might as well get a document shepherd. = It's now or later, and there is nothing to be gained by mere = delay.

Except... A review or two?

Arnt ------641HPA7WHRMS3B0M2LJMT5Y4VG6NPD-- From klensin@jck.com Thu Mar 8 06:41:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACF721F8722 for ; Thu, 8 Mar 2012 06:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLx+rqDC-9gI for ; Thu, 8 Mar 2012 06:41:25 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8621F871C for ; Thu, 8 Mar 2012 06:41:25 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5eSU-000Ahh-3s; Thu, 08 Mar 2012 09:36:46 -0500 Date: Thu, 08 Mar 2012 09:41:18 -0500 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: In-Reply-To: <66cd551f-530f-48d3-96cc-0acf16f04777@email.android.com> References: <66cd551f-530f-48d3-96cc-0acf16f04777@email.android.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:41:26 -0000 --On Thursday, March 08, 2012 15:30 +0100 Arnt Gulbrandsen wrote: > Hi, > > Any more comments? If not we might as well get a document > shepherd. It's now or later, and there is nothing to be gained > by mere delay. > > Except... A review or two? I would certainly prefer to see a review or two from those who have not been involved before concluding that we have sufficient WG consensus to start talking about document shepherds. I don't know quite how to proceed without it -- IETF Last Call and AUTH48 are not the times to discover that we don't have agreement on the text or, worse, don't know what it means. john From Shawn.Steele@microsoft.com Thu Mar 8 08:51:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6789A21F85D9 for ; Thu, 8 Mar 2012 08:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.17 X-Spam-Level: X-Spam-Status: No, score=-4.17 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWWKuiS5pogo for ; Thu, 8 Mar 2012 08:51:45 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0959821F85CD for ; Thu, 8 Mar 2012 08:51:44 -0800 (PST) Received: from mail178-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 16:51:44 +0000 Received: from mail178-va3 (localhost [127.0.0.1]) by mail178-va3-R.bigfish.com (Postfix) with ESMTP id 6580A2C0331 for ; Thu, 8 Mar 2012 16:51:44 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc89bhc857hzz1202hzz8275bhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail178-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3 (MessageSwitch) id 1331225500744465_24711; Thu, 8 Mar 2012 16:51:40 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.239]) by mail178-va3.bigfish.com (Postfix) with ESMTP id A7146320051 for ; Thu, 8 Mar 2012 16:51:40 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 16:51:38 +0000 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.241]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 16:51:30 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Mail to legacy servers Thread-Index: Acz9SsfUAwgIFHwWQZStgd78qOnmmA== Date: Thu, 8 Mar 2012 16:51:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A5B0DCCEFTK5EX14MBXC141r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:51:47 -0000 --_000_E14011F8737B524BB564B05FF748464A5B0DCCEFTK5EX14MBXC141r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V1JUIHRoZSBkb3duZ3JhZGUgc3R1ZmYsIEkgaGFkIGFuIGFjY2lkZW50YWwgZXhwZXJpbWVudCB0 aGF0IHdhcyBzb21ld2hhdCBpbnRlcmVzdGluZy4gIFNvbWVvbmUgc2VudCBhIGxpbmsgdG8gYSBz ZXJ2ZXIgdGhhdCBoYXMgYSBwYXJ0aWFsIGltcGxlbWVudGF0aW9uLiAgU2VudCBhcyBhIFVURjgg bWFpbCB0byBhIG5vbi1VVEY4IGF3YXJlIHNlcnZlciwgdGhlIG1haWwgc2hvdWxkbuKAmXQgaGF2 ZSBiZWVuIHNldG4sIGJ1dCBpdCB3YXMuICBJdCBlbmRlZCB1cCBiZWluZyByZWNlaXZlZCB3aXRo IGEgPz8/Pz8/PyBsb2NhbCBwYXJ0IChvbmUgPyBmb3IgZWFjaCBVVEYtOCBieXRlKS4gIENsZWFy bHkgSSB3YXNu4oCZdCBhYmxlIHRvIHJlcGx5IHRvIGl0LiAgT1RPSCwgSSAqZGlkKiByZWNlaXZl IHRoZSBtYWlsLCB3aGljaCBpcyBiZXR0ZXIgdGhhbiBuZXZlciBnZXR0aW5nIGEgbWFpbC4gIFBy ZXN1bWFibHksIGlmIGl0IHdlcmUgaW1wb3J0YW50LCBJIGNvdWxkIGZpbmQgYSBkaWZmZXJlbnQg cmVwbHkgcm91dGUuIChwaWNrIHVwIHRoZSBwaG9uZSkuICBNYWlsIGltcGxlbWVudGF0aW9ucyBt aWdodCBmaW5kIHRoYXQgYmVoYXZpb3Igd29ydGggY29uc2lkZXJpbmcuICBJZiBldmVyeXRoaW5n IGVsc2UgZmFpbHMsIGl0IHZpb2xhdGVzIHRoZSBzdGFuZGFyZCwgYnV0IGlmIHRoZSBtYWlsIGdl dHMgdGhyb3VnaCBtYXliZSBpdOKAmXMgYmV0dGVyIHRoYW4gbm90aGluZz/igKYNCg0KLVNoYXdu DQoNCu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9z aGF3bnN0ZQ0KDQo= --_000_E14011F8737B524BB564B05FF748464A5B0DCCEFTK5EX14MBXC141r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb2RlMjAwMDsNCglwYW5vc2UtMToyIDAgNiAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQ29kZTIwMDAiOw0KCXBhbm9z ZS0xOjIgMCA2IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XUlQgdGhlIGRvd25ncmFkZSBzdHVmZiwgSSBo YWQgYW4gYWNjaWRlbnRhbCBleHBlcmltZW50IHRoYXQgd2FzIHNvbWV3aGF0IGludGVyZXN0aW5n LiZuYnNwOyBTb21lb25lIHNlbnQgYSBsaW5rIHRvIGEgc2VydmVyIHRoYXQgaGFzIGEgcGFydGlh bCBpbXBsZW1lbnRhdGlvbi4mbmJzcDsgU2VudCBhcyBhIFVURjggbWFpbCB0byBhIG5vbi1VVEY4 IGF3YXJlIHNlcnZlciwgdGhlIG1haWwgc2hvdWxkbuKAmXQgaGF2ZSBiZWVuIHNldG4sDQogYnV0 IGl0IHdhcy4mbmJzcDsgSXQgZW5kZWQgdXAgYmVpbmcgcmVjZWl2ZWQgd2l0aCBhID8/Pz8/Pz8g bG9jYWwgcGFydCAob25lID8gZm9yIGVhY2ggVVRGLTggYnl0ZSkuJm5ic3A7IENsZWFybHkgSSB3 YXNu4oCZdCBhYmxlIHRvIHJlcGx5IHRvIGl0LiZuYnNwOyBPVE9ILCBJICo8Yj5kaWQ8L2I+KiBy ZWNlaXZlIHRoZSBtYWlsLCB3aGljaCBpcyBiZXR0ZXIgdGhhbiBuZXZlciBnZXR0aW5nIGEgbWFp bC4mbmJzcDsgUHJlc3VtYWJseSwgaWYgaXQgd2VyZSBpbXBvcnRhbnQsIEkgY291bGQNCiBmaW5k IGEgZGlmZmVyZW50IHJlcGx5IHJvdXRlLiAocGljayB1cCB0aGUgcGhvbmUpLiZuYnNwOyBNYWls IGltcGxlbWVudGF0aW9ucyBtaWdodCBmaW5kIHRoYXQgYmVoYXZpb3Igd29ydGggY29uc2lkZXJp bmcuJm5ic3A7IElmIGV2ZXJ5dGhpbmcgZWxzZSBmYWlscywgaXQgdmlvbGF0ZXMgdGhlIHN0YW5k YXJkLCBidXQgaWYgdGhlIG1haWwgZ2V0cyB0aHJvdWdoIG1heWJlIGl04oCZcyBiZXR0ZXIgdGhh biBub3RoaW5nP+KApiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1TaGF3bjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29kZTIwMDAiPu+j ou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibHVlIj5odHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGU8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E14011F8737B524BB564B05FF748464A5B0DCCEFTK5EX14MBXC141r_-- From sm@resistor.net Thu Mar 8 09:40:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACB121F8585 for ; Thu, 8 Mar 2012 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYQaSSGK38ts for ; Thu, 8 Mar 2012 09:40:43 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC0121F8550 for ; Thu, 8 Mar 2012 09:40:43 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q28Heb2q002930; Thu, 8 Mar 2012 09:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331228442; i=@resistor.net; bh=lzxYozUAnzpjUcKOoLuu2+XCIjatzzCQn0LUR6IT9Rk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=ePijqFX8koIURrkE29LWFlrtqUx5UED1ocme9IMTngaj2c5HBymyG2kmUxGSwnc0K RmCl9qkieDZT8AyAIyhKSJ/BFMsnqT4q428klY+oXbxCpjvtfg8Rf9Us2vfJ5WyurE 4Kx96Ulk+H16pDIg109FcNYMuO40EG7d/q/zF4Tg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331228442; i=@resistor.net; bh=lzxYozUAnzpjUcKOoLuu2+XCIjatzzCQn0LUR6IT9Rk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=3EhvQayHGTAiNIVLkMRrQVAxOEBCUxc4h6HjBM3lHMJxrPaTL/NqzyTNpcwQVS/kn lXd2mAZc7Rnyvw59gKj5bY1q9EGbW9qo2p8O1RSgTu6RWra8yB5kBP3DU6Vq3XicUJ OHqIPZfpIZ53ZoOsJytZKXl5XwVjqMwd7gbJGnWg= Message-Id: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Mar 2012 09:36:24 -0800 To: Shawn Steele From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:40:44 -0000 Hi Shawn, At 08:51 08-03-2012, Shawn Steele wrote: >a mail. Presumably, if it were important, I=20 >could find a different reply route. (pick up the=20 >phone). Mail implementations might find that=20 >behavior worth considering. If everything else=20 >fails, it violates the standard, but if the mail=20 >gets through maybe it's better than nothing?=85 If something is important, the question of=20 violating the standard would be less=20 important. At the end of the day, it is about=20 getting the message which the recipients wants to read through. Regards, -sm=20 From Shawn.Steele@microsoft.com Thu Mar 8 09:55:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3435021F8464 for ; Thu, 8 Mar 2012 09:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swe-vXRkgeFn for ; Thu, 8 Mar 2012 09:55:00 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id C411021F865B for ; Thu, 8 Mar 2012 09:54:58 -0800 (PST) Received: from mail50-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 17:54:57 +0000 Received: from mail50-am1 (localhost [127.0.0.1]) by mail50-am1-R.bigfish.com (Postfix) with ESMTP id 9D9B42404C6; Thu, 8 Mar 2012 17:54:57 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I936eK542M98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail50-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail50-am1 (localhost.localdomain [127.0.0.1]) by mail50-am1 (MessageSwitch) id 1331229295216204_24202; Thu, 8 Mar 2012 17:54:55 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.250]) by mail50-am1.bigfish.com (Postfix) with ESMTP id 309BD4E0046; Thu, 8 Mar 2012 17:54:55 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 17:54:53 +0000 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.241]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 17:54:41 +0000 From: Shawn Steele To: SM Thread-Topic: [EAI] Mail to legacy servers Thread-Index: Acz9SsfUAwgIFHwWQZStgd78qOnmmAAB9L41AABbFiA= Date: Thu, 8 Mar 2012 17:54:40 +0000 Message-ID: References: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> In-Reply-To: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ima@ietf.org" Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:55:02 -0000 I was sort of thinking that a mail client could choose to do something like= this. (I'm not necessarily advocating for it, more along the lines of "Ne= ither snow nor rain nor heat nor ASCII-only..." thinking). A) Try SMTPUTF8 route. =20 B) If not available, see if it can be resent using ASCII addresses. (Eg: i= f the user has registered such an address). C) If not possible, abuse the non-SMTPUTF8 route with UTF-8 addresses. B & C become harder (impossible) if you start having multiple hops. -Shawn -----Original Message----- From: SM [mailto:sm@resistor.net]=20 Sent: Thursday, March 08, 2012 9:36 AM To: Shawn Steele Cc: ima@ietf.org Subject: Re: [EAI] Mail to legacy servers Hi Shawn, At 08:51 08-03-2012, Shawn Steele wrote: >a mail. Presumably, if it were important, I could find a different=20 >reply route. (pick up the phone). Mail implementations might find that=20 >behavior worth considering. If everything else fails, it violates the=20 >standard, but if the mail gets through maybe it's better than nothing?... If something is important, the question of violating the standard would be = less=20 important. At the end of the day, it is about=20 getting the message which the recipients wants to read through. Regards, -sm=20 From arnt@gulbrandsen.priv.no Thu Mar 8 10:43:43 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5821F8613 for ; Thu, 8 Mar 2012 10:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMxQ6+958-6O for ; Thu, 8 Mar 2012 10:43:43 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E319921F85FC for ; Thu, 8 Mar 2012 10:43:42 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3A100F8D299; Thu, 8 Mar 2012 18:43:40 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1331232219-19852-19852/11/9; Thu, 8 Mar 2012 18:43:39 +0000 User-Agent: Kaiten Mail In-Reply-To: References: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----BXFUXE7PBNW3CNHEY50GUONPAMWO0O From: Arnt Gulbrandsen Date: Thu, 8 Mar 2012 19:43:34 +0100 To: Shawn Steele , sm@resistor.net Message-Id: <4799a9c0-b102-452d-a89f-54055e71aa3a@email.android.com> Cc: ima@ietf.org Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:43:43 -0000 ------BXFUXE7PBNW3CNHEY50GUONPAMWO0O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Code can do many things, but RFCs cannot say "ignore what RFCs say", so = this kind if thing is really not very interesting in the context of this = WG. Arnt ------BXFUXE7PBNW3CNHEY50GUONPAMWO0O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Code can do many things, but RFCs cannot say "ign= ore what RFCs say", so this kind if thing is really not very = interesting in the context of this WG.


Arnt ------BXFUXE7PBNW3CNHEY50GUONPAMWO0O-- From sm@resistor.net Thu Mar 8 11:06:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861DC21F853C for ; Thu, 8 Mar 2012 11:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m51vyne5lDo5 for ; Thu, 8 Mar 2012 11:06:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E84A21F84E7 for ; Thu, 8 Mar 2012 11:06:16 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q28J69gO022114; Thu, 8 Mar 2012 11:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331233574; i=@resistor.net; bh=VxDFnJq1se9Uj6PMpgX0j2lOxyYGfb0IeENmXh3GdPo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=T8JP7irSLW00+OrUs89GXEcVKGdmbZ+tVJbe8Oc1IR39RChOSlmcUhJjAwesC3Jyz Of6St7VDdQofDGe+N2k3Yvi4hc7fCkYv56MSSnU6GsNS3JXpor9UgF1LjfDm/lT7F1 dWwZM0GNgM2fFDpnpv49zHqpBYH529ah3JaSU3Jo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331233574; i=@resistor.net; bh=VxDFnJq1se9Uj6PMpgX0j2lOxyYGfb0IeENmXh3GdPo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=QW/RCr/7R5Dgo+RLdHx/HdUxZ6/ary+dRtKvTU/SaSVqj+jYdD2ZFMJxijMb6wgWp MdLRzsaWrGx7a4D/tKeRViho2JKkwO3fls/SEUDmHlKVIV9LtOCZjubVOAw4VaZfkY EmHrZI21SBsBTRwCH/BEBKubzNklZnFcE5xJCziQ= Message-Id: <6.2.5.6.2.20120308100734.0a5e1148@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Mar 2012 11:05:35 -0800 To: Shawn Steele From: SM In-Reply-To: References: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:06:17 -0000 Hi Shawn, At 09:54 08-03-2012, Shawn Steele wrote: >I was sort of thinking that a mail client could choose to do >something like this. (I'm not necessarily advocating for it, more >along the lines of "Neither snow nor rain nor heat nor >ASCII-only..." thinking). > >A) Try SMTPUTF8 route. >B) If not available, see if it can be resent using ASCII >addresses. (Eg: if the user has registered such an address). >C) If not possible, abuse the non-SMTPUTF8 route with UTF-8 addresses. > >B & C become harder (impossible) if you start having multiple hops. (c) is like throwing a bottle in the ocean. :-) From a specification perspective, we might consider (c) as an option which is undefined; we don't have any basis to say that it will work. From an operational perspective, we found out that it worked once or more. I would look this in terms of whether the average user should choose to do (c). It's easier to say no. Regards, -sm From Shawn.Steele@microsoft.com Thu Mar 8 11:13:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDF421F853A for ; Thu, 8 Mar 2012 11:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.543 X-Spam-Level: X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLln6M8OKSza for ; Thu, 8 Mar 2012 11:13:58 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id CF0D021F852B for ; Thu, 8 Mar 2012 11:13:58 -0800 (PST) Received: from mail70-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 19:13:58 +0000 Received: from mail70-tx2 (localhost [127.0.0.1]) by mail70-tx2-R.bigfish.com (Postfix) with ESMTP id 6049F2012B; Thu, 8 Mar 2012 19:13:58 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail70-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail70-tx2 (localhost.localdomain [127.0.0.1]) by mail70-tx2 (MessageSwitch) id 1331234036194913_446; Thu, 8 Mar 2012 19:13:56 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.248]) by mail70-tx2.bigfish.com (Postfix) with ESMTP id 2CDF9100164; Thu, 8 Mar 2012 19:13:56 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 19:13:54 +0000 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.241]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 19:13:53 +0000 From: Shawn Steele To: SM Thread-Topic: [EAI] Mail to legacy servers Thread-Index: Acz9SsfUAwgIFHwWQZStgd78qOnmmAAB9L41AABbFiAAAqIx4QAAP0wQ Date: Thu, 8 Mar 2012 19:13:52 +0000 Message-ID: References: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> <6.2.5.6.2.20120308100734.0a5e1148@resistor.net> In-Reply-To: <6.2.5.6.2.20120308100734.0a5e1148@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ima@ietf.org" Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:13:59 -0000 I don't think it's a spec thing at all, more of a potential implementation = curiousity. -----Original Message----- From: SM [mailto:sm@resistor.net]=20 Sent: Thursday, March 08, 2012 11:06 AM To: Shawn Steele Cc: ima@ietf.org Subject: RE: [EAI] Mail to legacy servers Hi Shawn, At 09:54 08-03-2012, Shawn Steele wrote: >I was sort of thinking that a mail client could choose to do something=20 >like this. (I'm not necessarily advocating for it, more along the=20 >lines of "Neither snow nor rain nor heat nor ASCII-only..." thinking). > >A) Try SMTPUTF8 route. >B) If not available, see if it can be resent using ASCII addresses. =20 >(Eg: if the user has registered such an address). >C) If not possible, abuse the non-SMTPUTF8 route with UTF-8 addresses. > >B & C become harder (impossible) if you start having multiple hops. (c) is like throwing a bottle in the ocean. :-) From a specification persp= ective, we might consider (c) as an option which is undefined; we don't hav= e any basis to say that it will work. From an operational perspective, we = found out that it worked once or more. I would look this in terms of whether the average user should choose to do = (c). It's easier to say no. Regards, -sm=20 From yaojk@cnnic.cn Thu Mar 8 18:30:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328A21F84C2 for ; Thu, 8 Mar 2012 18:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.515 X-Spam-Level: X-Spam-Status: No, score=-99.515 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaOruQgGSkks for ; Thu, 8 Mar 2012 18:30:58 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 428F821F84BD for ; Thu, 8 Mar 2012 18:30:55 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 09 Mar 2012 10:29:53 +0800 Message-ID: <53911D8D023C4D3A9685B38930AA8607@LENOVO47E041CF> From: "Jiankang YAO" To: "Arnt Gulbrandsen" , References: <66cd551f-530f-48d3-96cc-0acf16f04777@email.android.com> Date: Fri, 9 Mar 2012 10:29:52 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C9_01CCFDDF.902240C0" 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.6157 Subject: [EAI] Simpledowngrade or complex downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:30:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_05C9_01CCFDDF.902240C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIHR3byBraW5kcyBvZiBkb3duZ3JhZGVzLg0Kc2ltcGxlIGRvd25ncmFkZTogIGRy YWZ0LWlldGYtZWFpLXNpbXBsZWRvd25ncmFkZS0wMA0KY29tcGxleCBkb3duZ3JhZGU6IGRyYWZ0 LWlldGYtZWFpLXBvcGltYXAtZG93bmdyYWRlLTA0DQoNCg0KaW4gdGhlIHBvcCBhbmQgaW1hcCBk b2N1bWVudHMsIHdlIHJlY29tbWVuZCBzaW1wbGUgZG93bmdyYWRlIG9yIGNvbXBsZXggZG93bmdy YWRlIG9yIGJvdGg/DQoNCkl0IGlzIHVwIHRvIHRoZSBpbXBsZW1lbnRvcnMgdG8gZGVjaWRlIHdo aWNoIGRvd25ncmFkZSBpcyB0byBiZSBpbXBsZW1lbnRlZD8NCg0KDQpKaWFua2FuZyBZYW8NCg0K DQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEFybnQgR3VsYnJhbmRz ZW4gDQogIFRvOiBpbWFAaWV0Zi5vcmcgDQogIFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwOCwgMjAx MiAxMDozMCBQTQ0KICBTdWJqZWN0OiBbRUFJXSBTaW1wbGVkb3duZ3JhZGUNCg0KDQogIEhpLA0K DQogIEFueSBtb3JlIGNvbW1lbnRzPyBJZiBub3Qgd2UgbWlnaHQgYXMgd2VsbCBnZXQgYSBkb2N1 bWVudCBzaGVwaGVyZC4gSXQncyBub3cgb3IgbGF0ZXIsIGFuZCB0aGVyZSBpcyBub3RoaW5nIHRv IGJlIGdhaW5lZCBieSBtZXJlIGRlbGF5Lg0KDQogIEV4Y2VwdC4uLiBBIHJldmlldyBvciB0d28/ DQoNCiAgQXJudCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogIElNQSBtYWlsaW5nIGxpc3QN CiAgSU1BQGlldGYub3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aW1hDQo= ------=_NextPart_000_05C9_01CCFDDF.902240C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkxOTAiPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz4N CjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPlRoZXJlIGFyZSB0d28ga2luZHMgb2YgDQpk b3duZ3JhZGVzLjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm YWNlPeWui+S9kz5zaW1wbGUgZG93bmdyYWRlOiZuYnNwOyANCmRyYWZ0LWlldGYtZWFpLXNpbXBs ZWRvd25ncmFkZS0wMDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2T PmNvbXBsZXggZG93bmdyYWRlOiANCmRyYWZ0LWlldGYtZWFpLXBvcGltYXAtZG93bmdyYWRlLTA0 PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+DQo8RElWPjwvRk9OVD4mbmJz cDs8L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPmluIHRoZSBwb3Ag YW5kIGltYXAgZG9jdW1lbnRzLCB3ZSByZWNvbW1lbmQgc2ltcGxlIA0KZG93bmdyYWRlIG9yIGNv bXBsZXggZG93bmdyYWRlIG9yIGJvdGg/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3l rovkvZM+SXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudG9ycyB0byBkZWNpZGUgd2hpY2ggZG93bmdy YWRlIA0KaXMgdG8gYmUgaW1wbGVtZW50ZWQ/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTIgZmFjZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovk vZM+SmlhbmthbmcgWWFvPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovk vZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+PC9G T05UPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJH SU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCDlrovkvZM7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJs YWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWFybnRAZ3VsYnJhbmRzZW4ucHJpdi5ubyBo cmVmPSJtYWlsdG86YXJudEBndWxicmFuZHNlbi5wcml2Lm5vIj5Bcm50IA0KICBHdWxicmFuZHNl bjwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwvQj4g PEEgdGl0bGU9aW1hQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86aW1hQGlldGYub3JnIj5pbWFA aWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5T ZW50OjwvQj4gVGh1cnNkYXksIE1hcmNoIDA4LCAyMDEyIDEwOjMwIFBNPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1YmplY3Q6PC9CPiBbRUFJXSBTaW1wbGVkb3du Z3JhZGU8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+SGksPEJSPjxCUj5BbnkgbW9yZSBjb21tZW50 cz8gSWYgbm90IHdlIG1pZ2h0IGFzIHdlbGwgZ2V0IGEgDQogIGRvY3VtZW50IHNoZXBoZXJkLiBJ dCdzIG5vdyBvciBsYXRlciwgYW5kIHRoZXJlIGlzIG5vdGhpbmcgdG8gYmUgZ2FpbmVkIGJ5IA0K ICBtZXJlIGRlbGF5LjxCUj48QlI+RXhjZXB0Li4uIEEgcmV2aWV3IG9yIHR3bz88QlI+PEJSPkFy bnQgDQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPklNQSBtYWlsaW5nIA0KICBsaXN0PEJSPjxBIGhyZWY9 Im1haWx0bzpJTUFAaWV0Zi5vcmciPklNQUBpZXRmLm9yZzwvQT48QlI+PEEgDQogIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYTwvQT48QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_05C9_01CCFDDF.902240C0-- From klensin@jck.com Fri Mar 9 04:05:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6F621F85B1 for ; Fri, 9 Mar 2012 04:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8EA8fd7160t for ; Fri, 9 Mar 2012 04:05:39 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9821F85AA for ; Fri, 9 Mar 2012 04:05:38 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5yVB-000CVc-OG; Fri, 09 Mar 2012 07:00:53 -0500 Date: Fri, 09 Mar 2012 07:05:27 -0500 From: John C Klensin To: Jiankang YAO , Arnt Gulbrandsen , ima@ietf.org Message-ID: In-Reply-To: <53911D8D023C4D3A9685B38930AA8607@LENOVO47E041CF> References: <66cd551f-530f-48d3-96cc-0acf16f04777@email.android.com> <53911D8D023C4D3A9685B38930AA8607@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Simpledowngrade or complex downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:05:41 -0000 --On Friday, March 09, 2012 10:29 +0800 Jiankang YAO wrote: > There are two kinds of downgrades. > simple downgrade: draft-ietf-eai-simpledowngrade-00 > complex downgrade: draft-ietf-eai-popimap-downgrade-04 See my status summary note, but there are at least three, the third being some sort of "message unavailable" report to the client. A couple of ways to do that have been outlined on the list. The WG needs to decide whether to write the third up in an I-D and, if so, get someone to do it. > in the pop and imap documents, we recommend simple downgrade > or complex downgrade or both? Unless others disagree, I think where we are headed is to note that there are multiple options, but not make a recommendation. I believe that the same thinking that argued for separating the original popimap-downgrade material from the POP and IMAP specs suggests that we not duplicate that explanation into the POP and IMAP document but, instead, keep it separate, even if that means yet another document (or, frighteningly, opening and updating Framework). > It is up to the implementors to decide which downgrade is to > be implemented? Yes. And up to whomever selects implementations to decide which one to select. Let me restate this into several questions for the WG. If we can't get discussion, reviews of documents, and answers soon, we are in trouble. (1) Does the WG want a document describing the third, "no downgrade", option? If yes, who understands that option well enough to write it up and is going to volunteer? If no, I believe that options can be incorporated as hand waving into "the explanation" (see (2)). (2) Whatever is decided, this multiple-choice situation with more than one alternative, tradeoffs, and recommendations (if any) will need to be written up. Do we want that explanation duplicated in the POP and IMAP documents or do we want it in one place only? And do we want a thorough explanation or just a statement that there are alternatives, leaving implementers and those who select server software largely on their own as to what to select? Whether separate or duplicated, this material is referenced as "the explanation" above and below. Note, first, that going with the statement plan might make the "duplicate" strategy more attractive while explaining everything we know and have talked about might favor a "one place" strategy. There are lots of alternatives in between those two extremes. Second, fwiw, I believe that most of what would need to go into even a thorough and complete explanation has already appeared in discussions on the list and in popimap-downgrade so, while some collecting, drawing together, and writing are needed, the explanation should not require significant new work or involve material the WG hasn't already had a chance to examine. (3) Have people reviewed the latest version of popimap-downgrade and, if so, do you think it is ready to go modulo wherever "the explanation" goes? If not, when and how is that going to get done? Also, should some of the newer text about choices be removed from popimap-downgrade and put into "the explanation". (4) Have people reviewed the current version of simpledowngrade and, if so, do you think it is ready to go modulo wherever "the explanation" goes? If not, when and how is that going to get done? A warning: I believe that the co-chairs have the authority to make document organization decisions. I have no intention of exercising that authority if the WG has preferences and even very rough consensus about them. But, if no one, or almost no one, expresses opinions, I/we will interpret that as indifference and make decisions that will expedite getting the work done. john From ned+ima@mrochek.com Fri Mar 9 09:20:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D0621F8629 for ; Fri, 9 Mar 2012 09:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnWmVq92JjGZ for ; Fri, 9 Mar 2012 09:20:09 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C351C21F84FA for ; Fri, 9 Mar 2012 09:20:08 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCWNJR0HEO0029N0@mauve.mrochek.com> for ima@ietf.org; Fri, 9 Mar 2012 09:20:07 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 9 Mar 2012 09:20:04 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCWNJPV1J400ZUIL@mauve.mrochek.com> Date: Fri, 09 Mar 2012 08:55:30 -0800 (PST) In-reply-to: "Your message dated Thu, 08 Mar 2012 11:05:35 -0800" <6.2.5.6.2.20120308100734.0a5e1148@resistor.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> <6.2.5.6.2.20120308100734.0a5e1148@resistor.net> To: SM DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331313619; bh=xL1LjuwW4PfAReHX944AieRE7IunCdG1WY1nHr6PaP0=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=GI2kkaO0qHN6q9HKrqjxFRW8MvxrOvNMCQo/Ml3VKbWVx7bXmz43E77SejH7gGC+m L5o6as/uaVa9aUE7tiG3tvJAZi8YJNtj6+Cpv8lpUWlsdSQhr8FrZnFD7KfDIl91bF YtkhUgDSiUY5mnVBMTQfR//dTcYlmUaHbV6E+5P8= Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:20:10 -0000 > Hi Shawn, > At 09:54 08-03-2012, Shawn Steele wrote: > >I was sort of thinking that a mail client could choose to do > >something like this. (I'm not necessarily advocating for it, more > >along the lines of "Neither snow nor rain nor heat nor > >ASCII-only..." thinking). > > > >A) Try SMTPUTF8 route. > >B) If not available, see if it can be resent using ASCII > >addresses. (Eg: if the user has registered such an address). > >C) If not possible, abuse the non-SMTPUTF8 route with UTF-8 addresses. > > > >B & C become harder (impossible) if you start having multiple hops. > (c) is like throwing a bottle in the ocean. :-) Actually, it's more like poking a stick into a wood chipper. For example, if the EAI stuff shows up in the outer header, there are two possible outcomes for sites using our software, depending on configuration settings: (a) The message will be bounced as invalid or (b) It will be delivered but all of the EAI stuff in the main header will depending on it's location, be removed or encoded (and if it is encoded it may or may not be marked as utf-8). As for EAI stuff appearing in inner headers, that again depends on configuration settings. In most cases option (b) above will probably apply. We don't tolerate invalid crap in the outer header. Period. Too many clients are known to barf on it. And that's a support call generator. Our customers really don't like support calls. And modifying messages so the client won't barf but the addresses are trashed doesn't generate nearly as many calls. For better or worse, people are used to funky crap showing up in headers. As long as they can get at the content - and nothing in the modifications we perform will affect that - they generally don't call. In fact it's the other way around: If utf-8 appears in a Content-type field, clients may not handle that well and encoding it may actually prevent a support call. All this also applies to submission as well as delivery, BTW. Of course this may change if EAI gets widely deployed. If we see a need we may, and I emphasize MAY, provide an option to promote an EAI message that isn't marked as such to EAI status. But any such option is years away from being implemented, let along deployed, and besides, there's a bit of a chicken-and-egg problem here, isn't there? > From a specification > perspective, we might consider (c) as an option which is undefined; > we don't have any basis to say that it will work. See above. There actually a pretty good basis to believe it's a bad idea, just like just-send-8 was a bad idea 20 years ago. > From an > operational perspective, we found out that it worked once or more. > I would look this in terms of whether the average user should choose > to do (c). It's easier to say no. Well, that's another thing. It won't be up to the user. The overwhelming majority of users don't run their own MSA or MTA, and don't have any control over whether or not any of this happens. So the question really is "what will mainstream clients and other mail software do"? I think the days of the brash "I'll do what I please and standards be damned" software developers being in control are pretty much over. Ned From johnl@iecc.com Fri Mar 9 09:43:58 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9127B21F8661 for ; Fri, 9 Mar 2012 09:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.285 X-Spam-Level: X-Spam-Status: No, score=-110.285 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssZKftFROoUB for ; Fri, 9 Mar 2012 09:43:57 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8821F85D5 for ; Fri, 9 Mar 2012 09:43:57 -0800 (PST) Received: (qmail 8829 invoked from network); 9 Mar 2012 17:43:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Mar 2012 17:43:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5a415c.xn--btvx9d.k1203; i=johnl@user.iecc.com; bh=kV5du92h9gaF3rBz4YXjGskm3KPplXh8BthoSjWEUdE=; b=hInS+YH/wHi4vle+wR6pYPBCbx/0KSYTvBFPfqUgUXI+njr1sFRXgI9riA7O7sfZQYjgABN8sxYs91ghqQq7VHF0Xt/aT+PLEUcF0E+XfjTVLXFe/OOrDL7dyHDQnE4c/YUrsLYXVpEFQjHn/MOalpfArK2penEn0/Zy+tpaUWc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5a415c.xn--btvx9d.k1203; olt=johnl@user.iecc.com; bh=kV5du92h9gaF3rBz4YXjGskm3KPplXh8BthoSjWEUdE=; b=eYKudnKvTuqROKM/ZhBJW+c8BU0dT6i4OP9cQnQfmb39VDVUN2lo+JZ/h4WAoxifgNTnGNrRrQXf+F+kPvHxcFVEIMT68rgYr0c/2U2FniBy3LaSdvZ3d9dV3aYQ5S3TJuOt3nUxqBVcHXMj8wvnC6XTo1DX9PdgASUmHCm7udc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Mar 2012 17:43:34 -0000 Message-ID: <20120309174334.89144.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] Simpledowngrade or complex downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:43:58 -0000 Having (as best I recall) originally proposed the no downgrade a/k/a hostage approach, I'd be happy with language that says to downgrade but leaves the details to the implementation. The details of the downgrade have little effect on interoperation, so there's no need to offer any more advice than is required not to break things unnecessarily. The main bit of advice would be not to downgrade to something that looke like a valid legacy message, e.g., don't turn UTF-8 mailboxes into INVALID or Mr. Invalid will be getting a lot of other people's mail. R's, John From wwwrun@rfc-editor.org Fri Mar 9 15:15:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C406521E8044 for ; Fri, 9 Mar 2012 15:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi6obeXIuO0H for ; Fri, 9 Mar 2012 15:15:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADEF21E8028 for ; Fri, 9 Mar 2012 15:15:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BBD91B1E002; Fri, 9 Mar 2012 15:14:56 -0800 (PST) To: abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, presnick@qualcomm.com, stpeter@stpeter.im, john-ietf@jck.com, jyee@afilias.info From: RFC Errata System Message-Id: <20120309231456.BBD91B1E002@rfc-editor.org> Date: Fri, 9 Mar 2012 15:14:56 -0800 (PST) Cc: ima@ietf.org, dthaler@microsoft.com, rfc-editor@rfc-editor.org Subject: [EAI] [Editorial Errata Reported] RFC6532 (3153) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:15:25 -0000 The following errata report has been submitted for RFC6532, "Internationalized Email Headers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6532&eid=3153 -------------------------------------- Type: Editorial Reported by: Dave Thaler Section: 4 Original Text ------------- The security impact of UTF-8 headers on email signature systems such as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is discussed in Section 14 of [RFC6530]. Corrected Text -------------- The security impact of UTF-8 headers on email signature systems such as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is discussed in Section 13 of [RFC6530]. Notes ----- Incorrect section number in reference. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6532 (draft-ietf-eai-rfc5335bis-13) -------------------------------------- Title : Internationalized Email Headers Publication Date : February 2012 Author(s) : A. Yang, S. Steele, N. Freed Category : PROPOSED STANDARD Source : Email Address Internationalization Area : Applications Stream : IETF Verifying Party : IESG From ned+ima@mrochek.com Fri Mar 9 21:46:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2658421F8512 for ; Fri, 9 Mar 2012 21:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOK5oKoCnInJ for ; Fri, 9 Mar 2012 21:46:43 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E48F221F8513 for ; Fri, 9 Mar 2012 21:46:42 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCXDM9Y300015HY3@mauve.mrochek.com> for ima@ietf.org; Fri, 9 Mar 2012 21:46:39 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 9 Mar 2012 21:46:33 -0800 (PST) From: ned+ima@mrochek.com Message-id: <01OCXDM85LDE00ZUIL@mauve.mrochek.com> Date: Fri, 09 Mar 2012 21:46:06 -0800 (PST) In-reply-to: "Your message dated Fri, 09 Mar 2012 15:14:56 -0800 (PST)" <20120309231456.BBD91B1E002@rfc-editor.org> MIME-version: 1.0 References: <20120309231456.BBD91B1E002@rfc-editor.org> To: RFC Errata System DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331358412; bh=c8Kzn9ZFwJCHx0dDkrBMQ5eFEYdZjo6+CWMVNPHQOdw=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: References:To; b=JCddP1BM0SFA73QW3tebFeulgnWmL0gH5bWN9spboh6hJ6TqETkQzYcCeYcQBH3ij IzrA9wo2u9wcybKrqUm0R7n6QBEbsQVRrmG5eiLJPUikEIxBUjpSaawZGE5n2B1Q64 HxYWx1oEDShMGtHBBfbfZUS9qiyVWfDNhaij7FJo= Cc: Shawn.Steele@microsoft.com, dthaler@microsoft.com, john-ietf@jck.com, ima@ietf.org, presnick@qualcomm.com, ned+ietf@mrochek.com, rfc-editor@rfc-editor.org Subject: Re: [EAI] [Editorial Errata Reported] RFC6532 (3153) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 05:46:44 -0000 The change looks correct to me - it should be section 13, not 14. Ned > The following errata report has been submitted for RFC6532, > "Internationalized Email Headers". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6532&eid=3153 > -------------------------------------- > Type: Editorial > Reported by: Dave Thaler > Section: 4 > Original Text > ------------- > The security impact of UTF-8 headers on email signature systems such > as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is > discussed in Section 14 of [RFC6530]. > Corrected Text > -------------- > The security impact of UTF-8 headers on email signature systems such > as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is > discussed in Section 13 of [RFC6530]. > Notes > ----- > Incorrect section number in reference. > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC6532 (draft-ietf-eai-rfc5335bis-13) > -------------------------------------- > Title : Internationalized Email Headers > Publication Date : February 2012 > Author(s) : A. Yang, S. Steele, N. Freed > Category : PROPOSED STANDARD > Source : Email Address Internationalization > Area : Applications > Stream : IETF > Verifying Party : IESG From john-ietf@jck.com Sat Mar 10 08:25:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FF521F8597 for ; Sat, 10 Mar 2012 08:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRkYOMrtArii for ; Sat, 10 Mar 2012 08:25:05 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD9621F851D for ; Sat, 10 Mar 2012 08:24:40 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S6P1A-000Eol-E1; Sat, 10 Mar 2012 11:19:40 -0500 Date: Sat, 10 Mar 2012 11:24:16 -0500 From: John C Klensin To: Ned Freed , RFC Errata System Message-ID: <0BAB5D1FA8D0EB611525841B@PST.JCK.COM> In-Reply-To: <01OCXDM85LDE00ZUIL@mauve.mrochek.com> References: <20120309231456.BBD91B1E002@rfc-editor.org> <01OCXDM85LDE00ZUIL@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: Shawn.Steele@microsoft.com, dthaler@microsoft.com, ima@ietf.org, presnick@qualcomm.com, ned+ietf@mrochek.com Subject: Re: [EAI] [Editorial Errata Reported] RFC6532 (3153) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 16:25:06 -0000 --On Friday, March 09, 2012 21:46 -0800 Ned Freed wrote: > The change looks correct to me - it should be section 13, not > 14. Concur. john >> The following errata report has been submitted for RFC6532, >> "Internationalized Email Headers". > >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6532&eid=3153 > >> -------------------------------------- >> Type: Editorial >> Reported by: Dave Thaler > >> Section: 4 > >> Original Text >> ------------- >> The security impact of UTF-8 headers on email signature >> systems such > >> as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is > >> discussed in Section 14 of [RFC6530]. > > > >> Corrected Text >> -------------- >> The security impact of UTF-8 headers on email signature >> systems such > >> as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is > >> discussed in Section 13 of [RFC6530]. > > > >> Notes >> ----- >> Incorrect section number in reference. > >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, >> please use "Reply All" to discuss whether it should be >> verified or rejected. When a decision is reached, the >> verifying party (IESG) can log in to change the status and >> edit the report, if necessary. > >> -------------------------------------- >> RFC6532 (draft-ietf-eai-rfc5335bis-13) >> -------------------------------------- >> Title : Internationalized Email Headers >> Publication Date : February 2012 >> Author(s) : A. Yang, S. Steele, N. Freed >> Category : PROPOSED STANDARD >> Source : Email Address Internationalization >> Area : Applications >> Stream : IETF >> Verifying Party : IESG From duerst@it.aoyama.ac.jp Mon Mar 12 03:29:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B13B21F8604 for ; Mon, 12 Mar 2012 03:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.513 X-Spam-Level: X-Spam-Status: No, score=-100.513 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpDomnMy2Hnt for ; Mon, 12 Mar 2012 03:29:16 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 54F9E21F85EE for ; Mon, 12 Mar 2012 03:29:15 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2CAT6Ma021754 for ; Mon, 12 Mar 2012 19:29:06 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6ddd_26a6_320b2cf0_6c2e_11e1_ade2_001d096c5782; Mon, 12 Mar 2012 19:29:05 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34615) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 12 Mar 2012 19:29:06 +0900 Message-ID: <4F5DCFF0.3080300@it.aoyama.ac.jp> Date: Mon, 12 Mar 2012 19:29:04 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Fwd: I-D Action: draft-duerst-eai-mailto-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 10:29:17 -0000 Dear EAI WG members, Just shortly before the draft submission deadline, I managed to submit a new version of draft-duerst-eai-mailto (see below). It mainly integrates part of the comments from Frank Ellermann in http://www.ietf.org/mail-archive/web/ima/current/msg04361.html (I still have to work on the rest of his comments) and updates the references to the published RFCs of this WG. I'm looking forward to any comments, and will gladly accept any directions I might receive from the WG chairs. Regards, Martin. P.S.: I also plan to comment on the currently open WG drafts in the near future. -------- Original Message -------- Subject: I-D Action: draft-duerst-eai-mailto-02.txt Date: Mon, 12 Mar 2012 03:12:54 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'mailto' URI/IRI Scheme Author(s) : Martin Duerst Larry Masinter Jamie Zawinski Filename : draft-duerst-eai-mailto-02.txt Pages : 21 Date : 2012-03-12 This document defines the format of Uniform Resource Identifiers (URIs) and Internationalized Resource Identfiers (IRIs) to identify resources that are reached using Internet mail. It adds the possibility to use Email Address Internationalization (EAI) email addresses (RFC6530) to the previous syntax of 'mailto' URIs (RFC 6068). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duerst-eai-mailto-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-duerst-eai-mailto-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jyee@afilias.info Tue Mar 13 23:11:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D8621F85E3 for ; Tue, 13 Mar 2012 23:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plmt6nl3Lsb6 for ; Tue, 13 Mar 2012 23:11:38 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id E536121F85DA for ; Tue, 13 Mar 2012 23:11:37 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S7hQu-0001sF-81 for ima@ietf.org; Wed, 14 Mar 2012 06:11:36 +0000 Received: from mail-iy0-f178.google.com ([209.85.210.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S7hQu-0007j3-7L for ima@ietf.org; Wed, 14 Mar 2012 06:11:36 +0000 Received: by iakl21 with SMTP id l21so2109677iak.9 for ; Tue, 13 Mar 2012 23:11:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LLMySFKd4sg/M+bxnNoefn8uucLZLMmSy5yodfEwwug=; b=nhjjR4kJmPhipXxZ1TsgH4HECRZdDNgeVoh4sQ0sO1UfUuUB+z16HFlmdWP6wgoQFP 7GoU7hZ3YiC8Lvn6p4O07p774XhDaiyLPzYQi8h9qcSJdpU2LYM1XVOw7Ky7HMM4vlfO VDJL50wHO9KrRn3x26NO62xNZScW42x9Nb5h71f0BVGMavnzfsymAyql/W7416LQ0R8z UljWNPWxxO9Y6sD+d29ej8/cbSJ8ctPkJtfpvILvAG0zG9yC1PhW4SCxzDFJn7NowaZt Y99WWdxUev0tiDHjXR8yzPpb7uwo/l8uudO/RftzO43O/T/GDL0hJWXhYY14aUQr5Iyl R4Aw== Received: by 10.42.147.199 with SMTP id o7mr1756415icv.50.1331705485362; Tue, 13 Mar 2012 23:11:25 -0700 (PDT) Received: from [192.168.0.103] (206-248-164-23.dsl.teksavvy.com. [206.248.164.23]) by mx.google.com with ESMTPS id mi10sm2736476igc.8.2012.03.13.23.11.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 23:11:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <4F539230.3080808@gulbrandsen.priv.no> Date: Wed, 14 Mar 2012 02:11:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F539230.3080808@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQm5gF9VHk6hd87AqKwpa2joYvm596qj+eOM7BhOYRtV/1cvBxoB8zOlCE5MK8INMEAOgAVu Cc: ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:11:38 -0000 All personal thought below.. I read -01, and think that this approach is tempting because it's = simpler. Its care focus on what's mostly visible (GUI wise). Using .valid makes the message harder to be actionable, but not = completely (ie. bad DNS hacks). This is where I am more in favor in = Fujiwara's draft of empty list. (Yes, there are still tradeoffs). =20 Nits spotted: Section 2.2 s/atttribute/attribute/ Section 2.4 "the modifications in sections 3.1 and 3.2 is silently excised" I believed that you mean sections 2.1 and 2.2? Joseph On 2012-03-04, at 11:02 AM, Arnt Gulbrandsen wrote: > I made a -01 after addressing blah. Should be out now. >=20 > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From jyee@afilias.info Tue Mar 13 23:37:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2644E21F85CD for ; Tue, 13 Mar 2012 23:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwb0Mogz-WcF for ; Tue, 13 Mar 2012 23:37:30 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3152921F85CC for ; Tue, 13 Mar 2012 23:37:30 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S7hpx-0008Ve-5C for ima@ietf.org; Wed, 14 Mar 2012 06:37:29 +0000 Received: from mail-iy0-f178.google.com ([209.85.210.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S7hpx-0008Ev-7m for ima@ietf.org; Wed, 14 Mar 2012 06:37:29 +0000 Received: by iakl21 with SMTP id l21so2138615iak.9 for ; Tue, 13 Mar 2012 23:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MxOJdsLriIDtt9nboKpEhb1LnyLp5ZyWtzkJAC8s+Ds=; b=Rfev8dTgq6aii2Z8KJl1f8mifgu0Pbig7YphFrsvtyepddOIVhpLyffe1CfFuLtzhs eAgUpkL2VNNXgWqPwxgG92K2kGPWK6r7Ji5w6Xg2BracW46Ttqpsb7zLUTcW2bt2xAbl te/TtcEMrYMhqmcGGh05iw6V6VMedt8DR2j+RwChCUvHnt14aZ2dW3UfJP69lUGvGzZ4 dn1UV54x5o2s1HCDCcCmj5K1UGt82LQ/kYLiT2KKd3U3AU921nTV0iRVDqxGrB+sR/sq OdCeBlH54/XpiyzcNiLYrC65Jqdj4nUTwcZzDo/FODdtQBAYVN1FSHQvbZOIxLrMMntb RzNg== Received: by 10.50.196.165 with SMTP id in5mr10523088igc.8.1331707048973; Tue, 13 Mar 2012 23:37:28 -0700 (PDT) Received: from [192.168.0.103] (206-248-164-23.dsl.teksavvy.com. [206.248.164.23]) by mx.google.com with ESMTPS id rd7sm11424143igb.14.2012.03.13.23.37.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 23:37:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: Date: Wed, 14 Mar 2012 02:37:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <074B45A0-0D85-403A-B6E9-12C8E4F17125@afilias.info> References: <6.2.5.6.2.20120308092629.0a7fede8@resistor.net> To: Shawn Steele X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnAkbjhXPH4Y5OmsAa24qstsUMfHtIiLFoSvy4g+U8zZEjcC+z9GrgV7Z4fCZsM2JJUj8L/ Cc: "ima@ietf.org" Subject: Re: [EAI] Mail to legacy servers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:37:31 -0000 On 2012-03-08, at 12:54 PM, Shawn Steele wrote: > I was sort of thinking that a mail client could choose to do something = like this. (I'm not necessarily advocating for it, more along the lines = of "Neither snow nor rain nor heat nor ASCII-only..." thinking). >=20 > A) Try SMTPUTF8 route. =20 > B) If not available, see if it can be resent using ASCII addresses. = (Eg: if the user has registered such an address). > C) If not possible, abuse the non-SMTPUTF8 route with UTF-8 addresses. >=20 > B & C become harder (impossible) if you start having multiple hops. Other than C (and others replied about C), RFC6531 section 3.2 covered = part of it, with different wordings/terminology where it's more of MSA = than mail client. I had a feeling that you say mail client, but not = meaning MUA literally. Joseph >=20 > -Shawn >=20 > -----Original Message----- > From: SM [mailto:sm@resistor.net]=20 > Sent: Thursday, March 08, 2012 9:36 AM > To: Shawn Steele > Cc: ima@ietf.org > Subject: Re: [EAI] Mail to legacy servers >=20 > Hi Shawn, > At 08:51 08-03-2012, Shawn Steele wrote: >> a mail. Presumably, if it were important, I could find a different=20= >> reply route. (pick up the phone). Mail implementations might find = that=20 >> behavior worth considering. If everything else fails, it violates = the=20 >> standard, but if the mail gets through maybe it's better than = nothing?... >=20 > If something is important, the question of violating the standard = would be less=20 > important. At the end of the day, it is about=20 > getting the message which the recipients wants to read through. >=20 > Regards, > -sm=20 >=20 >=20 >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From arnt@gulbrandsen.priv.no Wed Mar 14 01:39:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5611721F86F7 for ; Wed, 14 Mar 2012 01:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7LDNLrZ9rXF for ; Wed, 14 Mar 2012 01:39:39 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id B752A21F86F6 for ; Wed, 14 Mar 2012 01:39:39 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 28999F8D484; Wed, 14 Mar 2012 08:39:37 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1331714376-13042-13042/10/5; Wed, 14 Mar 2012 08:39:36 +0000 Message-Id: <4F605997.6000004@gulbrandsen.priv.no> Date: Wed, 14 Mar 2012 09:40:55 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> In-Reply-To: <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 08:39:40 -0000 On 03/14/2012 07:11 AM, Joseph Yee wrote: > Using .valid makes the message harder to be actionable, but not = completely (ie. bad DNS hacks). This is where I am more in favor in = Fujiwara's draft of empty list. (Yes, there are still tradeoffs). =20 .invalid is already reserved by RFC 2606. We'd have to reserve .valid using this document, I'm not sure how much work that would be. I fear that without a clear and convincing reason it might lead to wearisome discussion during IETF LC. > Nits spotted: > Section 2.2 > s/atttribute/attribute/ >=20 > Section 2.4 > "the modifications in sections 3.1 and 3.2 is silently excised" > I believed that you mean sections 2.1 and 2.2? I should learn to type. Fixed. Arnt From fujiwara@jprs.co.jp Wed Mar 14 02:08:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333C021F8712 for ; Wed, 14 Mar 2012 02:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGMMdX7pjsiw for ; Wed, 14 Mar 2012 02:08:32 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6753421F8713 for ; Wed, 14 Mar 2012 02:08:32 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q2E98PfD013617; Wed, 14 Mar 2012 18:08:25 +0900 X-AuditID: ac120820-b7f346d000007d33-3b-4f60600918d4 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 64.14.32051.900606F4; Wed, 14 Mar 2012 18:08:25 +0900 (JST) Date: Wed, 14 Mar 2012 18:08:25 +0900 (JST) Message-Id: <20120314.180825.183027988.fujiwara@jprs.co.jp> To: arnt@gulbrandsen.priv.no From: fujiwara@jprs.co.jp In-Reply-To: <4F605997.6000004@gulbrandsen.priv.no> References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsWyRoiFT5czIcHf4OYhEYvuB4fYLK4vXcfu wOSx599qZo8lS34yBTBFcdmkpOZklqUW6dslcGVs+HSPpeAna8XF5W/YGxifsHQxcnJICJhI TP56kQ3CFpO4cG89kM3FISRwklHi6sOX7CAJFgFtiZ7Li8EaeAWsJd7v+sUMYosIyEgs/LWb EcRmFhCQOHlpHpgtDDR077nPTCA2m4CkxObPrWD1nALGEisXnGeCWDCRUWLl7AtQV9hJnHi+ grWLkQNogaDE3x3CEDO1JHpmPGaHsOUltr+dwzyBkX8WQtUsJFWzkFQtYGRexSiTn5amW5ya l1Kcm25gqFdSma+XVVBUrJcMojcxgkORQ2EH44xTBocYBTgYlXh4PVvi/YVYE8uKK3MPMUpy MCmJ8tbEJvgL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9xgqU401JrKxKLcqHSUlzsCiJ8x4/ u8NPSCA9sSQ1OzW1ILUIJivDwaEkwVsfCdQoWJSanlqRlplTgpBm4uAEGc4DNNwpGmR4cUFi bnFmOkT+FKOklDhvfjhQQgAkkVGaB9f7ilEc6AVhXm+QLA8wrcB1vQIayAQ0sORbHMjAkkSE lFQD41Htnh9bFU5eF9BNvWsUV/Px1auZQo/WRxz5PVMwTPLBlHa2BUZX90jNk882V3mm/HiC 1y/2jXrHymbbVF7+aKq4asfEaBnL/zf/uB0L5OBd4bCmZ4718rBZnT2rWh9MSusoT+X+/ODc srQ+KTblp7eWGp6fW8niyXNjnsLHLRomTqntZhVSE5VYijMSDbWYi4oTAf8P3yToAgAA Cc: ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:08:33 -0000 > From: Arnt Gulbrandsen >> Using .valid makes the message harder to be actionable, but not completely (ie. bad DNS hacks). This is where I am more in favor in Fujiwara's draft of empty list. (Yes, there are still tradeoffs). 'Empty list' is WG dicision on the past meetings. > .invalid is already reserved by RFC 2606. We'd have to reserve .valid > using this document, I'm not sure how much work that would be. I fear > that without a clear and convincing reason it might lead to wearisome > discussion during IETF LC. The draft should refer RFC 2606 and some description about "eai.invalid" helps readers' understanding. and why don't you refer RFC 6532 ? -- Kazunori Fujiwara, JPRS From arnt@gulbrandsen.priv.no Wed Mar 14 02:43:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9489421F8512 for ; Wed, 14 Mar 2012 02:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiAu5GmJF-+5 for ; Wed, 14 Mar 2012 02:43:45 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0688621F84D2 for ; Wed, 14 Mar 2012 02:43:45 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 630CEF8D54B; Wed, 14 Mar 2012 09:43:43 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1331718221-13042-13042/10/6; Wed, 14 Mar 2012 09:43:41 +0000 Message-Id: <4F60689C.2030209@gulbrandsen.priv.no> Date: Wed, 14 Mar 2012 10:45:00 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> <20120314.180825.183027988.fujiwara@jprs.co.jp> In-Reply-To: <20120314.180825.183027988.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:43:45 -0000 On 03/14/2012 10:08 AM, fujiwara@jprs.co.jp wrote: >> From: Arnt Gulbrandsen >>> Using .valid makes the message harder to be actionable, but not = completely (ie. bad DNS hacks). This is where I am more in favor in = Fujiwara's draft of empty list. (Yes, there are still tradeoffs). =20 >=20 > 'Empty list' is WG dicision on the past meetings. Yes, but that doesn't apply since simpledowngrade does not specify any format, it just gives some examples. I added two more examples now, and changed the wording to make it clearer that they are just examples. Server authors are free to use whichever format generates the lowest number of support calls. Client authors are unable to write code to support downgrade (at risk of repeating myself: they should support EAI, not downgrade). >> .invalid is already reserved by RFC 2606. We'd have to reserve .valid >> using this document, I'm not sure how much work that would be. I fear >> that without a clear and convincing reason it might lead to wearisome >> discussion during IETF LC. >=20 > The draft should refer RFC 2606 and some description about > "eai.invalid" helps readers' understanding. OK, done. > and why don't you refer RFC 6532 ? No actual sentences need it. There also is no reference to 1939, 5234 or 5322. I could add a reference for the sake of the reference, but IMO it's better when the references are inserted out of concrete need. Arnt From arnt@gulbrandsen.priv.no Wed Mar 14 02:59:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31521F872D for ; Wed, 14 Mar 2012 02:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8AfioNpd13Q for ; Wed, 14 Mar 2012 02:59:38 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC221F871D for ; Wed, 14 Mar 2012 02:59:38 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4A695F8D599; Wed, 14 Mar 2012 09:59:37 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1331719176-13042-13042/10/7; Wed, 14 Mar 2012 09:59:36 +0000 Message-Id: <4F606C57.2030307@gulbrandsen.priv.no> Date: Wed, 14 Mar 2012 11:00:55 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> <20120314.180825.183027988.fujiwara@jprs.co.jp> <4F60689C.2030209@gulbrandsen.priv.no> In-Reply-To: <4F60689C.2030209@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1 Subject: [EAI] two downgrade specs, I think X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:59:39 -0000 One more thing. I think that I personally am now in favour of publishing both drafts as RFCs and letting server authors choose according to inclination. I have my inclination, of course, but I can see sensible reasons why people might choose differently, and I don't think we gain very much by forcing this issue to be resolved before we've gained real implementation and deployment experience. Possible wording (in the two downgrade documents or in a reference paragraph in the popimap spec): RFC x describes a very simple downgrade process, while RFC y describes a more complex, more accurate process. The WG decided that choosing one process based on little implementation experience would be premature, so both specifications are published, and servers may choose either. Arnt From sm@resistor.net Wed Mar 14 06:57:53 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD89121F87AD for ; Wed, 14 Mar 2012 06:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcQRi1P87--O for ; Wed, 14 Mar 2012 06:57:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A556921F87A5 for ; Wed, 14 Mar 2012 06:57:50 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2EDvcGr000246; Wed, 14 Mar 2012 06:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331733466; i=@resistor.net; bh=NBQDO6ST2LjzBs+JoCgDSzZYNK1GyDuw+D5lE62n2gk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XxK6hNLe1oAZjiMicdlAxxAeAAZ7LNsYFXWygcacKF725DPv/603NFziheeLgc09U RPO9mt94JODf8+SLySzqZ1VEBUuf/Z3/YoryyUGf1tQmCICnofVJ4tDkoX7gcuUn65 zCEnyOG1IKmxfw0eVnUKGSCjOqsowg26Y2C3D2F8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331733466; i=@resistor.net; bh=NBQDO6ST2LjzBs+JoCgDSzZYNK1GyDuw+D5lE62n2gk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NxVxOtiDL6Pjm7X6ec4mu+KHGTbcGV8WL4g6Xr2ACmHtePsV/Y0UU0cyMaQka1pcw fpXt3aM1Cfa0XgXNqHj4K7AEgW0N9M1i0eNSwBFs3iVXiwQh0CUYHTVxoG1J0xZoXf wyD1JXRt9vndMJ0CXybvUKYaHo3x6o9CCM7o1wK8= Message-Id: <6.2.5.6.2.20120314064531.0a834bb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 06:52:50 -0700 To: Arnt Gulbrandsen From: SM In-Reply-To: <4F606C57.2030307@gulbrandsen.priv.no> References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> <20120314.180825.183027988.fujiwara@jprs.co.jp> <4F60689C.2030209@gulbrandsen.priv.no> <4F606C57.2030307@gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] two downgrade specs, I think X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:57:53 -0000 Hi Arnt, At 03:00 14-03-2012, Arnt Gulbrandsen wrote: >One more thing. I think that I personally am now in favour of publishing >both drafts as RFCs and letting server authors choose according to >inclination. > >I have my inclination, of course, but I can see sensible reasons why >people might choose differently, and I don't think we gain very much by >forcing this issue to be resolved before we've gained real >implementation and deployment experience. The drafts could be Experimental. The question would be what to do once there is real implementation and deployment experience. It may end up as a problem for others to solve. I am not against what you suggested above. Regards, -sm From jyee@afilias.info Wed Mar 14 07:14:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4825E21F87B5 for ; Wed, 14 Mar 2012 07:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu3Q-3BecqYI for ; Wed, 14 Mar 2012 07:14:45 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2E521F87B0 for ; Wed, 14 Mar 2012 07:14:38 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S7oyM-0006qd-7g for ima@ietf.org; Wed, 14 Mar 2012 14:14:38 +0000 Received: from mail-vx0-f178.google.com ([209.85.220.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S7oyM-0002lS-3x for ima@ietf.org; Wed, 14 Mar 2012 14:14:38 +0000 Received: by vcbfo1 with SMTP id fo1so2124350vcb.9 for ; Wed, 14 Mar 2012 07:14:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Sz/JbS398rcaeWfsBsvLjIUf24Qv5Nl7qLdNK0UbI50=; b=TO1BnYZuT3oZpqTHzniGxHFTBjZKbwZyPMOp5KHmn6FDNt5dIJ21rikD0qiQcatS8l dhT2yxYXfWxpE7mSp1IModyj3CGlTPzQZE3/6Lc8iCmknmvajDkKJOxCBIvufEsBG4S6 W+MfcKCDULLIBqVkMTxUZy49davkCWKsH3IAu5HAzJ7A6Hqoe7JzboWIlLsFcLSaIrs4 ObTbZAsCpt1buWDpdwpLjPd1TRX0esbVm56V+Y6Ek5dCbqD1F44f5a2y0h/zFNt7a3Ov TR1RrYTFzXHjEKhV8NbmMXu8poIlMUz+shopvUvEQ2F/zRLQ/0v8oraJw2HA2QyE3YYi Tp8g== Received: by 10.52.26.14 with SMTP id h14mr1909967vdg.104.1331734477632; Wed, 14 Mar 2012 07:14:37 -0700 (PDT) Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id i20sm4380868vdh.2.2012.03.14.07.14.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 07:14:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <4F605997.6000004@gulbrandsen.priv.no> Date: Wed, 14 Mar 2012 10:14:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93D7BF05-1245-4EC1-9948-383F4299B7D0@afilias.info> References: <4F50ED61.4080706@gulbrandsen.priv.no> <80E97031DEDA757A75D1FB1D@96B2F16665FF96BAE59E9B90> <4F539012.90404@gulbrandsen.priv.no> <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQm0KuypRRMV0cg14TRaDpQh/NQ0LnyrYU9Vye5fAn2kSzijcC+dr/s4Ytgh4haVuqs4/fgR Cc: ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-simpledowngrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:14:46 -0000 On 2012-03-14, at 4:40 AM, Arnt Gulbrandsen wrote: > On 03/14/2012 07:11 AM, Joseph Yee wrote: >> Using .valid makes the message harder to be actionable, but not = completely (ie. bad DNS hacks). This is where I am more in favor in = Fujiwara's draft of empty list. (Yes, there are still tradeoffs). =20 >=20 > .invalid is already reserved by RFC 2606. We'd have to reserve .valid > using this document, I'm not sure how much work that would be. I fear > that without a clear and convincing reason it might lead to wearisome > discussion during IETF LC. >=20 My turn to say that I should learn to type, I want to type ".invalid" = rather than ".valid" Joseph >> Nits spotted: >> Section 2.2 >> s/atttribute/attribute/ >>=20 >> Section 2.4 >> "the modifications in sections 3.1 and 3.2 is silently excised" >> I believed that you mean sections 2.1 and 2.2? >=20 > I should learn to type. Fixed. >=20 > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Wed Mar 14 19:39:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403C711E8075 for ; Wed, 14 Mar 2012 19:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U49lSY6nQTb for ; Wed, 14 Mar 2012 19:39:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B240221F866C for ; Wed, 14 Mar 2012 19:39:28 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S80WT-00001v-KA; Wed, 14 Mar 2012 22:34:37 -0400 Date: Wed, 14 Mar 2012 22:39:21 -0400 From: John C Klensin To: SM , Arnt Gulbrandsen Message-ID: <93A31E76C91A2CFA4C338973@PST.JCK.COM> In-Reply-To: <6.2.5.6.2.20120314064531.0a834bb8@resistor.net> References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> <20120314.180825.183027988.fujiwara@jprs.co.jp> <4F60689C.2030209@gulbrandsen.priv.no> <4F606C57.2030307@gulbrandsen.priv.no> <6.2.5.6.2.20120314064531.0a834bb8@resistor.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] two downgrade specs, I think X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:39:29 -0000 --On Wednesday, March 14, 2012 06:52 -0700 SM wrote: >> both drafts as RFCs and letting server authors choose >> according to inclination. >> >> I have my inclination, of course, but I can see sensible >> reasons why people might choose differently, and I don't >> think we gain very much by forcing this issue to be resolved >> before we've gained real implementation and deployment >> experience. > > The drafts could be Experimental. The question would be what > to do once there is real implementation and deployment > experience. It may end up as a problem for others to solve. > I am not against what you suggested above. Speaking both personally and as co-chair, I would really like to avoid producing more Experimental documents that others have to come back and clean up later. That is particularly true in this situation because: (1) for possibly-further-refined of the two downgrade specs, it is pretty easy to achieve the Proposed Standard criterion of "no known defects". We really do understand POP and IMAP well enough to know what would or would not cause nasty surprises as already evidenced by discussion on this list. (2) I think it is extremely unlikely that implementation and deployment of these specs will tell us anything we don't know today, namely that both can be implemented, one is harder to implement than the other(s), and difference situations and circumstances will dictate different uses. We might learn a bit about the percentages, but knowing that one approach is applicable to a somewhat larger number of situations than another is not an appropriate basis for recommending for one and against the other. So, unless someone has a really good reason that they are prepared to share (and "could be Experimental" is not a reason), I think we should just move ahead. thanks, john From klensin@jck.com Wed Mar 14 19:55:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA81111E8075 for ; Wed, 14 Mar 2012 19:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeJzJLFvR4Oe for ; Wed, 14 Mar 2012 19:55:39 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03211E8074 for ; Wed, 14 Mar 2012 19:55:39 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S80m9-00002h-S0 for ima@ietf.org; Wed, 14 Mar 2012 22:50:49 -0400 Date: Wed, 14 Mar 2012 22:55:33 -0400 From: John C Klensin To: EAI WG Message-ID: <02891AC16204094690A8CC41@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] IETF 83 (Paris) EAI meeting and follow-on Interim Meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:55:40 -0000 Hi. In my March 2 "Status of the EAI effort" note, I discussed conditions for holding a WG meeting in Paris. Those conditions, particularly the one that people identify specific issues that have been discussed on-list and for which a f2f discussion would help, have not been met. So we are canceling the meeting slot in Paris, Anyone who feels either that this is a serious mistake or that the cancellation after the earlier request/warning is an abuse of procedure has 24 hours to complain. After that time, we will notify the Secretariat to free up the slot. Somewhat as an alternative to a face to face meeting in Paris, we'd like to schedule an interim Jabber-based meeting around the third week in April with the intention of using it to resolve any outstanding issues on the four POP/IMAP drafts (POP, IMAP, both "downgrades"). That means authors who have been accumulation issues or responses should plan on having new versions posted no later than April 16 (and preferably by the April 13) and that people should be sure they have read things carefully enough to identify any issue and have a reasonable discussion of them. You can consider that a one-week preliminary WG Last Call on all four documents starting on April 16. Joseph will put out a Doodle Poll for convenient times within the next few days. Given how many time zones participants in this WG spread over, some people should think in terms of being up either very early or very late. best, john From yaojk@cnnic.cn Thu Mar 15 18:20:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0497121F85F0 for ; Thu, 15 Mar 2012 18:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.409 X-Spam-Level: X-Spam-Status: No, score=-100.409 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrHl2r3ekggH for ; Thu, 15 Mar 2012 18:20:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 9AEA821F85EC for ; Thu, 15 Mar 2012 18:20:22 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 16 Mar 2012 09:20:20 +0800 Message-ID: <9D98B212D5814DB4BDE02A6B8E7D6A26@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , "SM" , "Arnt Gulbrandsen" References: <4F539230.3080808@gulbrandsen.priv.no><003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info><4F605997.6000004@gulbrandsen.priv.no><20120314.180825.183027988.fujiwara@jprs.co.jp><4F60689C.2030209@gulbrandsen.priv.no><4F606C57.2030307@gulbrandsen.priv.no><6.2.5.6.2.20120314064531.0a834bb8@resistor.net> <93A31E76C91A2CFA4C338973@PST.JCK.COM> Date: Fri, 16 Mar 2012 09:20:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ima@ietf.org Subject: Re: [EAI] two downgrade specs, I think X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:20:25 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJTTSIgPHNtQHJlc2lzdG9yLm5ldD47ICJBcm50IEd1bGJy YW5kc2VuIiA8YXJudEBndWxicmFuZHNlbi5wcml2Lm5vPg0KQ2M6IDxpbWFAaWV0Zi5vcmc+DQpT ZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMTIgMTA6MzkgQU0NClN1YmplY3Q6IFJlOiBbRUFJ XSB0d28gZG93bmdyYWRlIHNwZWNzLCBJIHRoaW5rDQoNCg0KPiANCj4gDQo+IC0tT24gV2VkbmVz ZGF5LCBNYXJjaCAxNCwgMjAxMiAwNjo1MiAtMDcwMCBTTSA8c21AcmVzaXN0b3IubmV0Pg0KPiB3 cm90ZToNCj4gDQo+Pj4gYm90aCBkcmFmdHMgYXMgUkZDcyBhbmQgbGV0dGluZyBzZXJ2ZXIgYXV0 aG9ycyBjaG9vc2UNCj4+PiBhY2NvcmRpbmcgdG8gaW5jbGluYXRpb24uDQo+Pj4gDQo+Pj4gSSBo YXZlIG15IGluY2xpbmF0aW9uLCBvZiBjb3Vyc2UsIGJ1dCBJIGNhbiBzZWUgc2Vuc2libGUNCj4+ PiByZWFzb25zIHdoeSBwZW9wbGUgbWlnaHQgY2hvb3NlIGRpZmZlcmVudGx5LCBhbmQgSSBkb24n dA0KPj4+IHRoaW5rIHdlIGdhaW4gdmVyeSBtdWNoIGJ5IGZvcmNpbmcgdGhpcyBpc3N1ZSB0byBi ZSByZXNvbHZlZA0KPj4+IGJlZm9yZSB3ZSd2ZSBnYWluZWQgcmVhbCBpbXBsZW1lbnRhdGlvbiBh bmQgZGVwbG95bWVudA0KPj4+IGV4cGVyaWVuY2UuDQo+PiANCj4+IFRoZSBkcmFmdHMgY291bGQg YmUgRXhwZXJpbWVudGFsLiAgVGhlIHF1ZXN0aW9uIHdvdWxkIGJlIHdoYXQNCj4+IHRvIGRvIG9u Y2UgdGhlcmUgaXMgcmVhbCBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudA0KPj4gZXhwZXJp ZW5jZS4gIEl0IG1heSBlbmQgdXAgYXMgYSBwcm9ibGVtIGZvciBvdGhlcnMgdG8gc29sdmUuDQo+ PiBJIGFtIG5vdCBhZ2FpbnN0IHdoYXQgeW91IHN1Z2dlc3RlZCBhYm92ZS4NCj4gDQo+IFNwZWFr aW5nIGJvdGggcGVyc29uYWxseSBhbmQgYXMgY28tY2hhaXIsIEkgd291bGQgcmVhbGx5IGxpa2Ug dG8NCj4gYXZvaWQgcHJvZHVjaW5nIG1vcmUgRXhwZXJpbWVudGFsIGRvY3VtZW50cyB0aGF0IG90 aGVycyBoYXZlIHRvDQo+IGNvbWUgYmFjayBhbmQgY2xlYW4gdXAgbGF0ZXIuICBUaGF0IGlzIHBh cnRpY3VsYXJseSB0cnVlIGluIHRoaXMNCj4gc2l0dWF0aW9uIGJlY2F1c2U6DQo+IA0KPiAoMSkg Zm9yIHBvc3NpYmx5LWZ1cnRoZXItcmVmaW5lZCBvZiB0aGUgdHdvIGRvd25ncmFkZSBzcGVjcywg aXQNCj4gaXMgcHJldHR5IGVhc3kgdG8gYWNoaWV2ZSB0aGUgUHJvcG9zZWQgU3RhbmRhcmQgY3Jp dGVyaW9uIG9mICJubw0KPiBrbm93biBkZWZlY3RzIi4gIFdlIHJlYWxseSBkbyB1bmRlcnN0YW5k IFBPUCBhbmQgSU1BUCB3ZWxsDQo+IGVub3VnaCB0byBrbm93IHdoYXQgd291bGQgb3Igd291bGQg bm90IGNhdXNlIG5hc3R5IHN1cnByaXNlcyBhcw0KPiBhbHJlYWR5IGV2aWRlbmNlZCBieSBkaXNj dXNzaW9uIG9uIHRoaXMgbGlzdC4NCj4gDQo+ICgyKSBJIHRoaW5rIGl0IGlzIGV4dHJlbWVseSB1 bmxpa2VseSB0aGF0IGltcGxlbWVudGF0aW9uIGFuZA0KPiBkZXBsb3ltZW50IG9mIHRoZXNlIHNw ZWNzIHdpbGwgdGVsbCB1cyBhbnl0aGluZyB3ZSBkb24ndCBrbm93DQo+IHRvZGF5LCBuYW1lbHkg dGhhdCBib3RoIGNhbiBiZSBpbXBsZW1lbnRlZCwgb25lIGlzIGhhcmRlciB0bw0KPiBpbXBsZW1l bnQgdGhhbiB0aGUgb3RoZXIocyksIGFuZCBkaWZmZXJlbmNlIHNpdHVhdGlvbnMgYW5kDQo+IGNp cmN1bXN0YW5jZXMgd2lsbCBkaWN0YXRlIGRpZmZlcmVudCB1c2VzLiAgV2UgbWlnaHQgbGVhcm4g YSBiaXQNCj4gYWJvdXQgdGhlIHBlcmNlbnRhZ2VzLCBidXQga25vd2luZyB0aGF0IG9uZSBhcHBy b2FjaCBpcw0KPiBhcHBsaWNhYmxlIHRvIGEgc29tZXdoYXQgbGFyZ2VyIG51bWJlciBvZiBzaXR1 YXRpb25zIHRoYW4NCj4gYW5vdGhlciBpcyBub3QgYW4gYXBwcm9wcmlhdGUgYmFzaXMgZm9yIHJl Y29tbWVuZGluZyBmb3Igb25lIGFuZA0KPiBhZ2FpbnN0IHRoZSBvdGhlci4NCj4gDQo+IFNvLCB1 bmxlc3Mgc29tZW9uZSBoYXMgYSByZWFsbHkgZ29vZCByZWFzb24gdGhhdCB0aGV5IGFyZQ0KPiBw cmVwYXJlZCB0byBzaGFyZSAoYW5kICJjb3VsZCBiZSBFeHBlcmltZW50YWwiIGlzIG5vdCBhIHJl YXNvbiksDQo+IEkgdGhpbmsgd2Ugc2hvdWxkIGp1c3QgbW92ZSBhaGVhZC4NCj4gDQoNCnllcywg ICsxLg0KDQpKaWFua2FuZyBZYW8NCg0KPiAgIHRoYW5rcywNCj4gICAgam9obg0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBt YWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaW1h From yaojk@cnnic.cn Thu Mar 15 18:33:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDDE21E8056 for ; Thu, 15 Mar 2012 18:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.686 X-Spam-Level: X-Spam-Status: No, score=-99.686 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YIJLraFENCd for ; Thu, 15 Mar 2012 18:33:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8AEDF21E8049 for ; Thu, 15 Mar 2012 18:33:15 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 16 Mar 2012 09:32:57 +0800 Message-ID: <18B70568C0584E62900D5A4B6D468E0A@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , "EAI WG" References: <02891AC16204094690A8CC41@PST.JCK.COM> Date: Fri, 16 Mar 2012 09:32:56 +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.6157 Subject: Re: [EAI] IETF 83 (Paris) EAI meeting and follow-on Interim Meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:33:17 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJFQUkgV0ciIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVy c2RheSwgTWFyY2ggMTUsIDIwMTIgMTA6NTUgQU0NClN1YmplY3Q6IFtFQUldIElFVEYgODMgKFBh cmlzKSBFQUkgbWVldGluZyBhbmQgZm9sbG93LW9uIEludGVyaW0gTWVldGluZw0KDQoNCj4gSGku DQo+IA0KPiBJbiBteSBNYXJjaCAyICJTdGF0dXMgb2YgdGhlIEVBSSBlZmZvcnQiIG5vdGUsIEkg ZGlzY3Vzc2VkDQo+IGNvbmRpdGlvbnMgZm9yIGhvbGRpbmcgYSBXRyBtZWV0aW5nIGluIFBhcmlz LiAgVGhvc2UgY29uZGl0aW9ucywNCj4gcGFydGljdWxhcmx5IHRoZSBvbmUgdGhhdCBwZW9wbGUg aWRlbnRpZnkgc3BlY2lmaWMgaXNzdWVzIHRoYXQNCj4gaGF2ZSBiZWVuIGRpc2N1c3NlZCBvbi1s aXN0IGFuZCBmb3Igd2hpY2ggYSBmMmYgZGlzY3Vzc2lvbiB3b3VsZA0KPiBoZWxwLCBoYXZlIG5v dCBiZWVuIG1ldC4gIFNvIHdlIGFyZSBjYW5jZWxpbmcgdGhlIG1lZXRpbmcgc2xvdA0KPiBpbiBQ YXJpcywNCj4gDQo+IEFueW9uZSB3aG8gZmVlbHMgZWl0aGVyIHRoYXQgdGhpcyBpcyBhIHNlcmlv dXMgbWlzdGFrZSBvciB0aGF0DQo+IHRoZSBjYW5jZWxsYXRpb24gYWZ0ZXIgdGhlIGVhcmxpZXIg cmVxdWVzdC93YXJuaW5nIGlzIGFuIGFidXNlDQo+IG9mIHByb2NlZHVyZSBoYXMgMjQgaG91cnMg dG8gY29tcGxhaW4uICBBZnRlciB0aGF0IHRpbWUsIHdlIHdpbGwNCj4gbm90aWZ5IHRoZSBTZWNy ZXRhcmlhdCB0byBmcmVlIHVwIHRoZSBzbG90Lg0KPiANCj4gU29tZXdoYXQgYXMgYW4gYWx0ZXJu YXRpdmUgdG8gYSBmYWNlIHRvIGZhY2UgbWVldGluZyBpbiBQYXJpcywNCj4gd2UnZCBsaWtlIHRv IHNjaGVkdWxlIGFuIGludGVyaW0gSmFiYmVyLWJhc2VkIG1lZXRpbmcgYXJvdW5kIHRoZQ0KPiB0 aGlyZCB3ZWVrIGluIEFwcmlsIHdpdGggdGhlIGludGVudGlvbiBvZiB1c2luZyBpdCB0byByZXNv bHZlDQo+IGFueSBvdXRzdGFuZGluZyBpc3N1ZXMgb24gdGhlIGZvdXIgUE9QL0lNQVAgZHJhZnRz IChQT1AsIElNQVAsDQo+IGJvdGggImRvd25ncmFkZXMiKS4gICBUaGF0IG1lYW5zIGF1dGhvcnMg d2hvIGhhdmUgYmVlbg0KPiBhY2N1bXVsYXRpb24gaXNzdWVzIG9yIHJlc3BvbnNlcyBzaG91bGQg cGxhbiBvbiBoYXZpbmcgbmV3DQo+IHZlcnNpb25zIHBvc3RlZCBubyBsYXRlciB0aGFuIEFwcmls IDE2IChhbmQgcHJlZmVyYWJseSBieSB0aGUNCj4gQXByaWwgMTMpIGFuZCB0aGF0IHBlb3BsZSBz aG91bGQgYmUgc3VyZSB0aGV5IGhhdmUgcmVhZCB0aGluZ3MNCj4gY2FyZWZ1bGx5IGVub3VnaCB0 byBpZGVudGlmeSBhbnkgaXNzdWUgYW5kIGhhdmUgYSByZWFzb25hYmxlDQo+IGRpc2N1c3Npb24g b2YgdGhlbS4gICBZb3UgY2FuIGNvbnNpZGVyIHRoYXQgYSBvbmUtd2Vlaw0KPiBwcmVsaW1pbmFy eSBXRyBMYXN0IENhbGwgb24gYWxsIGZvdXIgZG9jdW1lbnRzIHN0YXJ0aW5nIG9uIEFwcmlsDQo+ IDE2Lg0KPiANCnBvcCBoYXMgZmluaXNoZWQgYSB3Z2xjLiBpbWFwIGhhcyBnb3R0ZW4gaW50ZW5z aXZlIGNvbW1lbnRzIGR1cmluZyBsYXN0IGlldGYgbWVldGluZy4NCg0KYm90aCAiZG93bmdyYWRl cyIgIGFyZSB0aGUgbmV3IHZlc2lvbnMgbm93LiANCkkgdGhpbmsgdGhhdCBjaGFpcnMgY2FuIGlz c3VlICJjYWxsIGZvciBjb21tZW50cyIgIGF0IGZpcnN0LCB0aGVuIGJlZm9yZSAxMyBBcHJpbCwg dGhlIGF1dGhvcnMvZWRpdG9ycyBjYW4gdXBkYXRlIG9uZSBtb3JlIHZlcnNpb24gYmFzZWQgb24g dGhlIGNvbW1lbnRzIHJlY2VpdmVkLg0KDQoNCg0KPiBKb3NlcGggd2lsbCBwdXQgb3V0IGEgRG9v ZGxlIFBvbGwgZm9yIGNvbnZlbmllbnQgdGltZXMgd2l0aGluDQo+IHRoZSBuZXh0IGZldyBkYXlz LiAgIEdpdmVuIGhvdyBtYW55IHRpbWUgem9uZXMgcGFydGljaXBhbnRzIGluDQo+IHRoaXMgV0cg c3ByZWFkIG92ZXIsIHNvbWUgcGVvcGxlIHNob3VsZCB0aGluayBpbiB0ZXJtcyBvZiBiZWluZw0K PiB1cCBlaXRoZXIgdmVyeSBlYXJseSBvciB2ZXJ5IGxhdGUuDQo+IA0KDQpJIGxpa2UgRG9vZGxl IFBvbGwuDQoNCjopDQoNCkppYW5rYW5nIFlhbw0KDQo+IGJlc3QsDQo+ICAgIGpvaG4NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBt YWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaW1h From duerst@it.aoyama.ac.jp Sat Mar 17 07:02:30 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FB121F867A for ; Sat, 17 Mar 2012 07:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.301 X-Spam-Level: X-Spam-Status: No, score=-100.301 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhwR+F2hJ1p8 for ; Sat, 17 Mar 2012 07:02:30 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74021F8670 for ; Sat, 17 Mar 2012 07:02:29 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2HE2JRI004255 for ; Sat, 17 Mar 2012 23:02:19 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 28b4_c730_cf4d88e6_7039_11e1_8310_001d096c566a; Sat, 17 Mar 2012 23:02:19 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54067) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 17 Mar 2012 23:02:23 +0900 Message-ID: <4F649967.7040403@it.aoyama.ac.jp> Date: Sat, 17 Mar 2012 23:02:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:02:30 -0000 While investigating on how to implement a TODO in the updated mailto: draft (http://tools.ietf.org/html/draft-duerst-eai-mailto-02.txt), I stumbled upon the following in RFC 6531 (Section 3.3, page 8): sub-domain =/ U-label atext =/ UTF8-non-ascii (same for qtextSMTP, esmtp-value) This is highly problematic, because it mixes apples and oranges, or characters and bytes, to be precise (see further below for details). In other words, it's a layer violation. While I *hope* that implementers may still get this right, I plan to submit an erratum, which does two things: - Says clearly that the ABNF is in terms of characters (or alternatively bytes) - Fixes one or the other of the definitions to allign the layers. Before submitting an official erratum, I wanted to check with the WG for possible explanations/preferences. Here are the details: U-label is defined as a string of Unicode characters at http://tools.ietf.org/html/rfc5890#section-2.3.2.1: A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). On the other hand, UTF-8-non-ascii is defined in Section 3.1 of RFC 6532, as follows: UTF-8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = UTF8-3 = UTF8-4 = And in Section 4 of RFC 3629, we find: UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail ) UTF8-tail = %x80-BF Which is all in bytes (because that's what an encoding definition is about). Regards, Martin. From yaojk@cnnic.cn Sat Mar 17 07:16:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F9D21F8644 for ; Sat, 17 Mar 2012 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.842 X-Spam-Level: X-Spam-Status: No, score=-99.842 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSD0-6pn5NTO for ; Sat, 17 Mar 2012 07:16:54 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 03CD921F8674 for ; Sat, 17 Mar 2012 07:16:47 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 17 Mar 2012 22:16:42 +0800 Message-ID: <002301cd0448$9389a400$cb01a8c0@computer> From: "Jiankang Yao" To: =?iso-8859-1?Q?=22Martin_J._D=FCrst=22?= , References: <4F649967.7040403@it.aoyama.ac.jp> Date: Sat, 17 Mar 2012 22:16:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit 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] Erratum? Mixing character-based and byte based ABNF in RFC6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:16:55 -0000 In RFC6531 section 1.1. Terminology there is a sentence below " Strings referred to in this document, including ASCII strings, MUST be expressed in UTF-8. " It means that U-label must be expressed as UTF-8. Doe it solve your concern? Jiankang Yao ----- Original Message ----- From: ""Martin J. Dürst"" To: Sent: Saturday, March 17, 2012 10:02 PM Subject: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC6531 > While investigating on how to implement a TODO in the updated mailto: > draft (http://tools.ietf.org/html/draft-duerst-eai-mailto-02.txt), I > stumbled upon the following in RFC 6531 (Section 3.3, page 8): > > sub-domain =/ U-label > > atext =/ UTF8-non-ascii > (same for qtextSMTP, esmtp-value) > > This is highly problematic, because it mixes apples and oranges, or > characters and bytes, to be precise (see further below for details). In > other words, it's a layer violation. > > While I *hope* that implementers may still get this right, I plan to > submit an erratum, which does two things: > > - Says clearly that the ABNF is in terms of characters (or > alternatively bytes) > > - Fixes one or the other of the definitions to allign the layers. > > Before submitting an official erratum, I wanted to check with the WG for > possible explanations/preferences. > > Here are the details: U-label is defined as a string of Unicode characters > at http://tools.ietf.org/html/rfc5890#section-2.3.2.1: > > A "U-label" is an IDNA-valid string of Unicode characters, in > Normalization Form C (NFC) and including at least one non-ASCII > character, expressed in a standard Unicode Encoding Form (such as > UTF-8). > > On the other hand, UTF-8-non-ascii is defined in Section 3.1 of RFC 6532, > as follows: > > UTF-8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 > > UTF8-2 = > > UTF8-3 = > > UTF8-4 = > > And in Section 4 of RFC 3629, we find: > > UTF8-2 = %xC2-DF UTF8-tail > > UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / > %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) > UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / > %xF4 %x80-8F 2( UTF8-tail ) > UTF8-tail = %x80-BF > > Which is all in bytes (because that's what an encoding definition is > about). > > Regards, Martin. > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Sat Mar 17 09:47:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED63A21F8685 for ; Sat, 17 Mar 2012 09:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ5L6sXtipBU for ; Sat, 17 Mar 2012 09:47:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 068E521F866D for ; Sat, 17 Mar 2012 09:47:15 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S8whv-0006FM-Vb; Sat, 17 Mar 2012 12:42:19 -0400 Date: Sat, 17 Mar 2012 12:47:08 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , ima@ietf.org Message-ID: In-Reply-To: <4F649967.7040403@it.aoyama.ac.jp> References: <4F649967.7040403@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 16:47:16 -0000 Martin, While I think there are a number of things in RFC 6531 that could be expressed better (I think those who would like to see an Internet Standard version in September might reasonably start working on edits now ... although I'd rather see reviews of the pending set of documents), I'm not sure I see an actual error here. Certainly you are correct that U-labels are defined in IDNA as a list of Unicode code points, independent of encoding. IDNA itself is a layer (or half-layer) below anything in any of the base SMTPUTF8 documents, including RFC 6531. But the EAI WG made a very explicit decision that anything that went on the wire was required to be in UTF-8. If we were writing prose, it would be reasonable to express the rule as something like "... MUST be a U-label and any U-labels used in conformance with this standard MUST be encoded in UTF-8". =20 The best way to express that in ABNF is a separate question. Personally, I think we are sooner or later going to have to open RFC 5234 and add some rules to deal smoothly with characters outside the ASCII range and with the difference between character-abstractions and particular encodings. But those are not problems that 6531 can solve. I look forward to your erratum, but will push for it to be classified as "hold for document update". If Jiankang or others responded to it by creating a "needs to be revised to clarify how a collection of i18n issues should be handled" proposed erratum to 5234, that would be only fitting. The "mailto:" issue ultimately involves the same abstraction versus expression/encoding issues that, IMO, are the weak underbelly of the IRI work. If you want to adhere to the letter and spirit of RFC 6531 (and SMTPUTF8 generally), you are stuck with normalized UTF-8 encoding -- no A-labels and no other Unicode encoding forms. If you think that "mailto:" should represent a different layer of abstraction, e.g., whatever the IRI abstraction du jour happens to be, then go back to code points and let RFC 6531 and similar documents impose the encoding restrictions. (speaking only for myself, I hope obviously) john --On Saturday, March 17, 2012 23:02 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: > While investigating on how to implement a TODO in the updated > mailto: draft > (http://tools.ietf.org/html/draft-duerst-eai-mailto-02.txt), I > stumbled upon the following in RFC 6531 (Section 3.3, page 8): >=20 > sub-domain =3D/ U-label >=20 > atext =3D/ UTF8-non-ascii > (same for qtextSMTP, esmtp-value) >=20 > This is highly problematic, because it mixes apples and > oranges, or characters and bytes, to be precise (see further > below for details). In other words, it's a layer violation. >=20 > While I *hope* that implementers may still get this right, I > plan to submit an erratum, which does two things: >=20 > - Says clearly that the ABNF is in terms of characters (or > alternatively bytes) >=20 > - Fixes one or the other of the definitions to allign the > layers. >=20 > Before submitting an official erratum, I wanted to check with > the WG for possible explanations/preferences. >=20 > Here are the details: U-label is defined as a string of > Unicode characters at > http://tools.ietf.org/html/rfc5890#section-2.3.2.1: >=20 > A "U-label" is an IDNA-valid string of Unicode > characters, in > Normalization Form C (NFC) and including at least one > non-ASCII > character, expressed in a standard Unicode Encoding > Form (such as > UTF-8). >=20 > On the other hand, UTF-8-non-ascii is defined in Section 3.1 > of RFC 6532, as follows: >=20 > UTF-8-non-ascii =3D UTF8-2 / UTF8-3 / UTF8-4 >=20 > UTF8-2 =3D >=20 > UTF8-3 =3D >=20 > UTF8-4 =3D >=20 > And in Section 4 of RFC 3629, we find: >=20 > UTF8-2 =3D %xC2-DF UTF8-tail >=20 > UTF8-3 =3D %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( > UTF8-tail ) / > %xED %x80-9F UTF8-tail / %xEE-EF 2( > UTF8-tail ) > UTF8-4 =3D %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( > UTF8-tail ) / > %xF4 %x80-8F 2( UTF8-tail ) > UTF8-tail =3D %x80-BF >=20 > Which is all in bytes (because that's what an encoding > definition is about). >=20 > Regards, Martin. > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From ned+ima@mrochek.com Sat Mar 17 14:22:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DBE21F86BB for ; Sat, 17 Mar 2012 14:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqqmkfbrXW0U for ; Sat, 17 Mar 2012 14:22:51 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDC321F86BA for ; Sat, 17 Mar 2012 14:22:51 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD84GPHBGG016XNK@mauve.mrochek.com> for ima@ietf.org; Sat, 17 Mar 2012 14:22:46 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD80OS20WG008FFR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 17 Mar 2012 14:22:40 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OD84GMFYMA008FFR@mauve.mrochek.com> Date: Sat, 17 Mar 2012 13:29:09 -0700 (PDT) In-reply-to: "Your message dated Sat, 17 Mar 2012 12:47:08 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 References: <4F649967.7040403@it.aoyama.ac.jp> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1332019374; bh=8OCGmqYLHv/aqS2876/O1wFqNG67cEoO+bGZH06+J8Y=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=itBt+qv1N7WB2ZrbqfTlM/G5JtpqhrwPncINFkdyEyH8KRkzTyCplx98ZzWB3XlvW /IiDgTU8tQgj45/jdLzFybHlSTssF5UiWtzZJ+lCEsPUAv5lXfImDq/r0b1VLgh8Nk oyAHIlEYj76GC4IUsITxhnkI5ugz+it9nGoHaEe0= Cc: ima@ietf.org Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 21:22:52 -0000 > While I think there are a number of things in RFC 6531 that > could be expressed better (I think those who would like to see > an Internet Standard version in September might reasonably start > working on edits now ... although I'd rather see reviews of the > pending set of documents), I'm not sure I see an actual error > here. Neither do I. While it is nice to talk about layering of ABNF, I see nothing in this document (or most others, for that matter) that states that any such layering has been defined and therefore must be respected. You may want that layering for some purpose of your own in some other document, but the time is long since past to add such a thing to this revision of this set of documents. And even if this is the only place that needs to change in order to make the layering work (unlikely), it's completely inappropriate to attempt to add what amounts to a new feature in an erratum. The only possible issue I see is that the u-label definition allows any sort of encoding of the actual characters. Frankly, I'd call that a bug in the definition of u-label itself since IMO ABNF should always resolve down to the actual sequence of octets, but as John notes below, this specification repeatedly states that utf-8 is the only encoding we're using, so there's no strong need to restate it here. > Certainly you are correct that U-labels are defined in IDNA as a > list of Unicode code points, independent of encoding. IDNA > itself is a layer (or half-layer) below anything in any of the > base SMTPUTF8 documents, including RFC 6531. But the EAI WG > made a very explicit decision that anything that went on the > wire was required to be in UTF-8. If we were writing prose, it > would be reasonable to express the rule as something like "... > MUST be a U-label and any U-labels used in conformance with this > standard MUST be encoded in UTF-8". > The best way to express that in ABNF is a separate question. > Personally, I think we are sooner or later going to have to open > RFC 5234 and add some rules to deal smoothly with characters > outside the ASCII range and with the difference between > character-abstractions and particular encodings. But those are > not problems that 6531 can solve. Agreed. > I look forward to your erratum, but will push for it to be > classified as "hold for document update". If Jiankang or others > responded to it by creating a "needs to be revised to clarify > how a collection of i18n issues should be handled" proposed > erratum to 5234, that would be only fitting. I'm sorry, but I'm not as accepting as this - I don't think an erratum of the sort you appear to be proposing should be accepted, period. The last thing we need is to attempt to put in an ABNF layering in an implicit and therefore half-assed way. What happens if some later change gets made and breaks the layering because nobody is paying attention to preserving it? If want to define a layering, it needs to be done explicitly and carefuly, and once added the entire document set needs to be reviewed to make sure we've done it consistently. (The WG will also have to agree to do it, of course.) I'll also note that RFC 6532 was written in a fashion to avoid this stuff entirely, and I'll push back hard on any attempt to add it there since I think it will only add unnecessary complexity to what has become, after considerable effort, a surprisingly simple document. More specifically, since the allowed characters in domain names resolve down to atext through atoms and atoms are allowed in lots of other contexts in header fields, attempting to impose u-label normalization restrictions or whatever on RFC 6532 domain names instantly buys us into the old ABNF approach that was soundly rejected as being much to complex to deal with. And besides, domains as defined in RFC 5322 already allow all sorts of characters that the DNS doesn't, so this is hardly a break with how things have been done previously. In fact one of the main differences between RFC 5322 and RFC 822 is the rejection of ABNF layering approach. I'm personally not entirely comfortable with that, mostly because I believe using a layered parsing approach simplifies implementation considerably, but there's no doubt the way it was done in RFC 822 was quite sloppy and it isn't clear to me that just trying to clean up that sloppiness would have resulted in a cleaner or simpler specification. (Of course this is entirely academic now - we're not going to change approaches at this point, just as we're not going to split productions apart in RFC 5322 to make RFC 6532's life easier.) Now, if you want to propose a very simple erratum that clarifies that the use of u-label uses the utf-8 encoding, I'm not really sure it's necessary but I will support doing that. > The "mailto:" issue ultimately involves the same abstraction > versus expression/encoding issues that, IMO, are the weak > underbelly of the IRI work. If you want to adhere to the letter > and spirit of RFC 6531 (and SMTPUTF8 generally), you are stuck > with normalized UTF-8 encoding -- no A-labels and no other > Unicode encoding forms. If you think that "mailto:" should > represent a different layer of abstraction, e.g., whatever the > IRI abstraction du jour happens to be, then go back to code > points and let RFC 6531 and similar documents impose the > encoding restrictions. Exactly. While it is always nice if a given specification is done in a way that makes it easier to write other specifications, it is in no way incumbent on them that they do so. And in this particular case the issue should have been raised well over a year ago. I'll also add that my sympathy level is low to nonexistent because this happens to all of us all the time, and most of us have learned to suck it up and move on. The lack of separate productions for some things RFC 5322 is a case in point - having those would have made RFC 6532 much easier to write, but you didn't hear us asking to reopen RFC 5322. In fact entire standards efforts, including some that involved a huge amount of time and effort, have been consigned to the dustbin in part because of a failure to pay attention to the details of comtemporaneous standards development. The obvious example here is PEM - had PEM paid attention to MIME it might possibly have made the development of S/MIME unnecessary. But it didn't, and the rest is history. There are also times where you get lucky, like when MARF wanted to remove some restrictions on multipart/report. It happened at a time when the DSN document suite was being revised anyway and the change actually fixed an issue in DSN usage while not being overly onerous to make, so in the end everything worked out. But you cannot count on this happening, although it's nice when it does. Ned From klensin@jck.com Sat Mar 17 15:33:04 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CF521F860F for ; Sat, 17 Mar 2012 15:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.754 X-Spam-Level: X-Spam-Status: No, score=-3.754 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ucBcfAMJRPs for ; Sat, 17 Mar 2012 15:33:04 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1C21F85AA for ; Sat, 17 Mar 2012 15:33:03 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S926Y-0006bu-Ed; Sat, 17 Mar 2012 18:28:06 -0400 Date: Sat, 17 Mar 2012 18:32:59 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01OD84GMFYMA008FFR@mauve.mrochek.com> References: <4F649967.7040403@it.aoyama.ac.jp> <01OD84GMFYMA008FFR@mauve.mrochek.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 22:33:04 -0000 --On Saturday, March 17, 2012 1:29 PM -0700 Ned Freed wrote: >... >> I look forward to your erratum, but will push for it to be >> classified as "hold for document update". If Jiankang or >> others responded to it by creating a "needs to be revised to >> clarify how a collection of i18n issues should be handled" >> proposed erratum to 5234, that would be only fitting. > > I'm sorry, but I'm not as accepting as this - I don't think an > erratum of the sort you appear to be proposing should be > accepted, period. The last thing we need is to attempt to put > in an ABNF layering in an implicit and therefore half-assed > way. What happens if some later change gets made and breaks the > layering because nobody is paying attention to preserving it? >... Ned, no real disagreement. I wouldn't mind having a placeholder that essentially says "next time these documents are opened, review this". I think there ought to be better ways to do that than with the errata files but, since we aren't keeping an issues tracker for published documents (and such a tracker would be pretty likely to get lost when we suspend or close the WG anyway), that may be the best we have (and fixing _that_ problem is definitely not something that is under EAI control). The result of looking at it might well be a conclusion that nothing else needs to be done or that some additional "only U-labels encoded in UTF-8" sentences are needed. I doubt that it would result in a conclusion that the ABNF needed to be changed unless some i18n changes had been made to ABNF first, but Martin could make a case for that at that time. I certainly did not mean to imply that changes to the ABNF were a foregone conclusion. >... > I'll also note that RFC 6532 was written in a fashion to avoid > this stuff entirely, and I'll push back hard on any attempt to > add it there since I think it will only add unnecessary > complexity to what has become, after considerable effort, a > surprisingly simple document. More specifically, since the > allowed characters in domain names resolve down to atext > through atoms and atoms are allowed in lots of other contexts > in header fields, attempting to impose u-label normalization > restrictions or whatever on RFC 6532 domain names instantly > buys us into the old ABNF approach that was soundly rejected > as being much to complex to deal with. And besides, domains as > defined in RFC 5322 already allow all sorts of characters that > the DNS doesn't, so this is hardly a break with how things > have been done previously. You could add that the "UTF-8 on the wire" restriction doesn't necessarily apply to the relationships between mail header fields and mail reading (POP, IMAP, Web, local, ...) software on a single system and that trying to cover the specific cases there would not only break many precedents but would be generally insane (or perhaps just a cause of insanity). >... > Now, if you want to propose a very simple erratum that > clarifies that the use of u-label uses the utf-8 encoding, I'm > not really sure it's necessary but I will support doing that. See above. >> The "mailto:" issue ultimately involves the same abstraction >> versus expression/encoding issues that, IMO, are the weak >> underbelly of the IRI work. If you want to adhere to the >> letter and spirit of RFC 6531 (and SMTPUTF8 generally), you >> are stuck with normalized UTF-8 encoding -- no A-labels and >> no other Unicode encoding forms. If you think that "mailto:" >> should represent a different layer of abstraction, e.g., >> whatever the IRI abstraction du jour happens to be, then go >> back to code points and let RFC 6531 and similar documents >> impose the encoding restrictions. > > Exactly. While it is always nice if a given specification is > done in a way that makes it easier to write other > specifications, it is in no way incumbent on them that they do > so. And in this particular case the issue should have been > raised well over a year ago. >... > There are also times where you get lucky, like when MARF > wanted to remove some restrictions on multipart/report. It > happened at a time when the DSN document suite was being > revised anyway and the change actually fixed an issue in DSN > usage while not being overly onerous to make, so in the end > everything worked out. But you cannot count on this happening, > although it's nice when it does. Of course, our diddling a bit with RFC 4409 message submission to explicitly permit remapping addresses in RFC 6409 in order to prevent an ugly situation in EAI is another example and one that is a bit closer to home. In a situation somewhat similar to the DSN one, YAM already had 4409 open; the EAI requirement certainly contributed to Randy and my getting motivated. I agree with your other comments as well. john From ned+ima@mrochek.com Sat Mar 17 15:36:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B421521F862B for ; Sat, 17 Mar 2012 15:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoYqdKDSRg-h for ; Sat, 17 Mar 2012 15:36:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3669E21F860F for ; Sat, 17 Mar 2012 15:36:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD870U9CXS0069QF@mauve.mrochek.com> for ima@ietf.org; Sat, 17 Mar 2012 15:36:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD80OS20WG008FFR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 17 Mar 2012 15:36:07 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OD870P7DJ2008FFR@mauve.mrochek.com> Date: Sat, 17 Mar 2012 15:35:36 -0700 (PDT) In-reply-to: "Your message dated Sat, 17 Mar 2012 18:32:59 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F649967.7040403@it.aoyama.ac.jp> <01OD84GMFYMA008FFR@mauve.mrochek.com> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1332023783; bh=jziGbIJwS1FB3MYG9l+fON7f6I1BUzuff6JbaTdrtV4=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=LoIdGGGa73Zq74PNSabXtRbcL7iOiwRHHv0k0oP4CLHbjuEbTZnbQhBHx2XdHDUiE xerb0ORxbYiYolj39sCPkkBybQSci3ZWLXsFw3wYGe/kNA+r1gDrchM9ThZUPT2s60 nbFtv0y5DZFWcYiEPqmksgxZfAc1fAqPlRdHHhas= Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 22:36:22 -0000 > --On Saturday, March 17, 2012 1:29 PM -0700 Ned Freed > wrote: > >... > >> I look forward to your erratum, but will push for it to be > >> classified as "hold for document update". If Jiankang or > >> others responded to it by creating a "needs to be revised to > >> clarify how a collection of i18n issues should be handled" > >> proposed erratum to 5234, that would be only fitting. > > > > I'm sorry, but I'm not as accepting as this - I don't think an > > erratum of the sort you appear to be proposing should be > > accepted, period. The last thing we need is to attempt to put > > in an ABNF layering in an implicit and therefore half-assed > > way. What happens if some later change gets made and breaks the > > layering because nobody is paying attention to preserving it? > >... > Ned, no real disagreement. I wouldn't mind having a placeholder > that essentially says "next time these documents are opened, > review this". I think there ought to be better ways to do that > than with the errata files but, since we aren't keeping an > issues tracker for published documents (and such a tracker would > be pretty likely to get lost when we suspend or close the WG > anyway), that may be the best we have (and fixing _that_ problem > is definitely not something that is under EAI control). > The result of looking at it might well be a conclusion that > nothing else needs to be done or that some additional "only > U-labels encoded in UTF-8" sentences are needed. I doubt that > it would result in a conclusion that the ABNF needed to be > changed unless some i18n changes had been made to ABNF first, > but Martin could make a case for that at that time. I > certainly did not mean to imply that changes to the ABNF were a > foregone conclusion. Placeholders are fine as long as there's no expectation that having accepted the erratum that something _will_ be done. Ned From klensin@jck.com Sat Mar 17 17:27:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789E721F85EA for ; Sat, 17 Mar 2012 17:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBtbVFPmFpjn for ; Sat, 17 Mar 2012 17:27:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9928921F85E0 for ; Sat, 17 Mar 2012 17:27:32 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S93tO-0006jO-2K; Sat, 17 Mar 2012 20:22:38 -0400 Date: Sat, 17 Mar 2012 20:13:38 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01OD870P7DJ2008FFR@mauve.mrochek.com> References: <4F649967.7040403@it.aoyama.ac.jp> <01OD84GMFYMA008FFR@mauve.mrochek.com> <01OD870P7DJ2008FFR@mauve.mrochek.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 00:27:33 -0000 --On Saturday, March 17, 2012 3:35 PM -0700 Ned Freed wrote: >> The result of looking at it might well be a conclusion that >> nothing else needs to be done or that some additional "only >> U-labels encoded in UTF-8" sentences are needed. I doubt >> that it would result in a conclusion that the ABNF needed to >> be changed unless some i18n changes had been made to ABNF >> first, but Martin could make a case for that at that time. I >> certainly did not mean to imply that changes to the ABNF were >> a foregone conclusion. > > Placeholders are fine as long as there's no expectation that > having > accepted the erratum that something _will_ be done. Something will be done. We will be sure to look at the question. If the answer turns out to be something similar to what you and I have been discussing, that will be the end of it... at least within my ability to affect things. But I agree with your implicit suggestion that any "hold for document revision" status should go in with an explicit comment that briefly summarizes this discussion and points back to the mailing list entries. john From jyee@afilias.info Sun Mar 18 20:46:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968D021F8557 for ; Sun, 18 Mar 2012 20:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3TXse4tAd4z for ; Sun, 18 Mar 2012 20:46:08 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id A861221F8555 for ; Sun, 18 Mar 2012 20:46:08 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S9TXr-0001bU-4J for ima@ietf.org; Mon, 19 Mar 2012 03:46:07 +0000 Received: from mail-iy0-f178.google.com ([209.85.210.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S9TXr-0007K2-6y for ima@ietf.org; Mon, 19 Mar 2012 03:46:07 +0000 Received: by iakl21 with SMTP id l21so9922061iak.9 for ; Sun, 18 Mar 2012 20:46:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer:x-gm-message-state; bh=RCYUHNE8IT9W1X0AKE/WqNwLI3dDCwP0CUT5NF6s0/c=; b=F7K3jfv8YUeHBWFlosviNUS9vncGQpJvCd74p9rR6NDExIOqCmuf3Oc+uPDy6VstKE vHpIjPvP8Hv+GDBW8YJr/sqXyODMZ+YMHAc8cDZ7SbB9HssrTcU/13YOiVQHGi5lmWUH HLnJX/h5/KUGoOIACpGq1mBrUTsCfRdcECqrHk/RSmQrdIt8qTTNGzp79EYWji1nRTOs Wn4vtsOh3BLMaDCnCqgBcEE2Y28ceqCO/ZJsV4DSAtmFrMe3GeXEiEJjYObK8iWCpIg6 YAOzWzsNqZKPQ6+9iFmydb283X7jM/B3TQK3IXn6R/ML200c7b6OkxvRqnN8Wv8D5PcW dFNQ== Received: by 10.43.126.68 with SMTP id gv4mr5913970icc.30.1332128766715; Sun, 18 Mar 2012 20:46:06 -0700 (PDT) Received: from [192.168.0.103] (206-248-164-23.dsl.teksavvy.com. [206.248.164.23]) by mx.google.com with ESMTPS id i6sm7590037igq.3.2012.03.18.20.46.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 20:46:04 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2012 23:46:02 -0400 To: "ima@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnsFpc3V7gCxXM5yuW+1uc7yloMc6wRHvrsegAU0JAq9SBulzpUXeV3APHTaadBercoiduo Subject: [EAI] Doodle poll for IETF EAI April 2012 Interim Meeting time X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 03:46:09 -0000 All, Please visit the doodle link below to let us know of your available time = so that we can schedule an interim jabber based meeting to discuss the = core documents (POP, IMAP, and both downgrades) and any outstanding = issue. Note, the range of the meeting time is the third week of April, and = given many participant located in either North American or East Asia, = most time were picked at either before typical work hours or after = typical work hours (unless you are in US west coast), and no weekend = (Saturday, Sunday) in anyone's timezone. If no good time were available = from first round, I will expand the range but it remains the third week = of April for now. Thanks. http://www.doodle.com/3stamymgmeht29fk Regards, Joseph Yee, co-chair of EAI= From duerst@it.aoyama.ac.jp Mon Mar 19 04:39:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12E721F84BF for ; Mon, 19 Mar 2012 04:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.286 X-Spam-Level: X-Spam-Status: No, score=-101.286 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YozSfYtJ29WH for ; Mon, 19 Mar 2012 04:39:32 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC621F84A1 for ; Mon, 19 Mar 2012 04:39:31 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2JBdLua025411 for ; Mon, 19 Mar 2012 20:39:21 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5aa0_6594_2b176a64_71b8_11e1_aeb5_001d096c5782; Mon, 19 Mar 2012 20:39:20 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33653) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Mar 2012 20:39:21 +0900 Message-ID: <4F671AE5.3070305@it.aoyama.ac.jp> Date: Mon, 19 Mar 2012 20:39:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <4F649967.7040403@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 11:39:33 -0000 Hello John, Many thanks to you and others for your comments. On 2012/03/18 1:47, John C Klensin wrote: > Martin, > > While I think there are a number of things in RFC 6531 that > could be expressed better (I think those who would like to see > an Internet Standard version in September might reasonably start > working on edits now ... although I'd rather see reviews of the > pending set of documents), These will be forthcomming, hopefully this week. I started with RFC 6530/1/2 because I hadn't looked at the base specs in a while and because I needed to look at them anyway for the mailto: spec (which, among many other things, actually is on the WG's charter). > I'm not sure I see an actual error > here. > > Certainly you are correct that U-labels are defined in IDNA as a > list of Unicode code points, independent of encoding. IDNA > itself is a layer (or half-layer) below anything in any of the > base SMTPUTF8 documents, including RFC 6531. But the EAI WG > made a very explicit decision that anything that went on the > wire was required to be in UTF-8. If we were writing prose, it > would be reasonable to express the rule as something like "... > MUST be a U-label and any U-labels used in conformance with this > standard MUST be encoded in UTF-8". Yes, indeed. > The best way to express that in ABNF is a separate question. My understanding so far is that the main purpose of ABNF is direct or indirect executability. Although ABNF can express context-free languages, in the bulk of uses in the IETF, there is no recursion among rules, and in these cases, conversion to regular expressions is often done. There lots of regular expression engines running on bytes, and there are many (sometimes the same ones) running on (Unicode or otherwise) characters, but I don't know of one where you could do both things at the same time. Maybe you do? > Personally, I think we are sooner or later going to have to open > RFC 5234 and add some rules to deal smoothly with characters > outside the ASCII range and with the difference between > character-abstractions and particular encodings. But those are > not problems that 6531 can solve. No need to worry. These problems are *already solved* at http://tools.ietf.org/html/rfc5234#section-2.3: >>>> 2.3. Terminal Values Rules resolve into a string of terminal values, sometimes called characters. In ABNF, a character is merely a non-negative integer. In certain contexts, a specific mapping (encoding) of values into a character set (such as ASCII) will be specified. >>>> (Also check out http://tools.ietf.org/html/rfc5234#section-2.4, but please note that this is about how ABNFs themselves are encoded, not about what they describe.) While we are at it, please also note that the word "octet" appears only two times in RFC 5234, as opposed to about 25 mentions of "character". Also, please note that this is not only theory, it has already been used, in http://tools.ietf.org/html/rfc3987#section-2.2, after due explanation: >>>> Character numbers are taken from the UCS, without implying any actual binary encoding. Terminals in the ABNF are characters, not bytes. >>>> ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD / %xD0000-DFFFD / %xE1000-EFFFD iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD >>>> Some ABNF checkers barked on some parts of the ABNF used there, but that was the checker's fault, not the ABNF's. > I look forward to your erratum, but will push for it to be > classified as "hold for document update". That would be fine by me. > If Jiankang or others > responded to it by creating a "needs to be revised to clarify > how a collection of i18n issues should be handled" proposed > erratum to 5234, that would be only fitting. No, it wouldn't, because there is no need to fix 5234. > The "mailto:" issue ultimately involves the same abstraction > versus expression/encoding issues that, IMO, are the weak > underbelly of the IRI work. I agree that insofar as "mailto:" is an URI/IRI scheme, it will share encoding "issues" with IRIs in general. That should come as no surprise. However, I have to clearly and strongly disagree with (casual or on-purpose) interjections such as "weak underbelly". I hope we can all avoid such terms in technical discussion. > If you want to adhere to the letter > and spirit of RFC 6531 (and SMTPUTF8 generally), you are stuck > with normalized UTF-8 encoding -- no A-labels and no other > Unicode encoding forms. I would expect that not only I, but also everybody else, will adhere to the letter and spirit of RFC 6531, which says that *in the SMTP protocol*, it's UTF-8 and UTF-8 only. Same for RFC 6532 and header fields *in transit*. However, in good IETF tradition, I'd expect that implementations of all kinds (MUAs, MTAs,...) have all the liberty they need to choose other encodings where that makes sense for them, as long as they respect the RFCs on the wire. I may even have seen wording to that effect in one or the other (or both) of the above RFCs, but I assumed that as a matter of course and so didn't pay enough attention to be sure about it. As just one concrete example, I would assume that an MUA written in Java would use UTF-16 to store email addresses in memory. > If you think that "mailto:" should > represent a different layer of abstraction, It's not that *I* think, it's that because the "mailto:" scheme is an URI/IRI scheme, it has to work like an URI/IRI scheme. Please note that this isn't just an IRI issue, the issue is present in URIs, too. Please see the first paragraph of http://tools.ietf.org/html/rfc3986#section-2. For an actual example, please think about an URI embedded in an EBCDIC-encoded text (for those not old enough to remember EBCDIC, please try with UTF-16). > e.g., whatever the > IRI abstraction du jour happens to be, I'm in danger of repeating myself, but I have to clearly and strongly disagree with (casual or on-purpose) interjections such as "abstraction du jour". I hope we can all avoid such terms in technical discussion. [To give everybody some background, the design alternatives listed in http://tools.ietf.org/html/rfc3987#appendix-A represent the state of circa 1995, and around that time included the current solution (which of course doesn't have to be listed in that appendix). As early as 1996 (mainly motivated by http://tools.ietf.org/html/draft-weider-iab-char-wrkshop-00), it was clear that the current solution was the right one. That's roughly 16 years ago.] > then go back to code > points and let RFC 6531 and similar documents impose the > encoding restrictions. To get back to my main original point: It's of course clear to me that it's RFC 6531 and friends that have to impose the encoding restrictions, because otherwise implementations are overly constrained and humans (mail addresses have to work on paper and soundwaves, too) can't use these things. But this is orthogonal to the question of whether the ABNF in RFC 6531 should be written in terms of octets or in terms of (Unicode) code points. Either one is fine with me, but that still doesn't mean that mixing is a good idea. Having thought about the text in RFC 6531 a bit more, and looked at http://tools.ietf.org/html/rfc5890#section-2.3.2.1 again, I actually think it's not even so much a problem of mixing two levels of description (characters and octets) as of trying to import an ABNF rule when there never was one. Here is what http://tools.ietf.org/html/rfc6531#section-3.3 says: >>>> The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly: o The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly: o >>>> If I go to http://tools.ietf.org/html/rfc5234#appendix-B.1, I indeed find: >>>> DQUOTE = %x22 ; " (Double Quote) >>>> (which I can add directly to the grammar if my ABNF infrastructure hasn't it predefined already). On the other hand, if I got to http://tools.ietf.org/html/rfc5890#section-2.3.2.1, I see some very precisely worked out definitions that I should be able to turn into whatever I need for my implementation in due time if I'm not lucky enough to find a library that has already done that. However, (and actually for good reasons,) even the word "ABNF" is nowhere in sight in RFC 5890. So I currently think that I will propose an erratum along the following lines: In http://tools.ietf.org/html/rfc6531#section-3.3, replace <<<< The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly: o The following rules are extended in ABNF [RFC5234] as follows. sub-domain =/ U-label ; extend the definition of sub-domain in RFC 5321, Section 4.1.2 <<<< by >>>> The following rules are extended in ABNF [RFC5234] as follows. sub-domain =/ ; extend the definition of sub-domain in RFC 5321, Section 4.1.2 >>>> There are a few other places where RFC 5890 is mentioned in RFC 6531, and which may have to be tweaked, too. Regards, Martin. > (speaking only for myself, I hope obviously) > > john From arnt@gulbrandsen.priv.no Mon Mar 19 06:14:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5D21F85FC for ; Mon, 19 Mar 2012 06:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liNP0qXsaWHX for ; Mon, 19 Mar 2012 06:14:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4721F8413 for ; Mon, 19 Mar 2012 06:13:55 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0E7A2F8D78C; Mon, 19 Mar 2012 13:13:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1332162832-10833-10833/11/11; Mon, 19 Mar 2012 13:13:52 +0000 Message-Id: <4F673168.3010201@gulbrandsen.priv.no> Date: Mon, 19 Mar 2012 14:15:20 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: IMA Discussion Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:14:06 -0000 Hi, I find it rather irritating that the draft embargo before each meeting also applies to WGs that do not meet. http://arnt.gulbrandsen.priv.no/tmp/draft-ietf-eai-simpledowngrade-02.txt= resembles what will be -02 when the datatracker again allows submissions. It's better than -01. Feel free to review. Arnt From klensin@jck.com Mon Mar 19 06:43:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9821F8697 for ; Mon, 19 Mar 2012 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q06Cg1aGgdR6 for ; Mon, 19 Mar 2012 06:43:17 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B770D21F85F9 for ; Mon, 19 Mar 2012 06:43:16 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S9cmw-000AHa-Vb; Mon, 19 Mar 2012 09:38:18 -0400 Date: Mon, 19 Mar 2012 09:43:10 -0400 From: John C Klensin To: Arnt Gulbrandsen , IMA Discussion Message-ID: In-Reply-To: <4F673168.3010201@gulbrandsen.priv.no> References: <4F673168.3010201@gulbrandsen.priv.no> 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] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:43:18 -0000 --On Monday, March 19, 2012 14:15 +0100 Arnt Gulbrandsen wrote: > I find it rather irritating that the draft embargo before each > meeting also applies to WGs that do not meet. Many of us find many aspects of the way that embargo works and is interpreted very irritating. Please let's not have that discussion on this mailing list. thanks, john From Shawn.Steele@microsoft.com Mon Mar 19 09:14:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED90721F8876 for ; Mon, 19 Mar 2012 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGnqxh5Y1Kek for ; Mon, 19 Mar 2012 09:14:47 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 082BE21F871B for ; Mon, 19 Mar 2012 09:14:46 -0700 (PDT) Received: from mail55-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 19 Mar 2012 16:14:41 +0000 Received: from mail55-db3 (localhost [127.0.0.1]) by mail55-db3-R.bigfish.com (Postfix) with ESMTP id 96731403CF for ; Mon, 19 Mar 2012 16:14:41 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail55-db3 (localhost.localdomain [127.0.0.1]) by mail55-db3 (MessageSwitch) id 1332173680294454_19244; Mon, 19 Mar 2012 16:14:40 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.237]) by mail55-db3.bigfish.com (Postfix) with ESMTP id 3A4FA4E0045 for ; Mon, 19 Mar 2012 16:14:40 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 19 Mar 2012 16:14:39 +0000 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.30]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0283.004; Mon, 19 Mar 2012 16:14:42 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Erratum? Mixing character-based and byte based ABNF in RFC 6531 Thread-Index: Ac0F6urEy9do4SG0R7CUgFLllQFmmA== Date: Mon, 19 Mar 2012 16:14:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:14:48 -0000 I agree with the others that the U-Label/UTF-8 thing isn't much of a proble= m. I can see where IDNA has a slightly different definition of U-Label, an= d how that could lead to Martin's observation, but agree with the others th= at the spec is pretty clear about UTF-8, so I don't think there's any risk = of anyone creating a bad implementation because of this. It seems worth remembering that maybe this could be improved if the documen= t is revised, but don't think it's worth more effort than that. -Shawn From ned+ima@mrochek.com Mon Mar 19 10:10:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAAD21F889D for ; Mon, 19 Mar 2012 10:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JG0x7bo26bz for ; Mon, 19 Mar 2012 10:10:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFA21F8755 for ; Mon, 19 Mar 2012 10:10:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODAO8JU3PC017140@mauve.mrochek.com> for ima@ietf.org; Mon, 19 Mar 2012 10:10:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 19 Mar 2012 10:10:22 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01ODAO8IRWM800ZUIL@mauve.mrochek.com> Date: Mon, 19 Mar 2012 10:04:37 -0700 (PDT) In-reply-to: "Your message dated Mon, 19 Mar 2012 09:43:10 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F673168.3010201@gulbrandsen.priv.no> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1332177036; bh=NP2M58Dxh7ZRrRF7y0MaHmQyLeaxZGxwfLUvPvRFnDM=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=IvBoI0myVJ08YuQ6FvB9dw3bEAvRSv8F/fBIPsllLNmPkpCUFx0Vu7b4ERXr9kSoF 9tV/vwMKnay0x7kUo0rTYlQgjoq/yYgEmR3SokeKMfypHCMgWm+Aj7wGLpS2WbiL4K aPKozTHxm5RnXGTLbyBaTy4BTr072DGY0Gnkll5I= Cc: Arnt Gulbrandsen , IMA Discussion Subject: Re: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:10:41 -0000 > --On Monday, March 19, 2012 14:15 +0100 Arnt Gulbrandsen > wrote: > > I find it rather irritating that the draft embargo before each > > meeting also applies to WGs that do not meet. > Many of us find many aspects of the way that embargo works and > is interpreted very irritating. Please let's not have that > discussion on this mailing list. +Aleph-one Ned From alexey.melnikov@isode.com Mon Mar 19 13:23:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4177621E803E for ; Mon, 19 Mar 2012 13:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knBucNH9FPJO for ; Mon, 19 Mar 2012 13:23:08 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1811A21E803D for ; Mon, 19 Mar 2012 13:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332188587; d=isode.com; s=selector; i=@isode.com; bh=WRqk5qYgnga6jJW++VQb1C844JnHRFiuACjIUDMZ9QQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UB2lXIADSwblPeSU846Ee8tAeold6DkUWqVmIW3XAISgC8B+nmRjw0v34CE8RWPOJ94HbR Kn5x4POW9NBtG+987KJEa+OTGV4+2PbzlNfMo7LeX8vpuak0JtQmXKz3XxgVylp/5sR6YV pZjW2J4lIo/oLCLB353wi5BcArzcYV0=; Received: from [188.29.240.8] (188.29.240.8.threembb.co.uk [188.29.240.8]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 19 Mar 2012 20:23:06 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F6788B5.3000800@isode.com> Date: Mon, 19 Mar 2012 19:27:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Arnt Gulbrandsen References: <4F673168.3010201@gulbrandsen.priv.no> In-Reply-To: <4F673168.3010201@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IMA Discussion Subject: Re: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:23:09 -0000 On 19/03/2012 13:15, Arnt Gulbrandsen wrote: > Hi, > > I find it rather irritating that the draft embargo before each meeting > also applies to WGs that do not meet. > > http://arnt.gulbrandsen.priv.no/tmp/draft-ietf-eai-simpledowngrade-02.txt resembles > what will be -02 when the datatracker again allows submissions. It's > better than -01. Feel free to review. I've reviewed -02 and here are my comments: I generally like simplicity of the approach in your document and I am happy for it to go forward. (I am still undecided about picking one downgrade mechanism versa allowing multiple.) 2. Information preserved and lost The synthetic message is not intended to convey any information to the MUA. Nothing parsable is added, not even a marker to say "this message has been downgraded". Actually I really want to have a way to tell the user that the message is synthetic. Maybe allow editing of the Subject line? In Section 2.1 you talk about 14 header fields, I've only counted 12. In Section 3: I really dislike relaxation of base IMAP rules about sizes without at least signalling that with an IMAP capability. I understand that this is targeting legacy MUAs, but at least a new capability would help with protocol traces. But really, an IMAP server can synthesize a message and remember its size. We've been through this discussion before with IMAP CONVERT. Thank you, Alexey From alexey.melnikov@isode.com Mon Mar 19 13:23:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8521E803C for ; Mon, 19 Mar 2012 13:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F8ylIp82V6x for ; Mon, 19 Mar 2012 13:23:18 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5370F21E8035 for ; Mon, 19 Mar 2012 13:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332188596; d=isode.com; s=selector; i=@isode.com; bh=feXfJv9GTpqgGyfFeAy3htUZjlfdV4bjr1EbxVAz+s8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MyalaBOww5s3TSWGrOLWcpV7TZofUzg6Mq5Rv3luhfoD4TSZQketp0bawia+feAZfnSLu4 BSLt2aDY2I85hCKAve/VDJCjs6a6xyXg+4DKr5QMfJUmtxpkZpwNLIph5WYMmJiyRflbei SWq5dFuev/rYJBIJLLraiYNkaccwlzE=; Received: from [188.29.240.8] (188.29.240.8.threembb.co.uk [188.29.240.8]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 19 Mar 2012 20:23:15 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F678B8E.3030705@isode.com> Date: Mon, 19 Mar 2012 19:39:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: IETF EAI MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Comments on draft-ietf-eai-mailinglistbis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:23:19 -0000 Hi, I've reviewed -01 and I am generally very happy with the document. It contains a lot of useful information, in fact I kept thinking in several places "oh, forgot about this feature". One thing that I think needs fixing though (you might convince me that RFC Editor should just do this for you, but that is another discussion althogether): there are way too many terms and concepts mentioned in the document which have no references. If a reader is not an email expert, she/he would have no way of figuring out where to read more on different concepts referenced in the document. A quick scan revealed that at least the following terms need references: envelope, URI, mailto:, UTF-8, HTTP, Sieve, VERP. From arnt@gulbrandsen.priv.no Mon Mar 19 13:43:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B5421F8732 for ; Mon, 19 Mar 2012 13:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWw5piSlwN8j for ; Mon, 19 Mar 2012 13:43:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E3FAC21F8731 for ; Mon, 19 Mar 2012 13:43:24 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0F544F8D7A3; Mon, 19 Mar 2012 20:43:23 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1332189802-10833-10833/11/17; Mon, 19 Mar 2012 20:43:22 +0000 Message-Id: <4F679AC2.5000606@gulbrandsen.priv.no> Date: Mon, 19 Mar 2012 21:44:50 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F673168.3010201@gulbrandsen.priv.no> <4F6788B5.3000800@isode.com> In-Reply-To: <4F6788B5.3000800@isode.com> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:43:25 -0000 On 03/19/2012 08:27 PM, Alexey Melnikov wrote: > Actually I really want to have a way to tell the user that the message > is synthetic. Maybe allow editing of the Subject line? If anything, then I think a new pseudoflag like \recent, or a response code. My preference would be the response code. response-codes =/ "DOWNGRADED" SP sequence-set > In Section 2.1 you talk about 14 header fields, I've only counted 12. Barry pointed that out earlier today. I removed two fields during editing and forgot to update the number. (Message-ID and one other, I think. I really hate that they use address-like syntax.) I dropped the number. > In Section 3: I really dislike relaxation of base IMAP rules about sizes > without at least signalling that with an IMAP capability. I understand > that this is targeting legacy MUAs, but at least a new capability would > help with protocol traces. Good point. Enough of an argument to add a response code. > But really, an IMAP server can synthesize a message and remember its > size. We've been through this discussion before with IMAP CONVERT. a) This is a peculiar case, since it only ever applies to unaware clients and not, for example to any messages that are legal according to core IMAP. b) IMAP CONVERT is not a shining success of deployment and usage, so I think that if this document should follow any of its example, then good concrete reason is needed. Barry inspired me today: http://rant.gulbrandsen.priv.no/good-bad-rfc Arnt From alexey.melnikov@isode.com Tue Mar 20 03:17:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA5421F863E for ; Tue, 20 Mar 2012 03:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaXvnSeZ57+z for ; Tue, 20 Mar 2012 03:17:43 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 455DE21F8637 for ; Tue, 20 Mar 2012 03:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332238660; d=isode.com; s=selector; i=@isode.com; bh=6hfGpy9XnDy+LTSuSiqu8wjTbMxMMw3LhjExBczkdtw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=R3yE1xiue000Si7U7DXj/sFH/hVc3/6LzS85eSDQRx5bYg59MdPWJw8Cww51eZVNGyR9Ru E/Sc9Wlmucjg+CTLfVISjNm+i5PPW2OhIp3JYjvyGLmNemAKSCSo1Y2z964ZuTs4qytBcg Q2tdTX2q/Y0/yFaLrNX8Rijvpzuw7Z4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 20 Mar 2012 10:17:40 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F68595E.90503@isode.com> Date: Tue, 20 Mar 2012 10:18:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Arnt Gulbrandsen References: <4F673168.3010201@gulbrandsen.priv.no> <4F6788B5.3000800@isode.com> <4F679AC2.5000606@gulbrandsen.priv.no> In-Reply-To: <4F679AC2.5000606@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:17:45 -0000 On 19/03/2012 20:44, Arnt Gulbrandsen wrote: > On 03/19/2012 08:27 PM, Alexey Melnikov wrote: >> Actually I really want to have a way to tell the user that the message >> is synthetic. Maybe allow editing of the Subject line? > If anything, then I think a new pseudoflag like \recent, or a response > code. My preference would be the response code. > > response-codes =/ "DOWNGRADED" SP sequence-set This is useful for debugging, but not useful to users (two separate changes). Users need to know that they are not looking at the original message. >> In Section 2.1 you talk about 14 header fields, I've only counted 12. > Barry pointed that out earlier today. I removed two fields during > editing and forgot to update the number. (Message-ID and one other, I > think. I really hate that they use address-like syntax.) > > I dropped the number. Ok. >> In Section 3: I really dislike relaxation of base IMAP rules about sizes >> without at least signalling that with an IMAP capability. I understand >> that this is targeting legacy MUAs, but at least a new capability would >> help with protocol traces. > Good point. Enough of an argument to add a response code. I like that. >> But really, an IMAP server can synthesize a message and remember its >> size. We've been through this discussion before with IMAP CONVERT. > a) This is a peculiar case, since it only ever applies to unaware > clients and not, for example to any messages that are legal according to > core IMAP. b) IMAP CONVERT is not a shining success of deployment and > usage, so I think that if this document should follow any of its > example, then good concrete reason is needed. Although true, I don't think preconditions for the Lemonade discussion have changed, so I think the conclusions are still valid. > Barry inspired me today: http://rant.gulbrandsen.priv.no/good-bad-rfc From johnl@iecc.com Tue Mar 20 16:14:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F78521E800F for ; Tue, 20 Mar 2012 16:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.348 X-Spam-Level: X-Spam-Status: No, score=-110.348 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDi8mCZ20sHl for ; Tue, 20 Mar 2012 16:14:51 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E05D21E801A for ; Tue, 20 Mar 2012 16:14:51 -0700 (PDT) Received: (qmail 14916 invoked from network); 20 Mar 2012 23:14:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Mar 2012 23:14:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f690f6b.xn--i8sz2z.k1203; i=johnl@user.iecc.com; bh=FtZ4PXjFBZD4MAi8GAcZ/8SIjQOKaRzGTd/oKJoSv0s=; b=ikG8aZeoD9tHUhKv67pupCnboK5g3zRZDtDjxkk7eS+9G70/VADr+tBmUace/UK/Ap9BuecHoZskhGJirZJenfG1zOjH2aEq5W15zYch/RZwdSUu4vtIt43HSUJM4cG/bEwerIO6zFmlSVEXcAqx57yMUxcR/RaDaoBAPa+MEKA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f690f6b.xn--i8sz2z.k1203; olt=johnl@user.iecc.com; bh=FtZ4PXjFBZD4MAi8GAcZ/8SIjQOKaRzGTd/oKJoSv0s=; b=VNcSKxug/DJRH+irvZJ7zmQf6uUVQ9mYme7ZQ6jaN+1YtrjycONzCscWb7q27ITBXqmEdykzy7WSpEjcqCDDzwnLg+n1/N/l7XbrNPqcMXxP/gAH0swbHgyioeJaKGlsC8VPU2yQ7coMzrowRyDCErZW+9fmcyVWUayz4cOn/S0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Mar 2012 23:14:28 -0000 Message-ID: <20120320231428.76032.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4F678B8E.3030705@isode.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Comments on draft-ietf-eai-mailinglistbis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 23:14:52 -0000 >I've reviewed -01 and I am generally very happy with the document. It >contains a lot of useful information, in fact I kept thinking in several >places "oh, forgot about this feature". Thanks. >One thing that I think needs fixing though (you might convince me that >RFC Editor should just do this for you, but that is another discussion >althogether): there are way too many terms and concepts mentioned in the >document which have no references. If a reader is not an email expert, >she/he would have no way of figuring out where to read more on different >concepts referenced in the document. A quick scan revealed that at least >the following terms need references: envelope, URI, mailto:, UTF-8, >HTTP, Sieve, VERP. It's a first draft (the -00 was a rather different document long ago.) Once I collect the list of changes, I'll add references for stuff that needs them. R's, John From duerst@it.aoyama.ac.jp Tue Mar 20 22:16:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7753D21F851A for ; Tue, 20 Mar 2012 22:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.3 X-Spam-Level: X-Spam-Status: No, score=-100.3 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmzxRlDzbvJ2 for ; Tue, 20 Mar 2012 22:16:16 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id AB98721F8516 for ; Tue, 20 Mar 2012 22:16:14 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2L5G5O0004332 for ; Wed, 21 Mar 2012 14:16:05 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5ae7_5b5d_f5a5246c_7314_11e1_87f2_001d096c566a; Wed, 21 Mar 2012 14:16:05 +0900 Received: from [IPv6:::1] ([133.2.210.1]:55961) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 21 Mar 2012 14:16:10 +0900 Message-ID: <4F696410.9060500@it.aoyama.ac.jp> Date: Wed, 21 Mar 2012 14:16:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Arnt Gulbrandsen References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> <20120314.180825.183027988.fujiwara@jprs.co.jp> <4F60689C.2030209@gulbrandsen.priv.no> <4F606C57.2030307@gulbrandsen.priv.no> In-Reply-To: <4F606C57.2030307@gulbrandsen.priv.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] two downgrade specs, I think X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 05:16:16 -0000 I just have read draft-ietf-eai-popimap-downgrade-04 and draft-ietf-eai-simpledowngrade-02-proto. I will send some comments on each one separately. [If some of the following has already been discussed at length, pointers are appreciated.] However, my general assumptions for priorities would be, in decreasing order: 1) Make sure the user knows what this is not the real thing 2) Make sure the user gets told what the fundamental problem is, and how to deal with it (read: please upgrade) 3) Allow the user to get all the information in the message, if necessary manually What I'd personally try to do if I had, in a POP or IMAP implementation, would be to convert a minimum of the header fields that are usually used for display in MUAs in some obvious and helpful way. For the subject, I'd of course use RFC 2047, but prepend some indicative label (e.g., "INVALID" or so). For the typical mail address headers fields (From, To, Cc,...), if a display name is present I'd use only the display name, and remove or reduce the address to something like <> (if that's permitted by the syntax) or or so. Then what I'd do is to wrap the original message (in message/global or even just in text/plain;charset=utf-8) and prepend some text that explains the situation and what might be done about it. I'm really wondering why what I have written in the last paragraph (include an original verbatim) isn't proposed in either of the downgrade specs. It would make sure that no info is lost, although the information isn't very actionable directly. On 2012/03/14 19:00, Arnt Gulbrandsen wrote: > One more thing. I think that I personally am now in favour of publishing > both drafts as RFCs and letting server authors choose according to > inclination. > > I have my inclination, of course, but I can see sensible reasons why > people might choose differently, and I don't think we gain very much by > forcing this issue to be resolved before we've gained real > implementation and deployment experience. I'm fine with that. As explained above, I'd personally go for your approach, with some tweaks, if I had to implement something or if I had to choose an approach as an administrator. At the current point in time, I really don't see the point of all the Downgrade- headers. If we want a faithful reproduction of the original headers, it's much easier to just include that as a message part. If anybody wants to automatically move back to the original (in my opinion, MUA writers should focus on upgrading their clients, not on being able to handle Downgrade- headers,...), having the original headers included in some way is much easier to convert back than some complicated header mangling. But as I said above, I'm not against keeping both documents. Regards, Martin. > Possible wording (in the two downgrade documents or in a reference > paragraph in the popimap spec): > > RFC x describes a very simple downgrade process, while RFC y describes > a more complex, more accurate process. The WG decided that choosing > one process based on little implementation experience would be > premature, so both specifications are published, and servers may > choose either. > > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From duerst@it.aoyama.ac.jp Tue Mar 20 23:42:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E321E802D for ; Tue, 20 Mar 2012 23:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.357 X-Spam-Level: X-Spam-Status: No, score=-99.357 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abND64NzRig7 for ; Tue, 20 Mar 2012 23:42:50 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC321E8018 for ; Tue, 20 Mar 2012 23:42:49 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2L6geds030560 for ; Wed, 21 Mar 2012 15:42:40 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5172_a05f_0e1cd254_7321_11e1_9bce_001d096c5782; Wed, 21 Mar 2012 15:42:40 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49225) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 21 Mar 2012 15:42:45 +0900 Message-ID: <4F69785B.5050704@it.aoyama.ac.jp> Date: Wed, 21 Mar 2012 15:42:35 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [EAI] Comments on Post-delivery downgrade draft (draft-ietf-eai-popimap-downgrade-04.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 06:42:50 -0000 These are my comments on draft-ietf-eai-popimap-downgrade-04.txt: (see also my more general questions in an earlier mail) Abstract: "to be traditional message format" -> "to be in traditional message format"? "The purpose of post-delivery message downgrading is to enable POP/IMAP servers to deliver internationalized messages to traditional POP/IMAP clients.": At this point in the abstract, it was quite clear to me that the purpose was to "enable POP/IMAP servers to deliver internationalized messages to traditional POP/IMAP clients". So this sounded like an unnecessary repetition. What is not a repetition is the term "post-delivery message downgrading". I suggest replacing the above sentence with something like "This is called post-delivery message downgrading." "In the process, message elements requiring internationalized treatment can be removed or recoded and receivers can know they received messages containing such elements even if they cannot receive the elements themselves.": The two "can" (in particular the first) in this sentence don't work. Because we want to avoid "may", I suggest rewording to "It can happen that ...". 1.1 Problem statement: "([RFC6530] and [RFC6532] allows UTF-8 characters in those mail header fields.": - Nit: closing parenthese missing - Nit: "allows" -> "allow" - Serious rant: There are NO "UTF-8 characters". There are Unicode characters encoded in UTF-8. It may be simpler and clearer even (because there is also RFC 2047-encoded UTF-8) to say "allow raw UTF-8" Section 1.3: Redefinition (update) of From/Sender in RFC 5322: I am in no position to judge how much software is out there that will blow up on this, but the description in Section 3 (many will tolerate ... will fail in unpredictable ways) doesn't instill much confidence. I'd be way more happy if the description read "to the knowledge of the WG, and after extensive trial with a wide variety of software, no clients were found that don't tolerate this" (assuming it's true). I'm assuming that the WG has already discussed this, and it's okay for everybody who has a lot of implementation and infrastructure experience, but if not, I'm really not seeing the point of defining a downgrade that does 99% of the job to then blow up on some edge cases. "MIME header fields are expanded in [RFC6532]." -> The definition of MIME header fields in Internationalized Email Messages is given in [RFC 6532]." 2. Terminology "This document depends on [RFC6532]. Key words used in those documents are used in this document, too.": Only one document is mentioned, but it says "documents". Also, I first though this was an indirect import from RFC 2119, but those key words are given at the start of section 2. So I have no idea what this paragraph refers to. Please explain or reword. Section 3 ENCODED-WORD "<" NO_EXISTING_ADDRESS ">": nit: I'd change "NO_EXISTING_ADDRESS" to "NON_EXISTING_ADDRESS" opinion: I'd strongly prefer this to an update of RFC 5322. proposal: It's not a bad idea to move the UTF-8 address to the display name. But this should be done in a way that doesn't cancel the original display name. So instead of before: From: Иван Грозный <Иван@foo.example.net> after: From: =?UTF-8?Q?=d0=b8=d0=b2=d0=b0=d0=bd@foo.example.net?= something like: before: From: Иван Грозный <Иван@foo.example.net> after (without RFC 2047 encoding): From: Иван Грозный (Иван@foo.example.net) That proposal also applies to Arnt's simplified draft. The reason for this is that although often there is overlapping information in address and display text, it's usually only some part that's overlapping, and the rest is helpful, too. "@imap.example.com": I prefer the idea of using .invalid. The clearer it is that this isn't a real address (both to humans and software), the better. Section 5 The draft should be extremely clear on the fact that the "Downgrading-" prefix isn't a general convention, but is reserved for exactly those header it is used with in the spec. 5.1.1: This is about a specific header field, it seems to belong in 5.2. 5.2. Downgrading Method for Each Header Field "Header fields are listed in [RFC4021]." -> "[RFC 4021] establishes a registry of header fields." (There are headers that are not listed in RFC 4021.) 5.2.9. Other Header Fields "and their field value are" -> "and their field values are" 7. Security Considerations The purpose of post-delivery message downgrading is to allow POP/IMAP servers to deliver internationalized messages to traditional POP/IMAP clients and permit them to work with those messages. The last clause ("permit them to work with these messages") is unclear. What "work" can be done? References: Please order by RFC number, to make it easy to find each reference quickly. Regards, Martin. From arnt@gulbrandsen.priv.no Wed Mar 21 13:23:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B667821E8119 for ; Wed, 21 Mar 2012 13:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpFqNUD4Thzx for ; Wed, 21 Mar 2012 13:23:37 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 03B2321E8111 for ; Wed, 21 Mar 2012 13:23:37 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 43063F8D898; Wed, 21 Mar 2012 20:23:34 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1332361413-14074-14074/11/5; Wed, 21 Mar 2012 20:23:33 +0000 Message-Id: <4F6A3921.5090109@gulbrandsen.priv.no> Date: Wed, 21 Mar 2012 21:25:05 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F673168.3010201@gulbrandsen.priv.no> <01ODAO8IRWM800ZUIL@mauve.mrochek.com> In-Reply-To: <01ODAO8IRWM800ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:23:37 -0000 On 03/19/2012 06:04 PM, ned+ima@mrochek.com wrote: > +Aleph-one One excellent way to avoid discussing offtopic subjects is to discuss downgrade-02. Do you think you might be able to review it? It's two pages plus boilerplate and references, and you have to slow down and read anything carefully, please let me know where. http://arnt.gulbrandsen.priv.no/tmp/draft-ietf-eai-simpledowngrade-02.txt= until it appears in the i-d directories. Arnt From arnt@gulbrandsen.priv.no Wed Mar 21 13:56:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82CF21F86AB for ; Wed, 21 Mar 2012 13:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnJkfSBvODyn for ; Wed, 21 Mar 2012 13:56:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 35B5321F8682 for ; Wed, 21 Mar 2012 13:56:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3D20AF8D899; Wed, 21 Mar 2012 20:56:52 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1332363411-14074-14074/11/7; Wed, 21 Mar 2012 20:56:51 +0000 Message-Id: <4F6A40EE.1030806@gulbrandsen.priv.no> Date: Wed, 21 Mar 2012 21:58:22 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F539230.3080808@gulbrandsen.priv.no> <003AE1E0-C371-4B68-945F-6663CDF9967A@afilias.info> <4F605997.6000004@gulbrandsen.priv.no> <20120314.180825.183027988.fujiwara@jprs.co.jp> <4F60689C.2030209@gulbrandsen.priv.no> <4F606C57.2030307@gulbrandsen.priv.no> <4F696410.9060500@it.aoyama.ac.jp> In-Reply-To: <4F696410.9060500@it.aoyama.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] two downgrade specs, I think X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:56:55 -0000 On 03/21/2012 06:16 AM, Martin J. D=FCrst wrote: > For the subject, I'd of course use RFC 2047, but prepend some indicativ= e > label (e.g., "INVALID" or so). I hate the mere thought, but perhaps that's just me. If more people agree with you and Alexey I'll hold my nose and a sentence such as "the server may add a prefix or suffix to the subject to inform the user that the message has been downgraded", without specifying what the prefix/suffix should be. IMO that's too language-dependent to be specified in an RFC anyway. > For the typical mail address headers fields (From, To, Cc,...), if a > display name is present I'd use only the display name, and remove or > reduce the address to something like <> (if that's permitted by the > syntax) or or so. Neither is syntactically permitted by the RFC. Well, is permitted by much code, but it quite often points to something. Remember, there are a gmail accounts, so a billion people's misaddressed replies would pile up in the inbox of invalid@gmail.com. The four examples in the document, or varieties along the same lines, are the closest safe ones, I think. Your preference is probably #2 (original display-name plus ). There's also qmail's approach, <""@[]>. I've always felt bad about that, so I didn't include it as an example. > Then what I'd do is to wrap the original message (in message/global or > even just in text/plain;charset=3Dutf-8) and prepend some text that > explains the situation and what might be done about it. >=20 > I'm really wondering why what I have written in the last paragraph > (include an original verbatim) isn't proposed in either of the = downgrade > specs. It would make sure that no info is lost, although the informatio= n > isn't very actionable directly. In my case, I don't specify that precisely because it isn't very actionable, and because message/global is an unusual content type. Absent good reason I want to stay away from unusual syntax or features. I believe that internationalized mail will generally be sent to people who can read and write that. Send mail to people who can't reply, and nothing more happens. Send mail to people who can, and before you know it it's late at night and you have 116 more messages to read. It follows that downgrade occurs mostly when a user has an internationalized client, but is (also) using a conventional MUA (think of the built-in client on your smartphone). In that scenario, the optimal strategy is to deliver enough of the message to get the point across, without adding any unusual syntax that might make the client stumble, and expect the user to switch to the internationalized client if necessary. God what awfully long sentences. I hope I'm not rambling too much. I should finish off and go to bed. Arnt From stpeter@stpeter.im Wed Mar 21 16:34:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0A421E8128 for ; Wed, 21 Mar 2012 16:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaKzkMTFV3J5 for ; Wed, 21 Mar 2012 16:34:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8BB21E8126 for ; Wed, 21 Mar 2012 16:34:33 -0700 (PDT) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 06A1240058; Wed, 21 Mar 2012 17:47:17 -0600 (MDT) Message-ID: <4F6A6587.5090103@stpeter.im> Date: Wed, 21 Mar 2012 17:34:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <20120309231456.BBD91B1E002@rfc-editor.org> <01OCXDM85LDE00ZUIL@mauve.mrochek.com> <0BAB5D1FA8D0EB611525841B@PST.JCK.COM> In-Reply-To: <0BAB5D1FA8D0EB611525841B@PST.JCK.COM> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Shawn.Steele@microsoft.com, dthaler@microsoft.com, ima@ietf.org, presnick@qualcomm.com, Ned Freed , ned+ietf@mrochek.com, RFC Errata System Subject: Re: [EAI] [Editorial Errata Reported] RFC6532 (3153) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:34:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/10/12 9:24 AM, John C Klensin wrote: > > > --On Friday, March 09, 2012 21:46 -0800 Ned Freed > wrote: > >> The change looks correct to me - it should be section 13, not >> 14. > > Concur. So processed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9qZYcACgkQNL8k5A2w/vzvrQCdGmmC6TliIiaUebVsQjmwirGD 0IkAoJUGtOYP9dMNpLYsoOXLhqk+T3LA =ZB2r -----END PGP SIGNATURE----- From fujiwara@jprs.co.jp Thu Mar 22 02:28:04 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243B121F861E for ; Thu, 22 Mar 2012 02:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy4exPczMsdK for ; Thu, 22 Mar 2012 02:28:03 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id EDB2F21F8619 for ; Thu, 22 Mar 2012 02:28:02 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q2M9S0tD031770; Thu, 22 Mar 2012 18:28:01 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-5e-4f6af0a084ac Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id E7.AA.03276.0A0FA6F4; Thu, 22 Mar 2012 18:28:00 +0900 (JST) Date: Thu, 22 Mar 2012 18:27:59 +0900 (JST) Message-Id: <20120322.182759.71100095.fujiwara@jprs.co.jp> To: duerst@it.aoyama.ac.jp From: fujiwara@jprs.co.jp In-Reply-To: <4F69785B.5050704@it.aoyama.ac.jp> References: <4F69785B.5050704@it.aoyama.ac.jp> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsWyRoiFT3fBhyx/gxebeC3a715ht7i+dB27 A5PHkiU/mTyaLs9gCmCK4rJJSc3JLEst0rdL4MpYcPske8E254qWLw/ZGhhvOHYxcnJICJhI rJq1mB3CFpO4cG89WxcjF4eQwElGiZddvUwgCRYBbYk3t/Ywg9i8AlYSv6+fYAGxRQSkJFrf /WcEsZkFBCROXpoHZgsLZEjs274azGYTkJTY/LkVrJdTQF9i3vJ2NhBbSEBP4v6hSWwQi+0k TjxfwdrFyAE0X1Di7w5hiJHqEp9Xf2WGsBUlpnQ/ZJ/AyD8LoWoWkqpZSKoWMDKvYpTJT0vT LU7NSynOTTcw1CupzNfLKigq1ksG0ZsYwYHIobCDccYpg0OMAhyMSjy8nlZZ/kKsiWXFlbmH GCU5mJREeXPfAYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8G5QB8rxpiRWVqUW5cOkpDlYlMR5 j5/d4SckkJ5YkpqdmlqQWgSTleHgUJLgnf8eqFGwKDU9tSItM6cEIc3EwQkynAdo+BGQGt7i gsTc4sx0iPwpRkkpcd5OkIQASCKjNA+u9xWjONALwrw9IFkeYFKB63oFNJAJaOCEa2ADSxIR UlINjG4a/pld0t6y/5xP9Uzbwtzcz3I086pA8Ts590knzL4rLmR6EikS4/Ho2JaS+rw4ZvUn wt82fD/LMP9KYYDdF5MdWxS+SF0uOye4qL58xhw3nxeeaRVH/or3KPjEJvZZc81Y5pZ1m3n3 o7w5dtY3lA4u/HFp6Z+7/2ru6vx3jn63keexkMuSd0osxRmJhlrMRcWJAM3FSCjnAgAA Cc: ima@ietf.org Subject: Re: [EAI] Comments on Post-delivery downgrade draft (draft-ietf-eai-popimap-downgrade-04.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:28:04 -0000 VGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cy4NCg0KPiBGcm9tOiAiTWFydGluIEou IETDvHJzdCIgPGR1ZXJzdEBpdC5hb3lhbWEuYWMuanA+DQo+IEFic3RyYWN0Og0KPiANCj4gInRv IGJlIHRyYWRpdGlvbmFsIG1lc3NhZ2UgZm9ybWF0IiAtPiAidG8gYmUgaW4gdHJhZGl0aW9uYWwg bWVzc2FnZQ0KPiBmb3JtYXQiPw0KDQp1cGRhdGVkIG15IGxvY2FsIGNvcHkuDQoNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJUaGUgcHVycG9zZSBvZiBwb3N0LWRlbGl2 ZXJ5DQo+ICAgIG1lc3NhZ2UgZG93bmdyYWRpbmcgaXMgdG8gZW5hYmxlIFBPUC9JTUFQIHNlcnZl cnMgdG8gZGVsaXZlcg0KPiAgICBpbnRlcm5hdGlvbmFsaXplZCBtZXNzYWdlcyB0byB0cmFkaXRp b25hbCBQT1AvSU1BUCBjbGllbnRzLiI6DQo+IEF0IHRoaXMgcG9pbnQgaW4gdGhlIGFic3RyYWN0 LCBpdCB3YXMgcXVpdGUgY2xlYXIgdG8gbWUgdGhhdCB0aGUNCj4gcHVycG9zZSB3YXMgdG8gImVu YWJsZSBQT1AvSU1BUCBzZXJ2ZXJzIHRvIGRlbGl2ZXIgaW50ZXJuYXRpb25hbGl6ZWQNCj4gbWVz c2FnZXMgdG8gdHJhZGl0aW9uYWwgUE9QL0lNQVAgY2xpZW50cyIuIFNvIHRoaXMgc291bmRlZCBs aWtlIGFuDQo+IHVubmVjZXNzYXJ5IHJlcGV0aXRpb24uIFdoYXQgaXMgbm90IGEgcmVwZXRpdGlv biBpcyB0aGUgdGVybQ0KPiAicG9zdC1kZWxpdmVyeSBtZXNzYWdlIGRvd25ncmFkaW5nIi4gSSBz dWdnZXN0IHJlcGxhY2luZyB0aGUgYWJvdmUNCj4gc2VudGVuY2Ugd2l0aCBzb21ldGhpbmcgbGlr ZSAiVGhpcyBpcyBjYWxsZWQgcG9zdC1kZWxpdmVyeSBtZXNzYWdlDQo+IGRvd25ncmFkaW5nLiIN Cg0KSSB3aWxsIGNvbnNpZGVyIGhvdyB0byB1cGRhdGUuDQoNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIkluIHRoZQ0KPiAg ICBwcm9jZXNzLCBtZXNzYWdlIGVsZW1lbnRzIHJlcXVpcmluZyBpbnRlcm5hdGlvbmFsaXplZCB0 cmVhdG1lbnQgY2FuDQo+ICAgIGJlIHJlbW92ZWQgb3IgcmVjb2RlZCBhbmQgcmVjZWl2ZXJzIGNh biBrbm93IHRoZXkgcmVjZWl2ZWQgbWVzc2FnZXMNCj4gICAgY29udGFpbmluZyBzdWNoIGVsZW1l bnRzIGV2ZW4gaWYgdGhleSBjYW5ub3QgcmVjZWl2ZSB0aGUgZWxlbWVudHMNCj4gICAgdGhlbXNl bHZlcy4iOg0KPiBUaGUgdHdvICJjYW4iIChpbiBwYXJ0aWN1bGFyIHRoZSBmaXJzdCkgaW4gdGhp cyBzZW50ZW5jZSBkb24ndA0KPiB3b3JrLiBCZWNhdXNlIHdlIHdhbnQgdG8gYXZvaWQgIm1heSIs IEkgc3VnZ2VzdCByZXdvcmRpbmcgdG8gIkl0IGNhbg0KPiBoYXBwZW4gdGhhdCAuLi4iLg0KDQpJ IHdpbGwgY29uc2lkZXIgaG93IHRvIHVwZGF0ZS4NCg0KPiAxLjEgUHJvYmxlbSBzdGF0ZW1lbnQ6 DQo+IA0KPiAiKFtSRkM2NTMwXSBhbmQgW1JGQzY1MzJdIGFsbG93cyBVVEYtOCBjaGFyYWN0ZXJz IGluIHRob3NlIG1haWwgaGVhZGVyDQo+IGZpZWxkcy4iOg0KPiAtIE5pdDogY2xvc2luZyBwYXJl bnRoZXNlIG1pc3NpbmcNCj4gLSBOaXQ6ICJhbGxvd3MiIC0+ICJhbGxvdyINCj4gLSBTZXJpb3Vz IHJhbnQ6IFRoZXJlIGFyZSBOTyAiVVRGLTggY2hhcmFjdGVycyIuIFRoZXJlIGFyZSBVbmljb2Rl DQo+IC0gY2hhcmFjdGVycyBlbmNvZGVkIGluIFVURi04LiBJdCBtYXkgYmUgc2ltcGxlciBhbmQg Y2xlYXJlciBldmVuDQo+IC0gKGJlY2F1c2UgdGhlcmUgaXMgYWxzbyBSRkMgMjA0Ny1lbmNvZGVk IFVURi04KSB0byBzYXkgImFsbG93IHJhdw0KPiAtIFVURi04Ig0KDQp1cGRhdGVkLg0KDQo+IFNl Y3Rpb24gMS4zOg0KPiANCj4gUmVkZWZpbml0aW9uICh1cGRhdGUpIG9mIEZyb20vU2VuZGVyIGlu IFJGQyA1MzIyOiBJIGFtIGluIG5vIHBvc2l0aW9uDQo+IHRvIGp1ZGdlIGhvdyBtdWNoIHNvZnR3 YXJlIGlzIG91dCB0aGVyZSB0aGF0IHdpbGwgYmxvdyB1cCBvbiB0aGlzLCBidXQNCj4gdGhlIGRl c2NyaXB0aW9uIGluIFNlY3Rpb24gMyAobWFueSB3aWxsIHRvbGVyYXRlIC4uLiB3aWxsIGZhaWwg aW4NCj4gdW5wcmVkaWN0YWJsZSB3YXlzKSBkb2Vzbid0IGluc3RpbGwgbXVjaCBjb25maWRlbmNl LiBJJ2QgYmUgd2F5IG1vcmUNCj4gaGFwcHkgaWYgdGhlIGRlc2NyaXB0aW9uIHJlYWQgInRvIHRo ZSBrbm93bGVkZ2Ugb2YgdGhlIFdHLCBhbmQgYWZ0ZXINCj4gZXh0ZW5zaXZlIHRyaWFsIHdpdGgg YSB3aWRlIHZhcmlldHkgb2Ygc29mdHdhcmUsIG5vIGNsaWVudHMgd2VyZSBmb3VuZA0KPiB0aGF0 IGRvbid0IHRvbGVyYXRlIHRoaXMiIChhc3N1bWluZyBpdCdzIHRydWUpLg0KPiBJJ20gYXNzdW1p bmcgdGhhdCB0aGUgV0cgaGFzIGFscmVhZHkgZGlzY3Vzc2VkIHRoaXMsIGFuZCBpdCdzIG9rYXkg Zm9yDQo+IGV2ZXJ5Ym9keSB3aG8gaGFzIGEgbG90IG9mIGltcGxlbWVudGF0aW9uIGFuZCBpbmZy YXN0cnVjdHVyZQ0KPiBleHBlcmllbmNlLCBidXQgaWYgbm90LCBJJ20gcmVhbGx5IG5vdCBzZWVp bmcgdGhlIHBvaW50IG9mIGRlZmluaW5nIGENCj4gZG93bmdyYWRlIHRoYXQgZG9lcyA5OSUgb2Yg dGhlIGpvYiB0byB0aGVuIGJsb3cgdXAgb24gc29tZSBlZGdlIGNhc2VzLg0KDQpSZWRlZmluaXRp b24gb2YgRnJvbS9TZW5kZXIgaW4gUkZDIDUzMjIgaXMgYSBXRyBjb25jbHVzaW9uLCBidXQgSSdt DQpub3Qgc3VyZSB0aGF0IGFsbCBleGlzdGluZyBzb2Z0d2FyZSBkbyBub3QgZW5jb3VudGVyIHBy b2JsZW1zIGNhdXNlZA0KYnkgdGhlIHVwZGF0ZS4gU28sIEkgYWRkZWQgW1sgTm90ZXMgaW4gZHJh ZnQ6IElmIHRoaXMgdXBkYXRlIGlzDQpyZWplY3RlZCwgLi4uXV0gIGluIHNlY3Rpb24gMy4NCg0K PiAiTUlNRSBoZWFkZXIgZmllbGRzIGFyZSBleHBhbmRlZCBpbiBbUkZDNjUzMl0uIiAtPiBUaGUg ZGVmaW5pdGlvbiBvZg0KPiBNSU1FIGhlYWRlciBmaWVsZHMgaW4gSW50ZXJuYXRpb25hbGl6ZWQg RW1haWwgTWVzc2FnZXMgaXMgZ2l2ZW4gaW4NCj4gW1JGQyA2NTMyXS4iDQoNCnVwZGF0ZWQuDQoN Cj4gMi4gVGVybWlub2xvZ3kNCj4gDQo+ICJUaGlzIGRvY3VtZW50IGRlcGVuZHMgb24gW1JGQzY1 MzJdLiAgS2V5IHdvcmRzIHVzZWQgaW4gdGhvc2UNCj4gZG9jdW1lbnRzIGFyZSB1c2VkIGluIHRo aXMgZG9jdW1lbnQsIHRvby4iOg0KPiBPbmx5IG9uZSBkb2N1bWVudCBpcyBtZW50aW9uZWQsIGJ1 dCBpdCBzYXlzICJkb2N1bWVudHMiLiBBbHNvLCBJIGZpcnN0DQo+IHRob3VnaCB0aGlzIHdhcyBh biBpbmRpcmVjdCBpbXBvcnQgZnJvbSBSRkMgMjExOSwgYnV0IHRob3NlIGtleSB3b3Jkcw0KPiBh cmUgZ2l2ZW4gYXQgdGhlIHN0YXJ0IG9mIHNlY3Rpb24gMi4gU28gSSBoYXZlIG5vIGlkZWEgd2hh dCB0aGlzDQo+IHBhcmFncmFwaCByZWZlcnMgdG8uIFBsZWFzZSBleHBsYWluIG9yIHJld29yZC4N Cg0KSSB3aWxsIHVwZGF0ZSB0aGUgcGFydCB0byByZWZlciByZWxhdGVkIGRvY3VtZW50cy4NCg0K PiBTZWN0aW9uIDMNCj4gDQo+IEVOQ09ERUQtV09SRCAiPCIgTk9fRVhJU1RJTkdfQUREUkVTUyAi PiI6DQo+IG5pdDogSSdkIGNoYW5nZSAiTk9fRVhJU1RJTkdfQUREUkVTUyIgdG8gIk5PTl9FWElT VElOR19BRERSRVNTIg0KDQp1cGRhdGVkDQoNCj4gb3BpbmlvbjogSSdkIHN0cm9uZ2x5IHByZWZl ciB0aGlzIHRvIGFuIHVwZGF0ZSBvZiBSRkMgNTMyMi4NCj4gcHJvcG9zYWw6IEl0J3Mgbm90IGEg YmFkIGlkZWEgdG8gbW92ZSB0aGUgVVRGLTggYWRkcmVzcyB0byB0aGUgZGlzcGxheQ0KPiBuYW1l LiBCdXQgdGhpcyBzaG91bGQgYmUgZG9uZSBpbiBhIHdheSB0aGF0IGRvZXNuJ3QgY2FuY2VsIHRo ZQ0KPiBvcmlnaW5hbCBkaXNwbGF5IG5hbWUuIFNvIGluc3RlYWQgb2YNCj4gICBiZWZvcmU6ICBG cm9tOiDQmNCy0LDQvSDQk9GA0L7Qt9C90YvQuSA80JjQstCw0L1AZm9vLmV4YW1wbGUubmV0Pg0K PiAgIGFmdGVyOiAgIEZyb206ID0/VVRGLTg/UT89ZDA9Yjg9ZDA9YjI9ZDA9YjA9ZDA9YmRAZm9v LmV4YW1wbGUubmV0Pz0NCj4gICAgICAgICAgICAgICAgICA8aW52YWxpZC1pMThuLWFkZHJlc3NA aW1hcC5leGFtcGxlLmNvbT4NCj4gDQo+IHNvbWV0aGluZyBsaWtlOg0KPiAgIGJlZm9yZTogIEZy b206INCY0LLQsNC9INCT0YDQvtC30L3Ri9C5IDzQmNCy0LDQvUBmb28uZXhhbXBsZS5uZXQ+DQo+ ICAgYWZ0ZXIgKHdpdGhvdXQgUkZDIDIwNDcgZW5jb2RpbmcpOg0KPiAgICAgICAgICAgIEZyb206 INCY0LLQsNC9INCT0YDQvtC30L3Ri9C5ICjQmNCy0LDQvUBmb28uZXhhbXBsZS5uZXQpDQo+ICAg ICAgICAgICAgICAgICAgIDxpbnZhbGlkLWkxOG4tYWRkcmVzc0BpbWFwLmV4YW1wbGUuY29tPg0K DQpEbyB5b3UgbWVhbiB0aGF0IHJlbW92aW5nIGJyYWNrZXRzICI8PiIgZnJvbSA8YW5nZWwtYWRk cj4gYW5kIHB1dCBpdA0KaW4gYSBjb21tZW50ID8NCg0KSXQgaXMgcmVhc29uYWJsZSBhbmQgSSB3 aWxsIHVwZGF0ZS4NCg0KPiBUaGF0IHByb3Bvc2FsIGFsc28gYXBwbGllcyB0byBBcm50J3Mgc2lt cGxpZmllZCBkcmFmdC4gVGhlIHJlYXNvbiBmb3INCj4gdGhpcyBpcyB0aGF0IGFsdGhvdWdoIG9m dGVuIHRoZXJlIGlzIG92ZXJsYXBwaW5nIGluZm9ybWF0aW9uIGluDQo+IGFkZHJlc3MgYW5kIGRp c3BsYXkgdGV4dCwgaXQncyB1c3VhbGx5IG9ubHkgc29tZSBwYXJ0IHRoYXQncw0KPiBvdmVybGFw cGluZywgYW5kIHRoZSByZXN0IGlzIGhlbHBmdWwsIHRvby4NCj4gDQo+ICJAaW1hcC5leGFtcGxl LmNvbSI6IEkgcHJlZmVyIHRoZSBpZGVhIG9mIHVzaW5nIC5pbnZhbGlkLiBUaGUgY2xlYXJlcg0K PiBpdCBpcyB0aGF0IHRoaXMgaXNuJ3QgYSByZWFsIGFkZHJlc3MgKGJvdGggdG8gaHVtYW5zIGFu ZCBzb2Z0d2FyZSksDQo+IHRoZSBiZXR0ZXIuDQoNCkFybnQncyAuaW52YWxpZCB1c2FnZSBpcyBh bHNvIHVzZWZ1bCBmb3IgTk9OX0VYSVNUSU5HX0FERFJFU1Mgb2YgdGhpcw0KZHJhZnQgaW4gW1sg Tm90ZXMgaW4gZHJhZnRzIF1dLg0KDQo+IFNlY3Rpb24gNQ0KPiANCj4gVGhlIGRyYWZ0IHNob3Vs ZCBiZSBleHRyZW1lbHkgY2xlYXIgb24gdGhlIGZhY3QgdGhhdCB0aGUNCj4gIkRvd25ncmFkaW5n LSIgcHJlZml4IGlzbid0IGEgZ2VuZXJhbCBjb252ZW50aW9uLCBidXQgaXMgcmVzZXJ2ZWQgZm9y DQo+IGV4YWN0bHkgdGhvc2UgaGVhZGVyIGl0IGlzIHVzZWQgd2l0aCBpbiB0aGUgc3BlYy4NCj4g DQo+IDUuMS4xOiBUaGlzIGlzIGFib3V0IGEgc3BlY2lmaWMgaGVhZGVyIGZpZWxkLCBpdCBzZWVt cyB0byBiZWxvbmcgaW4NCj4gNS4yLg0KDQpNb3ZlZCA1LjEuMSBhbmQgTWVyZ2VkIHdpdGggNS4y LjIuDQoNCj4gNS4yLiAgRG93bmdyYWRpbmcgTWV0aG9kIGZvciBFYWNoIEhlYWRlciBGaWVsZA0K PiANCj4gICAgIkhlYWRlciBmaWVsZHMgYXJlIGxpc3RlZCBpbiBbUkZDNDAyMV0uIiAtPiAiW1JG QyA0MDIxXSBlc3RhYmxpc2hlcw0KPiAgICBhIHJlZ2lzdHJ5IG9mIGhlYWRlciBmaWVsZHMuIiAo VGhlcmUgYXJlIGhlYWRlcnMgdGhhdCBhcmUgbm90IGxpc3RlZA0KPiAgICBpbiBSRkMgNDAyMS4p DQoNClVwZGF0ZWQNCg0KPiA1LjIuOS4gIE90aGVyIEhlYWRlciBGaWVsZHMNCj4gICAgImFuZCB0 aGVpciBmaWVsZCB2YWx1ZSBhcmUiIC0+ICJhbmQgdGhlaXIgZmllbGQgdmFsdWVzIGFyZSINCg0K dXBkYXRlZA0KDQo+IDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPiANCj4gICAgVGhlIHB1 cnBvc2Ugb2YgcG9zdC1kZWxpdmVyeSBtZXNzYWdlIGRvd25ncmFkaW5nIGlzIHRvIGFsbG93IFBP UC9JTUFQDQo+ICAgIHNlcnZlcnMgdG8gZGVsaXZlciBpbnRlcm5hdGlvbmFsaXplZCBtZXNzYWdl cyB0byB0cmFkaXRpb25hbCBQT1AvSU1BUA0KPiAgICBjbGllbnRzIGFuZCBwZXJtaXQgdGhlbSB0 byB3b3JrIHdpdGggdGhvc2UgbWVzc2FnZXMuDQo+IA0KPiAgICBUaGUgbGFzdCBjbGF1c2UgKCJw ZXJtaXQgdGhlbSB0byB3b3JrIHdpdGggdGhlc2UgbWVzc2FnZXMiKSBpcw0KPiAgICB1bmNsZWFy LiBXaGF0ICJ3b3JrIiBjYW4gYmUgZG9uZT8NCg0KSSBtZW50aW9uZWQgdGhhdCB0aGUgbWVzc2Fn ZXMgZW5hYmxlIHRoZSByZWNlaXZlcnMgdG8ga25vdyB0aGF0IHRoZXkNCnJlY2VpdmVkIHNvbWV0 aGluZy4NCg0KSSB3aWxsIHRyeSB0byB1cGRhdGUuDQoNCj4gUmVmZXJlbmNlczogUGxlYXNlIG9y ZGVyIGJ5IFJGQyBudW1iZXIsIHRvIG1ha2UgaXQgZWFzeSB0byBmaW5kIGVhY2gNCj4gcmVmZXJl bmNlIHF1aWNrbHkuDQoNCnVwZGF0ZWQuDQoNClJlZ2FyZHMsDQoNCi0tDQpLYXp1bm9yaSBGdWpp d2FyYSwgSlBSUyA8ZnVqaXdhcmFAanBycy5jby5qcD4NCg== From ned+ima@mrochek.com Thu Mar 22 09:47:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1021F8631 for ; Thu, 22 Mar 2012 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MltV7UNUKKZ for ; Thu, 22 Mar 2012 09:47:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 191E021F8629 for ; Thu, 22 Mar 2012 09:47:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODEUB90GOW016YQP@mauve.mrochek.com> for ima@ietf.org; Thu, 22 Mar 2012 09:47:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 22 Mar 2012 09:47:30 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01ODEUB78S9E00ZUIL@mauve.mrochek.com> Date: Thu, 22 Mar 2012 08:50:40 -0700 (PDT) In-reply-to: "Your message dated Mon, 19 Mar 2012 20:39:17 +0900" <4F671AE5.3070305@it.aoyama.ac.jp> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F649967.7040403@it.aoyama.ac.jp> <4F671AE5.3070305@it.aoyama.ac.jp> To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1332434868; bh=dljFnCQq9prG9uQxtWqd95cElbVZlPysnt9ZQ5Mr8pQ=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=DEKRPTdC+X02sKwUrB+5x17+N8wNmbTZFL/eK5QUW9Hm8D4TtiW2oaeWn4UXnsAP7 tW8U4ALGRl9WqGNVBogQhVOx+/IcuZNsS3jfa37gFS7ID60lMQ6zz2ZuP2uiA3NNC0 wSZ+1L/VbceleMQhDAT4KOjhYsQ+gRuO8B9Reyo4= Cc: ima@ietf.org Subject: Re: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:47:37 -0000 > Hello John, > Many thanks to you and others for your comments. > On 2012/03/18 1:47, John C Klensin wrote: > > Martin, > > > > While I think there are a number of things in RFC 6531 that > > could be expressed better (I think those who would like to see > > an Internet Standard version in September might reasonably start > > working on edits now ... although I'd rather see reviews of the > > pending set of documents), > These will be forthcomming, hopefully this week. I started with RFC > 6530/1/2 because I hadn't looked at the base specs in a while and > because I needed to look at them anyway for the mailto: spec (which, > among many other things, actually is on the WG's charter). > > I'm not sure I see an actual error > > here. > > > > Certainly you are correct that U-labels are defined in IDNA as a > > list of Unicode code points, independent of encoding. IDNA > > itself is a layer (or half-layer) below anything in any of the > > base SMTPUTF8 documents, including RFC 6531. But the EAI WG > > made a very explicit decision that anything that went on the > > wire was required to be in UTF-8. If we were writing prose, it > > would be reasonable to express the rule as something like "... > > MUST be a U-label and any U-labels used in conformance with this > > standard MUST be encoded in UTF-8". > Yes, indeed. > > The best way to express that in ABNF is a separate question. > My understanding so far is that the main purpose of ABNF is direct or > indirect executability. That's incorrect. The main purpose of ABNF is to provide a precise specification of the syntax that's allowed by a given specification. The choice of rules often also ties into the semantics. Executability is at *best* a tertiary goal. That's why we allow terminals to be defined in prose, allow complex additional constraints to be expressed in comments, and place no limits on the use of recursion. > Although ABNF can express context-free > languages, in the bulk of uses in the IETF, there is no recursion among > rules, and in these cases, conversion to regular expressions is often > done. And lots of problems result from that rather foolish design pattern. It is rarely the best implementation choice, and the fact that it's popular in some circles doesn't change things any. Parsing email headers is a case in point. There are at least two well known rants about how badly designed modern email is, both from well known members of the Perl community. But as is often the case with such things, they reveal more about the biases of the ranter than they do about the subject being ranted upon. And in this case they both mostly boil down to "Waah! This stuff is hard to deal with using regexps!", since of course that's Perl's hammer. What they really end up saying, in effect, is that these are people unwilling or unable to look past their hammer of choice to look at alternative approaches that solve the problem quite easily. > There lots of regular expression engines running on bytes, and > there are many (sometimes the same ones) running on (Unicode or > otherwise) characters, but I don't know of one where you could do both > things at the same time. Maybe you do? The present situation is another case in point for why you shouldn't be trying to convert ABNF to regexps willy-nilly. The real question you should be asking is whether or not you can usefully do IDNA constraint checks in a regexp, because if you're going to perform an actual syntax check at this level that's what's required. > ... > > I look forward to your erratum, but will push for it to be > > classified as "hold for document update". > That would be fine by me. It's going to depend on what the erratum says. If it's a simple patch to clarify the issue of needing to specify utf-8 as the encoding for u-labels, I've already said that's fine and in fact it should be approved immediately and not held for a document revision. If it attempts to go further and some layer concept to these documents, then it's going to depend on whether that's stated as a possible solution to a problem or a requirement that it must be done. The former is acceptable (although it should be held for a document revision), the latter is not. > > If Jiankang or others > > responded to it by creating a "needs to be revised to clarify > > how a collection of i18n issues should be handled" proposed > > erratum to 5234, that would be only fitting. > No, it wouldn't, because there is no need to fix 5234. > > The "mailto:" issue ultimately involves the same abstraction > > versus expression/encoding issues that, IMO, are the weak > > underbelly of the IRI work. > I agree that insofar as "mailto:" is an URI/IRI scheme, it will share > encoding "issues" with IRIs in general. That should come as no surprise. > However, I have to clearly and strongly disagree with (casual or > on-purpose) interjections such as "weak underbelly". I hope we can all > avoid such terms in technical discussion. > > If you want to adhere to the letter > > and spirit of RFC 6531 (and SMTPUTF8 generally), you are stuck > > with normalized UTF-8 encoding -- no A-labels and no other > > Unicode encoding forms. > I would expect that not only I, but also everybody else, will adhere to > the letter and spirit of RFC 6531, which says that *in the SMTP > protocol*, it's UTF-8 and UTF-8 only. Same for RFC 6532 and header > fields *in transit*. > However, in good IETF tradition, I'd expect that implementations of all > kinds (MUAs, MTAs,...) have all the liberty they need to choose other > encodings where that makes sense for them, as long as they respect the > RFCs on the wire. I may even have seen wording to that effect in one or > the other (or both) of the above RFCs, but I assumed that as a matter of > course and so didn't pay enough attention to be sure about it. As just > one concrete example, I would assume that an MUA written in Java would > use UTF-16 to store email addresses in memory. That's yet another hammer that causes implementation problems in practice (usually ones relating to field length limit calculations). > ... > Having thought about the text in RFC 6531 a bit more, and looked at > http://tools.ietf.org/html/rfc5890#section-2.3.2.1 again, I actually > think it's not even so much a problem of mixing two levels of > description (characters and octets) as of trying to import an ABNF rule > when there never was one. Here is what > http://tools.ietf.org/html/rfc6531#section-3.3 says: > >>>> > The following ABNF rule will be imported from RFC 5234, Appendix B.1, > directly: > o > The following ABNF rule will be imported from RFC 5890, Section > 2.3.2.1, directly: > o > >>>> > If I go to http://tools.ietf.org/html/rfc5234#appendix-B.1, I indeed find: > >>>> > DQUOTE = %x22 > ; " (Double Quote) > >>>> > (which I can add directly to the grammar if my ABNF infrastructure > hasn't it predefined already). On the other hand, if I got to > http://tools.ietf.org/html/rfc5890#section-2.3.2.1, I see some very > precisely worked out definitions that I should be able to turn into > whatever I need for my implementation in due time if I'm not lucky > enough to find a library that has already done that. However, (and > actually for good reasons,) even the word "ABNF" is nowhere in sight in > RFC 5890. But this also suggest that the right way to address the issue is to simply define a new ABNF rule: u-label = > So I currently think that I will propose an erratum along the following > lines: > In http://tools.ietf.org/html/rfc6531#section-3.3, replace > <<<< > The following ABNF rule will be imported from RFC 5890, Section > 2.3.2.1, directly: > o > The following rules are extended in ABNF [RFC5234] as follows. > sub-domain =/ U-label > ; extend the definition of sub-domain in RFC 5321, Section 4.1.2 > <<<< > by > >>>> > The following rules are extended in ABNF [RFC5234] as follows. > sub-domain =/ > ; extend the definition of sub-domain in RFC 5321, Section 4.1.2 > >>>> I think defining a u-label rule is a little cleaner, but this is acceptable. > There are a few other places where RFC 5890 is mentioned in RFC 6531, > and which may have to be tweaked, too. Again, it's going to depend on what those tweaks end up saying. Ned From duerst@it.aoyama.ac.jp Thu Mar 22 23:30:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1447A21E8037 for ; Thu, 22 Mar 2012 23:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.453 X-Spam-Level: X-Spam-Status: No, score=-99.453 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwdI9YLHRR8K for ; Thu, 22 Mar 2012 23:30:33 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9C21E8013 for ; Thu, 22 Mar 2012 23:30:33 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2N6UODq027951 for ; Fri, 23 Mar 2012 15:30:24 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 108c_8e56_ac22420e_74b1_11e1_902e_001d096c566a; Fri, 23 Mar 2012 15:30:23 +0900 Received: from [IPv6:::1] ([133.2.210.1]:56979) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 23 Mar 2012 15:30:28 +0900 Message-ID: <4F6C187A.8060101@it.aoyama.ac.jp> Date: Fri, 23 Mar 2012 15:30:18 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: fujiwara@jprs.co.jp References: <4F69785B.5050704@it.aoyama.ac.jp> <20120322.182759.71100095.fujiwara@jprs.co.jp> In-Reply-To: <20120322.182759.71100095.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ima@ietf.org Subject: Re: [EAI] Comments on Post-delivery downgrade draft (draft-ietf-eai-popimap-downgrade-04.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 06:30:34 -0000 Hello Kazunori, Many thanks for your quick reply. On 2012/03/22 18:27, fujiwara@jprs.co.jp wrote: > Thanks very much for your comments. > >> From: "Martin J. Dürst" >> Section 1.3: >> >> Redefinition (update) of From/Sender in RFC 5322: I am in no position >> to judge how much software is out there that will blow up on this, but >> the description in Section 3 (many will tolerate ... will fail in >> unpredictable ways) doesn't instill much confidence. I'd be way more >> happy if the description read "to the knowledge of the WG, and after >> extensive trial with a wide variety of software, no clients were found >> that don't tolerate this" (assuming it's true). >> I'm assuming that the WG has already discussed this, and it's okay for >> everybody who has a lot of implementation and infrastructure >> experience, but if not, I'm really not seeing the point of defining a >> downgrade that does 99% of the job to then blow up on some edge cases. > > Redefinition of From/Sender in RFC 5322 is a WG conclusion, I see. There are many people on the WG who have more experience with this than me, so I think it's okay. > but I'm > not sure that all existing software do not encounter problems caused > by the update. So, I added [[ Notes in draft: If this update is > rejected, ...]] in section 3. I suggest that somebody more familiar with the actual deployment situation helps you tweak that text. From the fact that there was WG consensus, it may be that your description read scarier than necessary. >> opinion: I'd strongly prefer this to an update of RFC 5322. >> proposal: It's not a bad idea to move the UTF-8 address to the display >> name. But this should be done in a way that doesn't cancel the >> original display name. So instead of >> before: From: Иван Грозный<Иван@foo.example.net> >> after: From: =?UTF-8?Q?=d0=b8=d0=b2=d0=b0=d0=bd@foo.example.net?= >> >> >> something like: >> before: From: Иван Грозный<Иван@foo.example.net> >> after (without RFC 2047 encoding): >> From: Иван Грозный (Иван@foo.example.net) >> > > Do you mean that removing brackets "<>" from and put it > in a comment ? > > It is reasonable and I will update. Ah, sorry, I forgot that parentheses are comments in these fields. A comment is fine, but something else would also be fine, e.g. (without RFC 2047 encoding): From: Иван Грозный: Иван@foo.example.net Regards, Martin. From randy@qualcomm.com Sun Mar 25 05:25:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ABB21F84AE for ; Sun, 25 Mar 2012 05:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.364 X-Spam-Level: X-Spam-Status: No, score=-106.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj-tYMValKKG for ; Sun, 25 Mar 2012 05:25:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id AC22221F849D for ; Sun, 25 Mar 2012 05:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1332678333; x=1364214333; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20|References:=20|X-Mailer:=20Eudora=20for=20Mac=20OS =20X|Date:=20Sun,=2025=20Mar=202012=2005:19:48=20-0700 |To:=20Joseph=20Yee=20,=20"ima@ietf.or g=20WG"=20|From:=20Randall=20Gellens=20|Subject:=20Re:=20[EAI]=20Doodle=20poll =20for=20IETF=20EAI=20April=202012=20Interim=20Meeting=0D =0A=20time|MIME-Version:=201.0|Content-Type:=20text/plain =3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.3 9.5]; bh=qB3Rv5Q4aC89kPq8NcJO3ecOG/4pnDHvelxMiAEbgE8=; b=OewnPLqizUQtDgfk5jJ81CJrQf9VFpCy6UBcz54V2/LpcPco3dIVil1M FIdSCjCoGWYJ0ohrY+jf0aInJgxU0SgQwc0CiYbOQCsdG7ceHx0P7zV/e lhrFqWdmBXxUJpyKxvMKnj7QVeGiLpNqsMzd8Iz05hcJhBh8pVYkIXajG Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6659"; a="175571371" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 25 Mar 2012 05:25:29 -0700 X-IronPort-AV: E=Sophos;i="4.75,314,1330934400"; d="scan'208";a="179765564" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Mar 2012 05:25:29 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sun, 25 Mar 2012 05:25:28 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sun, 25 Mar 2012 05:19:48 -0700 To: Joseph Yee , "ima@ietf.org WG" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [EAI] Doodle poll for IETF EAI April 2012 Interim Meeting time X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 12:25:34 -0000 At 11:46 PM -0400 3/18/12, Joseph Yee wrote: > Note, the range of the meeting time is the third week of April Would the following week (April 23-27) be convenient for people? (I'm not able to participate any of the dates on the Doodle list currently.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A list is only as strong as its weakest link. --Donald Knuth From klensin@jck.com Sun Mar 25 07:43:24 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E621F84C2 for ; Sun, 25 Mar 2012 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57gSf7SNwI9Y for ; Sun, 25 Mar 2012 07:43:24 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E322F21F84AA for ; Sun, 25 Mar 2012 07:43:23 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SBoaW-0002wd-Np; Sun, 25 Mar 2012 10:38:32 -0400 Date: Sun, 25 Mar 2012 10:43:15 -0400 From: John C Klensin To: Randall Gellens , Joseph Yee , "ima@ietf.org WG" Message-ID: <65B94D1DD92787B778D8ED0E@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] Doodle poll for IETF EAI April 2012 Interim Meeting time X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 14:43:24 -0000 --On Sunday, March 25, 2012 05:19 -0700 Randall Gellens wrote: > At 11:46 PM -0400 3/18/12, Joseph Yee wrote: > >> Note, the range of the meeting time is the third week of >> April > > Would the following week (April 23-27) be convenient for > people? The first part of that week is the ISOC Global INET event. I don't know how many EAI participants are going to it --at the moment, I'm not even sure whether I'm going00 but I've been reluctant to schedule against it. Given a travel day, that implies that only Thursday-Friday (26th and 27th) might be available that week. I'd personally be reluctant to let this slip in to May, even though the specific month-boundary is largely symbolic. >... john From randy@qualcomm.com Sun Mar 25 08:03:12 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4472A21F84E2 for ; Sun, 25 Mar 2012 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.391 X-Spam-Level: X-Spam-Status: No, score=-106.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4O3ZbNagrJM for ; Sun, 25 Mar 2012 08:03:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 88BF221F84DD for ; Sun, 25 Mar 2012 08:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1332687791; x=1364223791; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<65B94D1DD92787B778D8ED0E@PST.JCK.COM> |References:=20=0D=0A=20=0D=0A=20<65B94D1DD92787B778D8ED0E@PST.JCK.COM> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sun,=202 5=20Mar=202012=2008:02:04=20-0700|To:=20John=20C=20Klensi n=20,=20Randall=20Gellens=20,=0D=0A=09Joseph=20Yee=20,=20" ima@ietf.org=20WG"=20|From:=20Randall=20Gel lens=20|Subject:=20Re:=20[EAI]=20Dood le=20poll=20for=20IETF=20EAI=20April=202012=20Interim=20 =0D=0A=20Meeting=20time|MIME-Version:=201.0|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"=3B=20format=3Dflo wed|X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.3 0.48.1]; bh=qTYZnMXfkSKZfRUAYn4+9DGZX71KlHl1sHwq1Qytsoo=; b=DxYVBwgWfTDetmO254JH1/1c/nKoqFXo6xWSndZpMqaWH1BOqYpgqeoy kkKg19t3NyNfE+UJC0htl4kQrWUCEIrwHnPIgnvi2w6jdIwo5wvhZLjMD T15e/7vZ9TQORRfaBG5jKM9zltSyd7BHhwb58hmaFWzqhJY+jmtggdhHW I=; X-IronPort-AV: E=McAfee;i="5400,1158,6659"; a="173300490" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 25 Mar 2012 08:03:11 -0700 X-IronPort-AV: E=Sophos;i="4.75,315,1330934400"; d="scan'208";a="179799654" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Mar 2012 08:03:11 -0700 Received: from [192.168.8.84] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sun, 25 Mar 2012 08:03:10 -0700 Message-ID: In-Reply-To: <65B94D1DD92787B778D8ED0E@PST.JCK.COM> References: <65B94D1DD92787B778D8ED0E@PST.JCK.COM> X-Mailer: Eudora for Mac OS X Date: Sun, 25 Mar 2012 08:02:04 -0700 To: John C Klensin , Randall Gellens , Joseph Yee , "ima@ietf.org WG" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [EAI] Doodle poll for IETF EAI April 2012 Interim Meeting time X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 15:03:12 -0000 Given my spotty ability to participate of late, you should schedule whenever it's best for the rest of you. If it happens to be the 26th or 27th, that would give me a nice chance to read the drafts beforehand and participate, which would make me feel less guilty. At 10:43 AM -0400 3/25/12, John C Klensin wrote: > --On Sunday, March 25, 2012 05:19 -0700 Randall Gellens > wrote: > >> At 11:46 PM -0400 3/18/12, Joseph Yee wrote: >> >>> Note, the range of the meeting time is the third week of >>> April >> >> Would the following week (April 23-27) be convenient for >> people? > > The first part of that week is the ISOC Global INET event. I > don't know how many EAI participants are going to it --at the > moment, I'm not even sure whether I'm going00 but I've been > reluctant to schedule against it. Given a travel day, that > implies that only Thursday-Friday (26th and 27th) might be > available that week. > > I'd personally be reluctant to let this slip in to May, even > though the specific month-boundary is largely symbolic. > >>... > > john -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Men fear thought as they fear nothing else on earth, more than ruin, more even than death --Bertrand Russell From duerst@it.aoyama.ac.jp Sun Mar 25 21:12:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A20021E805A for ; Sun, 25 Mar 2012 21:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.137 X-Spam-Level: X-Spam-Status: No, score=-100.137 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EA1s+xlxjrr for ; Sun, 25 Mar 2012 21:12:35 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id A350921E8048 for ; Sun, 25 Mar 2012 21:12:30 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2Q4CNZI024165 for ; Mon, 26 Mar 2012 13:12:24 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3c74_7bfd_e3b1969e_76f9_11e1_b9a6_001d096c5782; Mon, 26 Mar 2012 13:12:23 +0900 Received: from [IPv6:::1] ([133.2.210.1]:58179) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Mar 2012 13:12:27 +0900 Message-ID: <4F6FECA7.80601@it.aoyama.ac.jp> Date: Mon, 26 Mar 2012 13:12:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Fwd: I-D Action: draft-duerst-eai-mailto-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 04:12:36 -0000 The draft announced below contains examples of IRIs. In the .txt version, they are in "XML Notation". In the PDF version (http://tools.ietf.org/pdf/draft-duerst-eai-mailto-03.pdf) and the HTML version (at http://www.sw.it.aoyama.ac.jp/2012/pub/draft-duerst-eai-mailto-03.html), they are actual (Unicode) characters. The main point of this submission is to serve as a contribution to the rfcform BOF at the current IETF meeting. If you want to comment on this aspect of the draft, please write to the relevant mailing list at rfc-interest@rfc-editor.org (but I recommend to check the archives at http://www.rfc-editor.org/pipermail/rfc-interest first; there has been a very active discussion recently). I still have a decent list of edits I plan to make on this draft, so now might not be the best time to review it. Regards, Martin. -------- Original Message -------- Subject: I-D Action: draft-duerst-eai-mailto-03.txt Date: Sun, 25 Mar 2012 20:27:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'mailto' URI/IRI Scheme Author(s) : Martin J. Duerst Larry Masinter Jamie Zawinski Filename : draft-duerst-eai-mailto-03.txt Pages : 22 Date : 2012-03-25 This document defines the format of Uniform Resource Identifiers (URIs) and Internationalized Resource Identfiers (IRIs) to identify resources that are reached using Internet mail. It adds the possibility to use Email Address Internationalization (EAI) email addresses (RFC6530) to the previous syntax of 'mailto' URIs (RFC 6068). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duerst-eai-mailto-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-duerst-eai-mailto-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Internet-Drafts@ietf.org Mon Mar 26 01:42:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA721F84AA; Mon, 26 Mar 2012 01:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrH9TH1roCi3; Mon, 26 Mar 2012 01:42:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B878221F8421; Mon, 26 Mar 2012 01:42:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326084233.13454.2780.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 01:42:33 -0700 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-simpledowngrade-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:42:34 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : EAI: Simplified POP/IMAP downgrading Author(s) : A. Gulbrandsen Filename : draft-ietf-eai-simpledowngrade Pages : 6 Date : March 26, 2012 This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eai-simpledowngrade"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-26014233.I-D@ietf.org> --NextPart-- From arnt@gulbrandsen.priv.no Tue Mar 27 02:16:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA121F890B for ; Tue, 27 Mar 2012 02:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB5i91oJLmPm for ; Tue, 27 Mar 2012 02:16:28 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E471721F8907 for ; Tue, 27 Mar 2012 02:16:23 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2123BF8DBC4; Tue, 27 Mar 2012 09:16:21 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1332839780-9886-9885/10/3; Tue, 27 Mar 2012 09:16:20 +0000 Message-Id: <4F7185C8.5020105@gulbrandsen.priv.no> Date: Tue, 27 Mar 2012 11:18:00 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: IMA Discussion Content-Type: text/plain; charset=iso-8859-1 Subject: [EAI] http://tools.ietf.org/html/draft-ietf-eai-simpledowngrade-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:16:29 -0000 Hi, it's there, and contains language to address almost all comments from reviewews. There is at least one exception. Section 2.3 (about Subject) does not (yet) end with "[RFC2047], perhaps adding a prefix or suffix to inform the user of the downgrading." Alexey wants it, and I think one other person did too? Martin? I know I'm being sloppy about names. Anyway. I'll add it if there's support. Personally I'm against it, since the downgrade process is largely harmless except when the user wants to reply, and when the user wants that there are clear markers on every affected address. Please raise your voice if you support the change. Arnt From barryleiba.mailing.lists@gmail.com Wed Mar 28 08:17:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC34821F86DD for ; Wed, 28 Mar 2012 08:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no8+KlBFzsg6 for ; Wed, 28 Mar 2012 08:17:49 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6B2C21F86C2 for ; Wed, 28 Mar 2012 08:17:48 -0700 (PDT) Received: by ggmi1 with SMTP id i1so873110ggm.31 for ; Wed, 28 Mar 2012 08:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/4G/OVoDS69DKdhxK78W/eYQRY6J65VrWbO6hSV8MFg=; b=ckH8uaSFE4BpLJSdOaqcmWZJ6lherItrlnFOfBjDrj4ZqQ9mwPhXnO9KoSiHRY5ERp VGJ/oM9xOMf3oxdj5JsfwPqcWWw1HoVTPwgTjIj+0z29F8aYJEgR0ACOop0kNDmxrm57 cncmZvuFpysA2aL1GgUopNqXPh+bk304V9TojhtA+Jxa20ZcJNb1wzTIzm2OaOHRBuVD 1i9C4yfxUX9DXQXO032mnR0HjYYmYr2NjlWxa4ph/c7S5iN0Yv5IblWUiWYKpuD2Iw1E /sViVUZEkg+phpeGamG3+IyN/r4MfcgRJSV0crYcrlOr0LeovqjaGVK6doxYC8oEoNvS U7kQ== MIME-Version: 1.0 Received: by 10.236.78.201 with SMTP id g49mr30958851yhe.33.1332947868514; Wed, 28 Mar 2012 08:17:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Wed, 28 Mar 2012 08:17:48 -0700 (PDT) In-Reply-To: <4F7185C8.5020105@gulbrandsen.priv.no> References: <4F7185C8.5020105@gulbrandsen.priv.no> Date: Wed, 28 Mar 2012 17:17:48 +0200 X-Google-Sender-Auth: Ap3Kr2snRUTkRfgc0k4sFtAixQg Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=20cf300fb16134f90604bc4f1cbd Cc: IMA Discussion Subject: Re: [EAI] http://tools.ietf.org/html/draft-ietf-eai-simpledowngrade-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:17:49 -0000 --20cf300fb16134f90604bc4f1cbd Content-Type: text/plain; charset=ISO-8859-1 > There is at least one exception. Section 2.3 (about Subject) does not > (yet) end with "[RFC2047], perhaps adding a prefix or suffix to inform > the user of the downgrading." Alexey wants it, and I think one other > person did too? Martin? I know I'm being sloppy about names. > > Anyway. I'll add it if there's support. Personally I'm against it, since > the downgrade process is largely harmless except when the user wants to > reply, and when the user wants that there are clear markers on every > affected address. I'm very much against it. We can "downgrade" (actually, encode; there's no real downgrading going on here) the subject with NO loss of data and NO ugliness. Let's not screw that up by making it ugly on purpose. Barry --20cf300fb16134f90604bc4f1cbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > There is at least one exception. Section 2.3 (about Subject) does not<= br>> (yet) end with "[RFC2047], perhaps adding a prefix or suffix t= o inform
> the user of the downgrading." Alexey wants it, and I = think one other
> person did too? Martin? I know I'm being sloppy about names.
&g= t;
> Anyway. I'll add it if there's support. Personally I'= ;m against it, since
> the downgrade process is largely harmless exce= pt when the user wants to
> reply, and when the user wants that there are clear markers on every> affected address.

I'm very much against it. =A0We can &qu= ot;downgrade" (actually, encode; there's no real downgrading going= on here) the subject with NO loss of data and NO ugliness. =A0Let's no= t screw that up by making it ugly on purpose.

Barry
--20cf300fb16134f90604bc4f1cbd-- From barryleiba.mailing.lists@gmail.com Wed Mar 28 08:24:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4221E8187 for ; Wed, 28 Mar 2012 08:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vr5p03Xf3ct for ; Wed, 28 Mar 2012 08:24:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4914221E8158 for ; Wed, 28 Mar 2012 08:24:57 -0700 (PDT) Received: by yhkk25 with SMTP id k25so863637yhk.31 for ; Wed, 28 Mar 2012 08:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=K9kIF6FmsLW514uLj2PQUjGeOFUvTw8sksYcLo2glKc=; b=TtWDLjCQvOl9qgdxH1tB1VSxvgNrtT3AMubXGkUedqIxtJBYbs2X0b2nQRu2wy1W1+ p/b3zUHBcvR8yUqdY8YEb2OdvavtCoXYN4g7Z58PeqEooYQ3KhxGH1MhsH1BioFGadAY R+Gyr0GprKVZWSqur1U+VxLSh+zS9M5U9/bC7uUlFz+41Ktxxp1l8g2WKV7R8BGxG0qC id+wbIv0Ae54ON6lcs/+wRZMFt/wmmI8mh0Ka9DaDfkSRQloxlJH/OC/n8Qcupl+SdwS cZSAs8U60I5+0Mp67EzohOs2X2jl9c6qPqdBDIkqbMeS+wkPKO//+FeXD6kOZ7SAoKY0 bIRw== MIME-Version: 1.0 Received: by 10.236.153.36 with SMTP id e24mr30394678yhk.67.1332948296955; Wed, 28 Mar 2012 08:24:56 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Wed, 28 Mar 2012 08:24:56 -0700 (PDT) In-Reply-To: <4F679AC2.5000606@gulbrandsen.priv.no> References: <4F673168.3010201@gulbrandsen.priv.no> <4F6788B5.3000800@isode.com> <4F679AC2.5000606@gulbrandsen.priv.no> Date: Wed, 28 Mar 2012 17:24:56 +0200 X-Google-Sender-Auth: nLyXKqb23vqkbxC_rBNSxWE-QNg Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=20cf302d4990be77a504bc4f350b Cc: "ima@ietf.org" Subject: Re: [EAI] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:24:58 -0000 --20cf302d4990be77a504bc4f350b Content-Type: text/plain; charset=ISO-8859-1 >> In Section 3: I really dislike relaxation of base IMAP rules about sizes >> without at least signalling that with an IMAP capability. I understand >> that this is targeting legacy MUAs, but at least a new capability would >> help with protocol traces. > > Good point. Enough of an argument to add a response code. Cool; I approve of using a response code. Telling someone who can loo at protocol traces that there are non-EAI clients around is fine. Let's not fool ourselves into thinking there's ANY value in informing the end user (Barry's mother). >> But really, an IMAP server can synthesize a message and remember its >> size. We've been through this discussion before with IMAP CONVERT. > > a) This is a peculiar case, since it only ever applies to unaware > clients and not, for example to any messages that are legal according to > core IMAP. It worries me that if a client SELECTs a mailbox with, say, 50,000 messages and does a "FETCH 1:* UID FLAGS RFC822.SIZE", we'll have to convert EVERY message just to get the size, even though the user isn't likely to actually fetch the bodies of more than a few. Let's not, please. Barry --20cf302d4990be77a504bc4f350b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> In Section 3: I really dislike relaxation of base IMAP rules about= sizes
>> without at least signalling that with an IMAP capability= . I understand
>> that this is targeting legacy MUAs, but at least= a new capability would
>> help with protocol traces.
>
> Good point. Enough of a= n argument to add a response code.

Cool; I approve of using a respon= se code. =A0Telling someone who can loo at protocol traces that there are n= on-EAI clients around is fine. =A0Let's not fool ourselves into thinkin= g there's ANY value in informing the end user (Barry's mother).

>> But really, an IMAP server can synthesize a message and rememb= er its
>> size. We've been through this discussion before with= IMAP CONVERT.
>
> a) This is a peculiar case, since it only ev= er applies to unaware
> clients and not, for example to any messages that are legal according = to
> core IMAP.

It worries me that if a client SELECTs a mailb= ox with, say, 50,000 messages and does a "FETCH 1:* UID FLAGS RFC822.S= IZE", we'll have to convert EVERY message just to get the size, ev= en though the user isn't likely to actually fetch the bodies of more th= an a few.

Let's not, please.

Barry --20cf302d4990be77a504bc4f350b-- From klensin@jck.com Thu Mar 29 07:07:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1965021F8AE1 for ; Thu, 29 Mar 2012 07:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXPhc-0i5yhZ for ; Thu, 29 Mar 2012 07:07:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7E63221F8A9D for ; Thu, 29 Mar 2012 07:07:50 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SDFwB-000Ah3-4S; Thu, 29 Mar 2012 10:02:51 -0400 Date: Thu, 29 Mar 2012 10:07:40 -0400 From: John C Klensin To: Barry Leiba , Arnt Gulbrandsen Message-ID: In-Reply-To: References: <4F673168.3010201@gulbrandsen.priv.no> <4F6788B5.3000800@isode.com> <4F679AC2.5000606@gulbrandsen.priv.no> 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] simpledowngrade proto-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:07:51 -0000 --On Wednesday, March 28, 2012 17:24 +0200 Barry Leiba wrote: >>> In Section 3: I really dislike relaxation of base IMAP rules >>> about sizes without at least signalling that with an IMAP >>> capability. I understand that this is targeting legacy MUAs, >>> but at least a new capability would help with protocol >>> traces. >> >> Good point. Enough of an argument to add a response code. > > Cool; I approve of using a response code. Telling someone who > can loo at protocol traces that there are non-EAI clients > around is fine. Let's not fool ourselves into thinking > there's ANY value in informing the end user (Barry's mother). I very slightly disagree, but only very slightly. This is a matter for UI design. Our job is to make sure the UI designer/ implementer(s) have sufficient information available to be sure that they can do the right thing as they see it and a response code seems right for that. As a sometime UI designer, I'd want to be really careful about what I tell (and don't tell) Barry's mother. But, from my point of view, the ideal thing to tell her is that something happened that was bad enough that she called the family computer and email expert (presumably Barry) asked what was going on, and was able to supply enough information (even if it wasn't comprehensible to her) to Barry for him to say "whoops, time to get your client upgraded and to do it right now". That model, I hope obviously, extends far beyond EAI and IMAP. john From klensin@jck.com Thu Mar 29 07:13:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B520121E80DF for ; Thu, 29 Mar 2012 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_00=-2.599, MANGLED_SPAM=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvKrKUE8Jou4 for ; Thu, 29 Mar 2012 07:13:36 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E362C21E803C for ; Thu, 29 Mar 2012 07:13:33 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SDG1i-000Ai4-Ip; Thu, 29 Mar 2012 10:08:34 -0400 Date: Thu, 29 Mar 2012 10:13:24 -0400 From: John C Klensin To: Barry Leiba , Arnt Gulbrandsen Message-ID: <97C3D02E3C3BAF053CD0D6B8@PST.JCK.COM> In-Reply-To: References: <4F7185C8.5020105@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IMA Discussion Subject: Re: [EAI] http://tools.ietf.org/html/draft-ietf-eai-simpledowngrade-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:13:36 -0000 --On Wednesday, March 28, 2012 17:17 +0200 Barry Leiba wrote: >> There is at least one exception. Section 2.3 (about Subject) >> does not (yet) end with "[RFC2047], perhaps adding a prefix >> or suffix to inform the user of the downgrading." Alexey >> wants it, and I think one other person did too? Martin? I >> know I'm being sloppy about names. >> >> Anyway. I'll add it if there's support. Personally I'm >> against it, since the downgrade process is largely harmless >> except when the user wants to reply, and when the user wants >> that there are clear markers on every affected address. > > I'm very much against it. We can "downgrade" (actually, > encode; there's no real downgrading going on here) the subject > with NO loss of data and NO ugliness. Let's not screw that up > by making it ugly on purpose. Agree. As a general guideline, I think that it is reasonable to make any translation or transition that can be made with no loss of information without adding notes. In addition, adding notes to Subject lines after they are transmitted is a bad idea because the recipient has no idea where the note came from (take the number of perfectly good messages that arrive with "[ s p a m ]" in the subject line as an example). If people think they need a note that transformations were applied, let's mandate doing it with a track field ("Received:" or otherwise is a separate discussion) that explains that something was done and by whom. And that part of the behavior, fwiw, should preferably be uniform between simple and not-simple downgrading. john From internet-drafts@ietf.org Thu Mar 29 13:02:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6E221F86FC; Thu, 29 Mar 2012 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHtn0E2-7ZOz; Thu, 29 Mar 2012 13:02:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3D21F8699; Thu, 29 Mar 2012 13:02:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120329200232.32366.95027.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 13:02:32 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-simpledowngrade-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:02:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Wo= rking Group of the IETF. Title : EAI: Simplified POP/IMAP downgrading Author(s) : Arnt Gulbrandsen Filename : draft-ietf-eai-simpledowngrade-03.txt Pages : 7 Date : 2012-03-29 This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-03.txt From arnt@gulbrandsen.priv.no Thu Mar 29 13:11:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2821E805F for ; Thu, 29 Mar 2012 13:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmn-dQt1ADpb for ; Thu, 29 Mar 2012 13:11:31 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 158B421E801A for ; Thu, 29 Mar 2012 13:11:31 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 7FC1DF8DC7E; Thu, 29 Mar 2012 20:11:28 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1333051887-9886-9885/10/14; Thu, 29 Mar 2012 20:11:27 +0000 Message-Id: <4F74C256.40800@gulbrandsen.priv.no> Date: Thu, 29 Mar 2012 22:13:10 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F673168.3010201@gulbrandsen.priv.no> <4F6788B5.3000800@isode.com> <4F679AC2.5000606@gulbrandsen.priv.no> <4F68595E.90503@isode.com> In-Reply-To: <4F68595E.90503@isode.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [EAI] http://tools.ietf.org/html/draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:11:31 -0000 Alexey Melnikov answered me: >> a) This is a peculiar case, since it only ever applies to unaware >> clients and not, for example to any messages that are legal according = to >> core IMAP. b) IMAP CONVERT is not a shining success of deployment and >> usage, so I think that if this document should follow any of its >> example, then good concrete reason is needed. > Although true, I don't think preconditions for the Lemonade discussion > have changed, so I think the conclusions are still valid. Those conclusions played a part in getting zero deployment, so I weigh the factors differently now. My two cents, of course, but I've come to place great emphasis on having a short, easily-read spec that's both easy and simple to implement. -03 is there now. The diff from -02 is small; the document seems to converge. http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-eai-s= impledowngrade-03.txt The main news is the response code you and Barry want: C: a UID FETCH ... S: 42 FETCH (UID 69 ... ... S: a OK [DOWNGRADED 69,71,73] Done Two issues to discuss: a) Is DOWNGRADED the right name? Typist hat off: I don't think that really matters, DOWNGRADE is good enough. b) Should both downgrade documents use it, compatibly? Arnt From arnt@gulbrandsen.priv.no Thu Mar 29 13:18:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278A821E809B for ; Thu, 29 Mar 2012 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c7jFmcaa8qL for ; Thu, 29 Mar 2012 13:18:39 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79F21E801F for ; Thu, 29 Mar 2012 13:18:39 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 8126EF8DC7E; Thu, 29 Mar 2012 20:18:37 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1333052316-9886-9885/10/16; Thu, 29 Mar 2012 20:18:36 +0000 Message-Id: <4F74C404.3020609@gulbrandsen.priv.no> Date: Thu, 29 Mar 2012 22:20:20 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Mime-Version: 1.0 To: ima@ietf.org References: <4F673168.3010201@gulbrandsen.priv.no> <4F6788B5.3000800@isode.com> <4F679AC2.5000606@gulbrandsen.priv.no> <4F68595E.90503@isode.com> <4F74C256.40800@gulbrandsen.priv.no> In-Reply-To: <4F74C256.40800@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] http://tools.ietf.org/html/draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:18:40 -0000 I wrote: > -03 is there now. The number 65 in an example should be 70. Sorry, fixed. Arnt