From klensin@jck.com Fri May 7 07:43:14 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E781E3A691E for ; Fri, 7 May 2010 07:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXaQUjZccASQ for ; Fri, 7 May 2010 07:43:13 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8BA343A6B2E for ; Fri, 7 May 2010 07:43:03 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OAOlO-000J8C-4J for ima@ietf.org; Fri, 07 May 2010 10:42:50 -0400 Date: Fri, 07 May 2010 10:42:49 -0400 From: John C Klensin To: EAI WG Message-ID: <185402E448E00071BB4906C5@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========9AE3C17A655DD9963700==========" Subject: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:43:15 -0000 --==========9AE3C17A655DD9963700========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. A draft revised charter is attached. This is likely to go to the IESG really soon, so, if anyone has comments, they should come quickly. A note about the benchmarks: They are quite aggressive and depend on (1) the WG staying focused, rather than reopening old issues or getting sidetracked into non-critical-path issues. If old issues have to be reopened due to new information, we will have to deal with that, but I hope that everyone can refrain from revisiting old issues with old arguments. (2) Document authors/editors staying on top of things. The WG has a fairly poor track record in that area. While Joseph and I will twist arms as needed, I hope that those who are interested and might be able to make some time will volunteer to help with the work, ideally by working out arrangements directly with the authors of the existing documents. regards, john --==========9AE3C17A655DD9963700========== Content-Type: text/plain; charset=us-ascii; name="eai-charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="eai-charter.txt"; size=5477 Description of Working Group: The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization. That approach is based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers. The mail header contexts can include both addresses and wherever existing protocols (e.g., RFC 2231) permit the use of encoded-words. All WG deliverables specified under the original charter, particularly the experimental protocol specifications, have been completed. The core specifications have been implemented and interoperability tests performed. The WG is now being rechartered to permit advancing revised versions of those specifications and supporting documents into the standards track. As a result of implementation and testing experience, the WG has concluded that ongoing work drop the model of in-transit downgrading that was a key part of the original effort. In-transit downgrading approaches simply do not work well enough and predictably enough to be worth the considerable additional complexity that accompanies them. In particular, dropping in-transit downgrading eliminates the need for the first significant change to the syntax of an email address since RFC 821 and 822 were published in 1982. Work will therefore reflect a "no fallback" approach. That approach provides a very minimal transition mechanism, but is consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers. Discoverable fallback addresses that could be applied before or during message submission or after SMTP "final delivery" may be investigated. The WG may also develop other materials to give advice to implementers or operators. Those efforts may lead to informational documents or best practices recommendations, but are considered independent of the core documents. Work on them will progress only under the condition that it not delay the primary standards track specifications. The WG believes that the lessons learned from implementation and testing and removal of in-transit downgrading as a goal eliminates all major areas of controversy about the core specifications and should permit very rapid progress. Such rapid progress is an explicit goal for the WG; issues resolved in the past will not be revisited unless those who wish to do so can demonstrate data, reasoning, or consequences that were not considered earlier. At the same time, any attempt to significantly extend an established and widely deployed set of protocols may uncover new consequences or side effects that need consideration and evaluation. If faced with a choice between spending time on such new considerations, the WG will favor getting things right over accelerating the schedule. Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents other than those listed below as "Required" or "Additional" will require a charter update. Required Documents (these are the "core specifications" referred to elsewhere) * Overview and Framework for Internationalized Email, replacing RFC 4952 (Informational or Proposed Standard at IESG discretion once complete) * UTF-8 SMTP extension specification, replacing RFC 5336 (Proposed Standard) * Header format specification, replacing RFC 5335 (Proposed Standard) * Internationalized DSN specification, replacing RFC 5337 (Proposed Standard) * UTF-8 POP specification, replacing RFC 5721 (Proposed Standard) * UTF-8 IMAP specification, replacing RFC 5738 (Proposed Standard) Additional possible documents suggested. While milestones are listed for most of these documents, they may be dropped by the WG with the consent of the Responsible AD. * Advice for MUA implementors (Informational or BCP) * Advice for EAI deployment (Informational or BCP) * Advice for non-ASCII and ASCII addresses for the same mailbox (Informational or BCP) * Mailinglist (Informational or Standards Track, replacing draft-eai-mailinglist) * Mailto (Proposed Standard, updating draft-duerst-mailto-bis to reflect internationalized addresses) * Protocol extensions for RFC 4409 Submission Servers or configuration advice for the MUA->Submission server interface. Goals and Milestones: Mar 2010 Discussion of Recharter for standards track at IETF 77 (completed) May 2010 New charter approval from IESG Jul 2010 EAI Framework to IESG Sep 2010 Headers to IESG Sep 2010 SMTP to IESG Sep 2010 DSN to IESG Nov 2010 IMAP & POP3 to IESG Dec 2010 Decision about possible changes or comments about Submission Servers. If the decision is to generate a document, the decision will include a schedule. Jan 2011 Advice for non-ASCII & ASCII addresses to IESG Jan 2011 Advice for MUA implementors to IESG Jan 2011 Advice for EAI deployment to IESG Apr 2011 Mailinglist to IESG Apr 2011 Mailto(Proposed Standard) to IESG --==========9AE3C17A655DD9963700==========-- From chl@clerew.man.ac.uk Tue May 11 02:27:37 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 371A828C159 for ; Tue, 11 May 2010 02:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pQJ5qrr9qpQ for ; Tue, 11 May 2010 02:27:36 -0700 (PDT) Received: from v-smtp-auth-relay-5.gradwell.net (v-smtp-auth-relay-5.gradwell.net [79.135.125.99]) by core3.amsl.com (Postfix) with ESMTP id AB42028C234 for ; Tue, 11 May 2010 02:24:13 -0700 (PDT) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew&man&ac#uk) by v-smtp-auth-relay-5.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4be92227.3374.3 for ima@ietf.org; Tue, 11 May 2010 10:23:51 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o4B9NmWS019401 for ; Tue, 11 May 2010 10:23:49 +0100 (BST) To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <185402E448E00071BB4906C5@PST.JCK.COM> Content-Transfer-Encoding: 8bit Date: Tue, 11 May 2010 10:23:48 +0100 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 09:27:37 -0000 On Fri, 07 May 2010 15:42:49 +0100, John C Klensin wrote: > Hi. > > A draft revised charter is attached. This is likely to go to > the IESG really soon, so, if anyone has comments, they should > come quickly. Whilst we are agreed that the alt-address mechanisms must go, that is not to say the whole of the downgrade mechanisms should go wth them. Although the emphasis on it may well be reduced, it should still remain as an option for sites that wished to use it and be described in an RFC. There is much more to downgrading than fixing up non-deliverable addresses, and even for that recent discussions in this WG indicated that a punycode-based solution could be devised without too much difficulty. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From yaojk@cnnic.cn Tue May 11 02:41:23 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CB328C159 for ; Tue, 11 May 2010 02:41:23 -0700 (PDT) X-Quarantine-ID: <1JOl8yEPlhZz> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.806 X-Spam-Level: ** X-Spam-Status: No, score=2.806 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JOl8yEPlhZz for ; Tue, 11 May 2010 02:41:23 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 3EC043A6D17 for ; Tue, 11 May 2010 02:36:43 -0700 (PDT) Received: (eyou send program); Tue, 11 May 2010 17:36:33 +0800 Message-ID: <473570593.22648@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 11 May 2010 17:36:33 +0800 Message-ID: <32C3F7EDC79B4230A83C90AA1AF578BF@LENOVO47E041CF> From: "Jiankang YAO" To: "IMA" , "Charles Lindsey" References: <185402E448E00071BB4906C5@PST.JCK.COM> <473570052.12491@cnnic.cn> Date: Tue, 11 May 2010 17:36:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 09:41:24 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86ICJJTUEiIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBU dWVzZGF5LCBNYXkgMTEsIDIwMTAgNToyMyBQTQ0KU3ViamVjdDogUmU6IFtFQUldIERyYWZ0IHJl dmlzZWQgY2hhcnRlcg0KDQoNCg0KDQo+V2hpbHN0IHdlIGFyZSBhZ3JlZWQgdGhhdCB0aGUgYWx0 LWFkZHJlc3MgbWVjaGFuaXNtcyBtdXN0IGdvLA0KDQorMQ0KDQo+IHRoYXQgaXMgbm90DQo+dG8g c2F5IHRoZSB3aG9sZSBvZiB0aGUgZG93bmdyYWRlIG1lY2hhbmlzbXMgc2hvdWxkIGdvIHd0aCB0 aGVtLiBBbHRob3VnaA0KPnRoZSBlbXBoYXNpcyBvbiBpdCBtYXkgd2VsbCBiZSByZWR1Y2VkLCBp dCBzaG91bGQgc3RpbGwgcmVtYWluIGFzIGFuDQo+b3B0aW9uIGZvciBzaXRlcyB0aGF0IHdpc2hl ZCB0byB1c2UgaXQgYW5kIGJlIGRlc2NyaWJlZCBpbiBhbiBSRkMuDQoNCnRoZSBjaGFydGVyIHNh aWQ6Ig0KRGlzY292ZXJhYmxlIGZhbGxiYWNrIGFkZHJlc3NlcyB0aGF0IGNvdWxkIGJlIGFwcGxp ZWQgYmVmb3JlIG9yDQpkdXJpbmcgbWVzc2FnZSBzdWJtaXNzaW9uIG9yIGFmdGVyIFNNVFAgImZp bmFsIGRlbGl2ZXJ5IiBtYXkgYmUNCmludmVzdGlnYXRlZC4gIFRoZSBXRyBtYXkgYWxzbyBkZXZl bG9wIG90aGVyIG1hdGVyaWFscyB0byBnaXZlDQphZHZpY2UgdG8gaW1wbGVtZW50ZXJzIG9yIG9w ZXJhdG9ycy4iDQoNCnNvIHdlIG1heSBzdGlsbCBkbyBzb21ldGhpbmcgZm9yIGhlbHBpbmcgdGhl IHRyYW5zaXRpb24uDQoNCg0KSmlhbmthbmcgWWFv From klensin@jck.com Tue May 11 09:04:01 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC993A6A26 for ; Tue, 11 May 2010 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xCfr2GrcYU1 for ; Tue, 11 May 2010 09:04:00 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id C23113A67A2 for ; Tue, 11 May 2010 09:03:58 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OBrvt-0000Kx-NA for ima@ietf.org; Tue, 11 May 2010 12:03:46 -0400 Date: Tue, 11 May 2010 12:03:44 -0400 From: John C Klensin To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] FWD: Re: Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 16:04:01 -0000 Charles initially and accidentally sent his note to my rather than posting it to the list. What follows is a somewhat edited version of my reply to him (some prior material has been removed, some new material inserted). --On Monday, 10 May, 2010 10:00 +0100 Charles Lindsey wrote: > Whilst we are agreed that the alt-address mechanisms must go, > that is not to say the whole of the downgrade mechanisms > should go wth them. Although the emphasis on it may well be > reduced, it should still remain as an option for sites that > wished to use it and be described in an RFC. There is much > more to downgrading than fixing up non-deliverable addresses, > and even for that recent discussions in this WG indicated that > a punycode-based solution could be devised without too much > difficulty. Charles, let me summarize where I think we are: First, it is useful to distinguish between downgrading in transit (specifically between when the message leaves the Submission environment and when SMTP "final delivery" (as described in RFC 5321) is made and downgrading either before or after that range. For those intermediate hosts to start making local decisions about how to alter messages in transit violates the "don't mess with messages in transit" principle that we've established for email after great pain caused by the alternatives and invites massive unpredictability and interoperability problems. Second, there is a strong sense within the WG that getting the core documents -- header extensions, SMTP extensions, and general mechanisms for use of non-ASCII fields among conforming systems -- is critical. Based on what happens each time the "downgrade" issues are opened and examined against deployment and interoperability risks, it is clear that reaching consensus on any specific downgrading model, even one that does not involve in-transit changes, will be a long, slow, and painful process if, indeed, it is possible. There is also the matter that the IETF has been extremely reluctant to try to specify interface protocols between the submission MUA and Submission server and between the delivery MTA and mail stores, etc. At most, we provide alternatives and guidance, not single standardized answers. So the charter is designed to do just that: eliminate in-transit downgrading from the agenda, move forward very quickly on the core documents, and then go back and deal, as necessary, with the front-end and back end functions. It actually anticipates that some downgrading will occur on the submission side and that receiving back-end protocols like POP and IMAP will need feature to deal with transitional situations. But, because we don't even have agreement now about what to do, much less how to do it, discussion of those options should properly be deferred until the core documents are done and constrained by not requiring in-transit modifications or imposing requirements on those core documents. Note that in-transit is in-transit: if one is going to downgrade in the Submission server, then there is no in-transit issue. If one is going to downgrade in the first hop past the Submission server (the MTA to which the Submission server sends the message), then all of the downgrade problems appear, including the need to either carry alternate address information or to "automatically encode" and discover whether that is safe. Incidentally, I believe that your inference about emerging consensus that a punycode-based solution was not far away is incorrect. At least some of us who think we understand why such solutions are impossible without risking disruptions to the installed base (due to fundamental differences between email and DNS, among other things) simply sat that discussion out because we had been through all of the arguments before, nothing new was being said, and participating in going through them again would be just a waste of time. If you still disagree, a very specific proposal about how to proceed would be appropriate. Handwaving about what some systems might want to do is not, IMO, helpful. regards, john ---------- End Forwarded Message ---------- From Shawn.Steele@microsoft.com Tue May 11 12:24:08 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D8728C283 for ; Tue, 11 May 2010 12:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oo84cGJ86n7 for ; Tue, 11 May 2010 12:24:07 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C428F28C252 for ; Tue, 11 May 2010 12:20:32 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 11 May 2010 12:20:22 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.48]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 11 May 2010 12:20:07 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Draft revised charter Thread-Index: AcrxPu/aLaJpibA3RTW968lfdiYfXg== Date: Tue, 11 May 2010 19:20:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:24:09 -0000 RldJVzogSSdtIGhhcHB5IHdpdGggdGhlIHJldmlzZWQgY2hhcnRlci4NCg0KLVNoYXduDQoNCg== From chl@clerew.man.ac.uk Wed May 12 02:29:05 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776063A6B06 for ; Wed, 12 May 2010 02:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k12OAwWE01KN for ; Wed, 12 May 2010 02:29:04 -0700 (PDT) Received: from v-smtp-auth-relay-5.gradwell.net (v-smtp-auth-relay-5.gradwell.net [79.135.125.99]) by core3.amsl.com (Postfix) with ESMTP id 9F19D3A681B for ; Wed, 12 May 2010 02:29:02 -0700 (PDT) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew&man&ac&uk) by v-smtp-auth-relay-5.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4bea74d3.5047.6 for ima@ietf.org; Wed, 12 May 2010 10:28:51 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o4C9SofL023494 for ; Wed, 12 May 2010 10:28:51 +0100 (BST) Date: Wed, 12 May 2010 10:28:50 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <185402E448E00071BB4906C5@PST.JCK.COM> <473570052.12491@cnnic.cn> <473570593.22648@cnnic.cn> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <473570593.22648@cnnic.cn> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 09:29:05 -0000 On Tue, 11 May 2010 10:36:45 +0100, Jiankang YAO wrote: > ----- Original Message ----- > From: "Charles Lindsey" > To: "IMA" > Sent: Tuesday, May 11, 2010 5:23 PM > Subject: Re: [EAI] Draft revised charter > > > > >> Whilst we are agreed that the alt-address mechanisms must go, > > +1 > >> that is not >> to say the whole of the downgrade mechanisms should go wth them. >> Although >> the emphasis on it may well be reduced, it should still remain as an >> option for sites that wished to use it and be described in an RFC. > > the charter said:" > Discoverable fallback addresses that could be applied before or > during message submission or after SMTP "final delivery" may be > investigated. The WG may also develop other materials to give > advice to implementers or operators." To my way of thinking, the submission agent is the first stage of transit (i.e. it enquires whether the next (often final) server supports UTF8SMTP before deciding how to proceed). I e that John does not interpret it that way, so maybe I misunderstood. Anyway, that is the point at which downgrading, if it happens at all, could and should happen. OTOH, I don't really see why later servers (if for some reason there is more than one hop) shouldn't be allowed to do the same thing. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From klensin@jck.com Thu May 13 19:27:10 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD833A69F2 for ; Thu, 13 May 2010 19:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2qlX4ikYSYr for ; Thu, 13 May 2010 19:27:09 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 658B83A6995 for ; Thu, 13 May 2010 19:27:09 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OCkc5-000BYK-Po; Thu, 13 May 2010 22:26:58 -0400 Date: Thu, 13 May 2010 22:26:56 -0400 From: John C Klensin To: Charles Lindsey , IMA Message-ID: In-Reply-To: References: <185402E448E00071BB4906C5@PST.JCK.COM> <473570052.12491@cnnic.cn> <473570593.22648@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 02:27:10 -0000 --On Wednesday, 12 May, 2010 10:28 +0100 Charles Lindsey wrote: >... > OTOH, I don't really see why later servers (if for some reason > there is more than one hop) shouldn't be allowed to do the > same thing. Because they don't have sufficient information to do it reliably, predictably, and consistently (across all such servers). john From chl@clerew.man.ac.uk Fri May 14 01:25:16 2010 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42D23A6A79 for ; Fri, 14 May 2010 01:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.083 X-Spam-Level: X-Spam-Status: No, score=-4.083 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBK1nS-DQgX5 for ; Fri, 14 May 2010 01:25:15 -0700 (PDT) Received: from v-smtp-auth-relay-6.gradwell.net (v-smtp-auth-relay-6.gradwell.net [79.135.125.112]) by core3.amsl.com (Postfix) with ESMTP id 2341C28C133 for ; Fri, 14 May 2010 01:22:28 -0700 (PDT) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew#man&ac&uk) by v-smtp-auth-relay-6.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4bed0835.52bb.9 for ima@ietf.org; Fri, 14 May 2010 09:22:13 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o4E8MBCN009142 for ; Fri, 14 May 2010 09:22:12 +0100 (BST) Date: Fri, 14 May 2010 09:22:11 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <185402E448E00071BB4906C5@PST.JCK.COM> <473570052.12491@cnnic.cn> <473570593.22648@cnnic.cn> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] Draft revised charter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 08:25:16 -0000 On Fri, 14 May 2010 03:26:56 +0100, John C Klensin wrote: > --On Wednesday, 12 May, 2010 10:28 +0100 Charles Lindsey > wrote: > >> ... >> OTOH, I don't really see why later servers (if for some reason >> there is more than one hop) shouldn't be allowed to do the >> same thing. > > Because they don't have sufficient information to do it > reliably, predictably, and consistently (across all such > servers). I disagree. We defined a suitable downgrade system before which could be mechanically applied to any AUT8 message. If we can devise a suitable punycode-based transfmormation of UTF-8 addresses, then the same woild still be true. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From root@core3.amsl.com Tue May 25 10:00:01 2010 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D01C43A6C43; Tue, 25 May 2010 10:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100525170001.D01C43A6C43@core3.amsl.com> Date: Tue, 25 May 2010 10:00:01 -0700 (PDT) Cc: john-ietf@jck.com, ima@ietf.org Subject: [EAI] WG Review: Recharter of Email Address Internationalization (eai) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 17:00:02 -0000 A modified charter has been submitted for the Email Address Internationalization (eai) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 1, 2010. Email Address Internationalization (eai) ------------------------------------- Last updated: 2010-05-21 Current Status: Active Chairs: John Klensin Joseph Yee Secretary: Jiankang Yao Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization. That approach is based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers. The mail header contexts can include both addresses and wherever existing protocols (e.g., RFC 2231) permit the use of encoded-words. All WG deliverables specified under the original charter, particularly the experimental protocol specifications, have been completed. The core specifications have been implemented and interoperability tests performed. The WG is now being rechartered to permit advancing revised versions of those specifications and supporting documents into the standards track. As a result of implementation and testing experience, the WG has concluded to drop the model of in-transit downgrading that was a key part of the original effort. In-transit downgrading approaches simply do not work well enough and predictably enough to be worth the considerable additional complexity that accompanies them. In particular, dropping in-transit downgrading eliminates the need for the first significant change to the syntax of an email address since RFC 821 and 822 were published in 1982. Work will therefore reflect a "no fallback" approach. That approach provides a very minimal transition mechanism, but is consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers. Discoverable fallback addresses that could be applied before or during message submission or after SMTP "final delivery" may be investigated. The WG may also develop other materials to give advice to implementers or operators. Those efforts may lead to informational documents or best practices recommendations, but are considered independent of the core documents. Work on them will progress only under the condition that it not delay the primary standards track specifications. The WG believes that the lessons learned from implementation and testing and removal of in-transit downgrading as a goal eliminates all major areas of controversy about the core specifications and should permit very rapid progress. Such rapid progress is an explicit goal for the WG; issues resolved in the past will not be revisited unless those who wish to do so can demonstrate data, reasoning, or consequences that were not considered earlier. At the same time, any attempt to significantly extend an established and widely deployed set of protocols may uncover new consequences or side effects that need consideration and evaluation. If faced with a choice between spending time on such new considerations, the WG will favor getting things right over accelerating the schedule. Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents other than those listed below as "Required" or "Additional" will require a charter update. Required Documents (these are the "core specifications" referred to elsewhere) * Overview and Framework for Internationalized Email, replacing RFC 4952 (Informational or Proposed Standard at IESG discretion once complete) * UTF-8 SMTP extension specification, replacing RFC 5336 (Proposed Standard) * Header format specification, replacing RFC 5335 (Proposed Standard) * Internationalized DSN specification, replacing RFC 5337 (Proposed Standard) * UTF-8 POP specification, replacing RFC 5721 (Proposed Standard) * UTF-8 IMAP specification, replacing RFC 5738 (Proposed Standard) Additional possible documents suggested. While milestones are listed for most of these documents, they may be dropped by the WG with the consent of the Responsible AD. * Advice for MUA implementors (Informational or BCP) * Advice for EAI deployment (Informational or BCP) * Advice for non-ASCII and ASCII addresses for the same mailbox (Informational or BCP) * Mailinglist (Informational or Standards Track, replacing draft-eai-mailinglist) * Mailto (Proposed Standard, updating draft-duerst-mailto-bis to reflect internationalized addresses) * Protocol extensions for RFC 4409 Submission Servers or configuration advice for the MUA->Submission server interface. Goals and Milestones: Mar 2010 Discussion of Recharter for standards track at IETF 77 (completed) May 2010 New charter approval from IESG Jul 2010 EAI Framework to IESG Sep 2010 Headers to IESG Sep 2010 SMTP to IESG Sep 2010 DSN to IESG Nov 2010 IMAP & POP3 to IESG Dec 2010 Decision about possible changes or comments about Submission Servers. If the decision is to generate a document, the decision will include a schedule. Jan 2011 Advice for non-ASCII & ASCII addresses to IESG Jan 2011 Advice for MUA implementors to IESG Jan 2011 Advice for EAI deployment to IESG Apr 2011 Mailinglist to IESG Apr 2011 Mailto (Proposed Standard) to IESG