From Claudio.Allocchio@garr.it Tue May 1 01:46:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB421F856C for ; Tue, 1 May 2012 01:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_PAYLESS=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN-3pnAIlvvD for ; Tue, 1 May 2012 01:46:57 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id ABE0021F869F for ; Tue, 1 May 2012 01:46:56 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q418kJ1N028583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 10:46:19 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q418kJ1N028583 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=rhXpXtfaf4XuaFKyGS4SzZtUNjwsRGEx5mCyebDHnfwFltVzjTlY+19YrGcWX0sQJ JS5FywlPGWcvx0pCZFOJMb71yEvMdeCgy+W9ckmIUAotcFIcydI2HGTvo2sVTBvxRAJ FjdJ46Wwm15RNkgNTMTYVPM+Roamt38jlW1RdOg= Date: Tue, 1 May 2012 10:46:18 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Ned Freed In-Reply-To: <01OEY3WPDPJI0006TF@mauve.mrochek.com> Message-ID: References: <20120430025540.68111.qmail@joyce.lan> <01OEXMTFWYEQ0006TF@mauve.mrochek.com> <01OEY3WPDPJI0006TF@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Barry Leiba , John Levine , ima@ietf.org Subject: Re: [EAI] Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 08:46:57 -0000 Hi Ned, > I'm sorry, but the point you're making here completely eludes me. Barry asked > for information to help him respond regarding the effects of downgrading on > three specific things: (1) Signatures, (2) Sieve, and (3) Additional attacks > facilitated by downgrading. I responded with an analysis that basically said > the first two are demonstrably nonissues and the third is badly posed. Correct, and I agree with your analysis. > You then responded with a note that essentially said signatures seem to > be fairly worthless in practice. I confirm that. And that I was worried by anything which makes signatures and other security tools less "interesting" for users (I'm also a Service Provider with some million users). > And now you appear to be saying that the realproblem is the security > considerations section lacks information about certain scenarios > of concern, but I have no idea what these scenarios are. Mybe, when I write a note at 1AM, I do not convey correctly what I want :-) I'm not asking at all that all possible scneraios are precisly described and evalutated one by one. I'm just asking that the Security Consideration cleary say that: - a number of security mechanisms will be broken, ALSO by this downgrading process, not only by EAI of course. And here you can list already what we know (the security section of the other downgrading document draft-ietf-eai-popimap-downgrade-05 makes a good job on this!). And if you want, I'd add a general warning about effects that downgrading can produce in user's experience about security (see Ted's detailed description in his last message): less careful evaluation of received messages, etc. > In any case, assuming these scenarios involve some sort of trickery in > regards to what headers are or aren't displayed by different clients, > I'll fall back to my original point that given the ease with which email > headers can be forged, coupled with the uncertainty as to what client a > given user might use, does downgrading really change the the attack > surface in any significant way? I > rather think it does not. And I agree with you: it does not change the scenario: it just helps a bit in enabling the scenario to survive, because it will further mis-educate users about security feelings. > Now, I suppose you can argue that we should describe what amount to tiny > twigs on the attack tree even when there are enormous branches that are > far more accessible, but I'm going to have to disagree. I'm not asking that at all. See above. > But I freely admit I may be entirely incorrect about all this because I > really have no idea what scenarios are that you're concerned about. Here they are (just to re-write Ted's long message): - this specification breaks a number of security features (which security people are trying to spread as much as possible); - given the good will intention of this specification (better some information than nothing), users may get an even more relaxed attitute towards security features, getting used to pay less attention to what they read; - this users' relaxed attitude can further help malicious attempts, even if this is going to be a very small percentage of possible attacks: an attacker can just start forging downgraded-like messages to be delivered to these few users. Thus, in general, we should just say clearly that this specification can produce these effects, and that's all we can do. Personally I'm not worried this will make the email service more insecure that it is already: your analsys about MIME case is perfecty correct. But we should just state that this adds to the problem a tiny bit, hence we should try to enable these transition things for the minimal implementation time needed, and then make them historic. Now, speaking as a Serivce Provider, I always try to give a "ready to go" solution to users, whith no downgrading/transition solutions: you want this new service? Upgrade to what you need, or "no service". But I know well that I will get at least a non neglegible number of complaints about this yes/no solutions, and sometimes it is difficult to apply because of non technical reasons. Was this message a bit clearer than the night one? I hope so! Does "Smoke Kills you!" stop all people from smoking? Certainly not! But At least I think we should continue to write it. Same position here. Have a nice Labour's Day (for this having it!). ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From sm@elandsys.com Tue May 1 02:43:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5061721F8642 for ; Tue, 1 May 2012 02:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-wdLz6SnveU for ; Tue, 1 May 2012 02:43:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0334C21F863D for ; Tue, 1 May 2012 02:43:21 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.135]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q419h5sm025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2012 02:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335865400; i=@garr.it; bh=PekR4gKWIOWTEQODvj9ghnEklmih+EDoEHZDQN6qyyQ=; h=Date:To:From:Subject:Cc; b=ge1ZAZ1mc/5um94EnNv/mHqYuv4Y7Qq+h2axN9gJi/GUsYjT97tEB34jmIiypGPx/ N1GpaP8Db44S0Na/c6+x3q45QTiNoVoRXxtNkhcau3LrZFH0rDNF2sgUqMPem+sR0f Jm3/oSVVKDvBnVmDYYOraCRiJrxZPwKnPzRE5g5Y= Message-Id: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 May 2012 02:41:32 -0700 To: ima@ietf.org From: Claudio Allocchio (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 09:43:23 -0000 Hello all, I have been selected as the Applications Area Directorate co-reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-eai-simpledowngrade-03 Title: EAI: Simplified POP/IMAP downgrading Reviewer: Claudio Allocchio Review Date: April 30th 2012 IETF Last Call Date: n/a IESG Telechat Date: n/a Summary: This specification needs some revision before it can be published. Some of them are just clarifications and better text, but in the case of the Security Considerations section, it might even need a revision, set of suggestions, from the Security area folks, in order to find the best possible way to explain involved risks. I also suggest further thinking about the "Proposed Standards" track publication. I do see a good number of pros in doing this, but I'm not confident this is the completely correct way to go. Major Issues: 2.3 Subject adding or non adding a "DOWNGRADED" or equivalent to the subject is a major decision which also impacts on the way the security failure which are introduced by this specification are perceived by the user. This issue shall be fixed and a decision taken ASAP, in order to publish this. 5. Security Considerations this section is way too short and simplified, compared to the issues that this specification introduces against secure e-mail mechanisms. This section should give an exaustive list of caveats, and possible actions in various cases, in order to make clear that this specification breaks explicilty most of the existing security anchors where users should rely nowadays. It should also list that, while it is clear that in most of the cases where downgrading and/or gatewaying is involved, possible security leaks are introduced, and user's security mechanisms become invalid. "as is" is not enough. Minor Issues: Abstract: given the quite invasive action on messages presentation that such a specification describes, such a short and "optimistic" abstract is, IMHO, misleading. At least insert a sentence to describe the scenario, and what this specification is trying to accomplish, what problems it tries to solve, and what issues are left open and voluntarily not solved here. 1 Overview: I disagree on the way the overview present "phylosophically" the problem to the reader. This is a technical specification intended for Standards Track, not an informational document. Thus, it should not focus on the way implementerss spend their time, os users' behaviours. It should state the problem and the proposed solutions: (dot)! Here is my suggested version of this paragraph: --- 1. Overview It may happen that a conventional IMAP or POP client opens a mailbox containing internationalized messages, or even attempt to read internationalized messages, for instance when a user has both internationalized and conventional MUAs. When this mismatched sitation happens, various strategies are possible: a) the server can hide the existence of such messages entirely, but doing that can be both tricky to implement and gives a false mailbox status to the user; b) the server attempts to present at least some information about these messages to the user. It shall be clear that what the user is being presented is not the original message, and information is dropped; c) the server does nothing, possibly creating problems to the client, and providing a bad user's experience. This document specify a way to implement strategy b), which enables the best compromise between a) and c), and promotes a simple to implement solution which conveys a better-than-nothing information service to the user. Accuracy of information and Security featues of the message will, however, not be preserved, and users should rely on an internationalised client as much as possible. The server is assumed to be internationalized internally. When it needs to present an internationalized message to a conventional client, it synthesizes a conventional message containing most of the information and presents that (the "synthetic message"). ---- 2.1 Email addresses At lease one sentence clearly stating that this will make impossible to reply to such a synthetic message should be present here. Too obvious? no... never suppouse that. Nits: 1 Overwiew "It may happen that a conventional IMAP or POP client (MUA) opens..." ^ add the definition I suggest coherent use also in other parts of the specification. 6. Acknowledgments well... clean it up from the call, before publishing! 7. IANA Considerations ADD the name of the correct registry! ---------------------------- Ok... now I can go and read my co-reviewer report :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From sm@elandsys.com Tue May 1 02:43:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2538F21F875D for ; Tue, 1 May 2012 02:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFYjB6lLwZFY for ; Tue, 1 May 2012 02:43:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6B21F875E for ; Tue, 1 May 2012 02:43:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.135]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q419h5so025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2012 02:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335865405; i=@garr.it; bh=Q+YbGqHCvuHxyY5g2eTt/xJpAoI83XwZoeRDGBP2zZs=; h=Date:To:From:Subject:Cc; b=TOeEt1sTEshy5BHrEnJylu/6+qAGeH6gMXOI4TIYbVjiTgMZtg04cz6vQt3kt86fA +HJpZW6K0vhQU+x9j6F2lK7pD5Wx0KQiS+U3Gb+E49L701sf5TgonyKxTOc1B5wXKS 3OstpikUMZzw8EbOXNKKteadOVhDfC3BU2mzTQg8= Message-Id: <6.2.5.6.2.20120501024140.0a368638@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 May 2012 02:42:19 -0700 To: ima@ietf.org From: Claudio Allocchio (by way ofS Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [EAI] AppsDir review of draft-ietf-eai-popimap-downgrade-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 09:43:27 -0000 Hello all, I have been selected as the Applications Area Directorate co-reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-eai-popimap-downgrade-05 Title: Post-delivery Message Downgrading for Internationalized Email Messages Reviewer: Claudio Allocchio Review Date: April 30th 2012 IETF Last Call Date: n/a IESG Telechat Date: n/a Summary: This document is requires a major decision about updating/non updating RFC 5322 before it can go to publication. Once this is done, other minor changes are listed below and it can be published. Another issue to clarify/fix is its relationship with draft-ietf-eai-simpledowngrade-03 specification (and also in that document, of course, with respect to this one). Major Issues: 3. Updating RFC 5322 this is a big major issue in this specification. I do not believe that stating something like "It is anticipated that when existing implementations encounter a downgraded field from this set, many will tolerate the appearance of a group" is a possible thing into a Standards Track specification. Th "update" to RFC 5322 is a big major one, and cons should be carefully evaluated here, too. As the "Notes in Draf" itself states, there is an alternate, much safer mechamism which can be used, and convey the same information to the user. This isse must be clarified before this specification can be publisehd, and a decision taken. Minor Issues: there is not cross-reference at all with draft-ietf-eai-simpledowngrade-03! many implementers could ge confused about the releationship between these specifications. In the Summary this should be explicitly described and clearly stated. Security Considerations this section describes quite well the possible scenarios which this specification introduces (and can also be a good example for re-writing the same secrion in draft-ietf-eai-simpledowngrade-03); I'd just suggest a further review by the Security area folks, too. Just in case... Nits: 1.1 Problem statement I'd suggest removing "Discussions leading to this specification concluded that " and just start with "There are four...' 5.1.1 until 5.1.9 in the titles you use the defintions without the <...> surrounding them. e.g. 5.1.5 GROUP Downgrading. I'd suggest changing them all using the < and > ... e.g. 5.1.5 Downgrading. etc. IANA Considerartions: ... to be fixed with IANA before publication! All over the document (and expecially in the A.1 example): this document uses a different convetion than draft-ietf-eai-simpledowngrade-03 for non ASCII elements in addresses/fields. Please unify the used convetion with the other draft (whichever of the 2 convetion is better) before publication. Here you write "NON-ASCII-something..." there you just use UPPERCASE. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From arnt@gulbrandsen.priv.no Tue May 1 03:24:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD921F8752 for ; Tue, 1 May 2012 03:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzsKezcnmGRY for ; Tue, 1 May 2012 03:24:31 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E702721F8740 for ; Tue, 1 May 2012 03:24:30 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 28EC3F940E7; Tue, 1 May 2012 10:24:28 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335867867-19065-19064/10/7; Tue, 1 May 2012 10:24:27 +0000 Message-Id: <4F9FB9EB.100@gulbrandsen.priv.no> Date: Tue, 1 May 2012 12:24:43 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <20120430025540.68111.qmail@joyce.lan> <01OEXMTFWYEQ0006TF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 10:24:31 -0000 On 05/01/2012 12:57 AM, Ted Hardie wrote: > For what it is worth, I still believe the signature issue is a small > part of a more general issue: > how do I manage user expectation of what a message should look like so > that it is considered > valid? I've spoken to quite a number of people about this in the past decade, in the context of spam, and my feeling is that "valid" usually means either "something I was waiting for" or "something I can reply to" or a combination of the two. A non-EAI MUA will never be able to reply to mail from an EAI address, so we lose on that side, no matter how hard we try. Both downgrade documents preserve subject and attachments, so if the user was waiting for something, both score near 100% on that side. Arnt From alexey.melnikov@isode.com Tue May 1 12:00:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB64821E8438 for ; Tue, 1 May 2012 12:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjxM8rB0SLx1 for ; Tue, 1 May 2012 12:00:48 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3888A21E841A for ; Tue, 1 May 2012 12:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335898846; d=isode.com; s=selector; i=@isode.com; bh=hhAs4IDZQqWTKuRlIiiko4teD6rL+7tUgC0Alp7Le8M=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=c5bp0bf0s92QMn34xUGjuKer+jdjEuYd2S47PbcwnBFXUHrhWT7Q8pOPLlSnqZYvpHnr3M wZlkfvH6D8KAxvRJbvhPbHRcRJHyWtdTQ4fbvBtsQ9oPu56pS/PxiAG52PsAlkTSDIM170 VEpR/9F/KyMZGRYLteszfLeTG6GgXVU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 May 2012 20:00:46 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA03300.5090209@isode.com> Date: Tue, 01 May 2012 20:01:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Arnt Gulbrandsen References: <4F9E4C91.50701@gulbrandsen.priv.no> <4F9E8130.50403@isode.com> <4F9EA3E6.1040205@gulbrandsen.priv.no> In-Reply-To: <4F9EA3E6.1040205@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] a couple of 5738bis comments X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:00:50 -0000 Hi Arnt, On 30/04/2012 15:38, Arnt Gulbrandsen wrote: > Alexey answers me: >>> b enable utf8=accept >>> c select inbox >>> >> I am entirely lacking coffee today, so can you please spell out: >> 1). what is the problem > I see two obviously useful cases. > > 1. Client wants EAI. > 2. Client doesn't. > > But 5738bis provides three settings. > > 1. Client wants EAI syntax and messages. > 2. Client wants EAI syntax but not EAI messages > 3. Client knows nothing about EAI. > > (The command sequence above provides the middle case.) I don't think we really care about 2. Maybe we used to care when there were more IMAP extensions in the same document. Remind me how is 1 different from 2? >> 2). what change you are proposing to fix it. > I'm not proposing. I'm wondering why the document offers three cases. > > I'm not saying "b enable utf8=accept" followed by "c select inbox" is > pointless, I'm asking what its point is. > From arnt@gulbrandsen.priv.no Tue May 1 12:54:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3B821E8404 for ; Tue, 1 May 2012 12:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eGtAn39w-eE for ; Tue, 1 May 2012 12:54:01 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12721E83FF for ; Tue, 1 May 2012 12:54:01 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2C5F2FA07A0; Tue, 1 May 2012 19:53:59 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335902038-19065-19064/10/9; Tue, 1 May 2012 19:53:58 +0000 Message-Id: <4FA03F66.6070508@gulbrandsen.priv.no> Date: Tue, 1 May 2012 21:54:14 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Alexey Melnikov References: <4F9E4C91.50701@gulbrandsen.priv.no> <4F9E8130.50403@isode.com> <4F9EA3E6.1040205@gulbrandsen.priv.no> <4FA03300.5090209@isode.com> In-Reply-To: <4FA03300.5090209@isode.com> Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] a couple of 5738bis comments X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:54:02 -0000 Alexey answers me: >> 1. Client wants EAI syntax and messages. >> 2. Client wants EAI syntax but not EAI messages >> 3. Client knows nothing about EAI. ... > I don't think we really care about 2. Maybe we used to care when there > were more IMAP extensions in the same document. > > Remind me how is 1 different from 2? a login alexey features b enable utf8=accept c select inbox ... d uid fetch 1:* bodystructure If command c uses the UTF8 option, command d returns data from the real messages. This is option 1 above. If command c doesn't use the UTF8 option, the responses for command d can use *"..." strings, but have to contain downgraded information. This is option 2 above. If option 2 isn't valuable, then I think the UTF8 option to SELECT, LIST etc can perhaps be dropped, and the single command ENABLE UTF8=ACCEPT turns on EAI support completely. Arnt From arnt@gulbrandsen.priv.no Tue May 1 13:43:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7699F21E8053 for ; Tue, 1 May 2012 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lkYBlci8RQR for ; Tue, 1 May 2012 13:43:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8035B21E8045 for ; Tue, 1 May 2012 13:43:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id D3BF0FA07DD; Tue, 1 May 2012 20:43:52 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335905030-19065-19064/10/10; Tue, 1 May 2012 20:43:50 +0000 Message-Id: <4FA04B17.9050902@gulbrandsen.priv.no> Date: Tue, 1 May 2012 22:44:07 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> In-Reply-To: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 20:43:55 -0000 On 05/01/2012 11:41 AM, Claudio Allocchio wrote: > 2.3 Subject > > adding or non adding a "DOWNGRADED" or equivalent to the subject is a > major decision which also impacts on the way the security failure which > are introduced by this specification are perceived by the user. This > issue shall be fixed and a decision taken ASAP, in order to publish this. Yes. > 5. Security Considerations > > this section is way too short and simplified, compared to the issues > that this specification introduces against secure e-mail mechanisms. As far as I can tell it introduces no issues at all. Think about it: How would a program verify a signature when it cannot parse the signature's owner's address? Now downgrade the signature's owner's address, using any algorithm you can think of. What new issue has been introduced? > This section should give an exaustive list of caveats, and possible > actions in various cases, in order to make clear that this specification > breaks explicilty most of the existing security anchors where users > should rely nowadays. Duck that. You're just pointing out something that's easily pointed out. AFAICT it's not an issue either I or any downgrade implementer can do anything about, so why does it deserve any text? > given the quite invasive action on messages presentation that such a > specification describes, such a short and "optimistic" abstract is, > IMHO, misleading. At least insert a sentence to describe the scenario, > and what this specification is trying to accomplish, what problems it > tries to solve, and what issues are left open and voluntarily not solved > here. > > 1 Overview: > > I disagree on the way the overview present "phylosophically" the problem > to the reader. This is a technical specification intended for Standards > Track, not an informational document. Thus, it should not focus on the > way implementerss spend their time, os users' behaviours. It should > state the problem and the proposed solutions: (dot)! > > Here is my suggested version of this paragraph: > > --- > > 1. Overview > > It may happen that a conventional IMAP or POP client opens a mailbox > containing internationalized messages, or even attempt to read > internationalized messages, for instance when a user has both > internationalized and conventional MUAs. > > When this mismatched sitation happens, various strategies are possible: > > a) the server can hide the existence of such messages entirely, but > doing that can be both tricky to implement and gives a false mailbox > status to the user; > > b) the server attempts to present at least some information about these > messages to the user. It shall be clear that what the user is being > presented is not the original message, and information is dropped; > > c) the server does nothing, possibly creating problems to the client, and > providing a bad user's experience. > > This document specify a way to implement strategy b), which enables the > best compromise between a) and c), and promotes a simple to implement > solution which conveys a better-than-nothing information service to the > user. Accuracy of information and Security featues of the message will, > however, not be preserved, and users should rely on an internationalised > client as much as possible. > > The server is assumed to be internationalized internally. When it > needs to present an internationalized message to a conventional > client, it synthesizes a conventional message containing most of the > information and presents that (the "synthetic message"). You've made it about four times as long and hardly four times as good. > 2.1 Email addresses > > At lease one sentence clearly stating that this will make impossible to > reply to such a synthetic message should be present here. Too obvious? > no... never suppouse that. It's not obvious, it's wrong ;) Nothing is made impossible, it was impossible to start with. > 1 Overwiew > > "It may happen that a conventional IMAP or POP client (MUA) opens..." > ^ add the definition Do you mind if I define it as "IMAP or POP client"? That is, after all, the operative definition ;) > 7. IANA Considerations > > ADD the name of the correct registry! I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. Arnt From Claudio.Allocchio@garr.it Tue May 1 14:16:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136AF21E8248; Tue, 1 May 2012 14:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONDJ4NRxtEl4; Tue, 1 May 2012 14:16:41 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id B268C21E8129; Tue, 1 May 2012 14:16:40 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it ([140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q41LGbcj048492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 23:16:38 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q41LGbcj048492 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Y8UPAmLUnAwwSEasX0Q1zSxk/LRSPUCFFl7rUCgK4gBgBhYK51y3UD++91Q0WVrNc N0d9zevZzcfQUAtiy9EXSwPLEfPy/tP3qga0H2AbFLdCXyqUYk7d8gmnLJYuTX41zsa FWEfFnNZGq021NEuNxMpSJb1f9fRf53a0Fkz58o= Date: Tue, 1 May 2012 23:16:37 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Arnt Gulbrandsen In-Reply-To: <4FA04B17.9050902@gulbrandsen.priv.no> Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 21:16:42 -0000 On Tue, 1 May 2012, Arnt Gulbrandsen wrote: > On 05/01/2012 11:41 AM, Claudio Allocchio wrote: >> 2.3 Subject >> >> adding or non adding a "DOWNGRADED" or equivalent to the subject is a >> major decision which also impacts on the way the security failure which >> are introduced by this specification are perceived by the user. This >> issue shall be fixed and a decision taken ASAP, in order to publish this. > > Yes. > >> 5. Security Considerations >> >> this section is way too short and simplified, compared to the issues >> that this specification introduces against secure e-mail mechanisms. > > As far as I can tell it introduces no issues at all. > > Think about it: How would a program verify a signature when it cannot > parse the signature's owner's address? Now downgrade the signature's > owner's address, using any algorithm you can think of. What new issue > has been introduced? as I already clarified in other discussions on these lists, I'm not talking about the signatures and other features. I'm talking about including a Security consideration section which describes clearly which features can be broken, and just warns about this. I also suggested as example the security considerations section of draft-ietf-eai-popimap-downgrade-05. See my discussions with Ned and others. > >> This section should give an exaustive list of caveats, and possible >> actions in various cases, in order to make clear that this specification >> breaks explicilty most of the existing security anchors where users >> should rely nowadays. > > Duck that. You're just pointing out something that's easily pointed out. > AFAICT it's not an issue either I or any downgrade implementer can do > anything about, so why does it deserve any text? warning implementers that these problems exists, IMHO, is never useless. >> given the quite invasive action on messages presentation that such a >> specification describes, such a short and "optimistic" abstract is, >> IMHO, misleading. At least insert a sentence to describe the scenario, >> and what this specification is trying to accomplish, what problems it >> tries to solve, and what issues are left open and voluntarily not solved >> here. >> >> 1 Overview: >> >> I disagree on the way the overview present "phylosophically" the problem >> to the reader. This is a technical specification intended for Standards >> Track, not an informational document. Thus, it should not focus on the >> way implementerss spend their time, os users' behaviours. It should >> state the problem and the proposed solutions: (dot)! >> >> Here is my suggested version of this paragraph: >> >> --- >> >> 1. Overview >> >> It may happen that a conventional IMAP or POP client opens a mailbox >> containing internationalized messages, or even attempt to read >> internationalized messages, for instance when a user has both >> internationalized and conventional MUAs. >> >> When this mismatched sitation happens, various strategies are possible: >> >> a) the server can hide the existence of such messages entirely, but >> doing that can be both tricky to implement and gives a false mailbox >> status to the user; >> >> b) the server attempts to present at least some information about these >> messages to the user. It shall be clear that what the user is being >> presented is not the original message, and information is dropped; >> >> c) the server does nothing, possibly creating problems to the client, and >> providing a bad user's experience. >> >> This document specify a way to implement strategy b), which enables the >> best compromise between a) and c), and promotes a simple to implement >> solution which conveys a better-than-nothing information service to the >> user. Accuracy of information and Security featues of the message will, >> however, not be preserved, and users should rely on an internationalised >> client as much as possible. >> >> The server is assumed to be internationalized internally. When it >> needs to present an internationalized message to a conventional >> client, it synthesizes a conventional message containing most of the >> information and presents that (the "synthetic message"). > > You've made it about four times as long and hardly four times as good. being long is a problem in a specification? >> 2.1 Email addresses >> >> At lease one sentence clearly stating that this will make impossible to >> reply to such a synthetic message should be present here. Too obvious? >> no... never suppouse that. > > It's not obvious, it's wrong ;) Nothing is made impossible, it was > impossible to start with. This does not change the need to state it. >> 1 Overwiew >> >> "It may happen that a conventional IMAP or POP client (MUA) opens..." >> ^ add the definition > > Do you mind if I define it as "IMAP or POP client"? That is, after all, > the operative definition ;) it's a nit... it's up to editors :-) >> 7. IANA Considerations >> >> ADD the name of the correct registry! > > I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. > > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From arnt@gulbrandsen.priv.no Tue May 1 14:22:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671BA21E8279 for ; Tue, 1 May 2012 14:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8FcZu7oTdkF for ; Tue, 1 May 2012 14:22:53 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 04CBC21E825F for ; Tue, 1 May 2012 14:22:53 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id C9D9AF8CF3B; Tue, 1 May 2012 21:22:50 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335907369-19065-19064/10/11; Tue, 1 May 2012 21:22:49 +0000 Message-Id: <4FA05439.2070408@gulbrandsen.priv.no> Date: Tue, 1 May 2012 23:23:05 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> In-Reply-To: <4FA04B17.9050902@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 21:22:54 -0000 Hm. A possibly relevant point is that this is a document for people who maintain an IMAP or POP server and have extended it to support EAI. This implies that the readers know several of RFCs 1939, 3501, 5721, 5738, 6530 and 6531 well. Comprehension to these people is vital, comprehension to others is nice to have but essentially beside the point. Arnt From Claudio.Allocchio@garr.it Tue May 1 14:32:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB49B21E8043 for ; Tue, 1 May 2012 14:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMwjFN6HFcuz for ; Tue, 1 May 2012 14:32:09 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id D7B5C21E8020 for ; Tue, 1 May 2012 14:32:08 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it ([140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q41LW6nf048921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 23:32:07 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q41LW6nf048921 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=pBD2UBPrfkO9CRdPnw8TAWteLLBuTISOkij1hVJ1S1e+Dtc6UGW48Ye3AsukGSvZ1 +lmbxknOtzMo7Rd7dww1jsdKP1WrcKRCYJu0n6fa/bgyCfbxs7rrjfEYcSqZX+5H/o3 VS79yvkfFhS2z4nhb+uFrPde5SOq3Dkb93pGs7k= Date: Tue, 1 May 2012 23:32:06 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Arnt Gulbrandsen In-Reply-To: <4FA05439.2070408@gulbrandsen.priv.no> Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <4FA05439.2070408@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 21:32:10 -0000 On Tue, 1 May 2012, Arnt Gulbrandsen wrote: > Hm. > > A possibly relevant point is that this is a document for people who > maintain an IMAP or POP server and have extended it to support EAI. This > implies that the readers know several of RFCs 1939, 3501, 5721, 5738, > 6530 and 6531 well. Comprehension to these people is vital, > comprehension to others is nice to have but essentially beside the point. it seems you have a bigger consideration than me on implementers knowledge about the global environment they're putting their product to live wihin :-) ... I've seen so many bad or wrong implmentations of e-mail protocol specifications in the last 25 years that I prefer to repeat "well known" things ;-) But this is just my approach, and of course a "sggestion", not a "MUST". ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From ned+ima@mrochek.com Tue May 1 19:24:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1321F8949 for ; Tue, 1 May 2012 19:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMpwKYCYBvxm for ; Tue, 1 May 2012 19:24:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A5BFD21F8947 for ; Tue, 1 May 2012 19:24:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEZA4TGT74000WUP@mauve.mrochek.com> for ima@ietf.org; Tue, 1 May 2012 19:24:51 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 1 May 2012 19:24:49 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OEZA4S4IKM0006TF@mauve.mrochek.com> Date: Tue, 01 May 2012 19:06:49 -0700 (PDT) In-reply-to: "Your message dated Tue, 01 May 2012 22:44:07 +0200" <4FA04B17.9050902@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 02:24:54 -0000 > On 05/01/2012 11:41 AM, Claudio Allocchio wrote: > > 2.3 Subject > > > > adding or non adding a "DOWNGRADED" or equivalent to the subject is a > > major decision which also impacts on the way the security failure which > > are introduced by this specification are perceived by the user. This > > issue shall be fixed and a decision taken ASAP, in order to publish this. > Yes. > > 5. Security Considerations > > > > this section is way too short and simplified, compared to the issues > > that this specification introduces against secure e-mail mechanisms. > As far as I can tell it introduces no issues at all. > Think about it: How would a program verify a signature when it cannot > parse the signature's owner's address? Now downgrade the signature's > owner's address, using any algorithm you can think of. What new issue > has been introduced? That's certainly true for any mechanism that verifies signatures using addresses. It also points out additional work EAI needs to do to deal with the use of EAI addresses in S/MIME and elsewhere. And since we cannot predict how that will go, it is pointless to try and address any potential issues those standards have with EAI or downgrading in any present specification. Now, there may be other security mechanisms out there that interact with EAI in interesting ways. Not to put too fine point on it, but that's their problem to solve, not ours. > > This section should give an exaustive list of caveats, and possible > > actions in various cases, in order to make clear that this specification > > breaks explicilty most of the existing security anchors where users > > should rely nowadays. > Duck that. You're just pointing out something that's easily pointed out. > AFAICT it's not an issue either I or any downgrade implementer can do > anything about, so why does it deserve any text? Security considerations do need to cover the issues that cannot be addressed. That said, all that's really needed here is a statement to the effect that downgrading may removes addresse information that may be critical to properly assessing the validity or invalidity of a message. I see absolutely no point in getting into a bunch of what-ifs. If we do we'll end up with a 20 page security considerations section that nobody, myself included, will bother to read. > > given the quite invasive action on messages presentation that such a > > specification describes, such a short and "optimistic" abstract is, > > IMHO, misleading. At least insert a sentence to describe the scenario, > > and what this specification is trying to accomplish, what problems it > > tries to solve, and what issues are left open and voluntarily not solved > > here. > > > > 1 Overview: > > > > I disagree on the way the overview present "phylosophically" the problem > > to the reader. This is a technical specification intended for Standards > > Track, not an informational document. Thus, it should not focus on the > > way implementerss spend their time, os users' behaviours. It should > > state the problem and the proposed solutions: (dot)! > > > > Here is my suggested version of this paragraph: > > > > --- > > > > 1. Overview > > > > It may happen that a conventional IMAP or POP client opens a mailbox > > containing internationalized messages, or even attempt to read > > internationalized messages, for instance when a user has both > > internationalized and conventional MUAs. > > > > When this mismatched sitation happens, various strategies are possible: > > > > a) the server can hide the existence of such messages entirely, but > > doing that can be both tricky to implement and gives a false mailbox > > status to the user; > > > > b) the server attempts to present at least some information about these > > messages to the user. It shall be clear that what the user is being > > presented is not the original message, and information is dropped; > > > > c) the server does nothing, possibly creating problems to the client, and > > providing a bad user's experience. > > > > This document specify a way to implement strategy b), which enables the > > best compromise between a) and c), and promotes a simple to implement > > solution which conveys a better-than-nothing information service to the > > user. Accuracy of information and Security featues of the message will, > > however, not be preserved, and users should rely on an internationalised > > client as much as possible. > > > > The server is assumed to be internationalized internally. When it > > needs to present an internationalized message to a conventional > > client, it synthesizes a conventional message containing most of the > > information and presents that (the "synthetic message"). > You've made it about four times as long and hardly four times as good. I'm afraid I have to agree. I see nothing wrong with the current text. > > 2.1 Email addresses > > > > At lease one sentence clearly stating that this will make impossible to > > reply to such a synthetic message should be present here. Too obvious? > > no... never suppouse that. > It's not obvious, it's wrong ;) Nothing is made impossible, it was > impossible to start with. While I agree, perhaps a statement to the effect that an EAI address is inherently unusable by an non-EAI-client and this does nothing to change that would be in order. (There are potential schemes involving encoding that could be used to address that, but we have avoided them - I think for good reason.) Ned From johnl@iecc.com Tue May 1 21:50:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0405A21F8936 for ; Tue, 1 May 2012 21:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.097 X-Spam-Level: X-Spam-Status: No, score=-111.097 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxT8bEpJPJlB for ; Tue, 1 May 2012 21:50:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B4EC321F8935 for ; Tue, 1 May 2012 21:50:26 -0700 (PDT) Received: (qmail 34288 invoked from network); 2 May 2012 04:50:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 May 2012 04:50:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa0bd10.xn--btvx9d.k1205; i=johnl@user.iecc.com; bh=EoSp7TB1JPZuAhN1dSLzDxZT7i9N8i7qnoD+8yauoCc=; b=ouV1uOmxhEvJE4ZG7O40Y+iKzwUFHaFw2ABYfF/6rC/O/SFSfPboghx/CJ6uyKG4NJZ8C9xRNHjtvz/DU9lh/1tGimCDZk3sUGXw9OyYuMpL8dml+c6jRNHoIeU9XHoT0InZkZOtHxFdwy4hMffBZpVACwC/7vQEDlLqcgxkWik= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa0bd10.xn--btvx9d.k1205; olt=johnl@user.iecc.com; bh=EoSp7TB1JPZuAhN1dSLzDxZT7i9N8i7qnoD+8yauoCc=; b=PX9w49vrAliK0Ez7KLM9nP6xktVEWhDPrP+2iPmmHpNftj8mvbIq21/weBQvNijPEyU9JbiqjVsuhJBGTUMoPQIuT333ATwxjOjD8oeEgAhFHOD5IZC4XJNP5W8LkFxPbP7n9BBdUbqk4ZRgUBr7Tg/EhkZzuPCDkSvXzLQoTrI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 May 2012 04:50:02 -0000 Message-ID: <20120502045002.4577.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 04:50:28 -0000 >This section should give an exaustive list of caveats, and possible >actions in various cases, ... I suppose we could add something like this: MUAs that attempt to validate message signatures such as DKIM or S/MIME will often be unable to do so, since the downgrade modifications will often break the signatures. Users should upgrade to an EAI-capable MUA if they wish to continue doing signature validation in the MUA. To echo Ned, there's a bazillion ways that messages are validated at various stages in the delivery process, and nobody could possibly enumerate what they all are or exactly how downgrading might break them. Signatures break already due to random mutations in transit, and a few more broken signatures don't present any new threats. R's, John From arnt@gulbrandsen.priv.no Wed May 2 00:23:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B74821F8875; Wed, 2 May 2012 00:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGPJklLo5lia; Wed, 2 May 2012 00:23:17 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id A6FD221F8874; Wed, 2 May 2012 00:23:17 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1487BF8E7E8; Wed, 2 May 2012 07:23:15 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335943394-31604-31603/10/1; Wed, 2 May 2012 07:23:14 +0000 Message-Id: <4FA0E0F3.5050208@gulbrandsen.priv.no> Date: Wed, 2 May 2012 09:23:31 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Claudio Allocchio References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 07:23:18 -0000 On 05/01/2012 11:16 PM, Claudio Allocchio wrote: > as I already clarified in other discussions on these lists, I'm not > talking about the signatures and other features. I'm talking about > including a Security consideration section which describes clearly which > features can be broken, and just warns about this. OK, what are they? > being long is a problem in a specification? Yes. If you sort the IMAP extension RFCs (just to take a reasonably sized corpus) by length, you've more or less also sorted them by deployment. The correlation isn't 1.0. But it's much closer to 1 than to -1. >>> 2.1 Email addresses >>> >>> At lease one sentence clearly stating that this will make impossible to >>> reply to such a synthetic message should be present here. Too obvious? >>> no... never suppouse that. >> >> It's not obvious, it's wrong ;) Nothing is made impossible, it was >> impossible to start with. > > This does not change the need to state it. Do you really think that someone who has written an IMAP or POP server and extended it to support EAI needs to be told that EAI extends email addresses incompatibly? Arnt From Claudio.Allocchio@garr.it Wed May 2 00:32:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0511E8081 for ; Wed, 2 May 2012 00:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1cYaDV05jZn for ; Wed, 2 May 2012 00:32:47 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id ACBA811E807F for ; Wed, 2 May 2012 00:32:45 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q427WBmA021516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 09:32:11 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q427WBmA021516 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=K4C1fVhIHMRDxxPpFoAYerqxdy9+9V9pW8vuEcK6QmJBXatafeuNQpE/0oVh3jOdE 6z0gcy+7Uu87EOPtPtgmzHfHNHDvOHFVt4mrGFx5KT3Jq0EZjv0dpjQBiAqC10aEjVu ff17nVpa5ZvcK4XVPVmkNV8+Paed8PA+ICE7Cas= Date: Wed, 2 May 2012 09:32:10 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: John Levine In-Reply-To: <20120502045002.4577.qmail@joyce.lan> Message-ID: References: <20120502045002.4577.qmail@joyce.lan> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 07:32:47 -0000 On Wed, 2 May 2012, John Levine wrote: >> This section should give an exaustive list of caveats, and possible >> actions in various cases, ... > > I suppose we could add something like this: > > MUAs that attempt to validate message signatures such as DKIM or > S/MIME will often be unable to do so, since the downgrade > modifications will often break the signatures. Users should upgrade > to an EAI-capable MUA if they wish to continue doing signature > validation in the MUA. this is a good short and clear way to state the problem! +1 > To echo Ned, there's a bazillion ways that messages are validated at > various stages in the delivery process, and nobody could possibly > enumerate what they all are or exactly how downgrading might break > them. Signatures break already due to random mutations in transit, > and a few more broken signatures don't present any new threats. True: there is no new threats, there is just "yet another way to break the mechanism" In case, references to other Security Consideration sections of published RFCs where these thrats are already described, could also be nice to have. > > R's, > John > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From Claudio.Allocchio@garr.it Wed May 2 00:45:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCAE11E807F for ; Wed, 2 May 2012 00:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9JDQE2J8y5w for ; Wed, 2 May 2012 00:45:45 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id C783611E8074 for ; Wed, 2 May 2012 00:45:44 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q427jfp2022041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 09:45:42 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q427jfp2022041 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=bnlwr3vFGrZr87F/r5XG2oF3QPU+KpqkkPpDwokt5iD5ZWjG4yMaPInCLKuhtmbS3 QnKh7N/e3IU10NhHYeQ7MNiOcpbdSUQ51qinxLsaLq3uezM2LNkH3uejIMdeeNYkeJb 78cry5rpvv0M77AdARNB94pUEsc+KKmISHJikgY= Date: Wed, 2 May 2012 09:45:41 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: ned+ima@mrochek.com In-Reply-To: <01OEZA4S4IKM0006TF@mauve.mrochek.com> Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <01OEZA4S4IKM0006TF@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 07:45:45 -0000 > Security considerations do need to cover the issues that cannot be addressed. > That said, all that's really needed here is a statement to the effect that > downgrading may removes addresse information that may be critical to properly > assessing the validity or invalidity of a message. Sure. See John's suggestion. > I see absolutely no point in getting into a bunch of what-ifs. If we do we'll > end up with a 20 page security considerations section that nobody, myself > included, will bother to read. maybe I like to read a lot... :-) but referencing other specification where this has already described can be enough, too. >>> Here is my suggested version of this paragraph: >>> >>> --- >>> >>> 1. Overview >>> >>> It may happen that a conventional IMAP or POP client opens a mailbox >>> containing internationalized messages, or even attempt to read >>> internationalized messages, for instance when a user has both >>> internationalized and conventional MUAs. >>> >>> When this mismatched sitation happens, various strategies are possible: >>> >>> a) the server can hide the existence of such messages entirely, but >>> doing that can be both tricky to implement and gives a false mailbox >>> status to the user; >>> >>> b) the server attempts to present at least some information about these >>> messages to the user. It shall be clear that what the user is being >>> presented is not the original message, and information is dropped; >>> >>> c) the server does nothing, possibly creating problems to the client, and >>> providing a bad user's experience. >>> >>> This document specify a way to implement strategy b), which enables the >>> best compromise between a) and c), and promotes a simple to implement >>> solution which conveys a better-than-nothing information service to the >>> user. Accuracy of information and Security featues of the message will, >>> however, not be preserved, and users should rely on an internationalised >>> client as much as possible. >>> >>> The server is assumed to be internationalized internally. When it >>> needs to present an internationalized message to a conventional >>> client, it synthesizes a conventional message containing most of the >>> information and presents that (the "synthetic message"). > >> You've made it about four times as long and hardly four times as good. > > I'm afraid I have to agree. I see nothing wrong with the current text. well, here is -1... again I like to read a lot... but what's wrong is being descriptive? ha ok... I see... I did like to write: $ directory/date/size/protection/owner/group *.txt instead of claudio% ls -la *.txt :-) it's my old bias and fault :-) But... I listed it as a "Minor Issue", so... >> It's not obvious, it's wrong ;) Nothing is made impossible, it was >> impossible to start with. > > While I agree, perhaps a statement to the effect that an EAI address is > inherently unusable by an non-EAI-client and this does nothing to change that > would be in order. another +1 ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From internet-drafts@ietf.org Wed May 2 01:03:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE90321F87E6; Wed, 2 May 2012 01:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNLPy5Hs9lih; Wed, 2 May 2012 01:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913BD21F87C4; Wed, 2 May 2012 01:03:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120502080344.29592.49110.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2012 01:03:44 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-simpledowngrade-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:03:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Wo= rking Group of the IETF. Title : EAI: Simplified POP/IMAP downgrading Author(s) : Arnt Gulbrandsen Filename : draft-ietf-eai-simpledowngrade-04.txt Pages : 8 Date : 2012-05-02 This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/ From arnt@gulbrandsen.priv.no Wed May 2 01:07:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4066021F8A4F for ; Wed, 2 May 2012 01:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdaMV6tYyZfs for ; Wed, 2 May 2012 01:07:20 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 93B0621F8A4D for ; Wed, 2 May 2012 01:07:20 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3C770F8E7DD; Wed, 2 May 2012 08:07:19 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335946038-31604-31603/10/2; Wed, 2 May 2012 08:07:18 +0000 Message-Id: <4FA0EB47.50207@gulbrandsen.priv.no> Date: Wed, 2 May 2012 10:07:35 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <20120502080344.29592.49110.idtracker@ietfa.amsl.com> In-Reply-To: <20120502080344.29592.49110.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] I-D Action: draft-ietf-eai-simpledowngrade-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:07:21 -0000 On 05/02/2012 10:03 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Email Address International= ization Working Group of the IETF. >=20 > Title : EAI: Simplified POP/IMAP downgrading > Author(s) : Arnt Gulbrandsen > Filename : draft-ietf-eai-simpledowngrade-04.txt In my inimitably ru^H^Hfrank style, another update. A bit of wordsmithing, and two changed paragraphs in the overview section. "Some operations cannot be performed by conventional clients. Most importantly, one or more addresses on an internationalized message are not valid according to the specifications the client uses, so address-based operations are not possible. This includes displaying the addresses, replying, and most types of address-based signature or security processing. Still, the sender's name, the message subject, body text and attachments can easily be displayed, so a helpful IMAP/POP server may prefer to provide access to what it can rather than hide the message entirely." Arnt From Claudio.Allocchio@garr.it Wed May 2 01:10:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3317B21F8A60; Wed, 2 May 2012 01:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-gxQb+SGonR; Wed, 2 May 2012 01:10:19 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id A3DCB21F8A63; Wed, 2 May 2012 01:10:18 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q4289jDB023061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 10:09:46 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q4289jDB023061 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=u3YYL0Ei6DWo2cwelV2BdF8XD1NrAQyMmFOZgwDMQD18h5v9dq9MeA28a8pmZRTTG 5WmTwmn5e+JFD0VjE6OXJruCPNKy0xcIkSPOOdbu9Bhblrxf2OKrjs7OroBZpzIXwFu gcSDptKxXnvwCdVjU5QtQUYJJQfup6tpji0B2dM= Date: Wed, 2 May 2012 10:09:45 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Arnt Gulbrandsen In-Reply-To: <4FA0E0F3.5050208@gulbrandsen.priv.no> Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <4FA0E0F3.5050208@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: apps-discuss@ietf.org, ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:10:20 -0000 On Wed, 2 May 2012, Arnt Gulbrandsen wrote: > On 05/01/2012 11:16 PM, Claudio Allocchio wrote: >> as I already clarified in other discussions on these lists, I'm not >> talking about the signatures and other features. I'm talking about >> including a Security consideration section which describes clearly which >> features can be broken, and just warns about this. > > OK, what are they? please read ALL replies before re-posting. Digesting information helps in non real time discussions like those using ML: On Wed, 2 May 2012, John Levine wrote: > I suppose we could add something like this: > > MUAs that attempt to validate message signatures such as DKIM or > S/MIME will often be unable to do so, since the downgrade > modifications will often break the signatures. Users should upgrade > to an EAI-capable MUA if they wish to continue doing signature > validation in the MUA. I replied: this is a good short and clear way to state the problem! +1 is this ok for you, too? >> being long is a problem in a specification? > > Yes. well, this is your opinion, were you probably then write the code yourself out of the specification, or suppouse that all implementers belong to the IETF world, etc.. I'm afrid I live in a different world where programmers sometine do not even know what a "scoket()" call does internally and why. But, this is an off topic for now, is it? > Do you really think that someone who has written an IMAP or POP server > and extended it to support EAI needs to be told that EAI extends email > addresses incompatibly? yes, and see above why. and it does not harm anybody. :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From arnt@gulbrandsen.priv.no Wed May 2 01:21:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8444521F8AD7; Wed, 2 May 2012 01:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieSdcqqegB+q; Wed, 2 May 2012 01:21:56 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id AFAD721F8AD6; Wed, 2 May 2012 01:21:56 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2194CF8E796; Wed, 2 May 2012 08:21:55 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335946914-31604-31603/10/3; Wed, 2 May 2012 08:21:54 +0000 Message-Id: <4FA0EEB4.6080507@gulbrandsen.priv.no> Date: Wed, 2 May 2012 10:22:12 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Claudio Allocchio References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <4FA0E0F3.5050208@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:21:57 -0000 On 05/02/2012 10:09 AM, Claudio Allocchio wrote: > On Wed, 2 May 2012, Arnt Gulbrandsen wrote: > >> On 05/01/2012 11:16 PM, Claudio Allocchio wrote: >>> as I already clarified in other discussions on these lists, I'm not >>> talking about the signatures and other features. I'm talking about >>> including a Security consideration section which describes clearly which >>> features can be broken, and just warns about this. >> >> OK, what are they? > > please read ALL replies before re-posting. Digesting information helps > in non real time discussions like those using ML: When I uploaded -04 at 9:50, I had read all the mail that had arrived until 9:30. Specifically regarding the security problems, I've seen that signatures can be invalid, which is in the draft, and nothing else that's concrete enough to add to the draft. I'm sorry if I've overlooked anything. Arnt From arnt@gulbrandsen.priv.no Wed May 2 01:29:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4221F8B2B for ; Wed, 2 May 2012 01:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+-eAfHlE8T6 for ; Wed, 2 May 2012 01:29:39 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8A32021F8B29 for ; Wed, 2 May 2012 01:29:39 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 20D84F8E79A; Wed, 2 May 2012 08:29:38 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335947377-31604-31603/10/4; Wed, 2 May 2012 08:29:37 +0000 Message-Id: <4FA0F083.3010401@gulbrandsen.priv.no> Date: Wed, 2 May 2012 10:29:55 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Ned Freed References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <01OEZA4S4IKM0006TF@mauve.mrochek.com> In-Reply-To: <01OEZA4S4IKM0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:29:40 -0000 Ned Freed answers me: >> > Think about it: How would a program verify a signature when it = cannot >> > parse the signature's owner's address? Now downgrade the signature's >> > owner's address, using any algorithm you can think of. What new = issue >> > has been introduced? > That's certainly true for any mechanism that verifies signatures using > addresses. It also points out additional work EAI needs to do to deal = with the > use of EAI addresses in S/MIME and elsewhere. And since we cannot = predict how > that will go, it is pointless to try and address any potential issues = those > standards have with EAI or downgrading in any present specification. >=20 > Now, there may be other security mechanisms out there that interact = with EAI in > interesting ways. Not to put too fine point on it, but that's their = problem to > solve, not ours. I think I'm willing to mention any such problem, probably without much detail. But I resent being told that I should go looking for problems. Anyone who wants me to mention a problem has to tell me what the problem is, without handwaving. > Security considerations do need to cover the issues that cannot be = addressed. > That said, all that's really needed here is a statement to the effect = that > downgrading may removes addresse information that may be critical to = properly > assessing the validity or invalidity of a message. Hm. I tried rewording the first paragraph of the security considerations. As I see it, it's neither better nor worse than before. But maybe others like it more. >>> > > At lease one sentence clearly stating that this will make = impossible to >>> > > reply to such a synthetic message should be present here. Too = obvious? >>> > > no... never suppouse that. >> > It's not obvious, it's wrong ;) Nothing is made impossible, it was >> > impossible to start with. > While I agree, perhaps a statement to the effect that an EAI address is > inherently unusable by an non-EAI-client and this does nothing to = change that > would be in order. (There are potential schemes involving encoding that > could be used to address that, but we have avoided them - I think for > good reason.) It's water under the bridge. This is not the time to reconsider basic EAI design choices. Arnt From fujiwara@jprs.co.jp Wed May 2 02:49:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C3D21F8AF3 for ; Wed, 2 May 2012 02:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WigJZYJDNE+r for ; Wed, 2 May 2012 02:49:51 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEDF21F8AF1 for ; Wed, 2 May 2012 02:49:51 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q429nAGP021144; Wed, 2 May 2012 18:49:10 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-fa-4fa10315947b Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 8A.1F.03276.51301AF4; Wed, 2 May 2012 18:49:09 +0900 (JST) Date: Wed, 02 May 2012 18:49:09 +0900 (JST) Message-Id: <20120502.184909.258138487.fujiwara@jprs.co.jp> To: Claudio.Allocchio@garr.it From: fujiwara@jprs.co.jp In-Reply-To: <6.2.5.6.2.20120501024140.0a368638@resistor.net> References: <6.2.5.6.2.20120501024140.0a368638@resistor.net> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsWyRoiFT1eMeaG/wSwvi4V3NrNbXF+6jt2B yWPru3eMHkuW/GQKYIrisklJzcksSy3St0vgyji9cg1LwS3FiuUH1rI0MDZIdzFyckgImEgs nTqFGcIWk7hwbz0biC0kcJJR4k2/MIjNIqAt8e/CJXYQm1fAWuLOz16WLkYODhEBWYlzi9RA wswCAhInL81jBLGFBTwk9iy6BmazCUhKbP7cCjaeU8BW4mzDHlaQViEBG4nT93IhttpJnHi+ AizMKyAo8XeHMMRELYmeGY/ZIWx5ie1v5zBPYOSfhVA1C0nVLCRVCxiZVzHK5Kel6Ran5qUU 56YbGOqVVObrZRUUFeslg+hNjOAA5FDYwTjjlMEhRgEORiUe3ppHC/yFWBPLiitzDzFKcjAp ifLK/AUK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGteAeU401JrKxKLcqHSUlzsCiJ8x4/u8NP SCA9sSQ1OzW1ILUIJivDwaEkwSvAtNBfSLAoNT21Ii0zpwQhzcTBCTKcB2i4NUgNb3FBYm5x ZjpE/hSjpJQ4rwNIQgAkkVGaB9f7ilEc6AVhXiuQLA8wmcB1vQIayAQ0MN98HsjAkkSElFQD 48HNstcEEv+L+8qbT+P9tzg4UOPx10JuLR1ejTfvF7tWbczrnzfxeP4cax9ZBZHHkw1NX3zK neiicnxbguPiZR1F0vO/8dRmtN++I8511tb92fof/KILI1/kR7v05qUwma798DGHz/Zle9at LVPfvjYJ2XvZLT2rx/nO3YuPVx69UixvkHEiW4mlOCPRUIu5qDgRAEyUepzjAgAA Cc: ima@ietf.org Subject: Re: [EAI] AppsDir review of draft-ietf-eai-popimap-downgrade-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 09:49:52 -0000 I will update the draft after next iterim meeting. People who attend the iterim meeting should read this comment. It contains two discussion points. 1. updating RFC 5322 (or not) 2. how to rewrite NON-ASCII elements (different from draft-ietf-eai-simpledowngrade) -- Kazunori Fujiwara, JPRS > From: Claudio Allocchio (by way ofS Moonesamy ) > Hello all, > > I have been selected as the Applications Area Directorate co-reviewer > for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > ). > > Please resolve these comments along with any other Last Call comments > you > may receive. Please wait for direction from your document shepherd or > AD > before posting a new version of the draft. > > Document: draft-ietf-eai-popimap-downgrade-05 > Title: Post-delivery Message Downgrading for Internationalized Email > Messages > Reviewer: Claudio Allocchio > Review Date: April 30th 2012 > IETF Last Call Date: n/a > IESG Telechat Date: n/a > > Summary: This document is requires a major decision about updating/non > updating RFC 5322 before it can go to publication. Once this is done, > other minor changes are listed below and it can be published. Another > issue to clarify/fix is its relationship with > draft-ietf-eai-simpledowngrade-03 specification (and also in that > document, of course, with respect to this one). > > Major Issues: > > 3. Updating RFC 5322 > > this is a big major issue in this specification. > > I do not believe that stating something like "It is anticipated that > when existing implementations encounter a downgraded field from this > set, many will tolerate the appearance of a group" is a possible thing > into a Standards Track specification. Th "update" to RFC 5322 is a > big major one, and cons should be carefully evaluated here, too. As > the "Notes in Draf" itself states, there is an alternate, much safer > mechamism which can be used, and convey the same information to the > user. This isse must be clarified before this specification can be > publisehd, and a decision taken. > > Minor Issues: > > there is not cross-reference at all with > > draft-ietf-eai-simpledowngrade-03! > > many implementers could ge confused about the releationship between > these specifications. In the Summary this should be explicitly > described and clearly stated. > > Security Considerations > > this section describes quite well the possible scenarios which this > specification introduces (and can also be a good example for > re-writing > the same secrion in draft-ietf-eai-simpledowngrade-03); I'd just > suggest a further review by the Security area folks, too. Just in > case... > > Nits: > > 1.1 Problem statement > > I'd suggest removing "Discussions leading to this specification > concluded that " and just start with "There are four...' > > 5.1.1 until 5.1.9 > > in the titles you use the defintions without the <...> surrounding > them. > e.g. > > 5.1.5 GROUP Downgrading. > > I'd suggest changing them all using the < and > ... e.g. > > 5.1.5 Downgrading. > > etc. > > IANA Considerartions: > > ... to be fixed with IANA before publication! > > All over the document (and expecially in the A.1 example): > > this document uses a different convetion than > draft-ietf-eai-simpledowngrade-03 for non ASCII elements in > addresses/fields. Please unify the used convetion with the other draft > (whichever of the 2 convetion is better) before publication. > > Here you write "NON-ASCII-something..." there you just use UPPERCASE. > > ------------------------------------------------------------------------------ > Claudio Allocchio G A R R Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From johnl@taugh.com Wed May 2 04:52:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176D821F89A2 for ; Wed, 2 May 2012 04:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO9kdunW8UwY for ; Wed, 2 May 2012 04:52:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1821F8841 for ; Wed, 2 May 2012 04:52:38 -0700 (PDT) Received: (qmail 11978 invoked from network); 2 May 2012 11:52:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2ec8.4fa12005.k1205; bh=HLewbIh3c1+bxnXUn/UC/qWl4L9lmr6yzDSrUmhCEEI=; b=FwMPaJftn1qgxy1vVI7aKcXoGTBlq7Ss9lk/DZkWkAsPJtJTk2zCzeJTwkEUYv8U1vgBrv2qmDzqp8flok/jVEU93zAwC4YdKLI5A7OlH/D2wFemigZGiHrvV2tor5yGaQ6vhfF1tcpvGJVOots6QzNUELze9Hy7acDjrqBGLdo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2ec8.4fa12005.k1205; bh=HLewbIh3c1+bxnXUn/UC/qWl4L9lmr6yzDSrUmhCEEI=; b=ARodYlaapygZ7/06M75RFww9Na2iDBkDHUNFp4bs2QnSwZNd/4d+ripvX2bSOI/Dx5FtS0yPLnQkB1qr9i+x92WPO6cOqGSiFU4Fl8NZOeChFEwshoPwYp8hTgvzM8/EsTuy/bJRCXNPGtqpmQeAh3L1WoLCXPx/jwQnyUd9E5U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 2 May 2012 11:52:15 -0000 Date: 2 May 2012 07:52:37 -0400 Message-ID: From: "John R Levine" To: "Claudio Allocchio" In-Reply-To: References: <20120502045002.4577.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:52:40 -0000 >> MUAs that attempt to validate message signatures such as DKIM or >> S/MIME will often be unable to do so, since the downgrade >> modifications will often break the signatures. Users should upgrade >> to an EAI-capable MUA if they wish to continue doing signature >> validation in the MUA. > > this is a good short and clear way to state the problem! +1 Oh, good. > In case, references to other Security Consideration sections of published > RFCs where these thrats are already described, could also be nice to have. Perhaps I'm overly grumpy, but it doesn't seem like a good use of anyone's time to try to make a list of every RFC that mentions a security scheme that someone might use in e-mail. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From arnt@gulbrandsen.priv.no Wed May 2 05:14:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40B21F898D for ; Wed, 2 May 2012 05:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyddd7-4g6zW for ; Wed, 2 May 2012 05:14:27 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5209721F898B for ; Wed, 2 May 2012 05:14:27 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 13CC6F8D5E1; Wed, 2 May 2012 12:14:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335960864-31604-31603/10/6; Wed, 2 May 2012 12:14:24 +0000 Message-Id: <4FA12531.3020500@gulbrandsen.priv.no> Date: Wed, 2 May 2012 14:14:41 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <6.2.5.6.2.20120501024140.0a368638@resistor.net> <20120502.184909.258138487.fujiwara@jprs.co.jp> In-Reply-To: <20120502.184909.258138487.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] AppsDir review of draft-ietf-eai-popimap-downgrade-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 12:14:28 -0000 I suppose there's no reasonable way around it. I really, really didn't want to publish my opinion of popimap-downgrade in RFC form, but there seems to be no way around it. Please help me rewrite the text below so noone will think I'm flaming Kazumori. The editor of a WG document deserves no blame if WG members ask him to add complexity, and he does so. The result may suffer from rampant featuritis, but that's the WG's fault, not the editor's. Arnt Appendix X. Comparison with [RFC-popimap-downgrade] The EAI working group has also produced another downgrade description, [RFCxxxx]. The two descriptions share some traits, but also have some important differences. This appendix is opinionated, and the author does not expect readers to share his opinion. While the prose below discusses IMAP, the same issues apply to POP. The most important common traits is that most conventional MUA will display the subject and main body text of most downgraded messages correctly, and that they generally cannot reply. The two documents take very different positions on the appropriate balance between implementation complexity and accuracy of presentation. Where this document allows the server to discard many things, [RFCxxxx] often/always[?] preserves all message content. An unextended IMAP client may not be able to see the content, but a skilled human debugger can. If, for instance, a Received header field contains unicode text, this document suggests that the server not show that field to the client. [RFCxxxx] preserves its content, which may require the server to know the syntax of many more header fields than this document does, and requires implementation work in the client to derive full advantage. [RCCxxxx] specifies enough detail that an IMAP client can read and display internationalized mail accurately using either [RFC5738] or [RFCxxxx]. In contrast, this document is based on a stance that there should be only one IMAP extension to read internationalized mail, and it's [RFC5738]. (It follows from that difference that [RFCxxxx] specifies exactly how to downgrade addresses and this document doesn't.) One might say that [RFCxxxx] is appropriate for a world where conventional and internationalized clients coexist for a long time, and where it's appropriate to put a great deal of effort into downgrading, while this document is appropriate for a quick transition, where it's more appropriate to put effort into implementing [RFC5721] and [RFC5738] and skimp on transition support. From ned+ima@mrochek.com Wed May 2 08:56:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0211F11E8085 for ; Wed, 2 May 2012 08:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9zQPFDFjps8 for ; Wed, 2 May 2012 08:56:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACE811E8081 for ; Wed, 2 May 2012 08:56:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF02GU1AQO000TUZ@mauve.mrochek.com> for ima@ietf.org; Wed, 2 May 2012 08:56:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 2 May 2012 08:56:14 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OF02GSEP160006TF@mauve.mrochek.com> Date: Wed, 02 May 2012 08:55:48 -0700 (PDT) In-reply-to: "Your message dated Wed, 02 May 2012 07:52:37 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120502045002.4577.qmail@joyce.lan> To: John R Levine Cc: ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:56:19 -0000 > >> MUAs that attempt to validate message signatures such as DKIM or > >> S/MIME will often be unable to do so, since the downgrade > >> modifications will often break the signatures. Users should upgrade > >> to an EAI-capable MUA if they wish to continue doing signature > >> validation in the MUA. > > > > this is a good short and clear way to state the problem! +1 > Oh, good. > > In case, references to other Security Consideration sections of published > > RFCs where these thrats are already described, could also be nice to have. > Perhaps I'm overly grumpy, but it doesn't seem like a good use of anyone's > time to try to make a list of every RFC that mentions a security scheme > that someone might use in e-mail. If this is "overly grumpy" then it's a condition I share. Ned From johnl@iecc.com Wed May 2 17:46:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ED011E80B1 for ; Wed, 2 May 2012 17:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.1 X-Spam-Level: X-Spam-Status: No, score=-111.1 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOKnVIM4zRmY for ; Wed, 2 May 2012 17:46:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E75F911E809B for ; Wed, 2 May 2012 17:46:58 -0700 (PDT) Received: (qmail 51938 invoked from network); 3 May 2012 00:46:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 May 2012 00:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa1d581.xn--hew.k1205; i=johnl@user.iecc.com; bh=4i63I/rMakHarLqBhedy8UFf2sxxgq8ywtVA7naMqxU=; b=a+3WJPJg47ztfHymtSQiEEZEdWJJea4W7pvPebjAelpwLNwyI3Bzy6PVnXwrlFdCqg+iHJFdeN9NSdxZMvxXHTqkP/fa+Olkymu8P8OSxACdqLGrYsU9NW+6oTp0JtA1GwT0v56mDKIcIKyiY8Ch73GNWlb8jAKuD21N7DoxB34= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa1d581.xn--hew.k1205; olt=johnl@user.iecc.com; bh=4i63I/rMakHarLqBhedy8UFf2sxxgq8ywtVA7naMqxU=; b=ZUrCirR1RzFRoBE+Xj9IA3qlXeabIyJySx/SQCPTjo2mD64nYrjZXyjHve0hFOufEYTAx/+BhLbQ9QUolnLQOm8rqGU5V+zdNYblqrQ2j8hMNwvShaLb6jjcGX5i0Y2acbGTJE08xsshna6feUNDQAFnIfgLndKfR0pV87lHpQ4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 May 2012 00:46:35 -0000 Message-ID: <20120503004635.30109.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [EAI] draft-ietf-eai-simpledowngrade-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 00:46:59 -0000 In the Security Considerations part, where it says "signed body parts", please make that "signed body parts or a DKIM signature". I'm a little vague about what IMAP status would be appropriate for an EAI message that had an unencoded UTF-8 subject, but no non-ASCII addresses in the headers. (I also don't think it's a big deal.) Other than that, it seems fine. R's, John From jyee@afilias.info Wed May 2 21:21:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6B11E8080 for ; Wed, 2 May 2012 21:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP9ZnZIXtnFJ for ; Wed, 2 May 2012 21:21:16 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0668411E8076 for ; Wed, 2 May 2012 21:21:15 -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 1SPnXX-00013c-6X for ima@ietf.org; Thu, 03 May 2012 04:21:15 +0000 Received: from mail-yx0-f178.google.com ([209.85.213.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SPnXW-00043r-9G for ima@ietf.org; Thu, 03 May 2012 04:21:14 +0000 Received: by yenm14 with SMTP id m14so1488352yen.9 for ; Wed, 02 May 2012 21:21:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7rU66SZgwDDKSfPitM3uhA3a47/3sErY5Ejtxii9ZVI=; b=EupY1mXsiU5dZk2Lb7ris5RBRW0BQJ1TdX3xf1sKBVUrEjtO+o+dFSVjXOWUkJHjhq FRr+XVA6CffdsEMlilccbzc7MdZY4ZJJ1FqzfiHHPP37Gq6vNsE3rll1rVwlUczLdoRm Bb+PddxUt+S6liMG4Gn5Yxyc+2WglXqKNTQC/Q+tUqZdH2V1Q51vsZJxznDr4CNpP3Gg KXPERW4iFQqegdfscohZDIyu+kLHufZEME8Gzzhuts4a5knO3YKj45GC2h4RcdUWUVVp N9A5u5kgatjp9uxyEMCv7Nb++IILaLjZh7P8Rp+3dOGzfTvLUO4N2WzjpWScSwrvxycm 2nTA== Received: by 10.50.184.166 with SMTP id ev6mr357503igc.63.1336018874117; Wed, 02 May 2012 21:21:14 -0700 (PDT) Received: from [192.168.0.105] (75-119-255-184.dsl.teksavvy.com. [75.119.255.184]) by mx.google.com with ESMTPS id dl10sm23937832igb.5.2012.05.02.21.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 21:21:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Joseph Yee Date: Thu, 3 May 2012 00:21:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68B7634B-A946-4F53-83E4-AD5E76E4486E@afilias.info> References: <20120427203650.29585.45699.idtracker@ietfa.amsl.com> To: "ima@ietf.org WG" X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkRrefqb+YTvguJVx7e0x1Vlbm5SLguGa4II0tIEWE8FFFS90f6noMt9DUn0LbJ/7KFDy6N Subject: [EAI] Fwd: EAI WG Virtual Interim Meeting: Monday, May 14, 2012 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 04:21:21 -0000 All, Just an early reminder to everyone of the interim meeting at May 14, and = please provide revision of the draft by May 9 so that everyone read and = discuss the same draft. Revision after May 9 is acceptable, but prefer = to be editorial only update, and please provide rdiff along with the = notification to the mailing list so that it's easy for everyone to track = the change. Thanks Joseph Begin forwarded message: > From: IESG Secretary > Date: April 27, 2012 4:36:50 PM EDT > To: IETF Announcement List > Cc: ima@ietf.org > Subject: EAI WG Virtual Interim Meeting: Monday, May 14, 2012 >=20 > The next EAI WG virtual interim meeting will be via jabber chat > (eai@jabber.ietf.org) on Monday, May 14 at 12:00 UTC for 2 > hours. >=20 > Local times for 12:00 UTC: > = http://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF+EAI+WG+Jab= ber+Chat&iso=3D20120514T12&ah=3D2 >=20 > Draft: agenda, subject to discussion on the mailing list prior > to the meeting, is >=20 > 1 Agenda Bash >=20 > 2 POP/IMAP Cluster > Discussion of the following drafts. A _short_ WG Last Call will > be initiated either immediately after the meeting or immediately > after new versions can be posted if the latter is necessary: >=20 > draft-ietf-eai-5738bis-03 (IMAP) > draft-ietf-eai-rfc5721bis-04 (POP) > draft-ietf-eai-popimap-downgrade-05 > draft-ietf-eai-simpledowngrade-03 >=20 > 3 Other drafts > Discussion of status and plans for mailing lists and MAILTO. >=20 > 4 AOB=20 From ned+ima@mrochek.com Thu May 3 11:48:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3543621F8644 for ; Thu, 3 May 2012 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY2C0ojy+F6x for ; Thu, 3 May 2012 11:48:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2D621F8656 for ; Thu, 3 May 2012 11:48:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF1MRSC70W0010WY@mauve.mrochek.com> for ima@ietf.org; Thu, 3 May 2012 11:48:33 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 3 May 2012 11:48:30 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OF1MRQJ1WU0006TF@mauve.mrochek.com> Date: Thu, 03 May 2012 11:44:27 -0700 (PDT) In-reply-to: "Your message dated Wed, 02 May 2012 10:29:55 +0200" <4FA0F083.3010401@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <01OEZA4S4IKM0006TF@mauve.mrochek.com> <4FA0F083.3010401@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 18:48:38 -0000 > ... > But I resent being told that I should go looking for problems. Anyone > who wants me to mention a problem has to tell me what the problem is, > without handwaving. I completely understand, and agree. If specifics are desired, someone needs to volunteer text. > ... > > While I agree, perhaps a statement to the effect that an EAI address is > > inherently unusable by an non-EAI-client and this does nothing to change that > > would be in order. (There are potential schemes involving encoding that > > could be used to address that, but we have avoided them - I think for > > good reason.) > It's water under the bridge. This is not the time to reconsider basic > EAI design choices. Of course. I was only making a side comment on what might have been, but isn't and isn't going to be. Ned From barryleiba.mailing.lists@gmail.com Fri May 4 18:25:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565021E801F; Fri, 4 May 2012 18:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc1bf5ABTHPC; Fri, 4 May 2012 18:25:05 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D33021E8018; Fri, 4 May 2012 18:25:04 -0700 (PDT) Received: by lagj5 with SMTP id j5so2763886lag.31 for ; Fri, 04 May 2012 18:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Pr8tvjhdSF7EpXJNFRM7XtR1vdqMjQ572SCeNvqXkUk=; b=LlVDaTrMNRdxox9oMcklw+tB1otZ2VBvljaQY485zKAFSXJhlKjk4IPHu50ei/Vr2i tV86UaQYAFyX2KMGKcKniGd3fNrkiJxa4QBD9OFwjz5tY6hfUYDYn44jTZrHDsLfnFTu Ny7H2sMNoP9rATNq+bbInHNFHMKhAs3yHohm8crYLpO40PHs/YKDtW7hjXjE6Z5+k9Ta kWRP3GanBavDUgvGevQzbnakmF9mcPB30NMzkcEAKRt69SSPqxAo5NjDqhAd+rCpCn/z 36181JDAmZLOtzsYM8WTXJmxRyujxmjfS7qRhKgVu5UPe9ARxwhzB7xxSyaO9We0CToS XUVw== MIME-Version: 1.0 Received: by 10.112.88.98 with SMTP id bf2mr3951061lbb.30.1336181104033; Fri, 04 May 2012 18:25:04 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Fri, 4 May 2012 18:25:03 -0700 (PDT) In-Reply-To: <4FA04B17.9050902@gulbrandsen.priv.no> References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> Date: Fri, 4 May 2012 21:25:03 -0400 X-Google-Sender-Auth: 3iRNGhqzeS9H2fjK9uUn6eLGKtM Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=bcaec554da2a0fbec104bf3fe82e Cc: "ima@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:25:06 -0000 --bcaec554da2a0fbec104bf3fe82e Content-Type: text/plain; charset=ISO-8859-1 >> 7. IANA Considerations >> >> ADD the name of the correct registry! > > I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. Oy. Sorry: you're both being lazy. The IANA registries are here: http://www.iana.org/protocols/ One can (and should) look up the registry, and use the correct name, without guessing. That said, Claudio didn't look it up either, and as it turns out, Arnt (1) did use the correct name and (2) between the correct name and the reference to the creating RFC, specified it entirely adequately for IANA to understand it. In other words, the IANA section is fine. Barry --bcaec554da2a0fbec104bf3fe82e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> 7. IANA Considerations
&= gt;>
>> ADD the name of the correct registry!
>
> I= 'm afraid the schmuck who wrote RFC 5530 didn't define a correct na= me.

Oy. =A0Sorry: you're both being lazy. =A0The I= ANA registries are here:
http://www.iana.org/protocols/<= /a>

In other words, the IANA section is fine.

Barry
--bcaec554da2a0fbec104bf3fe82e-- From Claudio.Allocchio@garr.it Sat May 5 07:34:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27521F8498; Sat, 5 May 2012 07:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAmzf7xuYphB; Sat, 5 May 2012 07:34:14 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D421F8495; Sat, 5 May 2012 07:34:13 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q45EY0ft096799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 May 2012 16:34:07 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q45EY0ft096799 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=AWVXxGfSiV+kEckB3XJx0AzPL9W1dMAG623qxoRacZ6DF03ukFmKRYXnvvptkQ9dQ cZNnFhdfzJ1S7i1vQthRuDBC+iWG4Cbq2FEPaBPDJTcE1NfD0vD+70Ufh6th3m0Joh0 yFRpPCYjTYQskcv388CSwdIXg7GATDYrPJbRbHw= Date: Sat, 5 May 2012 16:34:01 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Barry Leiba In-Reply-To: Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Arnt Gulbrandsen , "ima@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [EAI] [apps-discuss] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 14:34:15 -0000 On Fri, 4 May 2012, Barry Leiba wrote: >>> 7. IANA Considerations >>> >>> ADD the name of the correct registry! >> >> I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. > > Oy. Sorry: you're both being lazy. The IANA registries are here: > http://www.iana.org/protocols/ yes... but? > One can (and should) look up the registry, and use the correct name, > without guessing. that's why I added my Nits note. > That said, Claudio didn't look it up either, and as it turns out, Arnt (1) True, I did not loked at it. > did use the correct name and (2) between the correct name and the reference > to the creating RFC, specified it entirely adequately for IANA to > understand it. > > In other words, the IANA section is fine. that why "(RFC editor: Please remove this paragraph. I can't remember the URL of the registry, but it's the one specified in RFC 5530.)" ? ;-) but as I said, it's a Nit. > Barry > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From klensin@jck.com Sat May 5 08:04:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59121F8593 for ; Sat, 5 May 2012 08:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-QXMlgbGL1a for ; Sat, 5 May 2012 08:04:16 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id F356421F858F for ; Sat, 5 May 2012 08:04:15 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SQgRm-000Cee-4A for ima@ietf.org; Sat, 05 May 2012 10:58:58 -0400 Date: Sat, 05 May 2012 11:04:10 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <1EBBAA421C87B002A0E1DE44@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 15:04:17 -0000 Hi. I've been trying to watch the discussion, rather than participating in it, in the hope that I could instead summarize conclusions and get us moving forward. Note that the comments and conclusions below are my summaries and extrapolations from what has been said on the list and are tentative: if anyone disagrees in any substantive way, speak up. Circa 50 messages in the last couple of weeks later... (1) I infer that we have general agreement on the basic EAI IMAP and POP specs. If we do not, people had better speak up quickly. We will review those documents quickly on the interim meeting Jabber chat, but, in the absence of significant issues then, I assume that the WG thinks the drafts are ready to go to the IESG and will start doing my final WG Chair (pre-Shepherd-writeup) check. (2) A separate note will follow about the other downgrade spec (draft-ietf-eai-popimap-downgrade). (3) Re the Simple Downgrade draft, I believe that, with the possible exception of one or two people or issues in the rough, the WG has concluded: (3.1) The Security Considerations should mention issues that are specific to receiver-end downgrading and to this spec. John Levine's request to include a DKIM pointer along with "signed body parts" falls into that category, but note that there is already text suggesting that the implementer better be really careful when altering messages that are signed in any way in the Framework spec (RFC 6530). A pointer to the Security Considerations section of the basic IMAP spec would be in order if the author likes (i.e., I consider the question of whether the pointers that effectively incorporate the IMAP spec by reference make such an additional reference/comment unnecessary to be a matter of author discretion unless the WG feels _very_ strongly to the contrary). Like Claudio, I generally tend to prefer to err on the side of too much explanation and detail rather than too little. However, no matter what we do in this spec, anyone who tries to implement it without a good understanding of the POP and/or IMAP specs and the documents that define the EAI changes to POP and IMAP is going to be in really serious trouble. I think we need to keep in mind that giving people enough detail that they might believe they don't need to understand the specs that this one supplements does no one any favors. And I think that tips the balance significantly toward not repeating (even by summary and reference) a lot of material here that appears elsewhere. I think it is also worth noting in this discussion that the split-UA model that underlies both IMAP and POP implies a certain intimacy between client and server that does not exist with, e.g., normal SMTP transit relationships. Yes, we have protocols that permit different clients to interwork with the same servers and vice versa, but a great many things depend on the assumption that the IMAP (or POP) client-server relationship involves a reasonably high level of trust in each other and in the channel -- the relationship is nowhere near as easy to compromise as, e.g., the one between a pair of SMTP relays or, historically, the DNS. (3.2) As a partial followup to the above, I think we have all known since the EAI effort started that this work would inevitably require updates, or at least careful review, to any security mechanism that involves integrity checks that are sensitive to the media type of the body parts, that involve signatures over either external or internal headers, or that use email addresses as identifiers. I've just reviewed the charter and I can find absolutely no support for the idea that it is our problem. The same comment applies to issues of UI presentation of messages involving valid or invalid signatures even though I think this work emphasizes how little deep thought the IETF has given to that problem. So, for those who want to pursue those reviews and upgrades, my very best wishes, but take it somewhere else. (3.3) There are a number of ways in which the popimap-downgrade draft, by virtue of taking on a harder task and possibly because it has had more time to mature in the WG, is simply more comprehensive than this one. That is ok because it is really another symptom of the tradeoffs between a comprehensive, but complex, approach and one that is "good enough" for some set of cases but much simpler. But, picking up a comment of Claudio's from several days ago, the WG may want to consider whether this document should reference that one for additional discussion of some of the risks and issues, especially those that appear in cases that are less easily understood. (3.4) Environments in which complete EAI collections are rolled out at once and made mandatory or in which upgraded POP and IMAP clients and servers are completely deployed before UTF8SMTP is enabled in the delivery MTA are simply irrelevant to these two downgrade specs. If it not clear in the POP and IMAP docs that downgrading is never going to be invoked in those cases, then, despite (1) above, they need to be fixed. Whether they are fixed or not, the two downgrade specs are still unaffected. These documents exist only for the real-world situations in which those who control the servers cannot completely control the end-user's choice of clients _and_ who have chosen to not respond to the combination of a legacy client and a message that requires UTF8SMTP features with an error condition equivalent to "message inaccessible to you until you upgrade (or use webmail)". I don't think anyone has seriously suggested "pretend the message isn't there". Regardless of what the specs say, every competent POP and (especially) IMAP server implementation in the world --except those that are designed to sit behind delivery MTAs or mail stores that will reject or drop problem messages-- has mechanisms for dealing with messages that are sufficiently broken that they can't be delivered across the interface. I've seen POP3 implementations that put message numbers of 0 or snarky comments in the scan listing response to LIST and respond to RETR with "-ERR junk message". Similarly, an IMAP server might respond to SEARCH ALL by including the message numbers of such messages, interpret the option of leaving out messages with non-text and non-Message body parts from more selective SEARCH command responses, and then respond to FETCH NN .. with something like "* NN FETCH (BOGUS)" or "* FETCH NN (BOGUS (22) invalid message format)". If either causes the client to get annoyed, that is more or less the intended behavior. Most of us have also seen clients and occasionally servers self-destruct under equivalent circumstances, but that is, sadly, how it goes. Perhaps IMAP and/or POP should be updated to explicitly allow per-message "junk; cannot convert and download" responses but, again, not this WG's problem. Going back to the discussion that led to the simpledowngrade spec, we should not lose track of the fact that a "you need to upgrade" response will be the right strategy for at least two kinds of environments, the enterprise one in which the intended message will be "we told you to upgrade, you lose until you do" and the large, don't-really-care, provider in which the intended message will be "if you don't want to keep your client up to date, too bad for you". That is ultimately the argument in favor of popimap-downgrade over simpledowngrade: if it is worth going to the trouble of downgrading at all, one might as well exert the extra effort to do it comprehensively. Fortunately, the WG doesn't need to resolve that argument and, if we need a better description of it, this document is probably not the right place. john From johnl@iecc.com Sat May 5 12:43:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3089221F85C4 for ; Sat, 5 May 2012 12:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.103 X-Spam-Level: X-Spam-Status: No, score=-111.103 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NReisjM+83hP for ; Sat, 5 May 2012 12:43:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5343521F8593 for ; Sat, 5 May 2012 12:43:39 -0700 (PDT) Received: (qmail 81598 invoked from network); 5 May 2012 19:43:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 May 2012 19:43:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa582e9.xn--9vv.k1205; i=johnl@user.iecc.com; bh=NWwauFPIFSe5yjsNtINbOE9b82TkBHuZgZC7oo/Soqs=; b=OQxAz8fZhJ94JnFajMKbLnIGgQ46AvbcECOmmXyuA18yaF+G2uelfL9UM9UXJ5SW7vzxp49TZGmWzQX93RIVZM51yRpiEYA+QR76xo6kGU1zywEeieoYuuiXgigF6//Wq5oORrnfn8X162xtjFo91nq+xzqQMy0SmWsxXM4n+cc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa582e9.xn--9vv.k1205; olt=johnl@user.iecc.com; bh=NWwauFPIFSe5yjsNtINbOE9b82TkBHuZgZC7oo/Soqs=; b=PCVSJqWea/5rBfQqr7+VVDF7OfeHUj4Xm92eOo/WCnCoo3yDeeRjmZvrVHkPo8hAqfkTWZjxx7j1osr2D5zIkjWGnRacT2OvwL06d6OLLkRPx2fX9JQoNGTONteUU09DxVhIureQKSucH/thVbGgSNhgSUASgOTVhEBgtRYOy28= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 May 2012 19:43:15 -0000 Message-ID: <20120505194315.6286.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <1EBBAA421C87B002A0E1DE44@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 19:43:40 -0000 > That is ultimately the argument in favor of popimap-downgrade over > simpledowngrade: if it is worth going to the trouble of downgrading > at all, one might as well exert the extra effort to do it > comprehensively. That's the argument, but it's one that I don't find at all persuasive. If a user has a non-EAI MUA, the most a downgrade can realistically do to create something the MUA can display is what simpledowngrade describes. Anything beyond that is a quality of implementation issue that has nothing to do with interoperability. As soon as you rewrite anything, signatures break, heuristics that look for patterns in the header lines don't work any more, and it's just a losing battle to try to make it look like a real non-EAI message. If a message's headers contain EAI addresses, there's no no way a non-EAI MUA can respond to them directly, so there's nothing to standardize with addresses beyond ensuring that one can't reply to them. I'm not aware of any MUA that would do anything useful with Downgraded-Something headers, and I believe I am far from alone in thinking that any work that might be invested in making a MUA use them would be far better spent making the MUA handle native EAI. R's, John From klensin@jck.com Sat May 5 14:06:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6571421F84C4 for ; Sat, 5 May 2012 14:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBUlshL5ys5z for ; Sat, 5 May 2012 14:06:00 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A07E821F841D for ; Sat, 5 May 2012 14:06:00 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SQm5p-000D0n-Vg; Sat, 05 May 2012 17:00:41 -0400 Date: Sat, 05 May 2012 17:05:54 -0400 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> In-Reply-To: <20120505194315.6286.qmail@joyce.lan> References: <20120505194315.6286.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 21:06:01 -0000 --On Saturday, May 05, 2012 19:43 +0000 John Levine wrote: >> That is ultimately the argument in favor of popimap-downgrade >> over simpledowngrade: if it is worth going to the trouble of >> downgrading at all, one might as well exert the extra effort >> to do it comprehensively. > > That's the argument, but it's one that I don't find at all > persuasive. > > If a user has a non-EAI MUA, the most a downgrade can > realistically do to create something the MUA can display is > what simpledowngrade describes. Anything beyond that is a > quality of implementation issue that has nothing to do with > interoperability. As soon as you rewrite anything, signatures > break, heuristics that look for patterns in the header lines > don't work any more, and it's just a losing battle to try to > make it look like a real non-EAI message. >... John (and others), (Co-Chair hat pulled firmly over ears) Let me be blunt, with the understanding that I agreed to take on this WG because there seemed to be general agreement that one of our major shared goals was to move this work forward efficiently, much more efficiently than we have been doing lately. Unless someone is going to argue strongly that the more complex popimap-downgrade spec should simply be dropped, which scenarios you (or others) find persuasive is simply not interesting. You predict that one scenario will dominate and that certain things are important and therefore find some approaches unpersuasive. Others make different predictions and/or assessments of importance. Starting from a variation on some of Ned's comments, others of us may have yet a third prediction. No matter how persuasive each of us may find our individual predictions, there are two important realities. First, we are all making those predictions without specific experience or data about this particular type of situation. Second, people who implement and deploy these things are thoroughly likely to do what they think is right, regardless of what the IETF predicts or thinks is good for them. Another scenario we haven't discussed at all is among the likely ones in some situations. That is that the POP or IMAP server generates an alert or special log entry to what is often called a "Help Desk" with the user's identity and the fact that a message that requires EAI capability has landed in the mailbox so that the Help Desk personnel can do something proactive and entirely out of band. Really low implementation cost and, for those environments in which the "Help Desk" can force upgrades, a very efficient and thoroughly likely one. Similarly, none of our beliefs about how time is best spent are likely to amount to anything. To generalize from what Ned has pointed out several times, implementers have audiences (sometimes called "customers") and are likely to end up doing what those audiences want, whether we think it is efficient or not. So I continue to suggest that we just do as competent a job as we can of documenting the protocol alternatives that subsets of us think are reasonable and then move on, independent of who those who favor (or predict) one scenario feel about the others. The alternative, it seems to me, is to try to reach agreement about those scenarios. All I can say about trying to reach agreement on one scenario is that it is certain to cost us a lot of time and that, based on the discussions of the last several weeks, the odds that many people will be persuaded to change their positions are really low. Recommendation: Those of us who care about (note that I didn't say "like") each of the scenarios try to make sure that the protocols and actions that result are well-thought-out, well-documented, and, ideally, clear about the scenarios for which they are optimized. Let's be sure that the base EAI POP and IMAP documents provide the right references and linkages to whatever downgrade specs are out there and that they are otherwise agnostics. And let's save arguments about persuasiveness or plausibility for some time post-deployment when we've actually accumulated some serious experience. best, john p.s. Nothing personal: you were merely the first person who stuck his head up and made a "presuasiveness" point today. From johnl@taugh.com Sat May 5 14:42:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4F21F8585 for ; Sat, 5 May 2012 14:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0f0u4j8kHvm for ; Sat, 5 May 2012 14:42:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0105221F8573 for ; Sat, 5 May 2012 14:42:43 -0700 (PDT) Received: (qmail 98227 invoked from network); 5 May 2012 21:42:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=17faf.4fa59ed2.k1205; bh=dinfRQTA6WKNOiOf6OtqGOMzEZ0rJ18EtPAEUqiStXE=; b=Ka2EkvovRWs5XpAPEJmxjOCSkJ7YO8gkRocJDVcRNZyZXIelmX1q66LG7NnhBuB1bqC8jvVIGvdeZLSD3wV6QQW7OkSC6rS2vRoTXFRSubwNmbaVDQc8O1myGqeod7tx/F+B8Tx5C6S1wC2kSLfz+8UnoMoKQ6YKlOo2sNGUaJc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=17faf.4fa59ed2.k1205; bh=dinfRQTA6WKNOiOf6OtqGOMzEZ0rJ18EtPAEUqiStXE=; b=yoMjnhn1MlAW+2TJi24yXXR0QUT6UZF6pp20FODcM/mTkZ+MRw4/Fu4OUX5LAH3EXEh6cKpAj8bJwjMgYSRk2WqXvWG8CiQbH2slPGYjUOa3qelh6ojtigOE3YCqCqwW7KzRs/e3MD6UlGc0A/d4Vle0xhNLEM3BgyAHlVAmcbM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 5 May 2012 21:42:20 -0000 Date: 5 May 2012 17:42:42 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> References: <20120505194315.6286.qmail@joyce.lan> <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 21:42:44 -0000 > Second, people who implement and deploy these things are thoroughly > likely to do what they think is right, regardless of what the IETF > predicts or thinks is good for them. Of course. To restate the obvious, standards tell how to write independent subsystems so they interoperate with each other. Your alarm scenario is entirely within one system, so it presents nothing to standardize. If people concretely expect to write MUAs that do something useful with the Downgraded-foo headers, then we might as well publish a document that says what those headers should contain. But it's my impression that the plan is to add them just in case anyone is interested, which strikes me as mildly counterproductive. R's, John From klensin@jck.com Sat May 5 16:36:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AB021F8540 for ; Sat, 5 May 2012 16:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsya+YycPWol for ; Sat, 5 May 2012 16:36:33 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6C21F856A for ; Sat, 5 May 2012 16:36:32 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SQoRV-000D9K-Pw; Sat, 05 May 2012 19:31:13 -0400 Date: Sat, 05 May 2012 19:36:26 -0400 From: John C Klensin To: John R Levine Message-ID: In-Reply-To: References: <20120505194315.6286.qmail@joyce.lan> <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 23:36:33 -0000 --On Saturday, May 05, 2012 17:42 -0400 John R Levine wrote: >> Second, people who implement and deploy these things are >> thoroughly likely to do what they think is right, regardless >> of what the IETF predicts or thinks is good for them. > > Of course. To restate the obvious, standards tell how to > write independent subsystems so they interoperate with each > other. Your alarm scenario is entirely within one system, so > it presents nothing to standardize. To restate the equally obvious, the thing that is important about that scenario is that it represents a case in which no downgrading at all is needed or likely to be useful, making both of our downgrading specs irrelevant. > If people concretely expect to write MUAs that do something > useful with the Downgraded-foo headers, then we might as well > publish a document that says what those headers should > contain. But it's my impression that the plan is to add them > just in case anyone is interested, which strikes me as mildly > counterproductive. Kazunori Fujiwara and his colleagues can (and should) speak for themselves, but I suspect that they already have such MUAs implemented. Certainly they had those MUAs when the experimental specs specified very similar downgrading in transit. It would be quite easy to modify an MUA, and to move the downgrading code from an MTA to a POP/IMAP server, if one had that code already. If I'm correct, there is both running code for the popimap-downgrade case and the Downgraded-foo headers and a community with a long history of routinely dealing with non-ASCII characters who think that approach is desirable. The combination is a lot more than "in case anyone is interested". One can speculate on how many others are likely to support it, but that is more speculation. Independent of that, the main argument for Downgraded-foo, as I've understood it, is not that MUAs will be able to do anything useful with it but that displaying those headers will permit an intelligent and determined user to figure out a lot more about what was going on with the original message than they could do with a more simplistic downgrading model. With most MUAs, such headers would appear only with a "full" header display and I think most normal users almost never look at full header displays (even if they know how to activate them). But one could say that few users ever look at, or know how to access and interpret, trace fields, yet we spend a lot of energy trying to get them right. >From my own experience, I'd expect a typical user to freak out about a downgraded (and un-reply-able) EAI-requiring message appearing in a traditional MUA, regardless of the downgrade model that was used. But, if our Japanese colleagues tell us that either their MUAs or their users --who have many years of experience working in environments use multiple non-European scripts-- are different from what I think of as a typical user, I am quite sure I don't have enough knowledge or experience to tell them that they are wrong. john From ned+ima@mrochek.com Sat May 5 22:05:30 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DED21F84C9 for ; Sat, 5 May 2012 22:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyvNLnhxEaW9 for ; Sat, 5 May 2012 22:05:29 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3B621F84C5 for ; Sat, 5 May 2012 22:05:29 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF50WA2ZZ40016BZ@mauve.mrochek.com> for ima@ietf.org; Sat, 5 May 2012 22:05:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 5 May 2012 22:05:23 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OF50W8LW0Q0006TF@mauve.mrochek.com> Date: Sat, 05 May 2012 21:36:51 -0700 (PDT) In-reply-to: "Your message dated Sat, 05 May 2012 19:43:15 +0000" <20120505194315.6286.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1EBBAA421C87B002A0E1DE44@PST.JCK.COM> <20120505194315.6286.qmail@joyce.lan> To: John Levine Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 05:05:30 -0000 > > That is ultimately the argument in favor of popimap-downgrade over > > simpledowngrade: if it is worth going to the trouble of downgrading > > at all, one might as well exert the extra effort to do it > > comprehensively. > That's the argument, but it's one that I don't find at all persuasive. I don't really find it persuasive either, but not for some the reasons you give. > If a user has a non-EAI MUA, the most a downgrade can realistically do > to create something the MUA can display is what simpledowngrade > describes. Anything beyond that is a quality of implementation issue > that has nothing to do with interoperability. As soon as you rewrite > anything, signatures break, heuristics that look for patterns in the > header lines don't work any more, and it's just a losing battle to try > to make it look like a real non-EAI message. Unfortunately, one of your examples is demonstrably off target while the other actually favors popimap-downgrade. More specifically, as I pointed out in a previous message, AFAICT this supposed "signature breaking" is nothing but a will o' the wisp. Yes, it will break DKIM and DomainKeys, but those aren't intended to be end-to-end mechanisms. (And if they used that way, they encounter a plethora of much more serious problems.) The actual end-to-end signature mechanisms in use are things like PGP or S/MIME. which operate either by using multipart/signed or through embeddings in text parts. Since multipart/signed requires 7bit encoding of content, the issue it has is with EAI proper, not with downgrading. And I fail to see an issue specific to downgrading with text part embedddings either. There may also be issues with EAI when signature schemes use addresses as identifiers in certificates, or when header lines are copied into secure enclosures, but these again have everything to do with EAI and nothing to do with downgrading per se. Tests on headers are another matter, however. This is Sieve territory. Sieve specifies that encoded words in headers should be decoded and converted to utf-8 before tests are performed. There can be issues with this when the charset is unknown but EAI downgrading always produces utf-8 encoded words, which of course decode as an identity transformatin. The net result is Sieve scripts running on a non-EAI client will actually work better on messages transformed by popimap-downgrade and not simpledowngrade, because the former preserves more header fields. And yes, there are any number of nonstandard facilities out there for this sort of thing, e.g., procmail, but as I've said previously, I don't see any obligation to spend time worrying about them. But all this is really beside the point, because the real issue isn't rewriting, it's the likely loss of critical address information. For better or worse, there's no useful way to present an EAI address in a non-EAI client. And that's why I don't think there's a persuasive case to try and support "better" downgrading. > If a message's headers contain EAI addresses, there's no no way a > non-EAI MUA can respond to them directly, so there's nothing to > standardize with addresses beyond ensuring that one can't reply to > them. Exactly, although the issues actually transcend replies. While I completely disagree with Ted's conclusions about the loss of validation anchors, he is absolutely correct in stating that their loss is an unavoidable consequence of downgrading. > I'm not aware of any MUA that would do anything useful with > Downgraded-Something headers, and I believe I am far from alone in > thinking that any work that might be invested in making a MUA use them > would be far better spent making the MUA handle native EAI. Couldn't agree more. There is simply no point in spending a bunch of time implementing complex downgrading schemes and then implementing even more complex upgrading schemes in clients when it's actually easier to simply support EAI in the client. Ned From ned+ima@mrochek.com Sat May 5 22:49:03 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C114E21F84D8 for ; Sat, 5 May 2012 22:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D8u9+6YhyDO for ; Sat, 5 May 2012 22:49:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77521F84D1 for ; Sat, 5 May 2012 22:49:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF52FARTY800176Q@mauve.mrochek.com> for ima@ietf.org; Sat, 5 May 2012 22:49:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 5 May 2012 22:48:57 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OF52F93BB00006TF@mauve.mrochek.com> Date: Sat, 05 May 2012 22:13:36 -0700 (PDT) In-reply-to: "Your message dated Sat, 05 May 2012 17:05:54 -0400" <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120505194315.6286.qmail@joyce.lan> <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> To: John C Klensin Cc: John Levine , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 05:49:03 -0000 > Let me be blunt, with the understanding that I agreed to take on > this WG because there seemed to be general agreement that one of > our major shared goals was to move this work forward > efficiently, much more efficiently than we have been doing > lately. > Unless someone is going to argue strongly that the more complex > popimap-downgrade spec should simply be dropped, which scenarios > you (or others) find persuasive is simply not interesting. You > predict that one scenario will dominate and that certain things > are important and therefore find some approaches unpersuasive. > Others make different predictions and/or assessments of > importance. Starting from a variation on some of Ned's > comments, others of us may have yet a third prediction. Well, as I've stated before, I actually don't find it especially persuasive that either of these documents will see much use in their intended roles. That said, I've never said there is no utility here, and to be honest I'm really not sure in the "whole mailbox permanent downgrade" which approach makes more sense. > No matter how persuasive each of us may find our individual > predictions, there are two important realities. First, we are > all making those predictions without specific experience or data > about this particular type of situation. Second, people who > implement and deploy these things are thoroughly likely to do > what they think is right, regardless of what the IETF predicts > or thinks is good for them. Sure, none of us have any actual deployment experience with EAI, which is part of why I haven't argued in favor of focusing on the whole mailbox downgrade scenario I view as most likely. > Another scenario we haven't discussed at all is among the likely > ones in some situations. That is that the POP or IMAP server > generates an alert or special log entry to what is often called > a "Help Desk" with the user's identity and the fact that a > message that requires EAI capability has landed in the mailbox > so that the Help Desk personnel can do something proactive and > entirely out of band. Really low implementation cost and, for > those environments in which the "Help Desk" can force upgrades, > a very efficient and thoroughly likely one. I'm dubious as to the extent that proactive approaches like this will be used. But there are plenty of environments out there where the choice of client is not under the user's control. Those environments will simply upgrade to an EAI-capable client when the need arises and the users will have no say in the matter. > Similarly, none of our beliefs about how time is best spent are > likely to amount to anything. To generalize from what Ned has > pointed out several times, implementers have audiences > (sometimes called "customers") and are likely to end up doing > what those audiences want, whether we think it is efficient or > not. Well, yes and no. I have no problem believing that user demand for EAI will drive EAI deployment in some, and perhaps many, cases. But in my experience *how* that happens is not going to be under the user's control. > So I continue to suggest that we just do as competent a job as > we can of documenting the protocol alternatives that subsets of > us think are reasonable and then move on, independent of who > those who favor (or predict) one scenario feel about the others. > The alternative, it seems to me, is to try to reach agreement > about those scenarios. All I can say about trying to reach > agreement on one scenario is that it is certain to cost us a lot > of time and that, based on the discussions of the last several > weeks, the odds that many people will be persuaded to change > their positions are really low. Fair point. > Recommendation: Those of us who care about (note that I didn't > say "like") each of the scenarios try to make sure that the > protocols and actions that result are well-thought-out, > well-documented, and, ideally, clear about the scenarios for > which they are optimized. Let's be sure that the base EAI POP > and IMAP documents provide the right references and linkages to > whatever downgrade specs are out there and that they are > otherwise agnostics. And let's save arguments about > persuasiveness or plausibility for some time post-deployment > when we've actually accumulated some serious experience. Seems like a reasonable approach to me, especially since I happen to think the likely deployment scenario may be rather different from what we're envisioning. Ned From Claudio.Allocchio@garr.it Sun May 6 01:07:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187121F84C3 for ; Sun, 6 May 2012 01:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+eTYqvF2+ME for ; Sun, 6 May 2012 01:07:09 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 18A1D21F84A1 for ; Sun, 6 May 2012 01:07:08 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q46874Y9072318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 May 2012 10:07:05 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q46874Y9072318 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=PNB4MU8b8G9oQcgxTiRAJWUiXHU4bYd7yTVbttGkdh59eTTFJiTF1rCDSgwFhci4C 5cKGqD6LnxiUfG+mpmHMIS7U1Ixn8iEkvca3sCurqDitJtc91mDgdmydFRgPNmpv5y8 ImBz8T5B89dnYgEyHt3ofdltp5VMdAVgWRV7LHk= Date: Sun, 6 May 2012 10:07:04 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: ned+ima@mrochek.com In-Reply-To: <01OF52F93BB00006TF@mauve.mrochek.com> Message-ID: References: <20120505194315.6286.qmail@joyce.lan> <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> <01OF52F93BB00006TF@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John Levine , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 08:07:10 -0000 >> Recommendation: Those of us who care about (note that I didn't >> say "like") each of the scenarios try to make sure that the >> protocols and actions that result are well-thought-out, >> well-documented, and, ideally, clear about the scenarios for >> which they are optimized. Let's be sure that the base EAI POP >> and IMAP documents provide the right references and linkages to >> whatever downgrade specs are out there and that they are >> otherwise agnostics. And let's save arguments about >> persuasiveness or plausibility for some time post-deployment >> when we've actually accumulated some serious experience. > > Seems like a reasonable approach to me, especially since I happen to > think the likely deployment scenario may be rather different from what > we're envisioning. with just my WG member hat on (and the ancient one of implmemeter and provider of gateway services - a very similar scenario to downgrading) I can only FULLY support this reccomendation and approach! Very strange deployment we cannot even think of in our way to see the world can happen, also driven by users/groups which believes that the correct way to send a personal message to somebody is to post it on a social network messages board ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From arnt@gulbrandsen.priv.no Sun May 6 01:10:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9A21F84A1 for ; Sun, 6 May 2012 01:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs3ORjZfo8j3 for ; Sun, 6 May 2012 01:10:01 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8BA21F847E for ; Sun, 6 May 2012 01:10:01 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 190D6FA0818; Sun, 6 May 2012 08:09:59 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1336291798-16727-16726/11/2; Sun, 6 May 2012 08:09:58 +0000 Message-Id: <4FA631ED.5020401@gulbrandsen.priv.no> Date: Sun, 6 May 2012 10:10:21 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <20120505194315.6286.qmail@joyce.lan> <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 08:10:02 -0000 On 05/06/2012 01:36 AM, John C Klensin wrote: > Kazunori Fujiwara and his colleagues can (and should) speak for > themselves, but I suspect that they already have such MUAs > implemented. Certainly they had those MUAs when the > experimental specs specified very similar downgrading in > transit. This makes sense. A great deal of sense. > It would be quite easy to modify an MUA, and to move > the downgrading code from an MTA to a POP/IMAP server, if one > had that code already. The conditions and O() expectations differ. In one case, the code is expected to store and forward a single message. In the other, it's expected to open up to around 10-20k messages, sometimes with read-only access. Creating Downgraded-Cc is easy if you store and forward. Less so if you have read-only write access to the mailbox and the client expects you to do it for 10k messages, fast. UID FETCH 1:* (RFC822.SIZE FLAGS) for instance. Servers commonly have to do that for datasets which won't fit in available RAM. BTW, I don't think popimap-downgrade discusses what happens if a mischievous sender already adds downgraded-* fields? Arnt From johnl@iecc.com Sun May 6 07:43:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D24521F84FB for ; Sun, 6 May 2012 07:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.806 X-Spam-Level: X-Spam-Status: No, score=-110.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_55=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4ChoplpPqTS for ; Sun, 6 May 2012 07:43:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAC321F8493 for ; Sun, 6 May 2012 07:43:26 -0700 (PDT) Received: (qmail 47644 invoked from network); 6 May 2012 14:43:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 May 2012 14:43:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa68e06.xn--yuvv84g.k1205; i=johnl@user.iecc.com; bh=Ex+3LIitgMundJnAEnqmKTZlbCoA4pTvzgOa0gBlZN0=; b=GrhtEWYL2r9x2Mf+bWIB6Si5kfS8tAa0F+Rz+AQhW2mpoeSm78CD3EJhyjT4kxiGctGbuq8V2XGJjXW5SnNR1SkYRrdJovb9MqKZ3R7hgrB0Wb9SOwz2bXczIePmSWUtl/btI6b+jbCq7kAUhm9NmIBFG3A3slHvct/HQcxfrkk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa68e06.xn--yuvv84g.k1205; olt=johnl@user.iecc.com; bh=Ex+3LIitgMundJnAEnqmKTZlbCoA4pTvzgOa0gBlZN0=; b=4ESmRFeqXNdtw4iYpKx9AoFEPS9eWJtUoGee1wwIRrbEhMy7owt6efArAzuRcIUawQ17WULs/fjrRCExSqIBGyOh9ARPCnffI3tTszqNzI5dj0s2phuv+2+Sn3QMl6USzCwBTyM3ZkM5/L1u5vV8mqc9vfsV0boFOSF5G74AEDQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 May 2012 14:42:55 -0000 Message-ID: <20120506144255.71243.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Downgrade this, was Status summary X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 14:43:28 -0000 > Second, people who implement and deploy these things are thoroughly > likely to do what they think is right, regardless of what the IETF > predicts or thinks is good for them. You're doubtless correct, but now I'm totally confused. I think I'm seeing the suggestion that we provide a range of downgrade options, none of which can interoperate, and implementers will implement one of them or maybe do something totally different. What's the benefit of putting anything in a standard beyond the advice that a downgrade has to get rid of non-ASCII text and not introduce addresses that could be replied to by mistake? As a straw man, here's another unimplemented downgrade strategy. We all seem to agree that it would be a good thing for users to see the addresses of their correspondents. Let's say the message has these headers, with the capitalized strings standing for UTF-8. From: acomment To: bcomment Cc: ccomment The downgraded message headers are rewritten to these: From: ABDUL@AA acomment To: BIBI@BB bcomment Cc: CHEN@CC ccomment Since comment text can be MIME encoded, the user can now see the original addresses. The p1, p2, and p3 addresses are indexes into a database shared between the MDA and MSA; the addresses in the comment fields are just comments. When the user responds to this message, the MSA recognizes the proxy.local addresses, looks them up in the database, and replaces them with the EAI addresses. It might tidy up the comments to remove extra copies of the EAI addresses, but that's a quality of implementation issue. For the rest of the headers and MIME part headers, you do something, whatever one of the existing proposals does. There are all sorts of ways this could fail, e.g., a user sends mail through another MSA, but I will wave my hands and say that my users don't do that, or if they do, they get what they deserve. If we're going to list possible downgrade strategies, why stop at the two in the existing I-D's? Should we publish some like this? Why or why not? R's, John From ned+ima@mrochek.com Sun May 6 08:00:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A627021F84D9 for ; Sun, 6 May 2012 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNeDbl9UiSFi for ; Sun, 6 May 2012 08:00:25 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF3F21F84D6 for ; Sun, 6 May 2012 08:00:25 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF5LNXTJLS0015U2@mauve.mrochek.com> for ima@ietf.org; Sun, 6 May 2012 08:00:23 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 6 May 2012 08:00:20 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OF5LNWFBA20006TF@mauve.mrochek.com> Date: Sun, 06 May 2012 07:50:28 -0700 (PDT) In-reply-to: "Your message dated Sun, 06 May 2012 14:42:55 +0000" <20120506144255.71243.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> <20120506144255.71243.qmail@joyce.lan> To: John Levine Cc: ima@ietf.org Subject: Re: [EAI] Downgrade this, was Status summary X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 15:00:25 -0000 > > Second, people who implement and deploy these things are thoroughly > > likely to do what they think is right, regardless of what the IETF > > predicts or thinks is good for them. > You're doubtless correct, but now I'm totally confused. I think I'm > seeing the suggestion that we provide a range of downgrade options, > none of which can interoperate, and implementers will implement one of > them or maybe do something totally different. What's the benefit of > putting anything in a standard beyond the advice that a downgrade has > to get rid of non-ASCII text and not introduce addresses that could be > replied to by mistake? There are some who are arguing that all of this needs to be marked as informational, not standards-track. One of the possible, and even likely, outcomes of that is that implementors will feel *no* need to implement things in a consistent fashion. So not being on the standards track could reduce the availability of validation anchors even more than it needs to be. Regardless, I see your point that documenting multiple approaches has its own issues, almost independnent of what those approaches are. > As a straw man, here's another unimplemented downgrade strategy. > We all seem to agree that it would be a good thing for users to see > the addresses of their correspondents. Let's say the message has > these headers, with the capitalized strings standing for UTF-8. > From: acomment > To: bcomment > Cc: ccomment > The downgraded message headers are rewritten to these: > From: ABDUL@AA acomment > To: BIBI@BB bcomment > Cc: CHEN@CC ccomment > Since comment text can be MIME encoded, the user can now see the > original addresses. The p1, p2, and p3 addresses are indexes into a > database shared between the MDA and MSA; the addresses in the comment > fields are just comments. When the user responds to this message, the > MSA recognizes the proxy.local addresses, looks them up in the > database, and replaces them with the EAI addresses. It might tidy up > the comments to remove extra copies of the EAI addresses, but that's a > quality of implementation issue. For the rest of the headers and MIME > part headers, you do something, whatever one of the existing proposals > does. Very clever. I note that some MUAs *only* show the associated phrase text, with the result that there are already cases where addresses are duplicated into the phrase text so that users can see the actual address. This could be seen as expanding on that. > There are all sorts of ways this could fail, e.g., a user sends mail > through another MSA, but I will wave my hands and say that my users > don't do that, or if they do, they get what they deserve. Yes, least astonishment principle violations seem pretty likely in such a setup, especially given how users take their laptops on th road... Ned From klensin@jck.com Sun May 6 11:09:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F3221F847E for ; Sun, 6 May 2012 11:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffxsZV4D+zfm for ; Sun, 6 May 2012 11:09:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98A21F844F for ; Sun, 6 May 2012 11:09:15 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SR5oI-000Ebs-NA; Sun, 06 May 2012 14:03:54 -0400 Date: Sun, 06 May 2012 14:09:08 -0400 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <14723F3F9D85E853328E0115@PST.JCK.COM> In-Reply-To: <20120506144255.71243.qmail@joyce.lan> References: <20120506144255.71243.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Downgrade this, was Status summary X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:09:16 -0000 --On Sunday, May 06, 2012 14:42 +0000 John Levine wrote: >> Second, people who implement and deploy these things are >> thoroughly likely to do what they think is right, regardless >> of what the IETF predicts or thinks is good for them. > > You're doubtless correct, but now I'm totally confused. I > think I'm seeing the suggestion that we provide a range of > downgrade options, none of which can interoperate, and > implementers will implement one of them or maybe do something > totally different. What's the benefit of putting anything in > a standard beyond the advice that a downgrade has to get rid > of non-ASCII text and not introduce addresses that could be > replied to by mistake? See Ned's note. > As a straw man, here's another unimplemented downgrade > strategy. > > We all seem to agree that it would be a good thing for users > to see the addresses of their correspondents. Let's say the > message has these headers, with the capitalized strings > standing for UTF-8. > > From: acomment > To: bcomment > Cc: ccomment > > The downgraded message headers are rewritten to these: > > From: ABDUL@AA acomment > To: BIBI@BB bcomment > Cc: CHEN@CC ccomment > > Since comment text can be MIME encoded, the user can now see > the original addresses. The p1, p2, and p3 addresses are > indexes into a database shared between the MDA and MSA; the > addresses in the comment fields are just comments. When the > user responds to this message, the MSA recognizes the > proxy.local addresses, looks them up in the database, and > replaces them with the EAI addresses. It might tidy up the > comments to remove extra copies of the EAI addresses, but > that's a quality of implementation issue. For the rest of the > headers and MIME part headers, you do something, whatever one > of the existing proposals does. > > There are all sorts of ways this could fail, e.g., a user > sends mail through another MSA, but I will wave my hands and > say that my users don't do that, or if they do, they get what > they deserve. Variations on this theme in which elements of the delivery system tried to supply the MSA with specific information was considered very early in the WG's life and again when we first started discussing Submission server downgrading. It was rejected then, but nothing prevents you from bringing it up again. > If we're going to list possible downgrade strategies, why stop > at the two in the existing I-D's? Should we publish some like > this? Why or why not? I think it is clear that we could generate a number of different proposals if we were so inclined, each with different assumptions about implementation strategies, deployment strategies, interactions among client systems and POP/IMAP servers, delivery MTAs, storage and submission servers, and/or user behavior. Speaking as a co-chair with a perceived mandate to get this work wrapped up, pushing for documenting more (standards track or not) different approaches as a prerequisite for completing the existing four documents would be an excellent strategy for very long delays. I'm sure you don't intend that, but unless the WG has consensus that such delays are appropriate, I feel a need to push back against any more proposals. An alternative would be to put text into the the POP and IMAP specs indicating that downgrading is an issue and that there are several proposals around which might be published in the future. We could then publish those two documents, shut down the WG, and leave everything else to the tender mercies of individual submissions. My guess is that approach would not be popular with those who think the current two proposals are fairly well developed and likely to get traction in the community, but I'm happy to do whatever the WG likes as long as it doesn't involve another year or more of delays (unless the WG clearly agrees to that). I suggest we put the question of whether we are in a hurry or not on the agenda of the Jabber chat and then issue a consensus call. If you are serious about this proposal, I suggest you generate an I-D so that we can put the question of whether the WG wants to consider and cope with it on the Jabber chat agenda as well. john From Claudio.Allocchio@garr.it Sun May 6 13:56:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92DD21F8470 for ; Sun, 6 May 2012 13:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Icmdr4iQje51 for ; Sun, 6 May 2012 13:56:16 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28821F845C for ; Sun, 6 May 2012 13:56:09 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q46Ku5CY091429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 May 2012 22:56:06 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q46Ku5CY091429 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=r1lRN3/QxfYQ10PpkGZZyj26ch3V+6g7LuZJ1UBXaIQ0eTfYSlpGjp/YW7qD2baxW dlu/l9zireIjUOGSLaOnL10RLo1qFiCoq5Ilw+WGQi9CwPwPix++F5T+muSEPEg4y0F x3qTIHwo8c8pAlLe9QCUbWGrJrcylRFabBQGYVU= Date: Sun, 6 May 2012 22:56:05 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: John C Klensin In-Reply-To: <14723F3F9D85E853328E0115@PST.JCK.COM> Message-ID: References: <20120506144255.71243.qmail@joyce.lan> <14723F3F9D85E853328E0115@PST.JCK.COM> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John Levine , ima@ietf.org Subject: Re: [EAI] Downgrade this, was Status summary X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 20:56:17 -0000 > There are all sorts of ways this could fail, e.g., a user > sends mail through another MSA, but I will wave my hands and > say that my users don't do that, or if they do, they get what > they deserve. There are good reasons to be very careful in promoting some field to a different scope in order to supply missing or useful information to act on inside a message header or evelope if the used filed is unstructured, and vaguely specified in scope. A true story to explain it: in the '70s, the IBM MVS "SMTPNOTE" mail system (a quite primitive batch mail system) looked like //SENDNOTE EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT2 DD SYSOUT=(B,SMTP) //SYSUT1 DD * HELO MVSHOST MAIL FROM: RCPT TO: DATA From: "some comment here" To: "some comment here" Subject: Test message from MVS using SMTP This is a line in the body of the note. . QUIT The first attempt to build a gateway between early RFC821/822 and MVS used the "some comment here" filed to convey informaton to be used by the gateways... a pity that the chosen fields (something like <*informatiohere>) was interpreted by MVS JCL as a set of undocumented but existing instructions, and the SMTPNOTE job had to run in EXEC mode (e.g. superuser). The System/390 mainframe of Geneva CERN IT division crashed and all jobs and data in the batch queues were lost. 5 minutes later I had on the phone a quite angry IT division director (and later IETF chair), Brian Carpenter. > Speaking as a co-chair with a perceived mandate to get this work > wrapped up, pushing for documenting more (standards track or > not) different approaches as a prerequisite for completing the > existing four documents would be an excellent strategy for very > long delays. I'm sure you don't intend that, but unless the WG > has consensus that such delays are appropriate, I feel a need to > push back against any more proposals. An alternative would be > to put text into the the POP and IMAP specs indicating that > downgrading is an issue and that there are several proposals > around which might be published in the future. We could then > publish those two documents, shut down the WG, and leave > everything else to the tender mercies of individual submissions. > My guess is that approach would not be popular with those who > think the current two proposals are fairly well developed and > likely to get traction in the community, but I'm happy to do > whatever the WG likes as long as it doesn't involve another year > or more of delays (unless the WG clearly agrees to that). Now that hopefully I do not crash any more mainframes, I'm not in favour of leaving open to any (even good) alternate ideas the already slippery path of "downgrading". It's just MHO, of course... my cents, but let's stay with the current 2 proposals, and see what will be implemented out there. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From johnl@taugh.com Sun May 6 14:30:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F7821F8554 for ; Sun, 6 May 2012 14:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vq2R3H8N8Xg for ; Sun, 6 May 2012 14:30:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 13BFD21F854C for ; Sun, 6 May 2012 14:30:49 -0700 (PDT) Received: (qmail 24031 invoked from network); 6 May 2012 21:30:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=5ddd.4fa6ed88.k1205; bh=o2g9K41mJLb0GZsSenX88sG8orExfAyCWfb/45q7Z20=; b=gEGKBk5hbAUS8ZyNjd/5SYDYp9qrq68/geWEedVlwJpMFcok3CWwvWSssTKPELwApCZqIujiEXBmXIy8LSlzZzi69/xNuwAZn6rQYNshUILfgsBTaWC7fKZek7/G+cOJCavj+mhR+r8vXSQ3dXfFYphaPIEK5Vpsc6hL0oVIBvA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=5ddd.4fa6ed88.k1205; bh=o2g9K41mJLb0GZsSenX88sG8orExfAyCWfb/45q7Z20=; b=wLigTX5UScGIcpu5q9QCC2+ZO1/zrdvvEKYsAEG/mHcJKLxPfDa2H2HM8jPsoyW8HvC1daIqLyzfrh3x1kmQTIi70M+0MmOYUDlc6u2ccC2dCznOKQXM9SqHFaBsG11R4Ea3Scep8yxtq1/yAyMJHt6A40SXerC9rQyXXV60N7k= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 6 May 2012 21:30:26 -0000 Date: 6 May 2012 17:30:48 -0400 Message-ID: From: "John R Levine" To: "Claudio Allocchio" In-Reply-To: References: <20120506144255.71243.qmail@joyce.lan> <14723F3F9D85E853328E0115@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Downgrade this, was Status summary X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 21:30:50 -0000 > There are good reasons to be very careful in promoting some field to a > different scope in order to supply missing or useful information to act on > inside a message header or evelope if the used filed is unstructured, and > vaguely specified in scope. I agree. I did say I didn't think we should publish my hack. But it seems to me that anything beyond simpledowngrade runs a similar risk. > Now that hopefully I do not crash any more mainframes, I'm not in favour of > leaving open to any (even good) alternate ideas the already slippery path of > "downgrading". It's just MHO, of course... my cents, but let's stay with the > current 2 proposals, and see what will be implemented out there. I'm not thrilled about them, but I suppose that if we publish them as informational they'd be mostly harmless. R's, John From klensin@jck.com Sun May 6 16:22:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ACA21F8567 for ; Sun, 6 May 2012 16:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiCYU8FR2loe for ; Sun, 6 May 2012 16:22:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4016B21F8512 for ; Sun, 6 May 2012 16:22:26 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SRAhL-000Euk-FM; Sun, 06 May 2012 19:17:03 -0400 Date: Sun, 06 May 2012 19:22:17 -0400 From: John C Klensin To: Claudio Allocchio Message-ID: <0875095DE2BC1647BB3F5FAE@PST.JCK.COM> In-Reply-To: References: <20120506144255.71243.qmail@joyce.lan> <14723F3F9D85E853328E0115@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: John Levine , ima@ietf.org Subject: Re: [EAI] Downgrade this, was Status summary X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 23:22:33 -0000 --On Sunday, May 06, 2012 22:56 +0200 Claudio Allocchio wrote: > >> There are all sorts of ways this could fail, e.g., a user >> sends mail through another MSA, but I will wave my hands and >> say that my users don't do that, or if they do, they get what >> they deserve. > > There are good reasons to be very careful in promoting some > field to a different scope in order to supply missing or > useful information to act on inside a message header or > evelope if the used filed is unstructured, and vaguely > specified in scope. Yes. And that is one of the advantages of the "separate header fields" architecture of popimap-downgrade in comparison to trick encoding and embedding hacks of various sorts. Of course there are disadvantages as well but, since we've been telling mail implementers for many years to ignore (or purge) header fields they don't recognize, the odds of unintended consequences are vastly reduced. > A true story to explain it: > > in the '70s, the IBM MVS "SMTPNOTE" mail system (a quite > primitive batch mail system) looked like >... Yeah. We did a bit better with VM/CMS version of that problem, largely because we didn't try to integrate code going to or from the Internet gateway with the (almost non-existent) operating system mail facility. I think that was rather more good fortune than any particular insight on our part, but the issues with trying to encode information in places that other software might misunderstand were pretty clear. >... > Now that hopefully I do not crash any more mainframes, I'm not > in favour of leaving open to any (even good) alternate ideas > the already slippery path of "downgrading". It's just MHO, of > course... my cents, but let's stay with the current 2 > proposals, and see what will be implemented out there. Speaking personally rather than as co-chair, I agree. john From fujiwara@jprs.co.jp Sun May 6 22:18:03 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B772421F8493 for ; Sun, 6 May 2012 22:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZticuoOySSzA for ; Sun, 6 May 2012 22:18:03 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2EA21F848B for ; Sun, 6 May 2012 22:17:58 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q475HmEZ023622; Mon, 7 May 2012 14:17:54 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-0e-4fa75b01841f Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 29.FA.03276.10B57AF4; Mon, 7 May 2012 14:17:53 +0900 (JST) Date: Mon, 07 May 2012 14:17:53 +0900 (JST) Message-Id: <20120507.141753.27786252.fujiwara@jprs.co.jp> To: klensin@jck.com From: fujiwara@jprs.co.jp In-Reply-To: References: <4EB1DBB4A7F380D6DD286D25@PST.JCK.COM> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsWyRoiFT5cxerm/weJ7ZhbXl65jtzjds4bJ ov1KA7sDs8eSJT+ZPC6vfM3scW9LaABzFJdNSmpOZllqkb5dAldGx+V7bAWHeStOvnzL2sD4 g6uLkZNDQsBEYm3PWXYIW0ziwr31bF2MXBxCAicZJaYt2cACkmAR0JbYu76JsYuRg4NXwEri zQ8HkLCIgLBE29KDYGFmAUWJa7MCQMLCQCOPPnnGCGKzCUhKbP7cygxicwoYS0x+0MICMb6H UaLpaD8zxF47iRPPV7BCjBeU+LtDGCTMLKAl0TPjMTuELS+x/e0c5gmM/LMQqmYhqZqFpGoB I/MqRpn8tDTd4tS8lOLcdANDvZLKfL2sgqJivWQQvYkRHJgcCjsYZ5wyOMQowMGoxMPbK77c X4g1say4MvcQoyQHk5Io7/dQoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3va+Zf5CvCmJlVWp RfkwKWkOFiVx3uNnd/gJCaQnlqRmp6YWpBbBZGU4OJQkeC2jgIYKFqWmp1akZeaUIKSZODhB hvMADX8dCVTDW1yQmFucmQ6RP8WoyjFvytarjEIsefl5qVLivPNBigRAijJK8+DmvGIUB3pH mHcLSJYHmHzgJrwCGs4ENHzzM5DLi0sSEVJSDYzZL51kzJ38D8v6rpsf9P1KhueMRw/X3Iz5 N+PNlr9NblzBXM8uC9Ys/jdt1qUd3+9yH7wlzmgqyPH9S+i7kgz7sGiXGEX1ht22V08LcAg1 nRHYJ5GcLK50m3nFwWjX+EmVJpJPGb5b71b+LdAWe5tt7edDrysliywbC10WxPRI/HyV5a1X ZqLEUpyRaKjFXFScCADpBvtE+wIAAA== Cc: johnl@taugh.com, ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 05:18:03 -0000 > From: John C Klensin >> If people concretely expect to write MUAs that do something >> useful with the Downgraded-foo headers, then we might as well >> publish a document that says what those headers should >> contain. But it's my impression that the plan is to add them >> just in case anyone is interested, which strikes me as mildly >> counterproductive. > > Kazunori Fujiwara and his colleagues can (and should) speak for > themselves, but I suspect that they already have such MUAs > implemented. Certainly they had those MUAs when the > experimental specs specified very similar downgrading in > transit. It would be quite easy to modify an MUA, and to move > the downgrading code from an MTA to a POP/IMAP server, if one > had that code already. If I'm correct, there is both running > code for the popimap-downgrade case and the Downgraded-foo > headers and a community with a long history of routinely dealing > with non-ASCII characters who think that approach is desirable. > The combination is a lot more than "in case anyone is > interested". One can speculate on how many others are likely to > support it, but that is more speculation. I read the message now because of Japanesde holiday week. In-transit-downgrading worked at the experimental spec and implementing new MUA that understands Downgraded-* header fields may be easy. But, In my opinion, it is better to implement and deploy EAI capable MUAs rather than to implement MUAs which understand popimap downgraded messages. The popimap downgrade should be used to inform that the receiver received EAI messages and should update his/her MUA. -- Kazunori Fujiwara, JPRS From fujiwara@jprs.co.jp Sun May 6 22:50:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DDA21F84CF for ; Sun, 6 May 2012 22:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D16vrnT+jnbz for ; Sun, 6 May 2012 22:50:06 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id B51F621F84C8 for ; Sun, 6 May 2012 22:50:05 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q475o0Am025690; Mon, 7 May 2012 14:50:00 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-91-4fa762880a41 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 50.3B.03276.88267AF4; Mon, 7 May 2012 14:50:00 +0900 (JST) Date: Mon, 07 May 2012 14:50:00 +0900 (JST) Message-Id: <20120507.145000.191383992.fujiwara@jprs.co.jp> To: arnt@gulbrandsen.priv.no From: fujiwara@jprs.co.jp In-Reply-To: <4FA631ED.5020401@gulbrandsen.priv.no> References: <4FA631ED.5020401@gulbrandsen.priv.no> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsWyRoiFT7cjabm/weS/khbdDw6xWVxfuo7d gcljz7/VzB5LlvxkCmCK4rJJSc3JLEst0rdL4MroXX+PqaCdvWLW9OvMDYzXWLsYOTkkBEwk +j++ZoGwxSQu3FvP1sXIxSEkcJJRYtPdXrAEi4C2RPuzvWA2r4C1xOtDN5hBbBEBGYmFv3Yz gtjMAgISJy/NA7OFgYYeffIMzGYTkJTY/LkVrJ5TwFji5fVFLBALehglWrdvZIbYbCdx4vkK oIs4gBYISvzdIQwxU0uiZ8ZjdghbXmL72znMExj5ZyFUzUJSNQtJ1QJG5lWMMvlpabrFqXkp xbnpBoZ6JZX5elkFRcV6ySB6EyM4FDkUdjDOOGVwiFGAg1GJh7dXfLm/EGtiWXFl7iFGSQ4m JVHeqkSgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe9r5l/kK8KYmVValF+TApaQ4WJXHe42d3 +AkJpCeWpGanphakFsFkZTg4lCR4d4MMFSxKTU+tSMvMKUFIM3FwggznARr+DKSGt7ggMbc4 Mx0if4pRUkqc9xxIQgAkkVGaB9f7ilEc6AVh3nUgWR5gWoHregU0kAlo4OZnINcWlyQipKQa GGM9WLIZ3Paq/NmzT2o7z5nuvAla5bLsUqf1mBav4XginzujyFJbfUZzurpvlrrEzCv6EQt3 rn3VcPDe/7C1ThL9z6YJ3EhxnPFm7f7da0M3nRSua7tSscP/+b4zroXaAXmh7XzTec67TtNd vEC7N77rdOQs6Sag0/LKoqYwLbK4nJ7Ka8KmxFKckWioxVxUnAgAWq5ujegCAAA= Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 05:50:06 -0000 > From: Arnt Gulbrandsen > BTW, I don't think popimap-downgrade discusses what happens if a > mischievous sender already adds downgraded-* fields? "message/global" messages should not contain "Downgraded-*" header fields. If an message contains both non-ASCII header value and Downgraded-* header fields, the message is broken. A senario which show the broken case: - a user uses fetchmail and procmail to retreive messages from pop servers - and forward them to non-ASCII e-mail address. - where fetchmail does not know UTF8 capability -> The forwarded message contains both - Downgraded header fields - non-ASCII header fields (Received, Return-Path, Delivered-To, ...) which came from non-ASCII RCPT TO in SMTP. Otherwise, the broken case came from malicious entities. -- Kazunori Fujiwara, JPRS From arnt@gulbrandsen.priv.no Sun May 6 23:45:11 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCC021F84D3 for ; Sun, 6 May 2012 23:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDkHJVTOiq2y for ; Sun, 6 May 2012 23:45:10 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6D30021F84C8 for ; Sun, 6 May 2012 23:45:10 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4D8C5FA0944; Mon, 7 May 2012 06:45:08 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1336373107-30649-30648/11/3; Mon, 7 May 2012 06:45:07 +0000 Message-Id: <4FA76F8D.7000101@gulbrandsen.priv.no> Date: Mon, 7 May 2012 08:45:33 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: fujiwara@jprs.co.jp References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> In-Reply-To: <20120507.145000.191383992.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 06:45:11 -0000 On 05/07/2012 07:50 AM, fujiwara@jprs.co.jp wrote: > If an message contains both non-ASCII header value and Downgraded-* > header fields, the message is broken. Yes. But what should happen? Should the message be stripped of its wrongness at delivery time? In that case popimap-downgrade cannot apply to mail stored before it was deployed, or an time-consuming migration is required to deploy it. Should the message be edited on disk when popimap-downgrade sees it? In that case popimap-downgrade can only be deployed for mailboxes to which the server has write access. Further, if that's done for IMAP, the document needs to specify that the server issue a new UIDVALIDITY. The third alternative is to keep th message in RAM and discard it at the end of the mailbox session. But in that case even frequent and until now cheap operations like UID FETCH 1:* RFC822.SIZE become expensive. Arnt From fujiwara@jprs.co.jp Mon May 7 04:18:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687221F848F for ; Mon, 7 May 2012 04:18:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMUkZBmENnpW for ; Mon, 7 May 2012 04:17:59 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 348F321F83EF for ; Mon, 7 May 2012 04:17:58 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q47BHqBx011564; Mon, 7 May 2012 20:17:52 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-c8-4fa7af60d139 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 9D.EC.03276.06FA7AF4; Mon, 7 May 2012 20:17:52 +0900 (JST) Date: Mon, 07 May 2012 20:17:52 +0900 (JST) Message-Id: <20120507.201752.52172531.fujiwara@jprs.co.jp> To: arnt@gulbrandsen.priv.no From: fujiwara@jprs.co.jp In-Reply-To: <4FA76F8D.7000101@gulbrandsen.priv.no> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsWyRoiFTzdh/XJ/g/7zehbdDw6xWVxfuo7d gcljz7/VzB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYfWwaW0ELX8X+gxuYGhgXcncxcnJICJhI PPy1nB3CFpO4cG89G4gtJHCSUeLoUx0Qm0VAW+Lhki5mEJtXwEriwJMzrCC2iICMxMJfuxlB bGYBAYmTl+aB2cJAM48+eQZmswlISmz+3ArWyylgLDFzyT6WLkYuoPm9jBInDt9ghlhsJ3Hi +QqgoRxACwQl/u4QhpipJdEz4zE7hC0vsf3tHOYJjPyzEKpmIamahaRqASPzKkaZ/LQ03eLU vJTi3HQDQ72Syny9rIKiYr1kEL2JERyIHAo7GGecMjjEKMDBqMTD2yu+3F+INbGsuDL3EKMk B5OSKO+DJUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxLk4ByvCmJlVWpRfkwKWkOFiVx3uNn d/gJCaQnlqRmp6YWpBbBZGU4OJQkeKetBWoULEpNT61Iy8wpQUgzcXCCDOcBGl4DUsNbXJCY W5yZDpE/xSgpJc57HiQhAJLIKM2D633FKA70gjDvQZAsDzCpwHW9AhrIBDRw87NlIANLEhFS Ug2MTqknwgsUO+7M/MHRxbHVO2rPtYPPDlb6fq8uP859t6XvnlJAeWqaVfDzfhPHFRFJ0y6a H+c9Y7axL9nEQNJY6mDCG/WWUp+zVcH5yTJO6kcLn4T83GK15H7C3fdTZsx7Fjjrj6LWv3yh uuCtM/O2Lugy0f9wOs96i42ixpqPLt+slq1sXO2txFKckWioxVxUnAgAyMamX+cCAAA= Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 11:18:00 -0000 > From: Arnt Gulbrandsen >> If an message contains both non-ASCII header value and Downgraded-* >> header fields, the message is broken. > > Yes. But what should happen? > > Should the message be stripped of its wrongness at delivery time? It is out of scope of pop/imap. Bogus messages are delivered to pop/imap mailboxes as is. > In > that case popimap-downgrade cannot apply to mail stored before it was > deployed, or an time-consuming migration is required to deploy it. POP server or IMAP server shuold not change messages when a client support UTF8 capability. It is out of scope of pop/imap downgrading. > Should the message be edited on disk when popimap-downgrade sees it? A user may use multiple POP/IMAP clients. Some clients may support UTF8 capability, and others may not support UTF8 capability. Then, the POP/IMAP server must keep the messages as is. And the server may have downgraded version additonally (as a cache). > In > that case popimap-downgrade can only be deployed for mailboxes to which > the server has write access. Further, if that's done for IMAP, the > document needs to specify that the server issue a new UIDVALIDITY. The UIDVALIDITY value should be calculated by the original message. Is the UIDVALIDITY for the original message same as the UIDVALIDITY for the downgraded message ? > The third alternative is to keep th message in RAM and discard it at the > end of the mailbox session. But in that case even frequent and until now > cheap operations like UID FETCH 1:* RFC822.SIZE become expensive. You can keep the message in the disk cache. The downgrading occurs when the first lookup from non-UTF8 clients. Is it OK? -- Kazunori Fujiwara, JPRS From johnl@iecc.com Mon May 7 05:36:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2D521F84B9 for ; Mon, 7 May 2012 05:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.1 X-Spam-Level: X-Spam-Status: No, score=-111.1 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvJpvmSqBGO5 for ; Mon, 7 May 2012 05:36:06 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 55AC321F84B5 for ; Mon, 7 May 2012 05:36:05 -0700 (PDT) Received: (qmail 53271 invoked from network); 7 May 2012 12:36:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 May 2012 12:36:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa7c1b4.xn--i8sz2z.k1205; i=johnl@user.iecc.com; bh=iCHNIalNjrnSJPy8BWLfZ85fPjcm83sm8dmtb1HfrwY=; b=gB2tQjm0VqsozYmEkwK0QmfgGHH+2lokAiDoVYTjCq9/JuTSKMlWsDdy5DMbHLxlcUWzHvQEDy9WUG8jKHG9FF6ehBjwJpxivb5YMZSIq0nckZnXTpnKeDUjHAClWH+52Wnu6TaMeWyrutC1c38Kd7xjt0Q+dd2l8VLJp/TmWCg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fa7c1b4.xn--i8sz2z.k1205; olt=johnl@user.iecc.com; bh=iCHNIalNjrnSJPy8BWLfZ85fPjcm83sm8dmtb1HfrwY=; b=L09TZ0WRNt/frlhnfs7B0V0dZtTJ+zdrhMgGrFeK4e5FVuAoDCtXA6r3xlFGhQL76N9j5mleeZ3hAPPS4FrWgp0DBUZcq5cO0PgqsSJi53Q/gxIipAgmaAJvLQR8MfJC8KVm5vp9fSKOOUfrPg6EJVmU7Ks1uhF8d9h43HKkOIs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 May 2012 12:35:41 -0000 Message-ID: <20120507123541.43482.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4FA76F8D.7000101@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: arnt@gulbrandsen.priv.no Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 12:36:07 -0000 >The third alternative is to keep th message in RAM and discard it at the >end of the mailbox session. But in that case even frequent and until now >cheap operations like UID FETCH 1:* RFC822.SIZE become expensive. I would think that if your downgrade were something like simpledowngrade you could downgrade on the fly, as the message passes from the message store through the POP or IMAP server and out to the client. As far as I can tell it doesn't depend on any interactions between headers, so you can do it one line or header at a time. R's, John From jyee@afilias.info Fri May 11 12:59:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BEC21F867E for ; Fri, 11 May 2012 12:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Status: No, score=-4.342 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3fcNJdtePtu for ; Fri, 11 May 2012 12:59:01 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0346921F86C3 for ; Fri, 11 May 2012 12:59: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 1SSvzQ-0003uZ-3U for ima@ietf.org; Fri, 11 May 2012 19:59:00 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SSvzP-0003RM-9D for ima@ietf.org; Fri, 11 May 2012 19:58:59 +0000 Received: by vbal1 with SMTP id l1so1556796vba.9 for ; Fri, 11 May 2012 12:58:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=qZxILgF3xYLYkveT8aTIGSwHesUqBoiG+dMw7cBI70c=; b=XViljyI1WbAU/nKLf/y/nrDTM1ERmHnoVCouEHdWoQCWb+tFNAWbmXxLNZkGT7yCOV xx/P8Y0n/OkzdfYXiOy3HqDe5FZQU23KDETapd8eAl/abi25DmFEXy8ZOgsGRU1BVknJ 7Xr2GNUmf3d/ECNI4nGfqoyteHmNQTUr2klmrb8eiCBSrw4yXmlRLZzhxB7r+WtA4pP5 78MqQEtOKbELUSaTOD1Aw1Won5O0uUu/RepEHFmFllWaSrgYuNbhU0bn6RZwX/GL81FT VwZiLLMCP7mukBUBtqz5DjO21D3xhgD8D+4NLE+PfPKxtzfmep/zSoKzhF6koYR25Dw7 ih5Q== MIME-Version: 1.0 Received: by 10.52.34.165 with SMTP id a5mr1546066vdj.79.1336766339314; Fri, 11 May 2012 12:58:59 -0700 (PDT) Received: by 10.52.22.133 with HTTP; Fri, 11 May 2012 12:58:59 -0700 (PDT) In-Reply-To: <68B7634B-A946-4F53-83E4-AD5E76E4486E@afilias.info> References: <20120427203650.29585.45699.idtracker@ietfa.amsl.com> <68B7634B-A946-4F53-83E4-AD5E76E4486E@afilias.info> Date: Fri, 11 May 2012 15:58:59 -0400 Message-ID: From: Joseph Yee To: "ima@ietf.org WG" Content-Type: multipart/alternative; boundary=20cf3079bfc2cd72de04bfc82a27 X-Gm-Message-State: ALoCoQkd/tPZNIHG6bQNzwHjdz3TxZsvNSIH43PpBNcxxv4kTa+kF3WsTTUlQkw8CtMKNndYQ06+ Subject: [EAI] Fwd: EAI WG Virtual Interim Meeting: Monday, May 14, 2012 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:59:02 -0000 --20cf3079bfc2cd72de04bfc82a27 Content-Type: text/plain; charset=UTF-8 Another reminder to everyone of next Monday's interim meeting. Happy weekend and happy mother's day to everyone. Joseph ---------- Forwarded message ---------- From: Joseph Yee Date: Thu, May 3, 2012 at 12:21 AM Subject: Fwd: EAI WG Virtual Interim Meeting: Monday, May 14, 2012 To: "ima@ietf.org WG" All, Just an early reminder to everyone of the interim meeting at May 14, and please provide revision of the draft by May 9 so that everyone read and discuss the same draft. Revision after May 9 is acceptable, but prefer to be editorial only update, and please provide rdiff along with the notification to the mailing list so that it's easy for everyone to track the change. Thanks Joseph Begin forwarded message: > From: IESG Secretary > Date: April 27, 2012 4:36:50 PM EDT > To: IETF Announcement List > Cc: ima@ietf.org > Subject: EAI WG Virtual Interim Meeting: Monday, May 14, 2012 > > The next EAI WG virtual interim meeting will be via jabber chat > (eai@jabber.ietf.org) on Monday, May 14 at 12:00 UTC for 2 > hours. > > Local times for 12:00 UTC: > http://www.timeanddate.com/worldclock/fixedtime.html?msg=IETF+EAI+WG+Jabber+Chat&iso=20120514T12&ah=2 > > Draft: agenda, subject to discussion on the mailing list prior > to the meeting, is > > 1 Agenda Bash > > 2 POP/IMAP Cluster > Discussion of the following drafts. A _short_ WG Last Call will > be initiated either immediately after the meeting or immediately > after new versions can be posted if the latter is necessary: > > draft-ietf-eai-5738bis-03 (IMAP) > draft-ietf-eai-rfc5721bis-04 (POP) > draft-ietf-eai-popimap-downgrade-05 > draft-ietf-eai-simpledowngrade-03 > > 3 Other drafts > Discussion of status and plans for mailing lists and MAILTO. > > 4 AOB --20cf3079bfc2cd72de04bfc82a27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Another reminder to everyone of next Monday's interim meeting. =C2=A0Ha= ppy weekend and happy mother's day to everyone.

Jose= ph

---------- Forwarded message ---------= -
From: Joseph Yee <jyee@afilias.info>
Date= : Thu, May 3, 2012 at 12:21 AM
Subject: Fwd: EAI WG Virtual Interim Meet= ing: Monday, May 14, 2012
To: "ima@ietf.org WG" <ima@ietf.org>


All,

Just an early reminder to everyone of the interim meeting at May 14, and pl= ease provide revision of the draft by May 9 so that everyone read and discu= ss the same draft. =C2=A0 Revision after May 9 is acceptable, but prefer to= be editorial only update, and please provide rdiff along with the notifica= tion to the mailing list so that it's easy for everyone to track the ch= ange.

Thanks
Joseph

Begin forwarded message:

> From: IESG Secretary <ie= sg-secretary@ietf.org>
> Date: April 27, 2012 4:36:50 PM EDT
> To: IETF Announcement List <ietf-announce@ietf.org>
> Cc: ima@ietf.org
> Subject: EAI WG Virtual Interim Meeting: Monday, May 14, 2012
>
> The next EAI WG virtual interim meeting will be via jabber chat
> (eai@jabber.ietf.org) on Mo= nday, May 14 at 12:00 UTC for 2
> hours.
>
> Local times for 12:00 UTC:
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF+EAI+WG+Jab= ber+Chat&iso=3D20120514T12&ah=3D2
>
> Draft: agenda, subject to discussion on the mailing list prior
> to the meeting, is
>
> 1 Agenda Bash
>
> 2 POP/IMAP Cluster
> Discussion of the following drafts. A _short_ WG Last Call will
> be initiated either immediately after the meeting or immediately
> after new versions can be posted if the latter is necessary:
>
> draft-ietf-eai-5738bis-03 (IMAP)
> draft-ietf-eai-rfc5721bis-04 (POP)
> draft-ietf-eai-popimap-downgrade-05
> draft-ietf-eai-simpledowngrade-03
>
> 3 Other drafts
> Discussion of status and plans for mailing lists and MAILTO.
>
> 4 AOB


--20cf3079bfc2cd72de04bfc82a27-- From klensin@jck.com Mon May 14 04:35:08 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970AD21F8454 for ; Mon, 14 May 2012 04:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjErBBolYlyu for ; Mon, 14 May 2012 04:35:08 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1168221F86D3 for ; Mon, 14 May 2012 04:35:06 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1STtT3-00069h-3W for ima@ietf.org; Mon, 14 May 2012 07:29:33 -0400 Date: Mon, 14 May 2012 07:35:00 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <69CFD17502649FFA54DB72CA@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] EAI critical path issues X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:35:08 -0000 Hi. Sorry to be posting this just before the meeting, but I wanted to see if anything would be posted over the weekend that would help clarify issues. This note attempts to summarize what appear to me to be the critical-path outstanding issues in the hope it can help focus our agenda. No particular order; writing as co-chair except where noted. (1) IMAP: Is "{SELECT, LIST,...} UTF-8" necessary and/or desirable. If so, do we intend to permit a client to specific that it accepts EAI syntax but not EAI messages?. This question doesn't seem to have a POP analogy -- is that true and does that answer help inform the decision. (2) IMAP: Murray's note of 23 April raises an issue about LANG that does not appear to have been answered on-list. (3) Do weintend to allow a critique of popimap-downgrade (or other approaches) in simple=downgrade or vice versa? (4) popimap-downgrade: Does this update 5322? (5) popimap-downgrade: Given that we are going to publish this spec, is the rewrite model acceptable or do we intend to change it? Personal note: the model that is there has been refined, presumably, by many months of exposure in the WG. Do we really have sufficient consensus for restarting that discussion. (6) The two downgrade specs are currently on track for Proposed Standard? Do you we have consensus for starting a discussion about Information or Experimental instead? (7) fter going through all four documents again and, to my personal relief, having gotten no traction for reopening RFC 6530 ("Framework"), I think we should consider: 7.1 Adding a paragraph to the IMAP spec (5738bis) that makes three points explicitly: (i) Unless it knows that all mail-reading clients that might be used have been upgraded to be EAI-compliant or the associated delivery MTA doesn't advertise UTF8SMTP, an IMAP (or POP) server or mail store that supports EAI messages must anticipate that it will receive connections and message requests from mail-reading clients that are not EAI-capable. (ii) Whatever decision a server makes about how to handle that case will lose information -- either hiding the message, replacing it with an error response, or creating a variation on the message that is EAI-compatible (the latter is known as "downgrading" but, because there will be significant information losses in many cases, the result is really a variant message, not a downgrade. There are no completely satisfactory solutions to this problem: the best answer is obviously for users who might receive messages that require EAI capabilities to upgrade all mail-reading mechanisms that might use. The choice among the best ways to encourage users to upgrade and supply appropriate information while doing so will depend on a series of tradeoffs that should recognize the particulars of the mail environment, implementation cost issues, expectations of how quickly conversions will occur, assumptions about the ratio of messages that require EAI capability and those that do not, and perhaps other issues. The WG cannot predict the future well enough to make a single, definitive, recommendation in this area. (iii) In many environments, a given user may use multiple mail reading approaches, perhaps an IMAP client on one occasion, a POP client on another, webmail access at other times, and a different POP or IMAP client at still other times. Because of this, a server cannot convert a message to "downgraded" form and use that form to replace the original message in the store without completely disabling EAI capability. In principle, a server can be designed to keep a "downgraded" version in combination with the original one, selecting the appropriate one when the client request arrives, but that is an implementation optimization, not a specification requirement. 7.2 The two "downgrade" specs should be reference from that section as examples -- nothing more or less. 7.3 All other text about downgrading should be removed from the IMAP spec. 7.4 All text about downgrading should be removed from the POP spec and a reference to the above substituted. Does that help move us forward? Chat with you all soon. john From klensin@jck.com Mon May 14 06:20:53 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E644021F86C4 for ; Mon, 14 May 2012 06:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwFU2n3LvxM8 for ; Mon, 14 May 2012 06:20:53 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5EA21F8634 for ; Mon, 14 May 2012 06:20:53 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1STv7M-0006Ga-RD for ima@ietf.org; Mon, 14 May 2012 09:15:16 -0400 Date: Mon, 14 May 2012 09:20:43 -0400 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Dropped connection X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:20:54 -0000 Hi. I was dropped and every attempt to reconnect gets dropped too. Jiankang is having similar problems. I can't tell if they are general (e.g., problem with IETF server that is dropping everyone) or if he and I have having bad luck. Will keep trying but, if the rest of you are online, please try to continue making progress. john From yaojk@cnnic.cn Mon May 14 06:31:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7E021F86B0 for ; Mon, 14 May 2012 06:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.239 X-Spam-Level: X-Spam-Status: No, score=-99.239 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L6T8XeJwh-8 for ; Mon, 14 May 2012 06:31:16 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 4957121F866E for ; Mon, 14 May 2012 06:31:13 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 14 May 2012 21:31:09 +0800 Message-ID: <129441982BD240E987BF3277365D8915@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: Date: Mon, 14 May 2012 21:31:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Dropped connection X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:31:17 -0000 ZG8gd2UgbmVlZCB0byBtb3ZlIHRvIGFub3RoZXIgamFiYmVyIHNlcnZlcj8NCg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8a2xlbnNpbkBq Y2suY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiA5 OjIwIFBNDQpTdWJqZWN0OiBbRUFJXSBEcm9wcGVkIGNvbm5lY3Rpb24NCg0KDQo+IEhpLg0KPiAN Cj4gSSB3YXMgZHJvcHBlZCBhbmQgZXZlcnkgYXR0ZW1wdCB0byByZWNvbm5lY3QgZ2V0cyBkcm9w cGVkIHRvby4NCj4gSmlhbmthbmcgaXMgaGF2aW5nIHNpbWlsYXIgcHJvYmxlbXMuICBJIGNhbid0 IHRlbGwgaWYgdGhleSBhcmUNCj4gZ2VuZXJhbCAoZS5nLiwgcHJvYmxlbSB3aXRoIElFVEYgc2Vy dmVyIHRoYXQgaXMgZHJvcHBpbmcNCj4gZXZlcnlvbmUpIG9yIGlmIGhlIGFuZCBJIGhhdmUgaGF2 aW5nIGJhZCBsdWNrLg0KPiANCj4gV2lsbCBrZWVwIHRyeWluZyBidXQsIGlmIHRoZSByZXN0IG9m IHlvdSBhcmUgb25saW5lLCBwbGVhc2UgdHJ5DQo+IHRvIGNvbnRpbnVlIG1ha2luZyBwcm9ncmVz cy4NCj4gDQo+ICAgam9obg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= From jyee@afilias.info Mon May 14 06:32:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D121F844F for ; Mon, 14 May 2012 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.992 X-Spam-Level: X-Spam-Status: No, score=-4.992 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRQ243rwTZsU for ; Mon, 14 May 2012 06:32:34 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 636FB21F843E for ; Mon, 14 May 2012 06:32:29 -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 1STvO0-0006gd-8h for ima@ietf.org; Mon, 14 May 2012 13:32:28 +0000 Received: from mail-qa0-f43.google.com ([209.85.216.43]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1STvO0-0007zc-83 for ima@ietf.org; Mon, 14 May 2012 13:32:28 +0000 Received: by qadb33 with SMTP id b33so2932108qad.9 for ; Mon, 14 May 2012 06:32:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZVc3a3J9pz0W/3x8ziQ/l+V3Fl0hs0SGXYZjBpuILXk=; b=nti70QS0kGLRV4nj2JjPtLLvgWsoMFX98LeTVw4iF0Py5aLTBA+wGJPMUk1n/l3tQl sKsS1cWWyOHxYWdy8rtd1ueNza0ko98K8tfE2UJf1zoBsELpX4S1zLesvDGpi+lfJRup TVgRCuD7IWh6TH2SFExwnxmYbxsKU3/CUG6awz0TlvbXSzXBgOSqxFXFAcneGJR6OCxc wdESm6PboAf/2ipm/8/VLTCu6c/Zs5xM2cXAOTkMV/tmi9+U/P876PKtmXBRh7vKKgIt 9DUr0/NYp7yZY9RiIQoEKquX7kJV0FaEIzt+Jf6xwfqqqHNFCvGPJ0+WhrqNZFjHqOJF nGNg== MIME-Version: 1.0 Received: by 10.220.141.84 with SMTP id l20mr5061148vcu.31.1337002348014; Mon, 14 May 2012 06:32:28 -0700 (PDT) Received: by 10.52.22.133 with HTTP; Mon, 14 May 2012 06:32:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 May 2012 09:32:27 -0400 Message-ID: From: Joseph Yee To: John C Klensin Content-Type: multipart/alternative; boundary=f46d0434bf52046bcc04bfff1efe X-Gm-Message-State: ALoCoQmXi3AjbdW4lZUoT4FZXtgw0DnNgRZObp3756Dm7U9Li0f/yMcTfpv1QaTscKGXOr5rOlUt Cc: ima@ietf.org Subject: Re: [EAI] Dropped connection X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:32:34 -0000 --f46d0434bf52046bcc04bfff1efe Content-Type: text/plain; charset=UTF-8 Jabber.org seems to be the issue, best try with google or other IM. Joseph On Mon, May 14, 2012 at 9:20 AM, John C Klensin wrote: > Hi. > > I was dropped and every attempt to reconnect gets dropped too. > Jiankang is having similar problems. I can't tell if they are > general (e.g., problem with IETF server that is dropping > everyone) or if he and I have having bad luck. > > Will keep trying but, if the rest of you are online, please try > to continue making progress. > > john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > --f46d0434bf52046bcc04bfff1efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jabber.org seems to be the issue, best try with google or other IM.
Joseph

On Mon, May 14, 2012 a= t 9:20 AM, John C Klensin <klensin@jck.com> wrote:
Hi.

I was dropped and every attempt to reconnect gets dropped too.
Jiankang is having similar problems. =C2=A0I can't tell if they are
general (e.g., problem with IETF server that is dropping
everyone) or if he and I have having bad luck.

Will keep trying but, if the rest of you are online, please try
to continue making progress.

=C2=A0 john

_______________________________________________
IMA mailing list
IMA@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ima

--f46d0434bf52046bcc04bfff1efe-- From alexey.melnikov@isode.com Mon May 14 06:39:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE421F8720 for ; Mon, 14 May 2012 06:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.707 X-Spam-Level: X-Spam-Status: No, score=-102.707 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tYbq-RKFXOM for ; Mon, 14 May 2012 06:39:49 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4390121F871D for ; Mon, 14 May 2012 06:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337002786; d=isode.com; s=selector; i=@isode.com; bh=aTIEjDmzhsLd00AJ43AfiB0NBh5hdWaMo/yr69LR6kk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=R3SpOTCrGN+UAu9Uj1RfViO1BAFAieGjCC8cvakGk9wZ5ruAhZPiIU2fbvPhpw8gYG7Wgt MF0CIcKfb76dAbT8uNzXOpMgw8JFgaeT98rkR5M4FAXm1ih9WlKCA1i2Nay72lAXPl/Kqh eKLUN4JTU8XcNmihTGBo9DVKL2aNA8M=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 14 May 2012 14:39:46 +0100 Message-ID: <4FB10B77.5030608@isode.com> Date: Mon, 14 May 2012 14:41:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 To: ima@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080206040609010400020200" Subject: [EAI] Fwd: [apps-discuss] AppsDir review of draft-ietf-eai-5738bis-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:39:50 -0000 This is a multi-part message in MIME format. --------------080206040609010400020200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. -------- Original Message -------- Subject: [apps-discuss] AppsDir review of draft-ietf-eai-5738bis-03 Date: Mon, 14 May 2012 06:37:19 -0700 From: Aaron Stone To: apps-discuss@ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). I apologize for the terrible tardiness of this review. Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-eai-5738bis-03 Title: IMAP Support for UTF-8 Reviewer: Aaron Stone Review Date: 5/13/2012 IETF Last Call Date: none found IESG Telechat Date: none scheduled Summary: This draft is ready for publication with only a few editorial nits. Major Issues: none Minor Issues: Section 3.2 (text that should be in 3.3, see below): The text first says that LIST without UTF8 will hide the UTF8 mailboxes, but then it says that LIST without UTF8 in the presensce of a UTF8 mailbox results in an error. Will this cause user anguish if one mailbox is upgraded to UTF-8 and now the portion of mailbox hierarchy that mailbox is in cannot be listed by non-UTF8-extension aware clients? Nits: - Section 3, last sentence: replace "imply" with "implies". - Section 3.1: What's the "appropriate internal format"? All IMAP servers that advertise the "UTF8=ACCEPT" 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. This looks like a nit, possible new last portion of text: ... MUST accept utf8-quoted mailbox names and convert them to the server's appropriate internal format as needed. - Section 3.2, second paragraph, "Servers MAY include mailboxes that can only be selected or examined..." This paragraph in the wrong section. It deals with LIST, LSUB, so I think it should be moved to 3.3. - Section 4: First sentence, the server may reject the command -- the server itself isn't failing. OLD A server that advertises "UTF8=ACCEPT" MAY fail for \NotUTF8 mailboxes with a NOT-UTF-8 response code. NEW A server that advertises "UTF8=ACCEPT" MAY fail an APPEND command for \NotUTF8 mailboxes with a NOT-UTF-8 response code. - Section 4: change "8-bit" to "8-bit character" in the last sentence. - Section 5: Expand the contraction doesn't => does not. - Section 5: Should this section state more obviously that the UTF8=USER stuff in 5738 is removed entirely? - Section 6: replace "internaltion mailbox name convention (modified UTF-7) with "Mailbox International Naming Convention" for consistency. - Section 9, Security Considerations: The first paragraph is left-over from 5738, should be removed entirely (LOGIN is no longer extended to UTF-8). Thank you, Aaron _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --------------080206040609010400020200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

-------- Original Message --------
Subject: [apps-discuss] AppsDir review of draft-ietf-eai-5738bis-03
Date: Mon, 14 May 2012 06:37:19 -0700
From: Aaron Stone <aaron@serendipity.cx>
To: apps-discuss@ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org 


I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
I apologize for the terrible tardiness of this review.

Please resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-eai-5738bis-03
Title: IMAP Support for UTF-8
Reviewer: Aaron Stone
Review Date: 5/13/2012
IETF Last Call Date: none found
IESG Telechat Date: none scheduled
Summary: This draft is ready for publication with only a few editorial nits.

Major Issues: none

Minor Issues:

Section 3.2 (text that should be in 3.3, see below):

The text first says that LIST without UTF8 will hide the UTF8 mailboxes, but
then it says that LIST without UTF8 in the presensce of a UTF8 mailbox results
in an error. Will this cause user anguish if one mailbox is upgraded
to UTF-8 and
now the portion of mailbox hierarchy that mailbox is in cannot be listed by
non-UTF8-extension aware clients?


Nits:

- Section 3, last sentence: replace "imply" with "implies".

- Section 3.1: What's the "appropriate internal format"?
   All IMAP servers that advertise the "UTF8=ACCEPT" 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.

This looks like a nit, possible new last portion of text:
   ... MUST accept utf8-quoted mailbox names and convert them to the server's
   appropriate internal format as needed.

- Section 3.2, second paragraph, "Servers MAY include mailboxes that
can only be selected or examined..."

This paragraph in the wrong section. It deals with LIST, LSUB, so I
think it should be moved to 3.3.

- Section 4: First sentence, the server may reject the command -- the
server itself isn't failing.

OLD
   A server that advertises "UTF8=ACCEPT" MAY fail for \NotUTF8
   mailboxes with a NOT-UTF-8 response code.
NEW
   A server that advertises "UTF8=ACCEPT" MAY fail an APPEND command
   for \NotUTF8 mailboxes with a NOT-UTF-8 response code.

- Section 4: change "8-bit" to "8-bit character" in the last sentence.

- Section 5: Expand the contraction doesn't => does not.
- Section 5: Should this section state more obviously that the
UTF8=USER stuff in 5738 is removed entirely?

- Section 6: replace "internaltion mailbox name convention (modified
UTF-7) with "Mailbox International Naming Convention" for consistency.

- Section 9, Security Considerations: The first paragraph is left-over
from 5738,
should be removed entirely (LOGIN is no longer extended to UTF-8).


Thank you,
Aaron
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--------------080206040609010400020200-- From alexey.melnikov@isode.com Mon May 14 07:02:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852821F845E for ; Mon, 14 May 2012 07:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD-NqjbBOs-c for ; Mon, 14 May 2012 07:02:44 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 22A7921F845B for ; Mon, 14 May 2012 07:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337004162; d=isode.com; s=selector; i=@isode.com; bh=RXFjaO8HIdSPVSgYabcAKg6rjWU2HuTKUe3XhSavDMI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eWesEgJxVZizDDK5Ks/spad9wAaCcqn9kPq3d5ih6cza1QjYl8XS8j1iYcRYg5yRrBIpdP kCWYJWxP919TJAk/yxlABJZJihyDZtvoH88CDLt4SoZKwEmkxoiv5hO5mAL69eAByzu0/4 SLuRYr3duOCjcXh4SIc/BCpIe8mKc+c=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 14 May 2012 15:02:42 +0100 Message-ID: <4FB110D7.3030305@isode.com> Date: Mon, 14 May 2012 15:04:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 To: fujiwara@jprs.co.jp References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> In-Reply-To: <20120507.201752.52172531.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arnt@gulbrandsen.priv.no, ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:02:45 -0000 On 07/05/2012 12:17, fujiwara@jprs.co.jp wrote: >> From: Arnt Gulbrandsen >>> If an message contains both non-ASCII header value and Downgraded-* >>> header fields, the message is broken. >> Yes. But what should happen? >> >> Should the message be stripped of its wrongness at delivery time? > It is out of scope of pop/imap. > Bogus messages are delivered to pop/imap mailboxes as is. > >> In >> that case popimap-downgrade cannot apply to mail stored before it was >> deployed, or an time-consuming migration is required to deploy it. > POP server or IMAP server shuold not change messages when a client > support UTF8 capability. It is out of scope of pop/imap downgrading. > >> Should the message be edited on disk when popimap-downgrade sees it? > A user may use multiple POP/IMAP clients. Some clients may support > UTF8 capability, and others may not support UTF8 capability. > > Then, the POP/IMAP server must keep the messages as is. > And the server may have downgraded version additonally (as a cache). > >> In >> that case popimap-downgrade can only be deployed for mailboxes to which >> the server has write access. Further, if that's done for IMAP, the >> document needs to specify that the server issue a new UIDVALIDITY. > The UIDVALIDITY value should be calculated by the original message. > > Is the UIDVALIDITY for the original message same as the UIDVALIDITY > for the downgraded message ? Just to clarify one thing: A message in IMAP is immutable (i.e. it can't change its basic properties, other than IMAP flags/annotations). The message is uniquely identified by UIDVALIDITY (per mailbox value) + its UID. So if the message changes in the IMAP mailstore, it has to get a new UID, or the UIDVALIDITY for the mailbox has to change. The latter signals clients that all of its cached messages are no longer available and have to be purged from the cache. From klensin@jck.com Mon May 14 08:02:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AAD21F869E for ; Mon, 14 May 2012 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY8oKxcV3H4U for ; Mon, 14 May 2012 08:02:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACD521F8682 for ; Mon, 14 May 2012 08:02:32 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1STwhh-0006PY-VN; Mon, 14 May 2012 10:56:53 -0400 Date: Mon, 14 May 2012 11:02:21 -0400 From: John C Klensin To: Alexey Melnikov , fujiwara@jprs.co.jp Message-ID: <5BD49A7EBD875AFA169223A4@PST.JCK.COM> In-Reply-To: <4FB110D7.3030305@isode.com> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: arnt@gulbrandsen.priv.no, ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:02:32 -0000 --On Monday, May 14, 2012 15:04 +0100 Alexey Melnikov wrote: > A message in IMAP is immutable (i.e. it can't change its basic > properties, other than IMAP flags/annotations). The message is > uniquely identified by UIDVALIDITY (per mailbox value) + its > UID. > So if the message changes in the IMAP mailstore, it has to get > a new UID, or the UIDVALIDITY for the mailbox has to change. > The latter signals clients that all of its cached messages are > no longer available and have to be purged from the cache. Right. I think that, among other things that means that, if I'm a server and I try the strategy of converting/downgrading the message when it enters the mail store and then keeping both versions and deciding which one to deliver based on what the client asks for, I'd better be _really_ alert and careful about the above. I'm not even certain it is possible to get right, at least while preserving UIDVALIDITY at all. I started thinking about a slightly different, but related, problem over the weekend having to do with what happens when a user accesses a mail store with an EAI-compliant IMAP client, an EAI non-compliant IMAP client, a webmail client (probably compliant), and compliant and non-complaint POP clients that use the notorious "leave mail on server" option and that do so in different orders. One can get a bad headache rather easily. My use of the term "variant of message" rather than "downgraded message" in my "critical path issues" note earlier today was a consequence of that because, in many respects, a "downgraded message" (simple or otherwise) isn't really a transformed copy of the same message -- it is a new message with a familial or derivative relationship to the original one that the server chooses to deliver instead. best, john From arnt@gulbrandsen.priv.no Mon May 14 08:09:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3121F87D7 for ; Mon, 14 May 2012 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CslOjWI1G7s8 for ; Mon, 14 May 2012 08:09:44 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 343BD21F8763 for ; Mon, 14 May 2012 08:09:44 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5B31EF8E92A; Mon, 14 May 2012 15:09:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337008180-11856-11855/10/1; Mon, 14 May 2012 15:09:40 +0000 Message-Id: <4FB12058.7040200@gulbrandsen.priv.no> Date: Mon, 14 May 2012 17:10:16 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: John C Klensin References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> In-Reply-To: <5BD49A7EBD875AFA169223A4@PST.JCK.COM> Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:09:44 -0000 On 05/14/2012 05:02 PM, John C Klensin wrote: > I'm not even certain it is possible to get right, at > least while preserving UIDVALIDITY at all. I think simpledowngrade gets it right, since it doesn't touch any non-EAI message at all. popimap-downgrade has a bit of a problem, since it depends on downgraded-* not being there for non-EAI input messages. I think that perhaps the IMAP EAI document should say something like: A client which is updated to add UTF8=* should be aware that if it has cached any part of an internationalized message before it was extended with UTF8=* support, then that part may be some sort of compatibility rendering by the server. Clearing the cache when the upgrade is deployed may be advisable. Arnt From ned+ima@mrochek.com Mon May 14 08:36:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BA21F8807 for ; Mon, 14 May 2012 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-r7Xm2KgM0w for ; Mon, 14 May 2012 08:36:17 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B421F87FF for ; Mon, 14 May 2012 08:36:17 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFGT95Q2NK001PUP@mauve.mrochek.com> for ima@ietf.org; Mon, 14 May 2012 08:36:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 14 May 2012 08:36:12 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFGT94FDHK0006TF@mauve.mrochek.com> Date: Mon, 14 May 2012 08:29:00 -0700 (PDT) In-reply-to: "Your message dated Mon, 14 May 2012 17:10:16 +0200" <4FB12058.7040200@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:36:18 -0000 > On 05/14/2012 05:02 PM, John C Klensin wrote: > > I'm not even certain it is possible to get right, at > > least while preserving UIDVALIDITY at all. > I think simpledowngrade gets it right, since it doesn't touch any > non-EAI message at all. popimap-downgrade has a bit of a problem, since > it depends on downgraded-* not being there for non-EAI input messages. It's more than a problem, it's a disaster in the making. The problem is that you cannot make *any* assumptions about the presence or absence of downgraded-* fields. This is because they're certain to leak - consider the case of a non-EAI client that resends a message (an operation that's likely to retain these headers) to an EAI client that resends the message again, this time adding resent-* fields that contain EAI addresses. Now you have a perfectly legitimate EAI message that contains downgraded-* fields. And simpledowngrade doesn't really do much better, because you now end up with invalid addresses in the regular from and to fields. This is why I continue to believe that all of this stuff is not only going to generate support calls, they're going to be the sort of calls where figuring out what happened requires real expertise. > I think that perhaps the IMAP EAI document should say something like: > A client which is updated to add UTF8=* should be aware that if it > has cached any part of an internationalized message before > it was extended with UTF8=* support, then that part may be > some sort of compatibility rendering by the server. Clearing the > cache when the upgrade is deployed may be advisable. And what about download-and-delete clients (which exist for both POP and IMAP)? Yes, such clients won't suffer from UIDVALIDITY issues, but the messages are essentially irreversibly corrupt at this point. Ned From ned+ima@mrochek.com Mon May 14 09:13:04 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A10521F87D6 for ; Mon, 14 May 2012 09:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPErudvT7Ucz for ; Mon, 14 May 2012 09:13:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DF75621F87D0 for ; Mon, 14 May 2012 09:13:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFGUJQLVZK001IOK@mauve.mrochek.com> for ima@ietf.org; Mon, 14 May 2012 09:13:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 14 May 2012 09:12:59 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFGUJPDS1Y0006TF@mauve.mrochek.com> Date: Mon, 14 May 2012 09:06:28 -0700 (PDT) In-reply-to: "Your message dated Mon, 14 May 2012 11:02:21 -0400" <5BD49A7EBD875AFA169223A4@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> To: John C Klensin Cc: arnt@gulbrandsen.priv.no, ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:13:04 -0000 > --On Monday, May 14, 2012 15:04 +0100 Alexey Melnikov > wrote: > > A message in IMAP is immutable (i.e. it can't change its basic > > properties, other than IMAP flags/annotations). The message is > > uniquely identified by UIDVALIDITY (per mailbox value) + its > > UID. > > So if the message changes in the IMAP mailstore, it has to get > > a new UID, or the UIDVALIDITY for the mailbox has to change. > > The latter signals clients that all of its cached messages are > > no longer available and have to be purged from the cache. > Right. I think that, among other things that means that, if I'm > a server and I try the strategy of converting/downgrading the > message when it enters the mail store and then keeping both > versions and deciding which one to deliver based on what the > client asks for, I'd better be _really_ alert and careful about > the above. I'm not even certain it is possible to get right, at > least while preserving UIDVALIDITY at all. > I started thinking about a slightly different, but related, > problem over the weekend having to do with what happens when a > user accesses a mail store with an EAI-compliant IMAP client, an > EAI non-compliant IMAP client, a webmail client (probably > compliant), and compliant and non-complaint POP clients that use > the notorious "leave mail on server" option and that do so in > different orders. One can get a bad headache rather easily. My > use of the term "variant of message" rather than "downgraded > message" in my "critical path issues" note earlier today was a > consequence of that because, in many respects, a "downgraded > message" (simple or otherwise) isn't really a transformed copy > of the same message -- it is a new message with a familial or > derivative relationship to the original one that the server > chooses to deliver instead. If you want to turn that headache into a migraine, consider what happens when a single EAI client alternately accesses a mailbox on the campany LAN, which allows direct access, and through a capability-filtering corporate firewall that removes the EAI capability from the server announcement. And yes, such firewalls do exist for POP, IMAP, and SMTP. And you can't assume they filter all the protocols in a consistent way either - does that upgrade this to a cluster headache? Ned From klensin@jck.com Mon May 14 09:37:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8821F8758 for ; Mon, 14 May 2012 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhRvYPqqlkgG for ; Mon, 14 May 2012 09:37:41 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8805121F86F7 for ; Mon, 14 May 2012 09:37:41 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1STyBn-0006WC-Hp; Mon, 14 May 2012 12:32:03 -0400 Date: Mon, 14 May 2012 12:37:31 -0400 From: John C Klensin To: Ned Freed Message-ID: <5F7494491011BA4F762BAC04@PST.JCK.COM> In-Reply-To: <01OFGUJPDS1Y0006TF@mauve.mrochek.com> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <01OFGUJPDS1Y0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: arnt@gulbrandsen.priv.no, ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:37:42 -0000 --On Monday, May 14, 2012 09:06 -0700 Ned Freed wrote: >... >> I started thinking about a slightly different, but related, >> problem over the weekend having to do with what happens when a >> user accesses a mail store with an EAI-compliant IMAP client, >> an EAI non-compliant IMAP client, a webmail client (probably >> compliant), and compliant and non-complaint POP clients that >> use the notorious "leave mail on server" option and that do >> so in different orders. One can get a bad headache rather >> easily. My use of the term "variant of message" rather than >> "downgraded message" in my "critical path issues" note >> earlier today was a consequence of that because, in many >> respects, a "downgraded message" (simple or otherwise) isn't >> really a transformed copy of the same message -- it is a new >> message with a familial or derivative relationship to the >> original one that the server chooses to deliver instead. > > If you want to turn that headache into a migraine, consider > what happens when a single EAI client alternately accesses a > mailbox on the campany LAN, which allows direct access, and > through a capability-filtering corporate firewall that removes > the EAI capability from the server announcement. > > And yes, such firewalls do exist for POP, IMAP, and SMTP. And > you can't assume they filter all the protocols in a consistent > way either - does that upgrade this to a cluster headache? Yep. At some level, this is all part of "all of the alternatives to just get everything upgraded are pretty horrible and no one is hugely less horrible than the others", but it is yet another situation about which the IMAP spec should probably call out (and hence yet another reason for putting the text in the IMAP spec rather than the POP one). As promised during the Jabber chat meeting, I'll try to get text to the list as soon as I finish with a couple of other things (include the draft minutes), but please help me and the WG get the tone of that text right. john From arnt@gulbrandsen.priv.no Mon May 14 09:50:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5435821F883A for ; Mon, 14 May 2012 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZKBy5A7pqrL for ; Mon, 14 May 2012 09:50:43 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E897921F8839 for ; Mon, 14 May 2012 09:50:42 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 23401FA0C41; Mon, 14 May 2012 16:50:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337014240-11856-11855/10/2; Mon, 14 May 2012 16:50:40 +0000 Message-Id: <4FB13805.5070708@gulbrandsen.priv.no> Date: Mon, 14 May 2012 18:51:17 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Ned Freed References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> In-Reply-To: <01OFGT94FDHK0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:50:45 -0000 On 05/14/2012 05:29 PM, Ned Freed wrote: >> On 05/14/2012 05:02 PM, John C Klensin wrote: >>> I'm not even certain it is possible to get right, at >>> least while preserving UIDVALIDITY at all. >=20 >> I think simpledowngrade gets it right, since it doesn't touch any >> non-EAI message at all. popimap-downgrade has a bit of a problem, = since >> it depends on downgraded-* not being there for non-EAI input messages. >=20 > It's more than a problem, it's a disaster in the making. Perhaps. > The problem is that you cannot make *any* assumptions about the = presence or > absence of downgraded-* fields. [...] OK for me =97 I don't. > And simpledowngrade doesn't really do much better, because you now end = up > with invalid addresses in the regular from and to fields. IMO, that's the irreducible minimum problem. It's a nasty one, no question, but if we're going to have EAI, we have to pay that price. > This is why I continue to believe that all of this stuff is not only > going to generate support calls, they're going to be the sort of calls = where > figuring out what happened requires real expertise. Yes. >> I think that perhaps the IMAP EAI document should say something like: >=20 >> A client which is updated to add UTF8=3D* should be aware that if it >> has cached any part of an internationalized message before >> it was extended with UTF8=3D* support, then that part may be >> some sort of compatibility rendering by the server. Clearing the >> cache when the upgrade is deployed may be advisable. >=20 > And what about download-and-delete clients (which exist for both POP = and IMAP)? > Yes, such clients won't suffer from UIDVALIDITY issues, but the = messages are > essentially irreversibly corrupt at this point.=20 Yes. A serious problem. But I think it's not relevant to that document, since there's nothing to do about it. Fetchmail, for instance, can add EAI support, but there's nothing it can do about the mail it has deleted, so why bother to talk about that? Arnt From arnt@gulbrandsen.priv.no Mon May 14 09:59:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306B521F886E for ; Mon, 14 May 2012 09:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C1wp9wb3Gaf for ; Mon, 14 May 2012 09:59:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1221F886A for ; Mon, 14 May 2012 09:59:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4044BFA0C44; Mon, 14 May 2012 16:59:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337014792-11856-11855/10/3; Mon, 14 May 2012 16:59:52 +0000 Message-Id: <4FB13A2D.2000404@gulbrandsen.priv.no> Date: Mon, 14 May 2012 19:00:29 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> In-Reply-To: <01OFGT94FDHK0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:59:55 -0000 On 05/14/2012 05:29 PM, ned+ima@mrochek.com wrote: > And what about download-and-delete clients (which exist for both POP = and IMAP)? > Yes, such clients won't suffer from UIDVALIDITY issues, but the = messages are > essentially irreversibly corrupt at this point.=20 I have a feeling that during this transition, the late implementers are going to feel more pain than the early ones. Arnt From klensin@jck.com Mon May 14 10:32:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADA321F8900 for ; Mon, 14 May 2012 10:32:07 -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.335, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4REwNQ+4if4 for ; Mon, 14 May 2012 10:32:07 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3F05821F88FF for ; Mon, 14 May 2012 10:32:07 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1STz2Y-0006a3-1h; Mon, 14 May 2012 13:26:34 -0400 Date: Mon, 14 May 2012 13:32:01 -0400 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: In-Reply-To: <4FB13A2D.2000404@gulbrandsen.priv.no> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13A2D.2000404@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:32:07 -0000 --On Monday, May 14, 2012 19:00 +0200 Arnt Gulbrandsen wrote: > On 05/14/2012 05:29 PM, ned+ima@mrochek.com wrote: >> And what about download-and-delete clients (which exist for >> both POP and IMAP)? Yes, such clients won't suffer from >> UIDVALIDITY issues, but the messages are essentially >> irreversibly corrupt at this point. > > I have a feeling that during this transition, the late > implementers are going to feel more pain than the early ones. That is both poetic justice (for a change) and implies accelerating pressure to upgrade (probably A Good Thing). john From ned+ima@mrochek.com Mon May 14 11:08:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A174321F8857 for ; Mon, 14 May 2012 11:08:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8-qahZ0TuCV for ; Mon, 14 May 2012 11:08:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C53CA21F85C6 for ; Mon, 14 May 2012 11:08:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFGYL832DS001GZJ@mauve.mrochek.com> for ima@ietf.org; Mon, 14 May 2012 11:08:45 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 14 May 2012 11:08:42 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFGYL66S6E0006TF@mauve.mrochek.com> Date: Mon, 14 May 2012 11:01:23 -0700 (PDT) In-reply-to: "Your message dated Mon, 14 May 2012 18:51:17 +0200" <4FB13805.5070708@gulbrandsen.priv.no> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:08:48 -0000 > On 05/14/2012 05:29 PM, Ned Freed wrote: > >> On 05/14/2012 05:02 PM, John C Klensin wrote: > >>> I'm not even certain it is possible to get right, at > >>> least while preserving UIDVALIDITY at all. > > > >> I think simpledowngrade gets it right, since it doesn't touch any > >> non-EAI message at all. popimap-downgrade has a bit of a problem, since > >> it depends on downgraded-* not being there for non-EAI input messages. > > > > It's more than a problem, it's a disaster in the making. > Perhaps. > > The problem is that you cannot make *any* assumptions about the presence or > > absence of downgraded-* fields. [...] > OK for me — I don't. > > And simpledowngrade doesn't really do much better, because you now end up > > with invalid addresses in the regular from and to fields. > IMO, that's the irreducible minimum problem. It's a nasty one, no > question, but if we're going to have EAI, we have to pay that price. Not if you eliminate as many downgrade scenarios as possible. > > This is why I continue to believe that all of this stuff is not only > > going to generate support calls, they're going to be the sort of calls where > > figuring out what happened requires real expertise. > Yes. Any time a support call requires real expertise you're past front line and even second line suport, and at that point costs can easily go up by a factor of 10 or more. > >> I think that perhaps the IMAP EAI document should say something like: > > > >> A client which is updated to add UTF8=* should be aware that if it > >> has cached any part of an internationalized message before > >> it was extended with UTF8=* support, then that part may be > >> some sort of compatibility rendering by the server. Clearing the > >> cache when the upgrade is deployed may be advisable. > > > > And what about download-and-delete clients (which exist for both POP and IMAP)? > > Yes, such clients won't suffer from UIDVALIDITY issues, but the messages are > > essentially irreversibly corrupt at this point. > Yes. A serious problem. > But I think it's not relevant to that document, since there's nothing to > do about it. Fetchmail, for instance, can add EAI support, but there's > nothing it can do about the mail it has deleted, so why bother to talk > about that? I'm sorry, but I strongly disagree. It's absolutely vital that these specifications list all the known consequences of their use, *especially* those consequences that cannot be mitigated, so that people deploying this stuff can make informed choices about how to set things up, and indeed, whether or not to deploy it at all. I can almost accept the argument that these things can be covered in some other document, but the problem with that is that both the consequences and the mitigation methods are inextricably linked to what downgrade approach is used. We see any example right here: Downgrade-* headers have different issues than insertion of invalid addresses. Ned From ned+ima@mrochek.com Mon May 14 11:39:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D98921F889F for ; Mon, 14 May 2012 11:39:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUAIMvNT9Cfv for ; Mon, 14 May 2012 11:39:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1621F85AF for ; Mon, 14 May 2012 11:39:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFGZNM8NSG001FJ2@mauve.mrochek.com> for ima@ietf.org; Mon, 14 May 2012 11:39:42 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 14 May 2012 11:39:40 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFGZNL0MOU0006TF@mauve.mrochek.com> Date: Mon, 14 May 2012 11:18:19 -0700 (PDT) In-reply-to: "Your message dated Mon, 14 May 2012 13:32:01 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13A2D.2000404@gulbrandsen.priv.no> To: John C Klensin Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:39:45 -0000 > --On Monday, May 14, 2012 19:00 +0200 Arnt Gulbrandsen > wrote: > > On 05/14/2012 05:29 PM, ned+ima@mrochek.com wrote: > >> And what about download-and-delete clients (which exist for > >> both POP and IMAP)? Yes, such clients won't suffer from > >> UIDVALIDITY issues, but the messages are essentially > >> irreversibly corrupt at this point. > > > > I have a feeling that during this transition, the late > > implementers are going to feel more pain than the early ones. > That is both poetic justice (for a change) and implies > accelerating pressure to upgrade (probably A Good Thing). I'm not sure this is really relevant, but FWIW... I don't see how this is really any different from the deployment of MIME, or ESMTP, or many other things. It's been my experience that the main factor isn't when, but who. If you're an open source developer, for example, you're not under direct financial pressure... And you don't have to care about customer support if you don't want to. So you have a lot of control over your pain level, and most (wisely) choose to keep that level low. The same goes for the commercial entities whose software runs on vast numbers of deployed systems. You're in the envious position of having your stuff be treated as the defacto standard more often than not. You can release egregiously broken crap but as long as it self-interoperates it becomes everyone else's problem to deal with. The implementors in the middle are the ones who get screwed. They're under direct financial pressure to deliver, they have to deal with "but it works fine when foo talks to itself, that means you must be the one who is broken", and so on. As for what the middle group sees, the distribution of pain tends to be tricameral over time. The first hump is the early implementor hump, where the first set of interoperability issues are shaken out. The second is when the big players get on board, and invariably screw something up that you have no choice but to deal with. (See above.) And the final hump, which is smaller but with a long tail, is dealing with the crap that cannot or will not be upgraded. Of course there's an added hit, which is that whenever you enter you have your own bugs and deployment issues to sort out. And in the case of EAI those are going to be nonnegligable. The best way to handle this is to try and get between the humps. If you wait too long you'll overlap that long tail - which I guess is the case you're thinking of - and that's not going to be pleasant. But given that most implementors of this sort don't have full control over their release schedule, getting the timing right can be very tricky. You're probably best off implementing as soon as possible, because that gives you a shot at being between the first two humps. So I guess this is a longwinded way of saying I come to more or less the same conclusion but for different reasons. Ned From jyee@afilias.info Mon May 14 12:02:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC10021F875C for ; Mon, 14 May 2012 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.209 X-Spam-Level: X-Spam-Status: No, score=-5.209 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEqlVEWNpp0o for ; Mon, 14 May 2012 12:02:45 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23721F875B for ; Mon, 14 May 2012 12:02:45 -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 1SU0Xc-0003en-8m for ima@ietf.org; Mon, 14 May 2012 19:02:44 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SU0Xc-0001Di-84 for ima@ietf.org; Mon, 14 May 2012 19:02:44 +0000 Received: by mail-vb0-f50.google.com with SMTP id l1so3959041vba.9 for ; Mon, 14 May 2012 12:02:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=h1Fa1/Gx5/fRbDWGL/OIjWJHuaf911XTF5EmdXvkdCE=; b=idnX22hJPMZey7jPFqfAH6Gbt4QYmp4ZhjCA/gxGnJ+6U2T3r8oHuh2Rh1qgGKJHjQ c66bDmiBsKVIKDREjRQgRW8VEhpqWd/aMU8l7l+6wC9ss6n0jbYtMPEWUPsMS1M+OZ5g 9OXAWjnKcOLig48b+URLLVtkWp/4o9igWPqygUFNY+s2L9jkKWHI7nMEnXt2+WIZMtpu ePJNUvftx59DqeKiSCsDcqhaouCrEFShfwhbCh/DEubHB68C3xt5V6vJesYtpI35GJH8 paKTLHgM6ulVcZ8Acdgjs7yS1pxu2w+HsRsJG7jRxuUKHeBzWrGavnq2I6YcV2HNHKYa jMxA== MIME-Version: 1.0 Received: by 10.52.26.240 with SMTP id o16mr4572146vdg.20.1337022164244; Mon, 14 May 2012 12:02:44 -0700 (PDT) Received: by 10.52.22.133 with HTTP; Mon, 14 May 2012 12:02:44 -0700 (PDT) Date: Mon, 14 May 2012 15:02:44 -0400 Message-ID: From: Joseph Yee To: "ima@ietf.org WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnFHKqnCGI/F/dLsijB4SAy99qIkmQYnoHZhpx9S7hABtVEadOndoC70L/jNwQKi1InDSVo Subject: [EAI] Preliminary High-level summary of EAI Meeting Conclusions at May 14, 2012 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:02:46 -0000 Preliminary High-level summary of EAI Meeting Conclusions at May 14, 2012 (Interim Meeting @ Jabber) These notes are preliminary. =C2=A0Detailed minutes, with more=C2=A0of the reasoning for the conclusions captured, will be posted=C2=A0later in the week. Regarding IMAP-UTF8 draft - IMAP LANG will return language list in no specific order. - IMAP LANG will not return 'default' in the language list. - IMAP use ENABLE only to manage mode switch. - UTF8 parameters dropped at SELECT, EXAMINE, LIST, LSUB, hence all of the related responses as well - New text suggested about client and downgrade for IMAP-UTF8 draft, with both downgrade drafts and POP-UTF8 draft to reference to the proposed new section.=C2=A0 Group at interim meeting supported this approach.=C2=A0 The text follows the general outline of John Klensin's point (7) in http://www.ietf.org/mail-archive/web/ima/current/msg04787.html Regarding both downgrade drafts - Neither downgrade draft will not update RFC5322, RFC3501 - Downgrade docs will not critique each other - Dot invalid email address does not get WG consensus.=C2=A0 An separate email will go to mailing list again for confirmation. - Both downgrade drafts will publish as Proposed Standard, with PROTO write up addressing the rationale. Note: If we go into LC with PS as a target and IESG decides to make it Informational after LC, we are done. =C2=A0If we go in with Informational as a target and IESG decides that community consensus calls for Proposed Standard, we need another Last Call. =C2=A0So, while there are other reasons for PS, this pragmatic one is probably sufficient. Regarding approach to downgrade and empty group at "From:" - If a document is needed to "update" RFC5322 to explicitly allow empty group syntax in "From:", Barry Leiba will do a first draft of a "mini-doc" to that effect (rather than trying to do it in one of the downgrading specs). =C2=A0 John Klensin believes that he can=C2=A0develop t= ext for the IMAP document (see above) that will make such a document unnecessary. =C2=A0Avoiding such a document has two advantages: (i) less review and approval work for the WG and hence less time until this is finished and (ii) We really don't want to encourage that syntax in the inter-host SMTP environment. Meeting adjourned at roughly 14:07 UTC, deferring the EAI-mailinglist and EAI-MAILTO topics to the WG mailing list. From klensin@jck.com Mon May 14 12:08:14 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACD321F8896 for ; Mon, 14 May 2012 12:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUBFkXwYaK3y for ; Mon, 14 May 2012 12:08:13 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B539421F8893 for ; Mon, 14 May 2012 12:08:13 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SU0XW-0006hK-U1; Mon, 14 May 2012 15:02:38 -0400 Date: Mon, 14 May 2012 15:08:05 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01OFGZNL0MOU0006TF@mauve.mrochek.com> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13A2D.2000404@gulbrandsen.priv.no> <01OFGZNL0MOU0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:08:14 -0000 --On Monday, May 14, 2012 11:18 -0700 Ned Freed wrote: >... >> That is both poetic justice (for a change) and implies >> accelerating pressure to upgrade (probably A Good Thing). > > I'm not sure this is really relevant, but FWIW... > > I don't see how this is really any different from the > deployment of MIME, or ESMTP, or many other things. >... > So I guess this is a longwinded way of saying I come to more > or less the same conclusion but for different reasons. Ned, I think "yes". I think there is one small difference between EAI --perhaps not generally, but at the IMAP/POP end of things. I have no idea how much of a difference it makes. A system operator, especially one at the "we are giving things away for free that are worth what you pay for them and are big enough to not care" end of the spectrum can avoid all issues with client interfaces to the mail store by simply refusing to advertise EAI capability at the delivery server. Nothing requiring EAI capabilities ever makes it into the mail store, so it makes no difference whether POP or IMAP clients (or webmail interfaces) are upgraded or not. The MIME design avoided that particular control point and, with the possible exception of using SIZE to negotiate really big message transfers, the early/core SMTP extensions were about making things work more efficiently or smoothly, not about whether or not the messages went through. I think that difference is going to affect our deployment dynamics, including where at least some of the pain appears and who it affects. But I can't even guess at scenarios beyond that other than the one we've periodically predicted for the basic SMTP and Message Format extensions, i.e., that deployment and use is likely to spread outward from particularly-interested language / script communities. But I don't see the above --whether correct or not-- affecting our documents in any way. best, john From arnt@gulbrandsen.priv.no Mon May 14 12:39:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A021F88A6 for ; Mon, 14 May 2012 12:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRhuBfOp6sji for ; Mon, 14 May 2012 12:39:55 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9565321F88A3 for ; Mon, 14 May 2012 12:39:55 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3A2BFFA0C67; Mon, 14 May 2012 19:39:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337024392-11856-11855/10/4; Mon, 14 May 2012 19:39:52 +0000 Message-Id: <4FB15FAE.60503@gulbrandsen.priv.no> Date: Mon, 14 May 2012 21:40:30 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Ned Freed References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> In-Reply-To: <01OFGYL66S6E0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252 Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:39:56 -0000 On 05/14/2012 08:01 PM, Ned Freed wrote: > I'm sorry, but I strongly disagree. It's absolutely vital that these > specifications list all the known consequences of their use, *especially* > those consequences that cannot be mitigated, so that people deploying > this stuff can make informed choices about how to set things up, and indeed, > whether or not to deploy it at all. All of the documents from this WG are going to be read mostly by people who are implementing some EAI thing or another, or are already implementing. You're talking about people who might/will deploy, which is a different audience. I'm not at all opposed to having a document about deployment issues, I think it would be a fine thing, but I'm definitely not volunteering to write that. Arnt From ned+ima@mrochek.com Mon May 14 14:03:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0830721F88BF for ; Mon, 14 May 2012 14:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1PKM9C6r1od for ; Mon, 14 May 2012 14:03:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC221F8880 for ; Mon, 14 May 2012 14:03:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFH4P1DBO000199J@mauve.mrochek.com> for ima@ietf.org; Mon, 14 May 2012 14:03:37 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 14 May 2012 14:03:34 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFH4OZBTS40006TF@mauve.mrochek.com> Date: Mon, 14 May 2012 13:56:20 -0700 (PDT) In-reply-to: "Your message dated Mon, 14 May 2012 21:40:30 +0200" <4FB15FAE.60503@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> <4FB15FAE.60503@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:03:41 -0000 > On 05/14/2012 08:01 PM, Ned Freed wrote: > > I'm sorry, but I strongly disagree. It's absolutely vital that these > > specifications list all the known consequences of their use, *especially* > > those consequences that cannot be mitigated, so that people deploying > > this stuff can make informed choices about how to set things up, and indeed, > > whether or not to deploy it at all. > All of the documents from this WG are going to be read mostly by people > who are implementing some EAI thing or another, or are already > implementing. You're talking about people who might/will deploy, which > is a different audience. I'm doing nothing of the sort. There are *implementation* choices to be made here, including but not limited to which downgrade approach to use. This was actually the case even with one downgrade mechanism: Implementations choices don't stop at simply writing a module that performs a downgrade operation. There are a myriad of choices and tradeoffs as to how this interacts with the server, and the consequences of downgrade, including the non-mitigatable ones, are absolutely a part of that. But even that weren't the case, the minute you proposed an alternative downgrade mechanism, you bought in to all of this stuff. And with all due respect, I suggest you start dealing with that reality. Ned From arnt@gulbrandsen.priv.no Tue May 15 00:13:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B0221F8700 for ; Tue, 15 May 2012 00:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNF-kelMoiRH for ; Tue, 15 May 2012 00:13:44 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id DB16B21F8643 for ; Tue, 15 May 2012 00:13:43 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 449F5F8C54D; Tue, 15 May 2012 07:13:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337066020-11856-11855/10/5; Tue, 15 May 2012 07:13:40 +0000 Message-Id: <4FB2024A.4020809@gulbrandsen.priv.no> Date: Tue, 15 May 2012 09:14:18 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> <4FB15FAE.60503@gulbrandsen.priv.no> <01OFH4OZBTS40006TF@mauve.mrochek.com> In-Reply-To: <01OFH4OZBTS40006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 07:13:44 -0000 On 05/14/2012 10:56 PM, ned+ima@mrochek.com wrote: >> On 05/14/2012 08:01 PM, Ned Freed wrote: >>> I'm sorry, but I strongly disagree. It's absolutely vital that these >>> specifications list all the known consequences of their use, = *especially* >>> those consequences that cannot be mitigated, so that people deploying >>> this stuff can make informed choices about how to set things up, and = indeed, >>> whether or not to deploy it at all. >=20 >> All of the documents from this WG are going to be read mostly by = people >> who are implementing some EAI thing or another, or are already >> implementing. You're talking about people who might/will deploy, which >> is a different audience. >=20 > I'm doing nothing of the sort. There are *implementation* choices to be > made here, including but not limited to which downgrade approach to = use. Sorry, I guess I misunderstood. > This was actually the case even with one downgrade mechanism: Implement= ations > choices don't stop at simply writing a module that performs a downgrade > operation. There are a myriad of choices and tradeoffs as to how this = interacts > with the server, and the consequences of downgrade, including the > non-mitigatable ones, are absolutely a part of that. >=20 > But even that weren't the case, the minute you proposed an alternative > downgrade mechanism, you bought in to all of this stuff. And with all = due > respect, I suggest you start dealing with that reality. Do you have more concrete suggestions? Because I've thought about implementation discussion and advice and in the case of simpledowngrade I've even tried to write some, and failed. My foresight/insight is not good enough to offer anything useful. Arnt From johnl@iecc.com Tue May 15 07:26:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6751821F881A for ; Tue, 15 May 2012 07:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.105 X-Spam-Level: X-Spam-Status: No, score=-111.105 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1txSdtHd5SW for ; Tue, 15 May 2012 07:26:45 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 880BE21F8781 for ; Tue, 15 May 2012 07:26:45 -0700 (PDT) Received: (qmail 78498 invoked from network); 15 May 2012 14:26:44 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 May 2012 14:26:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fb267a4.xn--yuvv84g.k1205; i=johnl@user.iecc.com; bh=iUw1uQCJ8QQapfnAR9aTcRtUfBkFGXab1L1iHJlvJtY=; b=URbF0mNtYkYfu2T9x2FzpCGWE8++h+vPQYmFdH+W628qWFOO87AHSdOczOqY2YBWMgYw4A7TQb7lyZn99mR2L3ZgeEw2ezYfeXbRQaLzKv1s8dJJGqODN1FWT4r0Zu9Gtqccu7j4L4M3HybYMenHCZDSOPEJkvkoCEWPnVgNZIE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fb267a4.xn--yuvv84g.k1205; olt=johnl@user.iecc.com; bh=iUw1uQCJ8QQapfnAR9aTcRtUfBkFGXab1L1iHJlvJtY=; b=2kyl3y9C88SeES1GX/eaqCG5RJoT3gI8NLzk/+PBPT4k/jDCGY7PVhYIvZxS3nC1SQMWnvwjoy4MqhATaMOFZCCQ5oWg/gSw6kY2wkoRR5J/Rc30lL7vXb6XY4UUpKOMRgpkaeuq9Zs9VnsNk42sclBPMTsgXYVWycty9juj+Wk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 May 2012 14:26:21 -0000 Message-ID: <20120515142621.12541.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4FB2024A.4020809@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: arnt@gulbrandsen.priv.no Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:26:46 -0000 >> But even that weren't the case, the minute you proposed an alternative >> downgrade mechanism, you bought in to all of this stuff. And with all due >> respect, I suggest you start dealing with that reality. I have to agree with Arnt, all approaches to dealing with EAI mail to non-EAI recipients are horrible. If you do something different the horror changes but doesn't go away. If you reject EAI messages to non-EAI recipients, people will complain. If you deliver downgraded messages, they're not repliable and people will complain. If you hide them or deliver placeholders saying to upgrade your MUA, people will complain. If your MDAs notice EAI mail to non-EAI users and your concierge service goes out to upgrade the user's mail software, they'll complain that it's not a convenient time, my mail works fine, what are you doing, go away. I suppose some webmail systems will be able to upgrade their entire infrastructure, and only then globally set the EAI flag on all their incoming MTAs, but short of that, what do you suggest? R's, John From dotis@mail-abuse.org Tue May 15 11:12:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5021F875D for ; Tue, 15 May 2012 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyJdaXzZORu6 for ; Tue, 15 May 2012 11:12:56 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id C687821F875C for ; Tue, 15 May 2012 11:12:56 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 4D1C41740256 for ; Tue, 15 May 2012 18:12:56 +0000 (UTC) Message-ID: <4FB29CA7.1010201@mail-abuse.org> Date: Tue, 15 May 2012 11:12:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ima@ietf.org References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> In-Reply-To: <01OFGYL66S6E0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:12:57 -0000 On 5/14/12 11:01 AM, ned+ima@mrochek.com wrote: > > On 05/14/2012 05:29 PM, Ned Freed wrote: > >>> On 05/14/2012 05:02 PM, John C Klensin wrote: > >>>> I'm not even certain it is possible to get right, at least > >>>> while preserving UIDVALIDITY at all. > >>>> > >>> I think simpledowngrade gets it right, since it doesn't touch > >>> any non-EAI message at all. popimap-downgrade has a bit of a > >>> problem, since it depends on downgraded-* not being there for > >>> non-EAI input messages. > >> > >> It's more than a problem, it's a disaster in the making. > >> > > Perhaps. Dear Ned, One of the problems with EAI is many expect to leverage From-header-field domains to reference "authorization" records. IMHO, that approach has serious problems. Sources can still be authenticated via HELO/EHLO or StartTLS as a means to exclude phishing sources that otherwise place this type of email at extreme risk. The HELO/EHLO must be encoded using A-Labels so in that sense it is immune to change. As insurance against spoofing, conversion symmetry should be checked. > >> The problem is that you cannot make *any* assumptions about the > >> presence or absence of downgraded-* fields. [...] > > > OK for me — I don't. > > >> And simpledowngrade doesn't really do much better, because you > >> now end up with invalid addresses in the regular from and to > >> fields. Perhaps multiple From header identities might become useful. One with escaped local-part and A-label domain with the other as UTF-8 encoded that might be downgraded could represent a reasonable interim solution that simple downgrade still permits. > > IMO, that's the irreducible minimum problem. It's a nasty one, no > > question, but if we're going to have EAI, we have to pay that > > price. > > Not if you eliminate as many downgrade scenarios as possible. Malefactors are very good at looking like one of these cases. > >> This is why I continue to believe that all of this stuff is not > >> only going to generate support calls, they're going to be the > >> sort of calls where figuring out what happened requires real > >> expertise. > > > Yes. > > Any time a support call requires real expertise you're past front > line and even second line suport, and at that point costs can easily > go up by a factor of 10 or more. This is where use of EHLO and optional dual From header field encoding might result in fewer support issues. Those that occur could be explained in a FAQ in conjunction with a web based conversion tool. > >>> I think that perhaps the IMAP EAI document should say something > >>> like: > >>> > >>> A client which is updated to add UTF8=* should be aware that if > >>> it has cached any part of an internationalized message before > >>> it was extended with UTF8=* support, then that part may be some > >>> sort of compatibility rendering by the server. Clearing the > >>> cache when the upgrade is deployed may be advisable. > >> > >> And what about download-and-delete clients (which exist for both > >> POP and IMAP)? Yes, such clients won't suffer from UIDVALIDITY > >> issues, but the messages are essentially irreversibly corrupt at > >> this point. > > > Yes. A serious problem. > > > But I think it's not relevant to that document, since there's > > nothing to do about it. Fetchmail, for instance, can add EAI > > support, but there's nothing it can do about the mail it has > > deleted, so why bother to talk about that? > > I'm sorry, but I strongly disagree. It's absolutely vital that these > specifications list all the known consequences of their use, > *especially* those consequences that cannot be mitigated, so that > people deploying this stuff can make informed choices about how to > set things up, and indeed, whether or not to deploy it at all. > > I can almost accept the argument that these things can be covered in > some other document, but the problem with that is that both the > consequences and the mitigation methods are inextricably linked to > what downgrade approach is used. We see any example right here: > Downgrade-* headers have different issues than insertion of invalid > addresses. Ensure possible solutions are not prevented. Reluctance to implement dual identities within the From header field is understandable. It breaks things like DKIM. IMHO, EHLO in conjunction with ATPS type of authorization scheme provides a strategy that can adapt to the current email infrastructure as a reasonable means to mitigate risk. It seems most ESPs hope to avoid reliance on EHLOs which would then require a scheme like ATPS. ATPS can easily scale to cover any number of ESP services being used. This scheme can also supplant a need to preserve header fields as a means to mitigate risk. Regards, Douglas Otis From sm@resistor.net Tue May 15 11:40:04 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAD21F87E2 for ; Tue, 15 May 2012 11:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGSP-I8YtwAv for ; Tue, 15 May 2012 11:40:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6792B21F8836 for ; Tue, 15 May 2012 11:40:02 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4FIdsZk022657; Tue, 15 May 2012 11:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1337107200; i=@resistor.net; bh=h3nvKP7qw5UtlYADJn+NO5+2J1LiljSxMVXrHroBlnI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qUhJj0KwWXyKjOcx+weWuCqy0mkezYpCoo6YChai5FHMG/xOLna3e80Ao/6/pRzX5 JA3eBAi0DqjEX+VkirCYVKhwgtKjk/PgBaF+1IPzRG8lcAhbd85eE98A4pFolggUgF djjtY6UUiQXU/XVQq/fxcmDBXcZ36tFnVgpSNKzI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1337107200; i=@resistor.net; bh=h3nvKP7qw5UtlYADJn+NO5+2J1LiljSxMVXrHroBlnI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VbVmEKRkGRhuZIbcDipkE7IifKUoFW146cPTt89uFFyzCwPi84ZLnQ1Mb74oy5gs/ CuOQ4HOBDCPw9Y/jwJFsnYIOixO5bQ09dS8WmSUTitdRMCno+8lAZnZE1dBj9CfhRF A6i6IgGWxOsk9A/LtfOdYftXs6YsIalKnAMUrVB4= Message-Id: <6.2.5.6.2.20120515112655.0a691e18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 15 May 2012 11:39:13 -0700 To: Douglas Otis From: SM In-Reply-To: <4FB29CA7.1010201@mail-abuse.org> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> <4FB29CA7.1010201@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:40:04 -0000 Hi Doug, At 11:12 15-05-2012, Douglas Otis wrote: >One of the problems with EAI is many expect to leverage >From-header-field domains to reference "authorization" >records. IMHO, that approach has serious problems. Sources can >still be authenticated via HELO/EHLO or StartTLS as a means to >exclude phishing sources that otherwise place this type of email at >extreme risk. The HELO/EHLO must be encoded using A-Labels so in >that sense it is immune to change. As insurance against spoofing, >conversion symmetry should be checked. One of the problems is that there are problems outside the realm of EAI which are taken to EAI to resolve an issue outside EAI. >Ensure possible solutions are not prevented. Reluctance to >implement dual identities within the From header field is >understandable. It breaks things like DKIM. IMHO, EHLO in >conjunction with ATPS type of authorization scheme provides a >strategy that can adapt to the current email infrastructure as a >reasonable means to mitigate risk. It seems I am aware that someone else was, in my opinion, selectively quoting RFC 5321. :-) Regards, -sm From klensin@jck.com Tue May 15 14:21:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5621F8759 for ; Tue, 15 May 2012 14:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB4Iic7dpBdI for ; Tue, 15 May 2012 14:21:22 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 742D021F8703 for ; Tue, 15 May 2012 14:21:22 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUP5p-0008nn-Oe; Tue, 15 May 2012 17:15:41 -0400 Date: Tue, 15 May 2012 17:21:11 -0400 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <6B87EF95DE7CB363C17797A1@PST.JCK.COM> In-Reply-To: <20120515142621.12541.qmail@joyce.lan> References: <20120515142621.12541.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: arnt@gulbrandsen.priv.no Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:21:23 -0000 --On Tuesday, May 15, 2012 14:26 +0000 John Levine wrote: >>> But even that weren't the case, the minute you proposed an >>> alternative downgrade mechanism, you bought in to all of >>> this stuff. And with all due respect, I suggest you start >>> dealing with that reality. > > I have to agree with Arnt, all approaches to dealing with EAI > mail to non-EAI recipients are horrible. If you do something > different the horror changes but doesn't go away. I think we have consensus on that. Does anyone significantly disagree? If not, can we stop repeating it? > If you reject EAI messages to non-EAI recipients, people will > complain. If you deliver downgraded messages, they're not > repliable and people will complain. If you hide them or > deliver placeholders saying to upgrade your MUA, people will > complain. If your MDAs notice EAI mail to non-EAI users and > your concierge service goes out to upgrade the user's mail > software, they'll complain that it's not a convenient time, my > mail works fine, what are you doing, go away. Sure. Such is life. And I haven't seen any recent disagreement about this either. > I suppose some webmail systems will be able to upgrade their > entire infrastructure, and only then globally set the EAI flag > on all their incoming MTAs, but short of that, what do you > suggest? The bottom line is that we have two choices: (1) Deploy EAI, expect a certain amount of pain as people do (or don't), and live with it. (2) Decide that fully internationalized email isn't worth the trouble after all. We decided against (2) a rather long time ago. At the risk of sounding optimistic. I do believe that, in practice, this isn't going to turn out as badly as several of us have been predicting. A lot of the reason goes back, again, to discussions we had when the WG first started up (and earlier). If our hypotheses from that time are correct, it will basically not be feasible for an email provider in areas where internationalized addresses are important to avoid supporting them (MTA, IMAP/POP server, IMAP/POP client/ MUA/ Webmail, etc. In other areas, things will go more slowly, but the downgrade problem won't be much of an issue -- it will take uses with international correspondence very little time to figure out that, if getting messages through is important to them, they need to maintain ASCII return addresses and avoid pushing things with EAI features. That doesn't make the issues with, e.g., IMAP/POP downgrading any less real. But we probably aren't headed into the sort of global email interoperability disaster that the recent thread(s) could be interpreted to imply. john From Claudio.Allocchio@garr.it Tue May 15 14:39:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57811E8074 for ; Tue, 15 May 2012 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWwkJ15DS5VY for ; Tue, 15 May 2012 14:39:53 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 3605521F86C9 for ; Tue, 15 May 2012 14:39:53 -0700 (PDT) Received: from [10.0.0.59] (93-63-179-78.ip28.fastwebnet.it [93.63.179.78]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q4FLdYv5033476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 23:39:45 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q4FLdYv5033476 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=pdgK7Qn3q+D+OMljuFT5USvII7NCVpvm8JrW+T2Sb4gDnr5mU7Iq+q+BzRL3AQ/lw 4BJQoMm8rh78uvmKPJzrKQ+iKGpVfZkycxEE26dGKUggpu2zKFG4v49USCPARfeklgN 1R3p5oe05ZMkXcMzGoMW78uZ/n7TxHv26JKZDBc= Date: Tue, 15 May 2012 23:39:33 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: John C Klensin In-Reply-To: <6B87EF95DE7CB363C17797A1@PST.JCK.COM> Message-ID: References: <20120515142621.12541.qmail@joyce.lan> <6B87EF95DE7CB363C17797A1@PST.JCK.COM> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arnt@gulbrandsen.priv.no, John Levine , ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:39:54 -0000 On Tue, 15 May 2012, John C Klensin wrote: > > > --On Tuesday, May 15, 2012 14:26 +0000 John Levine > wrote: > >>>> But even that weren't the case, the minute you proposed an >>>> alternative downgrade mechanism, you bought in to all of >>>> this stuff. And with all due respect, I suggest you start >>>> dealing with that reality. >> >> I have to agree with Arnt, all approaches to dealing with EAI >> mail to non-EAI recipients are horrible. If you do something >> different the horror changes but doesn't go away. > > I think we have consensus on that. Does anyone significantly > disagree? If not, can we stop repeating it? correct, we all agree. >> If you reject EAI messages to non-EAI recipients, people will >> complain. If you deliver downgraded messages, they're not >> repliable and people will complain. If you hide them or >> deliver placeholders saying to upgrade your MUA, people will >> complain. If your MDAs notice EAI mail to non-EAI users and >> your concierge service goes out to upgrade the user's mail >> software, they'll complain that it's not a convenient time, my >> mail works fine, what are you doing, go away. > > Sure. Such is life. And I haven't seen any recent disagreement > about this either. another +1 >> I suppose some webmail systems will be able to upgrade their >> entire infrastructure, and only then globally set the EAI flag >> on all their incoming MTAs, but short of that, what do you >> suggest? > > The bottom line is that we have two choices: > > (1) Deploy EAI, expect a certain amount of pain as > people do (or don't), and live with it. > > (2) Decide that fully internationalized email isn't > worth the trouble after all. > > We decided against (2) a rather long time ago. otherwise we have just being playing games all the time, which is not true. > At the risk of sounding optimistic. I do believe that, in > practice, this isn't going to turn out as badly as several of us > have been predicting. A lot of the reason goes back, again, to > discussions we had when the WG first started up (and earlier). > If our hypotheses from that time are correct, it will basically > not be feasible for an email provider in areas where > internationalized addresses are important to avoid supporting > them (MTA, IMAP/POP server, IMAP/POP client/ MUA/ Webmail, etc. > In other areas, things will go more slowly, but the downgrade > problem won't be much of an issue -- it will take uses with > international correspondence very little time to figure out > that, if getting messages through is important to them, they > need to maintain ASCII return addresses and avoid pushing things > with EAI features. I can add that, being a sort of a dinosaur myself, I've personally being running an ASCII only MUA for a long time, even while I was receiving already lots of UTF8 content messages, and just eventually decided to upgrade my MUA to an ITF8 compliant one not because I was fed up if the strange things happening while opening UTF8 contente bodyparts, but because I wanted other features in the MUA which had nothing to do with UTF8 support, and the UTF8 support just came is as an accident. I guess a very similar scenario can happen with EAI downgrading, and that's not so dramatic. > That doesn't make the issues with, e.g., IMAP/POP downgrading > any less real. But we probably aren't headed into the sort of > global email interoperability disaster that the recent thread(s) > could be interpreted to imply. Indeed I'm not worried... and if this helps people in getting better MUAs installed, I'll be very happy. all the best! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From dotis@mail-abuse.org Tue May 15 15:09:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5189221F8668 for ; Tue, 15 May 2012 15:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS8nwzltWPCY for ; Tue, 15 May 2012 15:09:27 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4911E80C1 for ; Tue, 15 May 2012 15:09:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 9DF3B174029C; Tue, 15 May 2012 22:09:27 +0000 (UTC) Message-ID: <4FB2D417.20804@mail-abuse.org> Date: Tue, 15 May 2012 15:09:27 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: SM References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> <4FB29CA7.1010201@mail-abuse.org> <6.2.5.6.2.20120515112655.0a691e18@resistor.net> In-Reply-To: <6.2.5.6.2.20120515112655.0a691e18@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 22:09:28 -0000 On 5/15/12 11:39 AM, SM wrote: > Hi Doug, > At 11:12 15-05-2012, Douglas Otis wrote: >> One of the problems with EAI is many expect to leverage >> From-header-field domains to reference "authorization" records. >> IMHO, that approach has serious problems. Sources can still be >> authenticated via HELO/EHLO or StartTLS as a means to exclude >> phishing sources that otherwise place this type of email at extreme >> risk. The HELO/EHLO must be encoded using A-Labels so in that sense >> it is immune to change. As insurance against spoofing, conversion >> symmetry should be checked. > One of the problems is that there are problems outside the realm of > EAI which are taken to EAI to resolve an issue outside EAI. Dear SM, Agreed. Which is why leaving options open as simpledowngrade has done is likely the best approach. >> Ensure possible solutions are not prevented. Reluctance to implement >> dual identities within the From header field is understandable. It >> breaks things like DKIM. IMHO, EHLO in conjunction with ATPS type of >> authorization scheme provides a strategy that can adapt to the >> current email infrastructure as a reasonable means to mitigate risk. >> It seems > I am aware that someone else was, in my opinion, selectively quoting > RFC 5321. :-) I suspect those concerned about security need to carefully consider how EHLO/HELO SMTP parameters/StartTLS/etc might be used to secure email. While ESPs may not relish this challenge, it can be made to work in a fashion similar to that of early UUCP, which should not prove disruptive. I'll admit to making inferences from RFC5321 LDH DNS label restrictions and those in RFC6531. Whether or not RFC6531 had been written, UTF-8 email addresses have been in common use in Asia for several years, well ahead of written standards. It seems a shame the IETF did not suffer the transition pain years ago and use UTF-8 in DNS, now used in LLMNR and mDNS. The compression afforded makes visibility a PITA. Problems related to UTF-8 would have been resolved long ago within far less complex environments. In Asia it is fairly common to see UTF-8 headers and UTF-8 encoded sub-domains resolving hostnames. This is likely done to assist customers over the A-Label speed bump who are using poorly supported clients. In other words, don't assume that only valid A-labels resolve resource records. Regards, Douglas Otis From yaojk@cnnic.cn Tue May 15 19:58:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAFC11E80D7 for ; Tue, 15 May 2012 19:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.974 X-Spam-Level: X-Spam-Status: No, score=-99.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuCM-6ojtb-z for ; Tue, 15 May 2012 19:58:18 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id F10BC11E80C2 for ; Tue, 15 May 2012 19:58:15 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 16 May 2012 10:58:11 +0800 Message-ID: <8E0BDD2247D244C28190DDF680BE6DE4@LENOVO47E041CF> From: "Jiankang YAO" To: "Joseph Yee" , References: Date: Wed, 16 May 2012 10:58:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Preliminary High-level summary of EAI Meeting Conclusions atMay 14, 2012 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 02:58:19 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvc2VwaCBZZWUiIDxqeWVl QGFmaWxpYXMuaW5mbz4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTWF5IDE1 LCAyMDEyIDM6MDIgQU0NClN1YmplY3Q6IFtFQUldIFByZWxpbWluYXJ5IEhpZ2gtbGV2ZWwgc3Vt bWFyeSBvZiBFQUkgTWVldGluZyBDb25jbHVzaW9ucyBhdE1heSAxNCwgMjAxMg0KDQoNCj4gDQo+ IFJlZ2FyZGluZyBib3RoIGRvd25ncmFkZSBkcmFmdHMNCj4gDQo+IC0gTmVpdGhlciBkb3duZ3Jh ZGUgZHJhZnQgd2lsbCBub3QgdXBkYXRlIFJGQzUzMjIsIFJGQzM1MDENCj4gDQoNCnR5cG9zPyBv ciBjb25jbHVzaW9uPw0KDQpyZW1vdmUgbm90IGFuZCBjaGFuZ2UgaXQgYWJvdmUgdG8gDQoiTmVp dGhlciBkb3duZ3JhZGUgZHJhZnQgd2lsbCB1cGRhdGUgUkZDNTMyMiwgUkZDMzUwMSINCg0KDQpK aWFua2FuZyBZYW8NCg0K From joseph.yee@gmail.com Wed May 16 06:17:43 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34821F84FB for ; Wed, 16 May 2012 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8GNUYnG2DBM for ; Wed, 16 May 2012 06:17:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B591921F84D5 for ; Wed, 16 May 2012 06:17:42 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1271494obb.31 for ; Wed, 16 May 2012 06:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TEsxH+SdneED6hrVlY4RF55xq3rDjBFdoES7BbGrHe0=; b=hmevmobUJbWdRl/DvewX1SV+jgg76zhA+G1JUh8LImK7AvCrXg3QWbMCbSrsI+e9lN QNLzUm5TI8Fi0qFnB0fgiwzrtjE6ewHsjaeptnhdPay/wWBrSBkhQVScRPWbhC4t3lUt /5C57IrnI2+oOtb3kpS64CoQbSVZEkYavs8SrIwxzM4lOWORXAWWbYUu54utsAzARSrL rmGuSlt0aLztuaDzMsQXoleN5PnRD02LvZzJ88+xCT3xBSbi6rlC6KrL4nIm0F7g4XN6 gP0s00LqbjFwduo/3suGegORPeAoQPyrOrKdELAz65Atzs45c/lkeJy16HOrAi1NaOX+ 79Mw== MIME-Version: 1.0 Received: by 10.182.86.200 with SMTP id r8mr2771206obz.20.1337174262289; Wed, 16 May 2012 06:17:42 -0700 (PDT) Received: by 10.60.66.6 with HTTP; Wed, 16 May 2012 06:17:42 -0700 (PDT) In-Reply-To: <8E0BDD2247D244C28190DDF680BE6DE4@LENOVO47E041CF> References: <8E0BDD2247D244C28190DDF680BE6DE4@LENOVO47E041CF> Date: Wed, 16 May 2012 09:17:42 -0400 Message-ID: From: Joseph Yee To: Jiankang YAO Content-Type: text/plain; charset=UTF-8 Cc: ima@ietf.org Subject: Re: [EAI] Preliminary High-level summary of EAI Meeting Conclusions atMay 14, 2012 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:17:43 -0000 Thanks JianKang spotting the typo. - Neither downgrade draft will update RFC5322, RFC3501 Best Joseph On Tue, May 15, 2012 at 10:58 PM, Jiankang YAO wrote: > > ----- Original Message ----- > From: "Joseph Yee" > To: > Sent: Tuesday, May 15, 2012 3:02 AM > Subject: [EAI] Preliminary High-level summary of EAI Meeting Conclusions atMay 14, 2012 > > >> >> Regarding both downgrade drafts >> >> - Neither downgrade draft will not update RFC5322, RFC3501 >> > > typos? or conclusion? > > remove not and change it above to > "Neither downgrade draft will update RFC5322, RFC3501" > > > Jiankang Yao > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Wed May 16 14:52:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B0D21F8622 for ; Wed, 16 May 2012 14:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s11XNEivEKcP for ; Wed, 16 May 2012 14:52:31 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7EF21F85E4 for ; Wed, 16 May 2012 14:52:31 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUm3Z-000AhY-9E for ima@ietf.org; Wed, 16 May 2012 17:46:53 -0400 Date: Wed, 16 May 2012 17:52:24 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:52:32 -0000 Questions for the working group: (1) In reading the POP3 document, I notice that it is possible for a client to request and a server to process LANG without supporting UTF8. In the interest of simplification of variations and with the knowledge that very few languages can be completely supported by ASCII (and English is _not_ one of them), I suggest we consider requiring UTF8 capability if LANG is supported/requested. The logical alternative is for a server to have to support both UTF-8 and, e.g., transliterated / ASCII-mapped message forms for the various languages and, at least IMO, we really don't want to go there. UTF8 without LANG makes sense (elementary EAI/ SMTPUTF8 support for addresses and headers) but I suggest that LANG without UTF8 does not Note that adopting this change requires no change to the document other than a well-placed MUST and maybe a one sentence explanation. john From klensin@jck.com Wed May 16 15:11:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9559121F8670 for ; Wed, 16 May 2012 15:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKZ9-wwHH3d8 for ; Wed, 16 May 2012 15:11:49 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5545921F8622 for ; Wed, 16 May 2012 15:11:47 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUmME-000AjH-Fs for ima@ietf.org; Wed, 16 May 2012 18:06:10 -0400 Date: Wed, 16 May 2012 18:11:41 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <2F04F7925930F682E264E2CD@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] POP3 Spec and mail drop/ Mail store organization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:11:50 -0000 These are more or less nits but some of them are a fairly large ones (and the IMAP spec should be checked to be sure it doesn't suffer from any of the same problems). The second paragraph of Section 3.1 starts "Maildrops can natively store UTF-8 or be limited to ASCII.". Essentially the same statement appears at the beginning of paragraph 4 only it says "mail store" rather than "maildrop". Issues: (1) I'm not quite sure what the difference is between a "maildrop" and a "mail store". If there isn't one, the terminology should be harmonized. FWIW, RFC 1939 mentions "maildrop" in several places but never mentions a "mail store" (or "mailstore"). If there is a difference, the document should probably go to a little more effort to identify it. (2) The second paragraph of Section 3.1 starts "Maildrops can natively store UTF-8 or be limited to ASCII." As the inclusive statement that appears to be, it is flat wrong. First, if the maildrop uses Unicode, we don't care what is stored "natively", with various flavors of UTF-16 or UTF-32 being likely (and common). We don't even care if messages are stored in whatever Charset arrives over the wire (and, indeed, storage of messages in the form in which they were delivered may be common). We require that headers be either ASCII or UTF-8 on the wire, but that says almost nothing about either maildrop storage form or message content. What we care about is that, if the messages are delivered across a POP3 interfaces with UTF-8 enabled, the header material is in UTF-8 on the wire and on delivery to the POP client. (3) The language about UTF-8 maildrops and messages can easily be read to imply that a message that arrives with From: non-ASCII-string@example.com To: non-ASCII-string@example.net [...] Content-type: text/plain; charset="GB2312" Content-transfer-encoding: base64 [...] Is required to be decoded, converted to 'charset="UTF-8"', and then reencoded to base64. I don't think that is our intention: the conversion is burdensome and POP servers may not even have the capability for all possible Charsets. But, whether it is or is not, the spec should be absolutely clear about what our requirement actually is. john From klensin@jck.com Wed May 16 16:15:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFC69E8027 for ; Wed, 16 May 2012 16:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnuxM+R3kU9K for ; Wed, 16 May 2012 16:15:22 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 91E149E8022 for ; Wed, 16 May 2012 16:15:22 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUnLl-000AnM-L9 for ima@ietf.org; Wed, 16 May 2012 19:09:45 -0400 Date: Wed, 16 May 2012 19:15:17 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <3028478FA7960B651F0FE234@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] SimpleDowngrade and excising MIME parameters X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:15:23 -0000 The things one notices when trying to go through the documents looking for things that Monday's strategy requires adjusting... Section 2.2 says: "Any MIME parameter [RFC2045] (whether in the message header or a bodypart header) which cannot be presented as-is to the client is silently excised." I can't remember examples offhand (others might do better) but there is nothing in RFC 2045 that prevents a content [media] type (or header field that uses parameters) from having parameters whose meaning is interdependent. In part because of that, one really can't start dropping parameters (silently or not) without risking silly states unless the media type or header field type is understood. I believe that you should add to this section (and/or the Security Considerations one) a note that indicates that parameter-dropping might turn the associated field into nonsense or, perhaps even worse, reverse its meaning. john From klensin@jck.com Wed May 16 16:51:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE9721F8786 for ; Wed, 16 May 2012 16:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y42yK05AlTke for ; Wed, 16 May 2012 16:51:19 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5221F8773 for ; Wed, 16 May 2012 16:51:19 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUnuY-000Apd-Dv for ima@ietf.org; Wed, 16 May 2012 19:45:42 -0400 Date: Wed, 16 May 2012 19:51:13 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <9C5F2EF6DCEC35F3BDF79320@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Monday meeting and proposed text for IMAP, POP3, and the two downgrade docs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:51:20 -0000 Hi. I'm about to forward a note to the list that contains a first cut at the proposed text that we discussed on Monday along with some details about where it goes, etc. The note is long -- getting the text together required making a pass through all four documents and a lot of things turned up that need tuning (including some in separate notes I've posted already)-- but I'd appreciate if everyone, especially the authors/editors/pen-holders for the four documents would take the time to go through it. The notation "(Foo.2)" indicates it is the second comment/ proposed change for document "Foo" so, if people particularly want to look at comments for only one of the documents (or ignore one), that is your clue. I don't see any way to start writing up shepherd's/PROTO reports until the text and issues raised are resolved. thanks in advance, john From klensin@jck.com Wed May 16 16:52:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24F321F878A for ; Wed, 16 May 2012 16:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGRsqj9EStg9 for ; Wed, 16 May 2012 16:52:56 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A79E221F8786 for ; Wed, 16 May 2012 16:52:56 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUnw7-000Apl-ML for ima@ietf.org; Wed, 16 May 2012 19:47:19 -0400 Date: Wed, 16 May 2012 19:52:51 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:52:58 -0000 Hi. I propose the following changes to the IMAP [draft-ietf-eai-5738bis] and POP [draft-ietf-eai-5721bis] specs to reflect the discussion on Monday's Jabber-chat/ virtual meeting. These are subject to editorial discretion by the authors of that document, i.e., I'm trying to get the ideas outlined in my Monday note down but am not particularly attached to the suggested text. In particular, I've tried to reflect both my Monday note, the Jabber conversation, and a few other notes to the list within the last week. That has resulted in somewhat more words than even I would like. I've put them in on the assumption that it is easier to cut things that are unnecessary out than to add text; the next round of decisions are up to the WG and the authors/editors. An important point in the text below may not be obvious, but I think we should move away from talking about "downgraded" or "downconverted" messages. In the context of other mail protocols, both imply conversions, such as those of content-transfer-encodings, that preserve all information. I've used "variant message" and its synomyms/ variants(sic) below. I note that simpledowngrade uses "synthetic message", which would be equally satisfactory. Anyone who has a strong preference should speak up; I do hope we can settle on one or the other of the "variant" or "synthetic" alternatives rather than having to explain to the community and IESG why we are using both terms. I am prepared, given the text below, to explain why we don't get rid of the term "downgrade" entirely, but, if others disagree, please speak up (especially if you are willing to do the work). Specific changes: (IMAP.1) Introduction, second paragraph. Replace the paragraph by: Most of this specification assumes that the IMAP server will be operating in a fully internationalized environment, i.e., one in which all clients accessing the server will be able to accept non-ASCII message header fields and other information as specified in Section 3. At least during a transition period, that assumption will not be realistic for many environments; the issues involved are discussed in Section 7 below. (IMAP.2) New Section 7 (subsequent sections to be renumbered): 7. Dealing With Legacy Clients In most situations, it will be difficult or impossible for the implementer or operator of an IMAP (or POP) server to know whether all of the clients that might access it, or the associated mail store more generally, will be able to support the facilities defined in this document. In almost all cases, servers who conform to this specification will have to be prepared to deal with clients that do not enable the relevant capabilities. Unfortunately, there is no completely satisfactory way to do so other than for systems that wish to receive email that requires SMTPUTF8 capabilities to be sure that all components of those systems -- including IMAP and other clients selected by users -- are upgraded appropriately. Choices available to the server when a message that requires SMTPUTF8 is encountered and the client doesn't enable UTF-8 capability include hiding the problematic message(s) as outlined elsewhere in this specification, creating in band or out of band notifications or error messages, or somehow trying to create a variation on the message with the intention of providing useful information to that client about what has occurred. Such variant messages cannot be actual substitutes for the original message: it will rarely be possible to reply to (either at all or without loss of information), new header fields or specialized constructs for server-client communication may go beyond the requirements of, e.g., RFC 5322 and may consequently confuse some legacy mail user agents (including IMAP clients) or otherwise not provide the expected information to users. There are also tradeoffs in constructing variants of the original message between accepting complexity and additional computation costs in order to try to preserve as much information as possible (for example, in [draft-ietf-eai-popimap-downgrade]) and trying to minimize those costs while still providing useful information (for example, in [draft-ietf-eai-simpledowngrade]). Because such messages are really variations on the original ones, not really "downgraded" (ones although that terminology is often used for convenience), they inevitably have relationships to the original ones that the IMAP specification [RFC3501] did not anticipate. In particular, digital signatures computed over the original message will often not be applicable to the variant version and servers that may be accessed by the same user with different clients or methods (e.g., POP or webmail systems in addition to IMAP or IMAP clients with different capabilities) will need to exert extreme care to be sure that UIDVALIDITY behaves as the user would expect. Those issues may be especially sensitive if the server caches the variant message or computes and stores it when the message arrives with the intent of making either form available depending on client capabilities. The best (or "least bad") approach for any given environment will depend on local conditions, local assumptions about user behavior, the degree of control the server operator has over client usage and upgrading, the options that are actually available, and so on. It is impossible, at least at the time, to give good advice that will apply to all situations, or even particular profiles of situations, other than "upgrade legacy clients as soon as possible". (IMAP.3) Change the second paragraph of "Security Considerations" to read; Special considerations, some of them with security implications, occur if a server that conforms to this specification is accessed by a client that does not and in some more complex situations in which a given message is accessed by multiple clients that might use different protocols and/or support different capabilities. Those issues are discussed in Section 7 above. (POP.1) Most of the fourth paragraph of Section 3.1 ("Mail stores are either ASCII or native UTF-8, and clients either issue...") needs to disappear. Considering a separate note that I just sent (Subject: POP3 Spec and mail drop/ Mail store organization") and the instructions from the Jabber chat to the POP3 editors to get rid of excess "UTF8" parameters, this suggestion may need considerable rewriting, but, following the theme above, I suggest something like: Normal operation for UTF-8 maildrops will be for both servers and clients to support the extension discussed in this specification. Upgrading of both clients and servers is the only fully satisfactory way to support the capabilities offered by the "UTF8" extension and SMTPUTF8 mail more generally. Servers must, however, anticipate the possibility of a client attempting to access a message that requires this extension without having issued the "UTF8" command. There are no completely satisfactory responses for that case other than upgrading the client to support this specification. One solution, unsatisfactory because the user may be confused by being able to access the message through some means and not others, is that a server MAY choose to reject the command to retrieve the message as discussed in Section 5. Other alternatives, including the possibility of creating and delivering variant form of the message, are discussed in Section 7 of the IMAP UTF-8 specification [draft-ietf-eai-5738bis]. IMO, we can safely just lose the extended discussion of sizes, etc., in the existing paragraph. Part of the reason for shifting the terminology from "downgraded message" to "variant form of the message" is that no one sane would expect sizes, etc. to remain the same. If others think it is needed, I suggest adding as much of it as possible to the IMAP text (IMAP.2 above) and then moving the rest to the Security Considerations section of the POP3 doc (where there is now a back-reference pointing to 3.1, that reference would need to be corrected in any event). (POP.2) In Section 4, drop from "Mechanisms for 7-bit..." through the end of the paragraph and replace by: When the server is not in UTF-8 mode and the message requires that mode, requests to download the message MAY be rejected (as specified in the next section) or the various other alternatives outlined in Section 3.1 above and in Section 7 of the IMAP UTF-8 specification [draft-ietf-eai-5738bis], including creation and delivery of variations on the original message, MAY be considered. (POP.3) Section 5, last sentence. I recommend just dropping the parenthetical note, but the authors are welcome to propose another way to dance around the issue. Note that one of the goals of this set of suggestions is to eliminate all reference to the "downgrade" specs from the POP3 UTF-8 document and, ideally, get "downgrade" (and, worse, "downconvert") out of the POP3 UTF-8 document's vocabulary. (POPIMAP-Downgrade.1) "Security Considerations": Consider whether any of this material should be moved to either the new Section 7 or the Security Considerations section of the IMAP spec. I believe that any material that would apply to any "downgrading" transformation should be moved to the IMAP spec (the paragraph starting "Rewriting" is an obvious candidate) and referenced from here (and SimpleDowngrade) but, in the interest of getting these notes out without more delay, I haven't tried to do the work of identifying what, exactly should be moved. (SimpleDowngrade.1) Arnt, please review Section 1 Paragraph 4. "High-fidelity" might easily be read to imply "no information loss". My instinct (personal opinion) is that you just drop everything from ", since implementing" to the end of the paragraph, but other suggestions that support the "only horrible alternatives" and then talk about tradeoffs would be welcome. In particular (personal opinion again), if one considers providing sufficient explanations to enable customer support as part of the package, I think it is sensible to argue that your downgrading method is more trouble than implementing 5721bis and 5738bis (Note that your references should point to the new docs, not the earlier ones -- your note under "Open Issues is superfluous because the chance of this document being approved except in a package with 5721bis and 5738bis is exactly zero -- please let's not make it hard for the RFC Editor... or easy for them to make mistakes). (SimpleDowngrade.2) Note the interim meeting consensus that "invalid addresses" are to be avoided. I haven't noticed objections to that decision on the mailing list, so, unless I missed something important, I presume it will stand. (SimpleDowngrade.3) See the observations about message sizes in POP.1 above, think about whether this discussion should be abstracted somewhat and moved to the new Section 7 (or Security Considerations) of the IMAP spec, and dropped from here. Note that any variant/synthesized message is going to have this problem. (SimpleDowngrade.4) Given the on-list discussion about UIDs and UIDVALIDITY, do you think a Downgraded/synthesized message has the same UID value as the non-ASCII original or a different one? I think the text should be clear -- and then either moved to the IMAP spec or checked to be sure that popimap-downgrade is consistent. best regards, john From ned+ima@mrochek.com Wed May 16 17:52:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D606621F871A for ; Wed, 16 May 2012 17:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NiwsQ2cGsRn for ; Wed, 16 May 2012 17:52:06 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 511DC21F8715 for ; Wed, 16 May 2012 17:52:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFK58WL6BK001O7H@mauve.mrochek.com> for ima@ietf.org; Wed, 16 May 2012 17:52:01 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 16 May 2012 17:51:56 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFK58TF3NE0006TF@mauve.mrochek.com> Date: Wed, 16 May 2012 17:41:22 -0700 (PDT) In-reply-to: "Your message dated Wed, 16 May 2012 19:15:17 -0400" <3028478FA7960B651F0FE234@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <3028478FA7960B651F0FE234@PST.JCK.COM> To: John C Klensin Cc: ima@ietf.org Subject: Re: [EAI] SimpleDowngrade and excising MIME parameters X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 00:52:07 -0000 > The things one notices when trying to go through the documents > looking for things that Monday's strategy requires adjusting... > Section 2.2 says: > "Any MIME parameter [RFC2045] (whether in the message > header or a bodypart header) which cannot be presented > as-is to the client is silently excised." > I can't remember examples offhand (others might do better) but > there is nothing in RFC 2045 that prevents a content [media] > type (or header field that uses parameters) from having > parameters whose meaning is interdependent. Not only is is allowed, I believe it's been donee. For example, there are audio and video formats with multiple parameters specifying encoder settings, and I think there's one where a couple specify values and another specify the units for those values. OTOH, such parameters are unlikely to contain EAI material. > In part because of > that, one really can't start dropping parameters (silently or > not) without risking silly states unless the media type or > header field type is understood. In practice the far bigger risk is that of broken behavior from EAI filename parameters and clients that depend on those parameters for type identification. Given that we specify that utf-8 in in the subject field should be turned into encoded-words, and that RFC 2231 encoding is not significantly harder to do than that, I have a really hard time not understanding why that option wasn't chosen. > I believe that you should add to this section (and/or the > Security Considerations one) a note that indicates that > parameter-dropping might turn the associated field into nonsense > or, perhaps even worse, reverse its meaning. IMO the present security considerations section in this specification isn't even close to adequate, but this particular issue is way, way, way down the list. Ned From barryleiba.mailing.lists@gmail.com Wed May 16 18:56:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0B11E8091 for ; Wed, 16 May 2012 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HYkBdGgJfTe for ; Wed, 16 May 2012 18:56:56 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77A5F11E8073 for ; Wed, 16 May 2012 18:56:56 -0700 (PDT) Received: by lagv3 with SMTP id v3so1101887lag.31 for ; Wed, 16 May 2012 18:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RIf+tX4j7HmotmwoW0KJPRPgfs8fDWB9x9pFzhZS1YU=; b=ccinnSgAO5eInSgZt1nM1CHgwUH5iXKJSy0j4KnQkb/RQivPKSG/H2QDM2oIgRHzwR tzL3xEE/iXgViojGrPCSOwS5c7ah8WxgXoqA5cq4fFDheKwaFnzRw4j3D+0WtE8WcShG CTfj8F7UxvSrhr6PhE4Tlvw28/Aj4WrMfexH65s7spPGQtUY1Kh+juJ11ibqBWb9pNd5 c6BYQ+legMe1xTpoRnywU0ER3jj22c9mCY4POkcniE0hnoLQ46RFfTZRMSfHhlayO8lV kuimD8PrNMvtzR9sSt/dKZl9kxLP3yC3xyQolmDC01om8dlRsb0OgCDWupFWsM1weQfW a2Pg== MIME-Version: 1.0 Received: by 10.112.88.98 with SMTP id bf2mr2346460lbb.30.1337219815429; Wed, 16 May 2012 18:56:55 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Wed, 16 May 2012 18:56:55 -0700 (PDT) In-Reply-To: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> Date: Wed, 16 May 2012 21:56:55 -0400 X-Google-Sender-Auth: 8cHjsWfraSciuHOk28hq-yfMj5k Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 01:56:57 -0000 > UTF8 without LANG makes sense (elementary EAI/ SMTPUTF8 support > for addresses and headers) but I suggest that LANG without UTF8 > does not I don't see how they're related. The server's being able to put non-English on protocol messages, and having its messages translated into 17 languages, is entirely unrelated to its ability to handle UTF-8 in email address fields. On the other hand, I can't see anyone looking at this spec and saying, "Well, I can't/won't do the rest of it, but the LANG command looks interesting. I think I'll just implement that." Barry From klensin@jck.com Wed May 16 18:59:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742411E8091 for ; Wed, 16 May 2012 18:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 735SL+nK+XmE for ; Wed, 16 May 2012 18:59:33 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A654611E8073 for ; Wed, 16 May 2012 18:59:33 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUpub-000Axa-J3; Wed, 16 May 2012 21:53:53 -0400 Date: Wed, 16 May 2012 21:59:24 -0400 From: John C Klensin To: Douglas Otis , SM Message-ID: <108627B189317EDB5795F020@PST.JCK.COM> In-Reply-To: <4FB2D417.20804@mail-abuse.org> References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> <4FB29CA7.1010201@mail-abuse.org> <6.2.5.6.2.20120515112655.0a691e18@resistor.net> <4FB2D417.20804@mail-abuse.org> 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] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 01:59:34 -0000 Doug and SM, This note is written as co-chair in the hope of focusing the discussion... --On Tuesday, May 15, 2012 15:09 -0700 Douglas Otis wrote: >... >> One of the problems is that there are problems outside the >> realm of EAI which are taken to EAI to resolve an issue >> outside EAI. > Agreed. Which is why leaving options open as simpledowngrade > has done is likely the best approach. I don't know what SM's intent was, but mine is to say "not our problem, please take it elsewhere" every time an issue comes up that exists independent of the EAI work. I'm sorry you weren't able to make the interim meeting/ call on Monday, but I think there is reasonable agreement within the WG that the only way were are going to make progress toward getting things wrapped up and to the IETF is to avoid debates about "best approaches" where legacy POP or IMAP clients are accessing upgraded servers and trying to access SMTPUTF8 messages. We seem to be in agreement that all solutions to that problem other than upgrading the clients are bad enough that "best" is not meaningful. Please see and, if appropriate, comment on, the proposed new text I posted a short time ago. >>> Ensure possible solutions are not prevented. Reluctance to >>> implement dual identities within the From header field is >>> understandable. It breaks things like DKIM. IMHO, EHLO in >>> conjunction with ATPS type of authorization scheme provides >>> a strategy that can adapt to the current email >>> infrastructure as a reasonable means to mitigate risk. It >>> seems >> I am aware that someone else was, in my opinion, selectively >> quoting RFC 5321. :-) > I suspect those concerned about security need to carefully > consider how EHLO/HELO SMTP parameters/StartTLS/etc might be > used to secure email. While ESPs may not relish this > challenge, it can be made to work in a fashion similar to that > of early UUCP, which should not prove disruptive. Take it somewhere else. > I'll admit to making inferences from RFC5321 LDH DNS label > restrictions and those in RFC6531. Whether or not RFC6531 had > been written, UTF-8 email addresses have been in common use in > Asia for several years, well ahead of written standards. "In common use" is inconsistent with what the WG has been told by those of its active participants, several of whom who come from Asia and are familiar with (or operating) major email systems there. It is also inconsistent with recent inquiries I've received about EAI status from governments, ISP/ESPs, and others in South and Southeast Asia. But suppose you are correct? What would you have the WG do differently? Or at all, other than getting on with its work and being as little distracted by irrelevancies as possible. > It seems a shame the IETF did not suffer the transition pain > years ago and use UTF-8 in DNS, now used in LLMNR and mDNS. > The compression afforded makes visibility a PITA. Problems > related to UTF-8 would have been resolved long ago within far > less complex environments. In Asia it is fairly common to see > UTF-8 headers and UTF-8 encoded sub-domains resolving > hostnames. This is likely done to assist customers over the > A-Label speed bump who are using poorly supported clients. In > other words, don't assume that only valid A-labels resolve > resource records. The issue of non-IDNA encodings for domain names was dealt with at length in RFC 6055 and is not an EAI problem. Please take it elsewhere. Please consider this note a warning that the WG Co-chairs believe that the WG has consensus that it is important to move things along and at least rough consensus that delays and diversions into other topics are a threat to EAI-conforming deployment and encouragement for non-interoperable local solutions. As a result, my (and probably our) patience for off-topic postings -- including postings relevant to email or i18n issues but not specific to EAI -- is extremely limited. Please stop it. regards, john From barryleiba.mailing.lists@gmail.com Wed May 16 19:03:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2F811E809A for ; Wed, 16 May 2012 19:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-OKfJqTKY5F for ; Wed, 16 May 2012 19:03:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBDE11E8073 for ; Wed, 16 May 2012 19:03:49 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1118446lbb.31 for ; Wed, 16 May 2012 19:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JKGbJgl+jt/DYpa3XqL6eecXoaN3sC1ZKhtH3p36nf4=; b=vYouwTYwa1dxBGRJN/QvQOFjEAzswHOXpPNISFSIYriDKt7dfb1Kw8BqXyOdwl8YAx z9wSENcFMengnDqE42z+NQ8vJ4v8xqF41fTUNhys3N4VGjGOmQccv2t4k+9vCkRbdmdM PtWZGmr5cMs4H77Hc8o4BKilIoOyMx8X/6eMUPAPTEJ8HCdEF1Ytz13cRq29L7CVLe9e edLNVxC6eB75byn1P2ST3AzDyhGmFxK+DLUgg6j+qCBHogUVxeKfFjx78dA4EIwx7ELM M4Lf/6N4VWqco0wx/B0l74GGjaAPTfRYetupLSSBglHRdTU2mAhjTOMeg8EZQpzX/baZ xHtw== MIME-Version: 1.0 Received: by 10.152.132.233 with SMTP id ox9mr5323994lab.4.1337220228241; Wed, 16 May 2012 19:03:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Wed, 16 May 2012 19:03:48 -0700 (PDT) In-Reply-To: <2F04F7925930F682E264E2CD@PST.JCK.COM> References: <2F04F7925930F682E264E2CD@PST.JCK.COM> Date: Wed, 16 May 2012 22:03:48 -0400 X-Google-Sender-Auth: 1H5fYUo06SD_mJPoudFomlci8fQ Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] POP3 Spec and mail drop/ Mail store organization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:03:50 -0000 > (1) I'm not quite sure what the difference is between a > "maildrop" and a "mail store". =A0If there isn't one, the > terminology should be harmonized. =A0FWIW, RFC 1939 mentions > "maildrop" in several places but never mentions a "mail store" > (or "mailstore"). =A0If there is a difference, the document should > probably go to a little more effort to identify it. I think there is no difference. I think 1939 used "maildrop" because the model was the real post-office model: mail gets dropped there, and the POP client picks it up (and it no longer resides at the drop, but is now at the client). With UIDL and the proliferation of "leave on server" features, the maildrop has in many use cases given way to the mail store model, where the server provides long-term storage for the messages, even after they're picked up by (copied to, in this model) the client. I think we should stick with the terminology used in 1939.[1] Barry [1] Said with full realization that the extent to which that looks like a year might be telling us that we're trying to live in the past. From klensin@jck.com Wed May 16 19:26:58 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8E211E8073 for ; Wed, 16 May 2012 19:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoqrlzCEJllw for ; Wed, 16 May 2012 19:26:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7103521F85F6 for ; Wed, 16 May 2012 19:26:57 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUqLA-000AzJ-9l; Wed, 16 May 2012 22:21:20 -0400 Date: Wed, 16 May 2012 22:26:52 -0400 From: John C Klensin To: Ned Freed Message-ID: <0026968BF3169011BFD02799@PST.JCK.COM> In-Reply-To: <01OFK58TF3NE0006TF@mauve.mrochek.com> References: <3028478FA7960B651F0FE234@PST.JCK.COM> <01OFK58TF3NE0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] SimpleDowngrade and excising MIME parameters X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:26:58 -0000 --On Wednesday, May 16, 2012 17:41 -0700 Ned Freed wrote: >> The things one notices when trying to go through the documents >> looking for things that Monday's strategy requires >> adjusting... > >> Section 2.2 says: >> "Any MIME parameter [RFC2045] (whether in the message >> header or a bodypart header) which cannot be presented >> as-is to the client is silently excised." > >> I can't remember examples offhand (others might do better) but >> there is nothing in RFC 2045 that prevents a content [media] >> type (or header field that uses parameters) from having >> parameters whose meaning is interdependent. > > Not only is is allowed, I believe it's been donee. For > example, there are audio and video formats with multiple > parameters specifying encoder settings, and I think there's > one where a couple specify values and another specify the units > for those values. > > OTOH, such parameters are unlikely to contain EAI material. Yes, but my lack of conviction that it was an actual, rather than theoretical/potential problem was related precisely to the question of whether such parameters were likely to end up with non-ASCII values. The examples I could think of or make up in which dropping a parameter would make a major difference all used either digits, keywords from a reserved (and ASCII) list, or something similar. But the future is harder to predict. >> In part because of >> that, one really can't start dropping parameters (silently or >> not) without risking silly states unless the media type or >> header field type is understood. > > In practice the far bigger risk is that of broken behavior > from EAI filename parameters and clients that depend on those > parameters for type identification. Yes, but I don't see any way to solve that problem other than possibly warning about it. > > Given that we specify that utf-8 in in the subject field > should be turned into encoded-words, and that RFC 2231 > encoding is not significantly harder to do than that, I have a > really hard time not understanding why that option wasn't > chosen. Arnt can defend his own design choices but I can give two possible answers from my own perspective: (i) To the extent to which the plan is "simple" and "covering most of the obvious cases while minimizing effort", one has to draw the line somewhere. Whether it should be drawn after "Subject:" and before parameter values, or after parameter values is a very subjective judgment call. (ii) The encoded work specs are very explicit about being able to encode Subject fields, quite independent of EAI. If memory serves, they don't make a general rule about parameter values. That could make their use in parameter values as part of EAI "downgrading" a little dicey. We are doing lots of dicey things already, but the tradeoffs on this one are not completely obvious to me. >> I believe that you should add to this section (and/or the >> Security Considerations one) a note that indicates that >> parameter-dropping might turn the associated field into >> nonsense or, perhaps even worse, reverse its meaning. > > IMO the present security considerations section in this > specification isn't even close to adequate, but this > particular issue is way, way, way down the list. That is fair. My belief at this stage is that we should divide Security Considerations material into two categories. Material that would apply generically to "simple downgrade", "original downgrade", or any other approach to synthesize a surrogate message that is more or less conformant to 5322 ought to be phrased as generically as possible and stuffed into the new Section 7 of the IMAP spec. Anything else should be as explicit as need in the individual downgrade docs. I personally wouldn't mind seeing one or the other location go a little further than my draft text and essentially say "if one of these surrogate messages is generated, the user is screwed and the only specific security issues are what form that activity takes", but I couldn't figure out a nice enough way to say that. best, john From barryleiba.mailing.lists@gmail.com Wed May 16 19:42:08 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C2021F86CB for ; Wed, 16 May 2012 19:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNYILWAys2wH for ; Wed, 16 May 2012 19:42:07 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42AFA21F8682 for ; Wed, 16 May 2012 19:42:07 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1135658lbb.31 for ; Wed, 16 May 2012 19:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3ATxkLRTfCEXEpIGDe5gIc3b2udNJRYTrAfnkGdkYE0=; b=DgFoOZrpOlE6SS0y+Raq6Uqld7sVNWv8Qr01NnLrze+eHHWq7i3/CEzHWqpazO0dr0 uwlZz3XNaL/tbtu2CCPDLFNIyN//XG9hyi1OGGKY4pSqvzr4y9QwmfCcNAgLCdtLKqQn ye+BjqR8zz8rW8eXP/fKe5Vqsr6tS6PRCvKEz1iCk9WehfV7I0xnI0QLIYrY/cpDn0bN e/Xnn06zuMfOoa63CyppCj3sObGDs4YmcMRKpghn/BbFeR4xG6cw0atwjR5tlw8v7nFv Dk5LK9xS8rv9UoE+O5y+cj3u8YgAp6pdKpY5fRuKPGgfp4QtOw95q19MBhyFtM+RqrTC v40w== MIME-Version: 1.0 Received: by 10.112.37.71 with SMTP id w7mr2424228lbj.2.1337222526204; Wed, 16 May 2012 19:42:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Wed, 16 May 2012 19:42:05 -0700 (PDT) In-Reply-To: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> References: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> Date: Wed, 16 May 2012 22:42:05 -0400 X-Google-Sender-Auth: nYqX8MCY0EXcR67-uaZWGXmvp0A Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:42:08 -0000 I like the proposal in general, and don't have major comments about it. Lots of text tweaking and error corrections, of course, but that all needs to wait until text is folded into the actual documents, and the document editors have had their ways with it. Just one specific comment: > (SimpleDowngrade.4) Given the on-list discussion about UIDs and > UIDVALIDITY, do you think a Downgraded/synthesized message has > the same UID value as the non-ASCII original or a different > one? =A0I think the text should be clear -- and then either moved > to the IMAP spec or checked to be sure that popimap-downgrade > is consistent. This is, of course, a very tricky point, but I'll note one thing: It's generally assumed that all clients see the same UIDVALIDITY for a mailbox, and the same UIDs for each message... but I don't see anything that necessitates that, since every client deals with UIDs independently of all others. I suggest, then, that we don't have to worry about UIDVALIDITY, and that servers that do this message substitution simply present the same UID for a given message, regardless of whether that message is sent to the client in UTF-8 or not. My (compliant) client will see a different message with that UID than your non-compliant one will, but they will conceptually refer to the same message, and will, therefore, have substantially the same content. The failure mode of this approach is that when the user upgrades your client to the new, newly compliant version, and that version uses the same local message cache as the earlier version, it retains the "synthetic" message, and doesn't know that it needs to refresh its cache. A clean way for an updated client to know that a cached message has been synthesized would be a good way out of this, so maybe we should consider that (an IMAP flag?). Barry From klensin@jck.com Wed May 16 20:25:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F911E808F for ; Wed, 16 May 2012 20:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLIfNmyFGdcC for ; Wed, 16 May 2012 20:25:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CE7E511E8089 for ; Wed, 16 May 2012 20:25:19 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SUrFd-000B2U-9W; Wed, 16 May 2012 23:19:41 -0400 Date: Wed, 16 May 2012 23:25:13 -0400 From: John C Klensin To: Barry Leiba Message-ID: <850C102FE438B9DF074D9C7C@PST.JCK.COM> In-Reply-To: References: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 03:25:20 -0000 --On Wednesday, May 16, 2012 22:42 -0400 Barry Leiba wrote: > I like the proposal in general, and don't have major comments > about it. Lots of text tweaking and error corrections, of > course, but that all needs to wait until text is folded into > the actual documents, and the document editors have had their > ways with it. >=20 > Just one specific comment: >=20 >> (SimpleDowngrade.4) Given the on-list discussion about UIDs >> and UIDVALIDITY, do you think a Downgraded/synthesized >> message has the same UID value as the non-ASCII original or a >> different one? =C2=A0I think the text should be clear -- and = then >> either moved to the IMAP spec or checked to be sure that >> popimap-downgrade is consistent. >=20 > This is, of course, a very tricky point, but I'll note one > thing: It's generally assumed that all clients see the same > UIDVALIDITY for a mailbox, and the same UIDs for each > message... but I don't see anything that necessitates that, > since every client deals with UIDs independently of all > others. I suggest, then, that we don't have to worry about > UIDVALIDITY, and that servers that do this message > substitution simply present the same UID for a given message, > regardless of whether that message is sent to the client in > UTF-8 or not. My (compliant) client will see a different > message with that UID than your non-compliant one will, but > they will conceptually refer to the same message, and will, > therefore, have substantially the same content. This works for me, but my primary concern is that we not leave the issue up in the air. We should, IMO, pick something and be consistent about it or state clearly that we have no intention of doing so. > The failure mode of this approach is that when the user > upgrades your client to the new, newly compliant version, and > that version uses the same local message cache as the earlier > version, it retains the "synthetic" message, and doesn't know > that it needs to refresh its cache. A clean way for an > updated client to know that a cached message has been > synthesized would be a good way out of this, so maybe we > should consider that (an IMAP flag?). As usual, I'm reluctant to do anything in EAI that has non-specific implications. An IMAP flag ("synthesized_message"?) would certainly do the job, but so would something as simple as either recommending that client upgrades treat UIDVALIDITY as false and rebuild the cache on the assumption that _some_ message-or-flag-affecting capability, storage format, etc. might have changed. As a trivial example that is not EAI-specific (but part of which came up an earlier rant), suppose that non-EAI client version 1.98 tries to store text/plain information whenever possible in ISO-2022-JP (or 8859-1) even if that means verifying that there are no signatures present and converting from whatever form arrives even if it UTF-8. I can think of several practical reasons why one might want to do that. Now suppose that client version 2.0, in recognition of other changes in the world and preparatory for version 2.1 which has full EAI support, decides to bite the bullet and store everything locally in Unicode form (UTF-16BE if that is the local OS preference) and maybe to do a little less converting. I think it would want to resynchronize and reevaluate the cache, not try to convert old messages to reconstruct the guessed-at original form. Right? But I'd defer to the IMAP experts on the list. john From arnt@gulbrandsen.priv.no Wed May 16 23:40:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3011E8099 for ; Wed, 16 May 2012 23:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr+aP-RNvI8d for ; Wed, 16 May 2012 23:40:05 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8418F11E8095 for ; Wed, 16 May 2012 23:40:05 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3D14EF8C72D; Thu, 17 May 2012 06:40:03 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337236802-11856-11855/11/2; Thu, 17 May 2012 06:40:02 +0000 Message-Id: <4FB49D6C.4000702@gulbrandsen.priv.no> Date: Thu, 17 May 2012 08:40:44 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <3028478FA7960B651F0FE234@PST.JCK.COM> <01OFK58TF3NE0006TF@mauve.mrochek.com> <0026968BF3169011BFD02799@PST.JCK.COM> In-Reply-To: <0026968BF3169011BFD02799@PST.JCK.COM> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] SimpleDowngrade and excising MIME parameters X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 06:40:06 -0000 John answers Ned: >> > Given that we specify that utf-8 in in the subject field >> > should be turned into encoded-words, and that RFC 2231 >> > encoding is not significantly harder to do than that, I have a >> > really hard time not understanding why that option wasn't >> > chosen.=20 > Arnt can defend his own design choices That's the one I feel least sure of. The state of 2231 parsing in clients isn't too good, at least it wasn't when I last needed to look at it. I feel that asking servers to learn how to generate 2231 when clients aren't that good at parsing is a bit too much of a detour. But it's close. I wouldn't mind saying this in the document =97 should I do that? Arnt From arnt@gulbrandsen.priv.no Thu May 17 00:25:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ABE21F8547 for ; Thu, 17 May 2012 00:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR4SrFCmg38Q for ; Thu, 17 May 2012 00:25:59 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C67C921F8546 for ; Thu, 17 May 2012 00:25:58 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 10CD9FA09BD; Thu, 17 May 2012 07:25:56 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337239555-11856-11855/11/3; Thu, 17 May 2012 07:25:55 +0000 Message-Id: <4FB4A82D.2020709@gulbrandsen.priv.no> Date: Thu, 17 May 2012 09:26:37 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <3028478FA7960B651F0FE234@PST.JCK.COM> In-Reply-To: <3028478FA7960B651F0FE234@PST.JCK.COM> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] SimpleDowngrade and excising MIME parameters X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 07:25:59 -0000 On 05/17/2012 01:15 AM, John C Klensin wrote: > I believe that you should add to this section (and/or the > Security Considerations one) a note that indicates that > parameter-dropping might turn the associated field into nonsense > or, perhaps even worse, reverse its meaning. The same applies to header fields. The only example I've been able to find was more semantic than syntactic: File sets. "See appended files", before.jpg and after.jpg. I'll try to wordsmith something suitable. Arnt From dotis@mail-abuse.org Thu May 17 15:17:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C0821F8809 for ; Thu, 17 May 2012 15:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+wVeE24hQ0E for ; Thu, 17 May 2012 15:17:15 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4821F8804 for ; Thu, 17 May 2012 15:17:14 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 7CE6D17400F4; Thu, 17 May 2012 22:17:14 +0000 (UTC) Message-ID: <4FB578EA.7070205@mail-abuse.org> Date: Thu, 17 May 2012 15:17:14 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John C Klensin References: <4FA631ED.5020401@gulbrandsen.priv.no> <20120507.145000.191383992.fujiwara@jprs.co.jp> <4FA76F8D.7000101@gulbrandsen.priv.no> <20120507.201752.52172531.fujiwara@jprs.co.jp> <4FB110D7.3030305@isode.com> <5BD49A7EBD875AFA169223A4@PST.JCK.COM> <4FB12058.7040200@gulbrandsen.priv.no> <01OFGT94FDHK0006TF@mauve.mrochek.com> <4FB13805.5070708@gulbrandsen.priv.no> <01OFGYL66S6E0006TF@mauve.mrochek.com> <4FB29CA7.1010201@mail-abuse.org> <6.2.5.6.2.20120515112655.0a691e18@resistor.net> <4FB2D417.20804@mail-abuse.org> <108627B189317EDB5795F020@PST.JCK.COM> In-Reply-To: <108627B189317EDB5795F020@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Status summary on SimpleDowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 22:17:15 -0000 On 5/16/12 6:59 PM, John C Klensin wrote: > Doug and SM, > > This note is written as co-chair in the hope of focusing the > discussion... > > --On Tuesday, May 15, 2012 15:09 -0700 Douglas Otis > wrote: > >> ... >>> One of the problems is that there are problems outside the >>> realm of EAI which are taken to EAI to resolve an issue >>> outside EAI. >>> >> Agreed. Which is why leaving options open as simpledowngrade >> has done is likely the best approach. > I don't know what SM's intent was, but mine is to say "not our > problem, please take it elsewhere" every time an issue comes up > that exists independent of the EAI work. > > I'm sorry you weren't able to make the interim meeting/ call on > Monday, but I think there is reasonable agreement within the WG > that the only way were are going to make progress toward getting > things wrapped up and to the IETF is to avoid debates about > "best approaches" where legacy POP or IMAP clients are accessing > upgraded servers and trying to access SMTPUTF8 messages. We > seem to be in agreement that all solutions to that problem other > than upgrading the clients are bad enough that "best" is not > meaningful. Please see and, if appropriate, comment on, the > proposed new text I posted a short time ago. Dear John, I'll attempt to be more clear. The drafts look good and on track. Good job. An approach offering a visible and functional incentive to upgrade is an excellent choice. It seems other related areas need to consider the impact UTF-8 or lack of support will have on security is not be mitigated without changes made elsewhere. To be clear, this was responding somewhat holistically to criticisms of the approach, and that there is no ideal solution. In other words, I too think this has found general agreement. >> I'll admit to making inferences from RFC5321 LDH DNS label >> restrictions and those in RFC6531. Whether or not RFC6531 had >> been written, UTF-8 email addresses have been in common use in >> Asia for several years, well ahead of written standards. > "In common use" is inconsistent with what the WG has been told > by those of its active participants, several of whom who come > from Asia and are familiar with (or operating) major email > systems there. It is also inconsistent with recent inquiries > I've received about EAI status from governments, ISP/ESPs, and > others in South and Southeast Asia. > > But suppose you are correct? What would you have the WG do > differently? Or at all, other than getting on with its work and > being as little distracted by irrelevancies as possible. The term "common" suggested occurrences too frequent to justify filtering, and not to imply a predominate number of UTF-8 local-parts et al, sans negotiation and not necessarily pertaining to ISP/ESP or government agencies, but regionally isolated to specific interests. This was to support rapidly moving this effort forward as there is a clear desire to use real names when sussing out the message author and where dependence on display names is not safe. > Please consider this note a warning that the WG Co-chairs believe that > the WG has consensus that it is important to move things along and at > least rough consensus that delays and diversions into other topics are > a threat to EAI-conforming deployment and encouragement for > non-interoperable local solutions. As a result, my (and probably our) > patience for off-topic postings -- including postings relevant to > email or i18n issues but not specific to EAI -- is extremely limited. Most concerns have been addressed in the specifications and represent excellent work. Although already discussed in the draft, some have suggested UTF-8 addresses only require simple A-Label conversions. From a security stand point, this conversion must also ensure invalid code points are omitted. Prior conversion routines may not offer this assurance. It seems the draft might recommend something to help resolve this concern. Perhaps symmetry checks? References to rfc5890 by follow-on documents is lacking. While it might seem redundant, email can be stored for prolonged periods. For example, there have been changes to UTF-8 domain encoding. It seems such changes may impact UTF-8 domain handling. As such, this deserves a reference to better highlight this aspect of interchange compatibility requirements. Regards, Douglas Otis From yaojk@cnnic.cn Fri May 18 01:59:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAB521F856D for ; Fri, 18 May 2012 01:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.4 X-Spam-Level: X-Spam-Status: No, score=-100.4 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bPwTBiidvKz for ; Fri, 18 May 2012 01:59:19 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3E97121F8634 for ; Fri, 18 May 2012 01:59:15 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 18 May 2012 16:59:11 +0800 Message-ID: <8468C2ED7812451D8A320A386E0F9652@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> Date: Fri, 18 May 2012 16:59:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 08:59:20 -0000 dGhhbmtzIHRvIEpvaG4ncyBoYXJkIHdvcmsgYW5kIGtpbmQgcHJvcG9zZWQgY2hhbmdlcy4NCg0K SWYgdGhlIGZvbGxvd2luZyBjb21tZW50cyBvciBpc3N1c2VzIGFyZSBhZGRyZXNzZWQgaW4gdGhl IG5leHQgdmVyc2lvbiBvZiA0IGRvY3VtZW50cywgaXMgdGhlcmUgYW55IG90aGVyIGlzc3VzZSB3 aGljaCB3aWxsIA0Kbm90IGJlIGFkZHJlc3NlZD8NCg0KSWYgdGhlcmUgaXMgbm9uZSwgSSB0aGlu ayB0aGF0IGl0IHdpbGwgYmUgYSBiaWcgc3RlcCBmb3J3YXJkIHdoZW4gNCBuZXcgdmVyc2lvbiBv ZiBkb2N1bWVucyBhcHBlYXIuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2huIEMgS2xlbnNpbiIgPGtsZW5zaW5AamNrLmNvbT4N ClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIE1heSAxNywgMjAxMiA3OjUyIEFN DQpTdWJqZWN0OiBbRUFJXSBQcm9wb3NlZCByZXZpc2VkIHRleHQgZm9yIElNQVAgKDU3MzhiaXMp IGFuZCByZWxhdGVkIGRvY3VtZW50cw0KDQoNCj4gSGkuDQo+IA0KPiBJIHByb3Bvc2UgdGhlIGZv bGxvd2luZyBjaGFuZ2VzIHRvIHRoZSBJTUFQDQo+IFtkcmFmdC1pZXRmLWVhaS01NzM4YmlzXSBh bmQgUE9QIFtkcmFmdC1pZXRmLWVhaS01NzIxYmlzXSBzcGVjcw0KPiB0byByZWZsZWN0IHRoZSBk aXNjdXNzaW9uIG9uIE1vbmRheSdzIEphYmJlci1jaGF0LyB2aXJ0dWFsDQo+IG1lZXRpbmcuICBU aGVzZSBhcmUgc3ViamVjdCB0byBlZGl0b3JpYWwgZGlzY3JldGlvbiBieSB0aGUNCj4gYXV0aG9y cyBvZiB0aGF0IGRvY3VtZW50LCBpLmUuLCBJJ20gdHJ5aW5nIHRvIGdldCB0aGUgaWRlYXMNCj4g b3V0bGluZWQgaW4gbXkgTW9uZGF5IG5vdGUgZG93biBidXQgYW0gbm90IHBhcnRpY3VsYXJseQ0K PiBhdHRhY2hlZCB0byB0aGUgc3VnZ2VzdGVkIHRleHQuICBJbiBwYXJ0aWN1bGFyLCBJJ3ZlIHRy aWVkIHRvDQo+IHJlZmxlY3QgYm90aCBteSBNb25kYXkgbm90ZSwgdGhlIEphYmJlciBjb252ZXJz YXRpb24sIGFuZCBhIGZldw0KPiBvdGhlciBub3RlcyB0byB0aGUgbGlzdCB3aXRoaW4gdGhlIGxh c3Qgd2Vlay4gIFRoYXQgaGFzDQo+IHJlc3VsdGVkIGluIHNvbWV3aGF0IG1vcmUgd29yZHMgdGhh biBldmVuIEkgd291bGQgbGlrZS4gSSd2ZQ0KPiBwdXQgdGhlbSBpbiBvbiB0aGUgYXNzdW1wdGlv biB0aGF0IGl0IGlzIGVhc2llciB0byBjdXQgdGhpbmdzDQo+IHRoYXQgYXJlIHVubmVjZXNzYXJ5 IG91dCB0aGFuIHRvIGFkZCB0ZXh0OyB0aGUgbmV4dCByb3VuZCBvZg0KPiBkZWNpc2lvbnMgYXJl IHVwIHRvIHRoZSBXRyBhbmQgdGhlIGF1dGhvcnMvZWRpdG9ycy4NCj4gDQo+IEFuIGltcG9ydGFu dCBwb2ludCBpbiB0aGUgdGV4dCBiZWxvdyBtYXkgbm90IGJlIG9idmlvdXMsIGJ1dCBJDQo+IHRo aW5rIHdlIHNob3VsZCBtb3ZlIGF3YXkgZnJvbSB0YWxraW5nIGFib3V0ICJkb3duZ3JhZGVkIiBv cg0KPiAiZG93bmNvbnZlcnRlZCIgbWVzc2FnZXMuICBJbiB0aGUgY29udGV4dCBvZiBvdGhlciBt YWlsDQo+IHByb3RvY29scywgYm90aCBpbXBseSBjb252ZXJzaW9ucywgc3VjaCBhcyB0aG9zZSBv Zg0KPiBjb250ZW50LXRyYW5zZmVyLWVuY29kaW5ncywgdGhhdCBwcmVzZXJ2ZSBhbGwgaW5mb3Jt YXRpb24uDQo+IEkndmUgdXNlZCAidmFyaWFudCBtZXNzYWdlIiBhbmQgaXRzIHN5bm9teW1zLyB2 YXJpYW50cyhzaWMpDQo+IGJlbG93LiBJIG5vdGUgdGhhdCBzaW1wbGVkb3duZ3JhZGUgdXNlcyAi c3ludGhldGljIG1lc3NhZ2UiLA0KPiB3aGljaCB3b3VsZCBiZSBlcXVhbGx5IHNhdGlzZmFjdG9y eS4gICBBbnlvbmUgd2hvIGhhcyBhIHN0cm9uZw0KPiBwcmVmZXJlbmNlIHNob3VsZCBzcGVhayB1 cDsgSSBkbyBob3BlIHdlIGNhbiBzZXR0bGUgb24gb25lIG9yDQo+IHRoZSBvdGhlciBvZiB0aGUg InZhcmlhbnQiIG9yICJzeW50aGV0aWMiIGFsdGVybmF0aXZlcyByYXRoZXINCj4gdGhhbiBoYXZp bmcgdG8gZXhwbGFpbiB0byB0aGUgY29tbXVuaXR5IGFuZCBJRVNHIHdoeSB3ZSBhcmUNCj4gdXNp bmcgYm90aCB0ZXJtcy4NCj4gDQo+IEkgYW0gcHJlcGFyZWQsIGdpdmVuIHRoZSB0ZXh0IGJlbG93 LCB0byBleHBsYWluIHdoeSB3ZSBkb24ndA0KPiBnZXQgcmlkIG9mIHRoZSB0ZXJtICJkb3duZ3Jh ZGUiIGVudGlyZWx5LCBidXQsIGlmIG90aGVycw0KPiBkaXNhZ3JlZSwgcGxlYXNlIHNwZWFrIHVw IChlc3BlY2lhbGx5IGlmIHlvdSBhcmUgd2lsbGluZyB0byBkbw0KPiB0aGUgd29yaykuDQo+IA0K PiBTcGVjaWZpYyBjaGFuZ2VzOg0KPiANCj4gKElNQVAuMSkgSW50cm9kdWN0aW9uLCBzZWNvbmQg cGFyYWdyYXBoLiAgUmVwbGFjZSB0aGUgcGFyYWdyYXBoDQo+IGJ5Og0KPiANCj4gTW9zdCBvZiB0 aGlzIHNwZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IHRoZSBJTUFQIHNlcnZlcg0KPiB3aWxsIGJl IG9wZXJhdGluZyBpbiBhIGZ1bGx5IGludGVybmF0aW9uYWxpemVkIGVudmlyb25tZW50LA0KPiBp LmUuLCBvbmUgaW4gd2hpY2ggYWxsIGNsaWVudHMgYWNjZXNzaW5nIHRoZSBzZXJ2ZXIgd2lsbCBi ZQ0KPiBhYmxlIHRvIGFjY2VwdCBub24tQVNDSUkgbWVzc2FnZSBoZWFkZXIgZmllbGRzIGFuZCBv dGhlcg0KPiBpbmZvcm1hdGlvbiBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAzLiAgQXQgbGVhc3Qg ZHVyaW5nIGENCj4gdHJhbnNpdGlvbiBwZXJpb2QsIHRoYXQgYXNzdW1wdGlvbiB3aWxsIG5vdCBi ZSByZWFsaXN0aWMNCj4gZm9yIG1hbnkgZW52aXJvbm1lbnRzOyB0aGUgaXNzdWVzIGludm9sdmVk IGFyZSBkaXNjdXNzZWQgaW4NCj4gU2VjdGlvbiA3IGJlbG93Lg0KPiANCj4gKElNQVAuMikgTmV3 IFNlY3Rpb24gNyAoc3Vic2VxdWVudCBzZWN0aW9ucyB0byBiZSByZW51bWJlcmVkKToNCj4gDQo+ IDcuIERlYWxpbmcgV2l0aCBMZWdhY3kgQ2xpZW50cw0KPiANCj4gSW4gbW9zdCBzaXR1YXRpb25z LCBpdCB3aWxsIGJlIGRpZmZpY3VsdCBvciBpbXBvc3NpYmxlIGZvcg0KPiB0aGUgaW1wbGVtZW50 ZXIgb3Igb3BlcmF0b3Igb2YgYW4gSU1BUCAob3IgUE9QKSBzZXJ2ZXIgdG8NCj4ga25vdyB3aGV0 aGVyIGFsbCBvZiB0aGUgY2xpZW50cyB0aGF0IG1pZ2h0IGFjY2VzcyBpdCwgb3INCj4gdGhlIGFz c29jaWF0ZWQgbWFpbCBzdG9yZSBtb3JlIGdlbmVyYWxseSwgd2lsbCBiZSBhYmxlIHRvDQo+IHN1 cHBvcnQgdGhlIGZhY2lsaXRpZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgSW4gYWxtb3N0 DQo+IGFsbCBjYXNlcywgc2VydmVycyB3aG8gY29uZm9ybSB0byB0aGlzIHNwZWNpZmljYXRpb24g d2lsbA0KPiBoYXZlIHRvIGJlIHByZXBhcmVkIHRvIGRlYWwgd2l0aCBjbGllbnRzIHRoYXQgZG8g bm90IGVuYWJsZQ0KPiB0aGUgcmVsZXZhbnQgY2FwYWJpbGl0aWVzLiAgVW5mb3J0dW5hdGVseSwg dGhlcmUgaXMgbm8NCj4gY29tcGxldGVseSBzYXRpc2ZhY3Rvcnkgd2F5IHRvIGRvIHNvIG90aGVy IHRoYW4gZm9yIHN5c3RlbXMNCj4gdGhhdCB3aXNoIHRvIHJlY2VpdmUgZW1haWwgdGhhdCByZXF1 aXJlcyBTTVRQVVRGOA0KPiBjYXBhYmlsaXRpZXMgdG8gYmUgc3VyZSB0aGF0IGFsbCBjb21wb25l bnRzIG9mIHRob3NlDQo+IHN5c3RlbXMgLS0gaW5jbHVkaW5nIElNQVAgYW5kIG90aGVyIGNsaWVu dHMgc2VsZWN0ZWQgYnkNCj4gdXNlcnMgLS0gYXJlIHVwZ3JhZGVkIGFwcHJvcHJpYXRlbHkuDQo+ IA0KPiBDaG9pY2VzIGF2YWlsYWJsZSB0byB0aGUgc2VydmVyIHdoZW4gYSBtZXNzYWdlIHRoYXQN Cj4gcmVxdWlyZXMgU01UUFVURjggaXMgZW5jb3VudGVyZWQgYW5kIHRoZSBjbGllbnQgZG9lc24n dA0KPiBlbmFibGUgVVRGLTggY2FwYWJpbGl0eSBpbmNsdWRlIGhpZGluZyB0aGUgcHJvYmxlbWF0 aWMNCj4gbWVzc2FnZShzKSBhcyBvdXRsaW5lZCBlbHNld2hlcmUgaW4gdGhpcyBzcGVjaWZpY2F0 aW9uLA0KPiBjcmVhdGluZyBpbiBiYW5kIG9yIG91dCBvZiBiYW5kIG5vdGlmaWNhdGlvbnMgb3Ig ZXJyb3INCj4gbWVzc2FnZXMsIG9yIHNvbWVob3cgdHJ5aW5nIHRvIGNyZWF0ZSBhIHZhcmlhdGlv biBvbiB0aGUNCj4gbWVzc2FnZSB3aXRoIHRoZSBpbnRlbnRpb24gb2YgcHJvdmlkaW5nIHVzZWZ1 bCBpbmZvcm1hdGlvbg0KPiB0byB0aGF0IGNsaWVudCBhYm91dCB3aGF0IGhhcyBvY2N1cnJlZC4g IFN1Y2ggdmFyaWFudA0KPiBtZXNzYWdlcyBjYW5ub3QgYmUgYWN0dWFsIHN1YnN0aXR1dGVzIGZv ciB0aGUgb3JpZ2luYWwNCj4gbWVzc2FnZTogaXQgd2lsbCByYXJlbHkgYmUgcG9zc2libGUgdG8g cmVwbHkgdG8gKGVpdGhlciBhdA0KPiBhbGwgb3Igd2l0aG91dCBsb3NzIG9mIGluZm9ybWF0aW9u KSwgbmV3IGhlYWRlciBmaWVsZHMgb3INCj4gc3BlY2lhbGl6ZWQgY29uc3RydWN0cyAgZm9yIHNl cnZlci1jbGllbnQgY29tbXVuaWNhdGlvbg0KPiBtYXkgZ28gYmV5b25kIHRoZSByZXF1aXJlbWVu dHMgb2YsIGUuZy4sIFJGQyA1MzIyIGFuZCBtYXkNCj4gY29uc2VxdWVudGx5IGNvbmZ1c2Ugc29t ZSBsZWdhY3kgbWFpbCB1c2VyIGFnZW50cw0KPiAoaW5jbHVkaW5nIElNQVAgY2xpZW50cykgb3Ig b3RoZXJ3aXNlIG5vdCBwcm92aWRlIHRoZQ0KPiBleHBlY3RlZCBpbmZvcm1hdGlvbiB0byB1c2Vy cy4gIFRoZXJlIGFyZSBhbHNvIHRyYWRlb2ZmcyBpbg0KPiBjb25zdHJ1Y3RpbmcgdmFyaWFudHMg b2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYmV0d2Vlbg0KPiBhY2NlcHRpbmcgY29tcGxleGl0eSBh bmQgYWRkaXRpb25hbCBjb21wdXRhdGlvbiBjb3N0cyBpbg0KPiBvcmRlciB0byB0cnkgdG8gcHJl c2VydmUgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZQ0KPiAoZm9yIGV4YW1wbGUsIGlu IFtkcmFmdC1pZXRmLWVhaS1wb3BpbWFwLWRvd25ncmFkZV0pIGFuZA0KPiB0cnlpbmcgdG8gbWlu aW1pemUgdGhvc2UgY29zdHMgd2hpbGUgc3RpbGwgcHJvdmlkaW5nIHVzZWZ1bA0KPiBpbmZvcm1h dGlvbiAoZm9yIGV4YW1wbGUsIGluDQo+IFtkcmFmdC1pZXRmLWVhaS1zaW1wbGVkb3duZ3JhZGVd KS4gDQo+IA0KPiBCZWNhdXNlIHN1Y2ggbWVzc2FnZXMgYXJlIHJlYWxseSB2YXJpYXRpb25zIG9u IHRoZSBvcmlnaW5hbA0KPiBvbmVzLCBub3QgcmVhbGx5ICJkb3duZ3JhZGVkIiAob25lcyBhbHRo b3VnaCB0aGF0DQo+IHRlcm1pbm9sb2d5IGlzIG9mdGVuIHVzZWQgZm9yIGNvbnZlbmllbmNlKSwg dGhleSBpbmV2aXRhYmx5DQo+IGhhdmUgcmVsYXRpb25zaGlwcyB0byB0aGUgb3JpZ2luYWwgb25l cyB0aGF0IHRoZSBJTUFQDQo+IHNwZWNpZmljYXRpb24gW1JGQzM1MDFdIGRpZCBub3QgYW50aWNp cGF0ZS4gIEluIHBhcnRpY3VsYXIsDQo+IGRpZ2l0YWwgc2lnbmF0dXJlcyBjb21wdXRlZCBvdmVy IHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpbGwNCj4gb2Z0ZW4gbm90IGJlIGFwcGxpY2FibGUgdG8g dGhlIHZhcmlhbnQgdmVyc2lvbiBhbmQgc2VydmVycw0KPiB0aGF0IG1heSBiZSBhY2Nlc3NlZCBi eSB0aGUgc2FtZSB1c2VyIHdpdGggZGlmZmVyZW50IGNsaWVudHMNCj4gb3IgbWV0aG9kcyAoZS5n LiwgUE9QIG9yIHdlYm1haWwgc3lzdGVtcyBpbiBhZGRpdGlvbiB0bw0KPiBJTUFQIG9yIElNQVAg Y2xpZW50cyB3aXRoIGRpZmZlcmVudCBjYXBhYmlsaXRpZXMpIHdpbGwgbmVlZA0KPiB0byBleGVy dCBleHRyZW1lIGNhcmUgdG8gYmUgc3VyZSB0aGF0IFVJRFZBTElESVRZIGJlaGF2ZXMNCj4gYXMg dGhlIHVzZXIgd291bGQgZXhwZWN0LiAgVGhvc2UgaXNzdWVzIG1heSBiZSBlc3BlY2lhbGx5DQo+ IHNlbnNpdGl2ZSBpZiB0aGUgc2VydmVyIGNhY2hlcyB0aGUgdmFyaWFudCBtZXNzYWdlIG9yDQo+ IGNvbXB1dGVzIGFuZCBzdG9yZXMgaXQgd2hlbiB0aGUgbWVzc2FnZSBhcnJpdmVzIHdpdGggdGhl DQo+IGludGVudCBvZiBtYWtpbmcgZWl0aGVyIGZvcm0gYXZhaWxhYmxlIGRlcGVuZGluZyBvbiBj bGllbnQNCj4gY2FwYWJpbGl0aWVzLiANCj4gDQo+IFRoZSBiZXN0IChvciAibGVhc3QgYmFkIikg YXBwcm9hY2ggZm9yIGFueSBnaXZlbg0KPiBlbnZpcm9ubWVudCB3aWxsIGRlcGVuZCBvbiBsb2Nh bCBjb25kaXRpb25zLCBsb2NhbA0KPiBhc3N1bXB0aW9ucyBhYm91dCB1c2VyIGJlaGF2aW9yLCB0 aGUgZGVncmVlIG9mIGNvbnRyb2wgdGhlDQo+IHNlcnZlciBvcGVyYXRvciBoYXMgb3ZlciBjbGll bnQgdXNhZ2UgYW5kIHVwZ3JhZGluZywgdGhlDQo+IG9wdGlvbnMgdGhhdCBhcmUgYWN0dWFsbHkg YXZhaWxhYmxlLCBhbmQgc28gb24uICBJdCBpcw0KPiBpbXBvc3NpYmxlLCBhdCBsZWFzdCBhdCB0 aGUgdGltZSwgdG8gZ2l2ZSBnb29kIGFkdmljZSB0aGF0DQo+IHdpbGwgYXBwbHkgdG8gYWxsIHNp dHVhdGlvbnMsIG9yIGV2ZW4gcGFydGljdWxhciBwcm9maWxlcw0KPiBvZiBzaXR1YXRpb25zLCBv dGhlciB0aGFuICJ1cGdyYWRlIGxlZ2FjeSBjbGllbnRzIGFzIHNvb24NCj4gYXMgcG9zc2libGUi Lg0KPiANCj4gKElNQVAuMykgQ2hhbmdlIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mICJTZWN1cml0 eQ0KPiBDb25zaWRlcmF0aW9ucyIgdG8gcmVhZDsNCj4gDQo+IFNwZWNpYWwgY29uc2lkZXJhdGlv bnMsIHNvbWUgb2YgdGhlbSB3aXRoIHNlY3VyaXR5DQo+IGltcGxpY2F0aW9ucywgb2NjdXIgaWYg YSBzZXJ2ZXIgdGhhdCBjb25mb3JtcyB0byB0aGlzDQo+IHNwZWNpZmljYXRpb24gaXMgYWNjZXNz ZWQgYnkgYSBjbGllbnQgdGhhdCBkb2VzIG5vdCBhbmQgaW4NCj4gc29tZSBtb3JlIGNvbXBsZXgg c2l0dWF0aW9ucyBpbiB3aGljaCBhIGdpdmVuIG1lc3NhZ2UgaXMNCj4gYWNjZXNzZWQgYnkgbXVs dGlwbGUgY2xpZW50cyB0aGF0IG1pZ2h0IHVzZSBkaWZmZXJlbnQNCj4gcHJvdG9jb2xzIGFuZC9v ciBzdXBwb3J0IGRpZmZlcmVudCBjYXBhYmlsaXRpZXMuICBUaG9zZQ0KPiBpc3N1ZXMgYXJlIGRp c2N1c3NlZCBpbiBTZWN0aW9uIDcgYWJvdmUuDQo+IA0KPiAoUE9QLjEpIE1vc3Qgb2YgdGhlIGZv dXJ0aCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAzLjEgKCJNYWlsDQo+IHN0b3JlcyBhcmUgZWl0aGVy IEFTQ0lJIG9yIG5hdGl2ZSBVVEYtOCwgYW5kIGNsaWVudHMgZWl0aGVyDQo+IGlzc3VlLi4uIikg bmVlZHMgdG8gZGlzYXBwZWFyLiAgIENvbnNpZGVyaW5nIGEgc2VwYXJhdGUgbm90ZQ0KPiB0aGF0 IEkganVzdCBzZW50IChTdWJqZWN0OiBQT1AzIFNwZWMgYW5kIG1haWwgZHJvcC8gTWFpbCBzdG9y ZQ0KPiBvcmdhbml6YXRpb24iKSBhbmQgdGhlIGluc3RydWN0aW9ucyBmcm9tIHRoZSBKYWJiZXIg Y2hhdCB0byB0aGUNCj4gUE9QMyBlZGl0b3JzIHRvIGdldCByaWQgb2YgZXhjZXNzICJVVEY4IiBw YXJhbWV0ZXJzLCB0aGlzDQo+IHN1Z2dlc3Rpb24gbWF5IG5lZWQgY29uc2lkZXJhYmxlIHJld3Jp dGluZywgYnV0LCBmb2xsb3dpbmcgdGhlDQo+IHRoZW1lIGFib3ZlLCBJIHN1Z2dlc3Qgc29tZXRo aW5nIGxpa2U6DQo+IA0KPiBOb3JtYWwgb3BlcmF0aW9uIGZvciBVVEYtOCBtYWlsZHJvcHMgd2ls bCBiZSBmb3IgYm90aA0KPiBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRvIHN1cHBvcnQgdGhlIGV4dGVu c2lvbiBkaXNjdXNzZWQgaW4NCj4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgVXBncmFkaW5nIG9mIGJv dGggY2xpZW50cyBhbmQgc2VydmVycw0KPiBpcyB0aGUgb25seSBmdWxseSBzYXRpc2ZhY3Rvcnkg d2F5IHRvIHN1cHBvcnQgdGhlDQo+IGNhcGFiaWxpdGllcyBvZmZlcmVkIGJ5IHRoZSAiVVRGOCIg ZXh0ZW5zaW9uIGFuZCBTTVRQVVRGOA0KPiBtYWlsIG1vcmUgZ2VuZXJhbGx5LiAgU2VydmVycyBt dXN0LCBob3dldmVyLCBhbnRpY2lwYXRlIHRoZQ0KPiBwb3NzaWJpbGl0eSBvZiBhIGNsaWVudCBh dHRlbXB0aW5nIHRvIGFjY2VzcyBhIG1lc3NhZ2UgdGhhdA0KPiByZXF1aXJlcyB0aGlzIGV4dGVu c2lvbiB3aXRob3V0IGhhdmluZyBpc3N1ZWQgdGhlICJVVEY4Ig0KPiBjb21tYW5kLiAgVGhlcmUg YXJlIG5vIGNvbXBsZXRlbHkgc2F0aXNmYWN0b3J5IHJlc3BvbnNlcw0KPiBmb3IgdGhhdCBjYXNl IG90aGVyIHRoYW4gdXBncmFkaW5nIHRoZSBjbGllbnQgdG8gc3VwcG9ydA0KPiB0aGlzIHNwZWNp ZmljYXRpb24uICBPbmUgc29sdXRpb24sIHVuc2F0aXNmYWN0b3J5IGJlY2F1c2UNCj4gdGhlIHVz ZXIgbWF5IGJlIGNvbmZ1c2VkIGJ5IGJlaW5nIGFibGUgdG8gYWNjZXNzIHRoZQ0KPiBtZXNzYWdl IHRocm91Z2ggc29tZSBtZWFucyBhbmQgbm90IG90aGVycywgaXMgdGhhdCBhIHNlcnZlcg0KPiBN QVkgY2hvb3NlIHRvIHJlamVjdCB0aGUgY29tbWFuZCB0byByZXRyaWV2ZSB0aGUgbWVzc2FnZSBh cw0KPiBkaXNjdXNzZWQgaW4gU2VjdGlvbiA1LiAgT3RoZXIgYWx0ZXJuYXRpdmVzLCBpbmNsdWRp bmcgdGhlDQo+IHBvc3NpYmlsaXR5IG9mIGNyZWF0aW5nIGFuZCBkZWxpdmVyaW5nIHZhcmlhbnQg Zm9ybSBvZiB0aGUNCj4gbWVzc2FnZSwgYXJlIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDcgb2YgdGhl IElNQVAgVVRGLTgNCj4gc3BlY2lmaWNhdGlvbiBbZHJhZnQtaWV0Zi1lYWktNTczOGJpc10uDQo+ IA0KPiBJTU8sIHdlIGNhbiBzYWZlbHkganVzdCBsb3NlIHRoZSBleHRlbmRlZCBkaXNjdXNzaW9u IG9mIHNpemVzLA0KPiBldGMuLCBpbiB0aGUgZXhpc3RpbmcgcGFyYWdyYXBoLiAgUGFydCBvZiB0 aGUgcmVhc29uIGZvcg0KPiBzaGlmdGluZyB0aGUgdGVybWlub2xvZ3kgZnJvbSAiZG93bmdyYWRl ZCBtZXNzYWdlIiB0byAidmFyaWFudA0KPiBmb3JtIG9mIHRoZSBtZXNzYWdlIiBpcyB0aGF0IG5v IG9uZSBzYW5lIHdvdWxkIGV4cGVjdCBzaXplcywNCj4gZXRjLiB0byByZW1haW4gdGhlIHNhbWUu ICBJZiBvdGhlcnMgdGhpbmsgaXQgaXMgbmVlZGVkLCBJDQo+IHN1Z2dlc3QgYWRkaW5nIGFzIG11 Y2ggb2YgaXQgYXMgcG9zc2libGUgdG8gdGhlIElNQVAgdGV4dA0KPiAoSU1BUC4yIGFib3ZlKSBh bmQgdGhlbiBtb3ZpbmcgdGhlIHJlc3QgdG8gdGhlIFNlY3VyaXR5DQo+IENvbnNpZGVyYXRpb25z IHNlY3Rpb24gb2YgdGhlIFBPUDMgZG9jICh3aGVyZSB0aGVyZSBpcyBub3cgYQ0KPiBiYWNrLXJl ZmVyZW5jZSBwb2ludGluZyB0byAzLjEsIHRoYXQgcmVmZXJlbmNlIHdvdWxkIG5lZWQgdG8gYmUN Cj4gY29ycmVjdGVkIGluIGFueSBldmVudCkuDQo+IA0KPiAoUE9QLjIpIEluIFNlY3Rpb24gNCwg ZHJvcCBmcm9tICJNZWNoYW5pc21zIGZvciA3LWJpdC4uLiINCj4gdGhyb3VnaCB0aGUgZW5kIG9m IHRoZSBwYXJhZ3JhcGggYW5kIHJlcGxhY2UgYnk6DQo+IA0KPiBXaGVuIHRoZSBzZXJ2ZXIgaXMg bm90IGluIFVURi04IG1vZGUgYW5kIHRoZSBtZXNzYWdlDQo+IHJlcXVpcmVzIHRoYXQgbW9kZSwg cmVxdWVzdHMgdG8gZG93bmxvYWQgdGhlIG1lc3NhZ2UgTUFZDQo+IGJlIHJlamVjdGVkIChhcyBz cGVjaWZpZWQgaW4gdGhlIG5leHQgc2VjdGlvbikgb3IgdGhlDQo+IHZhcmlvdXMgb3RoZXIgYWx0 ZXJuYXRpdmVzIG91dGxpbmVkIGluIFNlY3Rpb24gMy4xIGFib3ZlDQo+IGFuZCBpbiBTZWN0aW9u IDcgb2YgdGhlIElNQVAgVVRGLTggc3BlY2lmaWNhdGlvbg0KPiBbZHJhZnQtaWV0Zi1lYWktNTcz OGJpc10sIGluY2x1ZGluZyBjcmVhdGlvbiBhbmQgZGVsaXZlcnkNCj4gb2YgdmFyaWF0aW9ucyBv biB0aGUgb3JpZ2luYWwgbWVzc2FnZSwgTUFZIGJlIGNvbnNpZGVyZWQuDQo+IA0KPiAoUE9QLjMp IFNlY3Rpb24gNSwgbGFzdCBzZW50ZW5jZS4gIEkgcmVjb21tZW5kIGp1c3QgZHJvcHBpbmcNCj4g dGhlIHBhcmVudGhldGljYWwgbm90ZSwgYnV0IHRoZSBhdXRob3JzIGFyZSB3ZWxjb21lIHRvIHBy b3Bvc2UNCj4gYW5vdGhlciB3YXkgdG8gZGFuY2UgYXJvdW5kIHRoZSBpc3N1ZS4gIE5vdGUgdGhh dCBvbmUgb2YgdGhlDQo+IGdvYWxzIG9mIHRoaXMgc2V0IG9mIHN1Z2dlc3Rpb25zIGlzIHRvIGVs aW1pbmF0ZSBhbGwgcmVmZXJlbmNlDQo+IHRvIHRoZSAiZG93bmdyYWRlIiBzcGVjcyBmcm9tIHRo ZSBQT1AzIFVURi04IGRvY3VtZW50IGFuZCwNCj4gaWRlYWxseSwgZ2V0ICJkb3duZ3JhZGUiIChh bmQsIHdvcnNlLCAiZG93bmNvbnZlcnQiKSBvdXQgb2YgdGhlDQo+IFBPUDMgVVRGLTggZG9jdW1l bnQncyB2b2NhYnVsYXJ5Lg0KPiANCj4gKFBPUElNQVAtRG93bmdyYWRlLjEpICJTZWN1cml0eSBD b25zaWRlcmF0aW9ucyI6IENvbnNpZGVyDQo+IHdoZXRoZXIgYW55IG9mIHRoaXMgbWF0ZXJpYWwg c2hvdWxkIGJlIG1vdmVkIHRvIGVpdGhlciB0aGUgbmV3DQo+IFNlY3Rpb24gNyBvciB0aGUgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiB0aGUgSU1BUA0KPiBzcGVjLiAgSSBiZWxp ZXZlIHRoYXQgYW55IG1hdGVyaWFsIHRoYXQgd291bGQgYXBwbHkgdG8gYW55DQo+ICJkb3duZ3Jh ZGluZyIgdHJhbnNmb3JtYXRpb24gc2hvdWxkIGJlIG1vdmVkIHRvIHRoZSBJTUFQIHNwZWMNCj4g KHRoZSBwYXJhZ3JhcGggc3RhcnRpbmcgIlJld3JpdGluZyIgaXMgYW4gb2J2aW91cyBjYW5kaWRh dGUpDQo+IGFuZCByZWZlcmVuY2VkIGZyb20gaGVyZSAoYW5kIFNpbXBsZURvd25ncmFkZSkgYnV0 LCBpbiB0aGUNCj4gaW50ZXJlc3Qgb2YgZ2V0dGluZyB0aGVzZSBub3RlcyBvdXQgd2l0aG91dCBt b3JlIGRlbGF5LCBJDQo+IGhhdmVuJ3QgdHJpZWQgdG8gZG8gdGhlIHdvcmsgb2YgaWRlbnRpZnlp bmcgd2hhdCwgZXhhY3RseQ0KPiBzaG91bGQgYmUgbW92ZWQuDQo+IA0KPiANCj4gKFNpbXBsZURv d25ncmFkZS4xKSBBcm50LCBwbGVhc2UgcmV2aWV3IFNlY3Rpb24gMSBQYXJhZ3JhcGggNC4NCj4g IkhpZ2gtZmlkZWxpdHkiIG1pZ2h0IGVhc2lseSBiZSByZWFkIHRvIGltcGx5ICJubyBpbmZvcm1h dGlvbg0KPiBsb3NzIi4gIE15IGluc3RpbmN0IChwZXJzb25hbCBvcGluaW9uKSBpcyB0aGF0IHlv dSBqdXN0IGRyb3ANCj4gZXZlcnl0aGluZyBmcm9tICIsIHNpbmNlIGltcGxlbWVudGluZyIgdG8g dGhlIGVuZCBvZiB0aGUNCj4gcGFyYWdyYXBoLCBidXQgb3RoZXIgc3VnZ2VzdGlvbnMgdGhhdCBz dXBwb3J0IHRoZSAib25seQ0KPiBob3JyaWJsZSBhbHRlcm5hdGl2ZXMiIGFuZCB0aGVuIHRhbGsg YWJvdXQgdHJhZGVvZmZzIHdvdWxkIGJlDQo+IHdlbGNvbWUuICBJbiBwYXJ0aWN1bGFyIChwZXJz b25hbCBvcGluaW9uIGFnYWluKSwgaWYgb25lDQo+IGNvbnNpZGVycyBwcm92aWRpbmcgc3VmZmlj aWVudCBleHBsYW5hdGlvbnMgdG8gZW5hYmxlIGN1c3RvbWVyDQo+IHN1cHBvcnQgYXMgcGFydCBv ZiB0aGUgcGFja2FnZSwgSSB0aGluayBpdCBpcyBzZW5zaWJsZSB0byBhcmd1ZQ0KPiB0aGF0IHlv dXIgZG93bmdyYWRpbmcgbWV0aG9kIGlzIG1vcmUgdHJvdWJsZSB0aGFuIGltcGxlbWVudGluZw0K PiA1NzIxYmlzIGFuZCA1NzM4YmlzIChOb3RlIHRoYXQgeW91ciByZWZlcmVuY2VzIHNob3VsZCBw b2ludCB0bw0KPiB0aGUgbmV3IGRvY3MsIG5vdCB0aGUgZWFybGllciBvbmVzIC0tIHlvdXIgbm90 ZSB1bmRlciAiT3Blbg0KPiBJc3N1ZXMgaXMgc3VwZXJmbHVvdXMgYmVjYXVzZSB0aGUgY2hhbmNl IG9mIHRoaXMgZG9jdW1lbnQgYmVpbmcNCj4gYXBwcm92ZWQgZXhjZXB0IGluIGEgcGFja2FnZSB3 aXRoIDU3MjFiaXMgYW5kIDU3MzhiaXMgaXMNCj4gZXhhY3RseSB6ZXJvIC0tIHBsZWFzZSBsZXQn cyBub3QgbWFrZSBpdCBoYXJkIGZvciB0aGUgUkZDDQo+IEVkaXRvci4uLiBvciBlYXN5IGZvciB0 aGVtIHRvIG1ha2UgbWlzdGFrZXMpLg0KPiANCj4gKFNpbXBsZURvd25ncmFkZS4yKSBOb3RlIHRo ZSBpbnRlcmltIG1lZXRpbmcgY29uc2Vuc3VzIHRoYXQNCj4gImludmFsaWQgYWRkcmVzc2VzIiBh cmUgdG8gYmUgYXZvaWRlZC4gIEkgaGF2ZW4ndCBub3RpY2VkDQo+IG9iamVjdGlvbnMgdG8gdGhh dCBkZWNpc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0LCBzbywgdW5sZXNzIEkNCj4gbWlzc2VkIHNv bWV0aGluZyBpbXBvcnRhbnQsIEkgcHJlc3VtZSBpdCB3aWxsIHN0YW5kLg0KPiANCj4gKFNpbXBs ZURvd25ncmFkZS4zKSBTZWUgdGhlIG9ic2VydmF0aW9ucyBhYm91dCBtZXNzYWdlIHNpemVzIGlu DQo+IFBPUC4xIGFib3ZlLCB0aGluayBhYm91dCB3aGV0aGVyIHRoaXMgZGlzY3Vzc2lvbiBzaG91 bGQgYmUNCj4gYWJzdHJhY3RlZCBzb21ld2hhdCBhbmQgbW92ZWQgdG8gdGhlIG5ldyBTZWN0aW9u IDcgKG9yIFNlY3VyaXR5DQo+IENvbnNpZGVyYXRpb25zKSBvZiB0aGUgSU1BUCBzcGVjLCBhbmQg ZHJvcHBlZCBmcm9tIGhlcmUuICBOb3RlDQo+IHRoYXQgYW55IHZhcmlhbnQvc3ludGhlc2l6ZWQg bWVzc2FnZSBpcyBnb2luZyB0byBoYXZlIHRoaXMNCj4gcHJvYmxlbS4NCj4gDQo+IChTaW1wbGVE b3duZ3JhZGUuNCkgR2l2ZW4gdGhlIG9uLWxpc3QgZGlzY3Vzc2lvbiBhYm91dCBVSURzIGFuZA0K PiBVSURWQUxJRElUWSwgZG8geW91IHRoaW5rIGEgRG93bmdyYWRlZC9zeW50aGVzaXplZCBtZXNz YWdlIGhhcw0KPiB0aGUgc2FtZSBVSUQgdmFsdWUgYXMgdGhlIG5vbi1BU0NJSSBvcmlnaW5hbCBv ciBhIGRpZmZlcmVudA0KPiBvbmU/ICBJIHRoaW5rIHRoZSB0ZXh0IHNob3VsZCBiZSBjbGVhciAt LSBhbmQgdGhlbiBlaXRoZXIgbW92ZWQNCj4gdG8gdGhlIElNQVAgc3BlYyBvciBjaGVja2VkIHRv IGJlIHN1cmUgdGhhdCBwb3BpbWFwLWRvd25ncmFkZQ0KPiBpcyBjb25zaXN0ZW50Lg0KPiANCj4g YmVzdCByZWdhcmRzLA0KPiAgIGpvaG4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From duerst@it.aoyama.ac.jp Mon May 21 21:06:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA11421F8616 for ; Mon, 21 May 2012 21:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.638 X-Spam-Level: X-Spam-Status: No, score=-99.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9BbN3RdNSK4 for ; Mon, 21 May 2012 21:06:51 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7E34C21F8602 for ; Mon, 21 May 2012 21:06:49 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q4M46eix008213 for ; Tue, 22 May 2012 13:06:40 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 718a_aa1a_886a8d80_a3c3_11e1_98c5_001d096c5782; Tue, 22 May 2012 13:06:39 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47024) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 22 May 2012 13:06:44 +0900 Message-ID: <4FBB10CD.3020909@it.aoyama.ac.jp> Date: Tue, 22 May 2012 13:06:37 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 04:06:51 -0000 On 2012/05/17 10:56, Barry Leiba wrote: >> UTF8 without LANG makes sense (elementary EAI/ SMTPUTF8 support >> for addresses and headers) but I suggest that LANG without UTF8 >> does not > > I don't see how they're related. The server's being able to put > non-English on protocol messages, and having its messages translated > into 17 languages, is entirely unrelated to its ability to handle > UTF-8 in email address fields. Well, except that most languages, to be written decently, need non-ASCII characters. > On the other hand, I can't see anyone looking at this spec and saying, > "Well, I can't/won't do the rest of it, but the LANG command looks > interesting. I think I'll just implement that." Agreed. Also, the other way round, I can't see anyone looking at the spec and saying: Implementing LANG is way too complex, I'll never get that done. A trivial implementation just means that the following two things have to work: C: LANG Foo S: -ERR invalid language Foo C: LANG S: -ERR Server is unable to list languages I'm not very familiar with POP3, but maybe this even could be shortened to a single uniform reply: C: LANG [Foo] S: -ERR Server only has a dummy implementation of the LANG command Implementer's mileage may vary, but I have serious difficulties imagining that this would take much work to get implemented. So given the above, I'd go a step further than John and fold the two capabilities together completely. Regards, Martin. From barryleiba.mailing.lists@gmail.com Tue May 22 05:58:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7BD21F8630 for ; Tue, 22 May 2012 05:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfRSuvhNGiqS for ; Tue, 22 May 2012 05:58:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28BC221F862F for ; Tue, 22 May 2012 05:58:58 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4936205lbb.31 for ; Tue, 22 May 2012 05:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1RcLT0GZlpScbk+5t2Di/9OWXfXo74pqmqcUyxeSWmA=; b=qY+CqXEjjBJZzTCTehawSj4DAmyjBvWr0cPkdn1mk5kBiQrMwX1Nt7o+bC7LFdNdME yaZ5wq1kZRYBOd8jHTXhmHAw8IDjsAHYAC6hKxRgIUFDuJpXMZblg7aGXldhuLN3eJh+ 1Y5hqQnLinGipx18Rxb/K0jNj7nr5SBHusrau1/lgISeDnzwSnjstk65r28TA29ObPUU tngi30u8A88a32N3NDgNzSNZF4d/Mxx/Km2wlFQUtKJTwEleSYy8+bqhymliAjyf3UEA Ryk912ULTdWB7ZpWKgQnU3w5UE6OJRD3fQs7Ar3+jRiU1N2KusjDmDEPOl0cFvrJZ5cd 2gZA== MIME-Version: 1.0 Received: by 10.152.111.33 with SMTP id if1mr22970163lab.10.1337691538089; Tue, 22 May 2012 05:58:58 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Tue, 22 May 2012 05:58:57 -0700 (PDT) In-Reply-To: <4FBB10CD.3020909@it.aoyama.ac.jp> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <4FBB10CD.3020909@it.aoyama.ac.jp> Date: Tue, 22 May 2012 08:58:57 -0400 X-Google-Sender-Auth: gBU95kSe6_roWUEaKJcWWpth7Fo Message-ID: From: Barry Leiba To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 12:59:00 -0000 >>> UTF8 without LANG makes sense (elementary EAI/ SMTPUTF8 support >>> for addresses and headers) but I suggest that LANG without UTF8 >>> does not >> >> I don't see how they're related. =A0The server's being able to put >> non-English on protocol messages, and having its messages translated >> into 17 languages, is entirely unrelated to its ability to handle >> UTF-8 in email address fields. > > Well, except that most languages, to be written decently, need non-ASCII > characters. So? What does being able to put non-ASCII characters in the human-readable messages have to do with being able to handle UTF-8 in email address fields? b From arnt@gulbrandsen.priv.no Tue May 22 06:10:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8821F854D for ; Tue, 22 May 2012 06:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0+GWEEei3Cd for ; Tue, 22 May 2012 06:10:16 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7F21F8539 for ; Tue, 22 May 2012 06:10:16 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0EC50FA09B8; Tue, 22 May 2012 13:10:13 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337692212-3791-3790/11/17; Tue, 22 May 2012 13:10:12 +0000 Message-Id: <4FBB9066.6070504@gulbrandsen.priv.no> Date: Tue, 22 May 2012 15:11:02 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <4FBB10CD.3020909@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 13:10:16 -0000 We have two options: 1. The server is permitted to issue "unknown command" on LANG if it does UTF8 but not LANG. 2. The server is permitted to issue "unimplemented command" on LANG if it does UTF8 but not LANG. Pardon my yawn. Arnt From arnt@gulbrandsen.priv.no Tue May 22 07:06:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC1B21F85FD for ; Tue, 22 May 2012 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r33NCbJT1GA9 for ; Tue, 22 May 2012 07:06:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4C721F85EA for ; Tue, 22 May 2012 07:06:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1351AFA09BC; Tue, 22 May 2012 14:06:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337695612-3791-3790/11/19; Tue, 22 May 2012 14:06:52 +0000 Message-Id: <4FBB9DAE.8060003@gulbrandsen.priv.no> Date: Tue, 22 May 2012 16:07:42 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: IMA Discussion Content-Type: text/plain; charset=iso-8859-1 Subject: [EAI] imap utf8 string decision X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:06:55 -0000 Hi, did we decide how UTF8 strings ought to be represented? Should I drop my uquoted code? Arnt From klensin@jck.com Tue May 22 09:21:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E721F8628 for ; Tue, 22 May 2012 09:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJKGGB2KHJZ9 for ; Tue, 22 May 2012 09:21:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8821F85EF for ; Tue, 22 May 2012 09:21:50 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SWrkd-000O8E-9z; Tue, 22 May 2012 12:15:59 -0400 Date: Tue, 22 May 2012 12:21:40 -0400 From: John C Klensin To: Barry Leiba , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: In-Reply-To: References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <4FBB10CD.3020909@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 16:21:50 -0000 --On Tuesday, May 22, 2012 08:58 -0400 Barry Leiba wrote: >>>> UTF8 without LANG makes sense (elementary EAI/ SMTPUTF8 >>>> support for addresses and headers) but I suggest that LANG >>>> without UTF8 does not >>>=20 >>> I don't see how they're related. =C2=A0The server's being = able >>> to put non-English on protocol messages, and having its >>> messages translated into 17 languages, is entirely unrelated >>> to its ability to handle UTF-8 in email address fields. >>=20 >> Well, except that most languages, to be written decently, >> need non-ASCII characters. "Most" is a bit of an understatement. Not even English qualifies (although many texts in English do). > So? What does being able to put non-ASCII characters in the > human-readable messages have to do with being able to handle > UTF-8 in email address fields? Barry, please reread what I wrote: IMO, UTF-8 without LANG makes perfectly good sense and email address fields and similar information is certainly part of the reason. I was just objecting to LANG without UTF-8, which I think is a setup for the use of *and battles over) arbitrary character codings. I do not believe this is a big enough deal to justify holding up the document, but the "LANG without..." case strikes me as unsanitary and in conflict what a lot of what other IETF groups have been saying about languages and characters sets. Most of those discussions would actually argue for "LANG implies UTF-8 with no mechanism for specifying anything else" but, for these specs, my personal design sense says that "if LANG is specified, UTF8 MUST be too" fits the model better. YMMD. john best, john From klensin@jck.com Tue May 22 13:01:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090B621F8685 for ; Tue, 22 May 2012 13:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI1ZyLNl3Yos for ; Tue, 22 May 2012 13:01:35 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7747021F8682 for ; Tue, 22 May 2012 13:01:35 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SWvBJ-000OO0-JW; Tue, 22 May 2012 15:55:45 -0400 Date: Tue, 22 May 2012 16:01:27 -0400 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: In-Reply-To: <4FBB9066.6070504@gulbrandsen.priv.no> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <4FBB10CD.3020909@it.aoyama.ac.jp> <4FBB9066.6070504@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 20:01:36 -0000 --On Tuesday, May 22, 2012 15:11 +0200 Arnt Gulbrandsen wrote: > We have two options: > > 1. The server is permitted to issue "unknown command" on LANG > if it does UTF8 but not LANG. > 2. The server is permitted to issue "unimplemented command" on > LANG if it does UTF8 but not LANG. Because I really hate the "try to guess what character code the string might be in" case, I pretty much agree. There is a third alternative, 3. LANG implies UTF-8 for anything that might be affected by LANG but not otherwise. But that takes us right back to "UTF-8 for some things but not others" issue that we rejected on the Jabber chat. Wrt what message the server should issue if the client issues LANG but not UTF8, I share your yawn but would prefer that something be picked. john From arnt@gulbrandsen.priv.no Tue May 22 13:11:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328B121F86B7 for ; Tue, 22 May 2012 13:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozM79m8cwKZc for ; Tue, 22 May 2012 13:11:20 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id A160721F85EF for ; Tue, 22 May 2012 13:11:20 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 57326F8C85C; Tue, 22 May 2012 20:11:18 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1337717477-3791-3790/11/23; Tue, 22 May 2012 20:11:17 +0000 Message-Id: <4FBBF2E1.7020105@gulbrandsen.priv.no> Date: Tue, 22 May 2012 22:11:13 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <4FBB10CD.3020909@it.aoyama.ac.jp> <4FBB9066.6070504@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 20:11:21 -0000 On 05/22/2012 10:01 PM, John C Klensin wrote: > But that takes us right back to "UTF-8 for some things but not > others" issue that we rejected on the Jabber chat. We have that anyway. Consider a server which speaks LANG and a client which groks EAI. That pair may still deal with a good old MIME message containing content-type: text/plain; charset=iso-646-10 If you feel strongly about this, I'll go along on the strength of your intuition. A sense of design is very often prescient, even if it nothing concrete is known to support it at first. Arnt PS: I've seen ISO 646 in real mail this millenium. From klensin@jck.com Tue May 22 20:25:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED1B21F86CF for ; Tue, 22 May 2012 20:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRyOkumLBjUd for ; Tue, 22 May 2012 20:25:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7047621F8554 for ; Tue, 22 May 2012 20:25:36 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SX26x-000OrS-9V; Tue, 22 May 2012 23:19:43 -0400 Date: Tue, 22 May 2012 23:25:25 -0400 From: John C Klensin To: Jiankang YAO , ima@ietf.org Message-ID: In-Reply-To: <8468C2ED7812451D8A320A386E0F9652@LENOVO47E041CF> References: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> <8468C2ED7812451D8A320A386E0F9652@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 03:25:37 -0000 --On Friday, May 18, 2012 16:59 +0800 Jiankang YAO wrote: > thanks to John's hard work and kind proposed changes. Just trying to move things along. > If the following comments or issuses are addressed in the next > version of 4 documents, is there any other issuse which will > not be addressed? Certainly the "get rid of extra 'UTF-8' parameters in favor of using only ENABLE (or equivalent) changes that we discussed on the call need to be made. I'm not aware of anything else of significance. > If there is none, I think that it will be a big step forward > when 4 new version of documens appear. It will be a big step when we get new drafts that reflect these changes either way. And I anxiously await new versions. johm From duerst@it.aoyama.ac.jp Wed May 23 01:37:03 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53FA21F85EA for ; Wed, 23 May 2012 01:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.752 X-Spam-Level: X-Spam-Status: No, score=-99.752 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyEhW4TaU8Xw for ; Wed, 23 May 2012 01:37:03 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65121F855F for ; Wed, 23 May 2012 01:37:02 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q4N8auiB013731 for ; Wed, 23 May 2012 17:36:56 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3038_0ec9_7461154e_a4b2_11e1_9be3_001d096c5782; Wed, 23 May 2012 17:36:55 +0900 Received: from [IPv6:::1] ([133.2.210.1]:59156) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 23 May 2012 17:37:00 +0900 Message-ID: <4FBCA1A3.3040108@it.aoyama.ac.jp> Date: Wed, 23 May 2012 17:36:51 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Arnt Gulbrandsen References: <4FBB9DAE.8060003@gulbrandsen.priv.no> In-Reply-To: <4FBB9DAE.8060003@gulbrandsen.priv.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IMA Discussion Subject: Re: [EAI] imap utf8 string decision X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 08:37:03 -0000 On 2012/05/22 23:07, Arnt Gulbrandsen wrote: > Hi, > > did we decide how UTF8 strings ought to be represented? Should I drop my > uquoted code? Where exactly? Regards, Martin. > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From Shawn.Steele@microsoft.com Wed May 23 12:25:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C417D11E8089 for ; Wed, 23 May 2012 12:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThF44gQ5W88i for ; Wed, 23 May 2012 12:25:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB311E8076 for ; Wed, 23 May 2012 12:25:31 -0700 (PDT) Received: from mail93-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 May 2012 19:25:22 +0000 Received: from mail93-ch1 (localhost [127.0.0.1]) by mail93-ch1-R.bigfish.com (Postfix) with ESMTP id C12A748035F for ; Wed, 23 May 2012 19:25:22 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail93-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail93-ch1 (localhost.localdomain [127.0.0.1]) by mail93-ch1 (MessageSwitch) id 1337801120526904_26574; Wed, 23 May 2012 19:25:20 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail93-ch1.bigfish.com (Postfix) with ESMTP id 73172380232 for ; Wed, 23 May 2012 19:25:20 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 May 2012 19:25:19 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 23 May 2012 19:25:26 +0000 Received: from mail29-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 May 2012 19:25:01 +0000 Received: from mail29-va3 (localhost [127.0.0.1]) by mail29-va3-R.bigfish.com (Postfix) with ESMTP id 2BFE440035A for ; Wed, 23 May 2012 19:24:54 +0000 (UTC) Received: from mail29-va3 (localhost.localdomain [127.0.0.1]) by mail29-va3 (MessageSwitch) id 1337801091597630_8136; Wed, 23 May 2012 19:24:51 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.249]) by mail29-va3.bigfish.com (Postfix) with ESMTP id 8CB173C0049 for ; Wed, 23 May 2012 19:24:51 +0000 (UTC) Received: from BY2PRD0310HT004.namprd03.prod.outlook.com (157.56.236.5) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 May 2012 19:24:58 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.157]) by BY2PRD0310HT004.namprd03.prod.outlook.com ([10.255.80.39]) with mapi id 14.16.0152.000; Wed, 23 May 2012 19:25:01 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: LANG, UTF-8, and POP3 Thread-Index: Ac05GVcM22UdYWvgTeugMJwDvVIGOw== Date: Wed, 23 May 2012 19:24:59 +0000 Message-ID: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 19:25:31 -0000 I've been ignoring the whole thread, but I don't get what LANG is for? =20 If I'm receiving mail in UTF-8, then I get UTF-8 mail and all is fine, what= 's LANG do for me? If I'm sending mail in UTF-8, then the server can send it with SMTPUTF8. I= f it can't be forwarded it's no more stuck that current EAI stuff, so what'= s LANG for? So, IMO, the LANG thing seems orthogonal to the EAI UTF8 support problem, s= o I don't get why it lives in this draft. -Shawn From klensin@jck.com Wed May 23 13:55:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015A111E80A0 for ; Wed, 23 May 2012 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfq7k6RlWXEi for ; Wed, 23 May 2012 13:55:15 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6E11E8080 for ; Wed, 23 May 2012 13:55:15 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SXIUm-0000Ix-6t; Wed, 23 May 2012 16:49:24 -0400 Date: Wed, 23 May 2012 16:55:07 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <77822CDFD95782E3E7E654E8@PST.JCK.COM> In-Reply-To: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 20:55:16 -0000 --On Wednesday, May 23, 2012 19:24 +0000 Shawn Steele wrote: > I've been ignoring the whole thread, but I don't get what LANG > is for? > > If I'm receiving mail in UTF-8, then I get UTF-8 mail and all > is fine, what's LANG do for me? Primarily, it permits the server to deliver error message text in the local language. Whether that is a good idea or not depends on the implementation model and, in particular, how one breaks up MUA and IMAP/POP server responsibilities in that particular UA model. FWIW, I'm not a good person to be defending this because I have long favored codes that are as specific as possible, standardized text in a canonical/interchange language to the degree needed to supplement those codes, and then local translation in the client. I.e., localized message strings appear only in the UI and not on the wire, even when that wire is between the two pars of a split UA. But I've been very much in the rough on most of the occasions when this, and similar issues, have come up in the IETF. That said, POP (especially) is an extra-difficult case because, unlike, e.g., SMTP, it doesn't really use codes -- all the information other than "success" or "failure" is in the text. Partially because of that and partially because I believe that the fewer capabilities we insist that IMAP and POP servers and clients support the sooner we will see working implementations, I'd be pretty strongly opposed to any attempt to require LANG support. But I don't think the current spec does that. > If I'm sending mail in UTF-8, then the server can send it with > SMTPUTF8. If it can't be forwarded it's no more stuck that > current EAI stuff, so what's LANG for? This is strictly between IMAP/POP server and the associated client, not anything related to transport. Remember too that IMAP actually permits option/capability negotiation (POP sort of, almost, does). > So, IMO, the LANG thing seems orthogonal to the EAI UTF8 > support problem, so I don't get why it lives in this draft. Where "this draft" is the IMAP spec? john From Shawn.Steele@microsoft.com Wed May 23 14:05:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8021F861F for ; Wed, 23 May 2012 14:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCEjJ1Ng-RNJ for ; Wed, 23 May 2012 14:05:30 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24521F8531 for ; Wed, 23 May 2012 14:05:30 -0700 (PDT) Received: from mail91-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 May 2012 21:05:21 +0000 Received: from mail91-ch1 (localhost [127.0.0.1]) by mail91-ch1-R.bigfish.com (Postfix) with ESMTP id EAA50404BC for ; Wed, 23 May 2012 21:05:13 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail91-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail91-ch1 (localhost.localdomain [127.0.0.1]) by mail91-ch1 (MessageSwitch) id 1337807112821582_26381; Wed, 23 May 2012 21:05:12 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail91-ch1.bigfish.com (Postfix) with ESMTP id B97981A0090 for ; Wed, 23 May 2012 21:05:12 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 May 2012 21:05:19 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 23 May 2012 21:05:26 +0000 Received: from mail62-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 May 2012 21:04:37 +0000 Received: from mail62-va3 (localhost [127.0.0.1]) by mail62-va3-R.bigfish.com (Postfix) with ESMTP id 5E36E202B5 for ; Wed, 23 May 2012 21:04:37 +0000 (UTC) Received: from mail62-va3 (localhost.localdomain [127.0.0.1]) by mail62-va3 (MessageSwitch) id 1337807075247897_2486; Wed, 23 May 2012 21:04:35 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.254]) by mail62-va3.bigfish.com (Postfix) with ESMTP id 395E4120047; Wed, 23 May 2012 21:04:35 +0000 (UTC) Received: from BY2PRD0310HT004.namprd03.prod.outlook.com (157.56.236.5) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 May 2012 21:04:34 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.157]) by BY2PRD0310HT004.namprd03.prod.outlook.com ([10.255.80.39]) with mapi id 14.16.0152.000; Wed, 23 May 2012 21:04:36 +0000 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNOSZqkM//O2OHI0CFsBiys5tIyJbX23GQ Date: Wed, 23 May 2012 21:04:35 +0000 Message-ID: <352CBC94712DF44392EE468860B35D3006F7F0@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com> <77822CDFD95782E3E7E654E8@PST.JCK.COM> In-Reply-To: <77822CDFD95782E3E7E654E8@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JCK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:05:31 -0000 > Primarily, it permits the server to deliver error message text in the loc= al language. I'd forgotten that :) >> So, IMO, the LANG thing seems orthogonal to the EAI UTF8 support=20 >> problem, so I don't get why it lives in this draft. > Where "this draft" is the IMAP spec? Yes, and I still see it as orthogonal to UTF-8 support. Eg: IMO, this is a= "localized error messages" feature, not a "deliver/receive UTF-8 mail" fea= ture. And, as you mentioned, it could be done on the client. Additionally= , there are some tools/forwarders that use POP or IMAP to grab mailboxes bu= t aren't the actual end user client. In those cases, it could even be kind= of bad because it might end up at some intermediate language instead of th= e true end user's language. I'd be happy if LANG was cut so we don't have to talk about it. If there's= enough interest, it could be its own draft. -Shawn From klensin@jck.com Wed May 23 15:17:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81EC11E80B3 for ; Wed, 23 May 2012 15:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ2LEB4YZ8jp for ; Wed, 23 May 2012 15:17:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86611E8098 for ; Wed, 23 May 2012 15:17:32 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SXJmP-0000PS-Pk; Wed, 23 May 2012 18:11:41 -0400 Date: Wed, 23 May 2012 18:17:25 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <3F029FB9B244ED0993C9FB3C@PST.JCK.COM> In-Reply-To: <352CBC94712DF44392EE468860B35D3006F7F0@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com> <77822CDFD95782E3E7E654E8@PST.JCK.COM> <352CBC94712DF44392EE468860B35D3006F7F0@BY2PRD0310MB388.namprd03.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:17:32 -0000 --On Wednesday, May 23, 2012 21:04 +0000 Shawn Steele wrote: >> Primarily, it permits the server to deliver error message >> text in the local language. > > I'd forgotten that :) > >>> So, IMO, the LANG thing seems orthogonal to the EAI UTF8 >>> support problem, so I don't get why it lives in this draft. > >> Where "this draft" is the IMAP spec? First, please will everyone I've confused forgive me. LANG is in the POP3 spec but is not in the (our) IMAP spec. So we are talking about POP3 here, per the subject line. > Yes, and I still see it as orthogonal to UTF-8 support. Eg: > IMO, this is a "localized error messages" feature, not a > "deliver/receive UTF-8 mail" feature. And, as you mentioned, > it could be done on the client. Additionally, there are some > tools/forwarders that use POP or IMAP to grab mailboxes but > aren't the actual end user client. In those cases, it could > even be kind of bad because it might end up at some > intermediate language instead of the true end user's language. I think those tools would be pretty stupid to specify a language and, if they were implemented for that purpose only, to even have the code there to support LANG. From a client point of view, it seems to me that it is quite harmless if not used. > I'd be happy if LANG was cut so we don't have to talk about > it. If there's enough interest, it could be its own draft. Personal view (the WG should debate this to the extent needed): I'd prefer to just leave it there because it has been there for quite a while now and the burden is on those who want to take it out to convince the WG to do so. Note in particular that LANG appeared in RFC 5721 so, if we take it out, someone is presumably going to ask us to explain why (and maybe show experimental evidence that it is a problem). I think we can deal with that, but it is unlikely to be pain-free. The optimal time to get rid of it would have been sometime in 2009. But I'd support clear language that points out the disadvantages and risks of trying to support it (most of which can be extracted from our conversation in these four notes). john From ned+ima@mrochek.com Wed May 23 18:13:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4511E8072 for ; Wed, 23 May 2012 18:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31-+0MYdqwVM for ; Wed, 23 May 2012 18:13:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE711E8088 for ; Wed, 23 May 2012 18:13:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFTY2EWY4W0027Z5@mauve.mrochek.com> for ima@ietf.org; Wed, 23 May 2012 18:13:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 23 May 2012 18:13:48 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFTY2BYXRO0006TF@mauve.mrochek.com> Date: Wed, 23 May 2012 17:51:35 -0700 (PDT) In-reply-to: "Your message dated Wed, 23 May 2012 16:55:07 -0400" <77822CDFD95782E3E7E654E8@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com> <77822CDFD95782E3E7E654E8@PST.JCK.COM> To: John C Klensin Cc: Shawn Steele , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:13:59 -0000 > --On Wednesday, May 23, 2012 19:24 +0000 Shawn Steele > wrote: > > I've been ignoring the whole thread, but I don't get what LANG > > is for? > > > > If I'm receiving mail in UTF-8, then I get UTF-8 mail and all > > is fine, what's LANG do for me? > Primarily, it permits the server to deliver error message text > in the local language. Whether that is a good idea or not > depends on the implementation model and, in particular, how one > breaks up MUA and IMAP/POP server responsibilities in that > particular UA model. As a practical matter, localization has to happen somewhere, and there are advantages and disadvantages to every possible location. Putting it in the back end server has the advantage that it saves having to do the work in what are often multiple clients. And the server is in the best position to know what a given error actually means. The main disadvantage is lack of flexibility - the server cannot respond to local client conditions because it is usually unaware of them. The conditions are flipped in the client case, of course. THe one place I really don't like seeing it done is in the web service layer. There are probably arguments for doing it there, but I've yet to hear one that's I found compelling. > FWIW, I'm not a good person to be defending this because I have > long favored codes that are as specific as possible, > standardized text in a canonical/interchange language to the > degree needed to supplement those codes, and then local > translation in the client. I.e., localized message strings > appear only in the UI and not on the wire, even when that wire > is between the two pars of a split UA. I agree that this is a superior model. > But I've been very much > in the rough on most of the occasions when this, and similar > issues, have come up in the IETF. That said, POP (especially) > is an extra-difficult case because, unlike, e.g., SMTP, it > doesn't really use codes -- all the information other than > "success" or "failure" is in the text. The main problem with doing it on the client side is that a significant number of clients are for whatever reason unwilling or unable to support localization locally. I don't really understand this, but I'm not a client author. The SMTP case needs to be broken down into SUBMIT and SMTP relay. SUBMIT is close enough to IMAP that a similar model makes sense. But SMTP relay is a much more difficult problem because it necessarily crosses administrative, local, and even national boundaries. In addition to the problem of how the server even becomes aware of the language preference across multiple hops, this creates another one of those situations so common in email: Asymmetric cost/benefits. Why should I care about internationalizing my SMTP server to a bunch of languages my user base doesn't use? And similarly, why should someone in some other country give a crap about making my users happy? But even though the server-side model doesn't really make sense for SMTP relay, the clients capable of internationalizing either SMTP responses, let alone DSNs or MDNs, are very rare. Makes no sense to me, but again, I'm not a client author. > Partially because of that and partially because I believe that > the fewer capabilities we insist that IMAP and POP servers and > clients support the sooner we will see working implementations, > I'd be pretty strongly opposed to any attempt to require LANG > support. But I don't think the current spec does that. I agree. Ned From yaojk@cnnic.cn Wed May 23 20:17:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0807421F855A for ; Wed, 23 May 2012 20:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.205 X-Spam-Level: X-Spam-Status: No, score=-99.205 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P-SM0yOUo74 for ; Wed, 23 May 2012 20:17:09 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id F17A421F862B for ; Wed, 23 May 2012 20:17:07 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 24 May 2012 11:17:05 +0800 Message-ID: <283210F2CC804D4E872106F4E6B6B771@LENOVO47E041CF> From: "Jiankang YAO" To: "Shawn Steele" References: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com><77822CDFD95782E3E7E654E8@PST.JCK.COM> <352CBC94712DF44392EE468860B35D3006F7F0@BY2PRD0310MB388.namprd03.prod.outlook.com> Date: Thu, 24 May 2012 11:17:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 03:17:10 -0000 DQoNCldoeSBMQU5HIHdhcyB0aGVyZSBzaW5jZSBVVEYtOCBpcyBlbmFibGVkPw0KSSB0aGluayB0 aGF0IG9uZSByZWFzb24gaXMgdGhhdDoNClVuaWNvZGUgaW5jbHVkZXMgbWFueSBsYW5ndWFnZXMn IGNoYXJhY3RlcnMgc3VjaCBhcyBDaGluZXNlLCBLb3JlYW4sIGFuZCBSdXNzaWEuLi4uLg0KSWYg dGhlcmUgaXMgYSBMQU5HIGNvbW1hbmQsIHRoZSBzZXJ2ZXIgYW5kIGNsaWVudCBjYW4gdGFsayB3 aXRoIHRoZSBsYW5ndWFnZXMgcHJlZmVycmVkIGJ5IGNsaWVudCBhbmQgc2VydmVyLg0KT3RoZXJ3 aXNlLCB0aGUgc2VydmVyIG1heSByZXNwb25kIHdpdGggS29yZWFuIGNoYXJhY3RlcnMsIGJ1dCB0 aGUgdXNlciBvZiB0aGUgY2xpZW50IG1heSBub3Qga25vdyBpdCBhbmQgc2F5ICJwbHMgc2VuZCBt ZSB3aXRoIENoaW5lc2UiLg0KDQpKaWFua2FuZyBZYW8gDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNoYXduIFN0ZWVsZSIgPFNoYXduLlN0ZWVsZUBtaWNyb3Nv ZnQuY29tPg0KVG86ICJKb2huIEMgS2xlbnNpbiIgPGtsZW5zaW5AamNrLmNvbT47IDxpbWFAaWV0 Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgTWF5IDI0LCAyMDEyIDU6MDQgQU0NClN1YmplY3Q6IFJl OiBbRUFJXSBMQU5HLCBVVEYtOCwgYW5kIFBPUDMNCg0KDQo+PiBQcmltYXJpbHksIGl0IHBlcm1p dHMgdGhlIHNlcnZlciB0byBkZWxpdmVyIGVycm9yIG1lc3NhZ2UgdGV4dCBpbiB0aGUgbG9jYWwg bGFuZ3VhZ2UuDQo+IA0KPiBJJ2QgZm9yZ290dGVuIHRoYXQgOikNCj4gDQo+Pj4gIFNvLCBJTU8s IHRoZSBMQU5HIHRoaW5nIHNlZW1zIG9ydGhvZ29uYWwgdG8gdGhlIEVBSSBVVEY4IHN1cHBvcnQg DQo+Pj4gIHByb2JsZW0sIHNvIEkgZG9uJ3QgZ2V0IHdoeSBpdCBsaXZlcyBpbiB0aGlzIGRyYWZ0 Lg0KPiANCj4+IFdoZXJlICJ0aGlzIGRyYWZ0IiBpcyB0aGUgSU1BUCBzcGVjPw0KPiANCj4gWWVz LCBhbmQgSSBzdGlsbCBzZWUgaXQgYXMgb3J0aG9nb25hbCB0byBVVEYtOCBzdXBwb3J0LiAgRWc6 IElNTywgdGhpcyBpcyBhICJsb2NhbGl6ZWQgZXJyb3IgbWVzc2FnZXMiIGZlYXR1cmUsIG5vdCBh ICJkZWxpdmVyL3JlY2VpdmUgVVRGLTggbWFpbCIgZmVhdHVyZS4gIEFuZCwgYXMgeW91IG1lbnRp b25lZCwgaXQgY291bGQgYmUgZG9uZSBvbiB0aGUgY2xpZW50LiAgQWRkaXRpb25hbGx5LCB0aGVy ZSBhcmUgc29tZSB0b29scy9mb3J3YXJkZXJzIHRoYXQgdXNlIFBPUCBvciBJTUFQIHRvIGdyYWIg bWFpbGJveGVzIGJ1dCBhcmVuJ3QgdGhlIGFjdHVhbCBlbmQgdXNlciBjbGllbnQuICBJbiB0aG9z ZSBjYXNlcywgaXQgY291bGQgZXZlbiBiZSBraW5kIG9mIGJhZCBiZWNhdXNlIGl0IG1pZ2h0IGVu ZCB1cCBhdCBzb21lIGludGVybWVkaWF0ZSBsYW5ndWFnZSBpbnN0ZWFkIG9mIHRoZSB0cnVlIGVu ZCB1c2VyJ3MgbGFuZ3VhZ2UuDQo+IA0KPiBJJ2QgYmUgaGFwcHkgaWYgTEFORyB3YXMgY3V0IHNv IHdlIGRvbid0IGhhdmUgdG8gdGFsayBhYm91dCBpdC4gIElmIHRoZXJlJ3MgZW5vdWdoIGludGVy ZXN0LCBpdCBjb3VsZCBiZSBpdHMgb3duIGRyYWZ0Lg0KPiANCj4gLVNoYXduDQo+IA0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ== From Shawn.Steele@microsoft.com Thu May 24 09:57:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE921F8587 for ; Thu, 24 May 2012 09:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L20beQR+PGMk for ; Thu, 24 May 2012 09:57:53 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id C473021F84CD for ; Thu, 24 May 2012 09:57:53 -0700 (PDT) Received: from mail132-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 May 2012 16:57:44 +0000 Received: from mail132-ch1 (localhost [127.0.0.1]) by mail132-ch1-R.bigfish.com (Postfix) with ESMTP id 12E07300346 for ; Thu, 24 May 2012 16:57:44 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1418Izz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail132-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail132-ch1 (localhost.localdomain [127.0.0.1]) by mail132-ch1 (MessageSwitch) id 1337878661397219_23825; Thu, 24 May 2012 16:57:41 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail132-ch1.bigfish.com (Postfix) with ESMTP id 530A13600F0 for ; Thu, 24 May 2012 16:57:41 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 May 2012 16:57:39 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 24 May 2012 16:57:44 +0000 Received: from mail34-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 May 2012 16:56:53 +0000 Received: from mail34-am1 (localhost [127.0.0.1]) by mail34-am1-R.bigfish.com (Postfix) with ESMTP id A7125A03C8 for ; Thu, 24 May 2012 16:56:53 +0000 (UTC) Received: from mail34-am1 (localhost.localdomain [127.0.0.1]) by mail34-am1 (MessageSwitch) id 1337878611119854_14812; Thu, 24 May 2012 16:56:51 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.242]) by mail34-am1.bigfish.com (Postfix) with ESMTP id 1B93860046; Thu, 24 May 2012 16:56:51 +0000 (UTC) Received: from BY2PRD0310HT003.namprd03.prod.outlook.com (157.56.236.5) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 May 2012 16:56:44 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.62]) by BY2PRD0310HT003.namprd03.prod.outlook.com ([10.255.80.38]) with mapi id 14.16.0152.000; Thu, 24 May 2012 16:56:52 +0000 From: Shawn Steele To: Jiankang YAO Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNOSZqkM//O2OHI0CFsBiys5tIyJbX23GQgABpvt+AAOTQIA== Date: Thu, 24 May 2012 16:56:51 +0000 Message-ID: <352CBC94712DF44392EE468860B35D3008BE14@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D3006EC57@BY2PRD0310MB388.namprd03.prod.outlook.com><77822CDFD95782E3E7E654E8@PST.JCK.COM> <352CBC94712DF44392EE468860B35D3006F7F0@BY2PRD0310MB388.namprd03.prod.outlook.com> <283210F2CC804D4E872106F4E6B6B771@LENOVO47E041CF> In-Reply-To: <283210F2CC804D4E872106F4E6B6B771@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CNNIC.CN$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JCK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 16:57:54 -0000 It had come up before & I'd forgotten :) I'm happy with or without it, wha= tever's easier. -Shawn -----Original Message----- From: Jiankang YAO [mailto:yaojk@cnnic.cn]=20 Sent: Wednesday, May 23, 2012 8:17 PM To: Shawn Steele Cc: John C Klensin; ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 Why LANG was there since UTF-8 is enabled? I think that one reason is that: Unicode includes many languages' characters such as Chinese, Korean, and Ru= ssia..... If there is a LANG command, the server and client can talk with the languag= es preferred by client and server. Otherwise, the server may respond with Korean characters, but the user of t= he client may not know it and say "pls send me with Chinese". Jiankang Yao=20 From yaojk@cnnic.cn Fri May 25 00:47:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C921F85CD for ; Fri, 25 May 2012 00:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.743 X-Spam-Level: X-Spam-Status: No, score=-98.743 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hJLnHfJTy6s for ; Fri, 25 May 2012 00:47:55 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D415021F85C6 for ; Fri, 25 May 2012 00:47:45 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 25 May 2012 15:47:36 +0800 Message-ID: <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> Date: Fri, 25 May 2012 15:47:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 07:47:56 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgTWF5 IDE3LCAyMDEyIDU6NTIgQU0NClN1YmplY3Q6IFtFQUldIExBTkcsIFVURi04LCBhbmQgUE9QMw0K DQoNCj4gUXVlc3Rpb25zIGZvciB0aGUgd29ya2luZyBncm91cDoNCj4gDQo+ICgxKSBJbiByZWFk aW5nIHRoZSBQT1AzIGRvY3VtZW50LCBJIG5vdGljZSB0aGF0IGl0IGlzIHBvc3NpYmxlDQo+IGZv ciBhIGNsaWVudCB0byByZXF1ZXN0IGFuZCBhIHNlcnZlciB0byBwcm9jZXNzIExBTkcgd2l0aG91 dA0KPiBzdXBwb3J0aW5nIFVURjguICBJbiB0aGUgaW50ZXJlc3Qgb2Ygc2ltcGxpZmljYXRpb24g b2YNCj4gdmFyaWF0aW9ucyBhbmQgd2l0aCB0aGUga25vd2xlZGdlIHRoYXQgdmVyeSBmZXcgbGFu Z3VhZ2VzIGNhbiBiZQ0KPiBjb21wbGV0ZWx5IHN1cHBvcnRlZCBieSBBU0NJSSAoYW5kIEVuZ2xp c2ggaXMgX25vdF8gb25lIG9mDQo+IHRoZW0pLCBJIHN1Z2dlc3Qgd2UgY29uc2lkZXIgcmVxdWly aW5nIFVURjggY2FwYWJpbGl0eSBpZiBMQU5HDQo+IGlzIHN1cHBvcnRlZC9yZXF1ZXN0ZWQuICAN Cj4gDQo+IFRoZSBsb2dpY2FsIGFsdGVybmF0aXZlIGlzIGZvciBhIHNlcnZlciB0byBoYXZlIHRv IHN1cHBvcnQgYm90aA0KPiBVVEYtOCBhbmQsIGUuZy4sIHRyYW5zbGl0ZXJhdGVkIC8gQVNDSUkt bWFwcGVkIG1lc3NhZ2UgZm9ybXMgZm9yDQo+IHRoZSB2YXJpb3VzIGxhbmd1YWdlcyBhbmQsIGF0 IGxlYXN0IElNTywgd2UgcmVhbGx5IGRvbid0IHdhbnQgdG8NCj4gZ28gdGhlcmUuDQo+IA0KPiBV VEY4IHdpdGhvdXQgTEFORyBtYWtlcyBzZW5zZSAoZWxlbWVudGFyeSBFQUkvIFNNVFBVVEY4IHN1 cHBvcnQNCj4gZm9yIGFkZHJlc3NlcyBhbmQgaGVhZGVycykgYnV0IEkgc3VnZ2VzdCB0aGF0IExB Tkcgd2l0aG91dCBVVEY4DQo+IGRvZXMgbm90DQo+IA0KPiBOb3RlIHRoYXQgYWRvcHRpbmcgdGhp cyBjaGFuZ2UgcmVxdWlyZXMgbm8gY2hhbmdlIHRvIHRoZQ0KPiBkb2N1bWVudCBvdGhlciB0aGFu IGEgd2VsbC1wbGFjZWQgTVVTVCBhbmQgbWF5YmUgYSBvbmUgc2VudGVuY2UNCj4gZXhwbGFuYXRp b24uDQo+IA0KDQpMQU5HIHdpdGhvdXQgc3VwcG9ydGluZyBVVEY4IGlzIG5vdCBnb29kLiBMQU5H IG11c3QgaGF2ZSBVVEY4Lg0KSSB3aWxsIHRyeSB0byBjbGFyaWZ5IHNvbWUgd29yZHMgaW4gdGhl IG5ldyB2ZXJzaW9uLg0KDQpKaWFua2FuZyBZYW8NCg0KPiAgICBqb2huDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBs aXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ltYQ== From klensin@jck.com Fri May 25 01:07:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64F821F8547 for ; Fri, 25 May 2012 01:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmVp1IBCJ2y2 for ; Fri, 25 May 2012 01:07:18 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64C21F8542 for ; Fri, 25 May 2012 01:07:18 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SXpSg-0003gU-7O; Fri, 25 May 2012 04:01:26 -0400 Date: Fri, 25 May 2012 04:07:12 -0400 From: John C Klensin To: Jiankang YAO , ima@ietf.org Message-ID: <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> In-Reply-To: <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:07:18 -0000 --On Friday, May 25, 2012 15:47 +0800 Jiankang YAO wrote: >... > LANG without supporting UTF8 is not good. LANG must have UTF8. > I will try to clarify some words in the new version. Excellent, thanks. The clarification could be as simple as a sentence in the LANG description that says "Because of the need to use non-ASCII characters to represent almost all languages in a comprehensive way, the LANG option MUST NOT be specified unless UTF8 is also specified". But I think that is a matter for editorial discretion. Anyone who objects to such a change should speak up, and explain, immediately. john From yaojk@cnnic.cn Fri May 25 02:32:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00DE21F8557 for ; Fri, 25 May 2012 02:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.587 X-Spam-Level: X-Spam-Status: No, score=-98.587 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR42jfVh7pyM for ; Fri, 25 May 2012 02:32:10 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 9102821F849A for ; Fri, 25 May 2012 02:32:08 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 25 May 2012 17:32:01 +0800 Message-ID: From: "Jiankang YAO" To: "John C Klensin" , References: <2F04F7925930F682E264E2CD@PST.JCK.COM> Date: Fri, 25 May 2012 17:32:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] POP3 Spec and mail drop/ Mail store organization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:32:11 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgTWF5 IDE3LCAyMDEyIDY6MTEgQU0NClN1YmplY3Q6IFtFQUldIFBPUDMgU3BlYyBhbmQgbWFpbCBkcm9w LyBNYWlsIHN0b3JlIG9yZ2FuaXphdGlvbg0KDQoNCj4gVGhlc2UgYXJlIG1vcmUgb3IgbGVzcyBu aXRzIGJ1dCBzb21lIG9mIHRoZW0gYXJlIGEgZmFpcmx5IGxhcmdlDQo+IG9uZXMgKGFuZCB0aGUg SU1BUCBzcGVjIHNob3VsZCBiZSBjaGVja2VkIHRvIGJlIHN1cmUgaXQgZG9lc24ndA0KPiBzdWZm ZXIgZnJvbSBhbnkgb2YgdGhlIHNhbWUgcHJvYmxlbXMpLg0KPiANCj4gVGhlIHNlY29uZCBwYXJh Z3JhcGggb2YgU2VjdGlvbiAzLjEgc3RhcnRzICJNYWlsZHJvcHMgY2FuDQo+IG5hdGl2ZWx5IHN0 b3JlIFVURi04IG9yIGJlIGxpbWl0ZWQgdG8gQVNDSUkuIi4gIEVzc2VudGlhbGx5IHRoZQ0KPiBz YW1lIHN0YXRlbWVudCBhcHBlYXJzIGF0IHRoZSBiZWdpbm5pbmcgb2YgcGFyYWdyYXBoIDQgb25s eSBpdA0KPiBzYXlzICJtYWlsIHN0b3JlIiByYXRoZXIgdGhhbiAibWFpbGRyb3AiLg0KPiANCj4g SXNzdWVzOg0KPiANCj4gKDEpIEknbSBub3QgcXVpdGUgc3VyZSB3aGF0IHRoZSBkaWZmZXJlbmNl IGlzIGJldHdlZW4gYQ0KPiAibWFpbGRyb3AiIGFuZCBhICJtYWlsIHN0b3JlIi4gIElmIHRoZXJl IGlzbid0IG9uZSwgdGhlDQo+IHRlcm1pbm9sb2d5IHNob3VsZCBiZSBoYXJtb25pemVkLiAgRldJ VywgUkZDIDE5MzkgbWVudGlvbnMNCj4gIm1haWxkcm9wIiBpbiBzZXZlcmFsIHBsYWNlcyBidXQg bmV2ZXIgbWVudGlvbnMgYSAibWFpbCBzdG9yZSINCj4gKG9yICJtYWlsc3RvcmUiKS4gIElmIHRo ZXJlIGlzIGEgZGlmZmVyZW5jZSwgdGhlIGRvY3VtZW50IHNob3VsZA0KPiBwcm9iYWJseSBnbyB0 byBhIGxpdHRsZSBtb3JlIGVmZm9ydCB0byBpZGVudGlmeSBpdC4gIA0KPiANCg0KeWVzLCBpdCBz aG91bGQgc3RpY2sgdG8gbWFpbGRyb3AuDQoNCg0KPiAoMikgVGhlIHNlY29uZCBwYXJhZ3JhcGgg b2YgU2VjdGlvbiAzLjEgc3RhcnRzICJNYWlsZHJvcHMgY2FuDQo+IG5hdGl2ZWx5IHN0b3JlIFVU Ri04IG9yIGJlIGxpbWl0ZWQgdG8gQVNDSUkuIiAgQXMgdGhlIGluY2x1c2l2ZQ0KPiBzdGF0ZW1l bnQgdGhhdCBhcHBlYXJzIHRvIGJlLCBpdCBpcyBmbGF0IHdyb25nLiAgRmlyc3QsIGlmIHRoZQ0K PiBtYWlsZHJvcCB1c2VzIFVuaWNvZGUsIHdlIGRvbid0IGNhcmUgd2hhdCBpcyBzdG9yZWQgIm5h dGl2ZWx5IiwNCj4gd2l0aCB2YXJpb3VzIGZsYXZvcnMgb2YgVVRGLTE2IG9yIFVURi0zMiBiZWlu ZyBsaWtlbHkgKGFuZA0KPiBjb21tb24pLiAgV2UgZG9uJ3QgZXZlbiBjYXJlIGlmIG1lc3NhZ2Vz IGFyZSBzdG9yZWQgaW4gd2hhdGV2ZXINCj4gQ2hhcnNldCBhcnJpdmVzIG92ZXIgdGhlIHdpcmUg KGFuZCwgaW5kZWVkLCBzdG9yYWdlIG9mIG1lc3NhZ2VzDQo+IGluIHRoZSBmb3JtIGluIHdoaWNo IHRoZXkgd2VyZSBkZWxpdmVyZWQgbWF5IGJlIGNvbW1vbikuICBXZQ0KPiByZXF1aXJlIHRoYXQg aGVhZGVycyBiZSBlaXRoZXIgQVNDSUkgb3IgVVRGLTggb24gdGhlIHdpcmUsIGJ1dA0KPiB0aGF0 IHNheXMgYWxtb3N0IG5vdGhpbmcgYWJvdXQgZWl0aGVyIG1haWxkcm9wIHN0b3JhZ2UgZm9ybSBv cg0KPiBtZXNzYWdlIGNvbnRlbnQuICBXaGF0IHdlIGNhcmUgYWJvdXQgaXMgdGhhdCwgaWYgdGhl IG1lc3NhZ2VzDQo+IGFyZSBkZWxpdmVyZWQgYWNyb3NzIGEgUE9QMyBpbnRlcmZhY2VzIHdpdGgg VVRGLTggZW5hYmxlZCwgdGhlDQo+IGhlYWRlciBtYXRlcmlhbCBpcyBpbiBVVEYtOCBvbiB0aGUg d2lyZSBhbmQgb24gZGVsaXZlcnkgdG8gdGhlDQo+IFBPUCBjbGllbnQuDQo+DQoNCkZyb20gbXkg cG9pbnQgb2YgdmlldywgSSBzZWUgbm8gcHJvYmxlbSBvZiBzcGVjaWZ5aW5nICJNYWlsZHJvcHMg Y2FuDQogbmF0aXZlbHkgc3RvcmUgVVRGLTggb3IgYmUgbGltaXRlZCB0byBBU0NJSS4iDQoNClVU Ri04IHN0b3JlZCAibmF0aXZlbHkiLCBJIHRoaW5rLCBpcyBzdG9yZWQgaW4gVVRGLTgsIG5vdCBV VEYtMTYgb3IgVVRGLTMyICBvciANCnNvbWUgQ29udGVudC10cmFuc2Zlci1lbmNvZGluZzogYmFz ZTY0Lg0KDQpTZWN0aW9uIDMuMSBzYWlkICIgTWFpbGRyb3BzIGNhbiBuYXRpdmVseSBzdG9yZSBV VEYtOCBvciBiZSBsaW1pdGVkIHRvIEFTQ0lJLiAgVVRGLTgNCiAgIG1vZGUgaGFzIG5vIGVmZmVj dCBvbiBtZXNzYWdlcyBpbiBhbiBBU0NJSS1vbmx5IG1haWxkcm9wLiANCiBNZXNzYWdlcw0KICAg aW4gbmF0aXZlIFVURi04IG1haWxkcm9wcyBjYW4gYmUgQVNDSUkgb3IgVVRGLTggdXNpbmcNCiAg IGludGVybmF0aW9uYWxpemVkIGhlYWRlcnMgW1JGQzY1MzJdIGFuZC9vciA4Yml0IGNvbnRlbnQt dHJhbnNmZXItDQogICBlbmNvZGluZywgYXMgZGVmaW5lZCBpbiBNSU1FIFNlY3Rpb24gMi44IFtS RkMyMDQ1XS4iDQoNCk1lc3NhZ2VzIHdpdGggc29tZSBDb250ZW50LXRyYW5zZmVyLWVuY29kaW5n OiBiYXNlNjQsIEkgdGhpbmssIGlzIGEga2luZCBvZiAibGltaXRlZCB0byBBU0NJSSIgYmFzZWQg b24gdGhlIHRleHQgYWJvdmUuDQoNCj4gDQo+ICgzKSBUaGUgbGFuZ3VhZ2UgYWJvdXQgVVRGLTgg bWFpbGRyb3BzIGFuZCBtZXNzYWdlcyBjYW4gZWFzaWx5DQo+IGJlIHJlYWQgdG8gaW1wbHkgdGhh dCBhIG1lc3NhZ2UgdGhhdCBhcnJpdmVzIHdpdGgNCj4gDQo+ICBGcm9tOiBub24tQVNDSUktc3Ry aW5nQGV4YW1wbGUuY29tDQo+ICBUbzogICBub24tQVNDSUktc3RyaW5nQGV4YW1wbGUubmV0DQo+ ICBbLi4uXQ0KPiAgQ29udGVudC10eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJHQjIzMTIiDQo+ ICBDb250ZW50LXRyYW5zZmVyLWVuY29kaW5nOiBiYXNlNjQNCj4gIFsuLi5dDQo+IA0KDQo+IElz IHJlcXVpcmVkIHRvIGJlIGRlY29kZWQsIGNvbnZlcnRlZCB0byAnY2hhcnNldD0iVVRGLTgiJywg YW5kDQo+IHRoZW4gcmVlbmNvZGVkIHRvIGJhc2U2NC4gICBJIGRvbid0IHRoaW5rIHRoYXQgaXMg b3VyIGludGVudGlvbjoNCj4NCg0KRnJvbSB0aGUgY3VycmVudCB3b3JkcyBpbiBzZWN0aW9uIDMu MSwgSSBoYXZlIHNlZW4gbm8gc3VjaCBtZWFuaW5nIHRvby4NCg0KPg0KPiB0aGUgY29udmVyc2lv biBpcyBidXJkZW5zb21lIGFuZCBQT1Agc2VydmVycyBtYXkgbm90IGV2ZW4gaGF2ZQ0KPiB0aGUg Y2FwYWJpbGl0eSBmb3IgYWxsIHBvc3NpYmxlIENoYXJzZXRzLiAgQnV0LCB3aGV0aGVyIGl0IGlz IG9yDQo+IGlzIG5vdCwgdGhlIHNwZWMgc2hvdWxkIGJlIGFic29sdXRlbHkgY2xlYXIgYWJvdXQg d2hhdCBvdXINCj4gcmVxdWlyZW1lbnQgYWN0dWFsbHkgaXMuDQo+IA0KDQp3aWxsIHRyeSB0byBy ZWZpbmUgaXQuDQoNCkppYW5rYW5nIFlhbw0KPiAgIGpvaG4NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4g SU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From alexey.melnikov@isode.com Fri May 25 07:30:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3BD21F8671 for ; Fri, 25 May 2012 07:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjfvLDZ9xaPk for ; Fri, 25 May 2012 07:30:55 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE04A21F8617 for ; Fri, 25 May 2012 07:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337956254; d=isode.com; s=selector; i=@isode.com; bh=PnNa4gEWX9S7eRvsm8uwkRS03jAkGdfbf7QAIFJfO4Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lsTXeWmd/R/24RzgvwFg8/ngQLtRn+qZJH00o3KRwuD1/Tb91itcbQP1dQlR6nh8hYD3yD 3k+CfcEDCvOOXdnDoRyUkX5fq8caF5DyJClaiZ5UfpHfirpHvTvkRM4E53x2iR7I/FFFon cu6nO+owpVPvDqyQSXJHwOIhRAbTYLA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 25 May 2012 15:30:54 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FBF97B5.1080306@isode.com> Date: Fri, 25 May 2012 15:31:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: John C Klensin References: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> <850C102FE438B9DF074D9C7C@PST.JCK.COM> In-Reply-To: <850C102FE438B9DF074D9C7C@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , ima@ietf.org Subject: Re: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:30:56 -0000 On 17/05/2012 04:25, John C Klensin wrote: > > --On Wednesday, May 16, 2012 22:42 -0400 Barry Leiba > wrote: > >> I like the proposal in general, and don't have major comments >> about it. Lots of text tweaking and error corrections, of >> course, but that all needs to wait until text is folded into >> the actual documents, and the document editors have had their >> ways with it. >> >> Just one specific comment: >> >>> (SimpleDowngrade.4) Given the on-list discussion about UIDs >>> and UIDVALIDITY, do you think a Downgraded/synthesized >>> message has the same UID value as the non-ASCII original or a >>> different one? I think the text should be clear -- and then >>> either moved to the IMAP spec or checked to be sure that >>> popimap-downgrade is consistent. >> This is, of course, a very tricky point, but I'll note one >> thing: It's generally assumed that all clients see the same >> UIDVALIDITY for a mailbox, and the same UIDs for each >> message... but I don't see anything that necessitates that, >> since every client deals with UIDs independently of all >> others. I suggest, then, that we don't have to worry about >> UIDVALIDITY, and that servers that do this message >> substitution simply present the same UID for a given message, >> regardless of whether that message is sent to the client in >> UTF-8 or not. My (compliant) client will see a different >> message with that UID than your non-compliant one will, but >> they will conceptually refer to the same message, and will, >> therefore, have substantially the same content. Right. There is only an issue if the same clients sees different versions of the same message with the same UIDVALIDITY+UID. Possible cases for this are: 1). An EAI-capable client was talking to a non-EAI capable server. The server was upgraded to support EAI. 2). An non EAI-capable client was talking to an EAI capable server. The client was upgraded to support EAI. 3). An EAI capable client accesses EAI capable mailstore sometimes directly and sometimes through IMAP proxies that remove the EAI capability. I suppose we could warn about cases 1 and 2 (In the 1st case the server should change UIDVALIDITY. In the 2nd case the client should blow away its cache, even if the UIDVALIDITY hasn't changed.) > This works for me, but my primary concern is that we not leave > the issue up in the air. We should, IMO, pick something and be > consistent about it or state clearly that we have no intention > of doing so. > >> The failure mode of this approach is that when the user >> upgrades your client to the new, newly compliant version, and >> that version uses the same local message cache as the earlier >> version, it retains the "synthetic" message, and doesn't know >> that it needs to refresh its cache. A clean way for an >> updated client to know that a cached message has been >> synthesized would be a good way out of this, so maybe we >> should consider that (an IMAP flag?). > As usual, I'm reluctant to do anything in EAI that has > non-specific implications. An IMAP flag > ("synthesized_message"?) would certainly do the job, but so > would something as simple as either recommending that client > upgrades treat UIDVALIDITY as false and rebuild the cache on the > assumption that _some_ message-or-flag-affecting capability, > storage format, etc. might have changed. Exactly. > As a trivial example > that is not EAI-specific (but part of which came up an earlier > rant), suppose that non-EAI client version 1.98 tries to store > text/plain information whenever possible in ISO-2022-JP (or > 8859-1) even if that means verifying that there are no > signatures present and converting from whatever form arrives > even if it UTF-8. I can think of several practical reasons why > one might want to do that. Now suppose that client version 2.0, > in recognition of other changes in the world and preparatory for > version 2.1 which has full EAI support, decides to bite the > bullet and store everything locally in Unicode form (UTF-16BE if > that is the local OS preference) and maybe to do a little less > converting. I think it would want to resynchronize and > reevaluate the cache, not try to convert old messages to > reconstruct the guessed-at original form. Right? > > But I'd defer to the IMAP experts on the list. I think some text about upgrading clients and servers would be helpful. From ned+ima@mrochek.com Fri May 25 12:11:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCD521F8712 for ; Fri, 25 May 2012 12:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKTPzg95cuDI for ; Fri, 25 May 2012 12:11:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7521F8707 for ; Fri, 25 May 2012 12:11:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFWDY22UDC002CV7@mauve.mrochek.com> for ima@ietf.org; Fri, 25 May 2012 12:10:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 25 May 2012 12:10:47 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFWDXYHLDQ0006TF@mauve.mrochek.com> Date: Fri, 25 May 2012 12:06:49 -0700 (PDT) In-reply-to: "Your message dated Fri, 25 May 2012 04:07:12 -0400" <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> To: John C Klensin Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:11:02 -0000 I have to say I don't really care for this approach, because it effectively requires a server to implement UTF8 (difficult) in order to implement LANG (easy). I'd rather say that the client's use of LANG implicitly authorizes the server to send replies in UTF-8, no matter what language ends up getting selected (or not selected). But if people really prefer the dependency, I can live with it. Ned P.S. Looking at the specification, another question: Why was the approach of enabling the use of UTF-8 in USER and PASS taken rather than simply requiring AUTH support in order to suport UTF8? This is a case where coupling makes considerably more sense. > --On Friday, May 25, 2012 15:47 +0800 Jiankang YAO > wrote: > >... > > LANG without supporting UTF8 is not good. LANG must have UTF8. > > I will try to clarify some words in the new version. > Excellent, thanks. The clarification could be as simple as a > sentence in the LANG description that says "Because of the need > to use non-ASCII characters to represent almost all languages in > a comprehensive way, the LANG option MUST NOT be specified > unless UTF8 is also specified". But I think that is a matter > for editorial discretion. > Anyone who objects to such a change should speak up, and > explain, immediately. > john > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Fri May 25 12:59:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D3F21F87C9 for ; Fri, 25 May 2012 12:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTKQrA3KYeVA for ; Fri, 25 May 2012 12:59:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 86AE521F87C4 for ; Fri, 25 May 2012 12:59:19 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SY0ZX-0004Tv-6k; Fri, 25 May 2012 15:53:15 -0400 Date: Fri, 25 May 2012 15:59:01 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01OFWDXYHLDQ0006TF@mauve.mrochek.com> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:59:20 -0000 Ned, Just trying to make sure we are seeing the issues the same way, even if we still reach different conclusions. --On Friday, May 25, 2012 12:06 -0700 Ned Freed wrote: > I have to say I don't really care for this approach, because > it effectively requires a server to implement UTF8 (difficult) > in order to implement LANG (easy). First, ancient history now, but I'd contend that standalone LANG would/should have been out of scope for EAI. One can argue that it has utility with traditional ASCII addresses and headers, but not a lot... and it should have been a separate proposal, not handled through EAI. RFC 5721's title reinforces that view: it is called "POP3 Support for UTF-8", not, e.g., "Assorted i18n extensions for POP3". Given that LANG was included in 5721, I hope that we can just skip dealing with that issue, but... Second, while there are several languages for which, with care, one can construct reply messages in ASCII only (e.g., English; German if the "ue", "oe", etc., conventions are acceptable; I suppose Chinese if one were willing to write in Pinyin without tone marks) the vast majority, both Latin-script-based and otherwise, require non-ASCII characters and that, these days, effectively means UTF-8. One could avoid that problem and make LANG independent of UTF-8 by specifying a mechanism for encoded words or some other escape convention in the relevant strings, but the current spec doesn't discuss that. In addition, creating a new case in which escapes or encoded words are needed sort of violates the EAI goal of creating a migration path toward a clean, UTF-8-based, target rather than instantiating more kludges forever. So I think that clean LANG support pretty much requires handling of replies in UTF-8. The current draft doesn't say that, so we need to do _something_. > I'd rather say that the client's use of LANG implicitly > authorizes the server to send replies in UTF-8, no matter what > language ends up getting selected (or not selected). That would work too. It seems to me that the argument for requiring UTF-8 option support instead is the same as the one that caused us to take the parameters out of IMAP -- we don't want to encourage partway implementations and the marginal utility of LANG without full EAI support is probably small. If one disagrees with either of those reasons, then, yes, a LANG that intrinsically enables UTF-8 replies without having any effect or whether i18n headers are permitted or not would be more sensible. Is that consistent with your analysis? > P.S. Looking at the specification, another question: Why was > the approach of enabling the use of UTF-8 in USER and PASS > taken rather than simply requiring AUTH support in order to > suport UTF8? This is a case where coupling makes considerably > more sense. Randy? Chris? john From ned+ima@mrochek.com Fri May 25 13:35:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20DF21F87E2 for ; Fri, 25 May 2012 13:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8OfBcakjS7A for ; Fri, 25 May 2012 13:35:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1479921F87E0 for ; Fri, 25 May 2012 13:35:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFWGX3UJLS00262N@mauve.mrochek.com> for ima@ietf.org; Fri, 25 May 2012 13:35:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 25 May 2012 13:35:27 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFWGWX7FD20006TF@mauve.mrochek.com> Date: Fri, 25 May 2012 13:19:00 -0700 (PDT) In-reply-to: "Your message dated Fri, 25 May 2012 15:59:01 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> To: John C Klensin Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:35:54 -0000 > Ned, > Just trying to make sure we are seeing the issues the same way, > even if we still reach different conclusions. > --On Friday, May 25, 2012 12:06 -0700 Ned Freed > wrote: > > I have to say I don't really care for this approach, because > > it effectively requires a server to implement UTF8 (difficult) > > in order to implement LANG (easy). > First, ancient history now, but I'd contend that standalone LANG > would/should have been out of scope for EAI. One can argue that > it has utility with traditional ASCII addresses and headers, but > not a lot... and it should have been a separate proposal, not > handled through EAI. RFC 5721's title reinforces that view: it > is called "POP3 Support for UTF-8", not, e.g., "Assorted i18n > extensions for POP3". Given that LANG was included in 5721, I > hope that we can just skip dealing with that issue, but... It's the same sort of argument that was used, back in the day, against MIME: The WG was chartered to internationalize email content, so what's all this multimedia crap doing in there? As you might guess, that past experience doesn't give me a lot of sympathy for this argument. > Second, while there are several languages for which, with care, > one can construct reply messages in ASCII only (e.g., English; > German if the "ue", "oe", etc., conventions are acceptable; I > suppose Chinese if one were willing to write in Pinyin without > tone marks) the vast majority, both Latin-script-based and > otherwise, require non-ASCII characters and that, these days, > effectively means UTF-8. One could avoid that problem and > make LANG independent of UTF-8 by specifying a mechanism for > encoded words or some other escape convention in the relevant > strings, but the current spec doesn't discuss that. In > addition, creating a new case in which escapes or encoded words > are needed sort of violates the EAI goal of creating a migration > path toward a clean, UTF-8-based, target rather than > instantiating more kludges forever. > So I think that clean LANG support pretty much requires handling > of replies in UTF-8. The current draft doesn't say that, so we > need to do _something_. Absolutely, which is why I made the proposal below. > > I'd rather say that the client's use of LANG implicitly > > authorizes the server to send replies in UTF-8, no matter what > > language ends up getting selected (or not selected). > That would work too. It seems to me that the argument for > requiring UTF-8 option support instead is the same as the one > that caused us to take the parameters out of IMAP -- we don't > want to encourage partway implementations and the marginal > utility of LANG without full EAI support is probably small. If > one disagrees with either of those reasons, then, yes, a LANG > that intrinsically enables UTF-8 replies without having any > effect or whether i18n headers are permitted or not would be > more sensible. > Is that consistent with your analysis? No, not really. It would be one thing if EAI was taking POP3 from no international capabilities to the full gamut. In that case, or if there was something equivalent to enhanced status codes in POP3, the incremental step LANG provides would be small enough not to bother. But it isn't and there aren't. MIME and SASL already gave POP3 internationalized bodies, header text, usernames, and passwords. So there are a lot of people out there using POP3 who potentially have a problem dealing with POP3 errors as the stand, especially given the crappy error code situation. It also would be different if UTF8 was a snap to implement. But that's not the case either. LANG is *far* simpler than implementing UTF8, mostly because of downgrading. But again, if people prefer the dependency, I can live with it. Ned From klensin@jck.com Fri May 25 14:29:08 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA021F8810 for ; Fri, 25 May 2012 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AUn4PrmnH19 for ; Fri, 25 May 2012 14:29:07 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C521F880E for ; Fri, 25 May 2012 14:29:07 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SY1yT-0004af-2n; Fri, 25 May 2012 17:23:05 -0400 Date: Fri, 25 May 2012 17:28:51 -0400 From: John C Klensin To: Ned Freed Message-ID: <15029D7820EB5D9B06974BB5@PST.JCK.COM> In-Reply-To: <01OFWGWX7FD20006TF@mauve.mrochek.com> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:29:08 -0000 Ok. IMO, Ned's position is entirely reasonable. I don't think I agree, but the difference is mostly a matter of taste. Up to the WG. Those who have opinions, speak up. If no one other than Ned and myself care, I'll either defer to Ned's implementation experience or ask Joseph to flip a coin. john --On Friday, May 25, 2012 13:19 -0700 Ned Freed wrote: >> Ned, > >> Just trying to make sure we are seeing the issues the same >> way, even if we still reach different conclusions. > >> --On Friday, May 25, 2012 12:06 -0700 Ned Freed >> wrote: > >> > I have to say I don't really care for this approach, because >> > it effectively requires a server to implement UTF8 >> > (difficult) in order to implement LANG (easy). > >> First, ancient history now, but I'd contend that standalone >> LANG would/should have been out of scope for EAI. One can >> argue that it has utility with traditional ASCII addresses >> and headers, but not a lot... and it should have been a >> separate proposal, not handled through EAI. RFC 5721's title >> reinforces that view: it is called "POP3 Support for UTF-8", >> not, e.g., "Assorted i18n extensions for POP3". Given that >> LANG was included in 5721, I hope that we can just skip >> dealing with that issue, but... > > It's the same sort of argument that was used, back in the day, > against MIME: The WG was chartered to internationalize email > content, so what's all this multimedia crap doing in there? > > As you might guess, that past experience doesn't give me a lot > of sympathy for this argument. > >> Second, while there are several languages for which, with >> care, one can construct reply messages in ASCII only (e.g., >> English; German if the "ue", "oe", etc., conventions are >> acceptable; I suppose Chinese if one were willing to write in >> Pinyin without tone marks) the vast majority, both >> Latin-script-based and otherwise, require non-ASCII >> characters and that, these days, effectively means UTF-8. >> One could avoid that problem and make LANG independent of >> UTF-8 by specifying a mechanism for encoded words or some >> other escape convention in the relevant strings, but the >> current spec doesn't discuss that. In addition, creating a >> new case in which escapes or encoded words are needed sort of >> violates the EAI goal of creating a migration path toward a >> clean, UTF-8-based, target rather than instantiating more >> kludges forever. > >> So I think that clean LANG support pretty much requires >> handling of replies in UTF-8. The current draft doesn't say >> that, so we need to do _something_. > > Absolutely, which is why I made the proposal below. > >> > I'd rather say that the client's use of LANG implicitly >> > authorizes the server to send replies in UTF-8, no matter >> > what language ends up getting selected (or not selected). > >> That would work too. It seems to me that the argument for >> requiring UTF-8 option support instead is the same as the one >> that caused us to take the parameters out of IMAP -- we don't >> want to encourage partway implementations and the marginal >> utility of LANG without full EAI support is probably small. >> If one disagrees with either of those reasons, then, yes, a >> LANG that intrinsically enables UTF-8 replies without having >> any effect or whether i18n headers are permitted or not would >> be more sensible. > >> Is that consistent with your analysis? > > No, not really. It would be one thing if EAI was taking POP3 > from no international capabilities to the full gamut. In that > case, or if there was something equivalent to enhanced status > codes in POP3, the incremental step LANG provides would be > small enough not to bother. > > But it isn't and there aren't. MIME and SASL already gave POP3 > internationalized bodies, header text, usernames, and > passwords. So there are a lot of people out there using POP3 > who potentially have a problem dealing with POP3 errors as the > stand, especially given the crappy error code situation. > > It also would be different if UTF8 was a snap to implement. > But that's not the case either. LANG is *far* simpler than > implementing UTF8, mostly because of downgrading. > > But again, if people prefer the dependency, I can live with it. > > Ned From barryleiba.mailing.lists@gmail.com Fri May 25 16:30:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2242921F8852 for ; Fri, 25 May 2012 16:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.847 X-Spam-Level: X-Spam-Status: No, score=-102.847 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQBCk+cUvnVT for ; Fri, 25 May 2012 16:30:56 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4969521F884E for ; Fri, 25 May 2012 16:30:56 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1114048lbb.31 for ; Fri, 25 May 2012 16:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BCVBb45DZ5xH6+tVuA+uu3T7ubSAwQSntaUiSoj7Sas=; b=gthRDTWOZ9cQH+g44kRPVUrInHUXFvnOWCrWb7aS6stiw+a85dty0RS7rDNIhfAoAv yIwCS632VhObs9M7gS7r+5TKQJ+ZLR+tKGFAsuxeX/qjsyx/0wW0aeM+VB4apTH0vjAW 0FG+DuEnOWRwr0JYjkUxIrCKWdslE7OdEpiDNa7TKwYzNBiVCpPRDWzUfVVyV4UtyXEp bcmndxBwkLRs33yjxhjLH/wbn1Va13/cMzh3nZEal1EIsuWWevu89UN20F2K9TjnAQ7k 9l7IVEdgdUTR2MmoDwlTr5aqQkmGi/La1aCJsGoDPHuzWhBrT1sVuS8t3fbLxoLyEDCP TqWg== MIME-Version: 1.0 Received: by 10.112.36.130 with SMTP id q2mr308785lbj.44.1337988654969; Fri, 25 May 2012 16:30:54 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Fri, 25 May 2012 16:30:54 -0700 (PDT) In-Reply-To: <15029D7820EB5D9B06974BB5@PST.JCK.COM> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> Date: Fri, 25 May 2012 19:30:54 -0400 X-Google-Sender-Auth: 0RphVYMf-rwyaFY-Pw6XpRaAX00 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 23:30:57 -0000 >> But it isn't and there aren't. MIME and SASL already gave POP3 >> internationalized bodies, header text, usernames, and >> passwords. So there are a lot of people out there using POP3 >> who potentially have a problem dealing with POP3 errors as the >> stand, especially given the crappy error code situation. >> >> It also would be different if UTF8 was a snap to implement. >> But that's not the case either. LANG is *far* simpler than >> implementing UTF8, mostly because of downgrading. > > Ok. =A0IMO, Ned's position is entirely reasonable. =A0I don't think > I agree, but the difference is mostly a matter of taste. =A0Up to > the WG. =A0Those who have opinions, speak up. =A0If no one other > than Ned and myself care, I'll either defer to Ned's > implementation experience or ask Joseph to flip a coin. Well, I've already said that I don't see the reason to tie them together, but was willing to agree with your (John's) proposal. Ned appears to be in the same boat that I am, so we now have two who think that UTF-8 support in error messages (LANG) does not need to be tied to UTF-8 support for email addresses. Not a strong opinion, and I'm happy to accept it either way, but my preference would be to keep them separate. Barry Barry From klensin@jck.com Fri May 25 23:26:12 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F60D21F8630 for ; Fri, 25 May 2012 23:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GPU0KM04elr for ; Fri, 25 May 2012 23:26:12 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 18FDC21F8624 for ; Fri, 25 May 2012 23:26:11 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SYAMI-00056Y-UU; Sat, 26 May 2012 02:20:14 -0400 Date: Sat, 26 May 2012 02:26:02 -0400 From: John C Klensin To: Barry Leiba Message-ID: <2328D78E62789C17C2ABB5B8@PST.JCK.COM> In-Reply-To: References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 06:26:12 -0000 --On Friday, May 25, 2012 19:30 -0400 Barry Leiba wrote: >... >>> It also would be different if UTF8 was a snap to implement. >>> But that's not the case either. LANG is *far* simpler than >>> implementing UTF8, mostly because of downgrading. >>=20 >> Ok. =C2=A0IMO, Ned's position is entirely reasonable. =C2=A0I = don't >> think I agree, but the difference is mostly a matter of >> taste. =C2=A0Up to the WG. =C2=A0Those who have opinions, = speak up. >> =C2=A0If no one other than Ned and myself care, I'll either = defer >> to Ned's implementation experience or ask Joseph to flip a >> coin. >=20 > Well, I've already said that I don't see the reason to tie = them > together, but was willing to agree with your (John's) > proposal. Ned appears to be in the same boat that I am, so we > now have two who think that UTF-8 support in error messages > (LANG) does not need to be tied to UTF-8 support for email > addresses. >=20 > Not a strong opinion, and I'm happy to accept it either way, > but my preference would be to keep them separate. Note that there are two separate issues here: (1) Is support for UTF-8 (the charset) required if LANG is used, i.e., if LANG is offered, does the server have the right to transmit responses in UTF-8 (the charset)? The current version of the spec actually does say "yes". IMO, it does so in a way that is a bit too hard to find -- my initial quick reading didn't find it, which is what started this discussion thread and proposal. Worse, what it does say is "This and subsequent protocol-level human-readable text is encoded in the UTF-8 charset" which could be a little over-broad because _all_ POP3 exchanges are "human-readable text", thereby possibly making the LANG capability a superset of the UTF8 one. I don't think anyone intends, but that is what a plausible reading of the text says. (2) Given a "yes, if LANG is used the server must be able to send +OK and -ERR replies un UTF-8 (the charset)" answer, is the best way to enable that: (2.1) Make that a property of LANG, such that using the option authorizes the server to send non-ASCII responses (in UTF-8, the charset)? (This is Ned's proposal and probably what the existing text was intended to say.) (2.2) Require support for the whole EAI package in order for LANG to be used, i.e., the LANG capability requires the UTF8 capability. (This is my original proposal, consistent with what I thought was the "don't allow implementing pieces and subsets" conclusion about IMAP parameters on the call.) If the preference is 2.1, then does anyone want to review the IMAP parameter question? For the record, I actually don't have a strong preference between 2.1 and 2.2. I just want to be sure that we make a decision and that whatever decision we make is completely clear and obvious in the final text. john From arnt@gulbrandsen.priv.no Sat May 26 00:34:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0C421F8617 for ; Sat, 26 May 2012 00:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocmKywJ6dwDl for ; Sat, 26 May 2012 00:34:28 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 646F421F8613 for ; Sat, 26 May 2012 00:34:27 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 53953F8CC67; Sat, 26 May 2012 07:34:21 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1338017660-30847-30846/11/1; Sat, 26 May 2012 07:34:20 +0000 User-Agent: Kaiten Mail In-Reply-To: <2328D78E62789C17C2ABB5B8@PST.JCK.COM> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----PSV2UPOYGSTVFIX6H00JLIB2ZYUHQW From: Arnt Gulbrandsen Date: Sat, 26 May 2012 09:34:23 +0200 To: John C Klensin , Barry Leiba Message-Id: <181594dd-daa0-471e-bb60-db9df70cc343@email.android.com> Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 07:34:29 -0000 ------PSV2UPOYGSTVFIX6H00JLIB2ZYUHQW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maybe I'm woozy from too much travel now, but I can't tell which = question the imap parameter one refers to. Arnt ------PSV2UPOYGSTVFIX6H00JLIB2ZYUHQW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maybe I'm woozy from too much travel now, but I = can't tell which question the imap parameter one refers to.

Arnt ------PSV2UPOYGSTVFIX6H00JLIB2ZYUHQW-- From barryleiba.mailing.lists@gmail.com Sat May 26 06:02:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DA421F85FF for ; Sat, 26 May 2012 06:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIdPBd4FmYT7 for ; Sat, 26 May 2012 06:02:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7221F8589 for ; Sat, 26 May 2012 06:02:26 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1349646lbb.31 for ; Sat, 26 May 2012 06:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=49UvpU2ZuzvRwWHYLYFj5WgBCXDmcAYqt9nhiEi3/U4=; b=KBzdMZm2GDDiNDGy/1SBp1UgNmZLP27CLNlSGNXzy02FzrJm/tEr0VQDvgq4P0qtgH eC6l3tHvKmf81LS5K4H1uDCNwni0GkLsgRera+DK+AdG+lgYREpKoC04cW8KR6m5Yrf3 tephJOrPzwZ31Dnahvw3VPkfQL1ydqsZpfaQnni0ZYfFHstbcZtv7thHlqjEzYwmPWWz d3zEIz5Xdl/WwBKUN67QHckltA94QtNfniKeor/vWJTlwL+LofVtyC1VPo/dilse2CPV D73t4jKxSD5lyousvpJ48y4Qw1+BFeQBEgS8t6VnBJj1czFcECK6133+EwT53xm91FRn um5w== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr2349623lab.2.1338037345832; Sat, 26 May 2012 06:02:25 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 26 May 2012 06:02:25 -0700 (PDT) In-Reply-To: <2328D78E62789C17C2ABB5B8@PST.JCK.COM> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> Date: Sat, 26 May 2012 09:02:25 -0400 X-Google-Sender-Auth: T7-JFSK00ZDhBwuyIBlzP6KNTF0 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: multipart/alternative; boundary=bcaec54d4dd6b1cce804c0f018d0 Cc: Ned Freed , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 13:02:28 -0000 --bcaec54d4dd6b1cce804c0f018d0 Content-Type: text/plain; charset=ISO-8859-1 Yes, and I prefer 2.1 but would accept 2.2. b On Saturday, May 26, 2012, John C Klensin wrote: > > > --On Friday, May 25, 2012 19:30 -0400 Barry Leiba > > wrote: > > >... > >>> It also would be different if UTF8 was a snap to implement. > >>> But that's not the case either. LANG is *far* simpler than > >>> implementing UTF8, mostly because of downgrading. > >> > >> Ok. IMO, Ned's position is entirely reasonable. I don't > >> think I agree, but the difference is mostly a matter of > >> taste. Up to the WG. Those who have opinions, speak up. > >> If no one other than Ned and myself care, I'll either defer > >> to Ned's implementation experience or ask Joseph to flip a > >> coin. > > > > Well, I've already said that I don't see the reason to tie them > > together, but was willing to agree with your (John's) > > proposal. Ned appears to be in the same boat that I am, so we > > now have two who think that UTF-8 support in error messages > > (LANG) does not need to be tied to UTF-8 support for email > > addresses. > > > > Not a strong opinion, and I'm happy to accept it either way, > > but my preference would be to keep them separate. > > Note that there are two separate issues here: > > (1) Is support for UTF-8 (the charset) required if LANG is used, > i.e., if LANG is offered, does the server have the right to > transmit responses in UTF-8 (the charset)? The current version > of the spec actually does say "yes". IMO, it does so in a way > that is a bit too hard to find -- my initial quick reading > didn't find it, which is what started this discussion thread and > proposal. Worse, what it does say is "This and subsequent > protocol-level human-readable text is encoded in the UTF-8 > charset" which could be a little over-broad because _all_ POP3 > exchanges are "human-readable text", thereby possibly making the > LANG capability a superset of the UTF8 one. I don't think > anyone intends, but that is what a plausible reading of the text > says. > > (2) Given a "yes, if LANG is used the server must be able to > send +OK and -ERR replies un UTF-8 (the charset)" answer, is the > best way to enable that: > > (2.1) Make that a property of LANG, such that using the option > authorizes the server to send non-ASCII responses (in UTF-8, the > charset)? (This is Ned's proposal and probably what the > existing text was intended to say.) > > (2.2) Require support for the whole EAI package in order for > LANG to be used, i.e., the LANG capability requires the UTF8 > capability. (This is my original proposal, consistent with what > I thought was the "don't allow implementing pieces and subsets" > conclusion about IMAP parameters on the call.) > > If the preference is 2.1, then does anyone want to review the > IMAP parameter question? > > For the record, I actually don't have a strong preference > between 2.1 and 2.2. I just want to be sure that we make a > decision and that whatever decision we make is completely clear > and obvious in the final text. > > john > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > --bcaec54d4dd6b1cce804c0f018d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, and I prefer 2.1 but would accept 2.2.

b

On Saturday, May 26, 2012, John C Klensin wrote:


--On Friday, May 25, 2012 19:30 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

>...
>>> It also would be different if UTF8 was a snap to implement. >>> But that's not the case either. LANG is *far* simpler than=
>>> implementing UTF8, mostly because of downgrading.
>>
>> Ok. =A0IMO, Ned's position is entirely reasonable. =A0I don= 9;t
>> think I agree, but the difference is mostly a matter of
>> taste. =A0Up to the WG. =A0Those who have opinions, speak up.
>> =A0If no one other than Ned and myself care, I'll either defer=
>> to Ned's implementation experience or ask Joseph to flip a
>> coin.
>
> Well, I've already said that I don't see the reason to tie the= m
> together, but was willing to agree with your (John's)
> proposal. =A0Ned appears to be in the same boat that I am, so we
> now have two who think that UTF-8 support in error messages
> (LANG) does not need to be tied to UTF-8 support for email
> addresses.
>
> Not a strong opinion, and I'm happy to accept it either way,
> but my preference would be to keep them separate.

Note that there are two separate issues here:

(1) Is support for UTF-8 (the charset) required if LANG is used,
i.e., if LANG is offered, does the server have the right to
transmit responses in UTF-8 (the charset)? =A0The current version
of the spec actually does say "yes". =A0IMO, it does so in a way<= br> that is a bit too hard to find -- my initial quick reading
didn't find it, which is what started this discussion thread and
proposal. =A0Worse, what it does say is "This and subsequent
protocol-level human-readable text is encoded in the UTF-8
charset" which could be a little over-broad because _all_ POP3
exchanges are "human-readable text", thereby possibly making the<= br> LANG capability a superset of the UTF8 one. =A0I don't think
anyone intends, but that is what a plausible reading of the text
says.

(2) Given a "yes, if LANG is used the server must be able to
send +OK and -ERR replies un UTF-8 (the charset)" answer, is the
best way to enable that:

(2.1) Make that a property of LANG, such that using the option
authorizes the server to send non-ASCII responses (in UTF-8, the
charset)? =A0 (This is Ned's proposal and probably what the
existing text was intended to say.)

(2.2) Require support for the whole EAI package in order for
LANG to be used, i.e., the LANG capability requires the UTF8
capability. =A0(This is my original proposal, consistent with what
I thought was the "don't allow implementing pieces and subsets&quo= t;
conclusion about IMAP parameters on the call.)

If the preference is 2.1, then does anyone want to review the
IMAP parameter question?

For the record, I actually don't have a strong preference
between 2.1 and 2.2. =A0 I just want to be sure that we make a
decision and that whatever decision we make is completely clear
and obvious in the final text.

=A0 john
_______________________________________________
IMA mailing list
IMA@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ima
--bcaec54d4dd6b1cce804c0f018d0-- From klensin@jck.com Sat May 26 06:26:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1651721F8604 for ; Sat, 26 May 2012 06:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu4QaKMjD6M7 for ; Sat, 26 May 2012 06:26:24 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0C21F8603 for ; Sat, 26 May 2012 06:26:24 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SYGux-0005pg-Oc; Sat, 26 May 2012 09:20:27 -0400 Date: Sat, 26 May 2012 09:26:14 -0400 From: John C Klensin To: Barry Leiba Message-ID: <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> In-Reply-To: <2328D78E62789C17C2ABB5B8@PST.JCK.COM> References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 13:26:25 -0000 After thinking about this for a few more hours, I've changed my mind. See below. --On Saturday, May 26, 2012 02:26 -0400 John C Klensin wrote: >... > (2) Given a "yes, if LANG is used the server must be able to > send +OK and -ERR replies un UTF-8 (the charset)" answer, is > the best way to enable that: > > (2.1) Make that a property of LANG, such that using the option > authorizes the server to send non-ASCII responses (in UTF-8, > the charset)? (This is Ned's proposal and probably what the > existing text was intended to say.) > > (2.2) Require support for the whole EAI package in order for > LANG to be used, i.e., the LANG capability requires the UTF8 > capability. (This is my original proposal, consistent with > what I thought was the "don't allow implementing pieces and > subsets" conclusion about IMAP parameters on the call.) > > If the preference is 2.1, then does anyone want to review the > IMAP parameter question? > > For the record, I actually don't have a strong preference > between 2.1 and 2.2. I just want to be sure that we make a > decision and that whatever decision we make is completely clear > and obvious in the final text. Writing as an individual participant only... Mixing the principle of making minimal changes at this late date with Ned's reasoning, I've changed my mind about preferred outcome. I propose that we go with 2.1 and that we change the second sentence of the Section 2 discussion of LANG in 5721bis to read something like: "The LANG capability and command permit a POP3 client to negotiate which language the server uses when sending human-readable text in replies and changes the character set used in those replies from ASCII to Unicode encoded in UTF-8." That correctly explains what the LANG capability and command actually do up front, rather than burying the UTF-8 part in what appears to be almost an offhand comment. Others may still favor 2.2; if so, they should speak up. best, john From ned+ima@mrochek.com Sat May 26 07:01:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0521F85B1 for ; Sat, 26 May 2012 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2V0o9nzP58z for ; Sat, 26 May 2012 07:01:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D2DED21F85AF for ; Sat, 26 May 2012 07:01:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFXHFTTBCW0024LT@mauve.mrochek.com> for ima@ietf.org; Sat, 26 May 2012 07:01:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 26 May 2012 07:01:24 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OFXHFPWEO00006TF@mauve.mrochek.com> Date: Sat, 26 May 2012 06:59:08 -0700 (PDT) In-reply-to: "Your message dated Sat, 26 May 2012 09:26:14 -0400" <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> To: John C Klensin Cc: Barry Leiba , Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 14:01:48 -0000 > Mixing the principle of making minimal changes at this late date > with Ned's reasoning, I've changed my mind about preferred > outcome. I propose that we go with 2.1 and that we change the > second sentence of the Section 2 discussion of LANG in 5721bis > to read something like: > "The LANG capability and command permit a POP3 client to > negotiate which language the server uses when sending > human-readable text in replies and changes the character > set used in those replies from ASCII to Unicode encoded > in UTF-8." This wording seems fine to me - it makes it clear where UTF-8 can now be used. > That correctly explains what the LANG capability and command > actually do up front, rather than burying the UTF-8 part in what > appears to be almost an offhand comment. It was sufficiently offhand that I missed it completely. Ned From klensin@jck.com Sun May 27 07:13:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598B321F854C for ; Sun, 27 May 2012 07:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFZVJg12HjKT for ; Sun, 27 May 2012 07:13:44 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8114221F8542 for ; Sun, 27 May 2012 07:13:39 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SYe8B-0007XN-KX; Sun, 27 May 2012 10:07:39 -0400 Date: Sun, 27 May 2012 10:13:29 -0400 From: John C Klensin To: Jiankang YAO , ima@ietf.org Message-ID: <203308B3612DC1A557B2C145@PST.JCK.COM> In-Reply-To: References: <2F04F7925930F682E264E2CD@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] POP3 Spec and mail drop/ Mail store organization X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 14:13:45 -0000 --On Friday, May 25, 2012 17:32 +0800 Jiankang YAO wrote: > > ----- Original Message ----- > From: "John C Klensin" > To: > Sent: Thursday, May 17, 2012 6:11 AM > Subject: [EAI] POP3 Spec and mail drop/ Mail store organization >... >> (2) The second paragraph of Section 3.1 starts "Maildrops can >> natively store UTF-8 or be limited to ASCII." As the >> inclusive statement that appears to be, it is flat wrong. >> First, if the maildrop uses Unicode, we don't care what is >> stored "natively", with various flavors of UTF-16 or UTF-32 >> being likely (and common). We don't even care if messages >> are stored in whatever Charset arrives over the wire (and, >> indeed, storage of messages in the form in which they were >> delivered may be common). We require that headers be either >> ASCII or UTF-8 on the wire, but that says almost nothing >> about either maildrop storage form or message content. What >> we care about is that, if the messages are delivered across a >> POP3 interfaces with UTF-8 enabled, the header material is in >> UTF-8 on the wire and on delivery to the POP client. >> > > From my point of view, I see no problem of specifying > "Maildrops can natively store UTF-8 or be limited to ASCII." Either I didn't explain the problem very well or we are caught on a problem with English, or both. If you say, especially in IETF-speak, "Maildrops can natively store UTF-8 or be limited to ASCII", there is an implication of "and there are no other choices". It is possible to read it as implying "or they can store it in any of several other ways", but that would be uncommon. At best, the statement is ambiguous. As far as limiting the maildrop to UTF-8 or its ASCII subset (and nothing else), I'd expect many systems to store data in whatever form the operating system/file system uses, converting to and from UTF-8 only to handle data on the wire. So some systems might use one of the UTF-16 or UTF-32 variations internally, reflecting whoever they handled text. They might even use GB2312 or what the IETF calls ISO-2022-JP. While some of us might think that maintaining UTF-8 in the maildrop would be a good idea, there are good reasons why it might not be. Far more important, to the best of my knowledge we have never told an implementer how data must be represented while it is stored on their systems. There is also no justification for our doing do except, maybe, for shared file system environments (far outside EAI's scope): only data that appear on the wire can affect interoperability. > UTF-8 stored "natively", I think, is stored in UTF-8, not > UTF-16 or UTF-32 or some Content-transfer-encoding: base64. Yes, that is how I read your comment. I just think that it is necessary to allow systems to _store_ data in whatever native form works for them, not to try to somehow force them into UTF-8. > Section 3.1 said " Maildrops can natively store UTF-8 or be > limited to ASCII. UTF-8 mode has no effect on messages in > an ASCII-only maildrop. Messages > in native UTF-8 maildrops can be ASCII or UTF-8 using > internationalized headers [RFC6532] and/or 8bit > content-transfer- encoding, as defined in MIME Section 2.8 > [RFC2045]." Let me say this a different way: I don't think we have any business saying anything at all about "UTF-8 maildrops" except as a short form for "maildrops that are capable of receiving and sending information as Unicode codes encoded in UTF-8", I think the above hopelessly confuses "UTF-8 mode" (an EAI characteristic that describes certain capabilities, commands, and functionality), a UTF-8-capable maildrop (one that can receive information in UTF-8 form, store it, and deliver/return it in UTF-8 form without loss of information), and and the actual internal ("native") storage form of a maildrop. > Messages with some Content-transfer-encoding: base64, I think, > is a kind of "limited to ASCII" based on the text above. Sure it is. But whether the maildrop should store content in base64 or store it in some decoded form is an implementation decision as long as (i) there is no information loss, and (ii) for IMAP, the server pays careful attention to UIDVALIDITY as discussed earlier on the list. >> (3) The language about UTF-8 maildrops and messages can easily >> be read to imply that a message that arrives with >> >> From: non-ASCII-string@example.com >> To: non-ASCII-string@example.net >> [...] >> Content-type: text/plain; charset="GB2312" >> Content-transfer-encoding: base64 >> [...] >> > >> Is required to be decoded, converted to 'charset="UTF-8"', and >> then reencoded to base64. I don't think that is our >> intention: > > From the current words in section 3.1, I have seen no such > meaning too. Then why do you consider C-T-E;base64 to be relevant above. Again, I'm not at all sure we have any substantive disagreement. But it is _very_ easy to misunderstand the current text. >> the conversion is burdensome and POP servers may not even have >> the capability for all possible Charsets. But, whether it is >> or is not, the spec should be absolutely clear about what our >> requirement actually is. >> > > will try to refine it. thanks. john From duerst@it.aoyama.ac.jp Tue May 29 02:59:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00721F8794 for ; Tue, 29 May 2012 02:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.689 X-Spam-Level: X-Spam-Status: No, score=-99.689 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFY3VQSJdcvJ for ; Tue, 29 May 2012 02:59:18 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08021F8793 for ; Tue, 29 May 2012 02:59:15 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q4T9x2C0002376 for ; Tue, 29 May 2012 18:59:03 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1f0c_12e7_eb58a100_a974_11e1_aa30_001d096c5782; Tue, 29 May 2012 18:59:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:32961) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 29 May 2012 18:59:06 +0900 Message-ID: <4FC49DE2.9010201@it.aoyama.ac.jp> Date: Tue, 29 May 2012 18:58:58 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> In-Reply-To: <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Ned Freed , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 09:59:18 -0000 I'm fine with 2.1. In case we went for 2.2, I'd again want to propose that we'd actually not have a separate LANG capability, because implementing the LANG command on the server is, as Ned has said, fairly trivial, and even more so if it's only a trivial version (i.e. there's only a single language to 'choose' for, which is perfectly okay according to how I understand the spec). Regards, Martin. On 2012/05/26 22:26, John C Klensin wrote: > After thinking about this for a few more hours, I've changed my > mind. See below. > > --On Saturday, May 26, 2012 02:26 -0400 John C Klensin > wrote: > >> ... >> (2) Given a "yes, if LANG is used the server must be able to >> send +OK and -ERR replies un UTF-8 (the charset)" answer, is >> the best way to enable that: >> >> (2.1) Make that a property of LANG, such that using the option >> authorizes the server to send non-ASCII responses (in UTF-8, >> the charset)? (This is Ned's proposal and probably what the >> existing text was intended to say.) >> >> (2.2) Require support for the whole EAI package in order for >> LANG to be used, i.e., the LANG capability requires the UTF8 >> capability. (This is my original proposal, consistent with >> what I thought was the "don't allow implementing pieces and >> subsets" conclusion about IMAP parameters on the call.) >> >> If the preference is 2.1, then does anyone want to review the >> IMAP parameter question? >> >> For the record, I actually don't have a strong preference >> between 2.1 and 2.2. I just want to be sure that we make a >> decision and that whatever decision we make is completely clear >> and obvious in the final text. > > Writing as an individual participant only... > > Mixing the principle of making minimal changes at this late date > with Ned's reasoning, I've changed my mind about preferred > outcome. I propose that we go with 2.1 and that we change the > second sentence of the Section 2 discussion of LANG in 5721bis > to read something like: > > "The LANG capability and command permit a POP3 client to > negotiate which language the server uses when sending > human-readable text in replies and changes the character > set used in those replies from ASCII to Unicode encoded > in UTF-8." > > That correctly explains what the LANG capability and command > actually do up front, rather than burying the UTF-8 part in what > appears to be almost an offhand comment. > > Others may still favor 2.2; if so, they should speak up. > > best, > john > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From tony@att.com Tue May 29 05:59:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DA721F8754 for ; Tue, 29 May 2012 05:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.033 X-Spam-Level: X-Spam-Status: No, score=-104.033 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3YkeVNfIeMA for ; Tue, 29 May 2012 05:59:52 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id EB75321F869F for ; Tue, 29 May 2012 05:59:51 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 748c4cf4.0.296022.00-464.772879.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 29 May 2012 12:59:51 +0000 (UTC) X-MXL-Hash: 4fc4c8473dfaa5a5-2f5fb572a82ae6094e151ffc5284fca748a5e6bd Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4TCxp5J010192 for ; Tue, 29 May 2012 08:59:51 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4TCxjCm010148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 May 2012 08:59:46 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 29 May 2012 08:59:33 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4TCxWl2025834 for ; Tue, 29 May 2012 08:59:32 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4TCxUcY025771 for ; Tue, 29 May 2012 08:59:31 -0400 Received: from [135.70.146.187] (vpn-135-70-146-187.vpn.mwst.att.com[135.70.146.187]) by maillennium.att.com (mailgw1) with ESMTP id <20120529125551gw10060loie> (Authid: tony); Tue, 29 May 2012 12:55:51 +0000 X-Originating-IP: [135.70.146.187] Message-ID: <4FC4C831.60400@att.com> Date: Tue, 29 May 2012 08:59:29 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ima@ietf.org References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> In-Reply-To: <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=ca2K3SKX16oA:10 a=4JAii899aesA:10 a=ANB9XOjaQQ] X-AnalysisOut: [QA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=E7dcTn56-gMxa8-G1EgA:9 a] X-AnalysisOut: [=wPNLvfGTeEIA:10] Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 12:59:52 -0000 On 5/26/2012 9:26 AM, John C Klensin wrote: > Writing as an individual participant only... > > Mixing the principle of making minimal changes at this late date > with Ned's reasoning, I've changed my mind about preferred > outcome. I propose that we go with 2.1 and that we change the > second sentence of the Section 2 discussion of LANG in 5721bis > to read something like: > > "The LANG capability and command permit a POP3 client to > negotiate which language the server uses when sending > human-readable text in replies and changes the character > set used in those replies from ASCII to Unicode encoded > in UTF-8." > > That correctly explains what the LANG capability and command > actually do up front, rather than burying the UTF-8 part in what > appears to be almost an offhand comment. I'm happy with this text. Tony From Shawn.Steele@microsoft.com Tue May 29 16:08:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3952411E8173 for ; Tue, 29 May 2012 16:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id intedP8KpNA7 for ; Tue, 29 May 2012 16:08:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9299F11E80F2 for ; Tue, 29 May 2012 16:08:20 -0700 (PDT) Received: from mail176-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 May 2012 23:07:56 +0000 Received: from mail176-va3 (localhost [127.0.0.1]) by mail176-va3-R.bigfish.com (Postfix) with ESMTP id 82EE01A01B0 for ; Tue, 29 May 2012 23:07:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail176-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail176-va3 (localhost.localdomain [127.0.0.1]) by mail176-va3 (MessageSwitch) id 133833287445927_10327; Tue, 29 May 2012 23:07:54 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.237]) by mail176-va3.bigfish.com (Postfix) with ESMTP id F2D1C160045 for ; Tue, 29 May 2012 23:07:53 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 May 2012 23:07:53 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 29 May 2012 23:07:54 +0000 Received: from mail126-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 May 2012 23:06:56 +0000 Received: from mail126-tx2 (localhost [127.0.0.1]) by mail126-tx2-R.bigfish.com (Postfix) with ESMTP id 07C9CC03F3 for ; Tue, 29 May 2012 23:06:56 +0000 (UTC) Received: from mail126-tx2 (localhost.localdomain [127.0.0.1]) by mail126-tx2 (MessageSwitch) id 1338332814540259_9596; Tue, 29 May 2012 23:06:54 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.249]) by mail126-tx2.bigfish.com (Postfix) with ESMTP id 81282220044 for ; Tue, 29 May 2012 23:06:54 +0000 (UTC) Received: from BY2PRD0310HT002.namprd03.prod.outlook.com (157.56.236.5) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 May 2012 23:06:54 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.199]) by BY2PRD0310HT002.namprd03.prod.outlook.com ([10.255.80.37]) with mapi id 14.16.0152.000; Tue, 29 May 2012 23:07:15 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: LANG, UTF-8, and POP3 Thread-Index: Ac097y/+CqsXnr5wRMKS7gFtbqpxQg== Date: Tue, 29 May 2012 23:07:14 +0000 Message-ID: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 23:08:26 -0000 While, technically I agree that LANG shouldn't depend on UTF8, and I think = it's not really needed, I'm happy with keeping it. I'm also happy with req= uiring UTF8 because, while LANG might be easier, certainly UTF8 is much mor= e important to the entire mail ecosystem and I'd much prefer developers spe= nd time getting UTF8 right. If that makes one extra app have UTF8 because = they wanted LANG, I can live with that :) So I prefer the 2.2: Use of LANG requires UTF8 support, because that pushe= s the message that UTF8 support is important. -Shawn From barryleiba.mailing.lists@gmail.com Tue May 29 16:49:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EC311E8160 for ; Tue, 29 May 2012 16:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqWzUgIVTW5M for ; Tue, 29 May 2012 16:49:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1811E8125 for ; Tue, 29 May 2012 16:49:40 -0700 (PDT) Received: by lagv3 with SMTP id v3so3318230lag.31 for ; Tue, 29 May 2012 16:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/4oGs5XCZ4+gS7ZR79ao/d6w4gNL70/7aAqlxEHYr+E=; b=cruOHgtb8oUCEIs7zR2kfP4aDYS5i5X5L50VEDcFasZPEx0DpIFqAA71ua7XXBTwoo jCebc8FdkHoD5lyuhvWSyxPyv/bc1zUXUH+y8IdbOyeu+gzBs2vfFgNPfdEFpGz79viK serALoJwCTgoo3ynv28XgzDuvLuTbg59Z2nt7HfCxHLXVw99K8JkJHMkS9lU9zH5jC3R XZ/Wv5gxZKH1f++24qTLkaXLu6qn9l4+2EpPXSMaIJ9HxFzPf89zY2LgSoZKyV6Oyp6A nn3ZbTrEMVbAHG7TTlkqJQ2wHWmT893HHXsI+t6Bwi4o7J+d6MrtEz5OGumMC++tC3CB OkLw== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr13218825lab.2.1338335379695; Tue, 29 May 2012 16:49:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Tue, 29 May 2012 16:49:39 -0700 (PDT) In-Reply-To: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> Date: Tue, 29 May 2012 19:49:39 -0400 X-Google-Sender-Auth: kVs4Garek_uqf8Jv_eVk956wauU Message-ID: From: Barry Leiba To: Shawn Steele Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 23:49:41 -0000 > So I prefer the 2.2: =A0Use of LANG requires UTF8 support, because that p= ushes > the message that UTF8 support is important. Sorry: I have to push back on this rather strongly. We should not be making protocol decisions because we want to push any messages about importance. We need to make protocol decisions based on what's right for the protocol. Barry From ned+ima@mrochek.com Tue May 29 16:54:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDD811E8177 for ; Tue, 29 May 2012 16:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2LhyvwS0lTs for ; Tue, 29 May 2012 16:54:06 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1393711E8125 for ; Tue, 29 May 2012 16:54:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG290GFIE8002JWF@mauve.mrochek.com> for ima@ietf.org; Tue, 29 May 2012 16:54:01 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFYZ0QA6000006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 29 May 2012 16:53:54 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OG290D214A0006TF@mauve.mrochek.com> Date: Tue, 29 May 2012 16:52:12 -0700 (PDT) In-reply-to: "Your message dated Tue, 29 May 2012 19:49:39 -0400" References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> To: Barry Leiba Cc: Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 23:54:06 -0000 > > So I prefer the 2.2:  Use of LANG requires UTF8 support, because that pushes > > the message that UTF8 support is important. > Sorry: I have to push back on this rather strongly. > We should not be making protocol decisions because we want to push any > messages about importance. We need to make protocol decisions based > on what's right for the protocol. Although I disagree with Shawn, I wasn't going to comment on it until I saw this. Barry, you are of course correct. Pushing decisions about what's important through protocol decisions is a bad thing, and especially when it results in a coupling that doesn't need to be there. Ned From Shawn.Steele@microsoft.com Tue May 29 17:58:35 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF921F8705 for ; Tue, 29 May 2012 17:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjwANa1baqTs for ; Tue, 29 May 2012 17:58:35 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id C283B21F8704 for ; Tue, 29 May 2012 17:58:34 -0700 (PDT) Received: from mail43-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 00:58:10 +0000 Received: from mail43-am1 (localhost [127.0.0.1]) by mail43-am1-R.bigfish.com (Postfix) with ESMTP id 257356025F for ; Wed, 30 May 2012 00:58:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VS-6(zz1432Nzz1202hzzz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail43-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail43-am1 (localhost.localdomain [127.0.0.1]) by mail43-am1 (MessageSwitch) id 133833948921710_19959; Wed, 30 May 2012 00:58:09 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.226]) by mail43-am1.bigfish.com (Postfix) with ESMTP id 03D9740049 for ; Wed, 30 May 2012 00:58:09 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 00:58:07 +0000 Received: from CH1EHSOBE003.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 30 May 2012 00:58:29 +0000 Received: from mail146-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 00:58:04 +0000 Received: from mail146-ch1 (localhost [127.0.0.1]) by mail146-ch1-R.bigfish.com (Postfix) with ESMTP id A28FA2009A for ; Wed, 30 May 2012 00:58:04 +0000 (UTC) Received: from mail146-ch1 (localhost.localdomain [127.0.0.1]) by mail146-ch1 (MessageSwitch) id 1338339482760096_3706; Wed, 30 May 2012 00:58:02 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail146-ch1.bigfish.com (Postfix) with ESMTP id B43083C0069; Wed, 30 May 2012 00:58:02 +0000 (UTC) Received: from BY2PRD0310HT005.namprd03.prod.outlook.com (157.56.236.5) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 00:58:02 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.199]) by BY2PRD0310HT005.namprd03.prod.outlook.com ([10.255.80.40]) with mapi id 14.16.0152.000; Wed, 30 May 2012 00:58:25 +0000 From: Shawn Steele To: Ned Freed , Barry Leiba Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNPfXIBB4hHTljhkOmJni472vZgZbhcNkpgAAMxKA= Date: Wed, 30 May 2012 00:58:24 +0000 Message-ID: <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> In-Reply-To: <01OG290D214A0006TF@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:58:35 -0000 > > Sorry: I have to push back on this rather strongly. > > We should not be making protocol decisions because we want to push any= =20 > > messages about importance. We need to make protocol decisions based=20 > > on what's right for the protocol. > Barry, you are of course correct. Pushing decisions about what's importan= t > through protocol decisions is a bad thing In that case LANG shouldn't be there. It's doing the same thing in reverse= . Either LANG's important for UTF-8 mail, or it's not. But it was argued = that at this point it should be left in basically for processes, which seem= s way worse than for "what's important". And, although I buy the higher level philosophical point, as devil's advoca= te isn't every protocol decision a decision about what's important? Eg: co= ol but unimportant things are often just left out. Other things get a MUST= because they're the right thing to do, not necessarily because there are t= echnical limitations that force their presence. For example, 3492 is very = permissive, allowing Punycode most anywhere. However 6530 discourages that= practice in EAI. If LANG is permitted without UTF-8 mail, then there are a bunch of question= s about code pages, encodings, etc. Technically they could probably be sol= ved, or ignored, but it works way better with UTF-8 mail. If a solution is= solved (or ignored) that allows LANG not requiring UTF-8, then I MUST test= LANG and no UTF-8 for interoperability, even if I have no intention in sup= porting the LANG w/o UTF8 case in my client or server. That protocol decis= ion adds overhead and complexity for every application developer for a scen= ario that we've all pretty much agreed is a not a desirable case. That mea= ns less time fixing real bugs or adding meaningful extensions to the standa= rd. So I think it's fair to ask for a baseline of support for new features= , in this case supporting UTF8 when supporting LANG. Making protocol decisions without considering the total cost of those decis= ions is also a bad thing. That said, I may have misused the word "important". LANG opens up the prob= lems of other scripts and stuff, which leads to the 3 options mentioned bef= ore: Require UTF8, restrict it to ASCII, or figure out how to declare/enco= de stuff in other encodings. Since our entire set of RFCs is trying to adv= ocate UTF8 over the current mixed up mail encoding story, the 3rd option se= ems a non-starter. So requiring UTF8 for LANG seems reasonable as the simp= lest way to get reliable LANG support. -Shawn From klensin@jck.com Tue May 29 21:20:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B8A11E80A5 for ; Tue, 29 May 2012 21:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQgm8V0y3PNg for ; Tue, 29 May 2012 21:20:21 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E035021F8623 for ; Tue, 29 May 2012 21:20:20 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SZaIR-000F26-76; Wed, 30 May 2012 00:14:07 -0400 Date: Wed, 30 May 2012 00:20:00 -0400 From: John C Klensin To: Shawn Steele , Ned Freed , Barry Leiba Message-ID: <9981FFF8F47099C952F9DD43@PST.JCK.COM> In-Reply-To: <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.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] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 04:20:23 -0000 Speaking personally only. I think we have a combination of a misunderstanding or two and a legitimate philosophical disagreement here. Mainly... --On Wednesday, May 30, 2012 00:58 +0000 Shawn Steele wrote: >> > Sorry: I have to push back on this rather strongly. >> > We should not be making protocol decisions because we want >> > to push any messages about importance. We need to make >> > protocol decisions based on what's right for the protocol. > >> Barry, you are of course correct. Pushing decisions about >> what's important through protocol decisions is a bad thing > > In that case LANG shouldn't be there. It's doing the same > thing in reverse. Either LANG's important for UTF-8 mail, or > it's not. But it was argued that at this point it should be > left in basically for processes, which seems way worse than > for "what's important". I don't think anyone has argued "for processes". Some, including myself, have argued that the time to get rid of (or not have) LANG was long ago and that, if we are going to make progress, we should not reopen old issues without compelling need. That really isn't a process issue but a somewhat different management one. That said, there is a strong case for removing LANG entirely that has nothing to do with importance. While "ask the server to do what you want" is always a tempting design issue, good protocol designs are almost always minimal, with as few extra options or features as possible. It is also almost always better to use a canonical form on the wire and let the systems at each end convert that to local form as necessary than to convert an "each client needs to convert from the canonical form to what it needs" problem into one in which each server has to support all possible forms to make clients happy. The case is not that straightforward for POP3 and LANG for two reasons. One is that POP3's reply structure is not particularly friendly to a canonical form approach. It differs in that respect from systems that return canonical codes that contain most of the needed information as part of the effort response. The other is that the list of preferred languages approach permits any given server to make its own decisions about what languages to support with, at least in principle, no pressure to support everything. Whether those two characteristics add enough value to overcome what I believe should be a bias against complexity and _any_ extra commands and capabilities unless they are clearly necessary, is a question on which the WG needs to decide (and, I suggest, decided many months ago). > And, although I buy the higher level philosophical point, as > devil's advocate isn't every protocol decision a decision > about what's important? Eg: cool but unimportant things are > often just left out. Other things get a MUST because they're > the right thing to do, not necessarily because there are > technical limitations that force their presence. For example, > 3492 is very permissive, allowing Punycode most anywhere. > However 6530 discourages that practice in EAI. Right. However... > If LANG is permitted without UTF-8 mail, then there are a > bunch of questions about code pages, encodings, etc. > Technically they could probably be solved, or ignored, but it > works way better with UTF-8 mail. If a solution is solved (or > ignored) that allows LANG not requiring UTF-8, then I MUST > test LANG and no UTF-8 for interoperability, even if I have no > intention in supporting the LANG w/o UTF8 case in my client or > server. That protocol decision adds overhead and complexity > for every application developer for a scenario that we've all > pretty much agreed is a not a desirable case. That means less > time fixing real bugs or adding meaningful extensions to the > standard. So I think it's fair to ask for a baseline of > support for new features, in this case supporting UTF8 when > supporting LANG. I don't see this problem. You are making the same assumption about what LANG specifies that Ned and I did after a few readings, i.e., that LANG didn't imply/require character set support at all. What LANG actually says is that, if it is enabled, the server gets to send messages associated with the negotiated language in UTF-8 coding. So no code page or encoding issues, just UTF-8. And your interoperability testing issue is limited to being sure that a client that enables LANG can handle receiving UTF-8 responses (presumably not burdensome). The server burden is one of keeping different response tables for each language you choose to support... and you need not support any at all, or even have such tables, to conform to the requirements of the spec. The fact that wasn't crystal-clear is exactly why I proposed new text and placement to clarify the relationship. > Making protocol decisions without considering the total cost > of those decisions is also a bad thing. Agreed. > That said, I may have misused the word "important". LANG > opens up the problems of other scripts and stuff, which leads > to the 3 options mentioned before: Require UTF8, restrict it > to ASCII, or figure out how to declare/encode stuff in other > encodings. Since our entire set of RFCs is trying to advocate > UTF8 over the current mixed up mail encoding story, the 3rd > option seems a non-starter. So requiring UTF8 for LANG seems > reasonable as the simplest way to get reliable LANG support. And that is what the current text says and the clarification reinforces. best, john From Shawn.Steele@microsoft.com Tue May 29 22:06:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A721F86F5 for ; Tue, 29 May 2012 22:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73Mk4uVtHvlg for ; Tue, 29 May 2012 22:06:18 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1EACF21F86F4 for ; Tue, 29 May 2012 22:06:16 -0700 (PDT) Received: from mail195-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 05:05:52 +0000 Received: from mail195-tx2 (localhost [127.0.0.1]) by mail195-tx2-R.bigfish.com (Postfix) with ESMTP id 08D854A04A4 for ; Wed, 30 May 2012 05:05:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail195-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail195-tx2 (localhost.localdomain [127.0.0.1]) by mail195-tx2 (MessageSwitch) id 13383543505141_17394; Wed, 30 May 2012 05:05:50 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.240]) by mail195-tx2.bigfish.com (Postfix) with ESMTP id E8676460049 for ; Wed, 30 May 2012 05:05:49 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 05:05:50 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 30 May 2012 05:05:54 +0000 Received: from mail109-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 05:05:28 +0000 Received: from mail109-am1 (localhost [127.0.0.1]) by mail109-am1-R.bigfish.com (Postfix) with ESMTP id B85883A01A7 for ; Wed, 30 May 2012 05:05:28 +0000 (UTC) Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1 (MessageSwitch) id 133835432614747_5176; Wed, 30 May 2012 05:05:26 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.244]) by mail109-am1.bigfish.com (Postfix) with ESMTP id 01136400047; Wed, 30 May 2012 05:05:26 +0000 (UTC) Received: from BY2PRD0310HT004.namprd03.prod.outlook.com (157.56.236.5) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 05:05:25 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.199]) by BY2PRD0310HT004.namprd03.prod.outlook.com ([10.255.80.39]) with mapi id 14.16.0152.000; Wed, 30 May 2012 05:05:47 +0000 From: Shawn Steele To: John C Klensin , Ned Freed , Barry Leiba Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNPfXIBB4hHTljhkOmJni472vZgZbhcNkpgAAMxKCAAD1rAIAADKRw Date: Wed, 30 May 2012 05:05:46 +0000 Message-ID: <352CBC94712DF44392EE468860B35D30CBCB2C@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <9981FFF8F47099C952F9DD43@PST.JCK.COM> In-Reply-To: <9981FFF8F47099C952F9DD43@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JCK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 05:06:38 -0000 Well, regardless of the methodology, it sounds like we're in violent agreem= ent with the result :) -----Original Message----- From: John C Klensin [mailto:klensin@jck.com]=20 Sent: Tuesday, May 29, 2012 9:20 PM To: Shawn Steele; Ned Freed; Barry Leiba Cc: ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 Speaking personally only. I think we have a combination of a misunderstand= ing or two and a legitimate philosophical disagreement here. Mainly... --On Wednesday, May 30, 2012 00:58 +0000 Shawn Steele wrote: >> > Sorry: I have to push back on this rather strongly. >> > We should not be making protocol decisions because we want to push=20 >> > any messages about importance. We need to make protocol decisions=20 >> > based on what's right for the protocol. >=20 >> Barry, you are of course correct. Pushing decisions about what's=20 >> important through protocol decisions is a bad thing >=20 > In that case LANG shouldn't be there. It's doing the same thing in=20 > reverse. Either LANG's important for UTF-8 mail, or it's not. But it=20 > was argued that at this point it should be left in basically for=20 > processes, which seems way worse than for "what's important". I don't think anyone has argued "for processes". Some, including myself, h= ave argued that the time to get rid of (or not have) LANG was long ago and = that, if we are going to make progress, we should not reopen old issues wit= hout compelling need. That really isn't a process issue but a somewhat dif= ferent management one. That said, there is a strong case for removing LANG= entirely that has nothing to do with importance. While "ask the server to do what you want" is always a tempting design issu= e, good protocol designs are almost always minimal, with as few extra optio= ns or features as possible. It is also almost always better to use a canon= ical form on the wire and let the systems at each end convert that to local= form as necessary than to convert an "each client needs to convert from th= e canonical form to what it needs" problem into one in which each server ha= s to support all possible forms to make clients happy. The case is not that straightforward for POP3 and LANG for two reasons. On= e is that POP3's reply structure is not particularly friendly to a canonica= l form approach. It differs in that respect from systems that return canon= ical codes that contain most of the needed information as part of the effor= t response. The other is that the list of preferred languages approach permits any give= n server to make its own decisions about what languages to support with, at= least in principle, no pressure to support everything. Whether those two = characteristics add enough value to overcome what I believe should be a bia= s against complexity and _any_ extra commands and capabilities unless they = are clearly necessary, is a question on which the WG needs to decide (and, = I suggest, decided many months ago). > And, although I buy the higher level philosophical point, as devil's=20 > advocate isn't every protocol decision a decision about what's=20 > important? Eg: cool but unimportant things are often just left out. =20 > Other things get a MUST because they're the right thing to do, not=20 > necessarily because there are technical limitations that force their=20 > presence. For example, > 3492 is very permissive, allowing Punycode most anywhere. > However 6530 discourages that practice in EAI. Right. However... > If LANG is permitted without UTF-8 mail, then there are a bunch of=20 > questions about code pages, encodings, etc. > Technically they could probably be solved, or ignored, but it works=20 > way better with UTF-8 mail. If a solution is solved (or > ignored) that allows LANG not requiring UTF-8, then I MUST test LANG=20 > and no UTF-8 for interoperability, even if I have no intention in=20 > supporting the LANG w/o UTF8 case in my client or server. That=20 > protocol decision adds overhead and complexity for every application=20 > developer for a scenario that we've all pretty much agreed is a not a=20 > desirable case. That means less time fixing real bugs or adding=20 > meaningful extensions to the standard. So I think it's fair to ask=20 > for a baseline of support for new features, in this case supporting=20 > UTF8 when supporting LANG. I don't see this problem. You are making the same assumption about what LA= NG specifies that Ned and I did after a few readings, i.e., that LANG didn'= t imply/require character set support at all. What LANG actually says is t= hat, if it is enabled, the server gets to send messages associated with the= negotiated language in UTF-8 coding. So no code page or encoding issues, = just UTF-8. And your interoperability testing issue is limited to being su= re that a client that enables LANG can handle receiving UTF-8 responses (pr= esumably not burdensome). The server burden is one of keeping different re= sponse tables for each language you choose to support... and you need not s= upport any at all, or even have such tables, to conform to the requirements= of the spec. The fact that wasn't crystal-clear is exactly why I proposed new text and p= lacement to clarify the relationship. > Making protocol decisions without considering the total cost of those=20 > decisions is also a bad thing. Agreed. > That said, I may have misused the word "important". LANG opens up the=20 > problems of other scripts and stuff, which leads to the 3 options=20 > mentioned before: Require UTF8, restrict it to ASCII, or figure out=20 > how to declare/encode stuff in other encodings. Since our entire set=20 > of RFCs is trying to advocate > UTF8 over the current mixed up mail encoding story, the 3rd option=20 > seems a non-starter. So requiring UTF8 for LANG seems reasonable as=20 > the simplest way to get reliable LANG support. And that is what the current text says and the clarification reinforces. best, john From ned+ima@mrochek.com Tue May 29 22:41:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476B911E80C9 for ; Tue, 29 May 2012 22:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtLycmObmgB8 for ; Tue, 29 May 2012 22:41:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 85E0321F845F for ; Tue, 29 May 2012 22:41:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG2L5CKNTC002E2I@mauve.mrochek.com> for ima@ietf.org; Tue, 29 May 2012 22:41:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFYZ0QA6000006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 29 May 2012 22:41:27 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OG2L596P9K0006TF@mauve.mrochek.com> Date: Tue, 29 May 2012 21:50:05 -0700 (PDT) In-reply-to: "Your message dated Wed, 30 May 2012 00:58:24 +0000" <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> To: Shawn Steele Cc: Barry Leiba , Ned Freed , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 05:41:46 -0000 > > > Sorry: I have to push back on this rather strongly. > > > We should not be making protocol decisions because we want to push any > > > messages about importance. We need to make protocol decisions based > > > on what's right for the protocol. > > Barry, you are of course correct. Pushing decisions about what's important > > through protocol decisions is a bad thing > In that case LANG shouldn't be there. It's doing the same thing in reverse. It does nothing of the sort. > Either LANG's important for UTF-8 mail, or it's not. You're once again falling into the trap Barry warned about. This is about creating standards with the greatest possible utility, not about trying to assess importance, or worse, trying to use standards language to force a notion of what we happen to think is important down people's throats. Given the limitations of POP error codes, by providing the ability to select a language and return responses in UTF-8, LANG provides a better client internationalization experience. This improvement is actually largely independent of whether the UTF8 capability is used to provide support for downloading EAI messages, especially since email already has significant internationalization facilities. This argues strongly for it to be possible to implement the LANG capability without also requiring the ability to use the UTF8 capability. > But it was argued that at this point it should be left in basically for > processes, which seems way worse than for "what's important". That certainly isn't the point I've been making. This has essentially nothing to do with process and everything to do with the utility of the outcome. > And, although I buy the higher level philosophical point, as devil's advocate > isn't every protocol decision a decision about what's important? Nope. It's about utility. Very different. > Eg: cool but unimportant things are often just left out. Other things get a > MUST because they're the right thing to do, not necessarily because there are > technical limitations that force their presence. For example, 3492 is very > permissive, allowing Punycode most anywhere. However 6530 discourages that > practice in EAI. That's the result of a technical assessment. (It happens to be one I actually disagree with, but I accept that it's the consensus of the group.) > If LANG is permitted without UTF-8 mail, then there are a bunch of questions > about code pages, encodings, etc. Nobody is saying that LANG should provide the ability to produce responses in any charset other than UTF-8. There's only one code page and one encoding on the table. You appear to be confusing the UTF8 *capability*, which provides the ability to download EAI messages in POP, with the UTF-8 *charset*. When people talk about LANG requiring UTF8, they are talking about coupling the capabilities with each other. They are most definitely not talking about allowing LANG to return responses in charsets other than UTF-8. That's completely off in left field. > Technically they could probably be solved, or ignored, but it works way better > with UTF-8 mail. If a solution is solved (or ignored) that allows LANG not > requiring UTF-8, See above. This is effectively a strawman. All we are saying is that servers should be allowed to support the LANG *capability* without also requiring support for the UTF8 *capability*. > then I MUST test LANG and no UTF-8 for interoperability, even if I have no > intention in supporting the LANG w/o UTF8 case in my client or server. Again, this is not about being able to use other charsets with LANG. As for the UTF8 capability, whether or not we require servers to support it if they support LANG has no impact on your test cases, for several reasons: (1) Nothing about server-side requirements has any impact on what clients may do - a client may choose to activate neither capability, LANG by itself, UTF8 by itself, or both. So if you implement both, your test cases have to cover all of the combinations in order to account for all possible client behavior. (2) If as you say, your client is going to require both capabilities, then the only server it is going to work with is one that offers both extensions, and that's the only case you need to test. This means you may not work with some servers, but that's your choice as an implementor to make. (3) The only place these capabilities actually overlap would be if there are internationalized error responses specific to UTF8 capability. That's not much overlap, so even if you decide to support one without the other in your client, it's not a significant test burden since the tests are mostly indepedent of each other. > That protocol decision adds overhead and complexity for every application > developer for a scenario that we've all pretty much agreed is a not a desirable case. It does no such thing. See above. > That means less time fixing real bugs or adding meaningful extensions to the > standard. So I think it's fair to ask for a baseline of support for new > features, in this case supporting UTF8 when supporting LANG. I'm afraid as a result of an apparent misunderstanding of the discussion, your analysis is flawed and therefore your conclusions are erroneous. > Making protocol decisions without considering the total cost of those > decisions is also a bad thing. > That said, I may have misused the word "important". LANG opens up the > problems of other scripts and stuff, which leads to the 3 options mentioned > before: Require UTF8, restrict it to ASCII, or figure out how to > declare/encode stuff in other encodings. > Since our entire set of RFCs is trying to advocate UTF8 over the current mixed > up mail encoding story, the 3rd option seems a non-starter. So requiring UTF8 > for LANG seems reasonable as the simplest way to get reliable LANG support. Again, since nobody is proposing anything like that, this amounts to nothing but a strawman. Ned From Shawn.Steele@microsoft.com Wed May 30 00:52:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6521F86D7 for ; Wed, 30 May 2012 00:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c4Mz4i4lN7I for ; Wed, 30 May 2012 00:52:31 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id EA52121F86F7 for ; Wed, 30 May 2012 00:52:30 -0700 (PDT) Received: from mail28-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 30 May 2012 07:52:05 +0000 Received: from mail28-va3 (localhost [127.0.0.1]) by mail28-va3-R.bigfish.com (Postfix) with ESMTP id 8D469440192 for ; Wed, 30 May 2012 07:52:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz146fIzz1202hzzz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail28-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail28-va3 (localhost.localdomain [127.0.0.1]) by mail28-va3 (MessageSwitch) id 1338364322911209_13307; Wed, 30 May 2012 07:52:02 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.245]) by mail28-va3.bigfish.com (Postfix) with ESMTP id DB4B6400049 for ; Wed, 30 May 2012 07:52:02 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 07:52:02 +0000 Received: from CH1EHSOBE002.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 30 May 2012 07:52:07 +0000 Received: from mail80-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 07:51:42 +0000 Received: from mail80-ch1 (localhost [127.0.0.1]) by mail80-ch1-R.bigfish.com (Postfix) with ESMTP id 03B85480336 for ; Wed, 30 May 2012 07:51:42 +0000 (UTC) Received: from mail80-ch1 (localhost.localdomain [127.0.0.1]) by mail80-ch1 (MessageSwitch) id 1338364299775577_20177; Wed, 30 May 2012 07:51:39 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail80-ch1.bigfish.com (Postfix) with ESMTP id B91E64600AA; Wed, 30 May 2012 07:51:39 +0000 (UTC) Received: from BY2PRD0310HT001.namprd03.prod.outlook.com (157.56.236.5) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 07:51:39 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.199]) by BY2PRD0310HT001.namprd03.prod.outlook.com ([10.255.80.36]) with mapi id 14.16.0152.000; Wed, 30 May 2012 07:52:02 +0000 From: Shawn Steele To: Ned Freed Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNPfXIBB4hHTljhkOmJni472vZgZbhcNkpgAAMxKCAAFRo6oAAHlnQ Date: Wed, 30 May 2012 07:52:01 +0000 Message-ID: <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> In-Reply-To: <01OG2L596P9K0006TF@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Barry Leiba , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 07:52:32 -0000 > This is about creating standards with the greatest possible utility, not = about trying to > assess importance, or worse, trying to use standards language to force a = notion of=20 > what we happen to think is important down people's throats. Features is not necessarily =3D=3D utility. Standards, by necessity, "forc= e what the authors happen to think is important down people's throats." No= matter how excellent the standard, people can be found that disagree with = that standard, either in large parts or small parts. Standards are limited to what the authors think is important. (If they did= n't think it was important, they wouldn't waste time including it in the st= andard). Hopefully there is consensus and a great process driving those de= cisions. I think we've done a decent job. For example, if we were striving for "greatest possible utility", I'd sugge= st that a more flexible approach would have been to not create "SMTPUTF8", = but rather "SMTPCP", with a mechanism for selecting from an unlimited set o= f code pages. We all decided that UTF8 and consistency was more important = for EAI than allowing people to pick their favorite code page. We sacrific= ed potential utility for the uniformity we perceived was more important. S= omeone stuck maintaining a system with some awkward code page may well have= preferred if we'd come to a different conclusion. Standards, IMO, are around to create interoperable systems. Many permitted= variations make the systems more complex and hinder the interoperability. = So, IMO, it's completely fair to require UTF8 for LANG in order to reduce = the complexity of the system. I do not think that allowing additional code= pages, particularly since it would introduce ambiguity or some complex dec= laration system, would provide more "utility". In fact I think it'd be les= s useful than a LANG that was unambiguous in its encoding. But I'd like to point out that it shouldn't be "forcing what the authors th= ink is important down people's throats". It should be what the WG has deci= ded is realistic and reasonable for the entire ecosystem and the long term = goals of the standard and related standards. IMO EAI cannot succeed withou= t widespread UTF8 adoption, so adding things to an EAI standard that encour= age deviating from UTF8 could only delay EAI adoption, conflicting with the= core goal of EAI adoption that this WG is trying to achieve. Anyway, this is a philosophical discussion is sort of orthogonal to what we= 're doing here. I'm fine with what John's been proposing, though there see= ms to be some disagreement since John just said "That is what the current t= ext says" and Ned said "nobody is proposing anything like that" :) -Shawn From klensin@jck.com Wed May 30 03:50:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588721F8682 for ; Wed, 30 May 2012 03:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTTIuPT5pbQF for ; Wed, 30 May 2012 03:50:40 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80A21F867F for ; Wed, 30 May 2012 03:50:40 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SZgOJ-000Fmf-6M; Wed, 30 May 2012 06:44:35 -0400 Date: Wed, 30 May 2012 06:50:29 -0400 From: John C Klensin To: Shawn Steele , Ned Freed , Barry Leiba Message-ID: <285049ABFE0BF6EEBB277606@PST.JCK.COM> In-Reply-To: <352CBC94712DF44392EE468860B35D30CBCB2C@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <9981FFF8F47099C952F9DD43@PST.JCK.COM> <352CBC94712DF44392EE468860B35D30CBCB2C@BY2PRD0310MB388.namprd03.prod.outlook.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] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 10:50:41 -0000 --On Wednesday, May 30, 2012 05:05 +0000 Shawn Steele wrote: > Well, regardless of the methodology, it sounds like we're in > violent agreement with the result :) At this stage, I think that is what is important. john From alexey.melnikov@isode.com Wed May 30 04:32:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9221F8693 for ; Wed, 30 May 2012 04:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GrIUeOSI3j1 for ; Wed, 30 May 2012 04:32:09 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3908521F8659 for ; Wed, 30 May 2012 04:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338377527; d=isode.com; s=selector; i=@isode.com; bh=W4x5+8tDWrzJjge32+IhYr+a7d9Ee17b0HeKRsCGZNs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=LZ/vVKwwbjgigaDO5Xs9xveJtaAtBPVV1rlu+CCASPyIbac8ge+FTL3Xt5wxh93jdGCLUH AYq8TBWbhu7WuXT0yU1Qpy8hnQhEwn9aXTHIN+VrQUldj9C+qxf6XYS8Opo8nYUObs2fiI cybWxCerXQDwhXyy62HLOedo4RrBh7A=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 May 2012 12:32:07 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FC60538.7020009@isode.com> Date: Wed, 30 May 2012 12:32:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: ima@ietf.org References: <52E1B64D3C9110B9E5B83F15@PST.JCK.COM> <9EF40999902C41B39D1ACAC70F2C4E88@LENOVO47E041CF> <4171F634B4DCCB52A0BE4AC2@PST.JCK.COM> <01OFWDXYHLDQ0006TF@mauve.mrochek.com> <01OFWGWX7FD20006TF@mauve.mrochek.com> <15029D7820EB5D9B06974BB5@PST.JCK.COM> <2328D78E62789C17C2ABB5B8@PST.JCK.COM> <7B867B0CA45CAA1C171B68A0@PST.JCK.COM> <4FC4C831.60400@att.com> In-Reply-To: <4FC4C831.60400@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 11:32:10 -0000 On 29/05/2012 13:59, Tony Hansen wrote: > On 5/26/2012 9:26 AM, John C Klensin wrote: >> Writing as an individual participant only... >> >> Mixing the principle of making minimal changes at this late date >> with Ned's reasoning, I've changed my mind about preferred >> outcome. I propose that we go with 2.1 and that we change the >> second sentence of the Section 2 discussion of LANG in 5721bis >> to read something like: >> >> "The LANG capability and command permit a POP3 client to >> negotiate which language the server uses when sending >> human-readable text in replies and changes the character >> set used in those replies from ASCII to Unicode encoded >> in UTF-8." >> >> That correctly explains what the LANG capability and command >> actually do up front, rather than burying the UTF-8 part in what >> appears to be almost an offhand comment. > > I'm happy with this text. Works for me as well. From klensin@jck.com Wed May 30 04:51:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30A921F86A3 for ; Wed, 30 May 2012 04:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RCww642Kipj for ; Wed, 30 May 2012 04:51:15 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA1621F86A1 for ; Wed, 30 May 2012 04:51:15 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SZhKy-000FqE-6u; Wed, 30 May 2012 07:45:12 -0400 Date: Wed, 30 May 2012 07:51:07 -0400 From: John C Klensin To: Shawn Steele , Ned Freed Message-ID: <6FBAF45C73C3EB5102A16BC5@PST.JCK.COM> In-Reply-To: <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.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: Barry Leiba , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 11:51:16 -0000 Shawn, Two added comments, just because the design philosophy discussion is interesting (at least to me). Again, speaking personally only. --On Wednesday, May 30, 2012 07:52 +0000 Shawn Steele wrote: >... > For example, if we were striving for "greatest possible > utility", I'd suggest that a more flexible approach would have > been to not create "SMTPUTF8", but rather "SMTPCP", with a > mechanism for selecting from an unlimited set of code pages. > We all decided that UTF8 and consistency was more important > for EAI than allowing people to pick their favorite code page. > We sacrificed potential utility for the uniformity we > perceived was more important. While you may see that in terms of importance, I see it as maximizing interoperability by permitting only one form on the wire. One would see greater utility only if either all servers or all clients supported all possible code pages, which is a near-impossibility. If not, an unlimited number of code pages approach would require every client to support both its preferred code page(s) and one or more that it was pretty sure everyone would support so it could convert. (As standards-writers, we could have made that choice easier by making something mandatory to implement; that something would probably be UTF-8). The result would be that a client implementer would need to support its preferred code page(s), UTF-8, and conversion between UTF-8 and one or more of those code pages. That is not either improved functionality nor reduced implementation complexity. It enables a performance optimization for clients that run on operating systems that prefer non-Unicode internally, but, given that these reply strings tend to be very short, that optimization is trivial. Of course, if there is no mandatory to implement code page (other than ASCII) on the server, and both server and client optimize flexibility by supporting only their own code pages, "flexibility" would translate into an interoperability horror. For context, I believe we would not have adopted the multiple code page/encoding "charset" approach with text/plain had it been clear that Unicode and UTF-8 would be available and successful. That was not at all obvious in 1992. Even if it had been, UTF-8 support wasn't even near widely deployed and supported enough to make trying to force its use (even on the wire) plausible. (I note that this wasn't long after the emerging HTML community effectively decided that, if they used 8859-1, they would be finished with i18n problems -- we at least knew that was a non-starter.) > Someone stuck maintaining a > system with some awkward code page may well have preferred if > we'd come to a different conclusion. Maybe. But, if they wanted to interoperate with others, I don't know how strong the preference would have been given that they would have had to support mapping to and from UTF-8 for that code page anyway. > Standards, IMO, are around to create interoperable systems. > Many permitted variations make the systems more complex and > hinder the interoperability. So, IMO, it's completely fair to > require UTF8 for LANG in order to reduce the complexity of the > system. I do not think that allowing additional code pages, > particularly since it would introduce ambiguity or some > complex declaration system, would provide more "utility". In > fact I think it'd be less useful than a LANG that was > unambiguous in its encoding. Exactly. > But I'd like to point out that it shouldn't be "forcing what > the authors think is important down people's throats". It > should be what the WG has decided is realistic and reasonable > for the entire ecosystem and the long term goals of the > standard and related standards. IMO EAI cannot succeed > without widespread UTF8 adoption, so adding things to an EAI > standard that encourage deviating from UTF8 could only delay > EAI adoption, conflicting with the core goal of EAI adoption > that this WG is trying to achieve. Again, no one opposed LANG with arbitrary code pages. My initial readings of the spec was that it didn't say anything at all on the subject, which meant that we either needed to specify that it used UTF-8 coding on replies or to descend into "ambiguity or some complex declaration system". This discussion has been entirely about exactly how the "if you are going to enable LANG, replies MUST be in UTF-8" condition was going to be specified. > Anyway, this is a philosophical discussion is sort of > orthogonal to what we're doing here. I'm fine with what > John's been proposing, though there seems to be some > disagreement since John just said "That is what the current > text says" and Ned said "nobody is proposing anything like > that" :) I actually don't think so. A really careful reading of the text actually turns up the requirement for replies in UTF-8 so my suggested modified text clarifies the situation but doesn't actually change anything. After another look at I-D this morning, I believe that we should also change the abstract and possibly even the title, to clarify that two separate and orthogonal capabilities are being specified. But even if the WG agreed to those changes, they would be clarifications to text to reduce confusion and increase the odds of correct implementations, not alterations to the spec that would affect any correct implementation. john From ned+ima@mrochek.com Wed May 30 07:35:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE51D21F8659 for ; Wed, 30 May 2012 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HifTJnOXE7UN for ; Wed, 30 May 2012 07:35:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D87B721F864E for ; Wed, 30 May 2012 07:35:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG33SQMOCW002SVL@mauve.mrochek.com> for ima@ietf.org; Wed, 30 May 2012 07:35:49 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFYZ0QA6000006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 30 May 2012 07:35:40 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OG33SLM2LW0006TF@mauve.mrochek.com> Date: Wed, 30 May 2012 07:17:03 -0700 (PDT) In-reply-to: "Your message dated Wed, 30 May 2012 07:52:01 +0000" <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> To: Shawn Steele Cc: Barry Leiba , Ned Freed , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 14:35:55 -0000 > > This is about creating standards with the greatest possible utility, not about trying to > > assess importance, or worse, trying to use standards language to force a notion of > > what we happen to think is important down people's throats. > Features is not necessarily == utility. Standards, by necessity, "force what > the authors happen to think is important down people's throats." No matter how > excellent the standard, people can be found that disagree with that standard, > either in large parts or small parts. Of course features are not equivalent to utility. That's exactly the point of this discussion. You're arguing for what amounts to a feature - coupling of LANG to UTF8. I'm arguing that the feature has considerable negative utility, not having it has negligable cost, and therefore it has no business being there. > Standards are limited to what the authors think is important. (If they > didn't think it was important, they wouldn't waste time including it in the > standard). Hopefully there is consensus and a great process driving those > decisions. I think we've done a decent job. I actually disagee, but that's irrelevant at this point. > For example, if we were striving for "greatest possible utility", I'd suggest > that a more flexible approach would have been to not create "SMTPUTF8", but > rather "SMTPCP", with a mechanism for selecting from an unlimited set of code > pages. Sorry, that's just flat out incorrect. There may have been a time when being able to use multiple charsets resulted in an overall increase in utility because of lack of widespread support for UTF-8, but that time is long since past. It's especially true given the total hashup that's been made of various CJK charsets. And there's no way you can demand that servers be able to supply all possible code pages. If you made that a requirement, it would either be ignored or nobody would implement the extension. That's just reality. > We all decided that UTF8 and consistency was more important for EAI than > allowing people to pick their favorite code page. No, we decided that having something that was implementable was more important than having something that was not. > We sacrificed potential utility for the uniformity we perceived was more > important. Someone stuck maintaining a system with some awkward code page may > well have preferred if we'd come to a different conclusion. Nope. You're comparing something that's implementable with something that is not. There is no utility in something that will never see the light of day. > Standards, IMO, are around to create interoperable systems. Many permitted > variations make the systems more complex and hinder the interoperability. So, > IMO, it's completely fair to require UTF8 for LANG in order to reduce the > complexity of the system. You have not provided the slightest scintilla of evidence that separating the two actually reduces significant added implementation complexity. I, OTOH, have analyzed the situation fairly carefully and shown that the added complexity is somewhere between nonexistent to negligable. > I do not think that allowing additional code pages, particularly since it > would introduce ambiguity or some complex declaration system, would provide > more "utility". And once again you're arguing a strawman. For the last time, nobody is arguing for requiring support of additional code pages. That's not part of any proposal anyone has made. Read the proposed text if you don't believe me. > In fact I think it'd be less useful than a LANG that was unambiguous in its > encoding. Please explain why there's anything ambiguous about requiring the use of UTF-8. > But I'd like to point out that it shouldn't be "forcing what the authors > think is important down people's throats". It should be what the WG has > decided is realistic and reasonable for the entire ecosystem and the long term > goals of the standard and related standards. IMO EAI cannot succeed without > widespread UTF8 adoption, so adding things to an EAI standard that encourage > deviating from UTF8 could only delay EAI adoption, conflicting with the core > goal of EAI adoption that this WG is trying to achieve. You need to stop piling up the strawmen. There is nothing about allowing LANG to be used separately from UTF8 that will discourage use of the UTF8 capability. > Anyway, this is a philosophical discussion is sort of orthogonal to what > we're doing here. I'm fine with what John's been proposing, though there seems > to be some disagreement since John just said "That is what the current text > says" and Ned said "nobody is proposing anything like that" :) John has apparently missed all your claims about how the revised LANG proposal introduces the need to support additional code pages. Ned From Shawn.Steele@microsoft.com Wed May 30 09:54:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3A511E80C9 for ; Wed, 30 May 2012 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asvKtJYoNVkA for ; Wed, 30 May 2012 09:54:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 71CC111E80A1 for ; Wed, 30 May 2012 09:54:01 -0700 (PDT) Received: from mail144-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 16:53:34 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id C19F020328 for ; Wed, 30 May 2012 16:53:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz1418Izz1202hzzz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail144-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1338396811916769_2591; Wed, 30 May 2012 16:53:31 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.239]) by mail144-va3.bigfish.com (Postfix) with ESMTP id DC0492C00F3 for ; Wed, 30 May 2012 16:53:31 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 16:53:30 +0000 Received: from CH1EHSOBE015.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 30 May 2012 16:53:50 +0000 Received: from mail154-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 16:39:44 +0000 Received: from mail154-ch1 (localhost [127.0.0.1]) by mail154-ch1-R.bigfish.com (Postfix) with ESMTP id 773031604AB for ; Wed, 30 May 2012 16:39:44 +0000 (UTC) Received: from mail154-ch1 (localhost.localdomain [127.0.0.1]) by mail154-ch1 (MessageSwitch) id 1338395983243702_5192; Wed, 30 May 2012 16:39:43 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail154-ch1.bigfish.com (Postfix) with ESMTP id 2D55322010D; Wed, 30 May 2012 16:39:43 +0000 (UTC) Received: from BY2PRD0310HT001.namprd03.prod.outlook.com (157.56.236.5) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 16:39:42 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.199]) by BY2PRD0310HT001.namprd03.prod.outlook.com ([10.255.80.36]) with mapi id 14.16.0152.000; Wed, 30 May 2012 16:40:07 +0000 From: Shawn Steele To: Ned Freed Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNPfXIBB4hHTljhkOmJni472vZgZbhcNkpgAAMxKCAAFRo6oAAHlnQgAB24+2AAB8KkA== Date: Wed, 30 May 2012 16:40:06 +0000 Message-ID: <352CBC94712DF44392EE468860B35D30CBFA02@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG33SLM2LW0006TF@mauve.mrochek.com> In-Reply-To: <01OG33SLM2LW0006TF@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Barry Leiba , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 16:54:02 -0000 > Sorry, that's just flat out incorrect. There may have been a time when=20 > being able to use multiple charsets resulted in an overall increase in ut= ility > because of lack of widespread support for UTF-8, but that time is long=20 > since past. It's especially true given the total hashup that's been made = of > various CJK charsets. I was being facetious. John said it wasn't "importance" but "maximizing i= nteroperability" that led to this decision. I think that it is important t= hat interoperability be maximized, so that seems like picking nits to me. And now I'm really confused, if code pages are so evil, why not require LAN= G to respond in UTF8? (Which is what I understand John is trying to agree = on language for.) The WG seems agreed that there's about 1 language that A= SCII is sufficient for, so it seems like having localized responses would i= mmediately require a non-ASCII response. IMO if LANG replies MUST be in UTF-8, then you're a large part of the way t= owards supporting UTF8 already? Like, how can you reply in UTF8 if you hav= en't negotiated a UTF8 connection? If I use LANG w/o using UTF8, then how = does that work? That's where I'm a bit confused. -Shawn From ned+ima@mrochek.com Wed May 30 10:01:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046D321F859B for ; Wed, 30 May 2012 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09+Z0UE21-wD for ; Wed, 30 May 2012 10:01:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEEB21F8569 for ; Wed, 30 May 2012 10:01:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG38VR0Z9C002IJ8@mauve.mrochek.com> for ima@ietf.org; Wed, 30 May 2012 10:01:01 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFYZ0QA6000006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 30 May 2012 10:00:50 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OG38VKA0SU0006TF@mauve.mrochek.com> Date: Wed, 30 May 2012 09:52:40 -0700 (PDT) In-reply-to: "Your message dated Wed, 30 May 2012 16:40:06 +0000" <352CBC94712DF44392EE468860B35D30CBFA02@BY2PRD0310MB388.namprd03.prod.outlook.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG33SLM2LW0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBFA02@BY2PRD0310MB388.namprd03.prod.outlook.com> To: Shawn Steele Cc: Barry Leiba , Ned Freed , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:01:16 -0000 > And now I'm really confused, if code pages are so evil, why not require LANG > to respond in UTF8? I dislike shouting, but it seems to be in order here: THAT'S EXACTLY WHAT IS BEING PROPOSED. ABSOLUTELY NOBODY IS PROPOSING ALLOWING ANYTHING OTHER THAN UTF-8 WHEN LANG IS USED. YOU ARE MAKING UP ISSUES WHERE NONE EXIST. *Please* read the text. I defy you to find even the slightest mention of allowing any other charset, any other code page, any other encoding. LANG does two things: (1) It allows the server to respond in utf-8 instead being restricted to ASCII. (2) It allows the client to request responses in different language, on the condition that the server is prepared to respond in that language. That's it. There is nothing else there. When we talk about the coupling of LANG with UTF8 (note the spelling - that's *not* a charset), we're talking about there being a connection between suporting LANG and supporting the UTF8 capability, which enables client access to EAI messages without downgrading. > (Which is what I understand John is trying to agree on language for.) And your understanding is simply incorrect. > The WG seems agreed that there's about 1 language that ASCII is sufficient > for, so it seems like having localized responses would immediately > require a non-ASCII response. Which is why LANG is useful. > IMO if LANG replies MUST be in UTF-8, then you're a large part of the way > towards supporting UTF8 already? No you are not. If you believe that, you need to look at the various downgrade specifications a *lot* more carefully. > Like, how can you reply in UTF8 if you haven't negotiated a UTF8 connection? > If I use LANG w/o using UTF8, then how does that work? That's where I'm a bit > confused. See above. These are separate things. Ned From klensin@jck.com Wed May 30 11:11:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3367B11E80C1 for ; Wed, 30 May 2012 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZGDYBZL9F4j for ; Wed, 30 May 2012 11:11:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 491AF11E80B3 for ; Wed, 30 May 2012 11:11:19 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SZnGl-000GGr-LO; Wed, 30 May 2012 14:05:15 -0400 Date: Wed, 30 May 2012 14:11:11 -0400 From: John C Klensin To: Shawn Steele , Ned Freed Message-ID: In-Reply-To: <352CBC94712DF44392EE468860B35D30CBFA02@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG33SLM2LW0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBFA02@BY2PRD0310MB388.namprd03.prod.outlook.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: Barry Leiba , ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:11:25 -0000 --On Wednesday, May 30, 2012 16:40 +0000 Shawn Steele wrote: > And now I'm really confused, if code pages are so evil, why > not require LANG to respond in UTF8? (Which is what I > understand John is trying to agree on language for.) The WG > seems agreed that there's about 1 language that ASCII is > sufficient for, so it seems like having localized responses > would immediately require a non-ASCII response. Please read the spec. In particular, the introduction to draft-ietf-eai-rfc5721bis-04 says (second paragraph of Section 1): "a mechanism to support UTF-8 characters in protocol level response strings as well as the ability to negotiate a language for such response strings." and, in the third paragraph of the "Discussion" in Section 2: "This and subsequent protocol-level human-readable text is encoded in the UTF-8 charset." That is really fairly clear and certainly doesn't suggest returning anything but UTF-8 strings. It has, IMO, only one problem, which is that the two pieces of text are a little bit buried and sound narrative rather than normative. My proposed fixes -- the modification to the actual description of LANG and the suggestion that the WG consider changes to the title and/or abstract -- simply clarify and highlight those statements; they do not change the protocol spec in any way. > IMO if LANG replies MUST be in UTF-8, then you're a large part > of the way towards supporting UTF8 already? Like, how can you > reply in UTF8 if you haven't negotiated a UTF8 connection? If > I use LANG w/o using UTF8, then how does that work? That's > where I'm a bit confused. Sending the LANG command and having it accepted constitutes negotiating a a connection over which UTF-8 (the charset, not the other Capability in this spec) will be sent. See above. Given that, I'm not sure what you are talking about, so one of us is probably _very_ confused. I don't think it is me (or Ned or Barry). best, john From Shawn.Steele@microsoft.com Wed May 30 12:01:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3AB11E8128 for ; Wed, 30 May 2012 12:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1j-x9Qc84fv for ; Wed, 30 May 2012 12:01:05 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id EAF5211E811B for ; Wed, 30 May 2012 12:00:47 -0700 (PDT) Received: from mail36-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 19:00:07 +0000 Received: from mail36-va3 (localhost [127.0.0.1]) by mail36-va3-R.bigfish.com (Postfix) with ESMTP id A24561C021E for ; Wed, 30 May 2012 19:00:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail36-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail36-va3 (localhost.localdomain [127.0.0.1]) by mail36-va3 (MessageSwitch) id 1338404405283396_28080; Wed, 30 May 2012 19:00:05 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.245]) by mail36-va3.bigfish.com (Postfix) with ESMTP id 3F6071002D4 for ; Wed, 30 May 2012 19:00:05 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 19:00:01 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 30 May 2012 19:00:20 +0000 Received: from mail212-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 18:59:25 +0000 Received: from mail212-va3 (localhost [127.0.0.1]) by mail212-va3-R.bigfish.com (Postfix) with ESMTP id 1BE988C0281 for ; Wed, 30 May 2012 18:59:25 +0000 (UTC) Received: from mail212-va3 (localhost.localdomain [127.0.0.1]) by mail212-va3 (MessageSwitch) id 1338404363124576_21637; Wed, 30 May 2012 18:59:23 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.246]) by mail212-va3.bigfish.com (Postfix) with ESMTP id 1A38B9E0048; Wed, 30 May 2012 18:59:23 +0000 (UTC) Received: from BY2PRD0310HT001.namprd03.prod.outlook.com (157.56.236.5) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 18:59:21 +0000 Received: from BY2PRD0310MB388.namprd03.prod.outlook.com ([169.254.7.199]) by BY2PRD0310HT001.namprd03.prod.outlook.com ([10.255.80.36]) with mapi id 14.16.0152.000; Wed, 30 May 2012 18:59:46 +0000 From: Shawn Steele To: John C Klensin , Ned Freed Thread-Topic: [EAI] LANG, UTF-8, and POP3 Thread-Index: AQHNPfXIBB4hHTljhkOmJni472vZgZbhcNkpgAAMxKCAAFRo6oAAHlnQgAB24+2AAB8KkIAAHPiAgAANhkA= Date: Wed, 30 May 2012 18:59:45 +0000 Message-ID: <352CBC94712DF44392EE468860B35D30CC0DCB@BY2PRD0310MB388.namprd03.prod.outlook.com> References: <352CBC94712DF44392EE468860B35D30CBB385@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG290D214A0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBBB04@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG2L596P9K0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBD668@BY2PRD0310MB388.namprd03.prod.outlook.com> <01OG33SLM2LW0006TF@mauve.mrochek.com> <352CBC94712DF44392EE468860B35D30CBFA02@BY2PRD0310MB388.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JCK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Barry Leiba , "ima@ietf.org" Subject: Re: [EAI] LANG, UTF-8, and POP3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:01:09 -0000 I'm happy with it, thanks :) -----Original Message----- From: John C Klensin [mailto:klensin@jck.com]=20 Sent: Wednesday, May 30, 2012 11:11 AM To: Shawn Steele; Ned Freed Cc: Barry Leiba; ima@ietf.org Subject: Re: [EAI] LANG, UTF-8, and POP3 --On Wednesday, May 30, 2012 16:40 +0000 Shawn Steele wrote: > And now I'm really confused, if code pages are so evil, why not=20 > require LANG to respond in UTF8? (Which is what I understand John is=20 > trying to agree on language for.) The WG seems agreed that there's=20 > about 1 language that ASCII is sufficient for, so it seems like having=20 > localized responses would immediately require a non-ASCII response. Please read the spec. In particular, the introduction to draft-ietf-eai-rfc5721bis-04 says (second paragraph of Section 1):=20 "a mechanism to support UTF-8 characters in protocol level response strings as well as the ability to negotiate a language for such response strings." and, in the third paragraph of the "Discussion" in Section 2: "This and subsequent protocol-level human-readable text is encoded in the UTF-8 charset." That is really fairly clear and certainly doesn't suggest returning anythin= g but UTF-8 strings. It has, IMO, only one problem, which is that the two = pieces of text are a little bit buried and sound narrative rather than normative. My proposed fixes -- the modification to the actual description of LANG and the suggest= ion that the WG consider changes to the title and/or abstract -- simply cla= rify and highlight those statements; they do not change the protocol spec i= n any way. =20 > IMO if LANG replies MUST be in UTF-8, then you're a large part of the=20 > way towards supporting UTF8 already? Like, how can you reply in UTF8=20 > if you haven't negotiated a UTF8 connection? If I use LANG w/o using=20 > UTF8, then how does that work? That's where I'm a bit confused. Sending the LANG command and having it accepted constitutes negotiating a a= connection over which UTF-8 (the charset, not the other Capability in this= spec) will be sent. See above. Given that, I'm not sure what you are talking about, so one of us is probab= ly _very_ confused. I don't think it is me (or Ned or Barry). best, john From yaojk@cnnic.cn Wed May 30 20:37:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E769E11E80A6 for ; Wed, 30 May 2012 20:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.813 X-Spam-Level: X-Spam-Status: No, score=-98.813 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBWfrXQOW8s6 for ; Wed, 30 May 2012 20:37:36 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 38E2911E8093 for ; Wed, 30 May 2012 20:37:28 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 31 May 2012 11:37:24 +0800 Message-ID: <0688F61625F94D0DBCFC6C32444AF050@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <8435F6589E81EE7ACBAF4CE9@PST.JCK.COM> Date: Thu, 31 May 2012 11:37:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Proposed revised text for IMAP (5738bis) and related documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 03:37:37 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgTWF5 IDE3LCAyMDEyIDc6NTIgQU0NClN1YmplY3Q6IFtFQUldIFByb3Bvc2VkIHJldmlzZWQgdGV4dCBm b3IgSU1BUCAoNTczOGJpcykgYW5kIHJlbGF0ZWQgZG9jdW1lbnRzDQoNCg0KPiBIaS4NCj4gDQo+ IEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMgdG8gdGhlIElNQVANCj4gW2RyYWZ0LWll dGYtZWFpLTU3MzhiaXNdIGFuZCBQT1AgW2RyYWZ0LWlldGYtZWFpLTU3MjFiaXNdIHNwZWNzDQo+ IHRvIHJlZmxlY3QgdGhlIGRpc2N1c3Npb24gb24gTW9uZGF5J3MgSmFiYmVyLWNoYXQvIHZpcnR1 YWwNCj4gbWVldGluZy4gIFRoZXNlIGFyZSBzdWJqZWN0IHRvIGVkaXRvcmlhbCBkaXNjcmV0aW9u IGJ5IHRoZQ0KPiBhdXRob3JzIG9mIHRoYXQgZG9jdW1lbnQsIGkuZS4sIEknbSB0cnlpbmcgdG8g Z2V0IHRoZSBpZGVhcw0KPiBvdXRsaW5lZCBpbiBteSBNb25kYXkgbm90ZSBkb3duIGJ1dCBhbSBu b3QgcGFydGljdWxhcmx5DQo+IGF0dGFjaGVkIHRvIHRoZSBzdWdnZXN0ZWQgdGV4dC4gIEluIHBh cnRpY3VsYXIsIEkndmUgdHJpZWQgdG8NCj4gcmVmbGVjdCBib3RoIG15IE1vbmRheSBub3RlLCB0 aGUgSmFiYmVyIGNvbnZlcnNhdGlvbiwgYW5kIGEgZmV3DQo+IG90aGVyIG5vdGVzIHRvIHRoZSBs aXN0IHdpdGhpbiB0aGUgbGFzdCB3ZWVrLiAgVGhhdCBoYXMNCj4gcmVzdWx0ZWQgaW4gc29tZXdo YXQgbW9yZSB3b3JkcyB0aGFuIGV2ZW4gSSB3b3VsZCBsaWtlLiBJJ3ZlDQo+IHB1dCB0aGVtIGlu IG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgaXQgaXMgZWFzaWVyIHRvIGN1dCB0aGluZ3MNCj4gdGhh dCBhcmUgdW5uZWNlc3Nhcnkgb3V0IHRoYW4gdG8gYWRkIHRleHQ7IHRoZSBuZXh0IHJvdW5kIG9m DQo+IGRlY2lzaW9ucyBhcmUgdXAgdG8gdGhlIFdHIGFuZCB0aGUgYXV0aG9ycy9lZGl0b3JzLg0K PiANCi4uLg0KPiANCj4gKFBPUC4xKSBNb3N0IG9mIHRoZSBmb3VydGggcGFyYWdyYXBoIG9mIFNl Y3Rpb24gMy4xICgiTWFpbA0KPiBzdG9yZXMgYXJlIGVpdGhlciBBU0NJSSBvciBuYXRpdmUgVVRG LTgsIGFuZCBjbGllbnRzIGVpdGhlcg0KPiBpc3N1ZS4uLiIpIG5lZWRzIHRvIGRpc2FwcGVhci4g ICBDb25zaWRlcmluZyBhIHNlcGFyYXRlIG5vdGUNCj4gdGhhdCBJIGp1c3Qgc2VudCAoU3ViamVj dDogUE9QMyBTcGVjIGFuZCBtYWlsIGRyb3AvIE1haWwgc3RvcmUNCj4gb3JnYW5pemF0aW9uIikg YW5kIHRoZSBpbnN0cnVjdGlvbnMgZnJvbSB0aGUgSmFiYmVyIGNoYXQgdG8gdGhlDQo+IFBPUDMg ZWRpdG9ycyB0byBnZXQgcmlkIG9mIGV4Y2VzcyAiVVRGOCIgcGFyYW1ldGVycywgDQo+DQoNCkRv ZXMgaXQgbWVhbiB0byAgZ2V0IHJpZCBvZiBleGNlc3MgIlVURjgiIHBhcmFtZXRlciAiYXJndW1l bnQiLCBhbmQgcmVtb3ZlIHRoZSAzLjIgc2VjdGlvbg0KIlVTRVIgQXJndW1lbnQgdG8gVVRGOCBD YXBhYmlsaXR5Ii4NCg0KRnJvbSBKb3NlcGgncyBKYWJiZXIgc3VtbWFyeSBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaW1hL2N1cnJlbnQvbXNnMDQ4MDMuaHRtbCwgDQoNCml0 IHNlZW1zIHRoYXQgdGhlcmUgaXMgbm8gc3VtbWFyeSByZWxhdGVkIHRvIFBPUC4NCg0KDQpKaWFu a2FuZyBZYW8NCg0KPg0KPnRoaXMNCj4gc3VnZ2VzdGlvbiBtYXkgbmVlZCBjb25zaWRlcmFibGUg cmV3cml0aW5nLCANCj5idXQsIGZvbGxvd2luZyB0aGUNCj4gdGhlbWUgYWJvdmUsIEkgc3VnZ2Vz dCBzb21ldGhpbmcgbGlrZToNCj4gDQo+IE5vcm1hbCBvcGVyYXRpb24gZm9yIFVURi04IG1haWxk cm9wcyB3aWxsIGJlIGZvciBib3RoDQo+IHNlcnZlcnMgYW5kIGNsaWVudHMgdG8gc3VwcG9ydCB0 aGUgZXh0ZW5zaW9uIGRpc2N1c3NlZCBpbg0KPiB0aGlzIHNwZWNpZmljYXRpb24uICBVcGdyYWRp bmcgb2YgYm90aCBjbGllbnRzIGFuZCBzZXJ2ZXJzDQo+IGlzIHRoZSBvbmx5IGZ1bGx5IHNhdGlz ZmFjdG9yeSB3YXkgdG8gc3VwcG9ydCB0aGUNCj4gY2FwYWJpbGl0aWVzIG9mZmVyZWQgYnkgdGhl ICJVVEY4IiBleHRlbnNpb24gYW5kIFNNVFBVVEY4DQo+IG1haWwgbW9yZSBnZW5lcmFsbHkuICBT ZXJ2ZXJzIG11c3QsIGhvd2V2ZXIsIGFudGljaXBhdGUgdGhlDQo+IHBvc3NpYmlsaXR5IG9mIGEg Y2xpZW50IGF0dGVtcHRpbmcgdG8gYWNjZXNzIGEgbWVzc2FnZSB0aGF0DQo+IHJlcXVpcmVzIHRo aXMgZXh0ZW5zaW9uIHdpdGhvdXQgaGF2aW5nIGlzc3VlZCB0aGUgIlVURjgiDQo+IGNvbW1hbmQu ICBUaGVyZSBhcmUgbm8gY29tcGxldGVseSBzYXRpc2ZhY3RvcnkgcmVzcG9uc2VzDQo+IGZvciB0 aGF0IGNhc2Ugb3RoZXIgdGhhbiB1cGdyYWRpbmcgdGhlIGNsaWVudCB0byBzdXBwb3J0DQo+IHRo aXMgc3BlY2lmaWNhdGlvbi4gIE9uZSBzb2x1dGlvbiwgdW5zYXRpc2ZhY3RvcnkgYmVjYXVzZQ0K PiB0aGUgdXNlciBtYXkgYmUgY29uZnVzZWQgYnkgYmVpbmcgYWJsZSB0byBhY2Nlc3MgdGhlDQo+ IG1lc3NhZ2UgdGhyb3VnaCBzb21lIG1lYW5zIGFuZCBub3Qgb3RoZXJzLCBpcyB0aGF0IGEgc2Vy dmVyDQo+IE1BWSBjaG9vc2UgdG8gcmVqZWN0IHRoZSBjb21tYW5kIHRvIHJldHJpZXZlIHRoZSBt ZXNzYWdlIGFzDQo+IGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUuICBPdGhlciBhbHRlcm5hdGl2ZXMs IGluY2x1ZGluZyB0aGUNCj4gcG9zc2liaWxpdHkgb2YgY3JlYXRpbmcgYW5kIGRlbGl2ZXJpbmcg dmFyaWFudCBmb3JtIG9mIHRoZQ0KPiBtZXNzYWdlLCBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24g NyBvZiB0aGUgSU1BUCBVVEYtOA0KPiBzcGVjaWZpY2F0aW9uIFtkcmFmdC1pZXRmLWVhaS01NzM4 YmlzXS4NCj4gDQo= From alexey.melnikov@isode.com Thu May 31 10:45:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85711E80B3 for ; Thu, 31 May 2012 10:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.804 X-Spam-Level: X-Spam-Status: No, score=-102.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pU5fUP7kONf for ; Thu, 31 May 2012 10:45:48 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F11E8096 for ; Thu, 31 May 2012 10:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338486347; d=isode.com; s=selector; i=@isode.com; bh=0gKj0R62D6U+Uvz3Mi/e9AvwLi+zV9BlbDQGHlC49EI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=SioawB5IQZN3B+tKS4DQXKFgr16ArImqu0qnmZP0orUEqpFyYPCO3dwj/zQxKTUfcX0ZUC qFtuL/CmvuZ6OFbZV65LmL/+O9UUyoDiVCtM1IRaE+HZvVy6zpYBfxvpTJTzuHsPbT2HA4 ZAbIrrTAyWeIKQMmd+BoJt4TRIlDUxY=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 31 May 2012 18:45:47 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FC7AE4E.6090906@isode.com> Date: Thu, 31 May 2012 18:45:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Arnt Gulbrandsen References: <4FBB9DAE.8060003@gulbrandsen.priv.no> In-Reply-To: <4FBB9DAE.8060003@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IMA Discussion Subject: Re: [EAI] imap utf8 string decision X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:45:49 -0000 On 22/05/2012 15:07, Arnt Gulbrandsen wrote: > Hi, > > did we decide how UTF8 strings ought to be represented? Should I drop my > uquoted code? I think that would be good. I don't know if the WG made the decision though yet (I am behind on reading the mailing list though).