From barryleiba.mailing.lists@gmail.com Tue Sep 1 07:25:19 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA3D28C6C8 for ; Tue, 1 Sep 2009 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mlUgI9ZbfWC for ; Tue, 1 Sep 2009 07:25:18 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 5C62728C3DA for ; Tue, 1 Sep 2009 07:25:18 -0700 (PDT) Received: by ywh4 with SMTP id 4so9109ywh.17 for ; Tue, 01 Sep 2009 07:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=XV50V3wLeSf5tv2ggpJrP6ZpPvbFZ9l36sPC8G9AOCY=; b=imUonUI2KNJmZyNnvNnGFUsn45yUfHMGaMaN87lyuEmqRab+vkLyfzJPITve1d2hvC uTC7gGi1yxyGHnkDBFqS8PFcisCo8GukayV2WJ3+BC0eapW19O3TzOHjyuyMjEppTH6Q pasW3nzA/96Ije6xfsmdWIxd/zP64j1Bk6ezQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=oAUUb/d3aKP5ew51UXK3vJzB5x2mJ1o+FQiTjOkNrrr4Hnk93HcCluuflSrMa2cX+8 rmLVRooxPdkKesbubrYtYPt6iBd/0MJb5vOSYrX3qmsmH5Zj7aOVbYI4Tc36XeHkrYiB QIL1qjzg7CnKa5rzUNweEbsKin2BuJrahgO5c= MIME-Version: 1.0 Received: by 10.150.81.20 with SMTP id e20mr10412747ybb.132.1251815128123; Tue, 01 Sep 2009 07:25:28 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> Date: Tue, 1 Sep 2009 10:25:28 -0400 Message-ID: <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> From: Barry Leiba To: EAI WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 14:25:19 -0000 I have a few comments in addition to SM's -- they're all editorial, but I think most of them are important. On the other hand, the document's technically sound, and ready to go in that regard. ---------------------------- Throughout: It's customary to use "that", rather than "which", to introduce restrictive clauses. It's not *wrong* to use "which", but it reads badly to this editor's eye, and it invites confusion with non-restrictive clauses, which must use "which" (like this one). Examples: pg 4 OLD MUST reject octet sequences with the high bit set which fail to NEW MUST reject octet sequences with the high bit set that fail to OLD All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP servers which support the "Mailbox International Naming Convention" NEW All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP servers that support the "Mailbox International Naming Convention" Etc. ---------------------------- pg 4 OLD If the UTF8 capability is advertised, then utf8-quoted syntax MAY be used with any IMAP argument that permits a string or an astring. NEW If the server advertises the UTF8 capability, the client MAY use utf8-quoted syntax with any IMAP argument that permits a string. The old text isn't clear about who advertises and who uses, and that should be made clear. Also, "string" is the operative part of the definition of "astring", so the latter doesn't need to be specified here. If it is, we also need to list "nstring". Better to leave them both off. Alternatively, "...permits a string (including astring and nstring)" would be OK. ---------------------------- pg 4 OLD All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP servers which support the "Mailbox International Naming Convention" described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox names and convert them to the appropriate internal format. NEW All IMAP servers that advertise the UTF8 capability SHOULD accept UTF-8 in mailbox names, and those that also support the "Mailbox International Naming Convention" described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox names and convert them to the appropriate internal format. If this change isn't correct, that means that I don't understand what this paragraph is trying to say, and so it should be made clearer anyway. ---------------------------- pg 4 OLD Mailbox names must comply with the Net-Unicode Definition (section 2 of [RFC5198]) with the specific exception that they may not contain control characters (0000-001F, 0080-009F), delete (007F), line separator (2028) or paragraph separator (2029). NEW Mailbox names MUST comply with the Net-Unicode Definition (section 2 of [RFC5198]) with the specific exception that they MAY NOT contain control characters (0000-001F, 0080-009F), delete (007F), line separator (2028) or paragraph separator (2029). It looks like we should be using RFC 2119 words here. ---------------------------- pg 4 OLD If an IMAP client issues a SEARCH command which uses a mixture of utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the IMAP server SHOULD reject the command with a BAD response (due to the conflicting charset labels). NEW An IMAP client MUST NOT issue a SEARCH command that uses a mixture of utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP server receives such a SEARCH command, it SHOULD reject the command with a BAD response (due to the conflicting charset labels). Make it clear whose fault this is, and actively tell the client what it mayn't do. ---------------------------- pg 5 OLD utf8-select-param = "UTF8" ;; Conforms to from RFC 4466 NEW utf8-select-param = "UTF8" ;; Conforms to from RFC 4466 (Scrunch it up a bit...) ---------------------------- pg 7 OLD Specifically, SELECT and EXAMINE with the UTF8 parameter will never fail with a [NOT-UTF-8] response token. NEW Specifically, SELECT and EXAMINE with the UTF8 parameter will never fail with a [NOT-UTF-8] response code. ---------------------------- pg 8 OLD The UTF8=ONLY capability implies the UTF8 base capability, the UTF8=ALL capability and the UTF8=APPEND capability. A server which advertises UTF8=ONLY need not advertise the three implicit capabilities. Oy. This makes parsing the capability string complicated, and should be earlier in the document. It'd be good to make this clear at the beginning, when the UTF8 capability is first mentioned. ---------------------------- pg 8/9 There seems to be a conflict between these two paragraphs: Server implementations also SHOULD up-convert all MIME body headers, SHOULD up-convert or remove the deprecated (and misused) name parameter [RFC1341] on Content-Type and MUST up-convert the Content- Disposition filename parameter. These parameters can be encoded using the standard MIME parameter encoding [RFC2231] mechanism, or via non-standard use of MIME header encoding [RFC2047] in quoted strings. The IMAP server MUST NOT perform up-conversion of headers and content of multipart/signed, as well as Original-Recipient and Return-Path. Isn't it possible to have a subpart of a multipart/signed message that has a Content-Disposition header with a "filename" parameter? If so, the first graph says you MUST up-convert it, and the second says you MUST NOT. Also, I'd prefer putting the parameter names in quotes: "name" parameter ... "filename" parameter. ---------------------------- pg 9 OLD 7-bit downgrading to help comply with the standards are discussed in Downgrading mechanism for Internationalized eMail Address (IMA) [RFC5504]. NEW 7-bit downgrading to help comply with the standards are discussed in "Downgrading Mechanism for Email Address Internationalization" [RFC5504]. ---------------------------- I note for the record that the reference to the obsolete RFC 1341 is intentional. I wonder, though, whether it really ought to be normative. Hm. ---------------------------- That's it... Barry From klensin@jck.com Tue Sep 1 11:27:59 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B58C28C958; Tue, 1 Sep 2009 11:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHq6ot29gzF5; Tue, 1 Sep 2009 11:27:58 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 5ECCE3A6973; Tue, 1 Sep 2009 11:26:29 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MiY3v-000OXG-QK; Tue, 01 Sep 2009 14:26:36 -0400 Date: Tue, 01 Sep 2009 14:26:34 -0400 From: John C Klensin To: Black_David@emc.com, presnick@qualcomm.com, chris.newman@sun.com, gen-art@ietf.org, harald@alvestrand.no Message-ID: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.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] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 18:27:59 -0000 David, A comment on one issue -- speaking for myself, not the WG... --On Monday, August 31, 2009 03:03 -0400 Black_David@emc.com wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >... > Major issues: >... > Section 8 lists a number of 8859 character sets for which > upconversion of MIME headers MUST be supported, and then says > "Other widely deployed MIME charsets SHOULD be supported." > How does an implementer figure out which character sets those > would be? As an alternative, I suggest saying something along > the lines of: any server-supported character set that is a > superset of ASCII should be supported for upconversion. That > probably leads to fewer client surprises caused by UTF-8 not > working as expected. FWIW, "superset of ASCII" turns out to be a nightmare definition. There are languages out there that use Latin-based scripts but don't use all ASCII characters. While I'm not aware of any of them that use coded character sets that don't include all of the undecorated "Latin" characters that appear in ASCII, that combination is certainly plausible and probably does occur somewhere. More important, the issues with local character coding systems are far more severe with non-Latin-based writing systems than they are with Latin-based ones, partially because there are different models for coding (precomposed characters versus combining ones, format and style effectors that may actually change the characters versus greater numbers of precomposed forms, etc.), rendering conversion to or from Unicode a context-dependent translation activity rather than a character-to-character mapping one. On the other hand, if the specification says "this needs to be Unicode, presented in UTF-8, on the wire" then servers pretty much know what they use (or have to deliver to mail-reading MUAs) locally and have to support and convert to and from, without our doing anything more than reminding them that, if they don't do those conversions, things won't work at all well. So, while I agree with you that the text doesn't sound sufficiently specific, I fear that the reality is that trying to actually make it more specific will set us up for either requiring support for conversions that are completely unnecessary in context or for leaving out ones that are important. Indeed, I suspect that the listing of specific 8859 standards will turn out to be a bad idea in the long term, but that is something the WG decided on and, for an Experimental document, I think it is reasonable to leave it there and examine operational experience when that is relevant. best, john From alexey.melnikov@isode.com Tue Sep 1 14:37:10 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1DA3A6BA5; Tue, 1 Sep 2009 14:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D9w5SiOckez; Tue, 1 Sep 2009 14:37:09 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 29E5F3A6C51; Tue, 1 Sep 2009 14:37:09 -0700 (PDT) Received: from [92.40.125.177] (92.40.125.177.sub.mbb.three.co.uk [92.40.125.177]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 1 Sep 2009 22:36:38 +0100 Message-ID: <4A9D93D7.8010709@isode.com> Date: Tue, 01 Sep 2009 22:36:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Black_David@emc.com References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, ima@ietf.org, presnick@qualcomm.com Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:37:11 -0000 Hi David, Thank you for your detailed review. Black_David@emc.com wrote: >I have been selected as the General Area Review Team (Gen-ART) >reviewer for this draft (for background on Gen-ART, please see >http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >Please resolve these comments along with any other Last Call >comments you may receive. > >Document: draft-ietf-eai-imap-utf8-07 >Reviewer: David L. Black >Review Date: August 31, 2009 >IETF LC End Date: August 31, 2009 >IESG Telechat Date: September 10, 2009 > >Summary: > >This draft is on the right track, but has open issues, described >in the review. > >The draft appears to be in good shape, although one has to be an >IMAP expert to understand all of its implications (and I am not >an IMAP expert). I found two open issues: > >- The header upconversion behavior specification for non-UTF-8 > mailstores appears to be incomplete. >- The recommendation to support MIME header upconversion for > "Other widely deployed MIME charsets" strikes me as > too vague to be useful guidance to implementers. > >Major issues: > >Section 3.2, upconversion behavior specification appears to be >incomplete: > > If the mailstore is not UTF-8 > header native and the SELECT or EXAMINE command with UTF-8 header > modifier succeeds, then the server MUST return results as if the > mailstore was UTF-8 header native with upconversion requirements as > described in Section 8. > >What happens if a header that is not upconverted is accessed with >a UTF-8 comparison string (e.g., by SEARCH)? I presume that no >matches occur courtesy of the charset mismatch, but that needs to >be explained, as it will be a surprise to users. > Actually no, I believe this is already fully specified in RFC 3501 (base IMAP spec), Section 6.4.4: The OPTIONAL [CHARSET] specification consists of the word "CHARSET" followed by a registered [CHARSET]. It indicates the [CHARSET] of the strings that appear in the search criteria. [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing text in a [CHARSET] other than US-ASCII. US-ASCII MUST be supported; other [CHARSET]s MAY be supported. So any of the recognized charsets will be decoded by the server and the right thing would happen. >Section 8 lists a number of 8859 character sets for which upconversion >of MIME headers MUST be supported, and then says "Other widely deployed >MIME charsets SHOULD be supported." How does an implementer figure >out which character sets those would be? As an alternative, I suggest >saying something along the lines of: any server-supported character >set that is a superset of ASCII should be supported for upconversion. >That probably leads to fewer client surprises caused by UTF-8 not >working as expected. > > I believe John Klensin has adequately responded to this point. >Minor issues: > >Section 3.1, next to last paragraph needs a couple of RFC 2119 >keywords: > > Mailbox > names must comply with the Net-Unicode Definition (section 2 of >MUST >-->^^^^ > > [RFC5198]) with the specific exception that they may not contain >MUST NOT >----------------------------------------->^^^^^^^ > > control characters (0000-001F, 0080-009F), delete (007F), line > separator (2028) or paragraph separator (2029). > Agreed. I've entered these as RFC Editor notes. >The ABNF in this draft is extensions to ABNF specified elsewhere. >I hope that the combined ABNF grammars have been run through an >ABNF checker, but didn't see any mention of that in the IESG >comment log. > Yes, both Harald Alvestrand and myself checked the ABNF. >This would normally be covered by a shepherd's >report, but I did not see one. > This is coming. >Section 7 recommends that all IMAP clients be modified to display a >clear error when the server advertises UTF8=ONLY. What's the >expected behavior of existing, unmodified clients? > > Such clients will not be using the UTF8 parameter to SELECT/EXAMINE (mailbox opening) commands, so they will fail to do anything useful. But this is to be expected. >Nits/editorial comments: > >Section 2 ought to introduce what's being added to the protocol. >Adaptations of the first two sentences in Section 10 (IANA >Considerations) would suffice. > >While not strictly a security consideration, it would be useful for >section 11 to point out the potential for user confusion caused by >SEARCH command match strings that have different UTF-8 representations >but display identically or similarly (strings that look like they >should match don't). > > I will let editors respond/address these 2 comments. > >------------------------------------------------------------------------ >---- > > ** There is 1 instance of too long lines in the document, the longest >one > being 14 characters in excess of 72. > > > Miscellaneous warnings: > >------------------------------------------------------------------------ >---- > > == The document seems to lack the recommended RFC 2119 boilerplate, >even if > it appears to use RFC 2119 keywords -- however, there's a paragraph >with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > > Checking references for intended status: Experimental > >------------------------------------------------------------------------ >---- > >idnits 2.11.12 found a few things (I've deleted a couple of >obviously incorrect "Missing Reference:" warnings): > > Checking nits according to http://www.ietf.org/ID-Checklist.html: == Unused Reference: 'RFC2045' is defined on line 475, but no explicit > reference was found in the text > > Not sure if this one is needed or not. > == Unused Reference: 'RFC2183' is defined on line 486, but no explicit > reference was found in the text > > I've entered an RFC Editor note that updates the document to reference this RFC. > ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) > According to authors this reference is intentional. From alexey.melnikov@isode.com Tue Sep 1 14:56:13 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F193A70AD for ; Tue, 1 Sep 2009 14:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R219cXK6m7pZ for ; Tue, 1 Sep 2009 14:56:12 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EF5583A70A4 for ; Tue, 1 Sep 2009 14:56:11 -0700 (PDT) Received: from [92.40.125.177] (92.40.125.177.sub.mbb.three.co.uk [92.40.125.177]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 1 Sep 2009 22:56:24 +0100 Message-ID: <4A9D9878.7010302@isode.com> Date: Tue, 01 Sep 2009 22:56:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: barryleiba@computer.org References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> In-Reply-To: <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:56:13 -0000 Hi Barry, Thank you for your review. My comments with my individual participant hat on: Barry Leiba wrote: >I have a few comments in addition to SM's -- they're all editorial, >but I think most of them are important. On the other hand, the >document's technically sound, and ready to go in that regard. > >---------------------------- > >Throughout: >It's customary to use "that", rather than "which", to introduce >restrictive clauses. It's not *wrong* to use "which", but it reads >badly to this editor's eye, and it invites confusion with >non-restrictive clauses, which must use "which" (like this one). > >Examples: >pg 4 >OLD > MUST reject octet sequences with the high bit set which fail to >NEW > MUST reject octet sequences with the high bit set that fail to > >OLD > All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP > servers which support the "Mailbox International Naming Convention" >NEW > All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP > servers that support the "Mailbox International Naming Convention" > >Etc. > I would leave this to RFC Editors. They always fix that. >---------------------------- > >pg 4 > >OLD > If the UTF8 capability is advertised, then utf8-quoted syntax MAY be > used with any IMAP argument that permits a string or an astring. >NEW > If the server advertises the UTF8 capability, the client MAY use > utf8-quoted syntax with any IMAP argument that permits a string. > >The old text isn't clear about who advertises and who uses, and that >should be made clear. Also, "string" is the operative part of the >definition of "astring", so the latter doesn't need to be specified >here. If it is, we also need to list "nstring". Better to leave them >both off. Alternatively, "...permits a string (including astring and >nstring)" would be OK. > Agreed. >---------------------------- > >pg 4 > >OLD > All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP > servers which support the "Mailbox International Naming Convention" > described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox > names and convert them to the appropriate internal format. >NEW > All IMAP servers that advertise the UTF8 capability SHOULD accept > UTF-8 in mailbox names, and those that also support the "Mailbox > International Naming Convention" described in RFC 3501 section 5.1.3 > MUST accept utf8-quoted mailbox names and convert them to the > appropriate internal format. > >If this change isn't correct, that means that I don't understand what >this paragraph is trying to say, and so it should be made clearer >anyway. > I agree with you. >---------------------------- > >pg 4 > >OLD > Mailbox > names must comply with the Net-Unicode Definition (section 2 of > [RFC5198]) with the specific exception that they may not contain > control characters (0000-001F, 0080-009F), delete (007F), line > separator (2028) or paragraph separator (2029). >NEW > Mailbox > names MUST comply with the Net-Unicode Definition (section 2 of > [RFC5198]) with the specific exception that they MAY NOT contain > control characters (0000-001F, 0080-009F), delete (007F), line > separator (2028) or paragraph separator (2029). > >It looks like we should be using RFC 2119 words here. > Yes. David Black (GenArt) already spotted this. >---------------------------- > >pg 4 > >OLD > If an IMAP client issues a SEARCH command which uses a mixture of > utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the > IMAP server SHOULD reject the command with a BAD response (due to the > conflicting charset labels). >NEW > An IMAP client MUST NOT issue a SEARCH command that uses a mixture of > utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP > server receives such a SEARCH command, it SHOULD reject the command > with a BAD response (due to the conflicting charset labels). > >Make it clear whose fault this is, and actively tell the client what >it mayn't do. > > Agree. >---------------------------- > >pg 5 > >OLD > utf8-select-param = "UTF8" > ;; Conforms to > from RFC 4466 >NEW > utf8-select-param = "UTF8" > ;; Conforms to from RFC 4466 > >(Scrunch it up a bit...) > >---------------------------- > >pg 7 > >OLD > Specifically, SELECT and EXAMINE with the UTF8 parameter will never > fail with a [NOT-UTF-8] response token. >NEW > Specifically, SELECT and EXAMINE with the UTF8 parameter will never > fail with a [NOT-UTF-8] response code. > Indeed, "response code" is the proper RFC 3501 term. >---------------------------- > >pg 8 > >OLD > The UTF8=ONLY capability implies the UTF8 base capability, the > UTF8=ALL capability and the UTF8=APPEND capability. A server which > advertises UTF8=ONLY need not advertise the three implicit > capabilities. > >Oy. This makes parsing the capability string complicated, and should >be earlier in the document. It'd be good to make this clear at the >beginning, when the UTF8 capability is first mentioned. > Agreed. [...] From Black_David@emc.com Wed Sep 2 09:54:37 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BCF3A6AC9; Wed, 2 Sep 2009 09:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBtMxndZLxTJ; Wed, 2 Sep 2009 09:54:36 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id D0B433A684D; Wed, 2 Sep 2009 09:54:35 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n82Gr5Ei027557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 12:53:05 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Wed, 2 Sep 2009 12:53:01 -0400 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n82GqsiV004054; Wed, 2 Sep 2009 12:52:59 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:52:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Sep 2009 12:46:04 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A03ABE34F@CORPUSMX80A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-eai-imap-utf8-07 - upconversion SHOULD Thread-Index: AcorMcaWasj+GXKPS9Odkm0md3NmGQAucMcw References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> From: To: , , , , X-OriginalArrivalTime: 02 Sep 2009 16:52:58.0714 (UTC) FILETIME=[D36203A0:01CA2BED] X-EMM-EM: Active Cc: ima@ietf.org, Black_David@emc.com Subject: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 - upconversion SHOULD X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 16:54:37 -0000 John, I freely admit to not being a character set expert. The core question from the review was: > > Section 8 lists a number of 8859 character sets for which > > upconversion of MIME headers MUST be supported, and then says > > "Other widely deployed MIME charsets SHOULD be supported." > > How does an implementer figure out which character sets those > > would be?=20 My attempt to improve on this seems to have missed the mark: > FWIW, "superset of ASCII" turns out to be a nightmare definition. I won't disagree with that, despite the number of 8859 character sets that are listed in the draft. Rather, what would you suggest to address the original concern?=20 Specifically, you wrote: > On the other hand, if the specification says "this needs to be > Unicode, presented in UTF-8, on the wire" then servers pretty > much know what they use (or have to deliver to mail-reading > MUAs) locally and have to support and convert to and from, > without our doing anything more than reminding them that, if > they don't do those conversions, things won't work at all well. Are you suggesting that the "SHOULD" for upconversion to UTF-8 ought to be on all character sets supported by the server, so that a client can just deal with UTF-8? Thanks, --David =20 > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com]=20 > Sent: Tuesday, September 01, 2009 2:27 PM > To: Black, David; presnick@qualcomm.com;=20 > chris.newman@sun.com; gen-art@ietf.org; harald@alvestrand.no > Cc: ima@ietf.org > Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 >=20 > David, >=20 > A comment on one issue -- speaking for myself, not the WG... >=20 > --On Monday, August 31, 2009 03:03 -0400 Black_David@emc.com > wrote: >=20 > > I have been selected as the General Area Review Team (Gen-ART)=20 > > reviewer for this draft (for background on Gen-ART, please see=20 > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).=20 > >... > =20 > > Major issues: > >... > > Section 8 lists a number of 8859 character sets for which > > upconversion of MIME headers MUST be supported, and then says > > "Other widely deployed MIME charsets SHOULD be supported." > > How does an implementer figure out which character sets those > > would be? As an alternative, I suggest saying something along > > the lines of: any server-supported character set that is a > > superset of ASCII should be supported for upconversion. That > > probably leads to fewer client surprises caused by UTF-8 not > > working as expected. >=20 > FWIW, "superset of ASCII" turns out to be a nightmare > definition. There are languages out there that use Latin-based > scripts but don't use all ASCII characters. While I'm not aware > of any of them that use coded character sets that don't include > all of the undecorated "Latin" characters that appear in ASCII, > that combination is certainly plausible and probably does occur > somewhere. More important, the issues with local character > coding systems are far more severe with non-Latin-based writing > systems than they are with Latin-based ones, partially because > there are different models for coding (precomposed characters > versus combining ones, format and style effectors that may > actually change the characters versus greater numbers of > precomposed forms, etc.), rendering conversion to or from > Unicode a context-dependent translation activity rather than a > character-to-character mapping one. >=20 > On the other hand, if the specification says "this needs to be > Unicode, presented in UTF-8, on the wire" then servers pretty > much know what they use (or have to deliver to mail-reading > MUAs) locally and have to support and convert to and from, > without our doing anything more than reminding them that, if > they don't do those conversions, things won't work at all well. >=20 > So, while I agree with you that the text doesn't sound > sufficiently specific, I fear that the reality is that trying to > actually make it more specific will set us up for either > requiring support for conversions that are completely > unnecessary in context or for leaving out ones that are > important. Indeed, I suspect that the listing of specific 8859 > standards will turn out to be a bad idea in the long term, but > that is something the WG decided on and, for an Experimental > document, I think it is reasonable to leave it there and examine > operational experience when that is relevant. >=20 > best, > john >=20 >=20 >=20 From alexey.melnikov@isode.com Wed Sep 2 14:59:36 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083373A7171 for ; Wed, 2 Sep 2009 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2FQmK4HTgyh for ; Wed, 2 Sep 2009 14:59:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 187B23A7178 for ; Wed, 2 Sep 2009 14:57:09 -0700 (PDT) Received: from [92.40.184.226] (92.40.184.226.sub.mbb.three.co.uk [92.40.184.226]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 2 Sep 2009 22:47:04 +0100 Message-ID: <4A9EE7B2.9020204@isode.com> Date: Wed, 02 Sep 2009 22:46:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: barryleiba@computer.org References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> In-Reply-To: <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:59:36 -0000 Hi Barry, Barry Leiba wrote: >pg 8/9 > >There seems to be a conflict between these two paragraphs: > > Server implementations also SHOULD up-convert all MIME body headers, > SHOULD up-convert or remove the deprecated (and misused) name > parameter [RFC1341] on Content-Type and MUST up-convert the Content- > Disposition filename parameter. These parameters can be encoded > using the standard MIME parameter encoding [RFC2231] mechanism, or > via non-standard use of MIME header encoding [RFC2047] in quoted > strings. > > The IMAP server MUST NOT perform up-conversion of headers and content > of multipart/signed, as well as Original-Recipient and Return-Path. > >Isn't it possible to have a subpart of a multipart/signed message that >has a Content-Disposition header with a "filename" parameter? If so, >the first graph says you MUST up-convert it, and the second says you >MUST NOT. > Right. I think the intent is for the second quoted paragraph to override the first. So I think the first sentence of the first quoted paragraph should end with something like: ... and MUST up-convert the Content- Disposition filename parameter, unless it is located inside a multipart/signed body part (see below). >Also, I'd prefer putting the parameter names in quotes: "name" >parameter ... "filename" parameter. > Yes, this would be better. [...] >---------------------------- > >I note for the record that the reference to the obsolete RFC 1341 is >intentional. I wonder, though, whether it really ought to be >normative. Hm. > > It sounds normative. But I don't know if such parameters can be found in the wild in sufficient quantities to worry about anyway. From presnick@qualcomm.com Thu Sep 3 14:25:38 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8B43A68A3; Thu, 3 Sep 2009 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwGRIwIgutC6; Thu, 3 Sep 2009 14:25:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 757F53A6882; Thu, 3 Sep 2009 14:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1252013149; x=1283549149; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<4A9D93D7.8010709@i sode.com>|References:=20<9FA859626025B64FBC2AF149D97C944A 03A3059B@CORPUSMX80A.corp.emc.com>=0D=0A=20<4A9D93D7.8010 709@isode.com>|User-Agent:=20Eudora=206.2.5b1(Macintosh) |Date:=20Thu,=203=20Sep=202009=2015:28:06=20-0500|To:=20A lexey=20Melnikov=20|From:=20Pe te=20Resnick=20|Subject:=20Re:=20[ EAI]=20Gen-ART=20review=20of=20draft-ietf-eai-imap-utf8-0 7|CC:=20,=20,=20|Content-Type:=20text/plain=3B=20charset=3D"u s-ascii"=3B=20format=3Dflowed|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5730"=3B=20a=3D"23084288"; bh=CtyQvRiHgCj75wAuSyocJL7cNU5CGGNfJEuHQn1cGMc=; b=OUgvCvSMsD355RuQ5p5Hnv2ehrG0lTz5FTegDY3tf60PUFCqSKrx/mPN 4lUeM8ik9E9Bd1LBF9EstAviTCDVd/zpTGHWB69IqI6ANpygzMfZu/e6P xxu1Ev9nGcUQ565GZOUWXLEnXSYMV6F/Rfp/CcbwyxejpsAiXaBLHA8Wf 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5730"; a="23084288" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2009 14:24:16 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n83LOGrZ000497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Sep 2009 14:24:16 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n83LOFpv004090 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Sep 2009 14:24:15 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Sep 2009 14:24:15 -0700 Received: from [172.16.1.8] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Sep 2009 14:24:14 -0700 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <4A9D93D7.8010709@isode.com> References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Thu, 3 Sep 2009 15:28:06 -0500 To: Alexey Melnikov From: Pete Resnick Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, Black_David@emc.com, ima@ietf.org Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:25:38 -0000 On 9/1/09 at 10:36 PM +0100, Alexey Melnikov wrote: >Black_David@emc.com wrote: > >>- The header upconversion behavior specification for non-UTF-8 >> mailstores appears to be incomplete. >>- The recommendation to support MIME header upconversion for >> "Other widely deployed MIME charsets" strikes me as >> too vague to be useful guidance to implementers. I'll leave these as they are without further instruction. >>Section 3.1, next to last paragraph needs a couple of RFC 2119 >>keywords: >> >> Mailbox >> names must comply with the Net-Unicode Definition (section 2 of >>MUST >-->^^^^ >> >> [RFC5198]) with the specific exception that they may not contain >>MUST NOT >----------------------------------------->^^^^^^^ >> >> control characters (0000-001F, 0080-009F), delete (007F), line >> separator (2028) or paragraph separator (2029). > >Agreed. I've entered these as RFC Editor notes. Fixed. >>Section 7 recommends that all IMAP clients be modified to display a >>clear error when the server advertises UTF8=ONLY. What's the >>expected behavior of existing, unmodified clients? > >Such clients will not be using the UTF8 parameter to SELECT/EXAMINE >(mailbox opening) commands, so they will fail to do anything useful. >But this is to be expected. No change. >>Nits/editorial comments: >> >>Section 2 ought to introduce what's being added to the protocol. >>Adaptations of the first two sentences in Section 10 (IANA >>Considerations) would suffice. Done. >>While not strictly a security consideration, it would be useful for >>section 11 to point out the potential for user confusion caused by >>SEARCH command match strings that have different UTF-8 representations >>but display identically or similarly (strings that look like they >>should match don't). (*mumble*) This seems to me a job for RFC 3629, not this document. (And, BTW, it does so.) >> ** There is 1 instance of too long lines in the document I'll find that. >> == The document seems to lack the recommended RFC 2119 boilerplate Huh? It's in there. Or is this document so old that it doesn't use the precise recommended wording? I'll leave that for the RFC Editor. >>idnits 2.11.12 found a few things (I've deleted a couple of >>obviously incorrect "Missing Reference:" warnings): >> >> Checking nits according to http://www.ietf.org/ID-Checklist.html: >>== Unused Reference: 'RFC2045' is defined on line 475, but no >>explicit >> reference was found in the text > >Not sure if this one is needed or not. Added a reference. >> == Unused Reference: 'RFC2183' is defined on line 486, but no explicit >> reference was found in the text >> >I've entered an RFC Editor note that updates the document to >reference this RFC. Added. >> ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) >According to authors this reference is intentional. It is. Thanks David (and Alexey). pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From presnick@qualcomm.com Thu Sep 3 14:26:54 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CE328C0CF for ; Thu, 3 Sep 2009 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.349 X-Spam-Level: X-Spam-Status: No, score=-105.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W2Z0-rkzmg5 for ; Thu, 3 Sep 2009 14:26:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 823ED3A6834 for ; Thu, 3 Sep 2009 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1252013232; x=1283549232; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<6.2.5.6.2.20090830 222724.034fdb30@elandnews.com>|References:=20<6.2.5.6.2.2 0090830222724.034fdb30@elandnews.com>|User-Agent:=20Eudor a=206.2.5b1(Macintosh)|Date:=20Thu,=203=20Sep=202009=2015 :28:15=20-0500|To:=20SM=20|From:=20Pete =20Resnick=20|Subject:=20Re:=20[EA I]=20Comments=20on=20draft-ietf-eai-imap-utf8-07|CC:=20EA I=20WG=20|Content-Type:=20text/plain=3B=20c harset=3D"us-ascii"=3B=20format=3Dflowed|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5730"=3B=20a=3D"23060287"; bh=SZ5FSWvIfExBMlDySayRYFH2d58MzvrEIJETG00JTlQ=; b=oAY4sg1nKzOSEwCpwZVblTr6eq8y3Yxi4qOx4EI7kyd9ZVyWtq4KJHOk 9wCgv4kTiic8i6MteDaZriUiEfcdwKA/wPRTG+xPaSG/UTa7SnCTVA8Eb EeWEm4XrUQPWN0zBiR2hK8tHxR+u+eITQWwFTaO7/ha/4Qoy0pIGMPU2n M=; X-IronPort-AV: E=McAfee;i="5300,2777,5730"; a="23060287" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2009 14:24:22 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n83LOMwu000513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Sep 2009 14:24:22 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n83LOH2W011619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Sep 2009 14:24:21 -0700 (PDT) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Sep 2009 14:24:17 -0700 Received: from [172.16.1.8] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Sep 2009 14:24:16 -0700 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Thu, 3 Sep 2009 15:28:15 -0500 To: SM From: Pete Resnick Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:26:54 -0000 On 8/30/09 at 10:46 PM -0700, SM wrote: >The Abstract section mentions that "this is an early draft and >intended as a framework for discussion. Please do not deploy >implementations of this draft." Removed. >In Section 3.3: > > "Instead, the server MUST return any mailbox names with characters > outside the US-ASCII repertorie using utf8-quoted syntax." > >There is a typo for "repertoire". Fixed. Thanks SM. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From presnick@qualcomm.com Thu Sep 3 14:26:54 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC543A67B8 for ; Thu, 3 Sep 2009 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.488 X-Spam-Level: X-Spam-Status: No, score=-105.488 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TklFNO8ESiyT for ; Thu, 3 Sep 2009 14:26:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9C6253A6939 for ; Thu, 3 Sep 2009 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1252013233; x=1283549233; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<4A9D9878.7010302@i sode.com>|References:=20<6.2.5.6.2.20090830222724.034fdb3 0@elandnews.com>=0D=0A=20<6c9fcc2a0909010725m9f1a4c2x159f b13d05df5f91@mail.gmail.com>=0D=0A=20<4A9D9878.7010302@is ode.com>|User-Agent:=20Eudora=206.2.5b1(Macintosh)|Date: =20Thu,=203=20Sep=202009=2015:29:29=20-0500|To:=20Alexey =20Melnikov=20|From:=20Pete=20 Resnick=20|Subject:=20Re:=20[EAI] =20Comments=20on=20draft-ietf-eai-imap-utf8-07|CC:=20,=20EAI=20WG=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"530 0,2777,5730"=3B=20a=3D"23060288"; bh=JtMRC6e7yOeXsM8J4qUic0QMm2cVNSXoQJL/FjIusao=; b=bdS+sXXlOIhlR81N7oY9FWDjX0GKIYoZCRILC1JqIhXM/T08bQaRyzeb ey6I/JT9lrrSxLoECUicAcMOsfIKI4VGujm8SJ8WXamK8zeQxy9Sdd+kO cm1imJVhJlzXJIfRfXMSnraZ7jz48W3dBBIP7sj1P/TYd0ESiG9HSG1zX 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5730"; a="23060288" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2009 14:24:23 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n83LONUm000486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Sep 2009 14:24:23 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n83LOKqb004102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Sep 2009 14:24:21 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Sep 2009 14:24:20 -0700 Received: from [172.16.1.8] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Sep 2009 14:24:18 -0700 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <4A9D9878.7010302@isode.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Thu, 3 Sep 2009 15:29:29 -0500 To: Alexey Melnikov From: Pete Resnick Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: barryleiba@computer.org, EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:26:54 -0000 On 9/1/09 at 10:56 PM +0100, Alexey Melnikov wrote: >>Throughout: >>It's customary to use "that", rather than "which", to introduce >>restrictive clauses. It's not *wrong* to use "which", but it reads >>badly to this editor's eye, and it invites confusion with >>non-restrictive clauses, which must use "which" (like this one). > >I would leave this to RFC Editors. They always fix that. It turned out easy to fix, so I did so, except for the last occurrence of "which", which did not need to be fixed. >>OLD >> If the UTF8 capability is advertised, then utf8-quoted syntax MAY be >> used with any IMAP argument that permits a string or an astring. >>NEW >> If the server advertises the UTF8 capability, the client MAY use >> utf8-quoted syntax with any IMAP argument that permits a string. > >Agreed. Fixed. >>OLD >> All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP >> servers which support the "Mailbox International Naming Convention" >> described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox >> names and convert them to the appropriate internal format. >>NEW >> All IMAP servers that advertise the UTF8 capability SHOULD accept >> UTF-8 in mailbox names, and those that also support the "Mailbox >> International Naming Convention" described in RFC 3501 section 5.1.3 >> MUST accept utf8-quoted mailbox names and convert them to the >> appropriate internal format. >> >>If this change isn't correct, that means that I don't understand what >>this paragraph is trying to say, and so it should be made clearer >>anyway. > >I agree with you. Changed as suggested. >>OLD >> Mailbox >> names must comply with the Net-Unicode Definition (section 2 of >> [RFC5198]) with the specific exception that they may not contain >> control characters (0000-001F, 0080-009F), delete (007F), line >> separator (2028) or paragraph separator (2029). >>NEW >> Mailbox >> names MUST comply with the Net-Unicode Definition (section 2 of >> [RFC5198]) with the specific exception that they MAY NOT contain >> control characters (0000-001F, 0080-009F), delete (007F), line >> separator (2028) or paragraph separator (2029). >> >>It looks like we should be using RFC 2119 words here. > >Yes. David Black (GenArt) already spotted this. Changed to MUST NOT. >>OLD >> If an IMAP client issues a SEARCH command which uses a mixture of >> utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the >> IMAP server SHOULD reject the command with a BAD response (due to the >> conflicting charset labels). >>NEW >> An IMAP client MUST NOT issue a SEARCH command that uses a mixture of >> utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP >> server receives such a SEARCH command, it SHOULD reject the command >> with a BAD response (due to the conflicting charset labels). >> >>Make it clear whose fault this is, and actively tell the client what >>it mayn't do. > >Agree. Changed as suggested. >>OLD >> utf8-select-param = "UTF8" >> ;; Conforms to >> from RFC 4466 >>NEW >> utf8-select-param = "UTF8" >> ;; Conforms to from RFC 4466 >> >>(Scrunch it up a bit...) Fixed. >>OLD >> Specifically, SELECT and EXAMINE with the UTF8 parameter will never >> fail with a [NOT-UTF-8] response token. >>NEW >> Specifically, SELECT and EXAMINE with the UTF8 parameter will never >> fail with a [NOT-UTF-8] response code. > >Indeed, "response code" is the proper RFC 3501 term. Fixed. >>OLD >> The UTF8=ONLY capability implies the UTF8 base capability, the >> UTF8=ALL capability and the UTF8=APPEND capability. A server which >> advertises UTF8=ONLY need not advertise the three implicit >> capabilities. >> >>Oy. This makes parsing the capability string complicated, and should >>be earlier in the document. It'd be good to make this clear at the >>beginning, when the UTF8 capability is first mentioned. > >Agreed. I'm not sure what you want here. Something in the "UTF8" section that says, "See below"? Left as is for now. Fix in an RFC Editor Note if need be. >>pg 8/9 >> >>There seems to be a conflict between these two paragraphs: >> >> Server implementations also SHOULD up-convert all MIME body headers, >> SHOULD up-convert or remove the deprecated (and misused) name >> parameter [RFC1341] on Content-Type and MUST up-convert the Content- >> Disposition filename parameter. These parameters can be encoded >> using the standard MIME parameter encoding [RFC2231] mechanism, or >> via non-standard use of MIME header encoding [RFC2047] in quoted >> strings. >> >> The IMAP server MUST NOT perform up-conversion of headers and content >> of multipart/signed, as well as Original-Recipient and Return-Path. >> >>Isn't it possible to have a subpart of a multipart/signed message that >>has a Content-Disposition header with a "filename" parameter? If so, >>the first graph says you MUST up-convert it, and the second says you >>MUST NOT. > >Right. I think the intent is for the second quoted paragraph to >override the first. >So I think the first sentence of the first quoted paragraph should >end with something like: > >... and MUST up-convert the Content- Disposition filename parameter, >unless it is located inside a multipart/signed body part (see below). Fixed accordingly. >>Also, I'd prefer putting the parameter names in quotes: "name" >>parameter ... "filename" parameter. > >Yes, this would be better. Done. >>OLD >> 7-bit downgrading to help comply with the standards are discussed in >> Downgrading mechanism for Internationalized eMail Address (IMA) >> [RFC5504]. >>NEW >> 7-bit downgrading to help comply with the standards are discussed in >> "Downgrading Mechanism for Email Address Internationalization" >> [RFC5504]. Done. >>I note for the record that the reference to the obsolete RFC 1341 is >>intentional. I wonder, though, whether it really ought to be >>normative. Hm. > >It sounds normative. But I don't know if such parameters can be >found in the wild in sufficient quantities to worry about anyway. No change unless someone says otherwise. Thanks Barry (and Alexey). pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From barryleiba.mailing.lists@gmail.com Thu Sep 3 15:20:42 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F693A6909 for ; Thu, 3 Sep 2009 15:20:42 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EVgCQvFvsnA for ; Thu, 3 Sep 2009 15:20:40 -0700 (PDT) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by core3.amsl.com (Postfix) with ESMTP id 3EB3A3A67E1 for ; Thu, 3 Sep 2009 15:20:39 -0700 (PDT) Received: by ywh42 with SMTP id 42so621678ywh.30 for ; Thu, 03 Sep 2009 15:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V9E0N2nXijrmXxy6CJZagcKR9oRjxT3UfVmjbrbwIKo=; b=WD6BQQu0JWXGrmiRKSHz8/pJkhfFAOnP5w69i4ljv20FbhatnFbhRoZbLy2nE9T2r+ 21FrRhsFFS2LTx5huULlrAa0CXFXstvRDFojj2Jd2HcQtZtYsZSIsT3lCfXqxZ070Qgo bvH/p0b4ldkkWMgujdeq7GOTaJtROt3vSEmqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=lRE8Rjn/W9pBQ2vBhEu/D1z0868hAt/WigujZk2T8+3tZAvUNysTLXW5BJpc5MaPwV W7VuzflJsG3sTBW829LL4PrRvt4PMy+KA8RnDasmeDL/cPLBasHx1znaNeZVtB5MYwUb HGb9pLpky0CsoaeyHOOLpMJBn+E1tz9OTFTyw= MIME-Version: 1.0 Received: by 10.150.55.42 with SMTP id d42mr15913659yba.244.1252016316701; Thu, 03 Sep 2009 15:18:36 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> Date: Thu, 3 Sep 2009 18:18:36 -0400 Message-ID: <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 22:20:43 -0000 Hi, Pete. >> OLD >> =A0The UTF8=3DONLY capability implies the UTF8 base capability, the >> =A0UTF8=3DALL capability and the UTF8=3DAPPEND capability. =A0A server w= hich >> =A0advertises UTF8=3DONLY need not advertise the three implicit >> =A0capabilities. >> >> Oy. =A0This makes parsing the capability string complicated, and should >> be earlier in the document. =A0It'd be good to make this clear at the >> beginning, when the UTF8 capability is first mentioned. > > I'm not sure what you want here. Something in the "UTF8" section that say= s, > "See below"? Left as is for now. Fix in an RFC Editor Note if need be. When one starts reading the document, one gets to this: --------------------------------------------- 3. UTF8 IMAP Capability The basic "UTF8" capability indicates the server supports UTF-8 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB commands. --------------------------------------------- It's only later, when one gets to section 7, which I quote above, that one finds that it's not sufficient to look for "UTF8": one also has to look for "UTF8=3DONLY". And we don't say that UTF8=3DALL, UTF8=3DAPPEND, o= r UTF8=3DUSER imply the base UTF8. So if UTF8=3DONLY is special, I think we need to say that right up there at the start of section 3, so it's clear. Or else we say that the presence of *any* "UTF8=3D" capability implies the base UTF8, and say *that* in section 3, so it's clear right up front as to what capability string(s) need to be checked for. D'you see what I'm getting at? Barry From jyee@ca.afilias.info Thu Sep 3 15:31:04 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97A63A696A; Thu, 3 Sep 2009 15:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBcm2yGGNBeg; Thu, 3 Sep 2009 15:31:03 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 5036D3A6880; Thu, 3 Sep 2009 15:31:03 -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 1MjKVS-00041g-6G; Thu, 03 Sep 2009 22:10:14 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MjKVS-0006Cz-8o; Thu, 03 Sep 2009 22:10:14 +0000 From: Joseph Yee To: Pete Resnick In-Reply-To: References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> Message-Id: <07A561BA-CBE7-48A7-A598-832B72D697A5@ca.afilias.info> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Sep 2009 18:10:14 -0400 X-Mailer: Apple Mail (2.936) Cc: gen-art@ietf.org, Black_David@emc.com, ima@ietf.org Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 22:31:05 -0000 On 3-Sep-09, at 4:28 PM, Pete Resnick wrote: [snip] > >>> While not strictly a security consideration, it would be useful for >>> section 11 to point out the potential for user confusion caused by >>> SEARCH command match strings that have different UTF-8 >>> representations >>> but display identically or similarly (strings that look like they >>> should match don't). > > (*mumble*) This seems to me a job for RFC 3629, not this document. > (And, BTW, it does so.) Agreed with Pete, the security concerns are user name and password. SEARCH is more of usability than security. Maybe mention it in design rational instead? (Just suggesting, not saying it MUST or SHOULD) Regards, Joseph > >>> ** There is 1 instance of too long lines in the document > > I'll find that. > >>> == The document seems to lack the recommended RFC 2119 boilerplate > > Huh? It's in there. Or is this document so old that it doesn't use > the precise recommended wording? I'll leave that for the RFC Editor. > >>> idnits 2.11.12 found a few things (I've deleted a couple of >>> obviously incorrect "Missing Reference:" warnings): >>> >>> Checking nits according to http://www.ietf.org/ID-Checklist.html: >>> == Unused Reference: 'RFC2045' is defined on line 475, but no >>> explicit >>> reference was found in the text >> >> Not sure if this one is needed or not. > > Added a reference. > >>> == Unused Reference: 'RFC2183' is defined on line 486, but no >>> explicit >>> reference was found in the text >>> >> I've entered an RFC Editor note that updates the document to >> reference this RFC. > > Added. > >>> ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) >> According to authors this reference is intentional. > > It is. > > Thanks David (and Alexey). > > pr > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: > (858)651-1102 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From Black_David@emc.com Fri Sep 4 02:50:47 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962983A69B4; Fri, 4 Sep 2009 02:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfqiucMO3Z5S; Fri, 4 Sep 2009 02:50:46 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id BBE473A65A6; Fri, 4 Sep 2009 02:50:44 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n846EtbO022084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 02:14:55 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Fri, 4 Sep 2009 02:14:51 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n846En7m022528; Fri, 4 Sep 2009 02:14:50 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 02:14:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Sep 2009 02:14:48 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com> In-Reply-To: <4A9D93D7.8010709@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-eai-imap-utf8-07 Thread-Index: AcorTFy2L5Rsf5bhSbCFtlvIt3z0lQAoJVyA References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> From: To: X-OriginalArrivalTime: 04 Sep 2009 06:14:49.0446 (UTC) FILETIME=[0206E060:01CA2D27] X-EMM-EM: Active Cc: gen-art@ietf.org, ima@ietf.org, presnick@qualcomm.com, Black_David@emc.com Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:50:47 -0000 Alexey, > >- The header upconversion behavior specification for non-UTF-8 > > mailstores appears to be incomplete. ... > Actually no, I believe this is already fully specified in RFC=20 > 3501 (base IMAP spec), Section 6.4.4: I concur - this is not an issue. Thanks for the pointer to the relevant portion of RFC 3501. > >- The recommendation to support MIME header upconversion for > > "Other widely deployed MIME charsets" strikes me as > > too vague to be useful guidance to implementers. ... > I believe John Klensin has adequately responded to this point. John has thoroughly demolished the change I suggested, but I don't think that demolition resolves this concern, as the original text remains vague. OTOH, this draft is intended to be an Experimental RFC - would it be reasonable to say that determining which charsets should be upconverted is part of the experiment? > >While not strictly a security consideration, it would be useful for > >section 11 to point out the potential for user confusion caused by > >SEARCH command match strings that have different UTF-8 representations > >but display identically or similarly (strings that look like they > >should match don't). That was a nit - leaving the Section 11 text unmodified is fine, as Section 11 already references RFC 3629. Thanks, --David =20 > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 > Sent: Tuesday, September 01, 2009 5:36 PM > To: Black, David > Cc: presnick@qualcomm.com; chris.newman@sun.com;=20 > gen-art@ietf.org; harald@alvestrand.no; lee@cnnic.cn; ima@ietf.org > Subject: Re: Gen-ART review of draft-ietf-eai-imap-utf8-07 >=20 > Hi David, > Thank you for your detailed review. >=20 > Black_David@emc.com wrote: >=20 > >I have been selected as the General Area Review Team (Gen-ART)=20 > >reviewer for this draft (for background on Gen-ART, please see=20 > >http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).=20 > > > >Please resolve these comments along with any other Last Call > >comments you may receive. > > > >Document: draft-ietf-eai-imap-utf8-07 > >Reviewer: David L. Black > >Review Date: August 31, 2009 > >IETF LC End Date: August 31, 2009 > >IESG Telechat Date: September 10, 2009 > >=20 > >Summary: > > > >This draft is on the right track, but has open issues, described > >in the review. > > > >The draft appears to be in good shape, although one has to be an > >IMAP expert to understand all of its implications (and I am not > >an IMAP expert). I found two open issues: > > > >- The header upconversion behavior specification for non-UTF-8 > > mailstores appears to be incomplete. > >- The recommendation to support MIME header upconversion for > > "Other widely deployed MIME charsets" strikes me as > > too vague to be useful guidance to implementers. > > > >Major issues: > > > >Section 3.2, upconversion behavior specification appears to be > >incomplete: > > > > If the mailstore is not UTF-8 > > header native and the SELECT or EXAMINE command with UTF-8 header > > modifier succeeds, then the server MUST return results as if the > > mailstore was UTF-8 header native with upconversion=20 > requirements as > > described in Section 8. =20 > > > >What happens if a header that is not upconverted is accessed with > >a UTF-8 comparison string (e.g., by SEARCH)? I presume that no > >matches occur courtesy of the charset mismatch, but that needs to > >be explained, as it will be a surprise to users. > > > Actually no, I believe this is already fully specified in RFC=20 > 3501 (base=20 > IMAP spec), Section 6.4.4: >=20 > The OPTIONAL [CHARSET] specification consists of the word > "CHARSET" followed by a registered [CHARSET]. It indicates the > [CHARSET] of the strings that appear in the search criteria. > [MIME-IMB] content transfer encodings, and [MIME-HDRS]=20 > strings in > [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing > text in a [CHARSET] other than US-ASCII. US-ASCII MUST be > supported; other [CHARSET]s MAY be supported. >=20 > So any of the recognized charsets will be decoded by the=20 > server and the=20 > right thing would happen. >=20 > >Section 8 lists a number of 8859 character sets for which=20 > upconversion > >of MIME headers MUST be supported, and then says "Other=20 > widely deployed > >MIME charsets SHOULD be supported." How does an implementer figure > >out which character sets those would be? As an alternative,=20 > I suggest > >saying something along the lines of: any server-supported character > >set that is a superset of ASCII should be supported for upconversion. > >That probably leads to fewer client surprises caused by UTF-8 not > >working as expected. > > =20 > > > I believe John Klensin has adequately responded to this point. >=20 > >Minor issues: > > > >Section 3.1, next to last paragraph needs a couple of RFC 2119 > >keywords: > > > > Mailbox > > names must comply with the Net-Unicode Definition (section 2 of > >MUST >-->^^^^ > > > > [RFC5198]) with the specific exception that they may not contain > >MUST NOT >----------------------------------------->^^^^^^^ > > > > control characters (0000-001F, 0080-009F), delete (007F), line > > separator (2028) or paragraph separator (2029). > > > Agreed. I've entered these as RFC Editor notes. >=20 > >The ABNF in this draft is extensions to ABNF specified elsewhere. > >I hope that the combined ABNF grammars have been run through an > >ABNF checker, but didn't see any mention of that in the IESG > >comment log. > > > Yes, both Harald Alvestrand and myself checked the ABNF. >=20 > >This would normally be covered by a shepherd's > >report, but I did not see one. > > > This is coming. >=20 > >Section 7 recommends that all IMAP clients be modified to display a > >clear error when the server advertises UTF8=3DONLY. What's the > >expected behavior of existing, unmodified clients? > > =20 > > > Such clients will not be using the UTF8 parameter to SELECT/EXAMINE=20 > (mailbox opening) commands, so they will fail to do anything=20 > useful. But=20 > this is to be expected. >=20 > >Nits/editorial comments: > > > >Section 2 ought to introduce what's being added to the protocol. > >Adaptations of the first two sentences in Section 10 (IANA > >Considerations) would suffice. > > > >While not strictly a security consideration, it would be useful for > >section 11 to point out the potential for user confusion caused by > >SEARCH command match strings that have different UTF-8=20 > representations > >but display identically or similarly (strings that look like they > >should match don't). > > =20 > > > I will let editors respond/address these 2 comments. >=20 > >=20 > >------------------------------------------------------------- > ----------- > >---- > > > > ** There is 1 instance of too long lines in the document,=20 > the longest > >one > > being 14 characters in excess of 72. > > > > > > Miscellaneous warnings: > >=20 > >------------------------------------------------------------- > ----------- > >---- > > > > =3D=3D The document seems to lack the recommended RFC 2119 = boilerplate, > >even if > > it appears to use RFC 2119 keywords -- however, there's=20 > a paragraph > >with > > a matching beginning. Boilerplate error? > > > > (The document does seem to have the reference to RFC=20 > 2119 which the > > ID-Checklist requires). > > > > Checking references for intended status: Experimental > >=20 > >------------------------------------------------------------- > ----------- > >---- > > > >idnits 2.11.12 found a few things (I've deleted a couple of > >obviously incorrect "Missing Reference:" warnings): > > > > Checking nits according to=20 > http://www.ietf.org/ID-Checklist.html: =3D=3D Unused Reference:=20 > 'RFC2045' is defined on line 475, but no explicit > > reference was found in the text > > =20 > > > Not sure if this one is needed or not. >=20 > > =3D=3D Unused Reference: 'RFC2183' is defined on line 486, but=20 > no explicit > > reference was found in the text > > =20 > > > I've entered an RFC Editor note that updates the document to=20 > reference=20 > this RFC. >=20 > > ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) =20 > > > According to authors this reference is intentional. >=20 >=20 >=20 From edainow@ca.afilias.info Fri Sep 4 05:58:37 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5DF3A6A20 for ; Fri, 4 Sep 2009 05:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_05=-1.11, FRT_BEFORE=1.272, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7Wr71pW00YW for ; Fri, 4 Sep 2009 05:58:36 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id CDE373A6A0E for ; Fri, 4 Sep 2009 05:58:36 -0700 (PDT) Message-ID: <4AA10ED8.7040500@ca.afilias.info> Date: Fri, 04 Sep 2009 08:58:00 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: [EAI] downgraded headers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 12:58:37 -0000 Further testing of downgrade with a second EAI implementation was successful on several cases where the first test had failed. Analysis led to the conclusion that the failures on the first tests were due primarily to an invalid continuation line in a header (contained a blank line). The second implementation also had an error in a header line (exceeded 80 length) but the email systems tested against were robust to this error. There were no clear cases of failure that could be attributed to introducing an unknown header into the email system. Based on this (note it is still a small test sample), it seems reasonable to consider keeping Downgraded headers. If we accept the simplified design goal for Downgrade that abandons any attempt to recover the original EAI information from downgraded headers to display to the user, then the only value of such headers is to provide audit trail information for email administrators or advanced users. However, these headers are not humanly readable. Here is an example from from one of the tests: Downgraded-From: =?UTF-8?B?zpXPgc69zrnOtQ==?= =?UTF-8?B?zpTOsc65zr3Ov8+J?=<=?UTF-8?B?zrXPgc69QM+AzrHOs866z4zPg868zrnOv y3PhM6xz4fPhc60z4HOv868zrXOr86/?= =?UTF-8?B?LmluZm8=?= > There is a range of choices: 1) keep all downgraded headers as described in RFC5504, Section 3. 2) keep only Downgraded-From (and perhaps a few others) 3) drop all downgraded headers My preference would be for 3) as the ultimate simplification. However, I have never been an email administrator and may be underestimating the value of the information these headers provide. -Ernie Dainow From edainow@ca.afilias.info Fri Sep 4 14:43:01 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3D13A688A for ; Fri, 4 Sep 2009 14:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It7jQ71OIxzl for ; Fri, 4 Sep 2009 14:43:00 -0700 (PDT) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id 3022D3A6778 for ; Fri, 4 Sep 2009 14:42:59 -0700 (PDT) Received: from edainow.tor.afilias-int.info ([10.10.68.27]) by tor-gateway.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MjgYZ-00023w-6w for ima@ietf.org; Fri, 04 Sep 2009 17:42:55 -0400 Message-ID: <4AA18AB2.5080508@ca.afilias.info> Date: Fri, 04 Sep 2009 17:46:26 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: EAI Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 21:43:01 -0000 One of the key goals in simplifying Downgrade is to drop the double angle bracket notation, due to compatibility and security concerns. There have been a few email threads on this. I think the following summarizes the current thinking. Dropping double angle brackets on Recipient addresses is part of the downgrade simplification to not support downgrade of forward pointing addresses (considering these cases as configuration errors). To replace double angle brackets for the Sender, John Klensin proposed using multiple From fields. SM amended this with Reply-To to specify the preferred address, as in From: EAI-addr, ASCII-addr Reply-To: EAI-addr where the EAI-addr gets dropped in Downgrade. I did some (non-EAI) tests of multiple From fields with Reply-To on two different email systems and both worked as expected. This looks like an elegant solution. SM raised some possible problems with multiple From addresses on mailing lists. The suggestion was to address these issues in the mailinglist document. There still needs to be a mechanism to carry the alternate address of the sender in the envelope through SMTP relays up until the point that a non-EAI transport is encountered. No change is being proposed to the EAI SMTP extension for the ALT-ADDRESS parameter on MAIL FROM. If a non-EAI server is encountered, Downgrade is done on the message and the EAI address in the Envelope is replaced with the ALT-ADDRESS. However, we would drop the ALT-ADDRESS parameter on RCPT TO. -Ernie Dainow From jyee@ca.afilias.info Fri Sep 4 14:57:01 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2B03A682F for ; Fri, 4 Sep 2009 14:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qtro+T9vBtC for ; Fri, 4 Sep 2009 14:57:00 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 189A93A6850 for ; Fri, 4 Sep 2009 14:57:00 -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 1Mjgkx-0006Nw-6D; Fri, 04 Sep 2009 21:55:43 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Mjgkx-0004Uc-8n; Fri, 04 Sep 2009 21:55:43 +0000 From: Joseph Yee To: barryleiba@computer.org In-Reply-To: <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> Message-Id: <1A999F1D-63B0-4142-BEF4-6B48371BABD9@ca.afilias.info> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 4 Sep 2009 17:55:43 -0400 X-Mailer: Apple Mail (2.936) Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 21:57:01 -0000 Let me try... I think it's down to whether ENABLE UTF8 enables everything in section 4,5,6.7, or we need to write ENABLE UTF8=APPEND, ENABLE UTF8=ALL, etc. And from my own understanding, UTF8=ALL is superset of UTF8, so it is UTF8=ONLY implies {UTF8=ALL, UTF8=APPEND} UTF8=ALL implies UTF8 UTF8=APPEND is not clear on UTF8, but can be UTF8=USER is info on SASL, but can imply UTF8 I think specifying the following should do.. UTF8=ONLY --> {UTF8=ALL, UTF8=APPEND, No m-UTF7} [This is clear from the doc] UTF8=ALL --> {UTF8} [This is clear] UTF8=APPEND --> {UTF8} UTF8=USER --> {UTF8} [USER is not something client can enable anyway] Joseph On 3-Sep-09, at 6:18 PM, Barry Leiba wrote: > Hi, Pete. > >>> OLD >>> The UTF8=ONLY capability implies the UTF8 base capability, the >>> UTF8=ALL capability and the UTF8=APPEND capability. A server which >>> advertises UTF8=ONLY need not advertise the three implicit >>> capabilities. >>> >>> Oy. This makes parsing the capability string complicated, and >>> should >>> be earlier in the document. It'd be good to make this clear at the >>> beginning, when the UTF8 capability is first mentioned. >> >> I'm not sure what you want here. Something in the "UTF8" section >> that says, >> "See below"? Left as is for now. Fix in an RFC Editor Note if need >> be. > > When one starts reading the document, one gets to this: > > --------------------------------------------- > 3. UTF8 IMAP Capability > > The basic "UTF8" capability indicates the server supports UTF-8 > quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and > UTF-8 > responses from the LIST and LSUB commands. > --------------------------------------------- > > It's only later, when one gets to section 7, which I quote above, that > one finds that it's not sufficient to look for "UTF8": one also has to > look for "UTF8=ONLY". And we don't say that UTF8=ALL, UTF8=APPEND, or > UTF8=USER imply the base UTF8. So if UTF8=ONLY is special, I think we > need to say that right up there at the start of section 3, so it's > clear. Or else we say that the presence of *any* "UTF8=" capability > implies the base UTF8, and say *that* in section 3, so it's clear > right up front as to what capability string(s) need to be checked for. > > D'you see what I'm getting at? > > Barry > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From root@core3.amsl.com Fri Sep 4 15:30:02 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 137D53A691C; Fri, 4 Sep 2009 15:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090904223002.137D53A691C@core3.amsl.com> Date: Fri, 4 Sep 2009 15:30:02 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-imap-utf8-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 22:30:02 -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 : IMAP Support for UTF-8 Author(s) : P. Resnick, C. Newman Filename : draft-ietf-eai-imap-utf8-08.txt Pages : 14 Date : 2009-09-04 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eai-imap-utf8-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-04151756.I-D@ietf.org> --NextPart-- From chl@clerew.man.ac.uk Sun Sep 6 04:58:07 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB1428C101 for ; Sun, 6 Sep 2009 04:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LVMd2zEmMjl for ; Sun, 6 Sep 2009 04:58:06 -0700 (PDT) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by core3.amsl.com (Postfix) with ESMTP id DB8133A69A5 for ; Sun, 6 Sep 2009 04:58:05 -0700 (PDT) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew$man^ac#uk) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4aa3a3e5.4211.31 for ima@ietf.org; Sun, 6 Sep 2009 12:58:29 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id n86BwOY8003855 for ; Sun, 6 Sep 2009 12:58:26 +0100 (BST) Date: Sun, 06 Sep 2009 12:58:24 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <4AA18AB2.5080508@ca.afilias.info> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4AA18AB2.5080508@ca.afilias.info> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 11:58:07 -0000 On Fri, 04 Sep 2009 22:46:26 +0100, Ernie Dainow wrote: > One of the key goals in simplifying Downgrade is to drop the double > angle bracket notation, due to compatibility and security concerns. > There have been a few email threads on this. I think the following > summarizes the current thinking. > > Dropping double angle brackets on Recipient addresses is part of the > downgrade simplification to not support downgrade of forward pointing > addresses (considering these cases as configuration errors). > > To replace double angle brackets for the Sender, John Klensin proposed > using multiple From fields. SM amended this with Reply-To to specify the > preferred address, as in > From: EAI-addr, ASCII-addr > Reply-To: EAI-addr > where the EAI-addr gets dropped in Downgrade. > > I did some (non-EAI) tests of multiple From fields with Reply-To on two > different email systems and both worked as expected. This looks like an > elegant solution. Yes, but the interesting case is multiple fields in Reply-To. Normally, these will cause the reply to go to _both_ (but if one is utf-8 and one is ascii, then the utf-8 might fail). If we retain the double angle brackets, then one could still say, in the Reply-To, "please reply to my utf-8 address if possible, but if your system (or some intermediate server that knows how to downgrade) can't do that, then please reply to my ascii address". I would expect that to be the commonest (and most useful) situation in which those double angle brackets will appear in practice. So my preference would be to retain them, at least so long as these remain Experimental documents. If the eventual Standard still retains them, then it could still say "this feature may well be withdrawn in a future version of this standard" (with the intent to do so when utf-8 has become so widely implemented that it is no longer needed). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From harald@alvestrand.no Sun Sep 6 05:59:11 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B9D28C112 for ; Sun, 6 Sep 2009 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmyJYqHKluIv for ; Sun, 6 Sep 2009 05:59:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 39F9128C100 for ; Sun, 6 Sep 2009 05:59:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6247039E15D for ; Sun, 6 Sep 2009 14:59:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWNfXtPuVN+E for ; Sun, 6 Sep 2009 14:59:29 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C41EB39E145 for ; Sun, 6 Sep 2009 14:59:29 +0200 (CEST) Message-ID: <4AA3B231.3000707@alvestrand.no> Date: Sun, 06 Sep 2009 14:59:29 +0200 From: Harald Tveit Alvestrand User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Summary of WG Last Calls X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 12:59:11 -0000 This is the very brief summary of the WG Last Call for the three documents: - draft-ietf-eai-pop-06 - draft-ietf-eai-imap-utf8-07 - draft-ietf-eai-downgraded-display-01 POP: There are nits that should be fixed. There are no technical objections to the approach taken. Once -07 is published, fixing the nits, this will be sent to the IESG. IMAP: There are nits that should be fixed. The AD has already issued the IETF Last Call. A new revision should be issued at the AD's discretion, either before or after the IESG telechat. DOWGRADED-DISPLAY: There are nits that should be fixed, and the language around security considerations needs to be somewhat clearer in how attacks can be guarded against. There are no serious technical omissions identified. Once -02 is published, fixing the identified issues, this will be sent to the IESG. If anything remains unclear, please respond. Harald From harald@alvestrand.no Sun Sep 6 08:54:08 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F523A6828 for ; Sun, 6 Sep 2009 08:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzGs15WvrXS2 for ; Sun, 6 Sep 2009 08:54:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 773303A659A for ; Sun, 6 Sep 2009 08:54:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BF4A39E15D for ; Sun, 6 Sep 2009 17:54:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5g3OEQaJ6o6 for ; Sun, 6 Sep 2009 17:54:27 +0200 (CEST) Received: from [192.168.1.198] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B4EA339E145 for ; Sun, 6 Sep 2009 17:54:27 +0200 (CEST) Message-ID: <4AA3DAF6.7020402@alvestrand.no> Date: Sun, 06 Sep 2009 17:53:26 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: EAI WG Content-Type: multipart/mixed; boundary="------------010302080703070002040806" Subject: [EAI] Minutes from Stockholm X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 15:54:08 -0000 This is a multi-part message in MIME format. --------------010302080703070002040806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In a combination of distraction and confusion, the fact that the EAI minutes were embedded in the Jabber log escaped the chairs' attention for a while, and the minutes were thus severely delayed. The attached is the first draft of a minutes-format minutes. Please comment Harald --------------010302080703070002040806 Content-Type: text/plain; name="stockholm-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="stockholm-minutes.txt" Email Address Internationalization (EAI) WG minutes Meeting: IETF75, Monday, July 27, 1740-1940 Place: Room 300, City Conference Center, Stockholm, Sweden Chair: Harald Alvestrand , Xiaodong Lee Minutes: Chris Newman Version: 1.0 ===================================================== 1740 - Scribe, blue sheet, agenda bashing Chris Newman volunteered as scribe. 1750 - Documents in Last Call draft-ietf-eai-imap-utf8-07 draft-ietf-eai-pop-06 draft-ietf-eai-downgraded-display-01 IMAP document: Alexey: reviewed with 1 issue: lack of SASLprep What to do with invalid UTF-8 and strings that fail SASLprep This is section talking about usernames Pete: fine. will just change this. John Klensin: concerned about reliance on stringprep as we're moving away from that in other way. Chris: suggest indirect reference through SASL PLAIN. Pete: has anyone implemented this IMAP spec? room: no hands Pete: this is a concern, but OK for experimental status. POP document: Alexey issues: language range reference needs to be clarified to be "basic language range" from the lang-range RFC. Issue 2: comments about SASLprep for APOP and USER/PASS. Same as IMAP. Issue 3: inexact message sizes issue. Randy: message size will be inexact with UTF-8 mailstore when it has to downgrade. Clients that require reliable sizes may be broken by this change. Joseph Yee (in chatroom): rfc1939 (pop3) is concern on list, not on stat (if I recall correctly) regards to size Conclusion: need more text describing the issue of message sizes. Barry: may want to support multiple usernames but best to describe that in framework or usability document Downgraded display: No issues raised on downgraded-display. 1810 - Deployment experience What implementations are done, what tests have been done, what has been deployed in (test) production? What areas of trouble did arise? How should we document this experience? draft-yao-eai-deployment-03 draft-yee-eai-pop3-scenarios-00 draft-ietf-eai-email-clients-00 Discussion of deployment experience. Problems talking to non-EAI mail servers, downgrading raises same phishing problem with non-downgrading. Joseph Yee confirmed that 30-40 participants had registered in the testing platform John: Concerned whether downgrade is sufficiently interoperable and proven to overcome significant disadvantages of new email syntax. Long discussion of interoperability concerns with downgrading. Ted: what use case is a concern? John: concerned with environments where anti-spam games based on behavior. If we're introducing distortions in such tests we should at least understand them. Ted: concerned about feature-creep for how downgrade interacts with non-standard systems delaying work. joseph.yee (in chat): On the 'business card' example, users type only one address, not the compound, downgrade's big main purpose is for the sender address John: concerned that downgrade is the high risk area. Particularly the > syntax. Draft standard test will involve testing this against broken mail related stuff in the wild. Dave Crocker: we really believe we do not understand all of the problems this may cause and would like to understand them better before promoting this. Ted: charter says we can go forward with downgrade as informational Charter does require mailing list problems be considered before advancing Barry: thought double-address would be transitional initially. Harald: may not be very transitional. We need to have confidence in downgrade or willingness to set aside downgrade before moving the set to standards track. Moving on to mailto URL issue (19:03) Discussion of schemes to do mailto iri and uri. Is mailto making progress? Alexey has encouraged document author Ted: if we do a new IRI scheme, this could be non-blocking. But if we do IRI form of mailto then mailto-bis is blocking. Suggest a conf call gets set up with dedicated time of experts such as Leslie and Pete. John: also interested in this call. Alexey will collect together assorted experts to talk with Martin about mailto-bis. Mailing list draft: Draft has expired. Randy: No, nothing has been worked on. Major issue in mailing list is the mailto: issue. The rest of the mailto issue is handwaving about ideal solutions. Chris: I volunteer to take EAI issue discussion to my engineering team to provide some feedback on the problems. Conclusions on drafts: documents in last call: imap & pop have small details. downgrade-display has no small details. need more input on list that documents have been reviewed. Will pass these 3 to Alexey hopefully relatively soon. Need shepherd write-ups for these from WG chairs or their delegates. Deployment experience: No concrete actions. Progressing on standards track: We do want downgrade experience and experience with what happens in the wild with downgrade. Who's doing testing, what are results? People who volunteer are extremely welcome. Mailto: AD action to figure out where it is. Mailing lists: Randy action to refresh document. Chris action to discuss with team to determine problems. The WG concludes at 19:28. --------------010302080703070002040806-- From alexey.melnikov@isode.com Sun Sep 6 09:05:23 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1126F3A68ED for ; Sun, 6 Sep 2009 09:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8zepdI1MgI2 for ; Sun, 6 Sep 2009 09:05:22 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2EDB23A68DA for ; Sun, 6 Sep 2009 09:05:22 -0700 (PDT) Received: from [92.40.185.65] (92.40.185.65.sub.mbb.three.co.uk [92.40.185.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 6 Sep 2009 17:05:46 +0100 Message-ID: <4AA3DDC2.7090602@isode.com> Date: Sun, 06 Sep 2009 17:05:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Harald Tveit Alvestrand References: <4AA3B231.3000707@alvestrand.no> In-Reply-To: <4AA3B231.3000707@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Summary of WG Last Calls X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 16:05:23 -0000 Harald Tveit Alvestrand wrote: > IMAP: > > There are nits that should be fixed. The AD has already issued the > IETF Last Call. > A new revision should be issued at the AD's discretion, either before > or after the IESG > telechat. A new revision was posted on Friday, which addressed most of the reported nits. But one more might be needed, depending on IESG review. From alexey.melnikov@isode.com Sun Sep 6 09:25:08 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136923A695C; Sun, 6 Sep 2009 09:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfzo14SjiLT1; Sun, 6 Sep 2009 09:25:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 00B843A693E; Sun, 6 Sep 2009 09:25:06 -0700 (PDT) Received: from [92.40.185.65] (92.40.185.65.sub.mbb.three.co.uk [92.40.185.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 6 Sep 2009 17:25:31 +0100 Message-ID: <4AA3E259.5060804@isode.com> Date: Sun, 06 Sep 2009 17:24:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Black_David@emc.com References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> <9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, ima@ietf.org, presnick@qualcomm.com Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 16:25:08 -0000 Black_David@emc.com wrote: >Alexey, > > Hi David, >>>- The recommendation to support MIME header upconversion for >>> "Other widely deployed MIME charsets" strikes me as >>> too vague to be useful guidance to implementers. >>> >... > > >>I believe John Klensin has adequately responded to this point. >> >> >John has thoroughly demolished the change I suggested, but I >don't think that demolition resolves this concern, as the original >text remains vague. > >OTOH, this draft is intended to be an Experimental RFC - would >it be reasonable to say that determining which charsets should >be upconverted is part of the experiment? > I am quite skeptical that we can come to a consensus after running such experiment. The answer to the question is going to be very region/country specific. This is not the first time we are discussing the rathole (the same applies to MIME, IMAP SEARCH, IMAP CONVERT extension) and this looks like a big rathole to me. I think you mentioned earlier that maybe an implementation should support conversion to UTF-8 of all charsets it already supports in SEARCH. After thinking more about this I think this proposal is quite sensible. Alternatively, the sentence saying: Other widely deployed MIME charsets SHOULD be supported should just be removed, as I tend to agree that it doesn't provide much useful information. From harald@alvestrand.no Sun Sep 6 11:07:06 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCC53A69F4; Sun, 6 Sep 2009 11:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+b5Q26PxN+Q; Sun, 6 Sep 2009 11:07:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 5AF923A67F5; Sun, 6 Sep 2009 11:07:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CFCB39E15D; Sun, 6 Sep 2009 20:07:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILYn8peK3D1P; Sun, 6 Sep 2009 20:07:25 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 98BFB39E145; Sun, 6 Sep 2009 20:07:25 +0200 (CEST) Message-ID: <4AA3FA5A.8030000@alvestrand.no> Date: Sun, 06 Sep 2009 20:07:22 +0200 From: Harald Tveit Alvestrand User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexey Melnikov References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> <9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com> <4AA3E259.5060804@isode.com> In-Reply-To: <4AA3E259.5060804@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, ima@ietf.org, presnick@qualcomm.com, Black_David@emc.com Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 18:07:06 -0000 Alexey Melnikov skrev: > Black_David@emc.com wrote: > >> Alexey, >> >> > Hi David, > >>>> - The recommendation to support MIME header upconversion for >>>> "Other widely deployed MIME charsets" strikes me as >>>> too vague to be useful guidance to implementers. >> ... >> >> >>> I believe John Klensin has adequately responded to this point. >>> >> John has thoroughly demolished the change I suggested, but I >> don't think that demolition resolves this concern, as the original >> text remains vague. >> >> OTOH, this draft is intended to be an Experimental RFC - would >> it be reasonable to say that determining which charsets should >> be upconverted is part of the experiment? >> > I am quite skeptical that we can come to a consensus after running > such experiment. The answer to the question is going to be very > region/country specific. > This is not the first time we are discussing the rathole (the same > applies to MIME, IMAP SEARCH, IMAP CONVERT extension) and this looks > like a big rathole to me. > > I think you mentioned earlier that maybe an implementation should > support conversion to UTF-8 of all charsets it already supports in > SEARCH. After thinking more about this I think this proposal is quite > sensible. It makes quite a lot of sense to me that if an IMAP server supports a specific charset in some other context (such as IMAP SEARCH and friends), it should be consistent about supporting the same charset in UTF8 too. Inconsistency here would be unreasonable for the user - and by pointing to that, we have "reduced to a previously unsolved problem". Suggested language: If the server supports other charsets in IMAP SEARCH or IMAP CONVERT (add references to taste), it SHOULD also support those charsets in this conversion. Harald From klensin@jck.com Sun Sep 6 20:15:51 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3542E3A67B4 for ; Sun, 6 Sep 2009 20:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u43VBmt0RGVw for ; Sun, 6 Sep 2009 20:15:50 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D29D23A67E3 for ; Sun, 6 Sep 2009 20:15:49 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1MkUi9-00052u-Jh; Sun, 06 Sep 2009 23:16:09 -0400 Date: Sun, 06 Sep 2009 23:16:07 -0400 From: John C Klensin To: Charles Lindsey , IMA Message-ID: <298A98F6EFCD96AACBBCA05A@[192.168.1.110]> In-Reply-To: References: <4AA18AB2.5080508@ca.afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 03:15:51 -0000 --On Sunday, September 06, 2009 12:58 PM +0100 Charles Lindsey wrote: > On Fri, 04 Sep 2009 22:46:26 +0100, Ernie Dainow > wrote: > >> One of the key goals in simplifying Downgrade is to drop the >> double angle bracket notation, due to compatibility and >> security concerns. There have been a few email threads on >> this. I think the following summarizes the current thinking. >> >> Dropping double angle brackets on Recipient addresses is part >> of the downgrade simplification to not support downgrade of >> forward pointing addresses (considering these cases as >> configuration errors). >> >> To replace double angle brackets for the Sender, John Klensin >> proposed using multiple From fields. SM amended this with >> Reply-To to specify the preferred address, as in >> From: EAI-addr, ASCII-addr >> Reply-To: EAI-addr >> where the EAI-addr gets dropped in Downgrade. >> >> I did some (non-EAI) tests of multiple From fields with >> Reply-To on two different email systems and both worked as >> expected. This looks like an elegant solution. > > Yes, but the interesting case is multiple fields in Reply-To. > Normally, these will cause the reply to go to _both_ (but if > one is utf-8 and one is ascii, then the utf-8 might fail). > > If we retain the double angle brackets, then one could still > say, in the Reply-To, "please reply to my utf-8 address if > possible, but if your system (or some intermediate server that > knows how to downgrade) can't do that, then please reply to my > ascii address". And this is different from adding "if this address doesn't work, try that other one" to the email model -- something we have never had, nor missed very much? The cost and risks of adding new syntax to addresses is quite high, especially given the risk of leakage and of causing serious interoperability problems if things do leak. It may be worth it (I'm still trying to keep an open mind although I'm increasingly doubtful that it is), but, if so, we should have a much stronger justification than a marginal reply-to case, at least IMO. > I would expect that to be the commonest (and most useful) > situation in which those double angle brackets will appear in > practice. > > So my preference would be to retain them, at least so long as > these remain Experimental documents. If the eventual Standard > still retains them, then it could still say "this feature may > well be withdrawn in a future version of this standard" (with > the intent to do so when utf-8 has become so widely > implemented that it is no longer needed). Our experience has been that, if one does that, it will only affect new implementations created after the feature is withdrawn and maybe, for competitive reasons, not even them. For everyone else, if a feature like that is ever supported as part of a standard, it is forever. john\ From klensin@jck.com Sun Sep 6 20:18:39 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7454A3A68BE; Sun, 6 Sep 2009 20:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+KoMhSCKQOk; Sun, 6 Sep 2009 20:18:38 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7F3243A684F; Sun, 6 Sep 2009 20:18:38 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1MkUkw-00054m-S1; Sun, 06 Sep 2009 23:19:03 -0400 Date: Sun, 06 Sep 2009 23:19:01 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Alexey Melnikov Message-ID: <379713518D25EEBB9E890E6B@[192.168.1.110]> In-Reply-To: <4AA3FA5A.8030000@alvestrand.no> References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> <9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com> <4AA3E259.5060804@isode.com> <4AA3FA5A.8030000@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: presnick@qualcomm.com, gen-art@ietf.org, ima@ietf.org, Black_David@emc.com Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 03:18:39 -0000 --On Sunday, September 06, 2009 8:07 PM +0200 Harald Tveit Alvestrand wrote: > It makes quite a lot of sense to me that if an IMAP server > supports a specific charset in some other context (such as > IMAP SEARCH and friends), it should be consistent about > supporting the same charset in UTF8 too. > > Inconsistency here would be unreasonable for the user - and by > pointing to that, we have "reduced to a previously unsolved > problem". > > Suggested language: > > If the server supports other charsets in IMAP SEARCH or IMAP > CONVERT (add references to taste), it SHOULD also support > those charsets in this conversion. Wfm john From yaojk@cnnic.cn Mon Sep 7 00:58:04 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683DB3A69ED for ; Mon, 7 Sep 2009 00:58:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.852 X-Spam-Level: X-Spam-Status: No, score=0.852 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQMDJ+bDFnAe for ; Mon, 7 Sep 2009 00:58:03 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 28D1F3A6981 for ; Mon, 7 Sep 2009 00:58:02 -0700 (PDT) Received: (eyou send program); Mon, 07 Sep 2009 15:58:29 +0800 Message-ID: <452310309.04689@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 07 Sep 2009 15:58:29 +0800 Message-ID: <035301ca2f90$fbea41b0$236ff1da@whatisfuture> From: "YAO Jiankang" To: "EAI WG" Date: Mon, 7 Sep 2009 15:58:27 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0351_01CA2FD4.09CF8E50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [EAI] Fw: I-D Action:draft-yao-eai-problem-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 07:58:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0351_01CA2FD4.09CF8E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbCwNCg0KIEkgc3VibWl0IGEgbmV3IGRyYWZ0IHRpdGxlZCB3aXRoICJQcm9ibGVt cyBvZiBpbXBlZGluZyB0aGUgdXNlIG9mIGludGVybmF0aW9uYWxpemVkIGVtYWlsIGFkZHJlc3Mi Lg0KDQpZYW8gSmlhbmthbmcNCkNOTklDDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiA8SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPg0KVG86IDxpLWQtYW5ub3VuY2VAaWV0 Zi5vcmc+DQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAwNywgMjAwOSAzOjQ1IFBNDQpTdWJqZWN0 OiBJLUQgQWN0aW9uOmRyYWZ0LXlhby1lYWktcHJvYmxlbS0wMC50eHQgDQoNCg0KPkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4gDQo+IFRpdGxlICAgICAgICAgICA6IFByb2JsZW1zIG9mIGltcGVk aW5nIHRoZSB1c2Ugb2YgaW50ZXJuYXRpb25hbGl6ZWQgZW1haWwgYWRkcmVzcw0KPiBBdXRob3Io cykgICAgICAgOiBKLiBZYW8sIFguIExlZQ0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC15YW8t ZWFpLXByb2JsZW0tMDAudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDcNCj4gRGF0ZSAgICAgICAg ICAgIDogMjAwOS0wOS0wNw0KPiANCj4gTWFueSBvcmdhbml6YXRpb25zIGhhdmUgaW1wbGVtZW50 ZWQgYW5kIHRlc3RlZCB0aGUgaW50ZXJuYXRpb25hbGl6ZWQNCj4gZW1haWwgc3lzdGVtcyBiYXNl ZCBvbiB0aGUga2V5IFJGQ3Mgd2hpY2ggaGF2ZSBiZWVuIHB1Ymxpc2hlZC4gIFRoaXMNCj4gZG9j dW1lbnQgcG9pbnRzIG91dCBzb21lIHByb2JsZW1zLCB3aGljaCBibG9ja3MgdGhlIHJlY2VpdmVy IHRvDQo+IHJlY2VpdmUgdGhlIGludGVybmF0aW9uYWxpemVkIGVtYWlsIGFkZHJlc3MgYW5kIG1h eSBpbXBlZGUgdGhlDQo+IGRlcGxveW1lbnQgYW5kIHVzZSBvZiB0aGUgaW50ZXJuYXRpb25hbGl6 ZWQgZW1haWwgYWRkcmVzcy4gIEtub3dpbmcNCj4gdGhlIHByb2JsZW1zIHdpbGwgaGVscCB0aGUg c21vb3RoIGRlcGxveW1lbnQgb2YgRW1haWwgQWRkcmVzcw0KPiBJbnRlcm5hdGlvbmFsaXphdGlv biBzeXN0ZW0uDQo+IA0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteWFvLWVhaS1wcm9ibGVtLTAw LnR4dA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4g QmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWls IHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBB U0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRlcm5ldC1EcmFmdC4NCj4NCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5u b3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50 eHQNCj4= ------=_NextPart_000_0351_01CA2FD4.09CF8E50 Content-Type: text/plain; name="draft-yao-eai-problem-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-eai-problem-00.txt" Content-Type: text/plain Content-ID: <2009-09-07004159.I-D@ietf.org> ------=_NextPart_000_0351_01CA2FD4.09CF8E50-- From sm@resistor.net Mon Sep 7 01:20:13 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283273A6961 for ; Mon, 7 Sep 2009 01:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gp8eGc3ZU7o for ; Mon, 7 Sep 2009 01:20:12 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 6B47D3A67D6 for ; Mon, 7 Sep 2009 01:20:12 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n878KJZB009375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Sep 2009 01:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1252311627; x=1252398027; bh=G9aMQvyX1l7nxD5v+gOIfLtORVOhGkHgqJ3mycYhUcA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=VGjUbVOPjAZVWDzhr61o1W0tzoHTaXp5cPST4AXna+EbkbOHxwAQX+VJU3f1yi4Zg AE5ZZvVJvQWpOWumyJI33x5pNynOgYvexFEjMPAzJtM7ha0MVxZAsBz/bM24uGwA3F m4m64gNDEfD7hkkiredCrAJVyYPTf79/AE7pI7io= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=AjoB5XV9uYPwdI/vUtf51gmC5oH4FXJc3lDWD4x2Ztq6iGjTNWzMaZGi8p8sU0W7G MiTMM9U/g2Tk6SD6NHTfxA/QHaFaQ1z8mf3mr1nQnAUUhaWIDduO4eLRnN1fclewUUL Y22eWQCUDfpd2EylP+MuFC0fCwa5XUnt2BJn/S4= Message-Id: <6.2.5.6.2.20090907004753.0332ae30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 07 Sep 2009 01:18:55 -0700 To: EAI From: SM In-Reply-To: <4AA18AB2.5080508@ca.afilias.info> References: <4AA18AB2.5080508@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 08:20:13 -0000 At 14:46 04-09-2009, Ernie Dainow wrote: >One of the key goals in simplifying Downgrade is to drop the double >angle bracket notation, due to compatibility and security concerns. >There have been a few email threads on this. I think the following >summarizes the current thinking. Yes. At 04:58 06-09-2009, Charles Lindsey wrote: >If we retain the double angle brackets, then one could still say, in the >Reply-To, "please reply to my utf-8 address if possible, but if your >system (or some intermediate server that knows how to downgrade) can't do >that, then please reply to my ascii address". > >I would expect that to be the commonest (and most useful) situation in >which those double angle brackets will appear in practice. Ernie summarizes what may be considered in my opinion as easier, i.e. lower amount of changes to existing syntax. >So my preference would be to retain them, at least so long as these remain >Experimental documents. If the eventual Standard still retains them, then >it could still say "this feature may well be withdrawn in a future version >of this standard" (with the intent to do so when utf-8 has become so >widely implemented that it is no longer needed). If the decision is taken to retain them in an existing Proposed Standard, it will be more difficult to withdraw that feature even though there is a statement about it. Regards, -sm From alexey.melnikov@isode.com Mon Sep 7 03:00:03 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187A03A67D7; Mon, 7 Sep 2009 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y-bxT3uJ3+C; Mon, 7 Sep 2009 03:00:02 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C1B073A6802; Mon, 7 Sep 2009 03:00:00 -0700 (PDT) Received: from [172.16.2.139] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 7 Sep 2009 11:00:24 +0100 Message-ID: <4AA4D99F.5060802@isode.com> Date: Mon, 07 Sep 2009 10:59:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com> <4A9D93D7.8010709@isode.com> <9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com> <4AA3E259.5060804@isode.com> <4AA3FA5A.8030000@alvestrand.no> <379713518D25EEBB9E890E6B@[192.168.1.110]> In-Reply-To: <379713518D25EEBB9E890E6B@[192.168.1.110]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: presnick@qualcomm.com, gen-art@ietf.org, ima@ietf.org, Black_David@emc.com Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 10:00:03 -0000 John C Klensin wrote: > --On Sunday, September 06, 2009 8:07 PM +0200 Harald Tveit Alvestrand > wrote: > >> It makes quite a lot of sense to me that if an IMAP server >> supports a specific charset in some other context (such as >> IMAP SEARCH and friends), it should be consistent about >> supporting the same charset in UTF8 too. >> >> Inconsistency here would be unreasonable for the user - and by >> pointing to that, we have "reduced to a previously unsolved >> problem". >> >> Suggested language: >> >> If the server supports other charsets in IMAP SEARCH or IMAP >> CONVERT (add references to taste), it SHOULD also support >> those charsets in this conversion. > > Wfm Ok, I've added this as an RFC Editor note. From Black_David@emc.com Mon Sep 7 19:18:51 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3173A68FF; Mon, 7 Sep 2009 19:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fCaSyYZNbXv; Mon, 7 Sep 2009 19:18:50 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5C3EE3A6778; Mon, 7 Sep 2009 19:18:50 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n882JIll024042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 22:19:18 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Mon, 7 Sep 2009 22:19:10 -0400 Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.166.45]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n882J9pa014377; Mon, 7 Sep 2009 22:19:10 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 22:19:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Sep 2009 22:19:08 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A03B1C902@CORPUSMX80A.corp.emc.com> In-Reply-To: <4AA4D99F.5060802@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Gen-art] [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07 Thread-Index: AcovohPEwoHXyMtFR2+k1JL62Q5L6AAiAVIg References: <9FA859626025B64FBC2AF149D97C944A03A3059B@CORPUSMX80A.corp.emc.com><4A9D93D7.8010709@isode.com><9FA859626025B64FBC2AF149D97C944A03B1C08E@CORPUSMX80A.corp.emc.com><4AA3E259.5060804@isode.com> <4AA3FA5A.8030000@alvestrand.no><379713518D25EEBB9E890E6B@[192.168.1.110]> <4AA4D99F.5060802@isode.com> From: To: , X-OriginalArrivalTime: 08 Sep 2009 02:19:09.0494 (UTC) FILETIME=[BF9C6D60:01CA302A] X-EMM-EM: Active Cc: presnick@qualcomm.com, gen-art@ietf.org, ima@ietf.org, Black_David@emc.com Subject: Re: [EAI] [Gen-art] Gen-ART review of draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 02:18:51 -0000 > John C Klensin wrote: >=20 > > --On Sunday, September 06, 2009 8:07 PM +0200 Harald Tveit=20 > Alvestrand=20 > > wrote: > > > >> It makes quite a lot of sense to me that if an IMAP server > >> supports a specific charset in some other context (such as > >> IMAP SEARCH and friends), it should be consistent about > >> supporting the same charset in UTF8 too. > >> > >> Inconsistency here would be unreasonable for the user - and by > >> pointing to that, we have "reduced to a previously unsolved > >> problem". > >> > >> Suggested language: > >> > >> If the server supports other charsets in IMAP SEARCH or IMAP > >> CONVERT (add references to taste), it SHOULD also support > >> those charsets in this conversion. > > > > Wfm >=20 > Ok, I've added this as an RFC Editor note. Also works for me. Thanks for working through the details, --David From Shawn.Steele@microsoft.com Tue Sep 8 09:51:05 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EA128C243 for ; Tue, 8 Sep 2009 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptOGHp9AMkeW for ; Tue, 8 Sep 2009 09:51:04 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 5EE843A694C for ; Tue, 8 Sep 2009 09:51:04 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Sep 2009 09:51:31 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Tue, 8 Sep 2009 09:51:31 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: double angle brackets Thread-Index: AQHKMKSdYkFgts6CNkW6FKuD53Kx3g== Date: Tue, 8 Sep 2009 16:51:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 16:51:05 -0000 > To replace double angle brackets for the Sender, John Klensin proposed=20 > using multiple From fields. SM amended this with Reply-To to specify the= =20 > preferred address, as in > From: EAI-addr, ASCII-addr > Reply-To: EAI-addr > where the EAI-addr gets dropped in Downgrade. I'd imagine that "something" isn't going to be happy with 2 addresses. It seems to me that 99% of the time email can be viewed as primarily "sende= r side" or "recipient side". Eg: Mail goes from a sender system to a recip= ient system. It is very rare (now) that an in-between system would relay m= ail from an untrusted server to another 3rd party server. If there is a re= lay, it'd have to trust the sender, so it's pretty much "sender side," or r= ecognize the recipient "recipient side." Assuming that a "sender" has an EAI aware system that is completely conform= ant and "works" with UTF-8 addresses, then the entire "sender side" would h= ave to be updated to support UTF-8 addresses. If the sender's relays aren'= t upgraded, then all of their mail ends up being downgraded anyway. Similarly a recipient either has an entirely EAI aware system, or they don'= t. =20 So I'm wondering how interesting downgrade really is. If my sending system= trusts the sender, presumably it could request an ASCII address from the t= rusted sender-side server if it needed to downgrade. (Through some other m= echanism, like asking the trusted server what other aliases were valid for = that account using some new, or even proprietary, protocol). So the proposed solution seems like overkill. VERY worst case a client (like Outlook) can try to send an EAI email. If i= t bounces, the client could resend using my ASCII address (assuming it is p= roperly configured). It could even do that silently, or with maybe a littl= e warning saying that had been downgraded. -Shawn From klensin@jck.com Tue Sep 8 11:49:33 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F70E3A68BC for ; Tue, 8 Sep 2009 11:49:33 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvLnlVSVA1j3 for ; Tue, 8 Sep 2009 11:49:30 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id F33C828C2BB for ; Tue, 8 Sep 2009 11:49:26 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Ml5lM-0002jF-DK; Tue, 08 Sep 2009 14:49:56 -0400 Date: Tue, 08 Sep 2009 14:49:55 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <04EA2C8DA30B414374C673EB@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] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:49:33 -0000 --On Tuesday, September 08, 2009 16:51 +0000 Shawn Steele wrote: >> To replace double angle brackets for the Sender, John Klensin >> proposed using multiple From fields. SM amended this with >> Reply-To to specify the preferred address, as in >> From: EAI-addr, ASCII-addr >> Reply-To: EAI-addr >> where the EAI-addr gets dropped in Downgrade. > > I'd imagine that "something" isn't going to be happy with 2 > addresses. Right. In particular, there are a lot of systems that do not support multiple-address From:, multiple-address Reply-to:, or both. > It seems to me that 99% of the time email can be viewed as > primarily "sender side" or "recipient side". Eg: Mail goes > from a sender system to a recipient system. It is very rare > (now) that an in-between system would relay mail from an > untrusted server to another 3rd party server. If there is a > relay, it'd have to trust the sender, so it's pretty much > "sender side," or recognize the recipient "recipient side." > > Assuming that a "sender" has an EAI aware system that is > completely conformant and "works" with UTF-8 addresses, then > the entire "sender side" would have to be updated to support > UTF-8 addresses. If the sender's relays aren't upgraded, then > all of their mail ends up being downgraded anyway. > > Similarly a recipient either has an entirely EAI aware system, > or they don't. > > So I'm wondering how interesting downgrade really is. If my > sending system trusts the sender, presumably it could request > an ASCII address from the trusted sender-side server if it > needed to downgrade. (Through some other mechanism, like > asking the trusted server what other aliases were valid for > that account using some new, or even proprietary, protocol). This is the "do we really need downgrade" argument that some of us have been raising on and off for years. The answer has never been "yes" or "no" but "are there enough edge cases (that do not conform to the analysis) out there to make downgrading useful anyway, at some cost level". If anything has changed recently it has been either * a perception that there are fewer relevant cases where downgrade is actually needed than was originally believed. * a perception that the costs and risks of having a downgrading arrangement (e.g., with double angle brackets) make the number of relevant cases needed to justify the mechanism much larger than we had originally believed. Of course, both may be true, but would make the case for "no downgrade" even more open and shut. > So the proposed solution seems like overkill. > > VERY worst case a client (like Outlook) can try to send an EAI > email. If it bounces, the client could resend using my ASCII > address (assuming it is properly configured). It could even > do that silently, or with maybe a little warning saying that > had been downgraded. That, of course, means that it knows your ASCII address. Absent some configuration changes, it might not. But I think we are in violent agreement, or at least getting close to it. john From Shawn.Steele@microsoft.com Tue Sep 8 12:26:19 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB88D3A69DF for ; Tue, 8 Sep 2009 12:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.341 X-Spam-Level: X-Spam-Status: No, score=-10.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWeYF84DyrJc for ; Tue, 8 Sep 2009 12:26:18 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9DAD13A6AEB for ; Tue, 8 Sep 2009 12:26:18 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Sep 2009 12:26:49 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Tue, 8 Sep 2009 12:26:49 -0700 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] double angle brackets Thread-Index: AQHKMLl9EyHXmbFjJ061QWEn2dwxTJDNEiTg Date: Tue, 8 Sep 2009 19:26:45 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> In-Reply-To: <04EA2C8DA30B414374C673EB@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:26:19 -0000 > * a perception that there are fewer relevant cases where > downgrade is actually needed than was originally > believed. For me, this is true =09 > * a perception that the costs and risks of having a > downgrading arrangement (e.g., with double angle > brackets) make the number of relevant cases needed to > justify the mechanism much larger than we had originally > believed. And so I think the risk is more interesting now that I think the downgrade = is less helpful :) > That, of course, means that it knows your ASCII address. Absent > some configuration changes, it might not. If I don't know my ASCII address, I'm not sure how I can send From: EAI, La= tn or other syntax :) So I don't think that's an interesting point. - Shawn From edainow@ca.afilias.info Tue Sep 8 14:25:38 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E463A6994 for ; Tue, 8 Sep 2009 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2YflB4r8lQT for ; Tue, 8 Sep 2009 14:25:37 -0700 (PDT) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id A1E0B3A69D4 for ; Tue, 8 Sep 2009 14:25:37 -0700 (PDT) Received: from edainow.tor.afilias-int.info ([10.10.68.27]) by tor-gateway.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Ml8CK-0005b4-5m; Tue, 08 Sep 2009 17:25:56 -0400 Message-ID: <4AA6CCBB.1070804@ca.afilias.info> Date: Tue, 08 Sep 2009 17:29:31 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: John C Klensin References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> In-Reply-To: <04EA2C8DA30B414374C673EB@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:25:38 -0000 John C Klensin wrote: > --On Tuesday, September 08, 2009 16:51 +0000 Shawn Steele > wrote: > > >>> To replace double angle brackets for the Sender, John Klensin >>> proposed using multiple From fields. SM amended this with >>> Reply-To to specify the preferred address, as in >>> From: EAI-addr, ASCII-addr >>> Reply-To: EAI-addr >>> where the EAI-addr gets dropped in Downgrade. >>> >> I'd imagine that "something" isn't going to be happy with 2 >> addresses. >> > > Right. In particular, there are a lot of systems that do not > support multiple-address From:, multiple-address Reply-to:, or > both. > > I don't think it's important if a lot of existing systems do not support multiple from addresses. As non-EAI systems they would only receive downgraded messages, which have only a single From address and no Reply-To. EAI systems, which will receive multiple From addresses, would have to support it since it would be part of the EAI spec. -Ernie Dainow From Shawn.Steele@microsoft.com Tue Sep 8 15:03:46 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E683A3A6920 for ; Tue, 8 Sep 2009 15:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHm-GxoH57xM for ; Tue, 8 Sep 2009 15:03:46 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1BDB13A681C for ; Tue, 8 Sep 2009 15:03:46 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Sep 2009 15:04:16 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Tue, 8 Sep 2009 15:04:16 -0700 From: Shawn Steele To: Ernie Dainow , John C Klensin Thread-Topic: [EAI] double angle brackets Thread-Index: AQHKMLl9EyHXmbFjJ061QWEn2dwxTJDNqs2A//+UO+A= Date: Tue, 8 Sep 2009 22:04:02 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> In-Reply-To: <4AA6CCBB.1070804@ca.afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 22:03:47 -0000 SG93IGRvIHlvdSB0ZWxsIG11bHRpcGxlIGZyb20gbWVhbmluZyBFQUkgYXBhcnQgZnJvbSBub24t RUFJIG11bHRpcGxlIGZyb20/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBF cm5pZSBEYWlub3cgW21haWx0bzplZGFpbm93QGNhLmFmaWxpYXMuaW5mb10gDQpTZW50OiBUdWVz ZGF5LCBTZXB0ZW1iZXIgMDgsIO+jk++jl++joiAyMDA5IDE0OjMwDQpUbzogSm9obiBDIEtsZW5z aW4NCkNjOiBTaGF3biBTdGVlbGU7IGltYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFQUldIGRv dWJsZSBhbmdsZSBicmFja2V0cw0KDQoNCg0KSm9obiBDIEtsZW5zaW4gd3JvdGU6DQo+IC0tT24g VHVlc2RheSwgU2VwdGVtYmVyIDA4LCAyMDA5IDE2OjUxICswMDAwIFNoYXduIFN0ZWVsZQ0KPiA8 U2hhd24uU3RlZWxlQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPg0KPiAgIA0KPj4+IFRvIHJlcGxh Y2UgZG91YmxlIGFuZ2xlIGJyYWNrZXRzIGZvciB0aGUgU2VuZGVyLCBKb2huIEtsZW5zaW4NCj4+ PiBwcm9wb3NlZCAgdXNpbmcgbXVsdGlwbGUgRnJvbSBmaWVsZHMuIFNNIGFtZW5kZWQgdGhpcyB3 aXRoDQo+Pj4gUmVwbHktVG8gdG8gc3BlY2lmeSB0aGUgIHByZWZlcnJlZCBhZGRyZXNzLCBhcyBp bg0KPj4+ICAgICAgICAgRnJvbTogRUFJLWFkZHIsIEFTQ0lJLWFkZHINCj4+PiAgICAgICAgIFJl cGx5LVRvOiBFQUktYWRkcg0KPj4+IHdoZXJlIHRoZSBFQUktYWRkciBnZXRzIGRyb3BwZWQgaW4g RG93bmdyYWRlLg0KPj4+ICAgICAgIA0KPj4gSSdkIGltYWdpbmUgdGhhdCAic29tZXRoaW5nIiBp c24ndCBnb2luZyB0byBiZSBoYXBweSB3aXRoIDINCj4+IGFkZHJlc3Nlcy4NCj4+ICAgICANCj4N Cj4gUmlnaHQuICBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBhcmUgYSBsb3Qgb2Ygc3lzdGVtcyB0aGF0 IGRvIG5vdA0KPiBzdXBwb3J0IG11bHRpcGxlLWFkZHJlc3MgRnJvbTosIG11bHRpcGxlLWFkZHJl c3MgUmVwbHktdG86LCBvcg0KPiBib3RoLg0KPg0KPiAgIA0KSSBkb24ndCB0aGluayBpdCdzIGlt cG9ydGFudCBpZiBhIGxvdCBvZiBleGlzdGluZyBzeXN0ZW1zIGRvIG5vdCBzdXBwb3J0IA0KbXVs dGlwbGUgZnJvbSBhZGRyZXNzZXMuICBBcyBub24tRUFJIHN5c3RlbXMgdGhleSB3b3VsZCBvbmx5 IHJlY2VpdmUgDQpkb3duZ3JhZGVkIG1lc3NhZ2VzLCB3aGljaCBoYXZlIG9ubHkgYSBzaW5nbGUg RnJvbSBhZGRyZXNzIGFuZCBubyBSZXBseS1Uby4NCg0KRUFJIHN5c3RlbXMsIHdoaWNoIHdpbGwg cmVjZWl2ZSBtdWx0aXBsZSBGcm9tIGFkZHJlc3Nlcywgd291bGQgaGF2ZSB0byANCnN1cHBvcnQg aXQgc2luY2UgaXQgd291bGQgYmUgcGFydCBvZiB0aGUgRUFJIHNwZWMuDQoNCiAgICAtRXJuaWUg RGFpbm93DQoNCg0KDQoNCg== From klensin@jck.com Tue Sep 8 16:30:33 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8864E3A6ACB for ; Tue, 8 Sep 2009 16:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nroZsIsCNRAw for ; Tue, 8 Sep 2009 16:30:31 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AF3D53A68A4 for ; Tue, 8 Sep 2009 16:30:31 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MlA9M-00099X-8D; Tue, 08 Sep 2009 19:31:00 -0400 Date: Tue, 08 Sep 2009 19:30:59 -0400 From: John C Klensin To: Shawn Steele , Ernie Dainow Message-ID: In-Reply-To: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 23:30:33 -0000 --On Tuesday, September 08, 2009 22:04 +0000 Shawn Steele wrote: > How do you tell multiple from meaning EAI apart from non-EAI > multiple from? I don't think you need to. If I correctly understand the point that Ernie was trying to make, there are the following cases: * non-EAI, support for multiple "From:": will accept both and probably discard the i18n email address. * non-EAI, no support for multiple "From:": Will reject either both addresses or the second one. If one is accepted, probably the first one (which should probably be the ASCII address) will probably be used. If both are rejected, then nothing much is lost compared to the failed downgrade case -- especially if you remember that an EAI envelope is unlikely to reach a non-EAI system. * EAI compliant system: will support multiple "From:" because the spec will require it. Then the EAI-compliant system will either respond to both addresses on "reply" or to just the EAI one, but that is consistent with how much we've historically underspecified what to do with multiple "From:" situations. The analysis for Reply-to won't be significantly different, IMO. john From Shawn.Steele@microsoft.com Tue Sep 8 16:48:54 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8C03A6B2E for ; Tue, 8 Sep 2009 16:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BJt6Atmrv0V for ; Tue, 8 Sep 2009 16:48:54 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1442A3A6B0A for ; Tue, 8 Sep 2009 16:48:54 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Sep 2009 16:49:25 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Tue, 8 Sep 2009 16:49:24 -0700 From: Shawn Steele To: John C Klensin , Ernie Dainow Thread-Topic: [EAI] double angle brackets Thread-Index: AQHKMLl9EyHXmbFjJ061QWEn2dwxTJDNqs2A//+UO+CAAI21gP//jfhA Date: Tue, 8 Sep 2009 23:49:23 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 23:48:55 -0000 > * non-EAI, support for multiple "From:": will accept > both and probably discard the i18n email address. That's an interesting assumption. Presumably I could also reject the entir= e message since I have no clue how to parse the address. =09 > * non-EAI, no support for multiple "From:": Will reject > either both addresses or the second one. If one is > accepted, probably the first one (which should probably > be the ASCII address) will probably be used. If both > are rejected, then nothing much is lost compared to the > failed downgrade case -- especially if you remember that > an EAI envelope is unlikely to reach a non-EAI system. Ditto. =09 > * EAI compliant system: will support multiple "From:" > because the spec will require it. =20 I still can't tell that they're a pair. It could be intentionally from 2 d= ifferent people, one of which has an EAI address, but the other has an ASCI= I address, and we don't know (or didn't bother to mention) what the EAI add= ress user's downgrade address is. So an EAI compliant system that "assumed" that "From: Unicode, ASCII" was E= AI would not bother replying to the ASCII address, &/or it would=20 Besides, if this was reasonable for From, what about To: or CC: or Reply-To= :? Presumably I could mail it to other EAI users as well, so how does a re= cipient respond? How would one reliably match up the pairs? Also, presumably I know my own downgrade address, but am I going to know al= l of the downgrade addresses for everyone on To: (or hopefully Bcc:) that I= 'm forwarding a joke to? I remain unconvinced that this solves enough downgrade problems completely = enough to be interesting. -Shawn From root@core3.amsl.com Tue Sep 8 17:30:01 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 741E828C124; Tue, 8 Sep 2009 17:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090909003001.741E828C124@core3.amsl.com> Date: Tue, 8 Sep 2009 17:30:01 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-downgraded-display-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 00:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Displaying Downgraded Messages for Email Address Internationalization Author(s) : K. Fujiwara Filename : draft-ietf-eai-downgraded-display-02.txt Pages : 14 Date : 2009-09-08 This document describes a method for displaying downgraded messages which originally contained internationalized E-mail addresses or internationalized header fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgraded-display-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-downgraded-display-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-08172124.I-D@ietf.org> --NextPart-- From edainow@ca.afilias.info Wed Sep 9 05:57:21 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D99928C135 for ; Wed, 9 Sep 2009 05:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvbywoSkJSis for ; Wed, 9 Sep 2009 05:57:20 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 7748D28C0CE for ; Wed, 9 Sep 2009 05:57:20 -0700 (PDT) Message-ID: <4AA7A649.5000903@ca.afilias.info> Date: Wed, 09 Sep 2009 08:57:45 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shawn Steele References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: "ima@ietf.org" Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 12:57:21 -0000 Shawn Steele wrote: >> * non-EAI, support for multiple "From:": will accept >> both and probably discard the i18n email address. >> > > That's an interesting assumption. Presumably I could also reject the entire message since I have no clue how to parse the address. > > >> * non-EAI, no support for multiple "From:": Will reject >> either both addresses or the second one. If one is >> accepted, probably the first one (which should probably >> be the ASCII address) will probably be used. If both >> are rejected, then nothing much is lost compared to the >> failed downgrade case -- especially if you remember that >> an EAI envelope is unlikely to reach a non-EAI system. >> > > Ditto. > For non-EAI, downgrade would remove the i18n email address, so From does not have multiple addresses. > > >> * EAI compliant system: will support multiple "From:" >> because the spec will require it. >> > > I still can't tell that they're a pair. It could be intentionally from 2 different people, one of which has an EAI address, but the other has an ASCII address, and we don't know (or didn't bother to mention) what the EAI address user's downgrade address is. > > So an EAI compliant system that "assumed" that "From: Unicode, ASCII" was EAI would not bother replying to the ASCII address, &/or it would > > This case would have a Reply-To with the EAI address, so the multiple From fields are not used. The reply is composed to the address(es) contained in the Reply-To and none of the From headers (see RFC 5322). I have tested this with a web mail client and a widely used windows/linux email client. From: had two addresses and Reply-To: had a third. When replying to such an email, both clients composed mail with To: that contained the Reply-To: address only. Based on this, I expect that most email clients that are upgraded to support EAI will actually support the proposal (repeated below) without requiring any further work. From: EAI-addr, ASCII-addr Reply-To: EAI-addr (where the EAI-addr gets dropped in Downgrade) > Besides, if this was reasonable for From, what about To: or CC: or Reply-To:? Presumably I could mail it to other EAI users as well, so how does a recipient respond? How would one reliably match up the pairs? > > Also, presumably I know my own downgrade address, but am I going to know all of the downgrade addresses for everyone on To: (or hopefully Bcc:) that I'm forwarding a joke to? > As part of the downgrade simplification, we are proposing to drop support for downgrade of forward pointing addresses such as To:, Cc:.If someone gives you an EAI address, the assumption is that their email system can receive EAI email.If their system cannot receive EAI email, it is a 'configuration' error on their end and they shouldn't be giving out an EAI address until they are ready to receive such mail. > I remain unconvinced that this solves enough downgrade problems completely enough to be interesting. > > -Shawn > > From wwwrun@core3.amsl.com Wed Sep 9 06:27:26 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0150C3A6A34; Wed, 9 Sep 2009 06:27:25 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090909132726.0150C3A6A34@core3.amsl.com> Date: Wed, 9 Sep 2009 06:27:25 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] Last Call: draft-ietf-eai-downgraded-display (Displaying Downgraded Messages for Email Address Internationalization) to Experimental RFC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 13:27:26 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Displaying Downgraded Messages for Email Address Internationalization ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eai-downgraded-display-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17781&rfc_flag=0 From Shawn.Steele@microsoft.com Wed Sep 9 09:20:16 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925AD3A6999 for ; Wed, 9 Sep 2009 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaymlWiuK8du for ; Wed, 9 Sep 2009 09:20:15 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C3EFF3A6A1D for ; Wed, 9 Sep 2009 09:20:15 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Sep 2009 09:20:48 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Wed, 9 Sep 2009 09:20:45 -0700 From: Shawn Steele To: Ernie Dainow Thread-Topic: [EAI] double angle brackets Thread-Index: AQHKMLl9EyHXmbFjJ061QWEn2dwxTJDNqs2A//+UO+CAAI21gP//jfhAgAFTcID//8DNtw== Date: Wed, 9 Sep 2009 16:20:45 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> In-Reply-To: <4AA7A649.5000903@ca.afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:20:16 -0000 > (From: EAI for user 1, ASCII for user 2) > > This case would have a Reply-To with the EAI address, so the multiple=20 > From fields are not used. I don't think you understood me correctly. I'm saying if I wanted the mail= to be "From: billg@microsoft.com, steveb@microsoft.com" when Bill had an E= AI address and Steve did not, then it'd be confused with an EAI downgrade f= ormat. I also don't see how Reply-To: helps. If Reply-To: always has the EAI fall= back path, then it can't be used normally. > As part of the downgrade simplification, we are proposing to drop > support for downgrade of forward pointing addresses such as To:, Cc:.If > someone gives you an EAI address, the assumption is that their email > system can receive EAI email.If their system cannot receive EAI email, > it is a 'configuration' error on their end and they shouldn't be giving > out an EAI address until they are ready to receive such mail. If I send email from an EAI aware account to 10 other EAI aware users, then= that's great. (Like on a list like this). If someone replies-all, everyt= hing works fine. Now if I add one non-EAI aware user, unless To: & Cc: are fixed, then that = person can't reply-all. In fact I guess all the other addresses have to be= dropped for downgrade (or the mail fails) If they replied-all, they'd get= me presumably because of From, but all the other users would fail. I use = Reply-All more than reply. That's how I replied to this mail in fact. I'm not sure how much good it does to "fix" from if the others can't be fix= ed as well. -Shawn= From edainow@ca.afilias.info Wed Sep 9 11:22:45 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E3F3A6847 for ; Wed, 9 Sep 2009 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv2UrTOMVTQa for ; Wed, 9 Sep 2009 11:22:44 -0700 (PDT) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id 3F65C3A694E for ; Wed, 9 Sep 2009 11:22:41 -0700 (PDT) Received: from edainow.tor.afilias-int.info ([10.10.68.27]) by tor-gateway.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MlRos-0007Vl-6R; Wed, 09 Sep 2009 14:23:03 -0400 Message-ID: <4AA7F35E.7080906@ca.afilias.info> Date: Wed, 09 Sep 2009 14:26:38 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Shawn Steele References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org" Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:22:45 -0000 Shawn Steele wrote: >> (From: EAI for user 1, ASCII for user 2) >> >> This case would have a Reply-To with the EAI address, so the multiple >> From fields are not used. >> > > I don't think you understood me correctly. I'm saying if I wanted the mail to be "From: billg@microsoft.com, steveb@microsoft.com" when Bill had an EAI address and Steve did not, then it'd be confused with an EAI downgrade format. > Can you actually compose mail like this with your email system? The assumption was that multiple From addresses are not widely used and are not generally a feature that users can utilize.The proposal was not to make the use of multiple From fields available for general use. The From headers would be generated automatically specifically to carry the downgrade information. > I also don't see how Reply-To: helps. If Reply-To: always has the EAI fallback path, then it can't be used normally. > If you don't want the Reply-To to be your EAI address, I don't see any reason you couldn't change it, or add additional addresses. This header would need to be made available to the user composing the email, with its default being the EAI address. > >> As part of the downgrade simplification, we are proposing to drop >> support for downgrade of forward pointing addresses such as To:, Cc:.If >> someone gives you an EAI address, the assumption is that their email >> system can receive EAI email.If their system cannot receive EAI email, >> it is a 'configuration' error on their end and they shouldn't be giving >> out an EAI address until they are ready to receive such mail. >> > > If I send email from an EAI aware account to 10 other EAI aware users, then that's great. (Like on a list like this). If someone replies-all, everything works fine. > > Now if I add one non-EAI aware user, unless To: & Cc: are fixed, then that person can't reply-all. In fact I guess all the other addresses have to be dropped for downgrade (or the mail fails) If they replied-all, they'd get me presumably because of From, but all the other users would fail. I use Reply-All more than reply. That's how I replied to this mail in fact. > > I'm not sure how much good it does to "fix" from if the others can't be fixed as well. > This is the "triangle" case raised by Harald. As noted, there may have to be trade offs in achieving simplification over complexity. This may be one of those cases that we have to consider giving up. > -Shawn From edainow@ca.afilias.info Wed Sep 9 11:39:50 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35C628C0F9 for ; Wed, 9 Sep 2009 11:39:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1kyaKTxk4yR for ; Wed, 9 Sep 2009 11:39:50 -0700 (PDT) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id EE8F53A6A9A for ; Wed, 9 Sep 2009 11:39:49 -0700 (PDT) Received: from edainow.tor.afilias-int.info ([10.10.68.27]) by tor-gateway.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MlS5e-0000Y7-8a for ima@ietf.org; Wed, 09 Sep 2009 14:40:22 -0400 Message-ID: <4AA7F76E.3040307@ca.afilias.info> Date: Wed, 09 Sep 2009 14:43:58 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: EAI Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:39:51 -0000 There is a question of whether the EAI spec should include simplified downgrade at all. To help answer this, compare what a user has to do in various situations when there is downgrade and when there is not. From the user's point of view, there are not that many cases to consider. 1. Sending email to an EAI user ("sending" includes compose new mail, forward, reply). This case will not have downgrade. If any recipients cannot in fact receive EAI mail, it will bounce. This is being considered a 'configuration' error. Note this is different from the current Downgrade spec which supports downgrade to forward pointing addresses. 2. Sending email to an non-EAI user. a. If EAI has downgrade, the user may use his EAI email account. As long as an alternate address has been configured, the mail will be downgraded using the supplied ASCII address as the From address. b. If there is no downgrade, the user will have to use his non-EAI email account. This is slightly awkward, but not be a major hindrance. Many people are used to managing more than one email accounts, for example one for work and a second for personal email. 3. Sending email to a mix of EAI and non-EAI users. a. If EAI has downgrade, the user may use his EAI email account and send a single message, freely mixing EAI and non-EAI addresses on To, Cc, etc. b. If there is no downgrade, the user will have to send the same email twice; once using the EAI account for the EAI recipients and a second time using the non-EAI account for the non-EAI recipients. Note that in 3b, EAI users and non-EAI recipients do not know the whole list of recipients, and Reply All will not reach the full list (unless the original sender is very disciplined and copies replies from EAI to non-EAI recipients and vice versa). By comparison, in 3a, EAI recipients will see all the people that received the email and Reply All will reach everyone. However, non-EAI recipients will not see any of the EAI recipients, and their Reply All will only reach the non-EAI recipients and the sender. This is a consequence of dropping double angle brackets on forward pointing addresses, and was pointed out by Harald as the "triangle" case. As noted in that discussion, even with double angle brackets the triangle case will not consistently work in practice, as it depends on users being sufficiently disciplined to undertake the extra effort of entering alterrnate addresses for all EAI email addresses. Clearly, the pain is case 3b. To the extent that we wish to improve on this scenario, we should include downgrade. A second consideration is the effect on encouraging and speeding the migration to EAI from legacy email systems. Without downgrade, people have to actively maintain two email accounts. Under this circumstance, they may just choose the non-EAI account as the primary. With downgrade, there is an incentive to use the EAI account as the primary account, since it handles mail for all cases 1, 2 and 3. One of the assumptions in a simplified downgrade is that it is not perfect (does not handle every possible case) and may lose some audit trail information. We need to decide if an imperfect downgrade is still better than no downgrade at all. -Ernie From Shawn.Steele@microsoft.com Wed Sep 9 13:27:08 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBF83A698A for ; Wed, 9 Sep 2009 13:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.378 X-Spam-Level: X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0MTuq5eoJAO for ; Wed, 9 Sep 2009 13:27:06 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 75CF13A67A2 for ; Wed, 9 Sep 2009 13:27:06 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Sep 2009 13:27:39 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Wed, 9 Sep 2009 13:27:37 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: The value of simplified downgrade Thread-Index: AQHKMYv4ZOcdUl+ZtkWkTJNMmLRGWQ== Date: Wed, 9 Sep 2009 20:27:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:27:08 -0000 PiBCeSBjb21wYXJpc29uLCBpbiAzYSwgRUFJIHJlY2lwaWVudHMgd2lsbCBzZWUgYWxsIHRoZSBw ZW9wbGUgdGhhdCANCj4gcmVjZWl2ZWQgdGhlIGVtYWlsIGFuZCBSZXBseSBBbGwgd2lsbCByZWFj aCBldmVyeW9uZS4gSG93ZXZlciwgbm9uLUVBSSANCj4gcmVjaXBpZW50cyB3aWxsIG5vdCBzZWUg YW55IG9mIHRoZSBFQUkgcmVjaXBpZW50cywgYW5kIHRoZWlyIFJlcGx5IEFsbCANCj4gd2lsbCBv bmx5IHJlYWNoIHRoZSBub24tRUFJIHJlY2lwaWVudHMgYW5kIHRoZSBzZW5kZXIuDQoNClRoaXMg c3VtbWFyaXplcyBteSBjb25jZXJucyB3aXRoICJwYXJ0aWFsIiBkb3duZ3JhZGUgc29sdXRpb25z LiAgVGhpbmdzIHRoYXQgYXBwZWFyIHRvIHdvcmsgc3RvcCB3b3JraW5nIGluIGVkZ2UgY2FzZXMs IGFuZCBpdCBtYXkgYmUgZGlmZmljdWx0IGZvciB0aGUgc2VuZGVyIHRvIHByZWRpY3Qgb3IgdW5k ZXJzdGFuZCB0aGUgYmVoYXZpb3IuICBJZiBpdCBmYWlscyBjb21wbGV0ZWx5IEkga25vdyBJIG5l ZWQgdG8gZ2V0IGZpeGVkIGFkZHJlc3NlcyBvciBnZXQgYW4gdXBkYXRlZCBtYWlsIGNsaWVudCBv ciB3aGluZSBhdCBteSBuZXR3b3JrIGFkbWluIG9yIHNvbWV0aGluZy4gIElmIGl0IGZhaWxzICJy YW5kb21seSIgKG1hbnkgdXNlcnMgd29uJ3QgcmVjb2duaXplIHRoZSBwYXR0ZXJuKSB0aGVuIHRo ZXkgaGF2ZSBubyByZWNvdXJzZSAoYnV0IHRvIHdoaW5lIGF0IHRoZSBuZXR3b3JrIGFkbWluLCB3 aGljaCB3b24ndCBoZWxwIGJ1dCB3aWxsIGNvc3QgdGhlIHN1cHBvcnQgcGVvcGxlIGEgbG90IG9m IG1vbmV5LikNCg0KSW4gc2hvcnQ6IElmIGl0IGFsd2F5cyB3b3JrcyBmb3IgbWUsIGdyZWF0LiAg SWYgaXQncyBhbHdheXMgYnJva2VuLCB0aGVuIEknbGwgZG8gc29tZXRoaW5nIHRvIGZpeCBpdCwg YnV0IGlmIGl0IHdvcmtzIHNvbWV0aW1lcyBidXQgbm90IG90aGVycyBJIGp1c3QgZ2V0IGNvbmZ1 c2VkIGFuZCBpdCBnZXRzIGV4cGVuc2l2ZSB0byBzdXBwb3J0Lg0KDQotIFNoYXduDQoNCu+jou+j kO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0K From Shawn.Steele@microsoft.com Wed Sep 9 15:30:36 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640533A67F2 for ; Wed, 9 Sep 2009 15:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.385 X-Spam-Level: X-Spam-Status: No, score=-10.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78hHHuMAGQlC for ; Wed, 9 Sep 2009 15:30:34 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 727543A67A7 for ; Wed, 9 Sep 2009 15:30:34 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Sep 2009 15:31:08 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Wed, 9 Sep 2009 15:31:07 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Thinking about requirements / downgrade Thread-Index: AQHKMZ04dhTeOuulWEmXtG0ZEbbCtw== Date: Wed, 9 Sep 2009 22:31:05 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> In-Reply-To: <4AA7F35E.7080906@ca.afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?TWFyayBEYXZpcyDijJs=?= Subject: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 22:30:36 -0000 SSdtIGdvaW5nIHRvIHRha2UgYSBjb3VwbGUgc3RlcHMgYmFjay4gIE1vc3RseSBJJ20gZm9jdXNp bmcgb24gdGhlIGxvY2FsIHBhcnQgb2YgdGhlIGFkZHJlc3MsIGFuZCBJIHRoaW5rIHRoZXJlJ3Mg YSBzb2x1dGlvbiB0byBnZXQgdXMgdW5zdHVjay4NCiANCkEgbG90IG9mIGJhY2tncm91bmQuICBB dCBhIGhpZ2ggbGV2ZWwgdGhlcmUgYXJlIHJlYWxseSBvbmx5IGEgZmV3IHJlcXVpcmVtZW50czoN Cg0KKiBXZSBuZWVkIFVuaWNvZGUgYWRkcmVzc2VzIChUaGF0J3MgdGhlIHBvaW50IG9mIEVBSSBh ZnRlciBhbGwgOikNCiogTWFueSBwZW9wbGUgc3RpbGwgbmVlZCBhIHVzZXIgZnJpZW5kbHkgQVND SUkgYWRkcmVzcywgZm9yIHRoZSBFbmdsaXNoIHNpZGUgb2YgYSBKYXBhbmVzZSBidXNpbmVzcyBj YXJkIGlmIG5vdGhpbmcgZWxzZS4NCiogU29tZSBzb3J0IG9mICJkb3duZ3JhZGUiIG11c3QgZXhp c3QgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiAgSSdtIGJlaW5nIGxpYmVyYWwgd2l0aCB0 aGUgdGVybS4gICJEb3duZ3JhZGUiIGNvdWxkIGJlIGEgdXNlciB0cnlpbmcgVW5pY29kZSBhbmQg dGhlbiByZXRyeWluZyB3aXRoIEFTQ0lJIGlmIG5lY2Vzc2FyeSwgb3IganVzdCBnaXZpbmcgb3V0 IEFTQ0lJIGJlY2F1c2UgdGhleSBrbm93IEVBSSB3b24ndCB3b3JrIGluIHNvbWUgc2NlbmFyaW8u DQoNCjEpIFdlIG5lZWQgVW5pY29kZSBhZGRyZXNzZXMuDQpUaGUgVW5pY29kZSBhZGRyZXNzIGlz IHNvbHZlZCByZWFzb25hYmx5IHdlbGwgYnkgVVRGLTggYW5kIHRoZSBleGlzdGluZyBSRkNzLiAg VVRGLTggYWxzbyBzb2x2ZXMgYSBteXJpYWQgb2YgcHJvYmxlbXMgcmVnYXJkaW5nIGNvZGUgcGFn ZXMgaW4gdGhlIHJlc3Qgb2YgdGhlIG1lc3NhZ2UsIGJ1dCB0aGF0J3Mgbm90IHNwZWNpZmljYWxs eSBhbiBFQUkgaXNzdWUuDQogDQoyKSBGcmllbmRseSBBU0NJSSBhZGRyZXNzZXMuDQpGcmllbmRs eSBBU0NJSSBhZGRyZXNzZXMgYXJlIHByZXR0eSBtdWNoIGEgbm9uLWlzc3VlIHNpbmNlIG1haWxi b3ggYWxpYXNlcyBhcmUgYSBjb21tb24gbWFpbCBmZWF0dXJlLiAgKEkgZ2V0IG1haWwgdG8gc2hh d25zdGUgJiBTaGF3bi5TdGVlbGUpICBJIG1ha2UgdGhlIHNtYWxsIGFzc3VtcHRpb24gdGhhdCBh bGlhc2luZyB3b3VsZCBiZSBleHRlbmRlZCB0byBVbmljb2RlIGFuZCB0aGF0IGFsaWFzZXMgd2ls bCBiZSBtb3JlIGNvbW1vbiBpbiBhbiBFQUkgd29ybGQuICBUaGlzIHByb2JhYmx5IHByaW1hcmls eSBpbXBhY3RzIG1haWxib3ggYWRtaW5pc3RyYXRpb24gdG9vbHMuDQoNCjMpIERvd25ncmFkZQ0K U28gdGhhdCBsZWF2ZXMgZG93bmdyYWRlLiAgRG93bmdyYWRlIGlzIG5lY2Vzc2FyeSBmb3IgYSAi dHJhbnNpdGlvbiIgcGVyaW9kLCB3aGljaCBpcyBwcm9iYWJseSBtYW55IHllYXJzLiAgTm90ZSB0 aGF0IHRoZXJlJ3Mgbm8gdGVjaG5pY2FsIHJlcXVpcmVtZW50IHRoYXQgZG93bmdyYWRlIHVzZSB0 aGUgZnJpZW5kbHkgQVNDSUkgYWRkcmVzcyBtZWNoYW5pc20uICBJdCBpcyBhbHNvIHdvcnRoIG1l bnRpb25pbmcgdGhhdCBkb3duZ3JhZGUgbmVjZXNzYXJpbHkgcmVxdWlyZXMgYW4gRUFJIGF3YXJl IHN5c3RlbSAoZXZlbiBpZiBpdCdzICJqdXN0IiBodW1hbiBkb3duZ3JhZGUsIHRoZSBodW1hbiBo YXMgdG8gYmUgYXdhcmUgb2YgdGhlIGlzc3VlKSB0byBkbyB0aGUgZG93bmdyYWRlLg0KDQpUaGVy ZSBhcmUgYWxzbyB2YXJpb3VzIGRlZ3JlZXMgb2YgZG93bmdyYWRlOg0KDQoqIEh1bWFuLW9ubHkg ZG93bmdyYWRlIHdpdGggbm8gYXV0b21hdGVkIG1lY2hhbmlzbS4gIElmIG15IG1haWwgYm91bmNl cyBJIHRyeSBhIGRpZmZlcmVudCBhZGRyZXNzLiAgU29tZSBiaWcgcHJvYmxlbXMgYXJlIHRoYXQg SSBtYXkgbm90IGtub3cgdGhlIG90aGVyIGFkZHJlc3MsIEkgbWF5IG5vdCBrbm93IGhvdyB0byBz ZW5kIEZyb206IGFuIEFTQ0lJIGFkZHJlc3MsIGFuZCBzb21lIHN5c3RlbXMgbWF5IGFjY2VwdCBt YWlsIHRoZXkgY2FuJ3QgcmVwbHkgdG8uDQoNCiogUGFydGlhbGx5IGF1dG9tYXRlZCBkb3duZ3Jh ZGUuICBUaGlzIGNvdWxkIGJlIHNvbWV0aGluZyBsaWtlIEZyb206LCBvciB0aGUgb2xkZXIgaGVh ZGVycyBvciBzb21ldGhpbmcgZWxzZSB0aGF0IGRvZXNuJ3QgcHJvdmlkZSB0aGUgc2FtZSBleHBl cmllbmNlIGluIGEgbWl4ZWQgZW52aXJvbm1lbnQgYXMgaW4gYSBsZWdhY3kgb3IgRUFJIG9ubHkg ZW52aXJvbm1lbnQuICBFZzogc2ltcGxlIG1haWwgbWF5IHdvcmssIGJ1dCBETCdzLCBuZXdzZ3Jv dXBzLCByZXBseS10bywgb3Igb3RoZXIgY2FzZXMgY291bGQgZ2V0IHRyaWNreSBvciBmYWlsLg0K DQpTb21lIGJpZyBwcm9ibGVtcyB3aXRoIHBhcnRpYWwgZG93bmdyYWRlIGFyZSB0aGF0IGl0IGlz IHBhcnRpYWwsIHNvIHVzZXIncyBtYXkgdGhpbmsgbWFpbCB3b3JrcywgYnV0IGdldCB1bmV4cGVj dGVkIGZhaWx1cmVzIGluIGVkZ2UgY2FzZXMuICBBbHNvIChkZXBlbmRpbmcgb24gdGhlIGRlZ3Jl ZSBvZiAicGFydGlhbCIpLCBpdCBtYXkgZmFpbCBpZiB0aGUgZmFsbGJhY2sgYWRkcmVzcyhlcykg YXJlbid0IGtub3cgb3IgY29uZmlndXJlZCBjb3JyZWN0bHkuICBBbHNvIHNvbWUgbWFpbCBtYXkg YXBwZWFyIHRvIHN1Y2NlZWQgYnV0IG1heSBub3QgYmUgYWJsZSB0byBiZSByZXBsaWVkIHRvLg0K DQoqIEZ1bGx5IGF1dG9tYXRlZCBkb3duZ3JhZGUuICBUaGlzIHdvdWxkIGJlIHNvbWUgbWFnaWMg c3lzdGVtIHRoYXQgd291bGQgZG93bmdyYWRlIGFsbCBoZWFkZXJzIHNvIHRoYXQgImV2ZXJ5dGhp bmciIHdvcmtlZCwgaW5jbHVkaW5nIG1haWxpbmcgbGlzdHMsIGV0Yy4gIEluIGFkZGl0aW9uIHRv IHRoZSBwcm9ibGVtIG9mIGRpc2NvdmVyaW5nIHRoZSBkb3duZ3JhZGUgYWRkcmVzcywgd2UndmUg cnVuIGludG8gbnVtZXJvdXMgdGVjaG5pY2FsIGNvbmNlcm5zIGFuZCBlZGdlIGNhc2VzIHdpdGgg dGhlIHNvbHV0aW9ucyBpbnZlc3RpZ2F0ZWQgc28gZmFyLg0KDQpJJ3ZlIGJlZW4gZmxpcC1mbG9w cGluZyBvbiBob3cgbXVjaCBkb3duZ3JhZGUgaXMgbmVjZXNzYXJ5Lg0KDQpIdW1hbi1vbmx5IGRv d25ncmFkZToNCkkgdGhpbmsgaXQncyBwb3NzaWJsZSB0aGF0IGEgaHVtYW4tb25seSBtZWNoYW5p c20gbWF5ICJ3b3JrIiwgYWx0aG91Z2ggdGhhdCBtYXkgc2xvdyBFQUkgYWRvcHRpb24gc2lnbmlm aWNhbnRseS4gIChJZiBJIGRvbid0IHRoaW5rIG15IEVBSSBhZGRyZXNzJ2xsIHdvcmssIHRoZW4g SSdsbCBvbmx5IGdpdmUgb3V0IG15IEFTQ0lJIGFkZHJlc3MsIHRoZW4gd2h5IGJvdGhlciB3aXRo IEVBST8pDQoNClBhcnRpYWxseSBhdXRvbWF0ZWQgZG93bmdyYWRlOg0KUGVyc29uYWxseSBJIGRv bid0IHNlZSBtdWNoIHBvaW50IGluIHBhcnRpYWxseSBhdXRvbWF0ZWQgZG93bmdyYWRlIChmb2xr cyBmcm9tIEV4Y2hhbmdlICYgT3V0bG9vayBhZ3JlZS4pICBJZiBteSBtYWlsIHRvIHlvdSB3b3Jr cywgYW5kIHlvdXIgcmVwbGllcyB3b3JrLCBidXQgZXZlcnl0aGluZyBicmVha3Mgd2hlbiBJIHNl bmQgdG8gYSBETCBvciBuZXdzZ3JvdXAsIHRoZW4gaXQncyBhbG1vc3Qgd29yc2UuDQoNCkZ1bGx5 IGF1dG9tYXRlZCBkb3duZ3JhZGU6DQpGdWxseSBhdXRvbWF0ZWQgZG93bmdyYWRlIHdvdWxkIGJl IGNvb2wsIGJ1dCB3ZSd2ZSBwcmV0dHkgbXVjaCBwcm92ZWQgdGhhdCBpdCdzIGltcG9zc2libGUu ICBNb3N0bHkgYmVjYXVzZSBwYWlyaW5nIHRoZSBhZGRyZXNzZXMgYnJlYWtzIGRvd24gaW4gc2V2 ZXJhbCBjYXNlcywgb3IgYmVjYXVzZSB0aGUgc3ludGF4IHRvIG1ha2UgdGhlIHBhaXJpbmcgZXhw bGljaXQgYnJlYWtzIGRvd25sZXZlbCBzeW50YXguDQoNCkEgcG9zc2libGUgc29sdXRpb246DQoN CkEgd2hpbGUgYmFjayBNYXJrIHN1Z2dlc3RlZCBhbiBzb2x1dGlvbiB0aGF0J3MgYmVlbiBkaXNj dXNzZWQgYmVmb3JlIGFuZCBJIHJlamVjdGVkIG91dCBvZiBoYW5kLiAgRWl0aGVyIEkndmUgaGFk IGEgcGFyYWRpZ20gc2hpZnQgaW4gbXkgdGhpbmtpbmcgb3IgSSBtaXN1bmRlcnN0b29kIE1hcmsn cyBlYXJsaWVyIHN1Z2dlc3Rpb24sIGhvd2V2ZXIgdGhlcmUgaXMgYSB3YXkgdGhhdCBhbGxvd3Mg ZnVsbHkgYXV0b21hdGVkIGRvd25ncmFkZSB3aXRob3V0IGJyZWFraW5nIGFueSBvZiB0aGUgb3Ro ZXIgQVNDSUkgYWRkcmVzcyBhbGlhcyBvciBVVEY4U01UUCBiZWhhdmlvci4gIEl0IGFsc28gb25s eSByZXF1aXJlcyB1cGRhdGluZyB0aGUgRUFJIGF3YXJlIHNlcnZlcnMvY2xpZW50cy4gIFVuYXdh cmUgc3lzdGVtcyB3b3VsZG4ndCBzZWUgYW55dGhpbmcgZGlmZmVyZW50LCBwcm9iYWJseSBldmVu IG1haWxpbmcgbGlzdHMuICBVcGdyYWRlIGlzIGV2ZW4gc3VwcG9ydGVkLg0KDQpNYXJrJ3Mgc3Vn Z2VzdGlvbiAob3IgbXkgbW9kaWZpY2F0aW9uIG9mIGl0KSBpcyBzb21ldGhpbmcgbGlrZSB0aGlz Og0KDQoqIEV2ZXJ5b25lIHRoYXQgd2FudHMgb25lIGdldHMgYSBVbmljb2RlIGFkZHJlc3MsIGFu ZCBhIGh1bWFuIGZyaWVuZGx5IEFTQ0lJIGFsaWFzIChpZiBkZXNpcmVkKS4NCiogV2hlbiBwZW9w bGUgZXhjaGFuZ2UgYWRkcmVzc2VzIGluIHdyaXR0ZW4gZm9ybSwgdGhleSBjYW4gdXNlIFVuaWNv ZGUgaWYgdGhleSB0aGluayB0aGUgcmVjaXBpZW50IGlzIEVBSSBhd2FyZSwgb3IgdGhleSBjYW4g dXNlIHRoZSBBU0NJSSBhZGRyZXNzLg0KKiBNYWlsIHdpdGggRUFJIHRvIEVBSSBhbmQgdGhlIFVu aWNvZGUgYWRkcmVzcyB3b3JrcyBhcyBzcGVjJ2QgZm9yIFVURjhTTVRQLCBldGMuICBObyBleHRy YSBmaWVsZHMgYXJlIHNlbnQuDQoqIFdoZW4gYSBodW1hbiBvciBmb3JtIGlzbid0IGV4cGVjdGlu ZyBVbmljb2RlLCB0aGUgdXNlciBzaGFyZXMgdGhlIGh1bWFuLWZyaWVuZGx5IEFTQ0lJIGFsaWFz LiBUaGVuIHRoZSBBU0NJSSB0byBFQUkgc2VydmVyIGJlaGF2ZXMgYXMgbm9ybWFsLiAgTm8gZXh0 cmEgZmllbGRzIGFyZSBzZW50Lg0KKiBXaGVuIGFuIEVBSSBzZXJ2ZXIgKG9yIGNsaWVudCkgaGl0 cyBhbiBFQUkgdW5hd2FyZSBzeXN0ZW0sIHRoZSBtZXNzYWdlIGlzIGRvd25ncmFkZWQuICBBZGRy ZXNzZXMgYXJlIGRvd25ncmFkZWQgYnkgdXNpbmcgdW5tYXBwZWQgcHVueWNvZGUsIHdoaWNoIGlz IGFsZ29yaXRobWljLCBzbyBpdCBhdm9pZHMgYWxsIHRoZSBhZGRyZXNzIHBhaXJpbmcgcHJvYmxl bXMuICBBbiBFQUkgYXdhcmUgY2xpZW50IGFwcCAobGlrZSBPdXRsb29rKSBjb3VsZCB0aGVuIHVw Z3JhZGUgdGhlIHB1bnljb2RlIGlmIGRlc2lyZWQuICBCZWZvcmUgZG93bmdyYWRlIGEgbWVzc2Fn ZSBpcyBpZGVudGljYWwgdG8gdGhlIGV4aXN0aW5nIHByYWN0aWNlLCBqdXN0IHdpdGggVVRGLTgs IGFuZCBpcyBub24tYnJlYWtpbmcuICBBZnRlciBkb3duZ3JhZGUsIGEgbWVzc2FnZSBpcyBzdGls bCBpZGVudGljYWwgdG8gZXhpc3RpbmcgbGVnYWN5IGJlaGF2aW9yLCBzbyB0aGVyZSdzIG5vIGJy ZWFraW5nLg0KDQpCeSB1c2luZyBVTk1BUFBFRCBwdW55Y29kZSAocmF3IEFDRSBlbmNvZGluZyks IHNlcnZlcnMgY2FuIGNvbnRyb2wgdGhlaXIgb3duIG1hcHBpbmdzIChUdXJraXNoIEkgb3Igd2hh dGV2ZXIncyBpbnRlcmVzdGluZyB0byB0aGVtKS4gIFByZXN1bWFibHkgdGhleSdkIGRlY29kZSBi YWNrIHRvIFVuaWNvZGUsIHRoZW4gZG8gdGhlaXIgbWFwcGluZyBhbmQgcm91dGluZy4gIFRoZSBw cm9ibGVtcyB0aGF0IGRvd25ncmFkZSBoYWQgd2l0aCBtYWlsaW5nIGxpc3RzIGlzIGF2b2lkZWQg YmVjYXVzZSBhbGwgYWRkcmVzc2VzIGNvdWxkIGJlIGRvd25ncmFkZWQgYXQgYW55IHBvaW50LiAg QWRkaXRpb25hbGx5IGEgQVNDSUktb25seSBtYWlsYm94IHVzZXIgZG9lc24ndCBuZWVkIGFuIEVB SSBhd2FyZSBzZXJ2ZXIgdG8gdXNlIEVBSSBiZWNhdXNlIHRoZWlyIEVBSSBhd2FyZSBjbGllbnQg Y291bGQgZG8gdGhlIG1hcHBpbmcuDQoNClRvIG1lLCB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0 aGlzIGFuZCBwcmV2aW91cyBwdW55Y29kZSBwcm9wb3NhbHMgKG1heWJlIEkgbWlzdW5kZXJzdG9v ZCB0aGVtKSBhcmU6DQphKSBVVEYtOCBpcyBwcmVmZXJyZWQsIGFuZCBpcyB0aGUgbG9uZyB0ZXJt IGZvcm0sIG5vdCBwdW55Y29kZS4NCmIpIEh1bWFuLXJlYWRhYmxlIEFTQ0lJIGFsaWFzZXMgYXJl IGEgcHJlZmVycmVkIG1ldGhvZCBvZiBleGNoYW5nZSBvbiB0aGUgc3RpY2t5IG5vdGUgb3Igd2hh dG5vdC4gIChOb2JvZHkncyBnb2luZyB0byBleGNoYW5nZSBhIHB1bnljb2RlIGFkZHJlc3MpLg0K YykgUHVueWNvZGUgaXMgb25seSB1c2VkIGZvciBmYWxsYmFjaywgd2hlbiBVVEY4U1RNUCBvciBv dGhlciBFQUkgcHJvdG9jb2xzIGFyZW4ndCByZWNvZ25pemVkLg0KZCkgSXQgaXNuJ3QgSUROIHB1 bnljb2RlLCBidXQganVzdCB1bm1hcHBlZCBVbmljb2RlIHRoYXQgdGhlIHNlcnZlciBoYXMgdG8g ZGVjb2RlIGFuZCBtYXAuDQoNClRoZSBhZHZhbnRhZ2VzIGFyZToNCiogVXNlcnMgZ2V0IGEgVW5p Y29kZSBhZGRyZXNzLg0KKiBVc2VycyBzdGlsbCBnZXQgYSBodW1hbiBmcmllbmRseSBBU0NJSSBh ZGRyZXNzIGFzIG5lZWRlZC4NCiogVGhlcmUncyBhIGZ1bGwgZG93bmdyYWRlIGNhcGFiaWxpdHkg KHdpdGggdXBncmFkZSBpZiBkZXNpcmVkKQ0KKiBJbnRlcm9wZXJhYmlsaXR5IHdpdGggbGVnYWN5 IHN5c3RlbXMgc2hvdWxkIGJlIHZlcnkgaGlnaC4NCiogTm8gcHJvYmxlbXMgd2l0aCBwYWlyaW5n IG9mIHRoZSBhZGRyZXNzZXMuDQoqIFdvcmtzIHdoZW5ldmVyIGFuIEVBSS1hd2FyZSBjbGllbnQv bWFpbGJveCBiZWhhdmUuICBJbnRlcm1lZGlhdGUgc3lzdGVtcyBkb24ndCBpbXBhY3QgaXQsIGFu ZCBhbiBFQUkgYXdhcmUgcmVjaXBpZW50IGNsaWVudCBjYW4gaGF2ZSBhbiBFQUkgZXhwZXJpZW5j ZSBldmVuIGlmIHRoZXkgZG9u4oCZdCBoYXZlIGFuIEVBSSBtYWlsYm94IHRoZW1zZWx2ZXMuDQoq IE9ubHkgc2VydmVycy9jbGllbnRzIHVwZ3JhZGVkIHRvIEVBSSBuZWVkIHRvIGJlIHRvdWNoZWQu ICBMZWdhY3kgc3lzdGVtcyBpbiB0aGUgbWlkZGxlIHdpbGwgc3RpbGwgYmVoYXZlLiAgKEknbSB0 b2xkIGJ5IEV4Y2hhbmdlIHRoYXQgaXQgd291bGQgdGFrZSBkZWNhZGVzIHRvIHVwZ3JhZGUgZXZl cnl0aGluZykuDQoqIE1hcHBpbmcgc3RpbGwgaGFwcGVucyBieSB0aGUgbWFpbGJveCBzZXJ2ZXIn cyBydWxlcy4NCiogQWxnb3JpdGhtaWMgcnVsZXMgZm9yIGRvd25ncmFkZSBtZWFuIHRoYXQgZG93 bmdyYWRlIGlzIGFsd2F5cyBwb3NzaWJsZSBpbnN0ZWFkIG9mIHJlcXVpcmluZyBrbm93bGVkZ2Ug b2YgdGhlIEFTQ0lJIGFsaWFzLg0KKiBTZW5kZXJzIGNhbiBkb3duZ3JhZGUgKGlmIHRoZSBjbGll bnQgaXMgRUFJIGF3YXJlKSBldmVuIHdpdGggb25seSBhIFVuaWNvZGUgcmVjaXBpZW50IGFkZHJl c3MsIGV2ZW4gaWYgdGhlaXIgbWFpbCBzZXJ2ZXIgaXMgYSBsZWdhY3kgc2VydmVyLg0KDQpUaGUg ZGlzYWR2YW50YWdlcyBhcmU6DQoqIE5vbi1FQUkgYXdhcmUgcmVjaXBpZW50cyB3b3VsZCByZWNl aXZlIHB1bnljb2RlIGFkZHJlc3NlcyBpbnN0ZWFkIG9mIGh1bWFuIGZyaWVuZGx5IEFTQ0lJLiAg VGhpcyBpcyBtaXRpZ2F0ZWQgYnkgdGhlIGZhY3QgdGhhdCBtb3N0IGNsaWVudHMgZGlzcGxheSB0 aGUgZGlzcGxheSBuYW1lLg0KKiBQdW55Y29kZSBkb3duZ3JhZGUgcmVxdWlyZXMgdGhhdCBFQUkg YXdhcmUgc3lzdGVtcyBrbm93IHRoZSBwdW55Y29kZSBtYXBwaW5nLiAgVGhpcyBpcyBtaXRpZ2F0 ZWQgYnkgcmVkdWNpbmcgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIG90aGVyIHBhaXJpbmcgc2NoZW1l cy4NCiogRUFJIG1haWxib3ggc2VydmVycyBoYXZlIHRvIHVubWFwIHRoZSBQdW55Y29kZSB0byBV bmljb2RlIGJlZm9yZSBkb2luZyBhbnkgbWFwcGluZyB0byBmaW5kIHRoZSBtYWlsYm94LiAgKEFs aWFzZXMgbWlnaHQgd29yayBpbiBzb21lIGNhc2VzLCBidXQgeW91J2Qgc3RpbGwgd2FudCBjYXNl IG1hcHBpbmcgcHJvYmFibHkpLg0KKiBGb3Igc3lzdGVtcyB0aGF0IGRvbid0IG5lZWQgRUFJIChl ZzogbWFueSBVUyBtYWlsIHNlcnZlcnMpIHRoZXJlJ3MgcmVkdWNlZCBpbmNlbnRpdmUgdG8gdXBn cmFkZSB0byBiZSBFQUkgYXdhcmUgc2luY2UgYW4gRUFJIGF3YXJlIGNsaWVudCBpcyBzdWZmaWNp ZW50LiAgVGhpcyBjb3VsZCBkZWxheSBjb21wbGV0ZSBhZG9wdGlvbi4gIChJdCdzIGFsc28gYW4g YWR2YW50YWdlIHRoYXQgY291bGQgc3BlZWQgdXAgZWFybHkgYWRvcHRpb24uKQ0KKiBUaHJlZSBh ZGRyZXNzZXMgKFVuaWNvZGUsIEFTQ0lJLCBQdW55Y29kZSkgaW5zdGVhZCBvZiAyICh0aG91Z2gg dGhlIFB1bnljb2RlIGlzIGp1c3QgYW4gZW5jb2RlZCBmb3JtIG9mIHRoZSBVbmljb2RlKS4NCg0K Q291cGxlIG1pbm9yIGNvbW1lbnRzOg0KKiBBcyBJIHNhaWQsIHRoZSBwdW55Y29kZSBzaG91bGQg YmUgdW5tYXBwZWQgQUNFLCBub3QgSUROIGZvcm0uDQoqIFRvIG1ha2UgdGhhdCBjbGVhciwgSSdk IHBpY2sgYSBkaWZmZXJlbnQgcHJlZml4LCBvciBzb21lIG90aGVyIHNpZ25hdHVyZSBtZWNoYW5p c20uICAoTXkgZmVhciBpcyB0aGF0IGRldmVsb3BlcnMgd291bGQgYWNjaWRlbnRhbGx5IGNhbGwg dGhlIElETiBBUElzIGFuZCBnZXQgaW5hcHByb3ByaWF0ZSBtYXBwaW5ncykuDQoNCkkga25vdyB3 ZSd2ZSBkaXNjdXNzZWQgUHVueWNvZGUgYmVmb3JlLCBidXQgSSB0aGluayB0aGUgZGlmZmVyZW5j ZSBpcyB0aGF0IEknbSBzdWdnZXN0aW5nIGl0IGFzIGEgbGFzdC1yZXNvcnQgY2FzZSwgbm90IGFz IGEgcmVwbGFjZW1lbnQgZm9yIFVURjhTTVRQLCBub3IgYSByZXBsYWNlbWVudCBmb3IgdGhlIGh1 bWFuIGZyaWVuZGx5IEFTQ0lJIGFsaWFzZXMuICANCg0KUGxlYXNlIG5vdGUgdGhhdCBJIGFtIHZl cnkgbXVjaCBhZ2FpbnN0IFB1bnljb2RlIGFzIGEgc29sdXRpb24gZm9yIEVBSSAoZWc6IHJlcGxh Y2luZyBVVEYtOCkuICBCeSBpdHNlbGYgYXMgYSBsb25nLXRlcm0gc29sdXRpb24gUHVueWNvZGUg aGFzIGh1Z2UgcHJvYmxlbXMuICBJIHRoaW5rIGl0IGhhcyBhIHBsYWNlIGEgImhhY2siIHRvIHNv bHZlIGRvd25ncmFkZSB0aG91Z2guDQoNCklmIG5lY2Vzc2FyeSB0byBmdXJ0aGVyIGRpc2N1c3Np b24gSSBjb3VsZCBwdXQgdGhpcyBpbiBkcmFmdCBmb3JtLg0KDQotU2hhd24NCg0KDQoNCg== From edainow@ca.afilias.info Thu Sep 10 06:57:05 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8EA28C18E for ; Thu, 10 Sep 2009 06:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2yNb23sdapc for ; Thu, 10 Sep 2009 06:57:04 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 3C3073A6866 for ; Thu, 10 Sep 2009 06:57:04 -0700 (PDT) Message-ID: <4AA905CC.3050709@ca.afilias.info> Date: Thu, 10 Sep 2009 09:57:32 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: "ima@ietf.org" Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 13:57:05 -0000 Shawn Steele wrote: >> By comparison, in 3a, EAI recipients will see all the people that >> received the email and Reply All will reach everyone. However, non-EAI >> recipients will not see any of the EAI recipients, and their Reply All >> will only reach the non-EAI recipients and the sender. >> > > This summarizes my concerns with "partial" downgrade solutions. Things that appear to work stop working in edge cases, and it may be difficult for the sender to predict or understand the behavior. If it fails completely I know I need to get fixed addresses or get an updated mail client or whine at my network admin or something. If it fails "randomly" (many users won't recognize the pattern) then they have no recourse (but to whine at the network admin, which won't help but will cost the support people a lot of money.) > > In short: If it always works for me, great. If it's always broken, then I'll do something to fix it, but if it works sometimes but not others I just get confused and it gets expensive to support. > So you basically do not accept the stated design goal for a simplified downgrade which was for a simplified but imperfect solution. Note that the 'full' downgrade specified in RFC 5504 does not meet this criterion either. Although RFC 5504, unlike the simplified downgrade, is able to handle the 'triangle' case, it will not be reliable and may work sometimes and not others. This is because Alternate Addresses are optional and not required. If the user does not provide an alternate address for every recipient EAI address, someone will be left out on a Reply All to a downgraded message. I don't think anyone would consider making Alternate Addesses required to solve this. So other approaches are necessary. On another thread (Thinking about requirements / downgrade), you have proposed to auto-generate alternate addresses to handle cases like this. That may provide a solution. Other approaches are possible. I think a cleaner one than an ACE based scheme is as follows. Have alternate addresses stored on the server, associated with the primary EAI address for the account (this has been recommended in draft-yao-eai-deployment, section 3). Then add a new SMTP command, something like VRFY, that verifies an email address and returns the associated alternate address. So when an MTA discovers it needs to downgrade, it can use this SMTP command to get the alternate addresses needed from an authoritative source. -Ernie From Shawn.Steele@microsoft.com Thu Sep 10 09:44:34 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA9D3A6A84 for ; Thu, 10 Sep 2009 09:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLQxfsiMCm-W for ; Thu, 10 Sep 2009 09:44:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 2F9583A69D9 for ; Thu, 10 Sep 2009 09:44:33 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Sep 2009 09:44:58 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Thu, 10 Sep 2009 09:44:58 -0700 From: Shawn Steele To: Ernie Dainow Thread-Topic: [EAI] The value of simplified downgrade Thread-Index: AcoyNgfOk0Mu+5R5GUmkX7T1pSeVEA== Content-Class: Date: Thu, 10 Sep 2009 16:44:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <659ed378-2145-4bdc-ae99-c89da3994eb4> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 16:44:34 -0000 SSBrbm93IGZ1bGwgZG9lc24ndCB3b3JrIGluIHRoZSBjdXJyZW50IHJmY3MgOikgDQoNCkFuZCB5 ZXMgSSBkb24ndCBidXkgaW50byB0aGUgdXRpbGl0eSBvZiB0aGUgY3VycmVudCBwYXJ0aWFsIGlk ZWEuDQoNCkEgcHJvYmxlbSB3aXRoIGEgVlJGWSB0eXBlIHNvbHV0aW9uIGlzIHRoYXQgaXQncyBh IHNwYW1tZXJzIGRyZWFtLCBzaW5jZSBpdCB3b3VsZCB0ZWxsIHRoZW0gZ29vZCBtYWlsYm94ZXMu DQoNCkknbSBhbHNvIGNvbmNlcm5lZCB0aGF0IGFuIGFzay10aGUtc2VydmVyIHR5cGUgc29sdXRp b24gd291bGQgYmUgbW9yZSBmcmFnaWxlLiAgTnVtZXJvdXMgdGhpbmdzIGNvdWxkIG1ha2UgaXQg aGFyZCB0byBhc2sgdGhlIHNlcnZlciwgeWV0IHRyYW5zbWl0IGxlZ2FjeSBtYWlsLiAgRm9yIGV4 YW1wbGUsIHdvdWxkIHlvdSBleHBlY3QgRUFJIGF3YXJlIG1haWwgY2xpZW50cyB0byBjb250YWN0 IHRoZSBzZXJ2ZXIgZGlyZWN0bHkgaWYgdGhleSBkb24ndCBoYXZlIGFuIEVBSSBhd2FyZSBzZXJ2 ZXI/ICBQb3J0IDI1IGlzIG9mdGVuIGJsb2NrZWQsIGZvcmNpbmcgdXNlIG9mIGEgbG9jYWwgc2Vy dmVyLg0KDQpJIEhBVEUgQUNFLiAgSXQgY2VydGFpbmx5IHNob3VsZG4ndCBiZSBhIGh1bWFuIGZy aWVuZGx5IGFsaWFzLiAgSG93ZXZlciBpdCBpcyByZWFzb25hYmx5IHNpbXBsZSwgcm9idXN0LCBh bmQgSSBjYW4ndCB0aGluayBvZiBhbnkgdGVjaG5pY2FsIHByb2JsZW0gd2l0aCB0aGF0IHNvbHV0 aW9uLCBvbmx5IGFlc3RoZXRpYy4NCg0KU2VudCBmcm9tIG15IEhUQyBGVVpF4oSiLCBhIFdpbmRv d3MgTW9iaWxlwq4gc21hcnRwaG9uZSBmcm9tIEFUJlQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEVybmllIERhaW5vdyA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+DQpTZW50 OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDA5IDc6MDAgQU0NClRvOiBTaGF3biBTdGVlbGUg PFNoYXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPg0KQ2M6IGltYUBpZXRmLm9yZyA8aW1hQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtFQUldIFRoZSB2YWx1ZSBvZiBzaW1wbGlmaWVkIGRvd25ncmFk ZQ0KDQoNCg0KU2hhd24gU3RlZWxlIHdyb3RlOg0KPj4gQnkgY29tcGFyaXNvbiwgaW4gM2EsIEVB SSByZWNpcGllbnRzIHdpbGwgc2VlIGFsbCB0aGUgcGVvcGxlIHRoYXQgDQo+PiByZWNlaXZlZCB0 aGUgZW1haWwgYW5kIFJlcGx5IEFsbCB3aWxsIHJlYWNoIGV2ZXJ5b25lLiBIb3dldmVyLCBub24t RUFJIA0KPj4gcmVjaXBpZW50cyB3aWxsIG5vdCBzZWUgYW55IG9mIHRoZSBFQUkgcmVjaXBpZW50 cywgYW5kIHRoZWlyIFJlcGx5IEFsbCANCj4+IHdpbGwgb25seSByZWFjaCB0aGUgbm9uLUVBSSBy ZWNpcGllbnRzIGFuZCB0aGUgc2VuZGVyLg0KPj4gICAgIA0KPg0KPiBUaGlzIHN1bW1hcml6ZXMg bXkgY29uY2VybnMgd2l0aCAicGFydGlhbCIgZG93bmdyYWRlIHNvbHV0aW9ucy4gIFRoaW5ncyB0 aGF0IGFwcGVhciB0byB3b3JrIHN0b3Agd29ya2luZyBpbiBlZGdlIGNhc2VzLCBhbmQgaXQgbWF5 IGJlIGRpZmZpY3VsdCBmb3IgdGhlIHNlbmRlciB0byBwcmVkaWN0IG9yIHVuZGVyc3RhbmQgdGhl IGJlaGF2aW9yLiAgSWYgaXQgZmFpbHMgY29tcGxldGVseSBJIGtub3cgSSBuZWVkIHRvIGdldCBm aXhlZCBhZGRyZXNzZXMgb3IgZ2V0IGFuIHVwZGF0ZWQgbWFpbCBjbGllbnQgb3Igd2hpbmUgYXQg bXkgbmV0d29yayBhZG1pbiBvciBzb21ldGhpbmcuICBJZiBpdCBmYWlscyAicmFuZG9tbHkiICht YW55IHVzZXJzIHdvbid0IHJlY29nbml6ZSB0aGUgcGF0dGVybikgdGhlbiB0aGV5IGhhdmUgbm8g cmVjb3Vyc2UgKGJ1dCB0byB3aGluZSBhdCB0aGUgbmV0d29yayBhZG1pbiwgd2hpY2ggd29uJ3Qg aGVscCBidXQgd2lsbCBjb3N0IHRoZSBzdXBwb3J0IHBlb3BsZSBhIGxvdCBvZiBtb25leS4pDQo+ DQo+IEluIHNob3J0OiBJZiBpdCBhbHdheXMgd29ya3MgZm9yIG1lLCBncmVhdC4gIElmIGl0J3Mg YWx3YXlzIGJyb2tlbiwgdGhlbiBJJ2xsIGRvIHNvbWV0aGluZyB0byBmaXggaXQsIGJ1dCBpZiBp dCB3b3JrcyBzb21ldGltZXMgYnV0IG5vdCBvdGhlcnMgSSBqdXN0IGdldCBjb25mdXNlZCBhbmQg aXQgZ2V0cyBleHBlbnNpdmUgdG8gc3VwcG9ydC4NCj4gICANClNvIHlvdSBiYXNpY2FsbHkgZG8g bm90IGFjY2VwdCB0aGUgc3RhdGVkIGRlc2lnbiBnb2FsIGZvciBhIHNpbXBsaWZpZWQgDQpkb3du Z3JhZGUgd2hpY2ggd2FzIGZvciBhIHNpbXBsaWZpZWQgYnV0IGltcGVyZmVjdCBzb2x1dGlvbi4N Cg0KTm90ZSB0aGF0IHRoZSAnZnVsbCcgZG93bmdyYWRlIHNwZWNpZmllZCBpbiBSRkMgNTUwNCBk b2VzIG5vdCBtZWV0IHRoaXMgDQpjcml0ZXJpb24gZWl0aGVyLiBBbHRob3VnaCBSRkMgNTUwNCwg dW5saWtlIHRoZSBzaW1wbGlmaWVkIGRvd25ncmFkZSwgaXMgDQphYmxlIHRvIGhhbmRsZSB0aGUg J3RyaWFuZ2xlJyBjYXNlLCBpdCB3aWxsIG5vdCBiZSByZWxpYWJsZSBhbmQgbWF5IHdvcmsgDQpz b21ldGltZXMgYW5kIG5vdCBvdGhlcnMuIFRoaXMgaXMgYmVjYXVzZSBBbHRlcm5hdGUgQWRkcmVz c2VzIGFyZSANCm9wdGlvbmFsIGFuZCBub3QgcmVxdWlyZWQuIElmIHRoZSB1c2VyIGRvZXMgbm90 IHByb3ZpZGUgYW4gYWx0ZXJuYXRlIA0KYWRkcmVzcyBmb3IgZXZlcnkgcmVjaXBpZW50IEVBSSBh ZGRyZXNzLCBzb21lb25lIHdpbGwgYmUgbGVmdCBvdXQgb24gYSANClJlcGx5IEFsbCB0byBhIGRv d25ncmFkZWQgbWVzc2FnZS4NCg0KSSBkb24ndCB0aGluayBhbnlvbmUgd291bGQgY29uc2lkZXIg bWFraW5nIEFsdGVybmF0ZSBBZGRyZXNzZXMgcmVxdWlyZWQgDQp0byBzb2x2ZSB0aGlzLiBTbyBv dGhlciBhcHByb2FjaGVzIGFyZSBuZWNlc3NhcnkuIE9uIGFub3RoZXIgdGhyZWFkIA0KKFRoaW5r aW5nIGFib3V0IHJlcXVpcmVtZW50cyAvIGRvd25ncmFkZSksIHlvdSBoYXZlIHByb3Bvc2VkIHRv IA0KYXV0by1nZW5lcmF0ZSBhbHRlcm5hdGUgYWRkcmVzc2VzIHRvIGhhbmRsZSBjYXNlcyBsaWtl IHRoaXMuIFRoYXQgbWF5IA0KcHJvdmlkZSBhIHNvbHV0aW9uLg0KDQpPdGhlciBhcHByb2FjaGVz IGFyZSBwb3NzaWJsZS4gSSB0aGluayBhIGNsZWFuZXIgb25lIHRoYW4gYW4gQUNFIGJhc2VkIA0K c2NoZW1lIGlzIGFzIGZvbGxvd3MuDQoNCkhhdmUgYWx0ZXJuYXRlIGFkZHJlc3NlcyBzdG9yZWQg b24gdGhlIHNlcnZlciwgYXNzb2NpYXRlZCB3aXRoIHRoZSANCnByaW1hcnkgRUFJIGFkZHJlc3Mg Zm9yIHRoZSBhY2NvdW50ICh0aGlzIGhhcyBiZWVuIHJlY29tbWVuZGVkIGluIA0KZHJhZnQteWFv LWVhaS1kZXBsb3ltZW50LCBzZWN0aW9uIDMpLiBUaGVuIGFkZCBhIG5ldyBTTVRQIGNvbW1hbmQs IA0Kc29tZXRoaW5nIGxpa2UgVlJGWSwgdGhhdCB2ZXJpZmllcyBhbiBlbWFpbCBhZGRyZXNzIGFu ZCByZXR1cm5zIHRoZSANCmFzc29jaWF0ZWQgYWx0ZXJuYXRlIGFkZHJlc3MuIFNvIHdoZW4gYW4g TVRBIGRpc2NvdmVycyBpdCBuZWVkcyB0byANCmRvd25ncmFkZSwgaXQgY2FuIHVzZSB0aGlzIFNN VFAgY29tbWFuZCB0byBnZXQgdGhlIGFsdGVybmF0ZSBhZGRyZXNzZXMgDQpuZWVkZWQgZnJvbSBh biBhdXRob3JpdGF0aXZlIHNvdXJjZS4NCg0KICAgIC1Fcm5pZQ0KDQoNCg0K From sm@resistor.net Thu Sep 10 11:11:44 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFD328C1D8 for ; Thu, 10 Sep 2009 11:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EvKti4+3XtX for ; Thu, 10 Sep 2009 11:11:43 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 1DD4428C1D1 for ; Thu, 10 Sep 2009 11:11:43 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n8AIC8aa023401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 11:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1252606336; x=1252692736; bh=Jc06fe/usmqUtb+aibRCKAOMjIfB5imw4EZs9IcFErw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=F+Brx8VhQSf0wTzQO1C3fvxVVl+a2jisxhkTeuKdqkSh3dfj2g1WdsYTc43o+1fU8 F5XmInQ6EmjXgd38N4qqEJoa9f77fePW2wz2S9bITFZA7Lvv3v620Xr3f707JqdKZS wRLA2wiyibhX7WjuOqVbnE1/WZwGF1ct+ZDlX8eI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ImdeJQx/5oXA0asKCP3s2jJ/aYs2i7GrFo2HDsOJVjsSKUOkFsXqwAnDfhk4z7Mqz 1ZebcMUHJuNfujr6aEE8DyMxq7lxIJnGK/w+olgFR2uL/Da98eDwfe1GSATjwg2qaqW zD2CPrkPeu8JtHLO2tU37SVcZJdDv+AR4zetD8c= Message-Id: <6.2.5.6.2.20090910105821.030bbdb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Sep 2009 11:11:29 -0700 To: Shawn Steele From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 18:11:44 -0000 Hi Shawn, At 09:44 10-09-2009, Shawn Steele wrote: >A problem with a VRFY type solution is that it's a spammers dream, >since it would tell them good mailboxes. VRFY could help in getting the EAI-addr. As that feature has been turned off in the default configuration since a long time, I'm not sure whether you can sell it as a solution. By the way, I can tell what are the good mailboxes even if VRFY is disabled. >I'm also concerned that an ask-the-server type solution would be >more fragile. Numerous things could make it hard to ask the server, >yet transmit legacy mail. For example, would you expect EAI aware >mail clients to contact the server directly if they don't have an >EAI aware server? Port 25 is often blocked, forcing use of a local server. The EAI mail client (not to be confused with the SMTP client) should be using the submission port. You cannot "ask the server" as you'll run into port 25 blocking and other techniques which prohibits that. Regards, -sm From Shawn.Steele@microsoft.com Thu Sep 10 11:15:46 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8FD3A6AB4 for ; Thu, 10 Sep 2009 11:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX2n7LaXeLXl for ; Thu, 10 Sep 2009 11:15:45 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B0E963A68D3 for ; Thu, 10 Sep 2009 11:15:45 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Sep 2009 11:16:20 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Thu, 10 Sep 2009 11:16:18 -0700 From: Shawn Steele To: SM Thread-Topic: [EAI] The value of simplified downgrade Thread-Index: AcoyNgfOk0Mu+5R5GUmkX7T1pSeVEAADEAgwAAAgjG0= Date: Thu, 10 Sep 2009 18:16:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 18:15:46 -0000 So you aren't suggesting an eai aware client should be able to downgradw w/= o an eai aware server on it's side? That is unnecessarily restrictive. Sent from my HTC FUZE=99, a Windows Mobile=AE smartphone from AT&T -----Original Message----- From: SM Sent: Thursday, September 10, 2009 11:12 AM To: Shawn Steele Cc: ima@ietf.org Subject: Re: [EAI] The value of simplified downgrade Hi Shawn, At 09:44 10-09-2009, Shawn Steele wrote: >A problem with a VRFY type solution is that it's a spammers dream, >since it would tell them good mailboxes. VRFY could help in getting the EAI-addr. As that feature has been turned off in the default configuration since a long time, I'm not sure whether you can sell it as a solution. By the way, I can tell what are the good mailboxes even if VRFY is disabled. >I'm also concerned that an ask-the-server type solution would be >more fragile. Numerous things could make it hard to ask the server, >yet transmit legacy mail. For example, would you expect EAI aware >mail clients to contact the server directly if they don't have an >EAI aware server? Port 25 is often blocked, forcing use of a local server= . The EAI mail client (not to be confused with the SMTP client) should be using the submission port. You cannot "ask the server" as you'll run into port 25 blocking and other techniques which prohibits that. Regards, -sm From sm@resistor.net Thu Sep 10 13:23:17 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAB33A6B75 for ; Thu, 10 Sep 2009 13:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn4yQwQFNjP1 for ; Thu, 10 Sep 2009 13:23:16 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id DC17A3A686C for ; Thu, 10 Sep 2009 13:23:16 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n8AKNUFm002358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 13:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1252614227; x=1252700627; bh=GosNutuBTkzo4DiJnzmrIZ+9YpLApaYItn3/5TvK8dU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=c9L9uy57MDvOMWMimIWAF4h+jowKvweXTwt+1xTcZpBJdYGduqZDwa1vyqkykNu29 oEhj7LB6D0xetN9x4hkywmxjERMg/UkSrmBiDXXYkitDGDy8xXbnhBv2qi/kyFI1Ih me4XFTBQklOydVRD7uDUPmlEiY+X64hcyudD04gs= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=zglC0VssQOCHMsBLyaFbFTL6uQxEGt433JrK+kbUjzYLIbn5p3sxto4+Fj2ZVIhq+ owt2LIc7HpyteazauNDEJpIrvMydXLu05av/3FAPPnTX58KRVYW+qcebb2Y8w59+aOs dgigQcqYVgt3W97Sph6693lXAocOVaB5uC4kVj8= Message-Id: <6.2.5.6.2.20090910131543.02ead860@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Sep 2009 13:23:02 -0700 To: Shawn Steele From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 20:23:18 -0000 At 11:16 10-09-2009, Shawn Steele wrote: >So you aren't suggesting an eai aware client should be able to >downgradw w/o an eai aware server on it's side? That is >unnecessarily restrictive. No, my comment was about not having a MUA interact with the SMTP server at the receiving end. I'll comment further in my reply to Ernie's message. Regards, -sm From alexey.melnikov@isode.com Thu Sep 10 14:12:01 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECBE28C20D for ; Thu, 10 Sep 2009 14:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFUoKZD9-ZSM for ; Thu, 10 Sep 2009 14:12:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 63F0928C204 for ; Thu, 10 Sep 2009 14:12:00 -0700 (PDT) Received: from [92.40.152.171] (92.40.152.171.sub.mbb.three.co.uk [92.40.152.171]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Sep 2009 22:12:19 +0100 Message-ID: <4AA96B90.7070007@isode.com> Date: Thu, 10 Sep 2009 22:11:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: barryleiba@computer.org References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> In-Reply-To: <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:12:01 -0000 Barry Leiba wrote: >Hi, Pete. > Hi Barry, >>>OLD >>> The UTF8=ONLY capability implies the UTF8 base capability, the >>> UTF8=ALL capability and the UTF8=APPEND capability. A server which >>> advertises UTF8=ONLY need not advertise the three implicit >>> capabilities. >>> >>>Oy. This makes parsing the capability string complicated, and should >>>be earlier in the document. It'd be good to make this clear at the >>>beginning, when the UTF8 capability is first mentioned. >>> >>I'm not sure what you want here. Something in the "UTF8" section that says, >>"See below"? Left as is for now. Fix in an RFC Editor Note if need be. >> >When one starts reading the document, one gets to this: > >--------------------------------------------- >3. UTF8 IMAP Capability > > The basic "UTF8" capability indicates the server supports UTF-8 > quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 > responses from the LIST and LSUB commands. >--------------------------------------------- > >It's only later, when one gets to section 7, which I quote above, that >one finds that it's not sufficient to look for "UTF8": one also has to >look for "UTF8=ONLY". And we don't say that UTF8=ALL, UTF8=APPEND, or >UTF8=USER imply the base UTF8. So if UTF8=ONLY is special, I think we >need to say that right up there at the start of section 3, so it's >clear. Or else we say that the presence of *any* "UTF8=" capability >implies the base UTF8, and say *that* in section 3, so it's clear >right up front as to what capability string(s) need to be checked for. > >D'you see what I'm getting at? > (As the responsible AD) After rereading various pieces of the document, I agree this is not clear. (As a WG participant) Here is my understanding how things should work: UTF8=USER is useful by itself, so I think it should be independent of all other UTF8* capabilities. For example it should be possible to only support UTF8=USER (non EAI IMAP server, but which accepts UTF-8 usernames/passwords), or support all other EAI functions, without supporting UTF-8 username/password (e.g. a legacy authentication database). I think UTF8=APPEND should be independent of other UTF8* capabilities. Allowing for EAI APPEND might require quite a bit of extra work. Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can either define them as implying UTF8, or say that if one of them is advertised, then UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies UTF8=ALL. One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either way, but one way or another this needs to be stated explicitly. Comments? From alexey.melnikov@isode.com Thu Sep 10 14:19:42 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F903A68F1 for ; Thu, 10 Sep 2009 14:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtECPBl+5kj9 for ; Thu, 10 Sep 2009 14:19:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ADACC28C184 for ; Thu, 10 Sep 2009 14:19:41 -0700 (PDT) Received: from [92.40.152.171] (92.40.152.171.sub.mbb.three.co.uk [92.40.152.171]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Sep 2009 22:20:16 +0100 Message-ID: <4AA96D88.10403@isode.com> Date: Thu, 10 Sep 2009 22:20:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Joseph Yee References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <1A999F1D-63B0-4142-BEF4-6B48371BABD9@ca.afilias.info> In-Reply-To: <1A999F1D-63B0-4142-BEF4-6B48371BABD9@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:19:42 -0000 Hi Joseph, Your message and the message from Barry prompted me to review this in more details. See my reply to Barry's message. I will just comment on your statement about the ENABLE command: Joseph Yee wrote: > Let me try... > > I think it's down to whether ENABLE UTF8 enables everything in > section 4,5,6.7, or we need to write ENABLE UTF8=APPEND, ENABLE > UTF8=ALL, etc. Well, there is no need for the client to call ENABLE for every extension it uses, although doing so wouldn't be an error. See RFC 5161 for more details. From alexey.melnikov@isode.com Thu Sep 10 14:28:03 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFA03A6AC5 for ; Thu, 10 Sep 2009 14:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OUSLuBHj5dr for ; Thu, 10 Sep 2009 14:28:02 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3BBA53A69D6 for ; Thu, 10 Sep 2009 14:28:02 -0700 (PDT) Received: from [92.40.152.171] (92.40.152.171.sub.mbb.three.co.uk [92.40.152.171]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Sep 2009 22:28:35 +0100 Message-ID: <4AA96F7B.7020603@isode.com> Date: Thu, 10 Sep 2009 22:28:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Pete Resnick MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: [EAI] An extra comment on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:28:03 -0000 > An IMAP client MUST NOT issue a SEARCH command that uses a mixture of > utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP > server receives such a SEARCH command, it SHOULD reject the command Can somebody remind me why SHOULD is used here? I think we want MUST here, i.e. we should say that any such SEARCH command must be rejected by the server. The only question I have is whether this results in a BAD response, or a NO response. BAD is clearer here, as it is a client error. > with a BAD response (due to the conflicting charset labels). From joseph.yee@gmail.com Thu Sep 10 14:30:41 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B941A28C0DB for ; Thu, 10 Sep 2009 14:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPhhAFZw0pEk for ; Thu, 10 Sep 2009 14:30:40 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 32B873A67AA for ; Thu, 10 Sep 2009 14:30:39 -0700 (PDT) Received: by bwz19 with SMTP id 19so417197bwz.37 for ; Thu, 10 Sep 2009 14:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=g3vUquRLbcMVitL/vU5jvHSk2aiXEgj2kESdyqIZgNY=; b=Gnt4LoXUQxY/xQaDKTWXa6eq7KG8XX/r8p03CAykrxYJBKfk0lE2KJM88BxK078E6Y bmqE0oOUeqAgeSWzaUQGMNE83jb1E31qC22qTUhHLCOlq5r2BMw0AXaZfFuvqvShZQKB r/i8dbfGRkc13jEAMsfR3Zus9tzvsCGvwAulw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=rMqBbXQgT7rDs5BiE9ybili4ykjLynHevuWnpcyY+7N1Sw0pitV4C3biBT+EYwDvHN COLd4P6CPTz8u6Hbv07P7+nezb/bZYdGCEpwN6KqlLMn9BklI3ll9FP3f3lE3ARbvI1m Evjo1+ta0Giv11L6+iqQlNT7XnKYj39AbK7PI= Received: by 10.204.32.204 with SMTP id e12mr1352800bkd.51.1252618272196; Thu, 10 Sep 2009 14:31:12 -0700 (PDT) Received: from ?10.127.8.37? ([24.114.234.28]) by mx.google.com with ESMTPS id 19sm3500810fkr.43.2009.09.10.14.31.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 14:31:11 -0700 (PDT) From: Joseph Yee To: Alexey Melnikov In-Reply-To: <4AA96B90.7070007@isode.com> X-Mailer: iPhone Mail (7A400) References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A400) Date: Thu, 10 Sep 2009 17:30:51 -0400 Cc: Pete Resnick , "barryleiba@computer.org" , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:30:41 -0000 Inline On 2009-09-10, at 5:11 PM, Alexey Melnikov wrote: > Barry Leiba wrote: > >> Hi, Pete. >> > Hi Barry, > >>>> OLD >>>> The UTF8=ONLY capability implies the UTF8 base capability, the >>>> UTF8=ALL capability and the UTF8=APPEND capability. A server which >>>> advertises UTF8=ONLY need not advertise the three implicit >>>> capabilities. >>>> >>>> Oy. This makes parsing the capability string complicated, and >>>> should >>>> be earlier in the document. It'd be good to make this clear at the >>>> beginning, when the UTF8 capability is first mentioned. >>> I'm not sure what you want here. Something in the "UTF8" section >>> that says, >>> "See below"? Left as is for now. Fix in an RFC Editor Note if need >>> be. >> When one starts reading the document, one gets to this: >> >> --------------------------------------------- >> 3. UTF8 IMAP Capability >> >> The basic "UTF8" capability indicates the server supports UTF-8 >> quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and >> UTF-8 >> responses from the LIST and LSUB commands. >> --------------------------------------------- >> >> It's only later, when one gets to section 7, which I quote above, >> that >> one finds that it's not sufficient to look for "UTF8": one also has >> to >> look for "UTF8=ONLY". And we don't say that UTF8=ALL, UTF8=APPEND, >> or >> UTF8=USER imply the base UTF8. So if UTF8=ONLY is special, I think >> we >> need to say that right up there at the start of section 3, so it's >> clear. Or else we say that the presence of *any* "UTF8=" capability >> implies the base UTF8, and say *that* in section 3, so it's clear >> right up front as to what capability string(s) need to be checked >> for. >> >> D'you see what I'm getting at? >> > (As the responsible AD) After rereading various pieces of the > document, I agree this is not clear. > > > (As a WG participant) Here is my understanding how things should work: > > UTF8=USER is useful by itself, so I think it should be independent > of all other UTF8* capabilities. For example it should be possible > to only support UTF8=USER (non EAI IMAP server, but which accepts > UTF-8 usernames/passwords), or support all other EAI functions, > without supporting UTF-8 username/password (e.g. a legacy > authentication database). I agree with the second part and that's my understanding of the doc. Not sure of the first part. Allowing UTF8 login/password but not UTF8- IMAP capable? I don't think we need special capa for it, it can be done today... > > I think UTF8=APPEND should be independent of other UTF8* > capabilities. Allowing for EAI APPEND might require quite a bit of > extra work. I personally think it can imply UTF8 but not any other UTF8-*. Not sure if you mean the same from UTF8* > > Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can > either define them as implying UTF8, or say that if one of them is > advertised, then UTF8 MUST also be advertised. Moreover, I think > UTF8=ONLY implies UTF8=ALL. > One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok > either way, but one way or another this needs to be stated explicitly. Section 7 of the doc makes it clear that UTF8-ONLY implies both ALL and APPEND. I have not fully read -08 yet, is it not there anymore? Thanks Joseph > > Comments? > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From joseph.yee@gmail.com Thu Sep 10 14:37:02 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5312128C199 for ; Thu, 10 Sep 2009 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL55yQkwToQy for ; Thu, 10 Sep 2009 14:37:01 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 2EF2228C156 for ; Thu, 10 Sep 2009 14:37:01 -0700 (PDT) Received: by bwz19 with SMTP id 19so420717bwz.37 for ; Thu, 10 Sep 2009 14:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=o7Y3Of7EcTk+Tzhds7WQQLP26y2ct6jvyIwLFbbbSXU=; b=Gmb/L+Gb2nfQBoK+XyhHudMRjV2M1u2GyykIavB9iuOxkhrFswkioRykQ5raD8pcWC Y83ivqXvPH5cxbPuT1K5eiZ9vIJC4MnTOKa0TpV0v8AEzgBrHIZhRsXxDVgAZ+B9FAdv zagMmqP6dFD583J0k0zBzOEGZVlqPLbftTRks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=YdjcpnbP4gt0iiKCRfIB3Io9RQ5prfPHRIoS6V15OyajrZHKE7RiPhVuJxyqSlIikm 27kHe3xdq6YIRn80JCUlBBfONnzMLI2BstCxz36dUp+VO3kxb20J+ySMAcUZWDyKO9Hn iP3CRaB2crhdw92Sg+vtKWj8KWXJa9F0ko3oU= Received: by 10.204.153.27 with SMTP id i27mr1337630bkw.155.1252618653349; Thu, 10 Sep 2009 14:37:33 -0700 (PDT) Received: from ?10.127.8.37? ([24.114.234.28]) by mx.google.com with ESMTPS id 18sm3609923fks.10.2009.09.10.14.37.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 14:37:32 -0700 (PDT) From: Joseph Yee To: Alexey Melnikov In-Reply-To: <4AA96D88.10403@isode.com> X-Mailer: iPhone Mail (7A400) References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <1A999F1D-63B0-4142-BEF4-6B48371BABD9@ca.afilias.info> <4AA96D88.10403@isode.com> Message-Id: <006C2B48-855D-49FA-A8DB-9B6B432F228A@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A400) Date: Thu, 10 Sep 2009 17:37:15 -0400 Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:37:02 -0000 Which I think is better, thanks Alexey best, Joseph Sent from my iPhone On 2009-09-10, at 5:20 PM, Alexey Melnikov wrote: > Hi Joseph, > Your message and the message from Barry prompted me to review this > in more details. See my reply to Barry's message. > > I will just comment on your statement about the ENABLE command: > > Joseph Yee wrote: > >> Let me try... >> >> I think it's down to whether ENABLE UTF8 enables everything in >> section 4,5,6.7, or we need to write ENABLE UTF8=APPEND, ENABLE >> UTF8=ALL, etc. > > Well, there is no need for the client to call ENABLE for every > extension it uses, although doing so wouldn't be an error. See RFC > 5161 for more details. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From alexey.melnikov@isode.com Thu Sep 10 14:54:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DD43A69D6 for ; Thu, 10 Sep 2009 14:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njtwj+s32vd9 for ; Thu, 10 Sep 2009 14:54:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 700C53A67AE for ; Thu, 10 Sep 2009 14:54:42 -0700 (PDT) Received: from [92.40.152.171] (92.40.152.171.sub.mbb.three.co.uk [92.40.152.171]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Sep 2009 22:55:16 +0100 Message-ID: <4AA975B9.5040700@isode.com> Date: Thu, 10 Sep 2009 22:55:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Joseph Yee References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , "barryleiba@computer.org" , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:54:43 -0000 Hi Joseph, Joseph Yee wrote: > Inline > > On 2009-09-10, at 5:11 PM, Alexey Melnikov > wrote: > >> Barry Leiba wrote: >> >>> Hi, Pete. >> >> Hi Barry, >> >>>>> OLD >>>>> The UTF8=ONLY capability implies the UTF8 base capability, the >>>>> UTF8=ALL capability and the UTF8=APPEND capability. A server which >>>>> advertises UTF8=ONLY need not advertise the three implicit >>>>> capabilities. >>>>> >>>>> Oy. This makes parsing the capability string complicated, and >>>>> should >>>>> be earlier in the document. It'd be good to make this clear at the >>>>> beginning, when the UTF8 capability is first mentioned. >>>> >>>> I'm not sure what you want here. Something in the "UTF8" section >>>> that says, >>>> "See below"? Left as is for now. Fix in an RFC Editor Note if need >>>> be. >>> >>> When one starts reading the document, one gets to this: >>> >>> --------------------------------------------- >>> 3. UTF8 IMAP Capability >>> >>> The basic "UTF8" capability indicates the server supports UTF-8 >>> quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 >>> responses from the LIST and LSUB commands. >>> --------------------------------------------- >>> >>> It's only later, when one gets to section 7, which I quote above, that >>> one finds that it's not sufficient to look for "UTF8": one also has to >>> look for "UTF8=ONLY". And we don't say that UTF8=ALL, UTF8=APPEND, or >>> UTF8=USER imply the base UTF8. So if UTF8=ONLY is special, I think we >>> need to say that right up there at the start of section 3, so it's >>> clear. Or else we say that the presence of *any* "UTF8=" capability >>> implies the base UTF8, and say *that* in section 3, so it's clear >>> right up front as to what capability string(s) need to be checked for. >>> >>> D'you see what I'm getting at? >> >> (As the responsible AD) After rereading various pieces of the >> document, I agree this is not clear. >> >> >> (As a WG participant) Here is my understanding how things should work: >> >> UTF8=USER is useful by itself, so I think it should be independent >> of all other UTF8* capabilities. For example it should be possible >> to only support UTF8=USER (non EAI IMAP server, but which accepts >> UTF-8 usernames/passwords), or support all other EAI functions, >> without supporting UTF-8 username/password (e.g. a legacy >> authentication database). > > I agree with the second part and that's my understanding of the doc. > Not sure of the first part. Allowing UTF8 login/password but not > UTF8- IMAP capable? I don't think we need special capa for it, it can > be done today... The base IMAP spec (RFC 3501) doesn't explicitly allow for UTF-8 username/passwords. So a server supporting UTF-8 usernames/passwords needs to advertise it to the client. I will double check this with the author of RFC 3501 though. RFC 5255 states that in section 5.1, but I don't see any text in RFC 3501 on this. If I am wrong on this, then the UTF-8=USER capability would need to be removed altogether. >> I think UTF8=APPEND should be independent of other UTF8* >> capabilities. Allowing for EAI APPEND might require quite a bit of >> extra work. > > I personally think it can imply UTF8 but not any other UTF8-*. I suppose that would be Ok as well. It is very unlikely that a server will only want to implement EAI APPEND, without wanting to implement the rest of EAI in IMAP. > Not sure if you mean the same from UTF8* > >> Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can >> either define them as implying UTF8, or say that if one of them is >> advertised, then UTF8 MUST also be advertised. Moreover, I think >> UTF8=ONLY implies UTF8=ALL. >> One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok >> either way, but one way or another this needs to be stated explicitly. > > Section 7 of the doc makes it clear that UTF8-ONLY implies both ALL > and APPEND. I have not fully read -08 yet, is it not there anymore? No, you are correct. I've missed the following paragraph which is quite clear on this: The UTF8=ONLY capability implies the UTF8 base capability, the UTF8=ALL capability and the UTF8=APPEND capability. A server that advertises UTF8=ONLY need not advertise the three implicit capabilities. From barryleiba.mailing.lists@gmail.com Thu Sep 10 15:49:39 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D8F3A67E7 for ; Thu, 10 Sep 2009 15:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJLJHUTZ275p for ; Thu, 10 Sep 2009 15:49:38 -0700 (PDT) Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.211.195]) by core3.amsl.com (Postfix) with ESMTP id 9FFC83A6861 for ; Thu, 10 Sep 2009 15:49:38 -0700 (PDT) Received: by ywh33 with SMTP id 33so829759ywh.18 for ; Thu, 10 Sep 2009 15:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fSGZb6FyApDN2rYKRqXeco5LZ+RDSALc1ErfBiyvjyk=; b=aS3KlqZzH0pDGUkM2b5DSovbsSJZVvaYYAooSvjdca+AU29r3xjlfh73e3wKP5mL7g RzuswYzS3wClBj9cMP0rQWx8zpGmDX8X+XCyMLXT9RR39kaZS0tfGkJqWVmzGTlJqk34 2gNYwzao/+up7lRyAdUoIrjn56yxcqzFB69a0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=aK0X3ncOWxlWjYjLSb6qpLKW3t1GA73xLIK3lDl1QeCIkD5ABLkx43ppUUek3QOiuY 3DN9iPZBFeJMgefr3Y7wPXgnTrtmbK0HzTqqt9sEp5bk/Em5HujSWjHisDtt0Yh4UWG6 f/qaFmXyzCaR+QBfW3Mn+ErDH3F7y0WvZIhqw= MIME-Version: 1.0 Received: by 10.150.61.18 with SMTP id j18mr3689811yba.184.1252623009633; Thu, 10 Sep 2009 15:50:09 -0700 (PDT) In-Reply-To: <4AA96B90.7070007@isode.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> Date: Thu, 10 Sep 2009 18:50:09 -0400 Message-ID: <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:49:39 -0000 > (As the responsible AD) After rereading various pieces of the document, I > agree this is not clear. > > > (As a WG participant) Here is my understanding how things should work: > > UTF8=USER is useful by itself, so I think it should be independent of all > other UTF8* capabilities. For example it should be possible to only support > UTF8=USER (non EAI IMAP server, but which accepts UTF-8 > usernames/passwords), or support all other EAI functions, without supporting > UTF-8 username/password (e.g. a legacy authentication database). > > I think UTF8=APPEND should be independent of other UTF8* capabilities. > Allowing for EAI APPEND might require quite a bit of extra work. > > Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can either > define them as implying UTF8, or say that if one of them is advertised, then > UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies UTF8=ALL. > One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either > way, but one way or another this needs to be stated explicitly. The more I think about it, the more I think that having a "UTF8" capability string as well as "UTF8=xxx" strings creates a confusing situation, particularly when one or more of the others implies the former. Here's what I suggest: Define the capability as "UTF8=x,y,z", where the bit after the "=" (let's call them "UTF8 subcapabilities") can be some combination of ACCEPT, APPEND, USER, ALL, and ONLY. Put this definition into a section that goes between the current sections 2 and 3, and say that the UTF8 subcapabilities are defined in the sections below, and that some of them may imply others. Note, too, that this does not extend the grammar for capability strings. RFC 3501 defines "capability" to be "atom", and the "," character is permitted in an atom. it may require a small tweak to the registry, though. Now, section 3 (now section 4) will start with this: 4. "ACCEPT" UTF8 Subcapability The "ACCEPT" UTF8 subcapability indicates the server supports UTF-8 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB commands. The old section 3.1 gets this change: string sent by the client. When the IMAP server advertises the "ACCEPT" UTF8 subcapability, it informs the client that it supports native UTF-8 quoted-strings with the following syntax: ...and so on, for the other instances of "UTF8 capability". References to "the UTF8=ALL capability" would similarly change to 'the "ALL" UTF8 subcapability', and so on. And we add this: The "ACCEPT" UTF8 subcapability may be specified on its own, or with any combination of other subcapabilities. It is implied by the "ALL" and "ONLY" subcapabilities, and MAY be omitted in the presence of one of those. In '5. "APPEND" UTF8 Subcapability', we add this: The "APPEND" UTF8 subcapability may be specified on its own, or with any combination of other subcapabilities. It is implied by the "ONLY" subcapability, and MAY be omitted in the presence of "ONLY". In '6. "USER" UTF8 Subcapability', we add this: The "USER" UTF8 subcapability may be specified on its own, or with any combination of other subcapabilities. It is not implied by any of the other subcapabilities. In '7. "ALL" UTF8 Subcapability', we add this: The "ALL" UTF8 subcapability may be specified on its own, or with any combination of other subcapabilities. It is implied by the "ONLY" subcapability, and MAY be omitted in the presence of "ONLY". The "ALL" UTF8 subcapability implies the "ACCEPT" subcapability, and "ACCEPT" MAY be omitted in the presence of "ALL". In '8. "ONLY" UTF8 Subcapability', we add this: The "ONLY" UTF8 subcapability may be specified on its own, or with any combination of other subcapabilities. It implies the "ACCEPT", "APPEND", and "ALL" subcapabilities, and those MAY be omitted in the presence of "ONLY". We might add examples, such as these: UTF8=ACCEPT,USER,APPEND UTF8=ACCEPT,ALL UTF8=ALL ; Note, same as above UTF8=ACCEPT,USER,APPEND,ALL,ONLY UTF8=USER,ONLY ; Note, same as above --- I think this makes everything clear and easy to parse. Comments? Barry From Shawn.Steele@microsoft.com Thu Sep 10 16:10:10 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758E93A6A94 for ; Thu, 10 Sep 2009 16:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.405 X-Spam-Level: X-Spam-Status: No, score=-10.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIA-KQbuUPNO for ; Thu, 10 Sep 2009 16:10:09 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 368453A69AF for ; Thu, 10 Sep 2009 16:10:09 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Sep 2009 16:10:44 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Thu, 10 Sep 2009 16:10:44 -0700 From: Shawn Steele To: SM Thread-Topic: [EAI] The value of simplified downgrade Thread-Index: AcoyNgfOk0Mu+5R5GUmkX7T1pSeVEAADEAgwAAAgjG0ABHmA0gAFlSww Date: Thu, 10 Sep 2009 23:10:42 +0000 Message-ID: References: <6.2.5.6.2.20090910131543.02ead860@resistor.net> In-Reply-To: <6.2.5.6.2.20090910131543.02ead860@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 23:10:10 -0000 SSB3YXNuJ3QgdmVyeSBjbGVhciwgc3R1Y2sgb24gbXkgY2VsbCBwaG9uZSwgc29ycnkuDQoNCkkg bWVhbiB0aGF0IGlmIGEgdXNlciBpcyB0cnlpbmcgdG8gc2VuZCBUbzogYW5kIEVBSSBhZGRyZXNz LCBhbmQgaGFzIGFuIEVBSSBhd2FyZSBjbGllbnQsIGl0J2QgYmUgbmljZSBpZiBpdCBjb3VsZCAi ZG93bmdyYWRlIiBiZWZvcmUgaXQgZ290IHRvIHRoZSBzZXJ2ZXIgb24gdGhlIHNlbmRpbmcgc2lk ZS4gIFRoZW4sIGV2ZW4gdGhvdWdoIHRoZSBzZW5kZXIncyBtYWlsIHNlcnZlciBpc24ndCBhbiBF QUkgc2VydmVyLCB0aGV5IGNvdWxkIHN0aWxsIGhhdmUgYSByaWNoIEVBSSBleHBlcmllbmNlLiAg Rm9yIGV4YW1wbGUsIHRoZSBzZW5kZXIgY291bGQgYmUgbWUgaW4gYSBVUyBjb21wYW55IHRoYXQg ZG9lc24ndCBzZWUgYSBuZWVkIGZvciBFQUkgbWFpbGJveGVzIHNlbmRpbmcgbWFpbCB0byBhIEph cGFuZXNlIEVBSSBhZGRyZXNzLg0KDQpJIHRoaW5rIHRoYXQgdG8gYmUgImNvbXBsZXRlIiBkb3du Z3JhZGUgd291bGQgbmVlZCB0byBjb25zaWRlciB0aGF0IGtpbmQgb2Ygc2NlbmFyaW8gKGRvd25n cmFkZSBmcm9tIHNlbmRlciBjbGllbnQgYmVmb3JlIHJlYWNoaW5nIHNlbmRlciBzZXJ2ZXIpLiAg VGhhdCBuZWNlc3NpdGF0ZXMgc29tZSBzb3J0IG9mIGF1dG9tYXRpYyBtZWNoYW5pc20gZm9yIGRv d25ncmFkZSwgc2luY2UgdGhlIHNlbmRlciBtYXkgbm90IGhhdmUgdGhlIEFTQ0lJIGFkZHJlc3Mu ICBTbyBlaXRoZXIgYWxnb3JpdGhtaWMsIG9yIHBlcmhhcHMgY29udGFjdGluZyB0aGUgc2VydmVy IGhvc3RpbmcgdGhlIEVBSSBhZGRyZXNzLiAgRHVlIHRvIHBvcnQgYmxvY2tpbmcsIGZpcmV3YWxs cyBhbmQgcHJveGllcyBhbmQgYWxsIHRoYXQsIEknbSBza2VwdGljYWwgdGhhdCB0aGUgaW5mb3Jt YXRpb24gY291bGQgYmUgcmVxdWVzdGVkIHJlbGlhYmx5IGZyb20gdGhlIGhvc3Qgc2VydmVyLg0K DQotU2hhd24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNNIFttYWlsdG86 c21AcmVzaXN0b3IubmV0XSANClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIO+jk++jl++j oiAyMDA5IDEzOjIzDQpUbzogU2hhd24gU3RlZWxlDQpDYzogaW1hQGlldGYub3JnDQpTdWJqZWN0 OiBSRTogW0VBSV0gVGhlIHZhbHVlIG9mIHNpbXBsaWZpZWQgZG93bmdyYWRlDQoNCkF0IDExOjE2 IDEwLTA5LTIwMDksIFNoYXduIFN0ZWVsZSB3cm90ZToNCj5TbyB5b3UgYXJlbid0IHN1Z2dlc3Rp bmcgYW4gZWFpIGF3YXJlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byANCj5kb3duZ3JhZHcgdy9v IGFuIGVhaSBhd2FyZSBzZXJ2ZXIgb24gaXQncyBzaWRlPyAgVGhhdCBpcyANCj51bm5lY2Vzc2Fy aWx5IHJlc3RyaWN0aXZlLg0KDQpObywgbXkgY29tbWVudCB3YXMgYWJvdXQgbm90IGhhdmluZyBh IE1VQSBpbnRlcmFjdCB3aXRoIHRoZSBTTVRQIA0Kc2VydmVyIGF0IHRoZSByZWNlaXZpbmcgZW5k Lg0KDQpJJ2xsIGNvbW1lbnQgZnVydGhlciBpbiBteSByZXBseSB0byBFcm5pZSdzIG1lc3NhZ2Uu DQoNClJlZ2FyZHMsDQotc20gDQoNCg0K From sm@resistor.net Thu Sep 10 16:28:31 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD54928C253 for ; Thu, 10 Sep 2009 16:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bUOc8vJTqQa for ; Thu, 10 Sep 2009 16:28:30 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A8A5728C1FA for ; Thu, 10 Sep 2009 16:28:27 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n8ANSQV0011594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 16:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1252625314; x=1252711714; bh=f9Y9Op4EPMZRW0/UDfzArzi4IEwYYblla7T51uQjaKs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=JhhvhyTi7d9IXLJjv7cCUQD/CS2AfAzp8aiR/Ob0k31t9AIM1PDr8nJ0PbZPTXafb L7V46okpgEfMAudkZsP8G0WeIZDvIYmywJ9vWYQ90bV88W7V7JtjrNLcorwQaVP/yH ULI1r5opOP9KrWjdM+Nr1DDbl1wpZbaaY8upeiYI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=faXTV53U9CN1vJ+yS24naKUyTjh7LcshmsVWdFqKiF9SEGgFu2BQwcZPuz+DCEOXS TBvx3+tMciCqwkwnVJvbgtVgI37NMgqzONmH5erqAhfhvjx33dQJNuAYSkQgBghMUM5 AdyJ5nuhtMK7iXZ+/faZP1zqEjAQZgbmaGCOgs0= Message-Id: <6.2.5.6.2.20090910161420.032fd858@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Sep 2009 16:28:16 -0700 To: Ernie Dainow From: SM In-Reply-To: <4AA905CC.3050709@ca.afilias.info> References: <4AA905CC.3050709@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 23:28:31 -0000 Hi Ernie, At 06:57 10-09-2009, Ernie Dainow wrote: >Have alternate addresses stored on the server, associated with the >primary EAI address for the account (this has been recommended in >draft-yao-eai-deployment, section 3). Then add a new SMTP command, >something like VRFY, that verifies an email address and returns the >associated alternate address. So when an MTA discovers it needs to >downgrade, it can use this SMTP command to get the alternate >addresses needed from an authoritative source. What Section 3 of draft-yao-eai-deployment-03 recommends is to generate an alternative address and have it stored on the (sender) server-side. The user does not have to bother about that alternative address as the server puts it in. Are you suggesting using VRFY to get the alternative address from another SMTP server? Regards, -sm From klensin@jck.com Thu Sep 10 17:33:42 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923093A6A7F for ; Thu, 10 Sep 2009 17:33:42 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Beb27dB5iJ for ; Thu, 10 Sep 2009 17:33:41 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 922EF3A68E9 for ; Thu, 10 Sep 2009 17:33:39 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mlu5O-000IgI-3t; Thu, 10 Sep 2009 20:33:58 -0400 Date: Thu, 10 Sep 2009 20:33:57 -0400 From: John C Klensin To: barryleiba@computer.org, Alexey Melnikov Message-ID: <24A912F1C6216F22166686E4@PST.JCK.COM> In-Reply-To: <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.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: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 00:33:42 -0000 FWIW, I agree with Barry's analysis and like this solution. john --On Thursday, September 10, 2009 18:50 -0400 Barry Leiba wrote: >> (As the responsible AD) After rereading various pieces of the >> document, I agree this is not clear. >> >> >> (As a WG participant) Here is my understanding how things >> should work: >> >> UTF8=USER is useful by itself, so I think it should be >> independent of all other UTF8* capabilities. For example it >> should be possible to only support UTF8=USER (non EAI IMAP >> server, but which accepts UTF-8 usernames/passwords), or >> support all other EAI functions, without supporting UTF-8 >> username/password (e.g. a legacy authentication database). >> >> I think UTF8=APPEND should be independent of other UTF8* >> capabilities. Allowing for EAI APPEND might require quite a >> bit of extra work. >> >> Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. >> We can either define them as implying UTF8, or say that if >> one of them is advertised, then UTF8 MUST also be advertised. >> Moreover, I think UTF8=ONLY implies UTF8=ALL. One can also >> argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either >> way, but one way or another this needs to be stated >> explicitly. > > The more I think about it, the more I think that having a > "UTF8" capability string as well as "UTF8=xxx" strings creates > a confusing situation, particularly when one or more of the > others implies the former. Here's what I suggest: > > Define the capability as "UTF8=x,y,z", where the bit after the > "=" (let's call them "UTF8 subcapabilities") can be some > combination of ACCEPT, APPEND, USER, ALL, and ONLY. Put this > definition into a section that goes between the current > sections 2 and 3, and say that the UTF8 subcapabilities are > defined in the sections below, and that some of them may imply > others. > > Note, too, that this does not extend the grammar for capability > strings. RFC 3501 defines "capability" to be "atom", and the > "," character is permitted in an atom. it may require a small > tweak to the registry, though. > > Now, section 3 (now section 4) will start with this: > > 4. "ACCEPT" UTF8 Subcapability > > The "ACCEPT" UTF8 subcapability indicates the server > supports UTF-8 quoted strings, the "UTF8" parameter to > SELECT and EXAMINE, and UTF-8 responses from the LIST and > LSUB commands. > > The old section 3.1 gets this change: > > string sent by the client. When the IMAP server advertises > the "ACCEPT" UTF8 subcapability, it informs the client that > it supports native UTF-8 quoted-strings with the following > syntax: > > ...and so on, for the other instances of "UTF8 capability". > References to "the UTF8=ALL capability" would similarly change > to 'the "ALL" UTF8 subcapability', and so on. > > And we add this: > > The "ACCEPT" UTF8 subcapability may be specified on its > own, or with any combination of other subcapabilities. It > is implied by the "ALL" and "ONLY" subcapabilities, and MAY > be omitted in the presence of one of those. > > > In '5. "APPEND" UTF8 Subcapability', we add this: > > The "APPEND" UTF8 subcapability may be specified on its > own, or with any combination of other subcapabilities. It > is implied by the "ONLY" subcapability, and MAY be omitted > in the presence of "ONLY". > > In '6. "USER" UTF8 Subcapability', we add this: > > The "USER" UTF8 subcapability may be specified on its own, > or with any combination of other subcapabilities. It is > not implied by any of the other subcapabilities. > > In '7. "ALL" UTF8 Subcapability', we add this: > > The "ALL" UTF8 subcapability may be specified on its own, or > with any combination of other subcapabilities. It is > implied by the "ONLY" subcapability, and MAY be omitted in > the presence of "ONLY". > > The "ALL" UTF8 subcapability implies the "ACCEPT" > subcapability, and "ACCEPT" MAY be omitted in the presence > of "ALL". > > In '8. "ONLY" UTF8 Subcapability', we add this: > > The "ONLY" UTF8 subcapability may be specified on its own, > or with any combination of other subcapabilities. It > implies the "ACCEPT", "APPEND", and "ALL" subcapabilities, > and those MAY be omitted in the presence of "ONLY". > > We might add examples, such as these: > UTF8=ACCEPT,USER,APPEND > UTF8=ACCEPT,ALL > UTF8=ALL ; Note, same as above > UTF8=ACCEPT,USER,APPEND,ALL,ONLY > UTF8=USER,ONLY ; Note, same as above > > --- > > I think this makes everything clear and easy to parse. > > Comments? > > Barry > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From alexey.melnikov@isode.com Fri Sep 11 03:05:32 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4198A3A6358 for ; Fri, 11 Sep 2009 03:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjKrrOt9m6Ax for ; Fri, 11 Sep 2009 03:05:31 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 166C23A68BA for ; Fri, 11 Sep 2009 03:05:31 -0700 (PDT) Received: from [172.16.2.156] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Sep 2009 11:05:29 +0100 Message-ID: <4AAA20BD.1060904@isode.com> Date: Fri, 11 Sep 2009 11:04:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: barryleiba@computer.org References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> In-Reply-To: <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:05:32 -0000 Barry Leiba wrote: >>(As the responsible AD) After rereading various pieces of the document, I >>agree this is not clear. >> >> >>(As a WG participant) Here is my understanding how things should work: >> >>UTF8=USER is useful by itself, so I think it should be independent of all >>other UTF8* capabilities. For example it should be possible to only support >>UTF8=USER (non EAI IMAP server, but which accepts UTF-8 >>usernames/passwords), or support all other EAI functions, without supporting >>UTF-8 username/password (e.g. a legacy authentication database). >> >>I think UTF8=APPEND should be independent of other UTF8* capabilities. >>Allowing for EAI APPEND might require quite a bit of extra work. >> >>Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can either >>define them as implying UTF8, or say that if one of them is advertised, then >>UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies UTF8=ALL. >>One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either >>way, but one way or another this needs to be stated explicitly. >> [All my responses with either IMAP server or client implementor hat on:] >The more I think about it, the more I think that having a "UTF8" >capability string as well as "UTF8=xxx" strings creates a confusing >situation, particularly when one or more of the others implies the >former. > Agreed. In fact, I think implied IMAP capabilities should be avoided. >Here's what I suggest: > >Define the capability as "UTF8=x,y,z", where the bit after the "=" >(let's call them "UTF8 subcapabilities") can be some combination of >ACCEPT, APPEND, USER, ALL, and ONLY. Put this definition into a >section that goes between the current sections 2 and 3, and say that >the UTF8 subcapabilities are defined in the sections below, and that >some of them may imply others. > >Note, too, that this does not extend the grammar for capability >strings. RFC 3501 defines "capability" to be "atom", and the "," >character is permitted in an atom. it may require a small tweak to >the registry, though. > > This concerns me a bit. Existing IMAP capabilities are just single tokens (with the exception of RIGHTS= defined in RFC 4314), so they can be used for hash table lookups or direct string comparison. What you are suggesting is that we change that. Note that the rest of your proposal seems sensible to me. From alexey.melnikov@isode.com Fri Sep 11 05:20:14 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8D83A67D6 for ; Fri, 11 Sep 2009 05:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmN9CxTm9QEV for ; Fri, 11 Sep 2009 05:20:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CFBEC3A68E9 for ; Fri, 11 Sep 2009 05:20:13 -0700 (PDT) Received: from [172.16.2.156] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Sep 2009 13:20:48 +0100 Message-ID: <4AAA4090.4060009@isode.com> Date: Fri, 11 Sep 2009 13:20:32 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: EAI WG MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060200070903070302070802" Cc: Dave Cridland Subject: [EAI] [Fwd: Re: [Fwd: Re: Comments on draft-ietf-eai-imap-utf8-07]] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 12:20:14 -0000 This is a multi-part message in MIME format. --------------060200070903070302070802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit With Dave's permission. --------------060200070903070302070802 Content-Type: message/rfc822; name="Re: [Fwd: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07]" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [Fwd: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07]" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine (Isode M-Box/14.4v1) with LMTP; Fri, 11 Sep 2009 12:59:54 +0100 (BST) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Fri, 11 Sep 2009 12:59:32 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: [Fwd: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07] References: <4AAA1E7E.5080001@isode.com> In-Reply-To: <4AAA1E7E.5080001@isode.com> Message-Id: <4848.1252670367.566947@puncture> Date: Fri, 11 Sep 2009 12:59:27 +0100 From: Dave Cridland To: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" On Fri Sep 11 10:55:10 2009, Alexey Melnikov wrote: > Any thoughts on this? I am concerned that this changes the > capability processing logic in the client from a simple token > lookup. > > Polymer has always assumed that capabilities are either: FOO Or: FOO=BAR FOO=BAZ And not a mixture. In fact, they're mapped internally to a dictionary construct, with the FOO as key, and a list of the "sub capabilities" as the value: { "FOO": [] } { "FOO": ["BAR", "BAZ"] } So if there's a UTF8 and a UTF8=ALL, that's likely to break things for me, at least. What I don't know is whether other programmers chose to treat caoability strings this way or not - it's certainly mandated by no specs I'm aware of. I would, however, prefer a UTF8=ALL UTF8=FOO UTF8=BANANA style. Dave. --------------060200070903070302070802-- From yaojk@cnnic.cn Fri Sep 11 09:06:04 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565B528C196 for ; Fri, 11 Sep 2009 09:06:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_20=-0.74, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1ATVV1bzMDW for ; Fri, 11 Sep 2009 09:06:03 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id D0B8E3A6A4C for ; Fri, 11 Sep 2009 09:06:02 -0700 (PDT) Received: (eyou send program); Sat, 12 Sep 2009 00:06:39 +0800 Message-ID: <452685199.06334@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 12 Sep 2009 00:06:39 +0800 Message-ID: <008501ca32f9$d8a4b980$0301a8c0@YaoJK> From: "Yao Jiankang" To: "Ernie Dainow" , "EAI" References: <452521626.17231@cnnic.cn> Date: Sat, 12 Sep 2009 00:06:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:06:04 -0000 ----- Original Message ----- From: "Ernie Dainow" To: "EAI" Sent: Thursday, September 10, 2009 2:43 AM Subject: [EAI] The value of simplified downgrade > There is a question of whether the EAI spec should include simplified > downgrade at all. To help answer this, compare what a user has to do in > various situations when there is downgrade and when there is not. From the > user's point of view, there are not that many cases to consider. > > 1. Sending email to an EAI user ("sending" includes compose new mail, > forward, reply). > This case will not have downgrade. If any recipients cannot in fact > receive EAI mail, it will bounce. This is being considered a > 'configuration' error. Note this is different from the current Downgrade > spec which supports downgrade to forward pointing addresses. If it is ascii user sending message to EAI, there should have a downgrade. If the SMTP server or MUA has not been updated to support EAI, the ascii user can not send the message to EAI account because the SMTP server or MUA can not recognize the EAI and will regard the EAI address as illegal one. This has been pointed out in draft-yao-eai-problem-00.txt. > > 2. Sending email to an non-EAI user. > a. If EAI has downgrade, the user may use his EAI email account. As long > as an alternate address has been configured, the mail will be downgraded > using the supplied ASCII address as the From address. > b. If there is no downgrade, the user will have to use his non-EAI email > account. This is slightly awkward, but not be a major hindrance. Many > people are used to managing more than one email accounts, for example one > for work and a second for personal email. > > 3. Sending email to a mix of EAI and non-EAI users. > a. If EAI has downgrade, the user may use his EAI email account and send a > single message, freely mixing EAI and non-EAI addresses on To, Cc, etc. > b. If there is no downgrade, the user will have to send the same email > twice; once using the EAI account for the EAI recipients and a second time > using the non-EAI account for the non-EAI recipients. > > Note that in 3b, EAI users and non-EAI recipients do not know the whole > list of recipients, and Reply All will not reach the full list (unless the > original sender is very disciplined and copies replies from EAI to non-EAI > recipients and vice versa). > > By comparison, in 3a, EAI recipients will see all the people that received > the email and Reply All will reach everyone. However, non-EAI recipients > will not see any of the EAI recipients, and their Reply All will only > reach the non-EAI recipients and the sender. This is a consequence of > dropping double angle brackets on forward pointing addresses, and was > pointed out by Harald as the "triangle" case. As noted in that discussion, > even with double angle brackets the triangle case will not consistently > work in practice, as it depends on users being sufficiently disciplined to > undertake the extra effort of entering alterrnate addresses for all EAI > email addresses. in 3a, +1, it means that even if the current full downgrade mechanism is used, we still can not assure 100% downgrade since the alt-address is depending on the user. so in this sense, simple downgrade does not differ from much the full downgrade. > > Clearly, the pain is case 3b. To the extent that we wish to improve on > this scenario, we should include downgrade. > 3b, is really pain? it is similar to business card situation. the chinese business card has two sides, english side and chinese side. english side is only for those who can not under stand english; chinse side is for those who knows chinese. > A second consideration is the effect on encouraging and speeding the > migration to EAI from legacy email systems. Without downgrade, people have > to actively maintain two email accounts. Under this circumstance, they may > just choose the non-EAI account as the primary. With downgrade, there is > an incentive to use the EAI account as the primary account, since it > handles mail for all cases 1, 2 and 3. > > One of the assumptions in a simplified downgrade is that it is not perfect > (does not handle every possible case) and may lose some audit trail > information. We need to decide if an imperfect downgrade is still better > than no downgrade at all. +1, yes. the WG should decide it. Yao Jiankang CNNIC > > -Ernie > > > > > > > > > > > > > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Fri Sep 11 10:10:28 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA89528C1BA for ; Fri, 11 Sep 2009 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEi4zunw0mB6 for ; Fri, 11 Sep 2009 10:10:27 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 37C3E3A681E for ; Fri, 11 Sep 2009 10:10:26 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mm9eB-0009On-NC; Fri, 11 Sep 2009 13:10:56 -0400 Date: Fri, 11 Sep 2009 13:10:54 -0400 From: John C Klensin To: Yao Jiankang , Ernie Dainow , EAI Message-ID: In-Reply-To: <452685199.06334@cnnic.cn>, <008501ca32f9$d8a4b980$0301a8c0@YaoJK> References: <452521626.17231@cnnic.cn> <452685199.06334@cnnic.cn>, <008501ca32f9$d8a4b980$0301a8c0@YaoJK> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:10:29 -0000 --On Saturday, September 12, 2009 00:06 +0800 Yao Jiankang wrote: >... >> 1. Sending email to an EAI user ("sending" includes compose >> new mail, forward, reply). >> This case will not have downgrade. If any recipients cannot >> in fact receive EAI mail, it will bounce. This is being >> considered a 'configuration' error. Note this is different >> from the current Downgrade spec which supports downgrade to >> forward pointing addresses. > > If it is ascii user sending message to EAI, there should have > a downgrade. If it an ASCII user (i.e., a user of an ASCII-only environment) sending a message to an EAI user, then there are only two possible cases: (i) The ASCII user has (or can easily obtain) an ASCII address for the EAI user and can use it in her MUA. In this case, the user is doing the "downgrade" and no "downgrade" in the protocol is necessary or even useful. (ii) The ASCII user does not have an ASCII address for the intended recipient. In this case, no downgrading mechanism that we could devise is going to be helpful -- the situation is hopeless and no message can be sent. Note that this is really no different from the traditional situation in which you want to send some one an email message but don't have an address or a way to guess one (or have only an address on an internal email system with no way to guess the mapping from your external environment, even if one exists). You are out of luck until and unless you can use some out-of-band mechanism to determine a usable address. > If the SMTP server or MUA has not been updated to support EAI, > the ascii user can not send the message to EAI account because > the SMTP server or MUA can not recognize the EAI and will > regard the EAI address as illegal one. This has been pointed > out in draft-yao-eai-problem-00.txt. Yes. And in several other places. >> 2. Sending email to an non-EAI user. >> a. If EAI has downgrade, the user may use his EAI email >> account. As long as an alternate address has been >> configured, the mail will be downgraded using the supplied >> ASCII address as the From address. b. If there is no >> downgrade, the user will have to use his non-EAI email >> account. This is slightly awkward, but not be a major >> hindrance. Many people are used to managing more than one >> email accounts, for example one for work and a second for >> personal email. But, if the user has both addresses available, and understands that the target address is not EAI, then the user can (and probably should) use his ASCII address as the "From:" address and backward-pointing envelope (MAIL FROM) address. If I were constructing an EAI-aware MUA with multiple identity support, I'd want to arrange it to support paired identities and to switch to the ASCII address if any or all of the outgoing addresses were ASCII. Note that this does not require any downgrade support in the protocol. >> 3. Sending email to a mix of EAI and non-EAI users. >> a. If EAI has downgrade, the user may use his EAI email >> account and send a single message, freely mixing EAI and >> non-EAI addresses on To, Cc, etc. Actually, no. The user must not only be able to mix those addresses, but must also have alternate addresses for all of the EAI ones. Otherwise, if downgrade is needed, it will fail and the message will be rejected. For the situation in which all of the possibly-needed alternate addresses are available, the sender has two choices, even if downgrade is included in the protocol: (i) Treat the message as all-ASCII, using the alternate addresses starting from the point of origin and encoding the i18n addresses, if desired, into name phrases or comments. (ii) Have out-of-band knowledge of the actual deliverability of the EAI addresses (as several people have pointed out, this is extremely likely if those addresses exist and everything is configured correctly). This case does not require that downgrade exist or be usable. (iii) Hope that downgrade not only exists in the protocol but that it will actually be used properly when needed by mid-path software. Any MUA that takes this course of action must, in practice, assume that it will fail and be prepared (in some way) to deal with message rejection because downgrade support is not a _required_ element of our protocols even today. It further needs to assume (or hope) that nothing will cause message rejection in a relay environment that requires returning an NDN and that the NDN will actually be generated and not discarded as an anti-blowback "feature". Note that the first two of these do not require Downgrade in the protocol and that the third is inherently unreliable. >> b. If there is no >> downgrade, the user will have to send the same email twice; >> once using the EAI account for the EAI recipients and a >> second time using the non-EAI account for the non-EAI >> recipients. >> >> Note that in 3b, EAI users and non-EAI recipients do not know >> the whole list of recipients, and Reply All will not reach >> the full list (unless the original sender is very >> disciplined and copies replies from EAI to non-EAI >> recipients and vice versa). >> >> By comparison, in 3a, EAI recipients will see all the people >> that received the email and Reply All will reach everyone. >> However, non-EAI recipients will not see any of the EAI >> recipients, and their Reply All will only reach the non-EAI >> recipients and the sender. This is a consequence of dropping >> double angle brackets on forward pointing addresses, and was >> pointed out by Harald as the "triangle" case. As noted in >> that discussion, even with double angle brackets the >> triangle case will not consistently work in practice, as it >> depends on users being sufficiently disciplined to undertake >> the extra effort of entering alterrnate addresses for all EAI >> email addresses. > > in 3a, > +1, it means that even if the current full downgrade mechanism > is used, > we still can not assure 100% downgrade since the alt-address > is depending on the user. That is correct. If if the alt-addresses are present, we still cannot assure 100% downgrade. Absent specific out-of-band knowledge about the receiving and intermediate systems, there are no circumstances in which downgrading is going to be 100% reliable (I think this is part of the point Shawn has been trying to make). Conversely, if one has that out of band knowledge, downgrading is not needed because all of the relevant adjustments can be made by the originating user or her MUA. > so in this sense, simple downgrade does not differ from much > the full downgrade. This is one of the situations that has caused me to want to see a protocol spec rather than more inherently-vague discussion in email. "Simple downgrade" may mean at least the following different things: (i) Downgrade for backward-pointing addresses only ("MAIL FROM" and "From:"), even if the double-angle-bracket syntax is used for the latter. (ii) Downgrade for backward-pointing _envelope_ addresses only, perhaps in combination with a multiple-valued From: field. Note that doing this would permit return of NDNs even when (or especially when) interpretation of the "From:" field linkages is uncertain. There may be other combinations. Note that the first risks leakage, etc., while the second sacrifices unambiguous Reply-ability to improved deliverability. >> Clearly, the pain is case 3b. To the extent that we wish to >> improve on this scenario, we should include downgrade. >> > > 3b, is really pain? > > it is similar to business card situation. > the chinese business card has two sides, english side and > chinese side. > english side is only for those who can not under stand > english; chinse side is for those who knows chinese. I'm not sure that analogy works, except that, if one finds a single non-Chinese speaker among the cards, one then decides to carry out the entire conversation in "English" in the hope that all of the Chinese speakers also understand English. That, again, leads to three cases: (i) All of the Chinese speakers do, in fact, speak English, all of the cards are turned to the English side, and the conversation is carried out in English. This is very similar to the "it just gets fixed by the sender (or sending MUA) to use nothing but ASCII addresses" case above; in-route downgrading is not needed. (ii) Some of the English speakers do not understand Chinese and some of the Chinese speakers do not understand English. In this case, the situation is hopeless without an intermediate _language_ translation function, whether everyone has an ASCII address or not. And, if not everyone has an ASCII address, delivery is impossible, without or without a downgrade capability. (iii) All of the Chinese speakers understand English, but some of them do not use two-sided cards. The English speaking sender, who does not speak Chinese, still has a way to use the Chinese outbound addresses for those users and does so _and_ no downgrading is needed en route (since it would fail if attempted because not all alt-addresses are present). Downgrade doesn't help with this case for that reason. And I suggest that it will be extremely rare in practice. >> A second consideration is the effect on encouraging and >> speeding the migration to EAI from legacy email systems. >> Without downgrade, people have to actively maintain two >> email accounts. No. Without downgrade they have to maintain two email _addresses_. Whether those addresses are aliases for the same account is a local matter -- remember that messages with non-ASCII body parts work (or not) regardless of EAI. >> Under this circumstance, they may just >> choose the non-EAI account as the primary. With downgrade, >> there is an incentive to use the EAI account as the primary >> account, since it handles mail for all cases 1, 2 and 3. Except when downgrade fails to work as expected because some intermediary rejects rather than downgrading, because there are other recipients who haven't supplied alternate addresses, etc. >> One of the assumptions in a simplified downgrade is that it >> is not perfect (does not handle every possible case) and may >> lose some audit trail information. We need to decide if an >> imperfect downgrade is still better than no downgrade at all. One of the assumptions in a non-simplified downgrade (i.e., 5504-conformant downgrading) is that it is not perfect and will not downgrade every possible case and may lose some audit trail information. From that perspective, the simplified and non-simplified cases are not much different. I think the questions are whether the simplified (and less complex) form still buys enough to be worth the trouble... even if we conclude that the full downgrade form is complex enough, and covers few enough realistic additional cases, to not be worth the trouble it requires. One of the key differences is that senders are always capable of knowing their own ASCII addresses (if those exist), but that we have no reliable and general mechanism for knowing those of all receivers. > +1, yes. the WG should decide it. I'm not quite sure how the WG does that. It is not clear to me that these discussions are converging. And, more important personally, I don't know how I would decide without a concrete proposal for "simplified downgrade" on the table, presumably as an I-D, so that I could really try to analyze the cases. john From edainow@ca.afilias.info Fri Sep 11 15:53:06 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D9F28C148 for ; Fri, 11 Sep 2009 15:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ODMl5XQYuFs for ; Fri, 11 Sep 2009 15:53:05 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 519273A67C0 for ; Fri, 11 Sep 2009 15:53:05 -0700 (PDT) Message-ID: <4AAAD4EE.3070303@ca.afilias.info> Date: Fri, 11 Sep 2009 18:53:34 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SM References: <4AA905CC.3050709@ca.afilias.info> <6.2.5.6.2.20090910161420.032fd858@resistor.net> In-Reply-To: <6.2.5.6.2.20090910161420.032fd858@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: ima@ietf.org Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 22:53:06 -0000 SM wrote: > Hi Ernie, > At 06:57 10-09-2009, Ernie Dainow wrote: >> Have alternate addresses stored on the server, associated with the >> primary EAI address for the account (this has been recommended in >> draft-yao-eai-deployment, section 3). Then add a new SMTP command, >> something like VRFY, that verifies an email address and returns the >> associated alternate address. So when an MTA discovers it needs to >> downgrade, it can use this SMTP command to get the alternate >> addresses needed from an authoritative source. > > What Section 3 of draft-yao-eai-deployment-03 recommends is to > generate an alternative address and have it stored on the (sender) > server-side. The user does not have to bother about that alternative > address as the server puts it in. > > Are you suggesting using VRFY to get the alternative address from > another SMTP server? Yes, if an EAI server has an alternate address associated with an EAI address, it can provide it in response to a new SMTP command from another EAI server. Apparently some similar ideas of doing this type of lookup, for example via LDAP, were explored early on and rejected. Doing this securely becomes complicated very quickly. > > Regards, > -sm From harald@alvestrand.no Sun Sep 13 10:03:13 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3D73A68CE for ; Sun, 13 Sep 2009 10:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJQqTqgQRz69 for ; Sun, 13 Sep 2009 10:03:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 1F3BD3A68A8 for ; Sun, 13 Sep 2009 10:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 634AC39E1A3; Sun, 13 Sep 2009 19:03:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGDehEmOher2; Sun, 13 Sep 2009 19:03:49 +0200 (CEST) Received: from [193.214.121.128] (unknown [193.214.121.128]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3E37039E16F; Sun, 13 Sep 2009 19:03:49 +0200 (CEST) Message-ID: <4AAD2591.4050803@alvestrand.no> Date: Sun, 13 Sep 2009 19:02:09 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org" Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 17:03:13 -0000 As I've said several times before, the situation where <<>> has value is the situation where an EAI user sends a message to both an EAI user and a non-EAI user, and the non-EAI user replies to the message. Shawn, if you think that in this scenario, it's OK that the recipient EAI user does not get the reply from the non-EAI user, please say so explicitly. The one sender / one recipient case works without it. Harald Shawn Steele wrote: >> To replace double angle brackets for the Sender, John Klensin proposed >> using multiple From fields. SM amended this with Reply-To to specify the >> preferred address, as in >> From: EAI-addr, ASCII-addr >> Reply-To: EAI-addr >> where the EAI-addr gets dropped in Downgrade. >> > > I'd imagine that "something" isn't going to be happy with 2 addresses. > > It seems to me that 99% of the time email can be viewed as primarily "sender side" or "recipient side". Eg: Mail goes from a sender system to a recipient system. It is very rare (now) that an in-between system would relay mail from an untrusted server to another 3rd party server. If there is a relay, it'd have to trust the sender, so it's pretty much "sender side," or recognize the recipient "recipient side." > > Assuming that a "sender" has an EAI aware system that is completely conformant and "works" with UTF-8 addresses, then the entire "sender side" would have to be updated to support UTF-8 addresses. If the sender's relays aren't upgraded, then all of their mail ends up being downgraded anyway. > > Similarly a recipient either has an entirely EAI aware system, or they don't. > > So I'm wondering how interesting downgrade really is. If my sending system trusts the sender, presumably it could request an ASCII address from the trusted sender-side server if it needed to downgrade. (Through some other mechanism, like asking the trusted server what other aliases were valid for that account using some new, or even proprietary, protocol). > > So the proposed solution seems like overkill. > > VERY worst case a client (like Outlook) can try to send an EAI email. If it bounces, the client could resend using my ASCII address (assuming it is properly configured). It could even do that silently, or with maybe a little warning saying that had been downgraded. > > -Shawn > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > From ajs@crankycanuck.ca Sun Sep 13 12:53:37 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33B53A68E3 for ; Sun, 13 Sep 2009 12:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6iZFZ5SKPvN for ; Sun, 13 Sep 2009 12:53:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E32723A6869 for ; Sun, 13 Sep 2009 12:53:36 -0700 (PDT) Received: from crankycanuck.ca (unknown [61.17.14.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3548F2FE8CE2 for ; Sun, 13 Sep 2009 19:54:15 +0000 (UTC) Date: Sun, 13 Sep 2009 15:54:09 -0400 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20090913195408.GA400@shinkuro.com> References: <4AAD2591.4050803@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAD2591.4050803@alvestrand.no> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 19:53:37 -0000 On Sun, Sep 13, 2009 at 07:02:09PM +0200, Harald Alvestrand wrote: > As I've said several times before, the situation where <<>> has value is > the situation where an EAI user sends a message to both an EAI user and > a non-EAI user, and the non-EAI user replies to the message. > > Shawn, if you think that in this scenario, it's OK that the recipient > EAI user does not get the reply from the non-EAI user, please say so > explicitly. As someone who has more or less stopped participating in this WG, I just want to note that the above amounts to a serious and important restriction on "backward compatibility". If the recipient EAI user is the loser from the non-EAI user, this really means that non-EAI users (i.e. the non-adopters) lose something, _but also_ that the EAI users (the adopters) lose something. I am completely uninformed about the values in play in that trade-off, and I have no opinion at all on how it ought to go. But it's a pretty serious limitation of interoperability between strictly-822-derived systems and EAI, and it seems to me the WG has to have a strong statement of the ways that interoperability is expected to succeed and the ways it is expected to fail. (Note that I regard "often" as an acceptable answer. But clarity is really important.) A -- Andrew Sullivan ajs@crankycanuck.ca From Shawn.Steele@microsoft.com Sun Sep 13 23:51:09 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A748A28C0ED for ; Sun, 13 Sep 2009 23:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.204 X-Spam-Level: X-Spam-Status: No, score=-9.204 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctKa2vw3oqom for ; Sun, 13 Sep 2009 23:51:09 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id EE2E728C0EE for ; Sun, 13 Sep 2009 23:51:08 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 13 Sep 2009 23:51:52 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Sun, 13 Sep 2009 23:51:52 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: The value of simplified downgrade Thread-Index: AQHKNQfWT3lomtddp06N4ZfYlAY+7w== Date: Mon, 14 Sep 2009 06:51:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] The value of simplified downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 06:51:09 -0000 John Wrote... > (ii) The ASCII user does not have an ASCII address for the > intended recipient. In this case, no downgrading mechanism > that we could devise is going to be helpful -- the situation is > hopeless and no message can be sent. That's not quite true. IF the user has an EAI aware client, it is possible= that the message could be downgraded through an algorithmic method, if one= was standardized. So there's two types of ASCII users: a) if the ASCII user is an ASCII user because they have an ASCII SMTP serve= r, then there's a possible solution. b) if they're an ASCII user because they can't type Chinese or whatever, th= en the situation is hopeless, although in the mass-mailing reply-to an EAI = aware client could still do an algorithmic downgrade. > If I were > constructing an EAI-aware MUA with multiple identity support, > I'd want to arrange it to support paired identities and to > switch to the ASCII address if any or all of the outgoing > addresses were ASCII. Do any of the docs make these kinds of implimentation hints? I think a few= things have been mentioned on the list (aliasing techniques / pairing too)= , that may be useful and not-quite-obvious to implimenters. > Actually, no. The user must not only be able to mix those > addresses, but must also have alternate addresses for all of the > EAI ones. This is another case where an algorithmic technique would be helpful. Note that I don't think that an algorithmic address should be a preferred A= SCII address, such as for a business card, but I do think that there is a p= lace for algorithmic addresses as a last-resort downgrade address. - Shawn= From Shawn.Steele@microsoft.com Mon Sep 14 00:11:36 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7485128C115 for ; Mon, 14 Sep 2009 00:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9q-AuTfZS-R for ; Mon, 14 Sep 2009 00:11:35 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id CD2F728C111 for ; Mon, 14 Sep 2009 00:11:35 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Sep 2009 00:12:19 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Mon, 14 Sep 2009 00:12:18 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: double angle brackets Thread-Index: AQHKNQqxbH1EdNvDi0+R+lbU4hUCcg== Date: Mon, 14 Sep 2009 07:12:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] double angle brackets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:11:36 -0000 Harald asked: > As I've said several times before, the situation where <<>> has value is > the situation where an EAI user sends a message to both an EAI user and > a non-EAI user, and the non-EAI user replies to the message. > Shawn, if you think that in this scenario, it's OK that the recipient > EAI user does not get the reply from the non-EAI user, please say so > explicitly. No, I don't think that partial support in cases like this is helpful. My current thinking is that: 1) Partial downgrade is worse than no downgrade. Edge cases like this make= the behavior difficult to predict, whereas with no downgrade users know to= exchange their friendly-ASCII address. 2) I think that a downgrade solution cannot be sufficiently complete for ca= ses like this unless it is algorithmic (eg: unmapped punycode/ACE). - Shawn= From Shawn.Steele@microsoft.com Mon Sep 14 00:24:36 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE353A67ED for ; Mon, 14 Sep 2009 00:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.387 X-Spam-Level: X-Spam-Status: No, score=-11.387 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZmCLEbjnCgb for ; Mon, 14 Sep 2009 00:24:35 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 61F773A67B5 for ; Mon, 14 Sep 2009 00:24:35 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Sep 2009 00:25:19 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Mon, 14 Sep 2009 00:25:19 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Algorithmic Downgrade Thread-Index: Aco1DIL1iwylGibwSGSQ8MsJ9Wjpbw== Date: Mon, 14 Sep 2009 07:25:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A020100TK5EX14MBXC137red_" MIME-Version: 1.0 Subject: [EAI] Algorithmic Downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:24:36 -0000 --_000_E14011F8737B524BB564B05FF748464A020100TK5EX14MBXC137red_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My current thinking is that: 1) Partial downgrade is worse than no downgrade. Edge cases like this make= the behavior difficult to predict, whereas with no downgrade users know to= exchange their friendly-ASCII address. 2) I think that a downgrade solution cannot be sufficiently complete for ca= ses like this unless it is algorithmic (eg: unmapped punycode/ACE). I can think of a few cases where even an algorithmic downgrade may break do= wn (user can't type the letters, email client doesn't support EAI, but that= 's all the user has, addresses in the text body of a message (eg: not in a = header so they didn't get downgraded) and no available EAI client) Some of= those don't always work today though. Some could be mitigated by an algor= ithmic web-based mapping tool. Other automated systems besides algorithmic would include: * Address pairing, either multiple from, or <<>> type pairs. <<>> doesn't = work everywhere (mailto:) and both get hard to keep the pairs together. We= 've already found numerous problems with these schemes. * Mappings queried from the server. Connectivity issues make this less rel= iable than algorithmic mappings. (Firewalls, port blocking, intermittent n= etwork access, etc., make that less robust.) It also seems more complicate= d to me on the surface to impliment. Again: I don't think that an algorithmic fallback should be "preferred" ASC= II mailbox. I think that a human friendly ASCII address is necessary for m= any EAI accounts. (Although I can imagine cases where maybe a business nee= ds multiple non-ASCII script addresses as well. Say Mongolian + Chinese. = Or Chinese + Arabic.) Anyway, my proposed algorithmic mapping is a worst-c= ase machine fallback address. About the only problem I can see with an algorithmic technique is that user= s would have 3 aliases for the same mailbox, however any EAI aware app shou= ld be able to discover that the algorithmic ASCII address and the Unicode a= ddress are equivilent. FWIW: An algorithmic alias need not replace other fallback techniques, thou= gh I'm not sure they'd add much value if there was a well known algorithmic= approach. At least 2 vendors that own both servers and clients that are independently= considering algorithmic generation of ASCII aliases just because it's easy= for them internally. (Not that they'd necessarily interoperate.) It's no= t clear if either would provide additional human friendly aliases. If a hypothetical "shawnMail" hosted mailboxes with this technique and also= provided web client access, it'd be a fairly complete closed solution. If= it was one of the big mail providers, I could easily imagine 3rd party or = open source clients adding similar support or supporting major providers' a= lgorithms as a competitive or convenience feature. Rather than having 5 di= fferent algorithms for major providers, it'd be nice if there was a common = technique. Even if algorithmic alias generation wasn't a MUST or formal part of the sp= ec, it'd be nice if there was a common algorithm providers MAY use if they = think that approach is interesting. -Shawn --_000_E14011F8737B524BB564B05FF748464A020100TK5EX14MBXC137red_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My current thinking is that:
 
1) Partial downgrade is worse than no downgrade.  Edge cases like= this make the behavior difficult to predict, whereas with no downgrade use= rs know to exchange their friendly-ASCII address.
 
2) I think that a downgrade solution cannot be sufficiently complete f= or cases like this unless it is algorithmic (eg: unmapped punycode/ACE).
 
I can think of a few cases where even an algorithmic downgrade&nb= sp;may break down (user can't type the letters, email client doesn't suppor= t EAI, but that's all the user has, addresses in the text body of a me= ssage (eg: not in a header so they didn't get downgraded) and no available EAI client)  Some of those don't always work today t= hough.  Some could be mitigated by an algorithmic web-based mapping to= ol.
 
Other automated systems besides algorithmic would include:
* Address pairing, either multiple from, or <<>> type pair= s.  <<>> doesn't work everywhere (mailto:) and both get ha= rd to keep the pairs together.  We've already found numerous problems = with these schemes.
 
* Mappings queried from the server.  Connectivity issues make thi= s less reliable than algorithmic mappings.  (Firewalls, port blocking,= intermittent network access, etc., make that less robust.)  It also s= eems more complicated to me on the surface to impliment.
 
Again: I don't think that an algorithmic fallback should be "= ;preferred" ASCII mailbox.  I think that a human friendly ASCII a= ddress is necessary for many EAI accounts.  (Although I can imagine ca= ses where maybe a business needs multiple non-ASCII script addresses as well.  Say Mongolian + Chinese.  Or Chinese = 3; Arabic.)  Anyway, my proposed algorithmic mapping is a worst-case m= achine fallback address.
 
About the only problem I can see with an algorithmic technique is= that users would have 3 aliases for the same mailbox, however any EAI awar= e app should be able to discover that the algorithmic ASCII address and the= Unicode address are equivilent.
 
FWIW: An algorithmic alias need not replace other fallback techni= ques, though I'm not sure they'd add much value if there was a well known a= lgorithmic approach.
 
At least 2 vendors that own both servers and clients that are ind= ependently considering algorithmic generation of ASCII aliases just be= cause it's easy for them internally.  (Not that they'd necessarily int= eroperate.)  It's not clear if either would provide additional human friendly aliases.
 
If a hypothetical "shawnMail" hosted mailboxes with this tec= hnique and also provided web client access, it'd be a fairly complete close= d solution.  If it was one of the big mail providers, I could easily i= magine 3rd party or open source clients adding similar support or supporting major providers' algorithms as a competitive= or convenience feature.  Rather than having 5 different algorithms fo= r major providers, it'd be nice if there was a common technique.
 
Even if algorithmic alias generation wasn't a MUST or formal part of t= he spec, it'd be nice if there was a common algorithm providers MAY use if = they think that approach is interesting.
 
-Shawn
 
--_000_E14011F8737B524BB564B05FF748464A020100TK5EX14MBXC137red_-- From yaojk@cnnic.cn Mon Sep 14 02:11:51 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E7028C0F1 for ; Mon, 14 Sep 2009 02:11:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=1.735, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6H+8bLDBA3F for ; Mon, 14 Sep 2009 02:11:50 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 8754828C111 for ; Mon, 14 Sep 2009 02:11:49 -0700 (PDT) Received: (eyou send program); Mon, 14 Sep 2009 17:12:30 +0800 Message-ID: <452919550.10348@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 14 Sep 2009 17:12:30 +0800 Message-ID: <00ae01ca351b$7ace4cd0$ad6df1da@whatisfuture> From: "YAO Jiankang" To: "EAI WG" References: <452918613.14378@cnnic.cn> Date: Mon, 14 Sep 2009 17:12:26 +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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [EAI] Algorithmic Downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 09:11:51 -0000 DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206IFNoYXduIFN0ZWVsZSAN Cj4gVG86IGltYUBpZXRmLm9yZyANCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTQsIDIwMDkg MzoyNSBQTQ0KPiBTdWJqZWN0OiBbRUFJXSBBbGdvcml0aG1pYyBEb3duZ3JhZGUNCj4gDQo+IA0K PiBNeSBjdXJyZW50IHRoaW5raW5nIGlzIHRoYXQ6DQo+IA0KPiAxKSBQYXJ0aWFsIGRvd25ncmFk ZSBpcyB3b3JzZSB0aGFuIG5vIGRvd25ncmFkZS4gIEVkZ2UgY2FzZXMgbGlrZSB0aGlzIG1ha2Ug dGhlIGJlaGF2aW9yIGRpZmZpY3VsdCB0byBwcmVkaWN0LCB3aGVyZWFzIHdpdGggbm8gZG93bmdy YWRlIHVzZXJzIGtub3cgdG8gPmV4Y2hhbmdlIHRoZWlyIGZyaWVuZGx5LUFTQ0lJIGFkZHJlc3Mu DQoNCmV2ZW4gaW4gZnVsbCBkb3duZ3JhZGUsIHRoZXJlIGlzIGFsc28gYSBlZGdlIGNhc2Ugc2lt aWxhciB0byBzaW1wbGUgZG93bmdyYWRlLCB3aG9zZSBiZWhhdmlvciBpcyBkaWZmaWN1bHQgdG8g YmUgcHJlZGljdC4NCg0KDQo+IA0KPiAyKSBJIHRoaW5rIHRoYXQgYSBkb3duZ3JhZGUgc29sdXRp b24gY2Fubm90IGJlIHN1ZmZpY2llbnRseSBjb21wbGV0ZSBmb3IgY2FzZXMgbGlrZSB0aGlzIHVu bGVzcyBpdCBpcyBhbGdvcml0aG1pYyAoZWc6IHVubWFwcGVkIHB1bnljb2RlL0FDRSkuDQo+IA0K PiBJIGNhbiB0aGluayBvZiBhIGZldyBjYXNlcyB3aGVyZSBldmVuIGFuIGFsZ29yaXRobWljIGRv d25ncmFkZSBtYXkgYnJlYWsgZG93biAodXNlciBjYW4ndCB0eXBlIHRoZSBsZXR0ZXJzLCBlbWFp bCBjbGllbnQgZG9lc24ndCBzdXBwb3J0IEVBSSwgYnV0IHRoYXQncyBhbGwgdGhlIHVzZXIgaGFz LCBhZGRyZXNzZXMgaW4gdGhlIHRleHQgYm9keSBvZiBhIG1lc3NhZ2UgKGVnOiBub3QgaW4gYSBo ZWFkZXIgc28gdGhleSBkaWRuJ3QgZ2V0IGRvd25ncmFkZWQpIGFuZCBubyBhdmFpbGFibGUgRUFJ IGNsaWVudCkgIFNvbWUgb2YgdGhvc2UgZG9uJ3QgYWx3YXlzIHdvcmsgdG9kYXkgdGhvdWdoLiAg U29tZSBjb3VsZCBiZSBtaXRpZ2F0ZWQgYnkgYW4gYWxnb3JpdGhtaWMgd2ViLWJhc2VkIG1hcHBp bmcgdG9vbC4NCj4gDQo+IE90aGVyIGF1dG9tYXRlZCBzeXN0ZW1zIGJlc2lkZXMgYWxnb3JpdGht aWMgd291bGQgaW5jbHVkZToNCj4gKiBBZGRyZXNzIHBhaXJpbmcsIGVpdGhlciBtdWx0aXBsZSBm cm9tLCBvciA8PD4+IHR5cGUgcGFpcnMuICA8PD4+IGRvZXNuJ3Qgd29yayBldmVyeXdoZXJlICht YWlsdG86KSBhbmQgYm90aCBnZXQgaGFyZCB0byBrZWVwIHRoZSBwYWlycyB0b2dldGhlci4gIFdl J3ZlIGFscmVhZHkgZm91bmQgbnVtZXJvdXMgcHJvYmxlbXMgd2l0aCB0aGVzZSBzY2hlbWVzLg0K PiANCj4gKiBNYXBwaW5ncyBxdWVyaWVkIGZyb20gdGhlIHNlcnZlci4gIENvbm5lY3Rpdml0eSBp c3N1ZXMgbWFrZSB0aGlzIGxlc3MgcmVsaWFibGUgdGhhbiBhbGdvcml0aG1pYyBtYXBwaW5ncy4g IChGaXJld2FsbHMsIHBvcnQgYmxvY2tpbmcsIGludGVybWl0dGVudCBuZXR3b3JrIGFjY2Vzcywg ZXRjLiwgbWFrZSB0aGF0IGxlc3Mgcm9idXN0LikgIEl0IGFsc28gc2VlbXMgbW9yZSBjb21wbGlj YXRlZCB0byBtZSBvbiB0aGUgc3VyZmFjZSB0byBpbXBsaW1lbnQuDQo+IA0KPiBBZ2FpbjogSSBk b24ndCB0aGluayB0aGF0IGFuIGFsZ29yaXRobWljIGZhbGxiYWNrIHNob3VsZCBiZSAicHJlZmVy cmVkIiBBU0NJSSBtYWlsYm94LiAgSSB0aGluayB0aGF0IGEgaHVtYW4gZnJpZW5kbHkgQVNDSUkg YWRkcmVzcyBpcyBuZWNlc3NhcnkgZm9yIG1hbnkgRUFJIGFjY291bnRzLiAgKEFsdGhvdWdoIEkg Y2FuIGltYWdpbmUgY2FzZXMgd2hlcmUgbWF5YmUgYSBidXNpbmVzcyBuZWVkcyBtdWx0aXBsZSBu b24tQVNDSUkgc2NyaXB0IGFkZHJlc3NlcyBhcyB3ZWxsLiAgU2F5IE1vbmdvbGlhbiArIENoaW5l c2UuICBPciBDaGluZXNlICsgQXJhYmljLikgIEFueXdheSwgbXkgcHJvcG9zZWQgYWxnb3JpdGht aWMgbWFwcGluZyBpcyBhIHdvcnN0LWNhc2UgbWFjaGluZSBmYWxsYmFjayBhZGRyZXNzLg0KPiAN Cj4gQWJvdXQgdGhlIG9ubHkgcHJvYmxlbSBJIGNhbiBzZWUgd2l0aCBhbiBhbGdvcml0aG1pYyB0 ZWNobmlxdWUgaXMgdGhhdCB1c2VycyB3b3VsZCBoYXZlIDMgYWxpYXNlcyBmb3IgdGhlIHNhbWUg bWFpbGJveCwgaG93ZXZlciBhbnkgRUFJIGF3YXJlIGFwcCBzaG91bGQgYmUgYWJsZSB0byBkaXNj b3ZlciB0aGF0IHRoZSBhbGdvcml0aG1pYyBBU0NJSSBhZGRyZXNzIGFuZCB0aGUgVW5pY29kZSBh ZGRyZXNzIGFyZSBlcXVpdmlsZW50Lg0KPiANCg0Kb3RoZXIgcHJvYmxlbXMgd2l0aCBhbGdvcml0 aG1pYyB0ZWNobmlxdWUgY2FuIGJlIGZvdW5kIGluIHRoZSBlYXJsaWVyIEVBSSBkcmFmdCB3cml0 dGVuIGJ5IEpvaG4uIA0KDQoNCj4gRldJVzogQW4gYWxnb3JpdGhtaWMgYWxpYXMgbmVlZCBub3Qg cmVwbGFjZSBvdGhlciBmYWxsYmFjayB0ZWNobmlxdWVzLCB0aG91Z2ggSSdtIG5vdCBzdXJlIHRo ZXknZCBhZGQgbXVjaCB2YWx1ZSBpZiB0aGVyZSB3YXMgYSB3ZWxsIGtub3duIGFsZ29yaXRobWlj IGFwcHJvYWNoLg0KPiANCj4gQXQgbGVhc3QgMiB2ZW5kb3JzIHRoYXQgb3duIGJvdGggc2VydmVy cyBhbmQgY2xpZW50cyB0aGF0IGFyZSBpbmRlcGVuZGVudGx5IGNvbnNpZGVyaW5nIGFsZ29yaXRo bWljIGdlbmVyYXRpb24gb2YgQVNDSUkgYWxpYXNlcyBqdXN0IGJlY2F1c2UgaXQncyBlYXN5IGZv ciB0aGVtIGludGVybmFsbHkuICAoTm90IHRoYXQgdGhleSdkIG5lY2Vzc2FyaWx5IGludGVyb3Bl cmF0ZS4pICBJdCdzIG5vdCBjbGVhciBpZiBlaXRoZXIgd291bGQgcHJvdmlkZSBhZGRpdGlvbmFs IGh1bWFuIGZyaWVuZGx5IGFsaWFzZXMuDQo+IA0KPiBJZiBhIGh5cG90aGV0aWNhbCAic2hhd25N YWlsIiBob3N0ZWQgbWFpbGJveGVzIHdpdGggdGhpcyB0ZWNobmlxdWUgYW5kIGFsc28gcHJvdmlk ZWQgd2ViIGNsaWVudCBhY2Nlc3MsIGl0J2QgYmUgYSBmYWlybHkgY29tcGxldGUgY2xvc2VkIHNv bHV0aW9uLiAgSWYgaXQgd2FzIG9uZSBvZiB0aGUgYmlnIG1haWwgcHJvdmlkZXJzLCBJIGNvdWxk IGVhc2lseSBpbWFnaW5lIDNyZCBwYXJ0eSBvciBvcGVuIHNvdXJjZSBjbGllbnRzIGFkZGluZyBz aW1pbGFyIHN1cHBvcnQgb3Igc3VwcG9ydGluZyBtYWpvciBwcm92aWRlcnMnIGFsZ29yaXRobXMg YXMgYSBjb21wZXRpdGl2ZSBvciBjb252ZW5pZW5jZSBmZWF0dXJlLiAgUmF0aGVyIHRoYW4gaGF2 aW5nIDUgZGlmZmVyZW50IGFsZ29yaXRobXMgZm9yIG1ham9yIHByb3ZpZGVycywgaXQnZCBiZSBu aWNlIGlmIHRoZXJlIHdhcyBhIGNvbW1vbiB0ZWNobmlxdWUuDQo+IA0KPiBFdmVuIGlmIGFsZ29y aXRobWljIGFsaWFzIGdlbmVyYXRpb24gd2Fzbid0IGEgTVVTVCBvciBmb3JtYWwgcGFydCBvZiB0 aGUgc3BlYywgaXQnZCBiZSBuaWNlIGlmIHRoZXJlIHdhcyBhIGNvbW1vbiBhbGdvcml0aG0gcHJv dmlkZXJzIE1BWSB1c2UgaWYgdGhleSB0aGluayB0aGF0IGFwcHJvYWNoIGlzIGludGVyZXN0aW5n Lg0KPiANCg0KQXMgZmFyIGFzIEkga25vdywgIHdlIGNhbiBub3QgZmluZCB0aGUgYXV0b21hdGNp IGFsZ29yaXRobSBzdWNoIGFzIHB1bnljb2RlIHdoaWNoICBjYW4gcHJvZHVjZSBib3RoIHRoZSAg dXNlciBmcmllbmRseSBhbmQgZ2xvYmFsIHVuaXF1ZSBhZGRyZXNzLg0KaWYgdGhlcmUgaXMgYSBv bmUsIHRoZXJlIHdpbGwgIGJlIGZpbmUuIHVuZm9ydHVuYXRlbHksIHRoZXJlIGlzIG5vbmUgYWNj b3JkaW5nIHRvIHRoZSBjdXJyZW50IHJlc2VhcmNoLg0KDQpZYW8gSmlhbmthbmcNCg0KDQoNCj4g LVNoYXduDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ== From harald@alvestrand.no Mon Sep 14 03:08:02 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A013A6A10 for ; Mon, 14 Sep 2009 03:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Cj8GFA2+TP for ; Mon, 14 Sep 2009 03:08:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id E769E3A69F7 for ; Mon, 14 Sep 2009 03:08:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E43D39E162; Mon, 14 Sep 2009 11:51:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DP+aXjkRFBJ; Mon, 14 Sep 2009 11:51:36 +0200 (CEST) Received: from [192.168.1.245] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 274D139E116; Mon, 14 Sep 2009 11:51:36 +0200 (CEST) Message-ID: <4AAE11DE.5030608@alvestrand.no> Date: Mon, 14 Sep 2009 11:50:22 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Shawn Steele References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 10:08:02 -0000 The overarching issue found with variants of this proposal previously rejected was: Can we guarantee (for a sufficiently strong version of "guarantee") that there are no valid mailboxes that "just happen to look like" the Punycoded strings? If not, we have to stick with the "don't mess with the left-hand side" principle and not let the specs define any upgrading, ever. (But then, if all home systems for the email recognized the Punycoded form, there isn't much reason to upgrade. But (3rd level) then that's a burden they'll have to carry around roughly forever..... more levels?) IDNA made the leap of faith that no existing application would be inconvenienced if we assumed that no domain name label starting "xn--" existed with any other use than IDNA. What assumption can we make? Harald (who was around when X.400 LHS encoding met Sendmail). Shawn Steele wrote: > I'm going to take a couple steps back. Mostly I'm focusing on the local part of the address, and I think there's a solution to get us unstuck. > > A lot of background. At a high level there are really only a few requirements: > > * We need Unicode addresses (That's the point of EAI after all :) > * Many people still need a user friendly ASCII address, for the English side of a Japanese business card if nothing else. > * Some sort of "downgrade" must exist for backwards compatibility. I'm being liberal with the term. "Downgrade" could be a user trying Unicode and then retrying with ASCII if necessary, or just giving out ASCII because they know EAI won't work in some scenario. > > 1) We need Unicode addresses. > The Unicode address is solved reasonably well by UTF-8 and the existing RFCs. UTF-8 also solves a myriad of problems regarding code pages in the rest of the message, but that's not specifically an EAI issue. > > 2) Friendly ASCII addresses. > Friendly ASCII addresses are pretty much a non-issue since mailbox aliases are a common mail feature. (I get mail to shawnste & Shawn.Steele) I make the small assumption that aliasing would be extended to Unicode and that aliases will be more common in an EAI world. This probably primarily impacts mailbox administration tools. > > 3) Downgrade > So that leaves downgrade. Downgrade is necessary for a "transition" period, which is probably many years. Note that there's no technical requirement that downgrade use the friendly ASCII address mechanism. It is also worth mentioning that downgrade necessarily requires an EAI aware system (even if it's "just" human downgrade, the human has to be aware of the issue) to do the downgrade. > > There are also various degrees of downgrade: > > * Human-only downgrade with no automated mechanism. If my mail bounces I try a different address. Some big problems are that I may not know the other address, I may not know how to send From: an ASCII address, and some systems may accept mail they can't reply to. > > * Partially automated downgrade. This could be something like From:, or the older headers or something else that doesn't provide the same experience in a mixed environment as in a legacy or EAI only environment. Eg: simple mail may work, but DL's, newsgroups, reply-to, or other cases could get tricky or fail. > > Some big problems with partial downgrade are that it is partial, so user's may think mail works, but get unexpected failures in edge cases. Also (depending on the degree of "partial"), it may fail if the fallback address(es) aren't know or configured correctly. Also some mail may appear to succeed but may not be able to be replied to. > > * Fully automated downgrade. This would be some magic system that would downgrade all headers so that "everything" worked, including mailing lists, etc. In addition to the problem of discovering the downgrade address, we've run into numerous technical concerns and edge cases with the solutions investigated so far. > > I've been flip-flopping on how much downgrade is necessary. > > Human-only downgrade: > I think it's possible that a human-only mechanism may "work", although that may slow EAI adoption significantly. (If I don't think my EAI address'll work, then I'll only give out my ASCII address, then why bother with EAI?) > > Partially automated downgrade: > Personally I don't see much point in partially automated downgrade (folks from Exchange & Outlook agree.) If my mail to you works, and your replies work, but everything breaks when I send to a DL or newsgroup, then it's almost worse. > > Fully automated downgrade: > Fully automated downgrade would be cool, but we've pretty much proved that it's impossible. Mostly because pairing the addresses breaks down in several cases, or because the syntax to make the pairing explicit breaks downlevel syntax. > > A possible solution: > > A while back Mark suggested an solution that's been discussed before and I rejected out of hand. Either I've had a paradigm shift in my thinking or I misunderstood Mark's earlier suggestion, however there is a way that allows fully automated downgrade without breaking any of the other ASCII address alias or UTF8SMTP behavior. It also only requires updating the EAI aware servers/clients. Unaware systems wouldn't see anything different, probably even mailing lists. Upgrade is even supported. > > Mark's suggestion (or my modification of it) is something like this: > > * Everyone that wants one gets a Unicode address, and a human friendly ASCII alias (if desired). > * When people exchange addresses in written form, they can use Unicode if they think the recipient is EAI aware, or they can use the ASCII address. > * Mail with EAI to EAI and the Unicode address works as spec'd for UTF8SMTP, etc. No extra fields are sent. > * When a human or form isn't expecting Unicode, the user shares the human-friendly ASCII alias. Then the ASCII to EAI server behaves as normal. No extra fields are sent. > * When an EAI server (or client) hits an EAI unaware system, the message is downgraded. Addresses are downgraded by using unmapped punycode, which is algorithmic, so it avoids all the address pairing problems. An EAI aware client app (like Outlook) could then upgrade the punycode if desired. Before downgrade a message is identical to the existing practice, just with UTF-8, and is non-breaking. After downgrade, a message is still identical to existing legacy behavior, so there's no breaking. > > By using UNMAPPED punycode (raw ACE encoding), servers can control their own mappings (Turkish I or whatever's interesting to them). Presumably they'd decode back to Unicode, then do their mapping and routing. The problems that downgrade had with mailing lists is avoided because all addresses could be downgraded at any point. Additionally a ASCII-only mailbox user doesn't need an EAI aware server to use EAI because their EAI aware client could do the mapping. > > To me, the differences between this and previous punycode proposals (maybe I misunderstood them) are: > a) UTF-8 is preferred, and is the long term form, not punycode. > b) Human-readable ASCII aliases are a preferred method of exchange on the sticky note or whatnot. (Nobody's going to exchange a punycode address). > c) Punycode is only used for fallback, when UTF8STMP or other EAI protocols aren't recognized. > d) It isn't IDN punycode, but just unmapped Unicode that the server has to decode and map. > > The advantages are: > * Users get a Unicode address. > * Users still get a human friendly ASCII address as needed. > * There's a full downgrade capability (with upgrade if desired) > * Interoperability with legacy systems should be very high. > * No problems with pairing of the addresses. > * Works whenever an EAI-aware client/mailbox behave. Intermediate systems don't impact it, and an EAI aware recipient client can have an EAI experience even if they don’t have an EAI mailbox themselves. > * Only servers/clients upgraded to EAI need to be touched. Legacy systems in the middle will still behave. (I'm told by Exchange that it would take decades to upgrade everything). > * Mapping still happens by the mailbox server's rules. > * Algorithmic rules for downgrade mean that downgrade is always possible instead of requiring knowledge of the ASCII alias. > * Senders can downgrade (if the client is EAI aware) even with only a Unicode recipient address, even if their mail server is a legacy server. > > The disadvantages are: > * Non-EAI aware recipients would receive punycode addresses instead of human friendly ASCII. This is mitigated by the fact that most clients display the display name. > * Punycode downgrade requires that EAI aware systems know the punycode mapping. This is mitigated by reducing the complexity of the other pairing schemes. > * EAI mailbox servers have to unmap the Punycode to Unicode before doing any mapping to find the mailbox. (Aliases might work in some cases, but you'd still want case mapping probably). > * For systems that don't need EAI (eg: many US mail servers) there's reduced incentive to upgrade to be EAI aware since an EAI aware client is sufficient. This could delay complete adoption. (It's also an advantage that could speed up early adoption.) > * Three addresses (Unicode, ASCII, Punycode) instead of 2 (though the Punycode is just an encoded form of the Unicode). > > Couple minor comments: > * As I said, the punycode should be unmapped ACE, not IDN form. > * To make that clear, I'd pick a different prefix, or some other signature mechanism. (My fear is that developers would accidentally call the IDN APIs and get inappropriate mappings). > > I know we've discussed Punycode before, but I think the difference is that I'm suggesting it as a last-resort case, not as a replacement for UTF8SMTP, nor a replacement for the human friendly ASCII aliases. > > Please note that I am very much against Punycode as a solution for EAI (eg: replacing UTF-8). By itself as a long-term solution Punycode has huge problems. I think it has a place a "hack" to solve downgrade though. > > If necessary to further discussion I could put this in draft form. > > -Shawn > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From Shawn.Steele@microsoft.com Mon Sep 14 09:46:39 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225C63A681D for ; Mon, 14 Sep 2009 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-3gm6YyKTae for ; Mon, 14 Sep 2009 09:46:38 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 68A403A686E for ; Mon, 14 Sep 2009 09:46:38 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Sep 2009 09:47:23 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Mon, 14 Sep 2009 09:47:22 -0700 From: Shawn Steele To: Harald Alvestrand Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNSEJ/2Jg2W1k4k2n/aUL3Uziq5DWSmSd Date: Mon, 14 Sep 2009 16:47:22 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> , <4AAE11DE.5030608@alvestrand.no> In-Reply-To: <4AAE11DE.5030608@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?TWFyayBEYXZpcyDijJs=?= , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 16:46:39 -0000 PiBJRE5BIG1hZGUgdGhlIGxlYXAgb2YgZmFpdGggdGhhdCBubyBleGlzdGluZyBhcHBsaWNhdGlv biB3b3VsZCBiZQ0KPiBpbmNvbnZlbmllbmNlZCBpZiB3ZSBhc3N1bWVkIHRoYXQgbm8gZG9tYWlu IG5hbWUgbGFiZWwgc3RhcnRpbmcgInhuLS0iDQo+IGV4aXN0ZWQgd2l0aCBhbnkgb3RoZXIgdXNl IHRoYW4gSUROQS4NCg0KPiBXaGF0IGFzc3VtcHRpb24gY2FuIHdlIG1ha2U/DQoNCkl0IHNlZW1z IHVubGlrZWx5IHRoYXQgbWFpbGJveGVzIHN0YXJ0IHdpdGggeG4tLSwgdGhvdWdoIG90aGVyIHZh bHVlcyBjb3VsZCBtYXliZSBiZSB1c2VkLiAgU2hvdWxkIHN1Y2ggYW4gYWRkcmVzcyBhbHJlYWR5 IGJlIHVzZWQsIEkgc3VnZ2VzdCB0aGF0IGl0IGlzIGVzb3RlcmljIGVub3VnaCB0aGF0IHN1Y2gg ZXhpc3RpbmcgdXNhZ2Ugc2hvdWxkbid0IHBlbmFsaXplIHRoZSByZXN0IG9mIHRoZSBJbnRlcm5l dCBtb3ZpbmcgZm9yd2FyZC4gIEFkZGl0aW9uYWxseSwgaXQnbGwgcHJvYmFibHkgc3RpbGwgIndv cmsiLCB0aG91Z2ggc29tZSBjbGllbnRzIG1pZ2h0IHJlbmRlciBpdCBmdW5ueS4NCg0KTXkgZWFy bGllciBvYmplY3Rpb25zIGhhZCBub3RoaW5nIHRvIGRvIHdpdGggImRvZXMgYSBtYWlsYm94IGxv b2tpbmcgbGlrZSB0aGF0IGFscmVhZHkgaGFwcGVuIHRvIGV4aXN0IiwgYnV0IHJhdGhlcjoNCiog UHVueWNvZGUgaXMgTk9UIGh1bWFuLWZyaWVuZGx5Lg0KKiBVVEYtOCBvbiB0aGUgd2lyZSBpcyBt dWNoIGNsZWFuZXIuDQoNCk15IHNoaWZ0IGluIHRoaW5raW5nIGlzIHRoYXQgVVRGLTggb24gdGhl IHdpcmUgaXMgc3RpbGwgc3Ryb25nbHkgcHJlZmVycmVkLCBhbmQgdGhhdCBhIGh1bWFuLWZyaWVu ZGx5IGFkZHJlc3MgaXMgYWxzbyByZXF1aXJlZC4NCg0KLVNoYXdu From yaojk@cnnic.cn Mon Sep 14 19:22:30 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C16A3A68CE for ; Mon, 14 Sep 2009 19:22:30 -0700 (PDT) X-Quarantine-ID: <2yEQxi0kJPK1> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=1.536, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yEQxi0kJPK1 for ; Mon, 14 Sep 2009 19:22:29 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id BC56E3A682A for ; Mon, 14 Sep 2009 19:22:28 -0700 (PDT) Received: (eyou send program); Tue, 15 Sep 2009 10:23:13 +0800 Message-ID: <452981393.27052@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 15 Sep 2009 10:23:13 +0800 Message-ID: <023101ca35ab$78c952a0$ad6df1da@whatisfuture> From: "YAO Jiankang" To: "Shawn Steele" , "Harald Alvestrand" References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info>, <4AA7A649.5000903@ca.afilias.info><4AA7F35E.7080906@ca.afilias.info>, <4AAE11DE.5030608@alvestrand.no> <452946849.07535@cnnic.cn> Date: Tue, 15 Sep 2009 10:23:11 +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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: =?UTF-8?Q?Mark_Davis_=E2=8C=9B?= , ima@ietf.org Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 02:22:30 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNoYXduIFN0ZWVsZSIgPFNo YXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPg0KVG86ICJIYXJhbGQgQWx2ZXN0cmFuZCIgPGhhcmFs ZEBhbHZlc3RyYW5kLm5vPg0KQ2M6ICJNYXJrIERhdmlzIOKMmyIgPG1hcmtAbWFjY2hpYXRvLmNv bT47IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMDkgMTI6 NDcgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBUaGlua2luZyBhYm91dCByZXF1aXJlbWVudHMgLyBk b3duZ3JhZGUNCg0KDQo+PiBJRE5BIG1hZGUgdGhlIGxlYXAgb2YgZmFpdGggdGhhdCBubyBleGlz dGluZyBhcHBsaWNhdGlvbiB3b3VsZCBiZQ0KPj4gaW5jb252ZW5pZW5jZWQgaWYgd2UgYXNzdW1l ZCB0aGF0IG5vIGRvbWFpbiBuYW1lIGxhYmVsIHN0YXJ0aW5nICJ4bi0tIg0KPj4gZXhpc3RlZCB3 aXRoIGFueSBvdGhlciB1c2UgdGhhbiBJRE5BLg0KPiANCj4+IFdoYXQgYXNzdW1wdGlvbiBjYW4g d2UgbWFrZT8NCj4gDQo+IEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgbWFpbGJveGVzIHN0YXJ0IHdp dGggeG4tLSwgdGhvdWdoIG90aGVyIHZhbHVlcyBjb3VsZCBtYXliZSBiZSB1c2VkLiAgU2hvdWxk IHN1Y2ggYW4gYWRkcmVzcyBhbHJlYWR5IGJlIHVzZWQsIEkgc3VnZ2VzdCB0aGF0IGl0IGlzIGVz b3RlcmljID5lbm91Z2ggdGhhdCBzdWNoIGV4aXN0aW5nIHVzYWdlIHNob3VsZG4ndCBwZW5hbGl6 ZSB0aGUgcmVzdCBvZiB0aGUgSW50ZXJuZXQgbW92aW5nIGZvcndhcmQuICBBZGRpdGlvbmFsbHks IGl0J2xsIHByb2JhYmx5IHN0aWxsICJ3b3JrIiwgdGhvdWdoIHNvbWUgY2xpZW50cyBtaWdodCBy ZW5kZXIgPml0IGZ1bm55Lg0KDQphc3N1bXB0aW9uIGlzIGp1c3QgYSBhc3N1bXB0aW9uLiBuZXZl ciBjb21lcyB0cnVlLiBpZiB3ZSBtb3ZlIGZvcndhcmQgd2l0aG91dCBjb25zaWRlcmluZyB0aGUg ICJlc290ZXJpYyIgb25lLA0KdGhlIHByb3RvY29sIG1pZ2h0IG5vdCBydW4gcHJvcGVybHkuIGlm IHlvdSBoYXZlIGEgdXRmLTggYWRkcmVzcyBhbmQgcHJvZHVjZSBhIGF1dG9tYWljIEFDRSBhZGRy ZXNzIHdoaWNoIGhhcHBlbnMgdG8gYmUgdGhlcmUgYWxyZWFkeSwgd2hhdCB3aWxsIGhhcHBlbj8N ClRoYXQgbWVhbnMgdGhhdCB0aGUgZGlmZmVyZW50IGFjY291bnRzIGJ1dCBlcXVhbGVudCB3aWxs ICBiZWxvbmcgdG8gdGhlIGRpZmZlcmVudCB1c2Vycy4NCiBJIHJlbWVtYmVyIHRoYXQgd2h5IHRo aXMgV0cgZG9lcyBub3QgY2hvb3NlIHRoZSBhdXRvbWFpYyBhbGdvcml0aG0gdG8gcHJvZHVjZSB0 aGUgYWx0LWFkZHJlc3MgaGFzIGJlZW4gZGlzY3Vzc2VkIHNldnJhbCB0aW1lcy4gSXQgc2VlbXMg dGhhdCB3ZSByZXR1cm4gYWdhaW4uDQoNCj4gDQo+IE15IGVhcmxpZXIgb2JqZWN0aW9ucyBoYWQg bm90aGluZyB0byBkbyB3aXRoICJkb2VzIGEgbWFpbGJveCBsb29raW5nIGxpa2UgdGhhdCBhbHJl YWR5IGhhcHBlbiB0byBleGlzdCIsIGJ1dCByYXRoZXI6DQo+ICogUHVueWNvZGUgaXMgTk9UIGh1 bWFuLWZyaWVuZGx5Lg0KKzENCg0KPiAqIFVURi04IG9uIHRoZSB3aXJlIGlzIG11Y2ggY2xlYW5l ci4NCg0KKzENCg0KPiANCj4gTXkgc2hpZnQgaW4gdGhpbmtpbmcgaXMgdGhhdCBVVEYtOCBvbiB0 aGUgd2lyZSBpcyBzdGlsbCBzdHJvbmdseSBwcmVmZXJyZWQsIGFuZCB0aGF0IGEgaHVtYW4tZnJp ZW5kbHkgYWRkcmVzcyBpcyBhbHNvIHJlcXVpcmVkLg0KDQorMQ0KDQp0aGUgcHJvYmxlbSBpcyB0 aGF0IHdlIGNhbiBub3QgZmluZCB0aGUgaHVtYW4tZnJpZW5kbHkgYWRkcmVzcyBlYXNpbHkuDQoN CmFsaWFzIHdheSBtaWdodCBiZSBhIHNvbHV0aW9uLiBidXQgaXQgc2VlbXMgdGhhdCBhbGlhcyB3 YXkgbWlnaHQgaGF2ZSBzb21lIG90aGVyIHByb2JsZW1zLiANCg0KWWFvIEppYW5rYW5nDQoNCg0K PiANCj4gLVNoYXduDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From Shawn.Steele@microsoft.com Tue Sep 15 09:45:58 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347D23A6AA7 for ; Tue, 15 Sep 2009 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.426 X-Spam-Level: X-Spam-Status: No, score=-10.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyYhzaS28a58 for ; Tue, 15 Sep 2009 09:45:57 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4763D3A6A4D for ; Tue, 15 Sep 2009 09:45:57 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Sep 2009 09:46:44 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Tue, 15 Sep 2009 09:46:44 -0700 From: Shawn Steele To: YAO Jiankang , Harald Alvestrand Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNSEJ/2Jg2W1k4k2n/aUL3Uziq5DW7MtzgADwF9k= Date: Tue, 15 Sep 2009 16:42:54 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info>, <4AA7A649.5000903@ca.afilias.info><4AA7F35E.7080906@ca.afilias.info>, <4AAE11DE.5030608@alvestrand.no> <452946849.07535@cnnic.cn>, <023101ca35ab$78c952a0$ad6df1da@whatisfuture> In-Reply-To: <023101ca35ab$78c952a0$ad6df1da@whatisfuture> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?TWFyayBEYXZpcyDijJs=?= , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 16:45:58 -0000 PiBhc3N1bXB0aW9uIGlzIGp1c3QgYSBhc3N1bXB0aW9uLiBuZXZlciBjb21lcyB0cnVlLiBpZiB3 ZSBtb3ZlIGZvcndhcmQgd2l0aG91dCBjb25zaWRlcmluZyB0aGUgICJlc290ZXJpYyIgb25lLA0K PiB0aGUgcHJvdG9jb2wgbWlnaHQgbm90IHJ1biBwcm9wZXJseS4gaWYgeW91IGhhdmUgYSB1dGYt OCBhZGRyZXNzIGFuZCBwcm9kdWNlIGEgYXV0b21haWMgQUNFIGFkZHJlc3Mgd2hpY2gNCj4gaGFw cGVucyB0byBiZSB0aGVyZSBhbHJlYWR5LCB3aGF0IHdpbGwgaGFwcGVuPw0KDQpXb3JzdCBjYXNl IEknZCBpbWFnaW5lIHRoYXQgaXQnZCBnZXQgY29udmVydGVkIHRvIFVuaWNvZGUgZm9yIGRpc3Bs YXkuICBJdCBzaG91bGQgc3RpbGwgIndvcmsiICBJJ3ZlIG5ldmVyIHNlZW4gYW4gYWRkcmVzcyB0 aGF0IGxvb2tzIGFueXRoaW5nIGxpa2UgeG4tLSwgYW5kIHdoaWxlIHRoYXQgaXNuJ3Qgc2F5aW5n IG11Y2gsIGl0IHNlZW1zIHRoYXQgaXQnZCBiZSB3b3J0aCB0aGUgcmlzayB0byB3aGF0ZXZlciBk b2VzIHVzZSB4bi0tIHRvIG1ha2UgcHJvZ3Jlc3MgdG93YXJkcyBVbmljb2RlIGVtYWlsLg0KDQo+ IFRoYXQgbWVhbnMgdGhhdCB0aGUgZGlmZmVyZW50IGFjY291bnRzIGJ1dCBlcXVhbGVudCB3aWxs ICBiZWxvbmcgdG8gdGhlIGRpZmZlcmVudCB1c2Vycy4NCg0KVGhhdCdzIGRvZXNuJ3Qgc2VlbSBw b3NzaWJsZS4gIElmIHdlIHVzZWQgeG4tLSwgdGhlbiBpdCdkIG9ubHkgYmUgc3ViamVjdCB0b3Ro ZSBkaWZmZXJlbnQgYWNjb3VudHMgY29uZGl0aW9uIGlmIHRoZSBsZWdhY3kgeG4tLSBtYWlsIHN5 c3RlbSB3ZXJlIHVwZ3JhZGVkIHRvIHN1cHBvcnQgRUFJLiAgSW4gdGhhdCBjYXNlIHRoZSBhZG1p bmlzdHJhdG9yIHdvdWxkIG5lY2Vzc2FyaWx5IGVpdGhlciBwcm9oaWJpdCBuZXcgbWFpbGJveGVz IHRoYXQgbWF0Y2hlZCB4bi0tLCBvciBjaGFuZ2UgdGhlIGV4aXN0aW5nIHhuLS0gYWRkcmVzc2Vz Lg0KDQotU2hhd24= From edainow@ca.afilias.info Tue Sep 15 15:17:46 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B813A6B0A for ; Tue, 15 Sep 2009 15:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsDxjqu5Fu1k for ; Tue, 15 Sep 2009 15:17:45 -0700 (PDT) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id 45C5D3A68EF for ; Tue, 15 Sep 2009 15:17:45 -0700 (PDT) Received: from edainow.tor.afilias-int.info ([10.10.68.27]) by tor-gateway.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MngLs-0002nz-9D; Tue, 15 Sep 2009 18:18:20 -0400 Message-ID: <4AB01389.6030607@ca.afilias.info> Date: Tue, 15 Sep 2009 18:22:01 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Harald Alvestrand References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> In-Reply-To: <4AAE11DE.5030608@alvestrand.no> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= , Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 22:17:46 -0000
Harald Alvestrand wrote:
The overarching issue found with variants of this proposal previously rejected was:

Can we guarantee (for a sufficiently strong version of "guarantee") that there are no valid mailboxes that "just happen to look like" the Punycoded strings?
I'm not sure it is necessary for a standard to guarantee this. I think it is just the responsibility of email administration to avoid name collisions. Currently, when a new email address is requested, the email administrator for the domain on which the name is requested (or email admin software) will not grant the email address if
1. the address (local name) is assigned to someone else on the domain.
2. the address is already in use as an alias on another email account on the domain.

Suppose EAI used automatic punycode email addresses, where punycode conversion is applied separately to each side of the @. Then email administrators on EAI systems just have the following additional verification to do on new email account requests:
3. generate the punycode of the new address (local name) and apply tests 1 and 2 above to make sure the punycode name is not in use on the domain.

Since only owners of a domain can create email addresses, name collisions cannot occur unless administrators fail to check for uniqueness before granting new email addresses. That requirement is no different from today.

Another concern about using ACE conversions in EAI was the issue of punycode addresses "leaking" into the user environment. Just to remind people how ugly this can be, here is a conversion of one of the EAI addresses used in one of the downgrade tests.
<xn--qxa.xn--mxafqqky@xn----vlbebiih2aiue6addbz1awu3bzg.info>


If not, we have to stick with the "don't mess with the left-hand side" principle and not let the specs define any upgrading, ever. (But then, if all home systems for the email recognized the Punycoded form, there isn't much reason to upgrade. But (3rd level) then that's a burden they'll have to carry around roughly forever..... more levels?)
I think receiving a lot of email with long unrecognizable ACE conversions might be incentive for people to upgrade to EAI.

IDNA made the leap of faith that no existing application would be inconvenienced if we assumed that no domain name label starting "xn--" existed with any other use than IDNA.
Email administrators can avoid local name collisions as outlined above. This assumption is also important to EAI to avoid collusions on the domain name.

What assumption can we make?

                         Harald (who was around when X.400 LHS encoding met Sendmail).

From yaojk@cnnic.cn Tue Sep 15 20:26:23 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1183A682D for ; Tue, 15 Sep 2009 20:26:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.883 X-Spam-Level: X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5+gdtCRB-9k for ; Tue, 15 Sep 2009 20:26:22 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id CECB93A635F for ; Tue, 15 Sep 2009 20:26:21 -0700 (PDT) Received: (eyou send program); Wed, 16 Sep 2009 11:26:59 +0800 Message-ID: <453071619.02711@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 16 Sep 2009 11:26:59 +0800 Message-ID: <145501ca367d$8c50d500$ad6df1da@whatisfuture> From: "YAO Jiankang" To: "Shawn Steele" , "Harald Alvestrand" References: <04EA2C8DA30B414374C673EB@PST.JCK.COM><4AA6CCBB.1070804@ca.afilias.info>, <4AA7A649.5000903@ca.afilias.info><4AA7F35E.7080906@ca.afilias.info>, <4AAE11DE.5030608@alvestrand.no> <452946849.07535@cnnic.cn>, <023101ca35ab$78c952a0$ad6df1da@whatisfuture> <453033209.25050@cnnic.cn> Date: Wed, 16 Sep 2009 11:24:48 +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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: =?UTF-8?Q?Mark_Davis_=E2=8C=9B?= , ima@ietf.org Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 03:26:23 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNoYXduIFN0ZWVsZSIgPFNo YXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPg0KVG86ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5p Yy5jbj47ICJIYXJhbGQgQWx2ZXN0cmFuZCIgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPg0KQ2M6ICJN YXJrIERhdmlzIOKMmyIgPG1hcmtAbWFjY2hpYXRvLmNvbT47IDxpbWFAaWV0Zi5vcmc+DQpTZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNiwgMjAwOSAxMjo0MiBBTQ0KU3ViamVjdDogUkU6IFtF QUldIFRoaW5raW5nIGFib3V0IHJlcXVpcmVtZW50cyAvIGRvd25ncmFkZQ0KDQoNCj4+IGFzc3Vt cHRpb24gaXMganVzdCBhIGFzc3VtcHRpb24uIG5ldmVyIGNvbWVzIHRydWUuIGlmIHdlIG1vdmUg Zm9yd2FyZCB3aXRob3V0IGNvbnNpZGVyaW5nIHRoZSAgImVzb3RlcmljIiBvbmUsDQo+PiB0aGUg cHJvdG9jb2wgbWlnaHQgbm90IHJ1biBwcm9wZXJseS4gaWYgeW91IGhhdmUgYSB1dGYtOCBhZGRy ZXNzIGFuZCBwcm9kdWNlIGEgYXV0b21haWMgQUNFIGFkZHJlc3Mgd2hpY2gNCj4+IGhhcHBlbnMg dG8gYmUgdGhlcmUgYWxyZWFkeSwgd2hhdCB3aWxsIGhhcHBlbj8NCj4gDQo+IFdvcnN0IGNhc2Ug SSdkIGltYWdpbmUgdGhhdCBpdCdkIGdldCBjb252ZXJ0ZWQgdG8gVW5pY29kZSBmb3IgZGlzcGxh eS4gIEl0IHNob3VsZCBzdGlsbCAid29yayIgIEkndmUgbmV2ZXIgc2VlbiBhbiBhZGRyZXNzIHRo YXQgbG9va3MgYW55dGhpbmcgbGlrZSB4bi0tLCBhbmQgd2hpbGUgPnRoYXQgaXNuJ3Qgc2F5aW5n IG11Y2gsIGl0IHNlZW1zIHRoYXQgaXQnZCBiZSB3b3J0aCB0aGUgcmlzayB0byB3aGF0ZXZlciBk b2VzIHVzZSB4bi0tIHRvIG1ha2UgcHJvZ3Jlc3MgdG93YXJkcyBVbmljb2RlIGVtYWlsLg0KDQpt YXliZSwgeG4tLSBpc24ndCBzYXlpbmcgbXVjaCBmb3IgZW5nbGlzaC4gIGJ1dCBpbiBDaGluZXNl IFBpbmd5aW4sIFhOIGNhbiBzdGFuZGFyZCBhIGNpdHkgbmFtZSAiWGkgTmluZyIgd2hpY2ggaXMg YSBjYXBpdGFsIGNpdHkgb2YgcHJvdmluY2UuDQoNCklmIEkgYW0gZnJvbSBYaSBOaW5nLCBzbyBJ IGNhbiBuYW1lIG15IG1haWxib3ggc3VjaCBhcyBYbi0teWFvLCB3aGlsZSBYbiBzdGFuZGFyZHMg Zm9yIHRoZSBjaXR5IG5hbWUsIC0tIGFzIHRoZSBzZXBhcmF0b3IsIGFuZCB5YW8gYXMgbXkgZmFt aWx5IG5hbWUuDQoNCnNvIHhuLS15YW9AY25uaWMuY24gIGhhcyBhIGxvdCBvZiBtZWFuaW5nLiB5 b3UgbWlnaHQgbm90IHNlZSBzdWNoIG5hbWUgaW4geW91ciBsaWZlLCBidXQgeW91IGNhbiBub3Qg cHJvdmUgdGhhdCBpdCBtaWdodCBiZSB0aGVyZS4NCg0KDQoNCj4gDQo+PiBUaGF0IG1lYW5zIHRo YXQgdGhlIGRpZmZlcmVudCBhY2NvdW50cyBidXQgZXF1YWxlbnQgd2lsbCAgYmVsb25nIHRvIHRo ZSBkaWZmZXJlbnQgdXNlcnMuDQo+IA0KPiBUaGF0J3MgZG9lc24ndCBzZWVtIHBvc3NpYmxlLiAg SWYgd2UgdXNlZCB4bi0tLCB0aGVuIGl0J2Qgb25seSBiZSBzdWJqZWN0IHRvdGhlIGRpZmZlcmVu dCBhY2NvdW50cyBjb25kaXRpb24gaWYgdGhlIGxlZ2FjeSB4bi0tIG1haWwgc3lzdGVtIHdlcmUg dXBncmFkZWQgdG8gPnN1cHBvcnQgRUFJLiAgSW4gdGhhdCBjYXNlIHRoZSBhZG1pbmlzdHJhdG9y IHdvdWxkIG5lY2Vzc2FyaWx5IGVpdGhlciBwcm9oaWJpdCBuZXcgbWFpbGJveGVzIHRoYXQgbWF0 Y2hlZCB4bi0tLCBvciBjaGFuZ2UgdGhlIGV4aXN0aW5nIHhuLS0gYWRkcmVzc2VzLg0KPg0KDQp5 ZXMsIHRoZSBhZG1pbmlzdHJhdG9yIG9mIHRoZSBlbWFpbCBhY2NvdW50cyBjYW4gIHByb2hpYml0 IG5ldyBtYWlsYm94ZXMgdGhhdCBtYXRjaGVkIHhuLS0uIGJ1dCB5b3UgY2FuIG5vdCBwcm9oaWJp dCB0aGUgZW1haWwgdXNlciBjbGllbnQgYW5kIG90aGVyIG1haWwgc2VydmVycyB0byBkbyBzby4g VGhlIGltcGxlbWVudG9yIG9mIHRoZSBFQUkgcHJvdG9jb2xzIG1pZ2h0IGltcGxlbWVudCB0aGUg YXV0b21hdGljIGFsZ29yaXRobSB0byBwcm9kdWNlIHRoZSBhbHQtYWRkcmVzcy4gSG93IGRvZXMg dGhlIGltcGxlbWVudG9ycyBrbm93IHRoZSBleGNlcHRpb24gY2FzZT8gaWYgeW91IGhhdmUgYSB1 dGY4IGFkZHJlc3Mgd2hpY2ggaGFwcGVucyB0byBtYXAgdG8gdGhlIG90aGVyIHhuLS0gYWRkcmVz cyBpbnN0ZWFkIG9mICB0aGUgeG4tLSBhZGRyZXNzIHByb2R1Y2VkIGJ5IGF1dG9tYXRpYyBhbGdv cml0aG0sIGhvdyBkbyB0aGUgTVVBIGFuZCBvdGhlciBTTVRQIHNlcnZlcnMga25vdyBpdD8gIHRo ZXNlIE1VQSBvciBTTVRQIHNlcnZlcnMgbWlnaHQgc3RpbGwgdGhpbmsgdGhhdCAgeG4tLSBhZGRy ZXNzIHByb2R1Y2VkIGJ5IGF1dG9tYXRpYyBhbGdvcml0aG0gaXMgc3RpbGwgYSByaWdodCBvbmUg Zm9yIG1hcHBpbmcgdG8gdGhlIHVmOCBhZGRyZXNzLg0KDQoNCllhbyBKaWFua2FuZw0KQ05OSUMN Cg0KDQoNCj4gLVNoYXdu From yaojk@cnnic.cn Tue Sep 15 21:15:21 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54223A67E9 for ; Tue, 15 Sep 2009 21:15:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.965 X-Spam-Level: X-Spam-Status: No, score=0.965 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD1r0Tj6kuJm for ; Tue, 15 Sep 2009 21:15:21 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 712D93A67B4 for ; Tue, 15 Sep 2009 21:15:19 -0700 (PDT) Received: (eyou send program); Wed, 16 Sep 2009 12:16:07 +0800 Message-ID: <453074567.10858@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 16 Sep 2009 12:16:07 +0800 Message-ID: <14da01ca3684$690f6500$ad6df1da@whatisfuture> From: "YAO Jiankang" To: "Ernie Dainow" References: <453073879.17525@cnnic.cn> Date: Wed, 16 Sep 2009 12:16:04 +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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: =?UTF-8?Q?Mark_Davis_=E2=8C=9B?= , Shawn Steele , ima@ietf.org Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 04:15:21 -0000 DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206IEVybmllIERhaW5vdyAN Cj4gVG86IEhhcmFsZCBBbHZlc3RyYW5kIA0KPiBDYzogTWFyayBEYXZpcyDijJsgOyBTaGF3biBT dGVlbGUgOyBpbWFAaWV0Zi5vcmcgDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE2LCAy MDA5IDY6MjIgQU0NCj4gU3ViamVjdDogUmU6IFtFQUldIFRoaW5raW5nIGFib3V0IHJlcXVpcmVt ZW50cyAvIGRvd25ncmFkZQ0KPiANCj4gDQo+IA0KIA0KPiBJJ20gbm90IHN1cmUgaXQgaXMgbmVj ZXNzYXJ5IGZvciBhIHN0YW5kYXJkIHRvIGd1YXJhbnRlZSB0aGlzLiBJIHRoaW5rIGl0IGlzIGp1 c3QgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGVtYWlsIGFkbWluaXN0cmF0aW9uIHRvIGF2b2lkIG5h bWUgY29sbGlzaW9ucy4gQ3VycmVudGx5LCB3aGVuIGEgbmV3IGVtYWlsIGFkZHJlc3MgaXMgcmVx dWVzdGVkLCB0aGUgZW1haWwgYWRtaW5pc3RyYXRvciBmb3IgdGhlIGRvbWFpbiBvbiB3aGljaCB0 aGUgbmFtZSBpcyByZXF1ZXN0ZWQgKG9yIGVtYWlsIGFkbWluIHNvZnR3YXJlKSB3aWxsIG5vdCBn cmFudCB0aGUgZW1haWwgYWRkcmVzcyBpZg0KPiAxLiB0aGUgYWRkcmVzcyAobG9jYWwgbmFtZSkg aXMgYXNzaWduZWQgdG8gc29tZW9uZSBlbHNlIG9uIHRoZSBkb21haW4uDQo+IDIuIHRoZSBhZGRy ZXNzIGlzIGFscmVhZHkgaW4gdXNlIGFzIGFuIGFsaWFzIG9uIGFub3RoZXIgZW1haWwgYWNjb3Vu dCBvbiB0aGUgZG9tYWluLg0KPiANCj4gU3VwcG9zZSBFQUkgdXNlZCBhdXRvbWF0aWMgcHVueWNv ZGUgZW1haWwgYWRkcmVzc2VzLCB3aGVyZSBwdW55Y29kZSBjb252ZXJzaW9uIGlzIGFwcGxpZWQg c2VwYXJhdGVseSB0byBlYWNoIHNpZGUgb2YgdGhlIEAuIFRoZW4gZW1haWwgYWRtaW5pc3RyYXRv cnMgb24gRUFJIHN5c3RlbXMganVzdCBoYXZlIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCB2ZXJp ZmljYXRpb24gdG8gZG8gb24gbmV3IGVtYWlsIGFjY291bnQgcmVxdWVzdHM6DQo+IDMuIGdlbmVy YXRlIHRoZSBwdW55Y29kZSBvZiB0aGUgbmV3IGFkZHJlc3MgKGxvY2FsIG5hbWUpIGFuZCBhcHBs eSB0ZXN0cyAxIGFuZCAyIGFib3ZlIHRvIG1ha2Ugc3VyZSB0aGUgcHVueWNvZGUgbmFtZSBpcyBu b3QgaW4gdXNlIG9uIHRoZSBkb21haW4uDQoNCnBscyBzZWUgbXkgbGFzdCBlbWFpbCB0byBzaGF3 bi4NCg0KPiANCj4gU2luY2Ugb25seSBvd25lcnMgb2YgYSBkb21haW4gY2FuIGNyZWF0ZSBlbWFp bCBhZGRyZXNzZXMsIG5hbWUgY29sbGlzaW9ucyBjYW5ub3Qgb2NjdXIgdW5sZXNzIGFkbWluaXN0 cmF0b3JzIGZhaWwgdG8gY2hlY2sgZm9yIHVuaXF1ZW5lc3MgYmVmb3JlIGdyYW50aW5nIG5ldyBl bWFpbCBhZGRyZXNzZXMuIFRoYXQgcmVxdWlyZW1lbnQgaXMgbm8gZGlmZmVyZW50IGZyb20gdG9k YXkuDQo+IA0KPiBBbm90aGVyIGNvbmNlcm4gYWJvdXQgdXNpbmcgQUNFIGNvbnZlcnNpb25zIGlu IEVBSSB3YXMgdGhlIGlzc3VlIG9mIHB1bnljb2RlIGFkZHJlc3NlcyAibGVha2luZyIgaW50byB0 aGUgdXNlciBlbnZpcm9ubWVudC4gSnVzdCB0byByZW1pbmQgcGVvcGxlIGhvdyB1Z2x5IHRoaXMg Y2FuIGJlLCBoZXJlIGlzIGEgY29udmVyc2lvbiBvZiBvbmUgb2YgdGhlIEVBSSBhZGRyZXNzZXMg dXNlZCBpbiBvbmUgb2YgdGhlIGRvd25ncmFkZSB0ZXN0cy4NCj4gPHhuLS1xeGEueG4tLW14YWZx cWt5QHhuLS0tLXZsYmViaWloMmFpdWU2YWRkYnoxYXd1M2J6Zy5pbmZvPg0KPiANCj4gDQo+IA0K DQo+IEkgdGhpbmsgcmVjZWl2aW5nIGEgbG90IG9mIGVtYWlsIHdpdGggbG9uZyB1bnJlY29nbml6 YWJsZSBBQ0UgY29udmVyc2lvbnMgbWlnaHQgYmUgaW5jZW50aXZlIGZvciBwZW9wbGUgdG8gdXBn cmFkZSB0byBFQUkuDQoNCml0IGFsc28gbWlnaHQgYmUgaW5jZW50aXZlIGZvciBwZW9wbGUgdG8g cmVmdXNlIHRoZSB1c2Ugb2YgIEVBSS4NCg0KPiANCj4gDQo+IEVtYWlsIGFkbWluaXN0cmF0b3Jz IGNhbiBhdm9pZCBsb2NhbCBuYW1lIGNvbGxpc2lvbnMgYXMgb3V0bGluZWQgYWJvdmUuIFRoaXMg YXNzdW1wdGlvbiBpcyBhbHNvIGltcG9ydGFudCB0byBFQUkgdG8gYXZvaWQgY29sbHVzaW9ucyBv biB0aGUgZG9tYWluIG5hbWUuDQo+IA0KDQp5b3UgY2FuIGF2b2lkIHRoZSBuYW1lIGNvbGxpc2lv bnMgd2hlbiBjcmVhdGluZyB0aGUgYWNjb3VudCwgYnV0IHlvdSBjYW4gbm90IHByb2hpYml0IHRo ZSBwb3NzaWJsZSBuYW1lIGNvbGxpc2lvbnMgd2hlbiB1c2luZyBpdC4gbWFueSBNVUEgYW5kIHNl cnZlcnMgbWF5IG1pcy11c2UgaXQgc2luY2UgbWFueSBtYW55IE1VQSBvciBzZXJ2ZXJzIG1pZ2h0 IHVzZSB0aGUgYXV0b21hdGljIG9uZSBpZiB0aGVyZSBpcyBhIGF1dG9tYXRpYyBhbGdvcml0aG0u DQoNCmZvciBtb3JlLCB5b3UgY2FuIHNlZSBteSBsYXN0IGVtYWlsIHRvIHNoYXduLg0KDQpZYW8g SmlhbmthbmcNCg0KDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From Shawn.Steele@microsoft.com Tue Sep 15 22:07:08 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525503A691E for ; Tue, 15 Sep 2009 22:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXCs1b5fG0Em for ; Tue, 15 Sep 2009 22:07:07 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9862B3A683F for ; Tue, 15 Sep 2009 22:07:07 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Sep 2009 22:07:56 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Tue, 15 Sep 2009 22:07:55 -0700 From: Shawn Steele To: YAO Jiankang , Harald Alvestrand Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNSEJ/2Jg2W1k4k2n/aUL3Uziq5DW7MtzgAGkdU2AABr1Ig== Date: Wed, 16 Sep 2009 05:04:56 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM><4AA6CCBB.1070804@ca.afilias.info>, <4AA7A649.5000903@ca.afilias.info><4AA7F35E.7080906@ca.afilias.info>, <4AAE11DE.5030608@alvestrand.no> <452946849.07535@cnnic.cn>, <023101ca35ab$78c952a0$ad6df1da@whatisfuture> <453033209.25050@cnnic.cn>, <145501ca367d$8c50d500$ad6df1da@whatisfuture> In-Reply-To: <145501ca367d$8c50d500$ad6df1da@whatisfuture> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?TWFyayBEYXZpcyDijJs=?= , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 05:07:08 -0000 PiBzbyB4bi0teWFvQGNubmljLmNuICBoYXMgYSBsb3Qgb2YgbWVhbmluZy4geW91IG1pZ2h0IG5v dCBzZWUgc3VjaCBuYW1lIGluIHlvdXIgbGlmZSwgYnV0IHlvdSBjYW4gbm90IHByb3ZlIHRoYXQg aXQgbWlnaHQgYmUgdGhlcmUuDQoNCk9mIGNvdXJzZSBhbnkgc3RyaW5nIG1pZ2h0IGJlIHVzZWQs IGJ1dCB0aGUgcHJvYmFiaWxpdHkgc2VlbXMgbG93LiAgQW4gYWRtaW5pc3RyYXRvciBjb3VsZCBh bHNvIHByb2hpYml0IGl0IChzdXJlIHRoZXJlIGNvdWxkIGJlIGEgZGlzcGxheSBnbGl0Y2hlcyBm b3IgRUFJIGNsaWVudHMpLiAgSWYgd2Ugd2VyZSBjb25jZXJuZWQgYWJvdXQgeG4tLSwgaXQgY291 bGQgYmUgcS4tXy4gb3Igc29tZXRoaW5nIGluc3RlYWQuICAoU3VyZSwgdGhhdCBjb3VsZCBhbHNv IGJlIGluIGFuIGFkZHJlc3MsIGJ1dCB0aGlzIGlzIHN0cmV0Y2hpbmcgaXQgYSBiaXQpLiAgSSBk b24ndCB0aGluayB0aGlzIG5lZWQgYmxvY2sgdXMuICBUaGUgcmlzayBvZiBicmVha2luZyBhIHZl cnkgZmV3IGFkZHJlc3NlcyBpcyBzbWFsbCBjb21wYXJlZCB0byB0aGUgZnVuY3Rpb25hbGl0eSB0 aGF0IGlzIGdhaW5lZC4NCg0KQWdhaW46IEknbSBvbmx5IChyZSlwcm9wb3NpbmcgdGhpcyBhcyBh IGxhc3QtcmVzb3J0IGZhbGxiYWNrLCBub3QgdG8gcmVwbGFjZSBhIGh1bWFuIGZyaWVuZGx5IGFs aWFzLg0KDQotIFNoYXdu From Shawn.Steele@microsoft.com Tue Sep 15 22:12:57 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223103A6840 for ; Tue, 15 Sep 2009 22:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0n-anmH7wPA for ; Tue, 15 Sep 2009 22:12:56 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 495753A682D for ; Tue, 15 Sep 2009 22:12:56 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Sep 2009 22:13:45 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 15 Sep 2009 22:13:44 -0700 From: Shawn Steele To: YAO Jiankang , Ernie Dainow Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNoRn/2Jg2W1k4k2n/aUL3Uziq5DYqlOi Date: Wed, 16 Sep 2009 05:13:43 +0000 Message-ID: References: <453073879.17525@cnnic.cn>, <14da01ca3684$690f6500$ad6df1da@whatisfuture> In-Reply-To: <14da01ca3684$690f6500$ad6df1da@whatisfuture> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?TWFyayBEYXZpcyDijJs=?= , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 05:12:57 -0000 PiA+IEkgdGhpbmsgcmVjZWl2aW5nIGEgbG90IG9mIGVtYWlsIHdpdGggbG9uZyB1bnJlY29nbml6 YWJsZSBBQ0UgY29udmVyc2lvbnMgbWlnaHQgYmUgaW5jZW50aXZlIGZvciBwZW9wbGUgdG8gdXBn cmFkZSB0byBFQUkuDQoNCj4gaXQgYWxzbyBtaWdodCBiZSBpbmNlbnRpdmUgZm9yIHBlb3BsZSB0 byByZWZ1c2UgdGhlIHVzZSBvZiAgRUFJLg0KDQpJIGRvdWJ0IGl0IG1hdHRlcnMgZWl0aGVyIHdh eS4gIE91dGxvb2sgc2hvd3MgdGhpcyBtZXNzYWdlIGFzIGJlaW5nIGZyb20gWUFPIEppYW5rYW5n LCBJIGRvbid0IGV2ZW4gc2VlIHRoZSBhZGRyZXNzZXMgJ3RpbCBJIHJlcGx5Lg0KDQpBZ2Fpbiwg SSdtIGNvbmNlcm5lZCB0aGF0IDIgImJpZyIgY29tcGFuaWVzIGFyZSBjb25zaWRlcmluZyBhZG9w dGluZyBzb21ldGhpbmcgbGlrZSB0aGlzLiAgSSBjYW4ndCBmYXVsdCB0aGVpciBsb2dpYywgZm9y IHRoZW0gdGhlIGVkZ2UgY2FzZSBzZWVtcyByYXJlLiAgQ2VydGFpbmx5IGl0J3MgYWxsb3dlZCBi eSB0aGUgc3RhbmRhcmQgKHdlJ3JlIHZlcnkgbGF4IGluIHdoYXQgdGhlIEFTQ0lJIGZvcm0gbWF5 IGJlLikgIEkgd291bGQgZXhwZWN0IHRoYXQgaWYgYSBtYWpvciB2ZW5kb3IgYWRvcHRlZCBhIHB1 bnljb2RlIGZvcm0sIHRoZW4gdGhlaXIgY2xpZW50cyB3b3VsZCBhbHNvIHJlY29nbml6ZSBpdC4N Cg0KSXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgdG8gaGF2ZSBhIHNoYXJlZCBhbGdvcml0aG1pYyBt ZXRob2QgdGhhdCB3ZSBjb3VsZCBhbGwgdXNlIChldmVuIGlmIGl0IHdhcyBkaXNjb3VyYWdlZCkg cmF0aGVyIHRoYW4gaGF2aW5nIGRpZmZlcmVudCB2ZW5kb3JzIGNyZWF0ZSB2ZXJzaW9ucyB0aGF0 IGFyZSBwZXJoYXBzIGluY29tcGF0aWJsZS4gIENhbiB3ZSBjcmVhdGUgYSBkcmFmdCAoSSBjYW4g aGVscCBpZiBuZWNlc3NhcnkpIG9mIGEgY29tbW9uIG1lY2hhbmlzbSBvciBhcmUgdGhlcmUgb3Ro ZXIgb2JqZWN0aW9ucyBiZXNpZGVzIHRoZSB4bi0tIG1pZ2h0IGNvbmZsaWN0IG9uZT8NCg0KLSBT aGF3bg== From harald@alvestrand.no Tue Sep 15 23:17:00 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC433A67E9 for ; Tue, 15 Sep 2009 23:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afxAQWkM39tB for ; Tue, 15 Sep 2009 23:16:59 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 780023A6991 for ; Tue, 15 Sep 2009 23:16:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7715439E1BE; Wed, 16 Sep 2009 08:17:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bei76N1Ibp97; Wed, 16 Sep 2009 08:17:43 +0200 (CEST) Received: from [192.168.1.245] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5BAA539E15D; Wed, 16 Sep 2009 08:17:43 +0200 (CEST) Message-ID: <4AB082BD.8070301@alvestrand.no> Date: Wed, 16 Sep 2009 08:16:29 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ernie Dainow References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info> In-Reply-To: <4AB01389.6030607@ca.afilias.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= , Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 06:17:00 -0000 Ernie Dainow wrote: > > Harald Alvestrand wrote: >> The overarching issue found with variants of this proposal previously >> rejected was: >> >> Can we guarantee (for a sufficiently strong version of "guarantee") >> that there are no valid mailboxes that "just happen to look like" the >> Punycoded strings? > I'm not sure it is necessary for a standard to guarantee this. I think > it is just the responsibility of email administration to avoid name > collisions. Currently, when a new email address is requested, the > email administrator for the domain on which the name is requested (or > email admin software) will not grant the email address if > 1. the address (local name) is assigned to someone else on the domain. > 2. the address is already in use as an alias on another email account > on the domain. My worry is about what happens if the recipient tries to decode the left-hand side as if it was a Punycoded name when it is not. Unless one can tell the difference between those domains that use Punycoded LHS and those that do not, a recipient will apply the Punycode decoding to left-hand sides indiscriminately. This can lead to similar effects as the "Bush hid the facts" bug (see http://en.wikipedia.org/wiki/Bush_hid_the_facts for details). Harald From McQuilWP@pobox.com Tue Sep 15 23:18:56 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49F73A6937 for ; Tue, 15 Sep 2009 23:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEGbfOq9aCGo for ; Tue, 15 Sep 2009 23:18:56 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 724513A6A2E for ; Tue, 15 Sep 2009 23:18:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 358CF52B95; Wed, 16 Sep 2009 02:19:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=LrTxJbRIZjk7 3nuTyG5Zec0Ze1I=; b=OTiwpWJNgbLXVKE4uHr+/kJPlCkrwA/nkPWjrRxQYMZf jh5DV2ANnqfbbminA/Dow131dY+ZWTfTtzfjHLsojZDpJu4/2VLogXNAI5uSjK7H WVmtcZ9v1j5K41kiFcpBiA52U4Wp709XItyB4pzHceBb0Ll6vgorg29WGyO3j3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=XGYJ6b kNSMhW6N1NOW8ufnVrWJKuYSErjCMA7C6cYZpZgYLt8EN0bpn6hFxonST/xDPu7+ vfHlM0wpL/V/aU78M8OiBge+CwLGF398u2st9UkSByeGBNaud5A1/4PFqYJi6JnE z0NzxrRJrchZKMBvPMInQnVzMONV7updzqG24= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 22F9C52B94; Wed, 16 Sep 2009 02:19:37 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.60.165]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPA id 8294852B8E; Wed, 16 Sep 2009 02:19:32 -0400 (EDT) Date: Tue, 15 Sep 2009 23:19:31 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <828324342.20090915231931@pobox.com> To: IMA Discussion In-Reply-To: References: <453073879.17525@cnnic.cn>, <14da01ca3684$690f6500$ad6df1da@whatisfuture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E8A96336-A288-11DE-BEFB-8B19076EA04E-02871704!a-pb-sasl-sd.pobox.com Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 06:18:57 -0000 On Tue, 2009-09-15, Shawn Steele wrote: > It would be much better to have a shared algorithmic method that we > could all use (even if it was discouraged) rather than having different > vendors create versions that are perhaps incompatible. Can we create a > draft (I can help if necessary) of a common mechanism or are there other > objections besides the xn-- might conflict one? I'm trying to remember all the reasons that were given when I advocated the algorithmic approach several years ago. The first was "Thou shalt not modify the left hand side!" Maybe all of the issues brought up recently have softened this. Maybe not. The second was "Some people expect to modify the left hand side!" For example, the convention that a mailing list manager may be contacted by appending "-request", like: . Punycode would mess this up by appending stuff after the modified portion. I don't remember if I bothered previously to suggest the ACE prefix: %% The double percent would be using a character that historically had been used for manual routing. Thus would be initially sent to example.org which would forward it to me at . This usage is now long deprecated, but may indicate that the percent sign was considered reserved in left hand sides. Also a double percent, like <%%punycode@example.com>, is perhaps very unlikely to collide with any existing left hand side. If the algorthmic method were guaranteed reversible, *any* ima-aware server or client could downgrade or upgrade as it saw fit (e.g., to parse embedded information in the left hand side) making sure only to downgrade before passing it along to an ima-UNaware server. -- Bill McQuillan From Shawn.Steele@microsoft.com Tue Sep 15 23:24:40 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D283A68D2 for ; Tue, 15 Sep 2009 23:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.439 X-Spam-Level: X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZAP8D7sDWRx for ; Tue, 15 Sep 2009 23:24:39 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B15593A6841 for ; Tue, 15 Sep 2009 23:24:39 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Sep 2009 23:25:28 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Tue, 15 Sep 2009 23:25:28 -0700 From: Shawn Steele To: Harald Alvestrand , Ernie Dainow Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNSEJ/2Jg2W1k4k2n/aUL3Uziq5DYsPqAgACEkYD//4vCgg== Date: Wed, 16 Sep 2009 06:25:27 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info>,<4AB082BD.8070301@alvestrand.no> In-Reply-To: <4AB082BD.8070301@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mark@macchiato.com" , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 06:24:40 -0000 > My worry is about what happens if the recipient tries to decode the > left-hand side as if it was a Punycoded name when it is not. Unless one > can tell the difference between those domains that use Punycoded LHS and > those that do not, a recipient will apply the Punycode decoding to > left-hand sides indiscriminately. This can lead to similar effects as > the "Bush hid the facts" bug (see > http://en.wikipedia.org/wiki/Bush_hid_the_facts for details). Yup. But I think it's worth the improvement for behavior in the 99.999% case. M= aybe we could get statistics for how many account names actually look like = this. Also we could pick something really wierd (like the q.-_.z or someth= ing). =20 IDN had the same issue, but seems to have succeeded (at least in that respe= ct.) I don't think we can improve the "other" fallback mechanism sufficiently to= be interesting. We've pretty much proven that pairing of addresses only w= orks in limited scenarios and breaks pretty quickly when deviating from the= simple scenarios. -Shawn= From McQuilWP@pobox.com Tue Sep 15 23:47:51 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD713A6991 for ; Tue, 15 Sep 2009 23:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQhIgdq4ukhi for ; Tue, 15 Sep 2009 23:47:50 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 388373A6979 for ; Tue, 15 Sep 2009 23:47:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 39FA234D9C; Wed, 16 Sep 2009 02:48:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=S8/skhbtRE+b 47aHeIswHvszd6k=; b=nqGcdledyy/HIulRqc+UayQDmFUj2Qi/Yy5oURS1h670 7GFtBaaJ5PxqhtsT80sHcbNW1o2+c3Cd//YxNFJgrdVNIBS9TlLAflr6PanCo4uu V1GUHkjtJOP4o9kcxb/MiUX0CIHbQ2rQV0sQV3pRrcdpoIrPT3cVHIYnjNrCWaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=S0AYeN douF7OSwmPOU2xQ0UHvVtFfBvRv8k66niLqVpARlLLT5d7NG8g7552kJJA8+DIQe Gs3XNtxzrWTRBRG2Nyfdi7RmZqLoaGaYScT5ATDO8AXRHb2jRhwr/S/tES8tecbZ hJ2yowRKIEd9sztkdZZ4gYrvRLYL+CR/y3gTc= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2925734D9B; Wed, 16 Sep 2009 02:48:35 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.60.165]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPA id 8F02734D9A; Wed, 16 Sep 2009 02:48:31 -0400 (EDT) Date: Tue, 15 Sep 2009 23:48:30 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <205021754.20090915234830@pobox.com> To: IMA Discussion In-Reply-To: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info>, <4AB082BD.8070301@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F4A69344-A28C-11DE-9E0C-A13518FFA523-02871704!a-pb-sasl-quonix.pobox.com Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 06:47:51 -0000 On Tue, 2009-09-15, Shawn Steele wrote: > IDN had the same issue, but seems to have succeeded (at least in that respect.) Unfortunately, this is a red herring. IDN had a much smaller universe to be compatible with. Hostnames are generally not allowed to have more than one hyphen in a row. Thus xn--... should never collide with a hostname, so they only had to discover if that form was found in the few other DNS usages. -- Bill McQuillan From edainow@ca.afilias.info Wed Sep 16 05:53:20 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB87028C0CF for ; Wed, 16 Sep 2009 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8aRP1uRf6lq for ; Wed, 16 Sep 2009 05:53:20 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 174083A6A02 for ; Wed, 16 Sep 2009 05:53:19 -0700 (PDT) Message-ID: <4AB0DFE9.9030602@ca.afilias.info> Date: Wed, 16 Sep 2009 08:54:01 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: YAO Jiankang References: <453073879.17525@cnnic.cn> <453074567.10858@cnnic.cn> In-Reply-To: <453074567.10858@cnnic.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= , Shawn Steele , ima@ietf.org Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 12:53:20 -0000 YAO Jiankang wrote: > >> I think receiving a lot of email with long unrecognizable ACE conversions might be incentive for people to upgrade to EAI. >> > > it also might be incentive for people to refuse the use of EAI. > > EAI users should never see the ACE names. They will appear only in downgraded messages and delivered to users who are not using EAI, since EAI -> downgrade -> delivery to EAI client is typically a configuration error. In any case, up-conversion on the receiving side (POP, IMAP, MUA) can apply the reverse translation and restore UTF8 addresses from the ACE encodings. As more and more people use EAI, non-EAI users will receive more and more downgraded messages with puunycode addresses. This will build momentum for conversion to the new standard. >> Email administrators can avoid local name collisions as outlined above. This assumption is also important to EAI to avoid collusions on the domain name. >> >> > > you can avoid the name collisions when creating the account, but you can not prohibit the possible name collisions when using it. many MUA and servers may mis-use it since many many MUA or servers might use the automatic one if there is a automatic algorithm. > > The design of punycode ensures that there are no collisions, where more than one UTF8 name maps to the same punycode. As long as all email systems use the same standard ACE that has this property, there will be no collisions when using it. -Ernie From edainow@ca.afilias.info Wed Sep 16 05:55:30 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3A228C0D0 for ; Wed, 16 Sep 2009 05:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXA71xp8m40B for ; Wed, 16 Sep 2009 05:55:29 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id DEDCA3A69FF for ; Wed, 16 Sep 2009 05:55:28 -0700 (PDT) Message-ID: <4AB0E06B.20609@ca.afilias.info> Date: Wed, 16 Sep 2009 08:56:11 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shawn Steele References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info>, <4AB082BD.8070301@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: "ima@ietf.org" , "mark@macchiato.com" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 12:55:30 -0000 Shawn Steele wrote: >> My worry is about what happens if the recipient tries to decode the >> left-hand side as if it was a Punycoded name when it is not. Unless one >> can tell the difference between those domains that use Punycoded LHS and >> those that do not, a recipient will apply the Punycode decoding to >> left-hand sides indiscriminately. This can lead to similar effects as >> the "Bush hid the facts" bug (see >> http://en.wikipedia.org/wiki/Bush_hid_the_facts for details). >> > > Yup. > Local names are not decoded until they arrive at the destination domain. At that point, if a mailbox exists for the local name, it is delivered. On EAI systems, if that mailbox does not exist, then the name is decoded and a second delivery is attempted to the UTF8 mailbox. If the checks outlined earlier are followed when creating new mailboxes, delivery will never go to different users for these two cases. In fact, email administration on an ACE-based EAI should assign the punycode translation of local addresses as an alias for the UTF8 address. So delivery of either punycode or UTF8 goes to the same mailbox without the above two step delivery process. > But I think it's worth the improvement for behavior in the 99.999% case. Maybe we could get statistics for how many account names actually look like this. Also we could pick something really wierd (like the q.-_.z or something). > > We have to be careful about about making a statistical decision. If there is any chance that mail gets delivered to the wrong place, it is a serious breach of privacy. This takes precedence over other goals such as "works 99.999% of the time". This is a more serious failure than delivery failures in the triangle case, which is what we are basically trying to solve with an ACE-based downgrade. -Ernie From klensin@jck.com Wed Sep 16 06:45:22 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6147F3A6924 for ; Wed, 16 Sep 2009 06:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKPglsTgw3tk for ; Wed, 16 Sep 2009 06:45:21 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id BF12D3A680E for ; Wed, 16 Sep 2009 06:45:20 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mnuph-0002rm-LN; Wed, 16 Sep 2009 09:46:06 -0400 Date: Wed, 16 Sep 2009 09:46:04 -0400 From: John C Klensin To: Harald Alvestrand , Ernie Dainow Message-ID: In-Reply-To: <4AB082BD.8070301@alvestrand.no> References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info> <4AB082BD.8070301@alvestrand.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: =?UTF-8?Q?Mark_Davis_=E2=8C=9B?= , Shawn Steele , ima@ietf.org Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 13:45:22 -0000 --On Wednesday, September 16, 2009 08:16 +0200 Harald Alvestrand wrote: > Ernie Dainow wrote: >> >> Harald Alvestrand wrote: >>> The overarching issue found with variants of this proposal >>> previously rejected was: >>> >>> Can we guarantee (for a sufficiently strong version of >>> "guarantee") that there are no valid mailboxes that "just >>> happen to look like" the Punycoded strings? >> I'm not sure it is necessary for a standard to guarantee >> this. I think it is just the responsibility of email >> administration to avoid name collisions. Currently, when a >> new email address is requested, the email administrator for >> the domain on which the name is requested (or email admin >> software) will not grant the email address if 1. the address >> (local name) is assigned to someone else on the domain. 2. >> the address is already in use as an alias on another email >> account on the domain. > My worry is about what happens if the recipient tries to > decode the left-hand side as if it was a Punycoded name when > it is not. Unless one can tell the difference between those > domains that use Punycoded LHS and those that do not, a > recipient will apply the Punycode decoding to left-hand sides > indiscriminately. This can lead to similar effects as the > "Bush hid the facts" bug (see > http://en.wikipedia.org/wiki/Bush_hid_the_facts for details). Let me say what Harald, Bill, and others have said from a different perspective and a little more strongly. Once upon a time, before the web and before we could assume that almost every node connected to the network was well-connected (end to end) with just about every other node, the most common method for transmitting command instructions from one host to another (or a device connected to another) involved email messages that could be received, stored, and forwarded by intermediaries. In many cases, local-part addresses were used to encode information and to secure and/or authenticate the commands with what amounted to shared-secret encryption and anti-reply coding. It may be worth noting that some very similar techniques have emerged in the "delay-tolerant networking" area. If one cannot do end-to-end (or end-to-closely-coordinated-surrogate) handshakes, there aren't that many options. Those applications led to some email local parts that were truly bizarre if one assumed that local parts are some stable variation on a user name or ID/handle. Worse, not only are strings that look remarkably like IDNA ACEs plausible, it is impossible to do the equivalent of sweeping the DNS tree or inquiring of top-level registries to give some confidence that choices are being made that don't conflict with existing uses (such sweeps and questions were part of the process of selecting the ACE prefix, and some candidate prefixes were eliminated on the basis of existing usage). There is at least anecdotal evidence that methods using local parts to transmit command and control information (either coded into the local-part or using the local part to authenticate the message payload) have not dropped out of use, even though their presence as a percentage of messages on the Internet has certainly dropped. For better or worse, little of this stuff is written down in, e.g., the RFC series. At least some of the reason is that many similar, but certainly not identical, mechanisms have been invented over and over again in different places and rely on "security by (often rather extreme) obscurity", rather than cryptographic integrity... but that doesn't make them less problematic from our standpoint. Those mechanisms are among the reasons why the email community established the very strong "only the receiving system can interpret a local part and it MUST NOT be messed with in transit" rules that appear in RFC 5321 and its predecessors and has been unwilling to change them. IMO, even if this WG reached the conclusion that such tag-identified encodings were a good idea, the proposal would be destroyed on IETF Last Call. Finally, while such address-encoded information is certainly still in use, the odds of showing up on, e.g., a search through Google databases are just about zip --the data aren't archived, the messages don't refer to each other, many of the addresses are one-time-use, and natural language processing mechanisms don't work because these addresses are about as far from natural language as one can get. And, finally, anyone who can't dedicate a host, or at least a domain or primary address and family of subaddresses, under their control to the particular control tasks at issue is just not in the game... so the more relevant and sophisticated methods are not using public/free email systems of the AOL/ Hotmail/ Gmail/ Yahoo/ etc persuasions. It just isn't a worthwhile path to try to follow. john From klensin@jck.com Wed Sep 16 12:31:00 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4403A686E for ; Wed, 16 Sep 2009 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy-OFcUjLClO for ; Wed, 16 Sep 2009 12:30:59 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AEA1A3A6861 for ; Wed, 16 Sep 2009 12:30:58 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mo0EB-000AR9-Ec; Wed, 16 Sep 2009 15:31:43 -0400 Date: Wed, 16 Sep 2009 15:31:42 -0400 From: John C Klensin To: Shawn Steele , Harald Alvestrand , Ernie Dainow Message-ID: <4E9F6C22B1F9B9179F22EABF@PST.JCK.COM> In-Reply-To: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info> ,<4AB082BD.8070301@alvestrand.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: mark@macchiato.com, ima@ietf.org Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 19:31:00 -0000 --On Wednesday, September 16, 2009 06:25 +0000 Shawn Steele wrote: >... >> left-hand sides indiscriminately. This can lead to similar >> effects as the "Bush hid the facts" bug (see >> http://en.wikipedia.org/wiki/Bush_hid_the_facts for details). > > Yup. > > But I think it's worth the improvement for behavior in the > 99.999% case. Maybe we could get statistics for how many > account names actually look like this. Also we could pick > something really wierd (like the q.-_.z or something). > IDN had the same issue, but seems to have succeeded (at least > in that respect.) Shawn, I addressed most of this in a note I sent a few hours ago and that probably crossed yours in the email. I won't repeat myself but, as others have also pointed out, the issues here are much more complicated than the IDN ones. In particular, one of the issues that has generated a lot of traffic on the IDNAbis list -- the desire to have upper-case letters that are properly majuscules, not capitals, handled differently depending on context-- gets a rather different answer here because of the "local parts get interpreted only by the delivery system" principle. For example, while the DNS guarantees case-insensitive matching for ASCII labels, there are absolutely no guarantees in email about case sensitivity or insensitivity. I actually works on a system some years ago in which traffic for, e.g., joe@example.com was treated as mail traffic for joe while traffic for jOe@example.com was treated as a command stream for one of joe's processes or daemons. The idea didn't last very long for security reasons --and got replaced by members of the family of the messy strings I described-- but you get the idea. I have to agree with what I think was at least the intent of a recent note of Harald's -- each of these suggestions needs careful analysis and explanations of what cases exist, which ones "work" (and what that implies) and which ones fail and in what ways. Without that sort of analysis, asserting that a particular approach will solve some large percentage of cases does not, IMO, help us very much (and doing so in a large stream of messages helps, again, IMO, even less). That said, let me state a question that I think might be illuminating, even though I'm not sure whether I think what it implies is acceptable: Suppose we were willing to start with "the number of cases in which downgrading is needed will be fairly few if sending systems are carefully designed and configured and receiving systems and their MX intermediaries are configured correctly" (you, Ernie, Jiankang, and others, including myself, have all said variations on that). We also assume that the number of cases in which it is needed will go down over time, as EAI deploys more broadly and as various actors understand the configuration issues better. Could we then say "whatever downgrading is needed is about getting messages delivered anyway but, if downgrading is applied, we no longer expect 'replies' to work reliably"? On the one hand, that is a fairly big step. But it has a lot of precedent (some intentional and some not) in email systems. And it would sweep away a lot of issues, including Harald's exemplar triangular case. Generating a header/marker to warn the recipient that the headers may not show all recipients and that "reply all" may not reach everyone to whom the original message was sent is pretty easy (reexamining the idea of using group syntax might work well here). As far as addresses are concerned, it turns the entire downgrade story into an envelope one, where we don't have syntax problems (double angle brackets or otherwise). It minimizes long-term damage for short-term/ transitional gains and gives the various humans involved an incentive to upgrade. And it makes things completely predictable, which you've been asking for, as long as one is willing to count "if you reply to this, it probably won't work as you expect, but no one prevents you from trying" as predictable behavior (I actually do, YMMD). I note that there were many examples and bad jokes about both X.400 and early versions of Exchange whose substance was that the only reliable "reply" mechanism involved picking up a telephone, so, in practice (and perhaps even in theory), we've never had nearly the same level of expectation about replies working that we've had about deliveries getting through. But it is a big step. Is it one we might be willing to consider? john From Shawn.Steele@microsoft.com Wed Sep 16 13:36:23 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABED28C0F7 for ; Wed, 16 Sep 2009 13:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.442 X-Spam-Level: X-Spam-Status: No, score=-11.442 tagged_above=-999 required=5 tests=[AWL=1.156, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VA1gOYd0I16 for ; Wed, 16 Sep 2009 13:36:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 2AE853A6A46 for ; Wed, 16 Sep 2009 13:36:21 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Sep 2009 13:37:11 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Wed, 16 Sep 2009 13:37:10 -0700 From: Shawn Steele To: John C Klensin , Harald Alvestrand , Ernie Dainow Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNSEJ/2Jg2W1k4k2n/aUL3Uziq5DYsPqAgACEkYD//4vCgoABUmwA//+ZauA= Date: Wed, 16 Sep 2009 20:37:09 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info> ,<4AB082BD.8070301@alvestrand.no> <4E9F6C22B1F9B9179F22EABF@PST.JCK.COM> In-Reply-To: <4E9F6C22B1F9B9179F22EABF@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A026CCFTK5EX14MBXC137red_" MIME-Version: 1.0 Cc: "mark@macchiato.com" , "ima@ietf.org" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 20:36:23 -0000 --_000_E14011F8737B524BB564B05FF748464A026CCFTK5EX14MBXC137red_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmU6IGNhc2luZywgZXRjLiAgVW5saWtlIElETiwgSSB0cmllZCB0byBtYWtlIGNsZWFyIHRoYXQg SSdtIHN1Z2dlc3Rpbmcgbm8gbWFwcGluZyBiZSBkb25lIHByaW9yIHRvIGVuY29kaW5nLCBpdCdz IG1lcmVseSBhbiBlbmNvZGluZy4gIFRoZSBzZXJ2ZXIgc2lkZSB3b3VsZCBzdGlsbCBkbyB3aGF0 ZXZlciBpdCB3YW50cyB3aXRoIGNhc2luZywgd2hpY2ggbWVhbnMgdGhhdCBpdCBNVVNUIGRlY29k ZSBpdCB0byBVbmljb2RlLCB0aGVuIGRvIHdoYXRldmVyIG1hcHBpbmcgaXQgd2FudHMuICAoRGlm ZmVyZW50bHkgY2FzZWQgc2jDpHduIGFuZCBTSMOEV04gd291bGQgZ2V0IGRpZmZlcmVudCBlbmNv ZGluZ3MgYW5kIGNvdWxkIG5vdCBiZSBjb21wYXJlZCBpbiB0aGUgZW5jb2RlZCBmb3JtLikgIFRo YXQgbWFrZXMgbWF0Y2hpbmcgb2YgdGhlIEFDRSBmb3JtcyBtb3JlIGRpZmZpY3VsdCwgYnV0IGF2 b2lkcyBwcm9ibGVtcyB3aXRoIGNhc2luZyBydWxlcyBiZWluZyBpbnRlcnByZXRlZCBkaWZmZXJl bnRseS4NCg0KDQoNClJlOiBwYXJ0aWFsIGRvd25ncmFkZS4gIEkgY2Fubm90IGltYWdpbmUgaG93 IGFsbG93aW5nIG1haWwgdG8gYmUgZGVsaXZlcmVkLCBidXQgbm90IHByb3ZpZGluZyBmb3IgcmVw bGllcyB0byB3b3JrIGlzIGhlbHBmdWwuICBUaGVyZeKAmXMgbm8gd2F5IGZvciBhIHNlbmRlciB0 byBrbm93IGlmIHRoZXkgd2VyZSBpZ25vcmVkIG9yIGp1c3QgaGFkIGEgbWFpbCBtaXh1cC4gIEkg ZG9u4oCZdCB0aGluayB0aGF0IHRoZSDigJxyZXBseeKAnSBhbmVjZG90ZSB5b3UgZGVzY3JpYmUg aXMgYXBwcm9wcmlhdGUgaW4gdGhlIG1vZGVybiB3b3JsZC4gIFdlIGhhdmUgYSBtdWNoIG1vcmUg cmVsaWFibGUgc3lzdGVtIG5vdyBhbmQgcmVwbHktYWxsIGlzIGV4cGVjdGVkIHRvIGJlaGF2ZS4N Cg0KDQoNCkkgdGhpbmsgdGhhdCBlaXRoZXIgd2UgbmVlZCB0byBoYXZlIG5vIGRvd25ncmFkZSBh dCBhbGwsIG9yIHdlIG11c3QgaGF2ZSBuZWFybHktY29tcGxldGUgZG93bmdyYWRlLiAgSSBhbHNv IHRoaW5rIHRoYXQgbmVhcmx5LWNvbXBsZXRlIGRvd25ncmFkZSB3b3VsZCByZXF1aXJlIGFuIGFs Z29yaXRobWljIHRlY2huaXF1ZSBhcyB3ZeKAmXZlIHByZXR0eSBtdWNoIHByb3ZlbiB0aGF0IHBh aXJpbmcgKGJ5IDw8Pj4gb3Igb3RoZXIgbWVhbnMpIGJyZWFrcyBwcmV0dHkgcmFwaWRseS4NCg0K DQoNCkkgZG9u4oCZdCB0aGluayB0aGUgZG93bmdyYWRlIHRlY2huaXF1ZSBkaXNjdXNzaW9uIGJs b2NrcyBhbnkgb2YgdGhlIG5vbi1kb3duZ3JhZGUgc3BlY3MgZnJvbSBwcm9jZWVkaW5nLiAgT2J2 aW91c2x5IEVBSSBkb2VzbuKAmXQg4oCcbmVlZOKAnSBkb3duZ3JhZGUsIGl0IGp1c3QgbWlnaHQg ZWFzZSB0aGUgdHJhbnNpdGlvbi4NCg0KDQoNCi1TaGF3bg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEpvaG4gQyBLbGVuc2luIFttYWlsdG86a2xlbnNpbkBqY2suY29t XQ0KU2VudDogUG/Ku2Frb2x1LCBLZXBha2VtYXBhIDE2LCAyMDA5IDEyOjMyIFBNDQpUbzogU2hh d24gU3RlZWxlOyBIYXJhbGQgQWx2ZXN0cmFuZDsgRXJuaWUgRGFpbm93DQpDYzogbWFya0BtYWNj aGlhdG8uY29tOyBpbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRUFJXSBUaGlua2luZyBhYm91 dCByZXF1aXJlbWVudHMgLyBkb3duZ3JhZGUNCg0KDQoNCg0KDQoNCg0KLS1PbiBXZWRuZXNkYXks IFNlcHRlbWJlciAxNiwgMjAwOSAwNjoyNSArMDAwMCBTaGF3biBTdGVlbGUNCg0KPFNoYXduLlN0 ZWVsZUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KDQoNCj4uLi4NCg0KPj4gbGVmdC1oYW5kIHNp ZGVzIGluZGlzY3JpbWluYXRlbHkuIFRoaXMgY2FuIGxlYWQgdG8gc2ltaWxhcg0KDQo+PiBlZmZl Y3RzIGFzIHRoZSAiQnVzaCBoaWQgdGhlIGZhY3RzIiBidWcgKHNlZQ0KDQo+PiBodHRwOi8vZW4u d2lraXBlZGlhLm9yZy93aWtpL0J1c2hfaGlkX3RoZV9mYWN0cyBmb3IgZGV0YWlscykuDQoNCj4N Cg0KPiBZdXAuDQoNCj4NCg0KPiBCdXQgSSB0aGluayBpdCdzIHdvcnRoIHRoZSBpbXByb3ZlbWVu dCBmb3IgYmVoYXZpb3IgaW4gdGhlDQoNCj4gOTkuOTk5JSBjYXNlLiAgTWF5YmUgd2UgY291bGQg Z2V0IHN0YXRpc3RpY3MgZm9yIGhvdyBtYW55DQoNCj4gYWNjb3VudCBuYW1lcyBhY3R1YWxseSBs b29rIGxpa2UgdGhpcy4gIEFsc28gd2UgY291bGQgcGljaw0KDQo+IHNvbWV0aGluZyByZWFsbHkg d2llcmQgKGxpa2UgdGhlIHEuLV8ueiBvciBzb21ldGhpbmcpLg0KDQo+IElETiBoYWQgdGhlIHNh bWUgaXNzdWUsIGJ1dCBzZWVtcyB0byBoYXZlIHN1Y2NlZWRlZCAoYXQgbGVhc3QNCg0KPiBpbiB0 aGF0IHJlc3BlY3QuKQ0KDQoNCg0KU2hhd24sDQoNCg0KDQpJIGFkZHJlc3NlZCBtb3N0IG9mIHRo aXMgaW4gYSBub3RlIEkgc2VudCBhIGZldyBob3VycyBhZ28gYW5kDQoNCnRoYXQgcHJvYmFibHkg Y3Jvc3NlZCB5b3VycyBpbiB0aGUgZW1haWwuICBJIHdvbid0IHJlcGVhdCBteXNlbGYNCg0KYnV0 LCBhcyBvdGhlcnMgaGF2ZSBhbHNvIHBvaW50ZWQgb3V0LCB0aGUgaXNzdWVzIGhlcmUgYXJlIG11 Y2gNCg0KbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoZSBJRE4gb25lcy4gIEluIHBhcnRpY3VsYXIs IG9uZSBvZiB0aGUNCg0KaXNzdWVzIHRoYXQgaGFzIGdlbmVyYXRlZCBhIGxvdCBvZiB0cmFmZmlj IG9uIHRoZSBJRE5BYmlzIGxpc3QNCg0KLS0gdGhlIGRlc2lyZSB0byBoYXZlIHVwcGVyLWNhc2Ug bGV0dGVycyB0aGF0IGFyZSBwcm9wZXJseQ0KDQptYWp1c2N1bGVzLCBub3QgY2FwaXRhbHMsIGhh bmRsZWQgZGlmZmVyZW50bHkgZGVwZW5kaW5nIG9uDQoNCmNvbnRleHQtLSBnZXRzIGEgcmF0aGVy IGRpZmZlcmVudCBhbnN3ZXIgaGVyZSBiZWNhdXNlIG9mIHRoZQ0KDQoibG9jYWwgcGFydHMgZ2V0 IGludGVycHJldGVkIG9ubHkgYnkgdGhlIGRlbGl2ZXJ5IHN5c3RlbSINCg0KcHJpbmNpcGxlLiAg Rm9yIGV4YW1wbGUsIHdoaWxlIHRoZSBETlMgZ3VhcmFudGVlcw0KDQpjYXNlLWluc2Vuc2l0aXZl IG1hdGNoaW5nIGZvciBBU0NJSSBsYWJlbHMsIHRoZXJlIGFyZSBhYnNvbHV0ZWx5DQoNCm5vIGd1 YXJhbnRlZXMgaW4gZW1haWwgYWJvdXQgY2FzZSBzZW5zaXRpdml0eSBvciBpbnNlbnNpdGl2aXR5 Lg0KDQpJIGFjdHVhbGx5IHdvcmtzIG9uIGEgc3lzdGVtIHNvbWUgeWVhcnMgYWdvIGluIHdoaWNo IHRyYWZmaWMNCg0KZm9yLCBlLmcuLCBqb2VAZXhhbXBsZS5jb20gd2FzIHRyZWF0ZWQgYXMgbWFp bCB0cmFmZmljIGZvciBqb2UNCg0Kd2hpbGUgdHJhZmZpYyBmb3Igak9lQGV4YW1wbGUuY29tIHdh cyB0cmVhdGVkIGFzIGEgY29tbWFuZA0KDQpzdHJlYW0gZm9yIG9uZSBvZiBqb2UncyBwcm9jZXNz ZXMgb3IgZGFlbW9ucy4gIFRoZSBpZGVhIGRpZG4ndA0KDQpsYXN0IHZlcnkgbG9uZyBmb3Igc2Vj dXJpdHkgcmVhc29ucyAtLWFuZCBnb3QgcmVwbGFjZWQgYnkNCg0KbWVtYmVycyBvZiB0aGUgZmFt aWx5IG9mIHRoZSBtZXNzeSBzdHJpbmdzIEkgZGVzY3JpYmVkLS0gYnV0IHlvdQ0KDQpnZXQgdGhl IGlkZWEuDQoNCg0KDQpJIGhhdmUgdG8gYWdyZWUgd2l0aCB3aGF0IEkgdGhpbmsgd2FzIGF0IGxl YXN0IHRoZSBpbnRlbnQgb2YgYQ0KDQpyZWNlbnQgbm90ZSBvZiBIYXJhbGQncyAtLSBlYWNoIG9m IHRoZXNlIHN1Z2dlc3Rpb25zIG5lZWRzDQoNCmNhcmVmdWwgYW5hbHlzaXMgYW5kIGV4cGxhbmF0 aW9ucyBvZiB3aGF0IGNhc2VzIGV4aXN0LCB3aGljaA0KDQpvbmVzICJ3b3JrIiAoYW5kIHdoYXQg dGhhdCBpbXBsaWVzKSBhbmQgd2hpY2ggb25lcyBmYWlsIGFuZCBpbg0KDQp3aGF0IHdheXMuICAg V2l0aG91dCB0aGF0IHNvcnQgb2YgYW5hbHlzaXMsIGFzc2VydGluZyB0aGF0IGENCg0KcGFydGlj dWxhciBhcHByb2FjaCB3aWxsIHNvbHZlIHNvbWUgbGFyZ2UgcGVyY2VudGFnZSBvZiBjYXNlcw0K DQpkb2VzIG5vdCwgSU1PLCBoZWxwIHVzIHZlcnkgbXVjaCAoYW5kIGRvaW5nIHNvIGluIGEgbGFy Z2Ugc3RyZWFtDQoNCm9mIG1lc3NhZ2VzIGhlbHBzLCBhZ2FpbiwgSU1PLCBldmVuIGxlc3MpLg0K DQoNCg0KVGhhdCBzYWlkLCBsZXQgbWUgc3RhdGUgYSBxdWVzdGlvbiB0aGF0IEkgdGhpbmsgbWln aHQgYmUNCg0KaWxsdW1pbmF0aW5nLCBldmVuIHRob3VnaCBJJ20gbm90IHN1cmUgd2hldGhlciBJ IHRoaW5rIHdoYXQgaXQNCg0KaW1wbGllcyBpcyBhY2NlcHRhYmxlOg0KDQoNCg0KU3VwcG9zZSB3 ZSB3ZXJlIHdpbGxpbmcgdG8gc3RhcnQgd2l0aCAidGhlIG51bWJlciBvZiBjYXNlcyBpbg0KDQp3 aGljaCBkb3duZ3JhZGluZyBpcyBuZWVkZWQgd2lsbCBiZSBmYWlybHkgZmV3IGlmIHNlbmRpbmcN Cg0Kc3lzdGVtcyBhcmUgY2FyZWZ1bGx5IGRlc2lnbmVkIGFuZCBjb25maWd1cmVkIGFuZCByZWNl aXZpbmcNCg0Kc3lzdGVtcyBhbmQgdGhlaXIgTVggaW50ZXJtZWRpYXJpZXMgYXJlIGNvbmZpZ3Vy ZWQgY29ycmVjdGx5Ig0KDQooeW91LCBFcm5pZSwgSmlhbmthbmcsIGFuZCBvdGhlcnMsIGluY2x1 ZGluZyBteXNlbGYsIGhhdmUgYWxsDQoNCnNhaWQgdmFyaWF0aW9ucyBvbiB0aGF0KS4gIFdlIGFs c28gYXNzdW1lIHRoYXQgdGhlIG51bWJlciBvZg0KDQpjYXNlcyBpbiB3aGljaCBpdCBpcyBuZWVk ZWQgd2lsbCBnbyBkb3duIG92ZXIgdGltZSwgYXMgRUFJDQoNCmRlcGxveXMgbW9yZSBicm9hZGx5 IGFuZCBhcyB2YXJpb3VzIGFjdG9ycyB1bmRlcnN0YW5kIHRoZQ0KDQpjb25maWd1cmF0aW9uIGlz c3VlcyBiZXR0ZXIuICBDb3VsZCB3ZSB0aGVuIHNheSAid2hhdGV2ZXINCg0KZG93bmdyYWRpbmcg aXMgbmVlZGVkIGlzIGFib3V0IGdldHRpbmcgbWVzc2FnZXMgZGVsaXZlcmVkIGFueXdheQ0KDQpi dXQsIGlmIGRvd25ncmFkaW5nIGlzIGFwcGxpZWQsIHdlIG5vIGxvbmdlciBleHBlY3QgJ3JlcGxp ZXMnIHRvDQoNCndvcmsgcmVsaWFibHkiPyAgT24gdGhlIG9uZSBoYW5kLCB0aGF0IGlzIGEgZmFp cmx5IGJpZyBzdGVwLg0KDQpCdXQgaXQgaGFzIGEgbG90IG9mIHByZWNlZGVudCAoc29tZSBpbnRl bnRpb25hbCBhbmQgc29tZSBub3QpIGluDQoNCmVtYWlsIHN5c3RlbXMuICBBbmQgaXQgd291bGQg c3dlZXAgYXdheSBhIGxvdCBvZiBpc3N1ZXMsDQoNCmluY2x1ZGluZyBIYXJhbGQncyBleGVtcGxh ciB0cmlhbmd1bGFyIGNhc2UuDQoNCg0KDQpHZW5lcmF0aW5nIGEgaGVhZGVyL21hcmtlciB0byB3 YXJuIHRoZSByZWNpcGllbnQgdGhhdCB0aGUNCg0KaGVhZGVycyBtYXkgbm90IHNob3cgYWxsIHJl Y2lwaWVudHMgYW5kIHRoYXQgInJlcGx5IGFsbCIgbWF5IG5vdA0KDQpyZWFjaCBldmVyeW9uZSB0 byB3aG9tIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdhcyBzZW50IGlzIHByZXR0eQ0KDQplYXN5IChy ZWV4YW1pbmluZyB0aGUgaWRlYSBvZiB1c2luZyBncm91cCBzeW50YXggbWlnaHQgd29yayB3ZWxs DQoNCmhlcmUpLiAgQXMgZmFyIGFzIGFkZHJlc3NlcyBhcmUgY29uY2VybmVkLCBpdCB0dXJucyB0 aGUgZW50aXJlDQoNCmRvd25ncmFkZSBzdG9yeSBpbnRvIGFuIGVudmVsb3BlIG9uZSwgd2hlcmUg d2UgZG9uJ3QgaGF2ZSBzeW50YXgNCg0KcHJvYmxlbXMgKGRvdWJsZSBhbmdsZSBicmFja2V0cyBv ciBvdGhlcndpc2UpLiAgSXQgbWluaW1pemVzDQoNCmxvbmctdGVybSBkYW1hZ2UgZm9yIHNob3J0 LXRlcm0vIHRyYW5zaXRpb25hbCBnYWlucyBhbmQgZ2l2ZXMNCg0KdGhlIHZhcmlvdXMgaHVtYW5z IGludm9sdmVkIGFuIGluY2VudGl2ZSB0byB1cGdyYWRlLiAgIEFuZCBpdA0KDQptYWtlcyB0aGlu Z3MgY29tcGxldGVseSBwcmVkaWN0YWJsZSwgd2hpY2ggeW91J3ZlIGJlZW4gYXNraW5nDQoNCmZv ciwgYXMgbG9uZyBhcyBvbmUgaXMgd2lsbGluZyB0byBjb3VudCAiaWYgeW91IHJlcGx5IHRvIHRo aXMsDQoNCml0IHByb2JhYmx5IHdvbid0IHdvcmsgYXMgeW91IGV4cGVjdCwgYnV0IG5vIG9uZSBw cmV2ZW50cyB5b3UNCg0KZnJvbSB0cnlpbmciIGFzIHByZWRpY3RhYmxlIGJlaGF2aW9yIChJIGFj dHVhbGx5IGRvLCBZTU1EKS4NCg0KDQoNCkkgbm90ZSB0aGF0IHRoZXJlIHdlcmUgbWFueSBleGFt cGxlcyBhbmQgYmFkIGpva2VzIGFib3V0IGJvdGgNCg0KWC40MDAgYW5kIGVhcmx5IHZlcnNpb25z IG9mIEV4Y2hhbmdlIHdob3NlIHN1YnN0YW5jZSB3YXMgdGhhdA0KDQp0aGUgb25seSByZWxpYWJs ZSAicmVwbHkiIG1lY2hhbmlzbSBpbnZvbHZlZCBwaWNraW5nIHVwIGENCg0KdGVsZXBob25lLCBz bywgaW4gcHJhY3RpY2UgKGFuZCBwZXJoYXBzIGV2ZW4gaW4gdGhlb3J5KSwgd2UndmUNCg0KbmV2 ZXIgaGFkIG5lYXJseSB0aGUgc2FtZSBsZXZlbCBvZiBleHBlY3RhdGlvbiBhYm91dCByZXBsaWVz DQoNCndvcmtpbmcgdGhhdCB3ZSd2ZSBoYWQgYWJvdXQgZGVsaXZlcmllcyBnZXR0aW5nIHRocm91 Z2guDQoNCg0KDQpCdXQgaXQgaXMgYSBiaWcgc3RlcC4gIElzIGl0IG9uZSB3ZSBtaWdodCBiZSB3 aWxsaW5nIHRvIGNvbnNpZGVyPw0KDQoNCg0KICAgICBqb2huDQoNCg0KDQoNCg== --_000_E14011F8737B524BB564B05FF748464A026CCFTK5EX14MBXC137red_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQx LUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEz LTAwQUEwMEMxNDg4MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0 IiB4bWxuczp6PSIjUm93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpwdWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOmFjdGl2YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiIHhtbG5zOnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUv IiB4bWxuczpydGM9Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmci IHhtbG5zOkQ9IkRBVjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v cmVwbC8iIHhtbG5zOm10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv c29hcC9tZWV0aW5ncy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29m ZmljZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20v TmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIg eG1sbnM6c3ViPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8y MDAyLzEvYWxlcnRzLyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5j IyIgeG1sbnM6c3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHht bG5zOnNwcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4 bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxu czp1ZGNzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5z OnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHht bG5zOnVkY3AycD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9w YXJ0IiB4bWxuczp3Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29m ZmljZS8yMDA2L2RpZ3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5v cGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczpt dmVyPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxp dHkvMjAwNiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAw NC8xMi9vbW1sIiB4bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3Jn L3BhY2thZ2UvMjAwNi9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0 LmNvbS9zaGFyZXBvaW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFz Lm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNz YWdlcyIgeG1sbnM6cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL1NsaWRlTGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dl YnNlcnZpY2VzL1NoYXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4 bWxuczpaPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxtZXRhIG5h bWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0p Ij4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWFuZ2FsOw0KCXBhbm9zZS0xOjIgNCA1IDMg NSAyIDMgMyAyIDI7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUg OCAzIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQs IGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJ e3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVT IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD5SZTogY2FzaW5nLCBldGMuwqAgVW5saWtlIElETiwgSSB0cmllZCB0 byBtYWtlIGNsZWFyIHRoYXQNCkknbSBzdWdnZXN0aW5nIG5vIG1hcHBpbmcgYmUgZG9uZSBwcmlv ciB0byBlbmNvZGluZywgaXQncyBtZXJlbHkgYW4gZW5jb2RpbmcuIMKgVGhlDQpzZXJ2ZXIgc2lk ZSB3b3VsZCBzdGlsbCBkbyB3aGF0ZXZlciBpdCB3YW50cyB3aXRoIGNhc2luZywgd2hpY2ggbWVh bnMgdGhhdCBpdA0KTVVTVCBkZWNvZGUgaXQgdG8gVW5pY29kZSwgdGhlbiBkbyB3aGF0ZXZlciBt YXBwaW5nIGl0IHdhbnRzLsKgIChEaWZmZXJlbnRseQ0KY2FzZWQgc2jDpHduIGFuZCBTSMOEV04g d291bGQgZ2V0IGRpZmZlcmVudCBlbmNvZGluZ3MgYW5kIGNvdWxkIG5vdCBiZSBjb21wYXJlZA0K aW4gdGhlIGVuY29kZWQgZm9ybS4pwqAgVGhhdCBtYWtlcyBtYXRjaGluZyBvZiB0aGUgQUNFIGZv cm1zIG1vcmUgZGlmZmljdWx0LCBidXQNCmF2b2lkcyBwcm9ibGVtcyB3aXRoIGNhc2luZyBydWxl cyBiZWluZyBpbnRlcnByZXRlZCBkaWZmZXJlbnRseS48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+UmU6IHBhcnRpYWwgZG93bmdyYWRlLsKgIEkgY2Fubm90IGltYWdpbmUgaG93IGFsbG93 aW5nDQptYWlsIHRvIGJlIGRlbGl2ZXJlZCwgYnV0IG5vdCBwcm92aWRpbmcgZm9yIHJlcGxpZXMg dG8gd29yayBpcyBoZWxwZnVsLsKgIFRoZXJl4oCZcw0Kbm8gd2F5IGZvciBhIHNlbmRlciB0byBr bm93IGlmIHRoZXkgd2VyZSBpZ25vcmVkIG9yIGp1c3QgaGFkIGEgbWFpbCBtaXh1cC4gwqBJDQpk b27igJl0IHRoaW5rIHRoYXQgdGhlIOKAnHJlcGx54oCdIGFuZWNkb3RlIHlvdSBkZXNjcmliZSBp cyBhcHByb3ByaWF0ZSBpbiB0aGUgbW9kZXJuDQp3b3JsZC7CoCBXZSBoYXZlIGEgbXVjaCBtb3Jl IHJlbGlhYmxlIHN5c3RlbSBub3cgYW5kIHJlcGx5LWFsbCBpcyBleHBlY3RlZCB0bw0KYmVoYXZl LsKgIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JIHRoaW5rIHRoYXQgZWl0aGVyIHdl IG5lZWQgdG8gaGF2ZSBubyBkb3duZ3JhZGUgYXQgYWxsLA0Kb3Igd2UgbXVzdCBoYXZlIG5lYXJs eS1jb21wbGV0ZSBkb3duZ3JhZGUuwqAgSSBhbHNvIHRoaW5rIHRoYXQgbmVhcmx5LWNvbXBsZXRl DQpkb3duZ3JhZGUgd291bGQgcmVxdWlyZSBhbiBhbGdvcml0aG1pYyB0ZWNobmlxdWUgYXMgd2Xi gJl2ZSBwcmV0dHkgbXVjaCBwcm92ZW4NCnRoYXQgcGFpcmluZyAoYnkgJmx0OyZsdDsmZ3Q7Jmd0 OyBvciBvdGhlciBtZWFucykgYnJlYWtzIHByZXR0eSByYXBpZGx5LjxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD5JIGRvbuKAmXQgdGhpbmsgdGhlIGRvd25ncmFkZSB0ZWNobmlxdWUgZGlz Y3Vzc2lvbiBibG9ja3MNCmFueSBvZiB0aGUgbm9uLWRvd25ncmFkZSBzcGVjcyBmcm9tIHByb2Nl ZWRpbmcuwqAgT2J2aW91c2x5IEVBSSBkb2VzbuKAmXQg4oCcbmVlZOKAnQ0KZG93bmdyYWRlLCBp dCBqdXN0IG1pZ2h0IGVhc2UgdGhlIHRyYW5zaXRpb24uPG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0Pi1TaGF3bjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86 cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEpvaG4gQyBLbGVuc2luIFttYWlsdG86a2xlbnNpbkBq Y2suY29tXSA8YnI+DQpTZW50OiBQb8q7YWtvbHUsIEtlcGFrZW1hcGEgMTYsIDIwMDkgMTI6MzIg UE08YnI+DQpUbzogU2hhd24gU3RlZWxlOyBIYXJhbGQgQWx2ZXN0cmFuZDsgRXJuaWUgRGFpbm93 PGJyPg0KQ2M6IG1hcmtAbWFjY2hpYXRvLmNvbTsgaW1hQGlldGYub3JnPGJyPg0KU3ViamVjdDog UmU6IFtFQUldIFRoaW5raW5nIGFib3V0IHJlcXVpcmVtZW50cyAvIGRvd25ncmFkZTxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRl eHQ+LS1PbiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNiwgMjAwOSAwNjoyNSArMDAwMCBTaGF3bg0K U3RlZWxlPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mbHQ7U2hhd24u U3RlZWxlQG1pY3Jvc29mdC5jb20mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7Li4uPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 Jmd0OyBsZWZ0LWhhbmQgc2lkZXMgaW5kaXNjcmltaW5hdGVseS4gVGhpcyBjYW4gbGVhZA0KdG8g c2ltaWxhcjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsg ZWZmZWN0cyBhcyB0aGUgJnF1b3Q7QnVzaCBoaWQgdGhlIGZhY3RzJnF1b3Q7DQpidWcgKHNlZTxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgaHR0cDovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9CdXNoX2hpZF90aGVfZmFjdHMNCmZvciBkZXRhaWxzKS48bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFl1cC48bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IEJ1dCBJIHRoaW5rIGl0J3Mgd29ydGggdGhlIGltcHJvdmVtZW50IGZvciBi ZWhhdmlvcg0KaW4gdGhlPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDk5Ljk5OSUgY2FzZS7CoCBNYXliZSB3ZSBjb3VsZCBnZXQgc3RhdGlzdGljcyBmb3IgaG93 DQptYW55PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGFjY291 bnQgbmFtZXMgYWN0dWFsbHkgbG9vayBsaWtlIHRoaXMuwqAgQWxzbyB3ZQ0KY291bGQgcGljazxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBzb21ldGhpbmcgcmVh bGx5IHdpZXJkIChsaWtlIHRoZSBxLi1fLnogb3INCnNvbWV0aGluZykuwqAgPG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IElETiBoYWQgdGhlIHNhbWUgaXNzdWUs IGJ1dCBzZWVtcyB0byBoYXZlIHN1Y2NlZWRlZA0KKGF0IGxlYXN0PG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGluIHRoYXQgcmVzcGVjdC4pPG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PlNoYXduLDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5J IGFkZHJlc3NlZCBtb3N0IG9mIHRoaXMgaW4gYSBub3RlIEkgc2VudCBhIGZldyBob3VycyBhZ28N CmFuZDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+dGhhdCBwcm9iYWJs eSBjcm9zc2VkIHlvdXJzIGluIHRoZSBlbWFpbC7CoCBJIHdvbid0IHJlcGVhdA0KbXlzZWxmPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5idXQsIGFzIG90aGVycyBoYXZl IGFsc28gcG9pbnRlZCBvdXQsIHRoZSBpc3N1ZXMgaGVyZSBhcmUNCm11Y2g8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGUgSURO IG9uZXMuwqAgSW4gcGFydGljdWxhciwgb25lDQpvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0Pmlzc3VlcyB0aGF0IGhhcyBnZW5lcmF0ZWQgYSBsb3Qgb2YgdHJh ZmZpYyBvbiB0aGUgSUROQWJpcw0KbGlzdDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+LS0gdGhlIGRlc2lyZSB0byBoYXZlIHVwcGVyLWNhc2UgbGV0dGVycyB0aGF0IGFy ZQ0KcHJvcGVybHk8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm1hanVz Y3VsZXMsIG5vdCBjYXBpdGFscywgaGFuZGxlZCBkaWZmZXJlbnRseSBkZXBlbmRpbmcNCm9uPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5jb250ZXh0LS0gZ2V0cyBhIHJh dGhlciBkaWZmZXJlbnQgYW5zd2VyIGhlcmUgYmVjYXVzZSBvZg0KdGhlPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mcXVvdDtsb2NhbCBwYXJ0cyBnZXQgaW50ZXJwcmV0 ZWQgb25seSBieSB0aGUgZGVsaXZlcnkNCnN5c3RlbSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+cHJpbmNpcGxlLsKgIEZvciBleGFtcGxlLCB3aGlsZSB0aGUg RE5TIGd1YXJhbnRlZXM8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PmNh c2UtaW5zZW5zaXRpdmUgbWF0Y2hpbmcgZm9yIEFTQ0lJIGxhYmVscywgdGhlcmUgYXJlDQphYnNv bHV0ZWx5PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5ubyBndWFyYW50 ZWVzIGluIGVtYWlsIGFib3V0IGNhc2Ugc2Vuc2l0aXZpdHkgb3INCmluc2Vuc2l0aXZpdHkuPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JIGFjdHVhbGx5IHdvcmtzIG9u IGEgc3lzdGVtIHNvbWUgeWVhcnMgYWdvIGluIHdoaWNoDQp0cmFmZmljPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5mb3IsIGUuZy4sIGpvZUBleGFtcGxlLmNvbSB3YXMg dHJlYXRlZCBhcyBtYWlsIHRyYWZmaWMNCmZvciBqb2U8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PndoaWxlIHRyYWZmaWMgZm9yIGpPZUBleGFtcGxlLmNvbSB3YXMgdHJl YXRlZCBhcyBhDQpjb21tYW5kPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5zdHJlYW0gZm9yIG9uZSBvZiBqb2UncyBwcm9jZXNzZXMgb3IgZGFlbW9ucy7CoCBUaGUgaWRl YQ0KZGlkbid0PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5sYXN0IHZl cnkgbG9uZyBmb3Igc2VjdXJpdHkgcmVhc29ucyAtLWFuZCBnb3QgcmVwbGFjZWQgYnk8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm1lbWJlcnMgb2YgdGhlIGZhbWlseSBv ZiB0aGUgbWVzc3kgc3RyaW5ncyBJIGRlc2NyaWJlZC0tDQpidXQgeW91PG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5nZXQgdGhlIGlkZWEuPG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PkkgaGF2ZSB0byBhZ3JlZSB3aXRoIHdoYXQgSSB0aGluayB3YXMgYXQgbGVh c3QgdGhlIGludGVudA0Kb2YgYTxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRl eHQ+cmVjZW50IG5vdGUgb2YgSGFyYWxkJ3MgLS0gZWFjaCBvZiB0aGVzZSBzdWdnZXN0aW9ucw0K bmVlZHM8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PmNhcmVmdWwgYW5h bHlzaXMgYW5kIGV4cGxhbmF0aW9ucyBvZiB3aGF0IGNhc2VzIGV4aXN0LA0Kd2hpY2g8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm9uZXMgJnF1b3Q7d29yayZxdW90OyAo YW5kIHdoYXQgdGhhdCBpbXBsaWVzKSBhbmQgd2hpY2gNCm9uZXMgZmFpbCBhbmQgaW48bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PndoYXQgd2F5cy7CoMKgIFdpdGhvdXQg dGhhdCBzb3J0IG9mIGFuYWx5c2lzLCBhc3NlcnRpbmcNCnRoYXQgYTxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+cGFydGljdWxhciBhcHByb2FjaCB3aWxsIHNvbHZlIHNv bWUgbGFyZ2UgcGVyY2VudGFnZSBvZg0KY2FzZXM8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PmRvZXMgbm90LCBJTU8sIGhlbHAgdXMgdmVyeSBtdWNoIChhbmQgZG9pbmcg c28gaW4gYSBsYXJnZQ0Kc3RyZWFtPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD5vZiBtZXNzYWdlcyBoZWxwcywgYWdhaW4sIElNTywgZXZlbiBsZXNzKS48bzpwPjwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+VGhhdCBzYWlkLCBsZXQgbWUgc3RhdGUgYSBxdWVzdGlvbiB0 aGF0IEkgdGhpbmsgbWlnaHQgYmU8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PmlsbHVtaW5hdGluZywgZXZlbiB0aG91Z2ggSSdtIG5vdCBzdXJlIHdoZXRoZXIgSSB0aGlu aw0Kd2hhdCBpdDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+aW1wbGll cyBpcyBhY2NlcHRhYmxlOjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5TdXBwb3NlIHdl IHdlcmUgd2lsbGluZyB0byBzdGFydCB3aXRoICZxdW90O3RoZSBudW1iZXIgb2YNCmNhc2VzIGlu PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD53aGljaCBkb3duZ3JhZGlu ZyBpcyBuZWVkZWQgd2lsbCBiZSBmYWlybHkgZmV3IGlmIHNlbmRpbmc8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PnN5c3RlbXMgYXJlIGNhcmVmdWxseSBkZXNpZ25lZCBh bmQgY29uZmlndXJlZCBhbmQNCnJlY2VpdmluZzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+c3lzdGVtcyBhbmQgdGhlaXIgTVggaW50ZXJtZWRpYXJpZXMgYXJlIGNvbmZp Z3VyZWQNCmNvcnJlY3RseSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+KHlvdSwgRXJuaWUsIEppYW5rYW5nLCBhbmQgb3RoZXJzLCBpbmNsdWRpbmcgbXlzZWxm LCBoYXZlDQphbGw8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PnNhaWQg dmFyaWF0aW9ucyBvbiB0aGF0KS7CoCBXZSBhbHNvIGFzc3VtZSB0aGF0IHRoZSBudW1iZXINCm9m PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5jYXNlcyBpbiB3aGljaCBp dCBpcyBuZWVkZWQgd2lsbCBnbyBkb3duIG92ZXIgdGltZSwgYXMNCkVBSTxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ZGVwbG95cyBtb3JlIGJyb2FkbHkgYW5kIGFzIHZh cmlvdXMgYWN0b3JzIHVuZGVyc3RhbmQgdGhlPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD5jb25maWd1cmF0aW9uIGlzc3VlcyBiZXR0ZXIuwqAgQ291bGQgd2UgdGhlbiBz YXkNCiZxdW90O3doYXRldmVyPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5kb3duZ3JhZGluZyBpcyBuZWVkZWQgaXMgYWJvdXQgZ2V0dGluZyBtZXNzYWdlcyBkZWxpdmVy ZWQNCmFueXdheTxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+YnV0LCBp ZiBkb3duZ3JhZGluZyBpcyBhcHBsaWVkLCB3ZSBubyBsb25nZXIgZXhwZWN0DQoncmVwbGllcycg dG88bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PndvcmsgcmVsaWFibHkm cXVvdDs/wqAgT24gdGhlIG9uZSBoYW5kLCB0aGF0IGlzIGEgZmFpcmx5DQpiaWcgc3RlcC48bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PkJ1dCBpdCBoYXMgYSBsb3Qgb2Yg cHJlY2VkZW50IChzb21lIGludGVudGlvbmFsIGFuZCBzb21lDQpub3QpIGluPG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5lbWFpbCBzeXN0ZW1zLsKgIEFuZCBpdCB3b3Vs ZCBzd2VlcCBhd2F5IGEgbG90IG9mIGlzc3Vlcyw8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PmluY2x1ZGluZyBIYXJhbGQncyBleGVtcGxhciB0cmlhbmd1bGFyIGNhc2Uu PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PkdlbmVyYXRpbmcgYSBoZWFkZXIvbWFya2Vy IHRvIHdhcm4gdGhlIHJlY2lwaWVudCB0aGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+aGVhZGVycyBtYXkgbm90IHNob3cgYWxsIHJlY2lwaWVudHMgYW5kIHRo YXQgJnF1b3Q7cmVwbHkNCmFsbCZxdW90OyBtYXkgbm90PG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD5yZWFjaCBldmVyeW9uZSB0byB3aG9tIHRoZSBvcmlnaW5hbCBtZXNz YWdlIHdhcyBzZW50IGlzDQpwcmV0dHk8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PmVhc3kgKHJlZXhhbWluaW5nIHRoZSBpZGVhIG9mIHVzaW5nIGdyb3VwIHN5bnRheCBt aWdodA0Kd29yayB3ZWxsPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5o ZXJlKS7CoCBBcyBmYXIgYXMgYWRkcmVzc2VzIGFyZSBjb25jZXJuZWQsIGl0IHR1cm5zIHRoZQ0K ZW50aXJlPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5kb3duZ3JhZGUg c3RvcnkgaW50byBhbiBlbnZlbG9wZSBvbmUsIHdoZXJlIHdlIGRvbid0IGhhdmUNCnN5bnRheDxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+cHJvYmxlbXMgKGRvdWJsZSBh bmdsZSBicmFja2V0cyBvciBvdGhlcndpc2UpLsKgIEl0DQptaW5pbWl6ZXM8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PmxvbmctdGVybSBkYW1hZ2UgZm9yIHNob3J0LXRl cm0vIHRyYW5zaXRpb25hbCBnYWlucyBhbmQNCmdpdmVzPG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD50aGUgdmFyaW91cyBodW1hbnMgaW52b2x2ZWQgYW4gaW5jZW50aXZl IHRvIHVwZ3JhZGUuwqDCoA0KQW5kIGl0PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD5tYWtlcyB0aGluZ3MgY29tcGxldGVseSBwcmVkaWN0YWJsZSwgd2hpY2ggeW91J3Zl IGJlZW4NCmFza2luZzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Zm9y LCBhcyBsb25nIGFzIG9uZSBpcyB3aWxsaW5nIHRvIGNvdW50ICZxdW90O2lmIHlvdQ0KcmVwbHkg dG8gdGhpcyw8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pml0IHByb2Jh Ymx5IHdvbid0IHdvcmsgYXMgeW91IGV4cGVjdCwgYnV0IG5vIG9uZSBwcmV2ZW50cw0KeW91PG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5mcm9tIHRyeWluZyZxdW90OyBh cyBwcmVkaWN0YWJsZSBiZWhhdmlvciAoSSBhY3R1YWxseSBkbywNCllNTUQpLjxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD5JIG5vdGUgdGhhdCB0aGVyZSB3ZXJlIG1hbnkgZXhhbXBsZXMg YW5kIGJhZCBqb2tlcyBhYm91dA0KYm90aDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+WC40MDAgYW5kIGVhcmx5IHZlcnNpb25zIG9mIEV4Y2hhbmdlIHdob3NlIHN1YnN0 YW5jZSB3YXMNCnRoYXQ8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PnRo ZSBvbmx5IHJlbGlhYmxlICZxdW90O3JlcGx5JnF1b3Q7IG1lY2hhbmlzbSBpbnZvbHZlZA0KcGlj a2luZyB1cCBhPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD50ZWxlcGhv bmUsIHNvLCBpbiBwcmFjdGljZSAoYW5kIHBlcmhhcHMgZXZlbiBpbiB0aGVvcnkpLA0Kd2UndmU8 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm5ldmVyIGhhZCBuZWFybHkg dGhlIHNhbWUgbGV2ZWwgb2YgZXhwZWN0YXRpb24gYWJvdXQNCnJlcGxpZXM8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PndvcmtpbmcgdGhhdCB3ZSd2ZSBoYWQgYWJvdXQg ZGVsaXZlcmllcyBnZXR0aW5nIHRocm91Z2guPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PkJ1dCBpdCBpcyBhIGJpZyBzdGVwLsKgIElzIGl0IG9uZSB3ZSBtaWdodCBiZSB3aWxsaW5nIHRv DQpjb25zaWRlcj88bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+wqDCoMKgwqAgam9objxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_E14011F8737B524BB564B05FF748464A026CCFTK5EX14MBXC137red_-- From Shawn.Steele@microsoft.com Wed Sep 16 15:20:30 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD503A6858 for ; Wed, 16 Sep 2009 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0g2bh-OSvGn for ; Wed, 16 Sep 2009 15:20:29 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5AF6F3A6A29 for ; Wed, 16 Sep 2009 15:20:29 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Sep 2009 15:21:19 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Wed, 16 Sep 2009 15:21:19 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Thinking about requirements / downgrade Thread-Index: AQHKNxwDSCjcbFGmQUOMYTyjaWghAQ== Date: Wed, 16 Sep 2009 22:21:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 22:20:30 -0000 U29tZWhvdyBJIG1pc3NlZCBKb2huJ3MgbWVzc2FnZSBlYXJsaWVyIDopDQoNCkkgZ2V0IHlvdXIg cG9pbnQsIEknbSBub3Qgc3VyZSBpdCdzIGdvaW5nIHRvIG1hdHRlciB0byBwZW9wbGUgdHJ5aW5n IHRvIG1pZ3JhdGUgdG8gRUFJIGVtYWlsIHRob3VnaC4gIElmIGFuIGVtYWlsIHByb3ZpZGVyIGlz IHByZXR0eSBzdXJlIHRoZXNlIGRvbid0IGFwcGx5IHRvIHRoZWlyIHNjZW5hcmlvLCB0aGVuIGl0 IG1heSBub3QgaW5mbHVlbmNlIHRoZW0gdGhhdCBzb21lIG90aGVyIHBlcnNvbiBtYXkgZG8gZGlm ZmVyZW50IHRoaW5ncyB3aXRoIElETi1saWtlIHRva2Vucy4uLg0KDQotIFNoYXduDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF0ZTogV2VkLCAxNiBTZXAgMjAwOSAwOTo0Njow NCAtMDQwMA0KRnJvbTogSm9obiBDIEtsZW5zaW4gPGtsZW5zaW5AamNrLmNvbT4NClN1YmplY3Q6 IFJlOiBbRUFJXSBUaGlua2luZyBhYm91dCByZXF1aXJlbWVudHMgLyBkb3duZ3JhZGUNClRvOiBI YXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm8+LAlFcm5pZSBEYWlub3cNCgk8 ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+DQpDYzogTWFyayBEYXZpcyA/IDxtYXJrQG1hY2NoaWF0 by5jb20+LAlTaGF3biBTdGVlbGUNCgk8U2hhd24uU3RlZWxlQG1pY3Jvc29mdC5jb20+LCBpbWFA aWV0Zi5vcmcNCk1lc3NhZ2UtSUQ6IDxDQUVFNUM5RTI1N0ZEOTRGRjlGREVEOUZAUFNULkpDSy5D T00+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkNCg0KDQoNCi0t T24gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMDkgMDg6MTYgKzAyMDAgSGFyYWxkIEFsdmVz dHJhbmQNCjxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4gd3JvdGU6DQoNCj4gRXJuaWUgRGFpbm93IHdy b3RlOg0KPj4gDQo+PiBIYXJhbGQgQWx2ZXN0cmFuZCB3cm90ZToNCj4+PiBUaGUgb3ZlcmFyY2hp bmcgaXNzdWUgZm91bmQgd2l0aCB2YXJpYW50cyBvZiB0aGlzIHByb3Bvc2FsDQo+Pj4gcHJldmlv dXNseSAgcmVqZWN0ZWQgd2FzOg0KPj4+IA0KPj4+IENhbiB3ZSBndWFyYW50ZWUgKGZvciBhIHN1 ZmZpY2llbnRseSBzdHJvbmcgdmVyc2lvbiBvZg0KPj4+ICJndWFyYW50ZWUiKSAgdGhhdCB0aGVy ZSBhcmUgbm8gdmFsaWQgbWFpbGJveGVzIHRoYXQgImp1c3QNCj4+PiBoYXBwZW4gdG8gbG9vayBs aWtlIiB0aGUgIFB1bnljb2RlZCBzdHJpbmdzPw0KDQo+PiBJJ20gbm90IHN1cmUgaXQgaXMgbmVj ZXNzYXJ5IGZvciBhIHN0YW5kYXJkIHRvIGd1YXJhbnRlZQ0KPj4gdGhpcy4gSSB0aGluayAgaXQg aXMganVzdCB0aGUgcmVzcG9uc2liaWxpdHkgb2YgZW1haWwNCj4+IGFkbWluaXN0cmF0aW9uIHRv IGF2b2lkIG5hbWUgIGNvbGxpc2lvbnMuIEN1cnJlbnRseSwgd2hlbiBhDQo+PiBuZXcgZW1haWwg YWRkcmVzcyBpcyByZXF1ZXN0ZWQsIHRoZSAgZW1haWwgYWRtaW5pc3RyYXRvciBmb3INCj4+IHRo ZSBkb21haW4gb24gd2hpY2ggdGhlIG5hbWUgaXMgcmVxdWVzdGVkIChvciAgZW1haWwgYWRtaW4N Cj4+IHNvZnR3YXJlKSB3aWxsIG5vdCBncmFudCB0aGUgZW1haWwgYWRkcmVzcyBpZiAxLiB0aGUg YWRkcmVzcw0KPj4gKGxvY2FsIG5hbWUpIGlzIGFzc2lnbmVkIHRvIHNvbWVvbmUgZWxzZSBvbiB0 aGUgZG9tYWluLiAyLg0KPj4gdGhlIGFkZHJlc3MgaXMgYWxyZWFkeSBpbiB1c2UgYXMgYW4gYWxp YXMgb24gYW5vdGhlciBlbWFpbA0KPj4gYWNjb3VudCAgb24gdGhlIGRvbWFpbi4NCg0KPiBNeSB3 b3JyeSBpcyBhYm91dCB3aGF0IGhhcHBlbnMgaWYgdGhlIHJlY2lwaWVudCB0cmllcyB0bw0KPiBk ZWNvZGUgdGhlIGxlZnQtaGFuZCBzaWRlIGFzIGlmIGl0IHdhcyBhIFB1bnljb2RlZCBuYW1lIHdo ZW4NCj4gaXQgaXMgbm90LiBVbmxlc3Mgb25lIGNhbiB0ZWxsIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhvc2UNCj4gZG9tYWlucyB0aGF0IHVzZSBQdW55Y29kZWQgTEhTIGFuZCB0aG9zZSB0aGF0 IGRvIG5vdCwgYQ0KPiByZWNpcGllbnQgd2lsbCBhcHBseSB0aGUgUHVueWNvZGUgZGVjb2Rpbmcg dG8gbGVmdC1oYW5kIHNpZGVzDQo+IGluZGlzY3JpbWluYXRlbHkuIFRoaXMgY2FuIGxlYWQgdG8g c2ltaWxhciBlZmZlY3RzIGFzIHRoZQ0KPiAiQnVzaCBoaWQgdGhlIGZhY3RzIiBidWcgKHNlZQ0K PiBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0J1c2hfaGlkX3RoZV9mYWN0cyBmb3IgZGV0 YWlscykuDQoNCkxldCBtZSBzYXkgd2hhdCBIYXJhbGQsIEJpbGwsIGFuZCBvdGhlcnMgaGF2ZSBz YWlkIGZyb20gYQ0KZGlmZmVyZW50IHBlcnNwZWN0aXZlIGFuZCBhIGxpdHRsZSBtb3JlIHN0cm9u Z2x5LiAgDQoNCk9uY2UgdXBvbiBhIHRpbWUsIGJlZm9yZSB0aGUgd2ViIGFuZCBiZWZvcmUgd2Ug Y291bGQgYXNzdW1lIHRoYXQNCmFsbW9zdCBldmVyeSBub2RlIGNvbm5lY3RlZCB0byB0aGUgbmV0 d29yayB3YXMgd2VsbC1jb25uZWN0ZWQNCihlbmQgdG8gZW5kKSB3aXRoIGp1c3QgYWJvdXQgZXZl cnkgb3RoZXIgbm9kZSwgIHRoZSBtb3N0IGNvbW1vbg0KbWV0aG9kIGZvciB0cmFuc21pdHRpbmcg Y29tbWFuZCBpbnN0cnVjdGlvbnMgZnJvbSBvbmUgaG9zdCB0bw0KYW5vdGhlciAob3IgYSBkZXZp Y2UgY29ubmVjdGVkIHRvIGFub3RoZXIpIGludm9sdmVkIGVtYWlsDQptZXNzYWdlcyB0aGF0IGNv dWxkIGJlIHJlY2VpdmVkLCBzdG9yZWQsIGFuZCBmb3J3YXJkZWQgYnkNCmludGVybWVkaWFyaWVz LiAgSW4gbWFueSBjYXNlcywgbG9jYWwtcGFydCBhZGRyZXNzZXMgd2VyZSB1c2VkDQp0byBlbmNv ZGUgaW5mb3JtYXRpb24gYW5kIHRvIHNlY3VyZSBhbmQvb3IgYXV0aGVudGljYXRlIHRoZQ0KY29t bWFuZHMgd2l0aCB3aGF0IGFtb3VudGVkIHRvIHNoYXJlZC1zZWNyZXQgZW5jcnlwdGlvbiBhbmQN CmFudGktcmVwbHkgY29kaW5nLg0KDQpJdCBtYXkgYmUgd29ydGggbm90aW5nIHRoYXQgc29tZSB2 ZXJ5IHNpbWlsYXIgdGVjaG5pcXVlcyBoYXZlDQplbWVyZ2VkIGluIHRoZSAiZGVsYXktdG9sZXJh bnQgbmV0d29ya2luZyIgYXJlYS4gIElmIG9uZSBjYW5ub3QNCmRvIGVuZC10by1lbmQgKG9yIGVu ZC10by1jbG9zZWx5LWNvb3JkaW5hdGVkLXN1cnJvZ2F0ZSkNCmhhbmRzaGFrZXMsIHRoZXJlIGFy ZW4ndCB0aGF0IG1hbnkgb3B0aW9ucy4NCg0KVGhvc2UgYXBwbGljYXRpb25zIGxlZCB0byBzb21l IGVtYWlsIGxvY2FsIHBhcnRzIHRoYXQgd2VyZSB0cnVseQ0KYml6YXJyZSBpZiBvbmUgYXNzdW1l ZCB0aGF0IGxvY2FsIHBhcnRzIGFyZSBzb21lIHN0YWJsZQ0KdmFyaWF0aW9uIG9uIGEgdXNlciBu YW1lIG9yIElEL2hhbmRsZS4gIFdvcnNlLCBub3Qgb25seSBhcmUNCnN0cmluZ3MgdGhhdCBsb29r IHJlbWFya2FibHkgbGlrZSBJRE5BIEFDRXMgcGxhdXNpYmxlLCBpdCBpcw0KaW1wb3NzaWJsZSB0 byBkbyB0aGUgZXF1aXZhbGVudCBvZiBzd2VlcGluZyB0aGUgRE5TIHRyZWUgb3INCmlucXVpcmlu ZyBvZiB0b3AtbGV2ZWwgcmVnaXN0cmllcyB0byBnaXZlIHNvbWUgY29uZmlkZW5jZSB0aGF0DQpj aG9pY2VzIGFyZSBiZWluZyBtYWRlIHRoYXQgZG9uJ3QgY29uZmxpY3Qgd2l0aCBleGlzdGluZyB1 c2VzDQooc3VjaCBzd2VlcHMgYW5kIHF1ZXN0aW9ucyB3ZXJlIHBhcnQgb2YgdGhlIHByb2Nlc3Mg b2Ygc2VsZWN0aW5nDQp0aGUgQUNFIHByZWZpeCwgYW5kIHNvbWUgY2FuZGlkYXRlIHByZWZpeGVz IHdlcmUgZWxpbWluYXRlZCBvbg0KdGhlIGJhc2lzIG9mIGV4aXN0aW5nIHVzYWdlKS4NCg0KVGhl cmUgaXMgYXQgbGVhc3QgYW5lY2RvdGFsIGV2aWRlbmNlIHRoYXQgbWV0aG9kcyB1c2luZyBsb2Nh bA0KcGFydHMgdG8gdHJhbnNtaXQgY29tbWFuZCBhbmQgY29udHJvbCBpbmZvcm1hdGlvbiAoZWl0 aGVyIGNvZGVkDQppbnRvIHRoZSBsb2NhbC1wYXJ0IG9yIHVzaW5nIHRoZSBsb2NhbCBwYXJ0IHRv IGF1dGhlbnRpY2F0ZSB0aGUNCm1lc3NhZ2UgcGF5bG9hZCkgaGF2ZSBub3QgZHJvcHBlZCBvdXQg b2YgdXNlLCBldmVuIHRob3VnaCB0aGVpcg0KcHJlc2VuY2UgYXMgYSBwZXJjZW50YWdlIG9mIG1l c3NhZ2VzIG9uIHRoZSBJbnRlcm5ldCBoYXMNCmNlcnRhaW5seSBkcm9wcGVkLg0KDQpGb3IgYmV0 dGVyIG9yIHdvcnNlLCBsaXR0bGUgb2YgdGhpcyBzdHVmZiBpcyB3cml0dGVuIGRvd24gaW4sDQpl LmcuLCB0aGUgUkZDIHNlcmllcy4gIEF0IGxlYXN0IHNvbWUgb2YgdGhlIHJlYXNvbiBpcyB0aGF0 IG1hbnkNCnNpbWlsYXIsIGJ1dCBjZXJ0YWlubHkgbm90IGlkZW50aWNhbCwgbWVjaGFuaXNtcyBo YXZlIGJlZW4NCmludmVudGVkIG92ZXIgYW5kIG92ZXIgYWdhaW4gaW4gZGlmZmVyZW50IHBsYWNl cyBhbmQgcmVseSBvbg0KInNlY3VyaXR5IGJ5IChvZnRlbiByYXRoZXIgZXh0cmVtZSkgb2JzY3Vy aXR5IiwgcmF0aGVyIHRoYW4NCmNyeXB0b2dyYXBoaWMgaW50ZWdyaXR5Li4uIGJ1dCB0aGF0IGRv ZXNuJ3QgbWFrZSB0aGVtIGxlc3MNCnByb2JsZW1hdGljIGZyb20gb3VyIHN0YW5kcG9pbnQuDQoN ClRob3NlIG1lY2hhbmlzbXMgYXJlIGFtb25nIHRoZSByZWFzb25zIHdoeSB0aGUgZW1haWwgY29t bXVuaXR5DQplc3RhYmxpc2hlZCB0aGUgdmVyeSBzdHJvbmcgIm9ubHkgdGhlIHJlY2VpdmluZyBz eXN0ZW0gY2FuDQppbnRlcnByZXQgYSBsb2NhbCBwYXJ0IGFuZCBpdCBNVVNUIE5PVCBiZSBtZXNz ZWQgd2l0aCBpbg0KdHJhbnNpdCIgcnVsZXMgdGhhdCBhcHBlYXIgaW4gUkZDIDUzMjEgYW5kIGl0 cyBwcmVkZWNlc3NvcnMgYW5kDQpoYXMgYmVlbiB1bndpbGxpbmcgdG8gY2hhbmdlIHRoZW0uICBJ TU8sIGV2ZW4gaWYgdGhpcyBXRyByZWFjaGVkDQp0aGUgY29uY2x1c2lvbiB0aGF0IHN1Y2ggdGFn LWlkZW50aWZpZWQgZW5jb2RpbmdzIHdlcmUgYSBnb29kDQppZGVhLCB0aGUgcHJvcG9zYWwgd291 bGQgYmUgZGVzdHJveWVkIG9uIElFVEYgTGFzdCBDYWxsLg0KDQpGaW5hbGx5LCB3aGlsZSBzdWNo IGFkZHJlc3MtZW5jb2RlZCBpbmZvcm1hdGlvbiBpcyBjZXJ0YWlubHkNCnN0aWxsIGluIHVzZSwg dGhlIG9kZHMgb2Ygc2hvd2luZyB1cCBvbiwgZS5nLiwgYSBzZWFyY2ggdGhyb3VnaA0KR29vZ2xl IGRhdGFiYXNlcyBhcmUganVzdCBhYm91dCB6aXAgLS10aGUgZGF0YSBhcmVuJ3QgYXJjaGl2ZWQs DQp0aGUgbWVzc2FnZXMgZG9uJ3QgcmVmZXIgdG8gZWFjaCBvdGhlciwgbWFueSBvZiB0aGUgYWRk cmVzc2VzDQphcmUgb25lLXRpbWUtdXNlLCBhbmQgbmF0dXJhbCBsYW5ndWFnZSBwcm9jZXNzaW5n IG1lY2hhbmlzbXMNCmRvbid0IHdvcmsgYmVjYXVzZSB0aGVzZSBhZGRyZXNzZXMgYXJlIGFib3V0 IGFzIGZhciBmcm9tIG5hdHVyYWwNCmxhbmd1YWdlIGFzIG9uZSBjYW4gZ2V0LiAgQW5kLCBmaW5h bGx5LCBhbnlvbmUgd2hvIGNhbid0DQpkZWRpY2F0ZSBhIGhvc3QsIG9yIGF0IGxlYXN0IGEgZG9t YWluIG9yIHByaW1hcnkgYWRkcmVzcyBhbmQNCmZhbWlseSBvZiBzdWJhZGRyZXNzZXMsIHVuZGVy IHRoZWlyIGNvbnRyb2wgdG8gdGhlIHBhcnRpY3VsYXINCmNvbnRyb2wgdGFza3MgYXQgaXNzdWUg aXMganVzdCBub3QgaW4gdGhlIGdhbWUuLi4gc28gdGhlIG1vcmUNCnJlbGV2YW50IGFuZCBzb3Bo aXN0aWNhdGVkIG1ldGhvZHMgYXJlIG5vdCB1c2luZyBwdWJsaWMvZnJlZQ0KZW1haWwgc3lzdGVt cyBvZiB0aGUgQU9MLyBIb3RtYWlsLyBHbWFpbC8gWWFob28vIGV0YyBwZXJzdWFzaW9ucy4NCg0K SXQganVzdCBpc24ndCBhIHdvcnRod2hpbGUgcGF0aCB0byB0cnkgdG8gZm9sbG93Lg0KDQogICAg ICBqb2huDQoNCg== From Shawn.Steele@microsoft.com Wed Sep 16 16:18:49 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5D528C1DC for ; Wed, 16 Sep 2009 16:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+qFZdxxGHer for ; Wed, 16 Sep 2009 16:18:48 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5193D3A6905 for ; Wed, 16 Sep 2009 16:18:48 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Sep 2009 16:19:38 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Wed, 16 Sep 2009 16:19:36 -0700 From: Shawn Steele To: Ernie Dainow Thread-Topic: [EAI] Thinking about requirements / downgrade Thread-Index: AQHKNSEJ/2Jg2W1k4k2n/aUL3Uziq5DYsPqAgACEkYD//4vCgoAA4+uAgAALVDA= Date: Wed, 16 Sep 2009 23:19:15 +0000 Message-ID: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info>,<4AB082BD.8070301@alvestrand.no> <4AB0E06B.20609@ca.afilias.info> In-Reply-To: <4AB0E06B.20609@ca.afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ima@ietf.org" , "mark@macchiato.com" Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 23:18:49 -0000 PiBMb2NhbCBuYW1lcyBhcmUgbm90IGRlY29kZWQgdW50aWwgdGhleSBhcnJpdmUgYXQgdGhlIGRl c3RpbmF0aW9uIGRvbWFpbi4gDQo+IEF0IHRoYXQgcG9pbnQsIGlmIGEgbWFpbGJveCBleGlzdHMg Zm9yIHRoZSBsb2NhbCBuYW1lLCBpdCBpcyBkZWxpdmVyZWQuIA0KPiBPbiBFQUkgc3lzdGVtcywg aWYgdGhhdCBtYWlsYm94IGRvZXMgbm90IGV4aXN0LCB0aGVuIHRoZSBuYW1lIGlzIGRlY29kZWQg DQo+IGFuZCBhIHNlY29uZCBkZWxpdmVyeSBpcyBhdHRlbXB0ZWQgdG8gdGhlIFVURjggbWFpbGJv eC4gSWYgdGhlIGNoZWNrcyANCj4gb3V0bGluZWQgZWFybGllciBhcmUgZm9sbG93ZWQgd2hlbiBj cmVhdGluZyBuZXcgbWFpbGJveGVzLCBkZWxpdmVyeSB3aWxsIA0KPiBuZXZlciBnbyB0byBkaWZm ZXJlbnQgdXNlcnMgZm9yIHRoZXNlIHR3byBjYXNlcy4NCg0KVGhhdCdzIHdoZXJlIHRoZXJlJ3Mg Y29uZnVzaW9uLiAgVGhlcmUgaXMgYW5vdGhlciBzY2VuYXJpbyB3aGVyZSBhbiBFQUkgYXdhcmUg c3lzdGVtIG1haWxzIHRvIGEgbm9uLWF3YXJlIHN5c3RlbSwgaG93ZXZlciB0aGUgY2xpZW50IG9u IHRoYXQgc2lkZSBpcyBFQUkgYXdhcmUuICBJbiB0aGF0IGNhc2UsIGl0IGlzIHBvc3NpYmxlIHRo YXQgdGhlIGNsaWVudCB3b3VsZCB3YW50IHRvIHVwZ3JhZGUgdGhlIG1lc3NhZ2UgZm9yIGRpc3Bs YXkuDQoNCg0KICANCg0KSSdtIGdvaW5nIHRvIGRlc2NyaWJlIHRoZSB0aGlua2luZyBvZiBhIHZl bmRvciB0cnlpbmcgdG8gY3JlYXRlIGFuIGVuZC10by1lbmQgc29sdXRpb24uICBTaW5jZSBiZWF0 aW5nIGFyb3VuZCB0aGUgYnVzaCBkaWRuJ3Qgd29yaywgSSB3aWxsIG5hbWUgTWljcm9zb2Z0IHBy b2R1Y3RzIGV4cGxpY2l0bHksIChUaGF0IGRvZXNuJ3QgbWVhbiB3ZSdyZSBkb2luZyB0aGlzLCBh bHRob3VnaCBpdCdzIHByZXR0eSBvYnZpb3VzIHdlJ3JlIHRoaW5raW5nIGFib3V0IGl0LikgIFBs ZWFzZSByZXBsYWNlIHRoZSBNaWNyb3NvZnQgcHJvZHVjdHMgd2l0aCB5b3VyIGZhdm9yaXRlIHZl bmRvcihzKSBiZWNhdXNlIG90aGVyIHZlbmRvcnMgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtcyBhbmQg aGF2ZSB0aG91Z2h0IGFib3V0IHRoaXMgYXMgd2VsbC4NCiANCkFzIGEgYnVzaW5lc3MsIHdlJ2Qg bGlrZSB0byBwcm92aWRlIEVBSSBzb2x1dGlvbnMuICBJdCdkIGJlIGNvb2wgJiBzb2x2ZSBhIHJl YWwgY3VzdG9tZXIgbmVlZC4gIEhvd2V2ZXIgcGVvcGxlIGFuZCBidXNpbmVzc2VzIGRvbid0IHVw Z3JhZGUgRXhjaGFuZ2UgYW5kIE91dGxvb2sgZXZlcnkgZGF5LiAgQWxzbyB3ZSBoYXZlIExpdmUg bWFpbCBhbmQgd2ViIGJhc2VkIGZyb250IGVuZHMgdG8gY29uc2lkZXIuDQoNClByZXN1bWFibHkg YXQgbGVhc3Qgc29tZSBvZiBvdXIgY3VzdG9tZXJzIHdhbnQgaW50ZXJuYXRpb25hbCBhZGRyZXNz ZXMuICBXZSdyZSBwcmV0dHkgbXVjaCBjZXJ0YWluIHRoYXQgdGhleSdsbCB3YW50IHJlbGlhYmxl IGVtYWlsIHNlcnZpY2UgYXMgd2VsbC4gIElmIGFuIEV4Y2hhbmdlIHNpdGUgaXMgZ29pbmcgdG8g dXBncmFkZSB0byBFQUksIHRoZXkncmUgZ29pbmcgdG8gd2FudCB0byBtYWtlIHN1cmUgdGhhdCBp dCBwbGF5cyB3ZWxsIHdpdGggb3RoZXIgRXhjaGFuZ2Ugc2l0ZXMsIHdpdGggT3V0bG9vayBjbGll bnRzLCBldGMuICBJbiBzb21lIGNhc2VzIGFuIGVudGlyZSBlbnRlcnByaXNlIGlzIHVzaW5nIE1p Y3Jvc29mdCBwcm9kdWN0czsgT3V0bG9vayBjbGllbnRzIHRhbGtpbmcgdG8gRXhjaGFuZ2Ugc2Vy dmVycywgZXRjLg0KDQpJZiBvdXIgY3VzdG9tZXJzIHdhbnQgdG8gdXBncmFkZSB0aGVpciBUb2t5 byBvZmZpY2UgdG8gc3VwcG9ydCBFQUkgYnV0IGNhbid0IGFmZm9yZCB0byB1cGRhdGUgdGhlaXIg VVMgc2VydmVycyByaWdodCBub3csIHdoYXQgd291bGQgYSBNaWNyb3NvZnQgc29sdXRpb24gbG9v ayBsaWtlPw0KIA0KVGhlIG90aGVyIGRvd25ncmFkZSB0ZWNobmlxdWVzIHRoYXQgaGF2ZSBiZWVu IHByb3Bvc2VkIGZhaWwgaW4gZmFyIHRvbyBtYW55IGNhc2VzIGZvciB1cyB0byBoYXZlIHNhdGlz ZmllZCBjdXN0b21lcnMuICBJdCBkb2Vzbid0IG1hdHRlciBpZiA5MCUgb2YgdGhlaXIgbWFpbCBz dWNjZWVkcywgaWYgMSUgZmFpbHMgd2l0aG91dCBhbnkgd2FybmluZy4gIEV2ZW4gc3RheWluZyBv biB0aGUgc2FtZSB2ZW5kb3IncyBwcm9kdWN0cyB3b24ndCBoZWxwIGJlY2F1c2Ugb2YgdGhlIG90 aGVyIGRvd25ncmFkZSB0ZWNobmlxdWVzIGhhdmUgZnVuZGFtZW50YWwgZmxhd3MuDQoNCkluIHRo YXQgY2FzZSwgYSB3b3JrYXJvdW5kIGNvdWxkIGJlIHRvIHVzZSBhbiBhbGdvcml0aG1pYyBlbmNv ZGluZy4gIFRoZW4gY3VzdG9tZXJzIHVzaW5nIE91dGxvb2sgb3IgTGl2ZSBNYWlsIGNvdWxkIHRh bGsgdG8gdGhlc2UgaW1wcm92ZWQgRUFJIEV4Y2hhbmdlIHNlcnZlcnMgYW5kIGludGVyb3BlcmF0 ZSwgcmVnYXJkbGVzcyBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUgaW4tYmV0d2Vlbi4gIFNvIHRoaXMg d291bGQgcHJvdmlkZSBhIGZhaXJseSByb2J1c3QgZW5kLXRvLWVuZCBzb2x1dGlvbiBmb3IgY3Vz dG9tZXJzIHRoYXQgdXNlZCBvdXIgcHJvZHVjdHMuICBJdCB3b3VsZCBwcm9iYWJseSBhbHNvIGhl bHAgb3VyIGN1c3RvbWVycyBpcyBhIGZldyBjYXNlcyBldmVuIHdoZW4gc29tZSBvZiB0aGUgaW5m cmFzdHJ1Y3R1cmUgd2FzIG9uIG90aGVyIHBsYXRmb3Jtcy4NCg0KSW4gYW4gRUFJLXN1cHBvcnRp bmcgRXhjaGFuZ2UvT3V0bG9vayBlbnZpcm9ubWVudCBpdCdkIGJlIHJlYWxseSBuaWNlIGlmIG5v bi1NaWNyb3NvZnQgcHJvZHVjdHMgaW50ZXJvcGVyYXRlZCBhcyB3ZWxsLCBidXQgZXZlbiBpZiBt YWlsIHRvIGEgZGlmZmVyZW50IHBsYXRmb3JtIGZhaWxlZCwgYXQgbGVhc3QgdGhlIGJvdW5kYXJ5 IHdvdWxkIGJlIHByZXR0eSBjbGVhci4gIEN1c3RvbWVycyBjb3VsZCBzdGlsbCBoYXZlIHNvbHV0 aW9ucyB0aGF0IHdvcmtlZCB3aXRoaW4gdGhlaXIgZW50ZXJwcmlzZSwgZXZlbiBpZiBleHRlcm5h bCBtYWlsIHJhbiBpbnRvIHRoZSBuby1kb3duZ3JhZGUgb3IgcGFydGlhbC1kb3duZ3JhZGUgZXhw ZXJpZW5jZSB3aGVuIHRhbGtpbmcgdG8gbm9uLU1pY3Jvc29mdCBwcm9kdWN0cy4NCg0KQXMgSSBt ZW50aW9uZWQsIHdlJ3JlIG5vdCB0aGUgb25seSBvbmVzIHRoaW5raW5nIGFsb25nIHRoZXNlIGxp bmVzLCByZXBsYWNlIG91ciBwcm9kdWN0cyB3aXRoIG91ciBjb21wZXRpdG9ycycgYWJvdmUuICBJ ZiB3ZSBjYW4gcHJvdmlkZSBhIG1vcmUgcm9idXN0IHNvbHV0aW9uIHdpdGggb3VyIHByb2R1Y3Rz LCB0aGVuIHdlJ3JlIGluY2xpbmVkIHRvIGNvbnNpZGVyIGl0LiAgT3VyIGNvbXBldGl0b3JzIGFy ZS4gIEknZCBwcmVmZXIgYSBzb2x1dGlvbiB0aGF0IGludGVyb3BlcmF0ZXMgYXMgbXVjaCBhcyBw b3NzaWJsZSB0aG91Z2guDQoNCldoZW4gY29uc2lkZXJpbmcgYSBzb2x1dGlvbiB0aGF0IHdvcmtz IHdpdGhpbiBvdXIgcHJvZHVjdCBsaW5lLCB0aGUgcHJvYmxlbSBpcyBzaW1wbGVyLiAgV2UgZG9u J3QgaGF2ZSB0byB3b3JyeSBhYm91dCBzdHJhbmdlIHhuLS0gY29kZXMgcnVubmluZyBzY3JpcHRz IGJlY2F1c2Ugb3VyIHN0dWZmIGRvZXNuJ3QgZG8gdGhhdC4gIE5laXRoZXIgZG8gbW9zdCBvZiBv dXIgY29tcGV0aXRvcnMnIHByb2R1Y3RzLiAgSSBjYW4gcmVhZGlseSBzZWUgd2hlcmUgYW4gb2xk IFVuaXg/IGJveCB0aGF0IHJhbiBzY3JpcHRzIGZyb20gZW1haWwgYWRkcmVzc2VzIHdvdWxkbid0 IHdhbnQgdG8gdXNlIHRoaXMgbWVjaGFuaXNtLCBidXQgdGhleSBkb24ndCBoYXZlIHRvLiAgSSdt IHN1Z2dlc3RpbmcgaXQgYXMgYW4gb3B0aW9uYWwgd29yc3QtY2FzZSBmYWxsYmFjay4NCg0KVGhl cmUncyBub3RoaW5nIGluIHRoZSBjdXJyZW50IEVBSSBSRkNzIHRoYXQgcHJvaGliaXRzIGFsZ29y aXRobWljIGdlbmVyYXRpb24gb2YgYW4gQVNDSUkgYWRkcmVzcywgYWRkcmVzcyBnZW5lcmF0aW9u IGlzIGxlZnQgdG8gdGhlIHNlcnZlci4gIEkgaW1hZ2luZSB0aGF0IGZhbGxiYWNrIHdvdWxkIGxv b2sgc29tZXRoaW5nIGxpa2U6DQoNCjEpIFVzZSBFQUkNCjIpIElmIEkgY2FuJ3QgdXNlIEVBSSwg dHJ5IHRvIHVzZSBodW1hbi1yZWFkYWJsZSBBU0NJSSAoYXNzdW1pbmcgSSBrbm93IGVub3VnaCkN CjMpIElmIEkgY2FuJ3QgZG8gdGhhdCwgdXNlIHRoZSB3b3JzdC1jYXNlLCBsYXN0LXJlc29ydCBQ dW55Y29kZSBtZWNoYW5pc20uICBMaWtlIGZvciBmaWVsZHMgdGhhdCBkb3duZ3JhZGUgZG9lc24n dCBhZGRyZXNzIGZ1bGx5Lg0KDQpJIGdldCB0aGF0IGFsZ29yaXRobWljIGRvd25ncmFkZSBtaWdo dCBub3Qgd29yayBmb3IgYWxsIGVudmlyb25tZW50cywgYnV0IEkgdGhpbmsgdGhhdCB3aGVuIHZl bmRvcnMgbG9vayBhdCB0aGVpciBvZmZlcmluZ3MgdGhleSdsbCB0cnkgdG8gcHJvdmlkZSBhIGNv bXBsZXRlIGVuZC10by1lbmQgc29sdXRpb24uICBJbiBtb3N0IGNhc2VzIHRoZSBhbGdvcml0aG1p YyB0ZWNobmlxdWUgd2lsbCB3b3JrLiAgSW4gb3RoZXIgY2FzZXMgaXQgc2hvdWxkbid0IGJlIHVz ZWQuDQoNCkkndmUgaGVhcmQgZmVlZGJhY2sgdGhhdCB4bi0tIG9yIGFueSBvdGhlciBwcmVmaXgg aXMgZ29pbmcgdG8gdHJpcCB1cCBzb21lIGVzb3RlcmljIHBhcnQgb2YgdGhlIHN5c3RlbSAoeW91 IGRvbid0IHJlYWxseSBuZWVkIHRvIHF1ZXJ5IGV2ZXJ5IG1haWwgc2VydmVyIHRvIHJlYWxpemUg dGhhdCB6Li1fLiwgb3IgZXZlbiB4bi0tLCBpcyByYXJlbHkgZW5jb3VudGVyZWQgaW4gZW1haWwp LiAgSSdtIG5vdCBzdWdnZXN0aW5nIHRoYXQgdGhpcyBpcyBhIHBlcmZlY3Qgc29sdXRpb24gZm9y IGV2ZXJ5IGVudmlyb25tZW50LCBvbmx5IHRoYXQgaXQgd2lsbCB3b3JrIGluIG1hbnkgZW52aXJv bm1lbnRzLg0KDQpVbmxlc3MgZG93bmdyYWRlIGNhbiBiZSBzb2x2ZWQgcGVyZmVjdGx5IHNvbWUg b3RoZXIgd2F5LCBJIGJlbGlldmUgdGhhdCBzb21lIHNvZnR3YXJlIHZlbmRvcnMgd2lsbCBpbXBs ZW1lbnQgc3VjaCBhIGxhc3QtcmVzb3J0IGFsZ29yaXRobWljIHNvbHV0aW9uLg0KDQoxKSBBcmUg dGhlcmUgYW55IHBsYWNlcyB3aGVyZSBhbGdvcml0aG1pYyBBU0NJSSBhZGRyZXNzZXMgdGhhdCB3 aWxsIGZhaWwgd29yc2UgdGhhbiB0aGUgbm9uLWRlbGl2ZXJ5IGNhc2Ugb3IgcGFydGlhbC1zdXBw b3J0IGNhc2U/ICBJIGNhbid0IHRoaW5rIG9mIGFueToNCiogSWYgSSBzdXBwb3J0IFB1bnljb2Rl IG1haWxib3hlcywgdGhlbiBJIGNhbiBhc3NpZ24gdGhlbSBpbiBhIHdheSB0aGF0IGFsaWFzaW5n IGlzbid0IGEgcHJvYmxlbS4NCiogSWYgeW91IGRvbid0IHN1cHBvcnQgUHVueWNvZGUgbWFpbGJv eGVzLCBidXQgbXkgbWFpbGVyIHRyaWVzIHRvIHNlbmQgbWFpbCB0aGF0IHdheSwgdGhlbiBlaXRo ZXI6DQoJYSkgWW91IGRvbid0IGdldCB0aGUgbWFpbCBiZWNhdXNlIHRoZXJlJ3Mgbm8gc3VjaCBt YWlsYm94LA0KCWIpIFRoZSBtYWlsIGdvZXMgc29tZXdoZXJlIGVsc2UsIGxpa2UgdG8gYSBkaWZm ZXJlbnQgbWFpbGJveC4gIFRoaXMgaXMgc2ltaWxhciB0byBhIG1pc2RpcmVjdGVkIGZheCBvciBh IHR5cG8gaW4gYW4gZW1haWwgYWRkcmVzcyB0b2RheS4gIEkgY2FuJ3QgdHJ1c3Qgc2Nvb2J5ODc4 N0BsaXZlLmNvbSBiZWNhdXNlIEkgbWlnaHQgaGF2ZSBnb3QgaXQgd3JvbmcgYW5kIGl0IHdhcyBy ZWFsbHkgc2Nvb2J5Nzg3OEBsaXZlLmNvbS4gIElmIEkndmUgbmV2ZXIgbWFpbGVkIHRoZXJlIGJl Zm9yZSB0aGVyZSdzIG5vIGd1YXJhbnRlZSBpdCdsbCBiZWhhdmUuICBJZiBJIHRydXN0IHRoZSBh ZGRyZXNzIGFzIHdvcmtpbmcsIHRoZW4gSSBrbm93IGl0IHdvcmtzLg0KCWMpIEFwcGFyZW50bHkg aXQgY291bGQgYWxzbyBydW4gYSBqb2Igc29tZXdoZXJlIG9yIGRvIHNvbWV0aGluZyBlbHNlIGlu dGVyZXN0aW5nLiAgSW4gdGhhdCBjYXNlIGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciBob3cgSSBz ZW50IG1haWwgdG8gdGhhdCBhZGRyZXNzIHNpbmNlIEkgY291bGQndmUgZG9uZSBpdCBkaXJlY3Rs eSBhbnl3YXkuICBJJ20gbm90IHN1cmUgaG93IHRoaXMgbWFrZXMgdGhlIHB1bnljb2RlIHRlY2hu aXF1ZSBhbnkgcmlza2llciwgdGhhdCBzeXN0ZW0gYWxyZWFkeSBoYXMgYSBwcmV0dHkgc2VyaW91 cyBzZWN1cml0eSBwcm9ibGVtLg0KDQoyKSBJIHJlYWxpemUgaXQncyBub3QgdGhlIHJpZ2h0IHNv bHV0aW9uIGZvciBldmVyeW9uZSwgYnV0IGlzIHRoZXJlIGFuIG9iamVjdGlvbiB0byBtZSBjcmVh dGluZyBhbiBPUFRJT05BTCBsYXN0LXJlc29ydCBkcmFmdCBmb3IgYXBwbGljYXRpb25zIHRoYXQg dGhpbmsgdGhleSBuZWVkIGl0PyAgVGhlbiBldmVuIGlmIHRob3NlIGFwcGxpY2F0aW9ucyBhcmUg YmVpbmcgc3R1cGlkLCBhdCBsZWFzdCB0aGV5J2xsIGFsbCBiZSBzdHVwaWQgaW4gYSBwcmVkaWN0 YWJsZSBhbmQgY29uc2lzdGVudCBtYW5uZXIuDQoNCi1TaGF3bg0KDQo= From McQuilWP@pobox.com Wed Sep 16 16:57:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8313A690A for ; Wed, 16 Sep 2009 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofj4VAjAToEa for ; Wed, 16 Sep 2009 16:57:42 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 2ACD43A683C for ; Wed, 16 Sep 2009 16:57:41 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8EF25537B8; Wed, 16 Sep 2009 19:58:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=OYIFHi2Xv7Eo f3prgape+Jyqum4=; b=BjCn6TjUVubT2pINYNZZSEDTRtW3jK+xP9Il+Nir9lkA 9xpWFyTlMckWIcw9Z9HOWTBqYIkqAUhS8ts/AnSuTsUOhmxtk0CTDjAhIvwjDcyD XqwTKJdQ9h9XUvVuAMUUQOlHKGuAwQKcMxfJNhTr8X/bpblG9qPqCm+1f8q4p1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=jRbMq0 GrW6IACWcmMCX0gI/TnqHvqiyJutIKiYr1F6GiSDgoc1EbW4/GKDPDwh6dWCk99i N3n9o4akrcpO7CHcPiN+zSODex4JkDQxRqtxck1Xg7QU/oWKrkgwJ87dyre7Tubw Hd3OQvyQhpDF1LZrpRVdhmF5PBAWaSRbIgD8w= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7EFA9537B7; Wed, 16 Sep 2009 19:58:30 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.60.165]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPA id A570D537B6; Wed, 16 Sep 2009 19:58:28 -0400 (EDT) Date: Wed, 16 Sep 2009 16:58:27 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1063145533.20090916165827@pobox.com> To: IMA Discussion In-Reply-To: References: <04EA2C8DA30B414374C673EB@PST.JCK.COM> <4AA6CCBB.1070804@ca.afilias.info> , <4AA7A649.5000903@ca.afilias.info> <4AA7F35E.7080906@ca.afilias.info> <4AAE11DE.5030608@alvestrand.no> <4AB01389.6030607@ca.afilias.info>, <4AB082BD.8070301@alvestrand.no> <4AB0E06B.20609@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 X-Pobox-Relay-ID: D58A8F84-A31C-11DE-8229-8B19076EA04E-02871704!a-pb-sasl-sd.pobox.com Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Thinking about requirements / downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 23:57:43 -0000 On Wed, 2009-09-16, Shawn Steele wrote: >> Local names are not decoded until they arrive at the destination domai= n. >> At that point, if a mailbox exists for the local name, it is delivered= .=20 >> On EAI systems, if that mailbox does not exist, then the name is decod= ed >> and a second delivery is attempted to the UTF8 mailbox. If the checks=20 >> outlined earlier are followed when creating new mailboxes, delivery wi= ll >> never go to different users for these two cases. > That's where there's confusion. There is another scenario where an > EAI aware system mails to a non-aware system, however the client on tha= t > side is EAI aware. In that case, it is possible that the client would > want to upgrade the message for display. =20 > I'm going to describe the thinking of a vendor trying to create an > end-to-end solution. Since beating around the bush didn't work, I will > name Microsoft products explicitly, (That doesn't mean we're doing this= , > although it's pretty obvious we're thinking about it.) Please replace > the Microsoft products with your favorite vendor(s) because other vendo= rs > have the same problems and have thought about this as well. > 1) Are there any places where algorithmic ASCII addresses that will > fail worse than the non-delivery case or partial-support case? I can't > think of any: > * If I support Punycode mailboxes, then I can assign them in a way that= aliasing isn't a problem. > * If you don't support Punycode mailboxes, but my mailer tries to send = mail that way, then either: > a) You don't get the mail because there's no such mailbox, > b) The mail goes somewhere else, like to a different mailbox. This > is similar to a misdirected fax or a typo in an email address today. I > can't trust scooby8787@live.com because I might have got it wrong and i= t > was really scooby7878@live.com. If I've never mailed there before > there's no guarantee it'll behave. If I trust the address as working, > then I know it works. > c) Apparently it could also run a job somewhere or do something else > interesting. In that case it doesn't really matter how I sent mail to > that address since I could've done it directly anyway. I'm not sure ho= w > this makes the punycode technique any riskier, that system already has = a > pretty serious security problem. > 2) I realize it's not the right solution for everyone, but is there an > objection to me creating an OPTIONAL last-resort draft for applications > that think they need it? Then even if those applications are being > stupid, at least they'll all be stupid in a predictable and consistent > manner. It seems to me that the potential damage only occurs when an algorthmical= ly downgraded address is received by an MX in which the algorithmically modified local part might be interpreted in some fashion other than as a downgraded address. This is only for addresses local to that domain, sinc= e all others would be treated as opaque by an eai-UNaware server. I think that this implies that, if a common, algorithmically determined aliasing system is allowed, then when a domain decides to implement ima, = it must examine such conventions within itself and make sure that it does no= t use any that would conflict with the algorithm. This seems to narrow the area of conflict somewhat. --=20 Bill McQuillan From jyee@ca.afilias.info Thu Sep 17 06:23:32 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E283A6AA2 for ; Thu, 17 Sep 2009 06:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlV8RzVLYRJw for ; Thu, 17 Sep 2009 06:23:31 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 9EE5D28C0D9 for ; Thu, 17 Sep 2009 06:23:31 -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 1MoGy4-0001ct-3M; Thu, 17 Sep 2009 13:24:12 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MoGy3-00015j-5w; Thu, 17 Sep 2009 13:24:11 +0000 From: Joseph Yee To: Alexey Melnikov In-Reply-To: <4AAA20BD.1060904@isode.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 09:24:11 -0400 X-Mailer: Apple Mail (2.936) Cc: Pete Resnick , barryleiba@computer.org, EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:23:32 -0000 On 11-Sep-09, at 6:04 AM, Alexey Melnikov wrote: > Barry Leiba wrote: > >>> (As the responsible AD) After rereading various pieces of the >>> document, I >>> agree this is not clear. >>> >>> >>> (As a WG participant) Here is my understanding how things should >>> work: >>> >>> UTF8=USER is useful by itself, so I think it should be independent >>> of all >>> other UTF8* capabilities. For example it should be possible to >>> only support >>> UTF8=USER (non EAI IMAP server, but which accepts UTF-8 >>> usernames/passwords), or support all other EAI functions, without >>> supporting >>> UTF-8 username/password (e.g. a legacy authentication database). >>> >>> I think UTF8=APPEND should be independent of other UTF8* >>> capabilities. >>> Allowing for EAI APPEND might require quite a bit of extra work. >>> >>> Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can >>> either >>> define them as implying UTF8, or say that if one of them is >>> advertised, then >>> UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies >>> UTF8=ALL. >>> One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be >>> Ok either >>> way, but one way or another this needs to be stated explicitly. >>> > [All my responses with either IMAP server or client implementor hat > on:] > >> The more I think about it, the more I think that having a "UTF8" >> capability string as well as "UTF8=xxx" strings creates a confusing >> situation, particularly when one or more of the others implies the >> former. >> > Agreed. > In fact, I think implied IMAP capabilities should be avoided. Maybe we need to reword the last paragraph at section 7. Saying something like UTF8=ONLY "covers" or "is superset of " functions UTF8, UTF8=ALL and UTF8=APPEND. > >> Here's what I suggest: >> >> Define the capability as "UTF8=x,y,z", where the bit after the "=" >> (let's call them "UTF8 subcapabilities") can be some combination of >> ACCEPT, APPEND, USER, ALL, and ONLY. Put this definition into a >> section that goes between the current sections 2 and 3, and say that >> the UTF8 subcapabilities are defined in the sections below, and that >> some of them may imply others. >> >> Note, too, that this does not extend the grammar for capability >> strings. RFC 3501 defines "capability" to be "atom", and the "," >> character is permitted in an atom. it may require a small tweak to >> the registry, though. >> > This concerns me a bit. Existing IMAP capabilities are just single > tokens (with the exception of RIGHTS= defined in RFC 4314), so they > can be used for hash table lookups or direct string comparison. What > you are suggesting is that we change that. > > Note that the rest of your proposal seems sensible to me. I would prefer to keep with style defined so far for IMAP, but I don't mind either way. Best, Joseph > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From harald@alvestrand.no Sun Sep 20 11:55:37 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C3E3A69BC for ; Sun, 20 Sep 2009 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KuSzqquFo-i for ; Sun, 20 Sep 2009 11:55:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 371693A68D2 for ; Sun, 20 Sep 2009 11:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0906F39E1A7; Sun, 20 Sep 2009 20:56:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ivu-YvotxR; Sun, 20 Sep 2009 20:56:30 +0200 (CEST) Received: from [192.168.0.12] (c83-250-103-72.bredband.comhem.se [83.250.103.72]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 521F139E162; Sun, 20 Sep 2009 20:56:30 +0200 (CEST) Message-ID: <4AB67A8C.2090202@alvestrand.no> Date: Sun, 20 Sep 2009 20:55:08 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Joseph Yee References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , barryleiba@computer.org, EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 18:55:37 -0000 My sense of the WG is that the WG doesn't feel that being creative in how IMAP options are specified is something this WG wants. Let's stay with UTF8=keyword tokens, and make sure we have documented what implies what. Harald, with his WG chair hat on. From barryleiba.mailing.lists@gmail.com Sun Sep 20 14:08:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209FF3A67F7 for ; Sun, 20 Sep 2009 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiPKoXVKfSPc for ; Sun, 20 Sep 2009 14:08:42 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 5594F3A6811 for ; Sun, 20 Sep 2009 14:08:42 -0700 (PDT) Received: by ywh4 with SMTP id 4so3126832ywh.6 for ; Sun, 20 Sep 2009 14:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=AH5j2aOX6gAnJx3hPG3mxjwcqT5/auSaBJhsYexQ/SA=; b=pEckZ37Sa5FfC9hcR6LUUFC8K+KOb/Jt76uH/QnO/L8qkO4AeVXZRTBIgaO4kxYyxh 8LPPkwIlg0YQSMpYsfM++/LLM18UcI3FRNZMCxU+sxJQ03wObALVpnzPCRmy3ILSr9AM Dxqy+xKoOHXMd5QAYTsYqyWRXjL5unCdDgxHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=nwnrp1TR7N6Csn8Y3HU1ccZ5EKrd0l7JHaLSl2sFNQbS1Rxrz/WBiugeO1dNl9lANr xSoUqVmtF/nLNsjS3UKMlKIt/BzbdJD2ceL5durn6wEFrR/uCFv52U9DrcTfNBrY/JTL F6OLrvqXwf1yjcfUXbeo7T0AM4TF4FAZ7adJ4= MIME-Version: 1.0 Received: by 10.150.131.5 with SMTP id e5mr6993053ybd.262.1253480978592; Sun, 20 Sep 2009 14:09:38 -0700 (PDT) In-Reply-To: <4AB67A8C.2090202@alvestrand.no> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> <4AB67A8C.2090202@alvestrand.no> Date: Sun, 20 Sep 2009 17:09:38 -0400 Message-ID: <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> From: Barry Leiba To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 21:08:43 -0000 > My sense of the WG is that the WG doesn't feel that being creative in how > IMAP options are specified is something this WG wants. Hm. I don't read that at all, from the few responses we have. That said, I'm happy to accommodate: I propose that we take my previous note, with all the changes suggested in it, but we modify the way the capabilities are specified. Instead of "UTF8=x,y,z", we have "UTF8=x UTF8=y UTF8=z". In particular, that means that there is no "UTF8" capability, and that is instead called "UTF8=ACCEPT". That should satisfy me, John, and Dave, as well as making Alexey and Joseph feel better. Is that cool? Barry From presnick@qualcomm.com Sun Sep 20 14:45:34 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85CE3A684A for ; Sun, 20 Sep 2009 14:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diHMcBofFNhF for ; Sun, 20 Sep 2009 14:45:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0504A3A67A8 for ; Sun, 20 Sep 2009 14:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1253483194; x=1285019194; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<6c9fcc2a090920 1409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> |References:=20<6.2.5.6.2.20090830222724.034fdb30@elandne ws.com>=09=0D=0A=20<6c9fcc2a0909010725m9f1a4c2x159fb13d05 df5f91@mail.gmail.com>=09=0D=0A=20<4A9D9878.7010302@isode .com>=20=09=0D=0A=20<6c 9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com >=09=0D=0A=20<4AA96B90.7070007@isode.com>=09=0D=0A=20<6c9 fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> =09=0D=0A=20<4AAA20BD.1060904@isode.com>=09=0D=0A=20=09=0D =0A=20<4AB67A8C.2090202@alvestrand.no>=0D=0A=20<6c9fcc2a0 909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> |User-Agent:=20Eudora=206.2.5b1(Macintosh)|Date:=20Sun, =2020=20Sep=202009=2016:46:25=20-0500|To:=20|From:=20Pete=20Resnick=20|Subject:=20Re:=20[EAI]=20Comments=20on=20draft-ietf- eai-imap-utf8-07|CC:=20Harald=20Alvestrand=20,=20EAI=20WG=20|Content-Type:=20t ext/plain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5747"=3B=20 a=3D"23872658"; bh=Ai7iQIPFkpjY+ERQTenwvnhoGw25dG6dwBBn6EQCuiA=; b=FBuK1BvHAtXqxiIZX/1igGTZi/Y6s6AMkIn0QbWO0+c5CmNoNnHFB8sw B0nOTtVoAwS55jdMQJVaKpRr1XxKTM9X/TnhuPv/SMZFPG5CIvX/+B1ao Ss1YUj79y29fiZZaQcqrchw0RCCnWJDLnowYJFr9JGOkbdF9K3cqmwZez E=; X-IronPort-AV: E=McAfee;i="5300,2777,5747"; a="23872658" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Sep 2009 14:46:33 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n8KLkXxR032042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Sep 2009 14:46:33 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n8KLkU66026444 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 20 Sep 2009 14:46:32 -0700 (PDT) Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 20 Sep 2009 14:46:30 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.14; Sun, 20 Sep 2009 14:46:29 -0700 Received: from [75.145.176.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 20 Sep 2009 14:46:29 -0700 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> <4AB67A8C.2090202@alvestrand.no> <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Sun, 20 Sep 2009 16:46:25 -0500 To: From: Pete Resnick Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 21:45:34 -0000 The document editor remains agnostic on these issues and waits for a consensus call from the chair. pr On 9/20/09 at 5:09 PM -0400, Barry Leiba wrote: >>My sense of the WG is that the WG doesn't feel that being creative >>in how IMAP options are specified is something this WG wants. > >Hm. I don't read that at all, from the few responses we have. That >said, I'm happy to accommodate: >I propose that we take my previous note, with all the changes >suggested in it, but we modify the way the capabilities are >specified. >Instead of "UTF8=x,y,z", we have "UTF8=x UTF8=y UTF8=z". In >particular, that means that there is no "UTF8" capability, and that >is instead called "UTF8=ACCEPT". > >That should satisfy me, John, and Dave, as well as making Alexey and >Joseph feel better. > >Is that cool? > >Barry -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From jyee@ca.afilias.info Mon Sep 21 10:59:35 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8103A68F6 for ; Mon, 21 Sep 2009 10:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lXFsFB4EKxn for ; Mon, 21 Sep 2009 10:59:35 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id ECC223A6AC8 for ; Mon, 21 Sep 2009 10:59:34 -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 1MpnBa-0005sS-5E; Mon, 21 Sep 2009 18:00:26 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MpnBa-0002s2-80; Mon, 21 Sep 2009 18:00:26 +0000 From: Joseph Yee To: barryleiba@computer.org In-Reply-To: <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> <4AB67A8C.2090202@alvestrand.no> <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 14:00:26 -0400 X-Mailer: Apple Mail (2.936) Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:59:35 -0000 On 20-Sep-09, at 5:09 PM, Barry Leiba wrote: >> My sense of the WG is that the WG doesn't feel that being creative >> in how >> IMAP options are specified is something this WG wants. > > Hm. I don't read that at all, from the few responses we have. That > said, I'm happy to accommodate: > I propose that we take my previous note, with all the changes > suggested in it, but we modify the way the capabilities are specified. > Instead of "UTF8=x,y,z", we have "UTF8=x UTF8=y UTF8=z". In > particular, that means that there is no "UTF8" capability, and that is > instead called "UTF8=ACCEPT". > > That should satisfy me, John, and Dave, as well as making Alexey and > Joseph feel better. > Barry, I feel good either way :) I guess what's left is to document (or not to document) all implications. Joseph > Is that cool? > > Barry > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From lunohod.baikonur@googlemail.com Mon Sep 21 12:11:47 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC1F3A6AD7 for ; Mon, 21 Sep 2009 12:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7YD8ti40leK for ; Mon, 21 Sep 2009 12:11:46 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 1F9AA3A69B7 for ; Mon, 21 Sep 2009 12:11:39 -0700 (PDT) Received: by ewy28 with SMTP id 28so423376ewy.42 for ; Mon, 21 Sep 2009 12:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Ni8VBt291lKxaeprwB13qzZfvl5O574WOAwGjctt+Ig=; b=ajug81OJgEeHl2qsRUl7CTuN2767qvvZ+6I4JOPrqp7RdKtzYBAjwMHNJKmkWEA0Ws XMzPKayenh+8uijZA6/7hjHxIYQsfItyeyCGKKHn2vbFC/1YlqnRJofFilU/qRQAkuLW TFSF6xjQuy1x89k349B3Lo3uzCEUBovHL6/QI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YvPa6ZYr2/HV4QjtPPXhPLP/bJRijbH5jwfKGHZ5VoRJKeTKRIbuTxtc8VnqlTALJf Sj/ZLGCgKxnpijIfScnAtDw9bVtXzBbCo0TdnbfDJ6Y7eCmg1ZTh/YVfw4D+VyV1bJQK oDjw5btFxgWtcE5/mxFbwsjb0BJ9FFhJSvS2I= MIME-Version: 1.0 Sender: lunohod.baikonur@googlemail.com Received: by 10.210.96.21 with SMTP id t21mr3351776ebb.4.1253560355642; Mon, 21 Sep 2009 12:12:35 -0700 (PDT) In-Reply-To: <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> <4AB67A8C.2090202@alvestrand.no> <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> Date: Mon, 21 Sep 2009 23:12:35 +0400 X-Google-Sender-Auth: 16e855feece2126d Message-ID: <29d3c4cb0909211212s7014fcc0mf6c153ee6bc685f1@mail.gmail.com> From: Alexey Melnikov To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:11:47 -0000 On Mon, Sep 21, 2009 at 1:09 AM, Barry Leiba wrote: >> My sense of the WG is that the WG doesn't feel that being creative in ho= w >> IMAP options are specified is something this WG wants. > > Hm. =A0I don't read that at all, from the few responses we have. =A0That > said, I'm happy to accommodate: > I propose that we take my previous note, with all the changes > suggested in it, but we modify the way the capabilities are specified. > =A0Instead of "UTF8=3Dx,y,z", we have "UTF8=3Dx UTF8=3Dy UTF8=3Dz". =A0In > particular, that means that there is no "UTF8" capability, and that is > instead called "UTF8=3DACCEPT". > > That should satisfy me, John, and Dave, as well as making Alexey and > Joseph feel better. > > Is that cool? Works for me. From harald@alvestrand.no Tue Sep 22 10:26:27 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F38D3A6AB4 for ; Tue, 22 Sep 2009 10:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvZuwcOuztev for ; Tue, 22 Sep 2009 10:26:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 9A6FC3A6A89 for ; Tue, 22 Sep 2009 10:26:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85ADE39E1F1; Tue, 22 Sep 2009 19:27:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLGlLdryIrLb; Tue, 22 Sep 2009 19:27:25 +0200 (CEST) Received: from [192.168.0.12] (c83-250-103-72.bredband.comhem.se [83.250.103.72]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B6DD439E162; Tue, 22 Sep 2009 19:27:25 +0200 (CEST) Message-ID: <4AB908AB.6060107@alvestrand.no> Date: Tue, 22 Sep 2009 19:26:03 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexey Melnikov References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <4A9D9878.7010302@isode.com> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com> <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com> <4AAA20BD.1060904@isode.com> <4AB67A8C.2090202@alvestrand.no> <6c9fcc2a0909201409n472d85f1xe87526b6f86ac9c9@mail.gmail.com> <29d3c4cb0909211212s7014fcc0mf6c153ee6bc685f1@mail.gmail.com> In-Reply-To: <29d3c4cb0909211212s7014fcc0mf6c153ee6bc685f1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , barryleiba@computer.org, EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:26:27 -0000 Alexey Melnikov wrote: > On Mon, Sep 21, 2009 at 1:09 AM, Barry Leiba > wrote: > >>> My sense of the WG is that the WG doesn't feel that being creative in how >>> IMAP options are specified is something this WG wants. >>> >> Hm. I don't read that at all, from the few responses we have. That >> said, I'm happy to accommodate: >> I propose that we take my previous note, with all the changes >> suggested in it, but we modify the way the capabilities are specified. >> Instead of "UTF8=x,y,z", we have "UTF8=x UTF8=y UTF8=z". In >> particular, that means that there is no "UTF8" capability, and that is >> instead called "UTF8=ACCEPT". >> >> That should satisfy me, John, and Dave, as well as making Alexey and >> Joseph feel better. >> >> Is that cool? >> > > Works for me. > I seem to detect a growing consensus.... as a contributor, "works for me too".