From julien@trigofacile.com Mon Oct 3 14:48:31 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B485721F8F15 for ; Mon, 3 Oct 2011 14:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.453 X-Spam-Level: X-Spam-Status: No, score=0.453 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 L6am4-dx6bw9 for ; Mon, 3 Oct 2011 14:48:31 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id 2858121F8ED9 for ; Mon, 3 Oct 2011 14:48:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id A02628168; Mon, 3 Oct 2011 23:51:29 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAfBPdZhjJPn; Mon, 3 Oct 2011 23:51:29 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id 647F98166; Mon, 3 Oct 2011 23:51:29 +0200 (CEST) Message-ID: <4E8A2E61.5060308@trigofacile.com> Date: Mon, 03 Oct 2011 23:51:29 +0200 From: =?ISO-8859-1?Q?Julien_=C9LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ima@ietf.org References: <01O4T11O8X4M00VHKR@mauve.mrochek.com> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Charles Lindsey Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 03 Oct 2011 21:48:31 -0000 Hi Charles, > The Message-ID is crucial to the correct operation of the > Netnews transport, and the effect of using utf-8 in it has not been > investigated (but should be). It is expected that some ancient transport > agents might not like it but even that might not be a show stopper, > since Netnews is very good at navigating around such obstacles. For what is worth, I do not think there would be any major issue with INN (a news server) because message-IDs are internally "hashed" after having parsed them. They can be retrievable. The problem is the transition period. INN currently rejects any message whose Message-ID: header field does not comply with RFC 5536. It also does not want to search for such message-IDs. 200 news.trigofacile.com InterNetNews NNRP server INN 2.6.0 (20111003 prerelease) ready (posting ok) ARTICLE <©@test> 501 Syntax error in message-ID QUIT 205 Bye! > If then, as is likely, they start to appear, then we will see how they > cope and decide how best to regulate them in a future standard. Meanwhile, the propagation of such articles will be very bad. -- Julien ÉLIE « Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé. » From johnl@iecc.com Mon Oct 3 18:40:19 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB5B21F8DE7 for ; Mon, 3 Oct 2011 18:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.042 X-Spam-Level: X-Spam-Status: No, score=-111.042 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 XSixXTdUf1gk for ; Mon, 3 Oct 2011 18:40:18 -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 85B9C21F8DAC for ; Mon, 3 Oct 2011 18:40:18 -0700 (PDT) Received: (qmail 96217 invoked from network); 4 Oct 2011 01:43:20 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 4 Oct 2011 01:43:20 -0000 Received: (qmail 38802 invoked from network); 4 Oct 2011 01:43:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Oct 2011 01:43:20 -0000 Date: 4 Oct 2011 01:42:57 -0000 Message-ID: <20111004014257.8027.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4E8A2E61.5060308@trigofacile.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: julien@trigofacile.com Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Oct 2011 01:40:19 -0000 >> If then, as is likely, they start to appear, then we will see how they >> cope and decide how best to regulate them in a future standard. > >Meanwhile, the propagation of such articles will be very bad. News servers aren't going to be thrilled about messages with unencoded UTF-8 in other headers, either. They'll have to upgrade to handle EAI, just like mail servers will. I suppose we might want to invent some new NNTP verb that lets hosts tell each other whether they can accept EAI messages, but this is most definitely not the current EAI group's problem. R's, John From klensin@jck.com Mon Oct 3 19:31:35 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262F321F8E7D for ; Mon, 3 Oct 2011 19:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.253, 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 Hq-7zl-npJzF for ; Mon, 3 Oct 2011 19:31:34 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8F21F8E7C for ; Mon, 3 Oct 2011 19:31:34 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RAuq4-0000XT-IZ; Mon, 03 Oct 2011 22:34:36 -0400 Date: Mon, 03 Oct 2011 22:34:35 -0400 From: John C Klensin To: =?UTF-8?Q?Julien_=C3=89LIE?= , ima@ietf.org Message-ID: <725E50D595CDB0AD7E4687A0@PST.JCK.COM> In-Reply-To: <4E8A2E61.5060308@trigofacile.com> References: <01O4T11O8X4M00VHKR@mauve.mrochek.com> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> <4E8A2E61.5060308@trigofacile.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: Charles Lindsey Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Oct 2011 02:31:35 -0000 --On Monday, October 03, 2011 23:51 +0200 Julien =C3=89LIE wrote: > Hi Charles, >=20 >> The Message-ID is crucial to the correct operation of the=20 >> Netnews transport, and the effect of using utf-8 in it has >> not been investigated (but should be). It is expected that >> some ancient transport agents might not like it but even >> that might not be a show stopper, since Netnews is very good >> at navigating around such obstacles. >=20 > For what is worth, I do not think there would be any major > issue with INN (a news server) because message-IDs are > internally "hashed" after having parsed them. They can be > retrievable. >=20 > The problem is the transition period. INN currently rejects > any message whose Message-ID: header field does not comply > with RFC 5536. It also does not want to search for such > message-IDs. >... =20 Julien, The edge case of a message with a non-ASCII Message-ID but no other non-ASCII header fields aside, how would the news servers you and Charles are familiar with respond to non-ASCII addresses or header fields more generally? Note also that, to some extent, this is not a news reader problem at all but a gateway issue between Internet mail and news. If articles originate in news and move to mail, there is no issue because they will be ASCII. So the question is what the gateways in the "to news" direction do. If they reject messages with non-ASCII headers (Message-IDs or otherwise), the readers won't see such messages... and the problem is really no different from an attempt to send an extended mail message to a server that is not UTF8SMTP-capable. john From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Oct 4 09:39:51 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C921F8B33 for ; Tue, 4 Oct 2011 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MIME_8BIT_HEADER=0.3, 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 5M2YHjzRO8ka for ; Tue, 4 Oct 2011 09:39:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1EF21F8783 for ; Tue, 4 Oct 2011 09:39:50 -0700 (PDT) Received: by wwf22 with SMTP id 22so760910wwf.13 for ; Tue, 04 Oct 2011 09:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Hm1tVLXeOAU1JtStsw1AE8IhIL8y1ZfL3+wxNDhfuYU=; b=bfGasWatu9qo+IT/wDqShbEUm1TaBUiwPXuuF8bITHCBoRWMyHm45enB3igzalacGK Sgs5SOkBJrq4OshWaoppHQBrNgeKWmhlpuWM3BNkK82r3BsFSS60irseq1gKAoXDdAXR 6hXw40Xao8jmTm3+JyTeaeumRaYs4UgMBEmkU= Received: by 10.227.19.141 with SMTP id a13mr1800980wbb.62.1317746576083; Tue, 04 Oct 2011 09:42:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 4 Oct 2011 09:42:16 -0700 (PDT) From: Frank Ellermann Date: Tue, 4 Oct 2011 18:42:16 +0200 Message-ID: To: =?ISO-8859-1?Q?Julien_=C9LIE?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: [EAI] OT: Message-IDs vs. hashes X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Oct 2011 16:39:51 -0000 On 3 October 2011 23:51, Julien =C9LIE wrote: [FWIW] > I do not think there would be any major issue with INN (a news > server) because message-IDs are internally "hashed" after having > parsed them. =A0They can be retrievable. That is an implementation detail. At least in theory Message-IDs are "globally unique forever", and a finite set: The unique part (LHS) and the RHS have known limitations such as LDH labels in the RHS. It is not required to hash the Message-IDs, they can be used "as is" for their purposes. OTOH any hash has collisions, by definition. For various reasons this WG allegedly decided (=3D as noted by the Chairs) to modify the Message-ID syntax. One reason I'm aware of is that "unique part" always happened to have the same syntax as "local part", only the semantics was slightly different. That could create two similar messes: Mailbox names (local parts) with different Unicode "spellings", ditto Message-IDs. The "KISS" solution to avoid this potential mess for Message-IDs was rejected: Folks claimed that nobody would get this right, IOW, it will be a mess anyway, therefore the old "same syntax" approach will be good enough. Normally I'd prefer one big mess (=3D WG proposal) instead of two different smaller messes. But actually I don't think that nobody would get this right (=3D only one smaller mess for the local parts not affecting unique parts). As long as you treat Message-IDs as opaque and don't try to modify any Unicode points the new "EAI-IDs" have the same features as the NetNews message-IDs. Notably they are not supposed to be hashes. -Frank From chl@clerew.man.ac.uk Tue Oct 4 13:38:13 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C2521F8C42 for ; Tue, 4 Oct 2011 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 A2kkFl3YN3tj for ; Tue, 4 Oct 2011 13:38:12 -0700 (PDT) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by ietfa.amsl.com (Postfix) with ESMTP id D396021F8C68 for ; Tue, 4 Oct 2011 13:38:11 -0700 (PDT) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 5FC672203F; Tue, 4 Oct 2011 21:41:15 +0100 (BST) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Tue, 04 Oct 2011 21:41:14 +0100 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 p94KfChG022394; Tue, 4 Oct 2011 21:41:13 +0100 (BST) Date: Tue, 04 Oct 2011 21:41:12 +0100 To: "John C Klensin" , =?iso-8859-1?Q?Julien_=C9LIE?= , ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <01O4T11O8X4M00VHKR@mauve.mrochek.com> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> <4E8A2E61.5060308@trigofacile.com> <725E50D595CDB0AD7E4687A0@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <725E50D595CDB0AD7E4687A0@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4e8b6f6a.121b8-499f-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Oct 2011 20:38:13 -0000 On Tue, 04 Oct 2011 03:34:35 +0100, John C Klensin wrote: > --On Monday, October 03, 2011 23:51 +0200 Julien ÉLIE > wrote: >> For what is worth, I do not think there would be any major >> issue with INN (a news server) because message-IDs are >> internally "hashed" after having parsed them. They can be >> retrievable. >> >> The problem is the transition period. INN currently rejects >> any message whose Message-ID: header field does not comply >> with RFC 5536. It also does not want to search for such >> message-IDs. >> ... > Julien, > > The edge case of a message with a non-ASCII Message-ID but no > other non-ASCII header fields aside, how would the news servers > you and Charles are familiar with respond to non-ASCII addresses > or header fields more generally? They would propagate fine. User agents that could display them would do so. Making EAI an official extension to Netnews would be quite simple - mainly a matter of inventing a Newsgroups: header and doing something about normalization of Message-IDs if there were to contain UTF-8 (which is why I opposed allowing them in EAI without some normalization rules being provided at the same time). > > Note also that, to some extent, this is not a news reader > problem at all but a gateway issue between Internet mail and > news. If articles originate in news and move to mail, there is > no issue because they will be ASCII. So the question is what > the gateways in the "to news" direction do. If they reject > messages with non-ASCII headers (Message-IDs or otherwise), the > readers won't see such messages... and the problem is really no > different from an attempt to send an extended mail message to a > server that is not UTF8SMTP-capable. I suspect that even if EAI does not find its way 'officially' into Netnews, it will still just happen anyway (probably in selected newsgroups where its use will become common). The transport mechanism it already 8-bit clean, so it should "just work". -- 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 julien@trigofacile.com Tue Oct 4 14:18:14 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D8521F8D10 for ; Tue, 4 Oct 2011 14:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zzbaCmbNMlvh for ; Tue, 4 Oct 2011 14:18:14 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43321F8D26 for ; Tue, 4 Oct 2011 14:18:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 826538169 for ; Tue, 4 Oct 2011 23:21:07 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IndTVoEhqEk4 for ; Tue, 4 Oct 2011 23:21:07 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id 16F618168 for ; Tue, 4 Oct 2011 23:21:07 +0200 (CEST) Message-ID: <4E8B78C2.9050304@trigofacile.com> Date: Tue, 04 Oct 2011 23:21:06 +0200 From: =?UTF-8?B?SnVsaWVuIMOJTElF?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ima@ietf.org References: <01O4T11O8X4M00VHKR@mauve.mrochek.com> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> <4E8A2E61.5060308@trigofacile.com> <725E50D595CDB0AD7E4687A0@PST.JCK.COM> In-Reply-To: <725E50D595CDB0AD7E4687A0@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Oct 2011 21:18:14 -0000 Hi John, > The edge case of a message with a non-ASCII Message-ID but no > other non-ASCII header fields aside, how would the news servers > you and Charles are familiar with respond to non-ASCII addresses > or header fields more generally? It depends on the header field. Basically, they should be valid per RFC 5536 when a syntax is specified (for instance, a Date: header field should be parsable, and should not contain non-ASCII chars where they are not expected). Regarding the Newsgroups: header field, it would work, as Charles says. However, I am unsure that a moderated newsgroup with non-ASCII chars works well (that is to say I am unsure the conversion from an internationalized newsgroup name to an internationalized e-mail address works out of the box right now). The Distribution: header field may also be affected by the use of non-ASCII chars. (Besides, MIME is not expected for this header.) No problem with non-ASCII addresses (From:, Sender:, Approved: ... header fields) as long as external programs using them comply with EAI (for instance programs processing NoCeM notices [a kind of cancel articles], control messages to create/remove newsgroups, moderation software, etc.). -- Julien ÉLIE « Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé. » From chl@clerew.man.ac.uk Wed Oct 5 03:08:04 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C921F8B51 for ; Wed, 5 Oct 2011 03:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.129 X-Spam-Level: X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 RjrJe7olFFeR for ; Wed, 5 Oct 2011 03:08:02 -0700 (PDT) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1687921F8B0F for ; Wed, 5 Oct 2011 03:08:01 -0700 (PDT) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 605AE2223F for ; Wed, 5 Oct 2011 11:11:07 +0100 (BST) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Wed, 05 Oct 2011 11:11:06 +0100 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 p95AAXHY000605 for ; Wed, 5 Oct 2011 11:11:06 +0100 (BST) Date: Wed, 05 Oct 2011 11:10:32 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <20111004014257.8027.qmail@joyce.lan> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20111004014257.8027.qmail@joyce.lan> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4e8c2d3a.11cc7-63c0-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 10:08:04 -0000 On Tue, 04 Oct 2011 02:42:57 +0100, John Levine wrote: >>> If then, as is likely, they start to appear, then we will see how they >>> cope and decide how best to regulate them in a future standard. >> >> Meanwhile, the propagation of such articles will be very bad. > > News servers aren't going to be thrilled about messages with > unencoded UTF-8 in other headers, either. > > They'll have to upgrade to handle EAI, just like mail servers will. I > suppose we might want to invent some new NNTP verb that lets hosts > tell each other whether they can accept EAI messages, but this is most > definitely not the current EAI group's problem. No they won't. User agents will have to be upgraded if people want to read the utf-8 stuff, or to reply by mail to articles From: people with utf-8 addresses. But the existing servers will handle all this just fine except insofar as they might be rejecting (unnecessarily) utf-8 in some headers where it did not matter. Servers will expect to be able to compare Message-IDs for equality by a simple octet-by-octet comparison, and they will expect Dates to be comparable (<,=,>), but I don't think EAI has changed that. Even Newsgroup names with utf-8 in them will work, as has alredy been demonstrated on the existing network, (so long as octet-by-octet comparison works, which means some severe normalization). As to whether it is any of this WG's business, it is certainly NOT the business of this WG to put obstacles in the way of other mail-like protocols which might want to follow the EAI path. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From klensin@jck.com Wed Oct 5 05:37:08 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8CC21F8BF0 for ; Wed, 5 Oct 2011 05:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 MSSIK3ifGxEN for ; Wed, 5 Oct 2011 05:37:08 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1106E21F8BE5 for ; Wed, 5 Oct 2011 05:37:08 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RBQld-0004SD-Gi; Wed, 05 Oct 2011 08:40:09 -0400 Date: Wed, 05 Oct 2011 08:40:08 -0400 From: John C Klensin To: Charles Lindsey , IMA Message-ID: <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> In-Reply-To: References: <20111004014257.8027.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] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 12:37:08 -0000 --On Wednesday, October 05, 2011 11:10 +0100 Charles Lindsey wrote: >... > As to whether it is any of this WG's business, it is certainly > NOT the business of this WG to put obstacles in the way of > other mail-like protocols which might want to follow the EAI > path. Charles, The job of this WG is to make a specific set of extensions to allow internationalized addresses, envelopes, and headers work well in Internet mail. That job includes making the extensions as obvious, internally consistent, and deployable as possible for Internet email use on the public Internet. Like any other change, including the original adoption of the SMTP extension model and MIME, almost anything that is done is likely to cause some difficulties for gateways to other mail systems (and mail-like protocols) and/or, depending on how the gateways behave, on user agents in those other systems. Trying to consider the perceived needs of every other mail-like protocol in order to avoid doing something that its implementers might consider an obstruction leads to paralysis and possibly madness. Because there are IETF Standards-Track documents, NNTP gets some extra consideration, but not much -- the job of the WG remains Internet email, not, in your words, "mail-like protocols". Speaking personally, I would be much more sympathetic to the position you are taking had I not seen all sorts of chaos caused over the years by news systems believing that netnews Message-IDs could be compared, uncritically, to Internet email Message-IDs and actions taken on the results. But those disruptions have occurred and presumably continue to occur. People live with them, and I don't see the disruptions this change to Message-IDs are likely to cause being any worse. YMMD. Again speaking personally, I would have preferred a "don't change anything that cannot be proven to be necessary" approach by the WG, even if it resulted in somewhat more complex rules about what header fields could have non-ASCII content and which could not. That opinion was almost certainly influenced by my having spent a lot of my life in the gateway world (although not with NNTP). The WG disagreed, favoring a less complex model in which substantially any header field can contain non-ASCII material, and Joseph has declared consensus. I've accepted that conclusion; unless you have something that is actually new to add to the discussion, I suggest you do too. best, john From julien@trigofacile.com Wed Oct 5 12:42:49 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF7E11E80D9 for ; Wed, 5 Oct 2011 12:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPaNQydH+ABq for ; Wed, 5 Oct 2011 12:42:48 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id 5623411E80C2 for ; Wed, 5 Oct 2011 12:42:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 01B178169 for ; Wed, 5 Oct 2011 21:45:51 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlt-oeo4toAw for ; Wed, 5 Oct 2011 21:45:50 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id C766C8168 for ; Wed, 5 Oct 2011 21:45:50 +0200 (CEST) Message-ID: <4E8CB3EE.10500@trigofacile.com> Date: Wed, 05 Oct 2011 21:45:50 +0200 From: =?windows-1252?Q?Julien_=C9LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [EAI] Question about draft-ietf-eai-rfc5335bis-12.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, 05 Oct 2011 19:42:49 -0000 Hi all, I have a few remarks about draft-ietf-eai-rfc5335bis-12.txt: * Shouldn't a way to distinguish currently suggested UTF-8 from a possible upcoming suggested encoding (UTF-32, UTF-128 or anything that could be standardized in a few years) be provided? Is "message/global" the way to know UTF-8 is expected? Isn't it necessary to mention UTF-8 somewhere (in a "charset" value)? * Can an internationalized message contain a multipart content-type using an UTF-8 "boundary" value? * Can an example of internationalized message be added to the document? > 3.3. Use of 8-bit UTF-8 in Message-Ids > > Implementers of message-id generation algorithms MAY prefer to > restrain their output to ASCII since that has some advantages, such > as when constructing References fields in mailing-list threads where > some senders use EAI and others not. Shouldn't "References: header fields" be written instead of "References fields"? > 3.4. Effects on Line Length Limits > > Section 2.1.1 of [RFC5322] limits lines to 998 characters and > recommends that the lines be restricted to only 78 characters. This > specification changes the former limit to 988 octets. (Note that in > ASCII octets and characters are effectively the same but this is not > true in UTF-8.) The 78 character limit remains defined in terms of > characters, not octets, since it is intended to address display width > issues, not line length issues. I am a bit puzzled. Why does the specification changes the limit to 988 octets? I would have understood if it were 998 octets. > Background: Normally, transfer of message/global will be done in > 8-bit-clean channels, and body parts will have "identity" encodings, > that is, no decoding is necessary. Two spaces after ":", as it is already the case in the rest of the document. > This is expected to be rarely seen in practice, and the potential > complexity of other ways of dealing with the issue are thought to be > larger than the complexity of allowing nested encodings where > necessary. Shouldn't it be in singular form? ("the potential complexity […] is thought"?) [Section 3.7] > Encoding considerations: Any content-transfer-encoding is permitted. > The 8-bit or binary content-transfer-encodings are recommended > where permitted. […] > Restrictions on usage: This is a structured media type that embeds > other MIME media types. The 8-bit or binary content-transfer- > encoding SHOULD be used unless this media type is sent over a > 7-bit-only transport. Shouldn't "content-transfer-encoding" be written similarly? (either in plural form or in singular form) > The normalization process is > described in Section 3.1 is recommended to minimize these issues. The first "is" should be removed. > This media type provides > functionality similar to the message/rfc822 content type for email > messages with international email headers. and: > Email clients that forward messages with international headers as > attachments. "internationalized"? -- Julien ÉLIE « Rien, ce n'est pas rien ! La preuve, c'est que l'on peut le soustraire. Exemple : rien moins rien = moins que rien ! » (Raymond Devos) From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 13:26:19 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F0821F8B8F for ; Wed, 5 Oct 2011 13:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 cdF8mAL5Fnrw for ; Wed, 5 Oct 2011 13:26:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD99521F8B88 for ; Wed, 5 Oct 2011 13:26:18 -0700 (PDT) Received: by wwf22 with SMTP id 22so2209713wwf.13 for ; Wed, 05 Oct 2011 13:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3Q1OBRkYApVqMbvA2UH/4bgNhvZ3dZ+/O1QzDAgfcAk=; b=dBi6wcqxXSAPY6uY3l+9yt7jhtI/TE1skFORz0KXeCfX+q1dHEA2j8Q4gJiEpaWsvK hpT4edYs98Q5/qwEC9MjU9u3wSJ1NebNmC3u/31kSAfmrwc6WP58uCP5KzEjWe+25hj3 QmntfwMKftFt5w9jtI2X/97aCBUIGBuBhgK3w= Received: by 10.227.19.141 with SMTP id a13mr3745805wbb.62.1317846567071; Wed, 05 Oct 2011 13:29:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 13:28:47 -0700 (PDT) In-Reply-To: <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> From: Frank Ellermann Date: Wed, 5 Oct 2011 22:28:47 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IMA Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 20:26:19 -0000 On 5 October 2011 14:40, John C Klensin wrote: > Trying to consider the perceived needs of every other mail-like > protocol in order to avoid doing something that its implementers > might consider an obstruction leads to paralysis and possibly > madness. =A0Because there are IETF Standards-Track documents, NNTP > gets some extra consideration, but not much -- the job of the WG > remains Internet email, not, in your words, "mail-like > protocols". I'm not sure what Charles and you are discussing here. Please correct me if I'm wrong, but the "Internet message format" is not only for e-mail, in essence it is also used by NetNews. And that is already the complete list. Other mail formats are not based on 822+, and other protocols (e.g., XMPP) are not about Internet messages. HTTP From: header fields not withstanding, "they" can adopt EAI when they feel like it. The mailto: URLs are almost ready for EAI, and the news: URLs can be "fixed" by an erratum. What can't be "fixed" might be thousands of NNTP servers, if the operators pick the wrong of three alternatives: (1) Do nothing, (2) upgrade, or (3) uninstall and give up on NetNews. > Speaking personally, I would be much more sympathetic to the > position you are taking had I not seen all sorts of chaos caused > over the years by news systems believing that netnews > Message-IDs could be compared, uncritically, to Internet email > Message-IDs and actions taken on the results. =A0But those > disruptions have occurred and presumably continue to occur. > People live with them, and I don't see the disruptions this > change to Message-IDs are likely to cause being any worse. =A0YMMD. A message-ID is a message-ID: Any chaos you have seen presumably involved naive or broken gateways from NetNews to e-mail, or more obscure sources, e.g., Fido (FTN) echomail. EAI won't make that worse. Sadly SASL killed it, otherwise CRAM-MD5 might be now in theory ready for "EAI-IDs". In practice I'd guess that CRAM-MD5 implementations never bother to check Message-ID syntax details. -Frank From johnl@iecc.com Wed Oct 5 13:42:11 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3711E811C for ; Wed, 5 Oct 2011 13:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.049 X-Spam-Level: X-Spam-Status: No, score=-111.049 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 G-kdUhu1N1Ax for ; Wed, 5 Oct 2011 13:42:10 -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 4EA6C11E8113 for ; Wed, 5 Oct 2011 13:42:08 -0700 (PDT) Received: (qmail 4463 invoked from network); 5 Oct 2011 20:45:15 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 5 Oct 2011 20:45:15 -0000 Received: (qmail 72798 invoked from network); 5 Oct 2011 20:45:15 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Oct 2011 20:45:15 -0000 Date: 5 Oct 2011 20:44:51 -0000 Message-ID: <20111005204451.8151.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 20:42:11 -0000 >I'm not sure what Charles and you are discussing here. Please >correct me if I'm wrong, but the "Internet message format" is not >only for e-mail, in essence it is also used by NetNews. Mail message format is described in RFC 5322, while news article format is described in RFC 5536. They're deliberately fairly similar, but it is just wrong to assert that you can turn one into the other without using a gateway that deals with the differences. I've written such gateways (indeed, I read this list via a gateway that turns it into a local newsgroup) and there's a lot of little nits they have to deal with. R's, John From klensin@jck.com Wed Oct 5 14:10:56 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE08E21F8C44 for ; Wed, 5 Oct 2011 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 9A-fv+U-oZDm for ; Wed, 5 Oct 2011 14:10:56 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id EE10C21F8C36 for ; Wed, 5 Oct 2011 14:10:55 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RBYmt-000EIW-TD; Wed, 05 Oct 2011 17:14:00 -0400 Date: Wed, 05 Oct 2011 17:13:59 -0400 From: John C Klensin To: Frank Ellermann Message-ID: In-Reply-To: References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@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 Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 21:10:56 -0000 --On Wednesday, October 05, 2011 22:28 +0200 Frank Ellermann wrote: First, thanks to John Levine for the response to your first question. I have nothing to add to his response. These are two systems that use very similar formats but that communicate through gateways, not one system. >... >> Speaking personally, I would be much more sympathetic to the >> position you are taking had I not seen all sorts of chaos >> caused over the years by news systems believing that netnews >> Message-IDs could be compared, uncritically, to Internet = email >> Message-IDs and actions taken on the results. =C2=A0But those >> disruptions have occurred and presumably continue to occur. >> People live with them, and I don't see the disruptions this >> change to Message-IDs are likely to cause being any worse. >> =C2=A0YMMD. >=20 > A message-ID is a message-ID: Any chaos you have seen > presumably involved naive or broken gateways from NetNews to > e-mail, or more obscure sources, e.g., Fido (FTN) echomail. A Message-ID is a Message-ID until something (usually a gateway) decides it needs or wants to improve on it. Those decisions can be due to misunderstanding or stupidity, they can be because other things change and the gateway believes that makes a new message, they can be because the gateway wants to be able to guarantee a unique identifier in the other environment. Sometimes changes are made to protect systems further downstream that are believed to be fragile, sometimes the gateways themselves are fragile and change things to recover from breakage. The changes are usually made with the best of intentions; whether they are naive, broken, or really useful and creative is in the minds of the beholders and the purpose to which they are supposed to be put. I would not presume to try to categorize all of the transformations I've seen, but some of them probably don't fall under your description above. This isn't trivial. Remember that simple transcoding of header fields from net-ASCII into, e.g., EBCDIC or what we call ISO-2022-JP means that dumb octet-string comparisons of Message-IDs (and other things) will fail. There is a rather long history of those issues. If someone asked my opinion about whether a gateway should mess with Message-IDs, I'd say "no, unless it is absolutely required by the systems on the other end". But lots of people don't ask and even fewer listen. Neither RFC 5321/5322 nor RFC 5536 offer any reciprocal guarantees. > EAI won't make that worse. If there are fragile systems out there -- and there almost certainly still are-- how can you possibly know that? > Sadly SASL killed it, otherwise > CRAM-MD5 might be now in theory ready for "EAI-IDs". In > practice I'd guess that CRAM-MD5 implementations never bother > to check Message-ID syntax details. In spite of being co-author of CRAM-MD5, I don't understand this comment at all. Certainly the CRAM-MD5 spec, regardless of its other strengths and weaknesses, doesn't even mention Message-IDs (or any other signature over headers or message content for that matter). john >=20 > -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 14:15:10 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09EE1F0C5F for ; Wed, 5 Oct 2011 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MIME_8BIT_HEADER=0.3, 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 MSPruS7lXSD9 for ; Wed, 5 Oct 2011 14:15:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2E1F0C46 for ; Wed, 5 Oct 2011 14:15:09 -0700 (PDT) Received: by wwf22 with SMTP id 22so2253713wwf.13 for ; Wed, 05 Oct 2011 14:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bqywTDNtF/zoT7/EHLCkYw+C/uKwxyXwtWlQwbcQ0fs=; b=Xo/s4pd/mxRu327We9pnZRKTMPEYUtS1CzvuBvNhzRUGoI2h0d2X2dhWxONnNO6xiN E9o25s3YhzARiHdTc6JYV3Z5PEhTQ8FJYZFXcBiNPIcbzi24H3MffI66y1pK5eua+Dw/ 7A9aFscUaRQfE7YmZS9P7SX/FPjKrT9Rb/jto= Received: by 10.227.11.81 with SMTP id s17mr224961wbs.62.1317849498090; Wed, 05 Oct 2011 14:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 14:17:38 -0700 (PDT) In-Reply-To: <4E8CB3EE.10500@trigofacile.com> References: <4E8CB3EE.10500@trigofacile.com> From: Frank Ellermann Date: Wed, 5 Oct 2011 23:17:38 +0200 Message-ID: To: =?ISO-8859-1?Q?Julien_=C9LIE?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] Question about draft-ietf-eai-rfc5335bis-12.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, 05 Oct 2011 21:15:10 -0000 On 5 October 2011 21:45, Julien =C9LIE wrote: Hi, I pick your easiest question: > * Shouldn't a way to distinguish currently suggested UTF-8 from > a possible upcoming suggested encoding (UTF-32, UTF-128 or > anything that could be standardized in a few years) be provided? All UTFs unsuited for MIME including those with NUL-octets like UTF-32 will never be used for Internet messages. All new Internet protocols already MUST support at least UTF-8, that is an IETF policy since 1998 stated in RFC 2277 (=3D BCP 18). In theory UTF-7 and BOCU-1 are suited for MIME, but if you MUST support UTF-8, and the protocols or document formats (=3D here the message header fields) offer no way to negotiate something else, it will be UTF-8. It can be limited to subsets such as NFC; see RFC 5198 for the details affecting all protocols remotely related to Telnet (incl. WHOIS, SMTP, FTP, HTTP, NNTP). Actually HTTP is a special case, HTTP embraced Latin-1 before UTF-8 and RFC 2277 existed: The HTTPbis WG has "fun" with this issue, but they are certainly also trying to adopt UTF-8, not something else. In other words, as far as the Internet is concerned we will get UTF-8 everywhere, anything else would be science fiction. In a bold statement RFC 2277 predicts that this transition will take at least 50 years. > Is "message/global" the way to know UTF-8 is expected? =A0Isn't > it necessary to mention UTF-8 somewhere (in a "charset" value)? The message/global business is about the message header fields; for message/rfc822 it is ASCII. The content (message body) is still default ASCII unless there is a MIME header field saying something else: Something else can be anything (not limited to UTF-8) encoded for 7bit (MIME B or QP) or 8bit (for UTF8SMTP, does not require an encoding for MIME-compatible charsets such as UTF-8, BOCU-1, Windows-1252, etc.) UTF8SMTP does not allow "unencoded binary" or charsets such as UTF-16, UTF-32, or SCSU in the message body. > * Can an internationalized message contain a multipart > content-type using an UTF-8 "boundary" value? Good question, without cheating (=3D looking into the EAI drafts if they cover MIME Content-* header fields somewhere) I don't know the answer. -Frank From julien@trigofacile.com Wed Oct 5 14:33:23 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED1411E80DB for ; Wed, 5 Oct 2011 14:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.408, 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 tk8kyooRiQK7 for ; Wed, 5 Oct 2011 14:33:23 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5911E80C4 for ; Wed, 5 Oct 2011 14:33:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id EA2458169 for ; Wed, 5 Oct 2011 23:36:29 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeuNLEnMh36e for ; Wed, 5 Oct 2011 23:36:29 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id BB9E78168 for ; Wed, 5 Oct 2011 23:36:29 +0200 (CEST) Message-ID: <4E8CCDDC.7010908@trigofacile.com> Date: Wed, 05 Oct 2011 23:36:28 +0200 From: =?UTF-8?B?SnVsaWVuIMOJTElF?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: IMA References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 21:33:23 -0000 Hi John, > If someone asked my opinion about whether a gateway should mess > with Message-IDs, I'd say "no, unless it is absolutely required > by the systems on the other end". But lots of people don't ask > and even fewer listen. Neither RFC 5321/5322 nor RFC 5536 > offer any reciprocal guarantees. RFC 5536 defines a stricter subset than RFC 5322 for Message-IDs; they therefore need being checked. I agree with your saying that they should not be modified if they have a valid syntax for the system on the other end. According to RFC 5537: 3.10.2. Duties of an Incoming Gateway If there is a message identifier that fills a role similar to that of the Message-ID header field in news, it SHOULD be used in the formation of the message identifier of the news article, perhaps with transformations required to meet the uniqueness requirement of Netnews and with the removal of any comments so as to comply with the syntax in Section 3.1.3 of [RFC5536]. Such transformations SHOULD be designed so that two messages with the same identifier generate the same Message-ID header field. NOTE: Message identifiers play a central role in the prevention of duplicates, and their correct use by gateways will do much to prevent loops. Netnews does, however, require that message identifiers be unique, and therefore message identifiers from other media may not be suitable for use without modification. A balance must be struck by the gateway between preserving information used to prevent loops and generating unique message identifiers. -- Julien ÉLIE « Rien, ce n'est pas rien ! La preuve, c'est que l'on peut le soustraire. Exemple : rien moins rien = moins que rien ! » (Raymond Devos) From ned+ima@mrochek.com Wed Oct 5 15:04:20 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CFE11E8082 for ; Wed, 5 Oct 2011 15:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhvQJhoweKxZ for ; Wed, 5 Oct 2011 15:04:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EBFC411E80A1 for ; Wed, 5 Oct 2011 15:04:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O6V25ZMDRK00WG7X@mauve.mrochek.com> for ima@ietf.org; Wed, 5 Oct 2011 15:05:26 -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 <01O6N7EP1TCG014O5Z@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 5 Oct 2011 15:05:23 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01O6V25Y505G014O5Z@mauve.mrochek.com> Date: Wed, 05 Oct 2011 14:45:00 -0700 (PDT) In-reply-to: "Your message dated Wed, 05 Oct 2011 21:45:50 +0200" <4E8CB3EE.10500@trigofacile.com> References: <4E8CB3EE.10500@trigofacile.com> To: =?windows-1252?Q?Julien_=C9LIE?= Cc: ima@ietf.org Subject: Re: [EAI] Question about draft-ietf-eai-rfc5335bis-12.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, 05 Oct 2011 22:04:20 -0000 > Hi all, > I have a few remarks about draft-ietf-eai-rfc5335bis-12.txt: > * Shouldn't a way to distinguish currently suggested UTF-8 from > a possible upcoming suggested encoding (UTF-32, UTF-128 or anything > that could be standardized in a few years) be provided? > Is "message/global" the way to know UTF-8 is expected? Isn't it > necessary to mention UTF-8 somewhere (in a "charset" value)? Short answer: No, no, and no. Longer answer: There is no expectation that the current use of utf-8 will ever be "upgraded" to utf-16, utf-32, or anything else. Utf-8 is where we're headed. See RFC 2277. > * Can an internationalized message contain a multipart content-type > using an UTF-8 "boundary" value? No. Nothing in this specification updates MIME's ABNF for boundaries, which clearly restricts them to a subset of printable ASCII. (I note that utf-8 and even binary MIME parameter values have been allowed for many years - see RFC 2231, so that hasn't been a limiting factor on boundaries in a long time.) > * Can an example of internationalized message be added > to the document? The closest we could get is a message/global encoding of a message containing UTF-8, which IMO would be much more confusing than helpful. > > 3.3. Use of 8-bit UTF-8 in Message-Ids > > > > Implementers of message-id generation algorithms MAY prefer to > > restrain their output to ASCII since that has some advantages, such > > as when constructing References fields in mailing-list threads where > > some senders use EAI and others not. > Shouldn't "References: header fields" be written instead of > "References fields"? Seems reasonable. > > 3.4. Effects on Line Length Limits > > > > Section 2.1.1 of [RFC5322] limits lines to 998 characters and > > recommends that the lines be restricted to only 78 characters. This > > specification changes the former limit to 988 octets. (Note that in > > ASCII octets and characters are effectively the same but this is not > > true in UTF-8.) The 78 character limit remains defined in terms of > > characters, not octets, since it is intended to address display width > > issues, not line length issues. > I am a bit puzzled. Why does the specification changes the limit > to 988 octets? I would have understood if it were 998 octets. That's just a typo. > > Background: Normally, transfer of message/global will be done in > > 8-bit-clean channels, and body parts will have "identity" encodings, > > that is, no decoding is necessary. > Two spaces after ":", as it is already the case in the rest of the document. I just checked; there is no other place where two spaces are used. I dislike this sort of double spacing and so don't use it. (If the RFC Editor disagrees that's fine too.) > > This is expected to be rarely seen in practice, and the potential > > complexity of other ways of dealing with the issue are thought to be > > larger than the complexity of allowing nested encodings where > > necessary. > Shouldn't it be in singular form? > ("the potential complexity […] is thought"?) Yes, I'll fix that. > [Section 3.7] > > Encoding considerations: Any content-transfer-encoding is permitted. > > The 8-bit or binary content-transfer-encodings are recommended > > where permitted. > […] > > Restrictions on usage: This is a structured media type that embeds > > other MIME media types. The 8-bit or binary content-transfer- > > encoding SHOULD be used unless this media type is sent over a > > 7-bit-only transport. > Shouldn't "content-transfer-encoding" be written similarly? (either > in plural form or in singular form) No, this one looks right to me as-is. > > The normalization process is > > described in Section 3.1 is recommended to minimize these issues. > The first "is" should be removed. Fixed. > > This media type provides > > functionality similar to the message/rfc822 content type for email > > messages with international email headers. > and: > > Email clients that forward messages with international headers as > > attachments. > "internationalized"? There are places where we use one and places where we use the other. *shrug* I guess I'll make them all internationalized for consistency, but either is really fine. Ned From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 15:10:31 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6B221F8BB3 for ; Wed, 5 Oct 2011 15:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 mO7ZhXZ6dp8g for ; Wed, 5 Oct 2011 15:10:31 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 016E221F8BB0 for ; Wed, 5 Oct 2011 15:10:30 -0700 (PDT) Received: by wwf22 with SMTP id 22so2300046wwf.13 for ; Wed, 05 Oct 2011 15:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dQFkloEkT2U7kk8+WSj3BtEwq94qboddXk2nX2di48A=; b=qTGlIq9i2x92kTuLd+7ElyHhdS/cuF5Qu1+9bBFvMCIFVig0RtWcz2zzRJ06ZONLhI rfh7O2vnOxkBiSMJGhrLk3l/ZIA26FrnplxWuBwXYJ2Du8AkSj0hgo7KVsur2cnUqC8H 0RI3dx3+GME9D7NFDk8y/DjXE6HI9zOHdFPEU= Received: by 10.227.11.81 with SMTP id s17mr286388wbs.62.1317852811109; Wed, 05 Oct 2011 15:13:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 15:12:51 -0700 (PDT) In-Reply-To: <20111005204451.8151.qmail@joyce.lan> References: <20111005204451.8151.qmail@joyce.lan> From: Frank Ellermann Date: Thu, 6 Oct 2011 00:12:51 +0200 Message-ID: To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 22:10:32 -0000 On 5 October 2011 22:44, John Levine wrote: > Mail message format is described in RFC 5322, while news article > format is described in RFC 5536. Yeah, I'm aware of 5536, it is firmly based on 5322. An earlier Usefor draft already had UTF-8, but it did not make it (roughly at the time when I felt that the "making of RFCs" is fascinating): 5536 is an application of 5322 + MIME. Son-of-1036 (1849) already had 822 + MIME, so this was not really a new idea after UTF-8 got no consensus back in 2002 or 2003. > it is just wrong to assert that you can turn one into the other > without using a gateway that deals with the differences. Nobody said that there are no gateways. About twenty years ago I ended up maintaining a list of gateway software for some time (at that time RFC822 <-> NetNews was an *apparently* simple case, and consequently this caused more troubles than the more convoluted scenarios involving other networks). IIRC that was in one of the "gatebau GABELs" (Group, Area, Boards, Echo, List; this was a "politically correct" acronym using the German word "gabel", i.e., it was no Usenet newsgroup also available in Fido or v.v., it was a neutral territory wrt the transport technologies and the resulting different admin structures.) > I read this list via a gateway that turns it into a local > newsgroup) and there's a lot of little nits they have to deal > with. For more than six years I read all IETF mailing lists on Larsi's GMaNe (Gateway MAil NEws), at the moment I try my luck with Gmail. Somewhere the EAI drafts should mention that the first ideas for UTF-8 in Internet message header fields was created by Usefor or more precisely by Charles about ten years ago. -Frank From julien@trigofacile.com Wed Oct 5 15:36:40 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDE421F8CD6 for ; Wed, 5 Oct 2011 15:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.306, 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 0XLLHPrCGo9x for ; Wed, 5 Oct 2011 15:36:40 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id 08DEE21F8CD2 for ; Wed, 5 Oct 2011 15:36:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 4ABC8816B for ; Thu, 6 Oct 2011 00:39:42 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLEIRTHnr3ZO for ; Thu, 6 Oct 2011 00:39:42 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id 19D9F8168 for ; Thu, 6 Oct 2011 00:39:42 +0200 (CEST) Message-ID: <4E8CDCAD.3000202@trigofacile.com> Date: Thu, 06 Oct 2011 00:39:41 +0200 From: =?ISO-8859-1?Q?Julien_=C9LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ima@ietf.org References: <20111005204451.8151.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 22:36:41 -0000 Hi Frank, > Somewhere the EAI drafts should mention that the first ideas for > UTF-8 in Internet message header fields was created by Usefor or > more precisely by Charles about ten years ago. Definitely. -- Julien ÉLIE « Rien, ce n'est pas rien ! La preuve, c'est que l'on peut le soustraire. Exemple : rien moins rien = moins que rien ! » (Raymond Devos) From julien@trigofacile.com Wed Oct 5 15:50:17 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B053A21F8CEE for ; Wed, 5 Oct 2011 15:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.245, 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 OwBIKB-KBk6g for ; Wed, 5 Oct 2011 15:50:17 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id C79A821F8CB7 for ; Wed, 5 Oct 2011 15:50:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 8764D816B for ; Thu, 6 Oct 2011 00:53:25 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsmHbPlLmpbS for ; Thu, 6 Oct 2011 00:53:25 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id 5C4DA8168 for ; Thu, 6 Oct 2011 00:53:25 +0200 (CEST) Message-ID: <4E8CDFE5.2040008@trigofacile.com> Date: Thu, 06 Oct 2011 00:53:25 +0200 From: =?ISO-8859-1?Q?Julien_=C9LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: IMA References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 22:50:17 -0000 Hi Frank, > The mailto: URLs are almost > ready for EAI, and the news: URLs can be "fixed" by an erratum. Wouldn't it be proper to update the RFCs instead of adding an erratum? (which would probably be "held for document update") It is not an error; it is a technical update. (Incidentally, we could try to do some work on USEAGE too, if Charles agrees. Maybe a new draft would be worthwhile, so that we could comment and make progress on it. -- Discussions on that subject should continue on the USEFOR mailing-list; it is not related to IMA.) > What can't be "fixed" might be thousands of NNTP servers, if the > operators pick the wrong of three alternatives: (1) Do nothing, > (2) upgrade, or (3) uninstall and give up on NetNews. I hope it will not split Usenet into two distinct "feeding areas": the UTF-8-aware one (with UTF-8 moderated newsgroup names, message-IDs, etc.) and the legacy one. -- Julien ÉLIE « Rien, ce n'est pas rien ! La preuve, c'est que l'on peut le soustraire. Exemple : rien moins rien = moins que rien ! » (Raymond Devos) From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 16:18:11 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BAB21F8DA7 for ; Wed, 5 Oct 2011 16:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 oDitxp9ggyGf for ; Wed, 5 Oct 2011 16:18:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9246D21F8DA4 for ; Wed, 5 Oct 2011 16:18:10 -0700 (PDT) Received: by wyh21 with SMTP id 21so2582647wyh.31 for ; Wed, 05 Oct 2011 16:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=R0Cqa5h29fFWSwZCohnoWcJumCH5ISyagv4UWips6p8=; b=YPOBiEsrDtGLHuzOJGXHs6JyNGTQC9sw+/7IU1tLO8Z3MbSQZmhQpKxz/ZkwJfVUky gtWHqUinX1ofbX1+TcKS4CH6tMwhLy+TbBEUiQGAoVS1O5U3j74jf5HHfu5YOPzv8Ryv r9jLlJTaNs0kPZY19FgJj+T5WJSVws/urV11I= Received: by 10.216.137.104 with SMTP id x82mr196400wei.77.1317856879068; Wed, 05 Oct 2011 16:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 16:20:39 -0700 (PDT) In-Reply-To: References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> From: Frank Ellermann Date: Thu, 6 Oct 2011 01:20:39 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IMA Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Oct 2011 23:18:11 -0000 On 5 October 2011 23:13, John C Klensin wrote: [Naive or broken] > I would not presume to try to categorize all of the > transformations I've seen, but some of them probably don't > fall under your description above. > This isn't trivial. ACK, but thinking that it's trivial would be covered by naive. I never had anything to do with MIXER. All I vaguely recall is related to "dupes" (=3D the same message arriving more than once where it is expected at most once) and "nopes" (=3D if an expected message arrives less than once, i.e., never, null, nada, nope). For Netnews "same message" means by definition "same Message-ID", it is a fundmental concept. Because I had a hard time to grok this years ago (in FTN the Message-ID is only optional, the real thing in FTN echos are the "Seen-By" thingies) I'm now reluctant to touch this "holy cow" of what used to be the "RFC822" side from my FTN (Fido technology network) POV. >=A0Remember that simple transcoding of header fields from > net-ASCII into, e.g., EBCDIC or what we call ISO-2022-JP > means that dumb octet-string comparisons of Message-IDs > (and other things) will fail. Actually I don't remember this issue, the "gatebau" problems with Message-IDs were limited to ASCII-compatible networks. But I can imagine how "ASCII-incompatible" offers wild and wonderful ways to get it wrong. If "they" can't do UTF-8 or at least UTF-EBCDIC they have only one EAI-option: Reject. The corner cases where only the EAI-ID causes this "reject", because everything else happens to work for say EBCDIC, are too odd to consider. > If someone asked my opinion about whether a gateway should mess > with Message-IDs, I'd say "no, unless it is absolutely required > by the systems on the other end". =A0But lots of people don't ask > and even fewer listen. =A0 Neither RFC 5321/5322 nor RFC 5536 > offer any reciprocal guarantees. RFC 1849 has a very good advice: "Avove all, prevent loops." The Usefor folks, or rather Russ, considered to write a gateway memo after 5537 (not the same as 5536). Some of the topics you didn't find in 5322 & 5536 are covered in 5321 & 5537. Sadly you can't put more about this in 5321bis, and actually it should get its own memo -- 5321 & 5537 aren't the place for gateway details. >> EAI won't make that worse. > If there are fragile systems out there -- and there almost > certainly still are-- how can you possibly know that? It is a guess: Gateway operators who manage to get it right for message/rfc822 <-> something based on EBCDIC could also manage to get it right for message/global <-> something UTF-EBCDIC, or simply reject message/global. In other words, when I'm opposed to UTF-8 in message-IDs I'm not worried about breaking gateways. > In spite of being co-author of CRAM-MD5, I don't understand this > comment at all. Certainly the CRAM-MD5 spec, regardless of its > other strengths and weaknesses, doesn't even mention Message-IDs Quoth 2195: "The syntax of the unencoded form must correspond to that of an RFC 822 'msg-id' [RFC822] as described in [POP3]." APOP and CRAM-MD5 use the syntactical form of a Message-ID for their challenges. You didn't write "globally unique forever", but the Message-ID challenges are still supposed to be "unique". -Frank From klensin@jck.com Wed Oct 5 17:08:50 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92A21F8D63 for ; Wed, 5 Oct 2011 17:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, J_BACKHAIR_44=1, 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 94jKWtrxui3q for ; Wed, 5 Oct 2011 17:08:49 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBB621F8D6E for ; Wed, 5 Oct 2011 17:08:49 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RBbZ4-000I7Q-BR; Wed, 05 Oct 2011 20:11:54 -0400 Date: Wed, 05 Oct 2011 20:11:53 -0400 From: John C Klensin To: =?UTF-8?Q?Julien_=C3=89LIE?= , IMA Message-ID: <20E612AF4F05B85D980028A1@PST.JCK.COM> In-Reply-To: <4E8CCDDC.7010908@trigofacile.com> References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> <4E8CCDDC.7010908@trigofacile.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 Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Oct 2011 00:08:50 -0000 --On Wednesday, October 05, 2011 23:36 +0200 Julien =C3=89LIE wrote: > Hi John, >=20 >> If someone asked my opinion about whether a gateway should >> mess with Message-IDs, I'd say "no, unless it is absolutely >> required by the systems on the other end". But lots of >> people don't ask and even fewer listen. Neither RFC >> 5321/5322 nor RFC 5536 offer any reciprocal guarantees. >=20 > RFC 5536 defines a stricter subset than RFC 5322 for > Message-IDs; they therefore need being checked. I agree with > your saying that they should not be modified if they have a > valid syntax for the system on the other end. >=20 > According to RFC 5537: >=20 > 3.10.2. Duties of an Incoming Gateway >=20 > If there is a message identifier that fills a role similar > to that of > the Message-ID header field in news, it SHOULD be used in > the > formation of the message identifier of the news article, > perhaps with >... Yes. This is exactly the point I was trying to make -- thanks for digging out the text. I believe it leaves us with the following cases for Message-IDs in mail<->news gateways: Direction news -> mail Since 5322 Message-IDs are less restrictive than 5536 ones, there should be no need to change anything. If a change is made, it would presumably be to better assure uniqueness on the Internet side, but still would not violate Internet rules for either unextended or=20 UTF8SMTPbis messages. Note that 5335bis permits=20 UTF-8 in Message-IDs, but certainly does not require any non-ASCII characters there. Direction mail -> news Case 1: The Message-ID is all-ASCII and otherwise conforms to the 5536 requirements. No transformation other than copying is necessary. If a change is made, it would presumably be to assure uniqueness on the news side. Nothing new here. Case 2: The Message-ID is all-ASCII but does not conform to the 5536 requirements. The gateway is required to change the mail Message-ID to a 5536 conforming one. Whatever happens, the two Message-IDs are no longer the same. Case 3: The Message-ID contains some non-ASCII characters. That doesn't conform to 5536, so the gateway is required to change it to something else, something that is 5536 conforming. Whatever happens, the two Message-IDs are no longer the same. =20 Case 3 is the only case that is dependent on or influenced by EAI/ UTF8SMTPbis. Everything else is the same. And, possible implementation details aside, there is really no difference between Case 2 and Case 3. Any competent existing gateway has to contain a test for 5536 conformance and has to contain code to generate a new Message-ID if the mail one does not conform. The only difference between the two cases is that the source of non-conformance under Case 2 is presumably some lexical problem, while the source under Case 3 is presumably the presence of one or more non-ASCII characters, which is still a lexical problem. No difference, really. Of course, if the mail-> news gateway doesn't enforce 5536, one can have all sorts of interesting problems at the news reader. But that is also true with or without the EAI work. Right? john From internet-drafts@ietf.org Wed Oct 5 17:19:00 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4500311E80AE; Wed, 5 Oct 2011 17:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 N5rDHrxDG8xq; Wed, 5 Oct 2011 17:18:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE53D11E8098; Wed, 5 Oct 2011 17:18:59 -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: 3.60 Message-ID: <20111006001859.23860.19195.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2011 17:18:59 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5337bis-dsn-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 00:19:00 -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 : Internationalized Delivery Status and Disposition Notifi= cations Author(s) : Tony Hansen Chris Newman Alexey Melnikov Filename : draft-ietf-eai-rfc5337bis-dsn-04.txt Pages : 19 Date : 2011-10-05 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798. It replaces the experimental RFC 5337. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5337bis-dsn-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-rfc5337bis-dsn-04.txt From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 17:35:04 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6136A1F0C41 for ; Wed, 5 Oct 2011 17:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 VziSBWEnPJli for ; Wed, 5 Oct 2011 17:35:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8B1F0C36 for ; Wed, 5 Oct 2011 17:35:03 -0700 (PDT) Received: by wwf22 with SMTP id 22so2392113wwf.13 for ; Wed, 05 Oct 2011 17:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RtKWdi64jZOBZvqfOzKyg1//SbeyvZbNe87hq4cEfJY=; b=F8z0h/UQXYL7T+5IuqfWmQfov6sCjAWe2YwcVybh4y/21BlxS3opo8mmAjmcDTylqg ewkSF/UPx5oUN12q9KyisGUNRqT/hpUmnjaEhfiOhn27EUfUkz4ot0F5cB1zECzmDPSs Ig1Qjz5dpFyWWOdLg++Yuko7Ka9jRYsxPQyEU= Received: by 10.216.137.104 with SMTP id x82mr275154wei.77.1317861491138; Wed, 05 Oct 2011 17:38:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 17:37:31 -0700 (PDT) In-Reply-To: <4E8CDFE5.2040008@trigofacile.com> References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> <4E8CDFE5.2040008@trigofacile.com> From: Frank Ellermann Date: Thu, 6 Oct 2011 02:37:31 +0200 Message-ID: To: =?ISO-8859-1?Q?Julien_=C9LIE?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IMA Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Oct 2011 00:35:04 -0000 On 6 October 2011 00:53, Julien =C9LIE wrote: >> The mailto: URLs are almost ready for EAI, and the >> news: URLs can be "fixed" by an erratum. > Wouldn't it be proper to update the RFCs instead of > adding an erratum? > (which would probably be "held for document update") > It is not an error; it is a technical update. The EAI mailto: IRIs are documented in an existing I-D: news: IRIs are documented in 5538, modulo one erroneous statement (if this WG gets its amended will in an IETF Last Call.) I'm not aware of "implementation reports" or any other reasons justifying more work than a simple "erratum": The secrets of percent-encoding are already covered by 3986 + 3987 + 5538. Maybe if Usefor and/or NNTP are updated for EAI it could make sense to work on a 5538bis. But as long as Usenet sticks to 5322/5536 Message-IDs that point is moot. > Incidentally, we could try to do some work on USEAGE > too, if Charles agrees. Well, I'm willing to review drafts, IIRC there were some pending IANA issues to be covered in USEAGE or "manually". Otherwise I'm not much tempted by serious IETF work at the moment, unless it is about 4408bis, 5321bis, 6068bis. > I hope it will not split Usenet into two distinct > "feeding areas": =A0the UTF-8-aware one (with UTF-8 > moderated newsgroup names, message-IDs, etc.) and the > legacy one. My best wishes for this hope, Frank From yaojk@cnnic.cn Wed Oct 5 18:21:18 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348AF21F8CD4 for ; Wed, 5 Oct 2011 18:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.196 X-Spam-Level: X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 jrC3RTbthede for ; Wed, 5 Oct 2011 18:21:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D226321F8CCA for ; Wed, 5 Oct 2011 18:21:14 -0700 (PDT) Received: (eyou send program); Thu, 06 Oct 2011 09:24:16 +0800 Message-ID: <517864256.25712@cnnic.cn> Received: from 125.33.1.173 by mail.cnnic.cn with HTTP; Thu, 06 Oct 2011 09:24:16 +0800 X-WebMAIL-MUA: [125.33.1.173] From: "Jiankang YAO" To: EAI-ADs@tools.ietf.org Date: Thu, 06 Oct 2011 09:24:16 +0800 X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_1317864256_25711.attach" Cc: ima@ietf.org, eai-chairs@tools.ietf.org Subject: [EAI] Publication request of draft-ietf-eai-rfc5335bis-12 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jiankang YAO List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 01:21:18 -0000 ------=_1317864256_25711.attach Content-Type: text/plain Dear ADs, This message is a request to publish draft-ietf-eai-rfc5335bis-12 on the Standards Track. The draft represents the rough consensus of the EAI Working Group. As required by RFC 4858, below is the completed current template for the Document Shepherd Write-Up. Best regards, Jiankang Yao(Shepherd for this document) -------------------------------------------- DRAFT FILENAME: draft-ietf-eai-rfc5335bis-12 TITLE: Internationalized Email Headers (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Jiankang Yao. Yes, I believe it is ready. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There has been a lot of discussions about this draft. An earlier version went through WG last call in Nov. 2010. That version received a significant number of comments. As a result, an additional author was added and the document restructured to address all of the issues that the WG considered substantive. In Sep. 2011, this draft got another WG last call to confirm that the revised version had gotten rough consensus. The EAI WG has been talking about this draft for very long time. I believe it has had adequate review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The question of whether this document should be identified as updating RFC 5322 remains unanswered, partially because neither the IETF nor the RFC Editor has a clear rule about the point at which document that extend a base specification but do not significant modify it are considered to be updated. Quoting the current lead editor, "we change the line length limit from 998 characters to 998 octets". This is really an i18n clarification: a count in "characters" and one in "octets" are identical for ASCII, but "octets" provides a precise and invariant length independent of character set and encoding. The WG is happy to have the IESG resolve this issue as you think appropriate. People representing the part of the Netnews community who believe that netnews and Internet mail are the same except for transport are still grousing about a decision (Message-IDs) that might have been different had the WG considered behavior on the other side of gateways as more important than smooth operation within the SMTP environment on the public Internet. There are no other known issues. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Many WG participants from EAI WG have reviewed this document and had reasonably strong WG consensus. There has been no dissent in the last two calls for comment within the WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, I have checked it. There is one outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5336bis-07 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. There are normative references to [I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5336bis], which are part of this package. The former is already in the RFC Editor queue awaiting approval of this document and draft-ietf-eai-rfc5336bis before being published. This document and draft-ietf-eai-rfc5336bis resolve those downward or missing references; they do not introduce new ones. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? No new registries, but IANA is requested to update the registration of the message/global MIME type (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies an enhancement to the Internet Message Format that allows use of Unicode in mail addresses and most header field content. Working Group Summary This document has been discussed in EAI WG for a very long time. The WG came to consensus on this document. Document Quality The documents have been extensively reviewed by people with mail expertise. It is in very good shape. (end) ------------------------------------------------------------------- ------=_1317864256_25711.attach Content-Type: text/plain; name="rfc5335bis-writup.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rfc5335bis-writup.txt" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkRlYXIgQURzLA0KDQpUaGlzIG1lc3NhZ2UgaXMgYSByZXF1ZXN0IHRvIHB1Ymxpc2gN CmRyYWZ0LWlldGYtZWFpLXJmYzUzMzViaXMtMTIgb24gdGhlIFN0YW5kYXJkcyBUcmFjay4N ClRoZSBkcmFmdCByZXByZXNlbnRzIHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhlIEVBSSBX b3JraW5nDQpHcm91cC4NCg0KQXMgcmVxdWlyZWQgYnkgUkZDIDQ4NTgsIGJlbG93IGlzIHRo ZSBjb21wbGV0ZWQgY3VycmVudCB0ZW1wbGF0ZSBmb3INCnRoZSBEb2N1bWVudCBTaGVwaGVy ZCBXcml0ZS1VcC4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWFua2FuZyBZYW8oU2hlcGhlcmQg Zm9yIHRoaXMgZG9jdW1lbnQpDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KRFJBRlQgRklMRU5BTUU6IA0KICAgIGRyYWZ0LWlldGYtZWFp LXJmYzUzMzViaXMtMTINClRJVExFOiAgICANCiAgICBJbnRlcm5hdGlvbmFsaXplZCBFbWFp bCBIZWFkZXJzDQoNCg0KDQogICgxLmEpIFdobyBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQg Zm9yIHRoaXMgZG9jdW1lbnQ/IEhhcyB0aGUNCiAgICAgICAgRG9jdW1lbnQgU2hlcGhlcmQg cGVyc29uYWxseSByZXZpZXdlZCB0aGlzIHZlcnNpb24gb2YgdGhlIA0KICAgICAgICBkb2N1 bWVudCBhbmQsIGluIHBhcnRpY3VsYXIsIGRvZXMgaGUgb3Igc2hlIGJlbGlldmUgdGhpcyAN CiAgICAgICAgdmVyc2lvbiBpcyByZWFkeSBmb3IgZm9yd2FyZGluZyB0byB0aGUgSUVTRyBm b3IgcHVibGljYXRpb24/IA0KDQpKaWFua2FuZyBZYW8uICBZZXMsIEkgYmVsaWV2ZSBpdCBp cyByZWFkeS4NCg0KICAoMS5iKSBIYXMgdGhlIGRvY3VtZW50IGhhZCBhZGVxdWF0ZSByZXZp ZXcgYm90aCBmcm9tIGtleSBXRyBtZW1iZXJzIA0KICAgICAgICBhbmQgZnJvbSBrZXkgbm9u LVdHIG1lbWJlcnM/IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgDQogICAgICAg IGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBvZiB0aGUgcmV2aWV3 cyB0aGF0IA0KICAgICAgICBoYXZlIGJlZW4gcGVyZm9ybWVkPw0KDQpUaGVyZSBoYXMgYmVl biBhIGxvdCBvZiBkaXNjdXNzaW9ucyBhYm91dCB0aGlzIGRyYWZ0LiBBbiBlYXJsaWVyDQp2 ZXJzaW9uIHdlbnQgdGhyb3VnaCBXRyBsYXN0IGNhbGwgaW4gTm92LiAyMDEwLiBUaGF0IHZl cnNpb24gcmVjZWl2ZWQNCmEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNvbW1lbnRzLiBBcyBh IHJlc3VsdCwgYW4gYWRkaXRpb25hbCBhdXRob3INCndhcyBhZGRlZCBhbmQgdGhlIGRvY3Vt ZW50IHJlc3RydWN0dXJlZCB0byBhZGRyZXNzIGFsbCBvZiB0aGUgaXNzdWVzDQp0aGF0IHRo ZSBXRyBjb25zaWRlcmVkIHN1YnN0YW50aXZlLiAgSW4gU2VwLiAyMDExLCB0aGlzIGRyYWZ0 IGdvdA0KYW5vdGhlciBXRyBsYXN0IGNhbGwgdG8gY29uZmlybSB0aGF0IHRoZSByZXZpc2Vk IHZlcnNpb24gaGFkIGdvdHRlbg0Kcm91Z2ggY29uc2Vuc3VzLiAgVGhlIEVBSSBXRyBoYXMg YmVlbiB0YWxraW5nIGFib3V0IHRoaXMgZHJhZnQgZm9yDQp2ZXJ5IGxvbmcgdGltZS4gIEkg YmVsaWV2ZSBpdCBoYXMgaGFkIGFkZXF1YXRlIHJldmlldy4gIA0KICANCiAgKDEuYykgRG9l cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBjb25jZXJucyB0aGF0IHRoZSBkb2N1bWVu dCANCiAgICAgICAgbmVlZHMgbW9yZSByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3IgYnJv YWRlciBwZXJzcGVjdGl2ZSwgDQogICAgICAgIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25h bCBjb21wbGV4aXR5LCBzb21lb25lIGZhbWlsaWFyIHdpdGggDQogICAgICAgIEFBQSwgaW50 ZXJuYXRpb25hbGl6YXRpb24gb3IgWE1MPyANCg0KTm8uDQoNCiAgKDEuZCkgRG9lcyB0aGUg RG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgDQogICAg ICAgIGlzc3VlcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJl YSBEaXJlY3Rvcg0KICAgICAgICBhbmQvb3IgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9m PyBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZSANCiAgICAgICAgb3Igc2hlIGlzIHVuY29tZm9y dGFibGUgd2l0aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3IgDQogICAgICAg IGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9yIGl0LiBJ biBhbnkgDQogICAgICAgIGV2ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3NlZCB0aG9zZSBp c3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgDQogICAgICAgIHRoYXQgaXQgc3RpbGwgd2lzaGVz IHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50LCBkZXRhaWwgdGhvc2UgDQogICAgICAgIGNvbmNl cm5zIGhlcmUuIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSByZWxhdGVkIHRvIHRoaXMgZG9jdW1l bnQgDQogICAgICAgIGJlZW4gZmlsZWQ/IElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJlZmVy ZW5jZSB0byB0aGUgDQogICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cg ZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBvbiANCiAgICAgICAgdGhpcyBpc3N1ZS4gDQoN ClRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGlkZW50 aWZpZWQgYXMgdXBkYXRpbmcNClJGQyA1MzIyIHJlbWFpbnMgdW5hbnN3ZXJlZCwgcGFydGlh bGx5IGJlY2F1c2UgbmVpdGhlciB0aGUgSUVURiBub3INCnRoZSBSRkMgRWRpdG9yIGhhcyBh IGNsZWFyIHJ1bGUgYWJvdXQgdGhlIHBvaW50IGF0IHdoaWNoIGRvY3VtZW50IHRoYXQNCmV4 dGVuZCBhIGJhc2Ugc3BlY2lmaWNhdGlvbiBidXQgZG8gbm90IHNpZ25pZmljYW50IG1vZGlm eSBpdCBhcmUNCmNvbnNpZGVyZWQgdG8gYmUgdXBkYXRlZC4gIFF1b3RpbmcgdGhlIGN1cnJl bnQgbGVhZCBlZGl0b3IsICJ3ZQ0KY2hhbmdlIHRoZSBsaW5lIGxlbmd0aCBsaW1pdCBmcm9t IDk5OCBjaGFyYWN0ZXJzIHRvIDk5OCBvY3RldHMiLiBUaGlzDQppcyByZWFsbHkgYW4gaTE4 biBjbGFyaWZpY2F0aW9uOiBhIGNvdW50IGluICJjaGFyYWN0ZXJzIiBhbmQgb25lIGluDQoi b2N0ZXRzIiBhcmUgaWRlbnRpY2FsIGZvciBBU0NJSSwgYnV0ICJvY3RldHMiIHByb3ZpZGVz IGEgcHJlY2lzZSBhbmQNCmludmFyaWFudCBsZW5ndGggaW5kZXBlbmRlbnQgb2YgY2hhcmFj dGVyIHNldCBhbmQgZW5jb2RpbmcuICBUaGUgV0cgaXMNCmhhcHB5IHRvIGhhdmUgdGhlIElF U0cgcmVzb2x2ZSB0aGlzIGlzc3VlIGFzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCg0KUGVv cGxlIHJlcHJlc2VudGluZyB0aGUgcGFydCBvZiB0aGUgTmV0bmV3cyBjb21tdW5pdHkgd2hv IGJlbGlldmUgdGhhdA0KIG5ldG5ld3MgYW5kIEludGVybmV0IG1haWwgYXJlIHRoZSBzYW1l IGV4Y2VwdCBmb3IgdHJhbnNwb3J0IGFyZSBzdGlsbCANCmdyb3VzaW5nIGFib3V0IGEgZGVj aXNpb24gKE1lc3NhZ2UtSURzKSB0aGF0IG1pZ2h0IGhhdmUgYmVlbiBkaWZmZXJlbnQNCiBo YWQgdGhlIFdHIGNvbnNpZGVyZWQgYmVoYXZpb3Igb24gdGhlIG90aGVyIHNpZGUgb2YgZ2F0 ZXdheXMgYXMgbW9yZQ0KaW1wb3J0YW50IHRoYW4gc21vb3RoIG9wZXJhdGlvbiB3aXRoaW4g dGhlIFNNVFAgZW52aXJvbm1lbnQgb24NCnRoZSBwdWJsaWMgSW50ZXJuZXQuIA0KDQpUaGVy ZSBhcmUgbm8gb3RoZXIga25vd24gaXNzdWVzLg0KDQoNCiAgKDEuZSkgSG93IHNvbGlkIGlz IHRoZSBXRyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/IERvZXMgaXQgDQogICAg ICAgIHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1 YWxzLCB3aXRoIA0KICAgICAgICBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBX RyBhcyBhIHdob2xlIHVuZGVyc3RhbmQgYW5kIA0KICAgICAgICBhZ3JlZSB3aXRoIGl0PyAg IA0KDQpNYW55IFdHIHBhcnRpY2lwYW50cyBmcm9tIEVBSSBXRyBoYXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYW5kDQogaGFkIHJlYXNvbmFibHkgc3Ryb25nIFdHIGNvbnNlbnN1cy4g IFRoZXJlIGhhcyBiZWVuIG5vIGRpc3NlbnQgaW4gdGhlDQogbGFzdCB0d28gY2FsbHMgZm9y IGNvbW1lbnQgd2l0aGluIHRoZSBXRy4NCg0KICAoMS5mKSBIYXMgYW55b25lIHRocmVhdGVu ZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSANCiAgICAgICAg ZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZs aWN0IGluIA0KICAgICAgICBzZXBhcmF0ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9u c2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IA0KICAgICAgICBzaG91bGQgYmUgaW4gYSBzZXBh cmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcyANCiAgICAgICAgZW50 ZXJlZCBpbnRvIHRoZSBJRCBUcmFja2VyLikgDQoNCk5vLg0KDQogICgxLmcpIEhhcyB0aGUg RG9jdW1lbnQgU2hlcGhlcmQgcGVyc29uYWxseSB2ZXJpZmllZCB0aGF0IHRoZSANCiAgICAg ICAgZG9jdW1lbnQgc2F0aXNmaWVzIGFsbCBJRCBuaXRzPyAoU2VlIHRoZSBJbnRlcm5ldC1E cmFmdHMgQ2hlY2tsaXN0IA0KICAgICAgICBhbmQgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rv b2xzL2lkbml0cy8pLiBCb2lsZXJwbGF0ZSBjaGVja3MgYXJlIA0KICAgICAgICBub3QgZW5v dWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdoLiBIYXMgdGhlIGRvY3VtZW50 IA0KICAgICAgICBtZXQgYWxsIGZvcm1hbCByZXZpZXcgY3JpdGVyaWEgaXQgbmVlZHMgdG8s IHN1Y2ggYXMgdGhlIE1JQiANCiAgICAgICAgRG9jdG9yLCBtZWRpYSB0eXBlIGFuZCBVUkkg dHlwZSByZXZpZXdzPyANCg0KWWVzLCBJIGhhdmUgY2hlY2tlZCBpdC4gVGhlcmUgaXMgb25l IG91dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlcg0KICB2ZXJzaW9uICgtMTMpIGV4aXN0cyBv ZiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTA3DQoNCiAgKDEuaCkgSGFzIHRoZSBkb2N1 bWVudCBzcGxpdCBpdHMgcmVmZXJlbmNlcyBpbnRvIG5vcm1hdGl2ZSBhbmQgDQogICAgICAg IGluZm9ybWF0aXZlPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1l bnRzIHRoYXQgDQogICAgICAgIGFyZSBub3QgcmVhZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFy ZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciANCiAgICAgICAgc3RhdGU/IElmIHN1Y2ggbm9y bWF0aXZlIHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhlIA0KICAgICAgICBzdHJhdGVn eSBmb3IgdGhlaXIgY29tcGxldGlvbj8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2Vz IA0KICAgICAgICB0aGF0IGFyZSBkb3dud2FyZCByZWZlcmVuY2VzLCBhcyBkZXNjcmliZWQg aW4gW1JGQzM5NjddPyBJZiANCiAgICAgICAgc28sIGxpc3QgdGhlc2UgZG93bndhcmQgcmVm ZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhIA0KICAgICAgICBEaXJlY3RvciBpbiB0aGUg TGFzdCBDYWxsIHByb2NlZHVyZSBmb3IgdGhlbSBbUkZDMzk2N10uIA0KDQpZZXMuICBUaGVy ZSBhcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gW0ktRC5pZXRmLWVhaS1mcm13cmstNDk1 MmJpc10NCmFuZCBbSS1ELmlldGYtZWFpLXJmYzUzMzZiaXNdLCB3aGljaCBhcmUgcGFydCBv ZiB0aGlzIHBhY2thZ2UuICBUaGUNCmZvcm1lciBpcyBhbHJlYWR5IGluIHRoZSBSRkMgRWRp dG9yIHF1ZXVlIGF3YWl0aW5nIGFwcHJvdmFsIG9mIHRoaXMNCmRvY3VtZW50IGFuZCBkcmFm dC1pZXRmLWVhaS1yZmM1MzM2YmlzIGJlZm9yZSBiZWluZyBwdWJsaXNoZWQuICBUaGlzDQpk b2N1bWVudCBhbmQgZHJhZnQtaWV0Zi1lYWktcmZjNTMzNmJpcyByZXNvbHZlIHRob3NlIGRv d253YXJkIG9yDQptaXNzaW5nIHJlZmVyZW5jZXM7IHRoZXkgZG8gbm90IGludHJvZHVjZSBu ZXcgb25lcy4NCg0KICAoMS5pKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVk IHRoYXQgdGhlIGRvY3VtZW50IElBTkEgDQogICAgICAgIGNvbnNpZGVyYXRpb24gc2VjdGlv biBleGlzdHMgYW5kIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgYm9keSANCiAgICAgICAgb2Yg dGhlIGRvY3VtZW50PyANCg0KWWVzLg0KDQoNCiAgICAgICAgSWYgdGhlIGRvY3VtZW50IHNw ZWNpZmllcyBwcm90b2NvbCANCiAgICAgICAgZXh0ZW5zaW9ucywgYXJlIHJlc2VydmF0aW9u cyByZXF1ZXN0ZWQgaW4gYXBwcm9wcmlhdGUgSUFOQSANCiAgICAgICAgcmVnaXN0cmllcz8g QXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVkPyBJZiANCiAgICAg ICAgdGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksIGRvZXMgaXQgZGVmaW5l IHRoZSANCiAgICAgICAgcHJvcG9zZWQgaW5pdGlhbCBjb250ZW50cyBvZiB0aGUgcmVnaXN0 cnkgYW5kIGFuIGFsbG9jYXRpb24gDQogICAgICAgIHByb2NlZHVyZSBmb3IgZnV0dXJlIHJl Z2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhIA0KICAgICAgICByZWFzb25hYmxlIG5h bWUgZm9yIHRoZSBuZXcgcmVnaXN0cnk/IFNlZSBbUkZDNTIyNl0uIElmIHRoZSANCiAgICAg ICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJvY2VzcyBoYXMgU2hl cGhlcmQgDQogICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJsZSBBcmVhIERp cmVjdG9yIHNvIHRoYXQgdGhlIElFU0cgDQogICAgICAgIGNhbiBhcHBvaW50IHRoZSBuZWVk ZWQgRXhwZXJ0IGR1cmluZyB0aGUgSUVTRyBFdmFsdWF0aW9uPyANCg0KTm8gbmV3IHJlZ2lz dHJpZXMsIGJ1dCBJQU5BIGlzIHJlcXVlc3RlZCB0byB1cGRhdGUgdGhlIHJlZ2lzdHJhdGlv biBvZiANCnRoZSBtZXNzYWdlL2dsb2JhbCBNSU1FIHR5cGUgDQoNCiAoMS5qKSBIYXMgdGhl IERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlIA0KICAg ICAgICBkb2N1bWVudCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBz dWNoIGFzIFhNTCANCiAgICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMs IGV0Yy4sIHZhbGlkYXRlIGNvcnJlY3RseSBpbiANCiAgICAgICAgYW4gYXV0b21hdGVkIGNo ZWNrZXI/IA0KDQpZZXMuDQoNCiAgKDEuaykgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2Vt ZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgDQogICAgICAgIEFubm91bmNlbWVudCBXcml0ZS1V cC4gUGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3VtZW50IA0KICAgICAgICBBbm5vdW5jZW1l bnQgV3JpdGUtVXA/IFJlY2VudCBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlDQogICAg ICAgICJBY3Rpb24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJvdmVkIGRvY3VtZW50cy4gVGhl IGFwcHJvdmFsIA0KICAgICAgICBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyBzZWN0aW9uczogDQoNCiAgICAgVGVjaG5pY2FsIFN1bW1hcnkgDQoNClRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIGFuIGVuaGFuY2VtZW50IHRvIHRoZSBJbnRlcm5ldCBNZXNzYWdlIEZv cm1hdA0KdGhhdCBhbGxvd3MgdXNlIG9mIFVuaWNvZGUgaW4gbWFpbCBhZGRyZXNzZXMgYW5k IG1vc3QgaGVhZGVyIGZpZWxkDQpjb250ZW50Lg0KDQoNCg0KICAgICBXb3JraW5nIEdyb3Vw IFN1bW1hcnkgDQogICAgICAgIA0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBkaXNjdXNzZWQg aW4gRUFJIFdHIGZvciBhIHZlcnkgbG9uZyB0aW1lLiANClRoZSBXRyBjYW1lIHRvIGNvbnNl bnN1cyBvbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KICAgICBEb2N1bWVudCBRdWFsaXR5IA0K DQpUaGUgZG9jdW1lbnRzIGhhdmUgYmVlbiBleHRlbnNpdmVseSByZXZpZXdlZCBieSBwZW9w bGUgd2l0aCBtYWlsDQpleHBlcnRpc2UuIEl0IGlzIGluIHZlcnkgZ29vZCBzaGFwZS4NCg0K KGVuZCkNCg== ------=_1317864256_25711.attach-- From internet-drafts@ietf.org Wed Oct 5 19:53:30 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC921F0C6F; Wed, 5 Oct 2011 19:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 1Yct74z+5ROg; Wed, 5 Oct 2011 19:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1155A1F0C58; Wed, 5 Oct 2011 19:53:30 -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: 3.60 Message-ID: <20111006025330.4735.67063.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2011 19:53:30 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-14.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 02:53:30 -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 : SMTP Extension for Internationalized Email Author(s) : Jiankang Yao W. Mao Filename : draft-ietf-eai-rfc5336bis-14.txt Pages : 21 Date : 2011-10-05 This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-14.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-rfc5336bis-14.txt From yaojk@cnnic.cn Thu Oct 6 01:29:44 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9521F8CC9 for ; Thu, 6 Oct 2011 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.196 X-Spam-Level: X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 SXdXs8wKcZlt for ; Thu, 6 Oct 2011 01:29:43 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 1CA4721F8CC5 for ; Thu, 6 Oct 2011 01:29:42 -0700 (PDT) Received: (eyou send program); Thu, 06 Oct 2011 16:32:45 +0800 Message-ID: <517889965.03123@cnnic.cn> Received: from 125.33.1.173 by mail.cnnic.cn with HTTP; Thu, 06 Oct 2011 16:32:45 +0800 X-WebMAIL-MUA: [125.33.1.173] From: "Jiankang YAO" To: ""@cnnic.cn, ""@cnnic.cn, EAI-ADs@tools.ietf.org Date: Thu, 06 Oct 2011 16:32:45 +0800 X-Priority: 3 Content-Type: text/plain Cc: ima@ietf.org, eai-chairs@tools.ietf.org Subject: Re: [EAI] Publication request of draft-ietf-eai-rfc5335bis-12 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jiankang YAO List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 08:29:44 -0000 BTW, this is the shepherd's report that John indicated should be forwarded. Chairs will give Last Call announcement (for all three core documents) soon. Jianakng Yao In your mail: >From: "Jiankang YAO" >Reply-To: Jiankang YAO >To: EAI-ADs@tools.ietf.org >Subject: [EAI] Publication request of draft-ietf-eai-rfc5335bis-12 >Date:Thu, 06 Oct 2011 09:24:16 +0800 > >Dear ADs, > >This message is a request to publish >draft-ietf-eai-rfc5335bis-12 on the Standards Track. >The draft represents the rough consensus of the EAI Working >Group. > >As required by RFC 4858, below is the completed current template for >the Document Shepherd Write-Up. > > >Best regards, >Jiankang Yao(Shepherd for this document) > > >-------------------------------------------- > >DRAFT FILENAME: > draft-ietf-eai-rfc5335bis-12 >TITLE: > Internationalized Email Headers > > > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > >Jiankang Yao. Yes, I believe it is ready. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > >There has been a lot of discussions about this draft. An earlier >version went through WG last call in Nov. 2010. That version received >a significant number of comments. As a result, an additional author >was added and the document restructured to address all of the issues >that the WG considered substantive. In Sep. 2011, this draft got >another WG last call to confirm that the revised version had gotten >rough consensus. The EAI WG has been talking about this draft for >very long time. I believe it has had adequate review. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > >No. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > >The question of whether this document should be identified as updating >RFC 5322 remains unanswered, partially because neither the IETF nor >the RFC Editor has a clear rule about the point at which document that >extend a base specification but do not significant modify it are >considered to be updated. Quoting the current lead editor, "we >change the line length limit from 998 characters to 998 octets". This >is really an i18n clarification: a count in "characters" and one in >"octets" are identical for ASCII, but "octets" provides a precise and >invariant length independent of character set and encoding. The WG is >happy to have the IESG resolve this issue as you think appropriate. > >People representing the part of the Netnews community who believe that netnews and >Internet mail are the same except for transport are still grousing about a >decision (Message-IDs) that might have been different had the WG considered >behavior on the other side of gateways as more >important than smooth operation within the SMTP environment on >the public Internet. > >There are no other known issues. > > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > >Many WG participants from EAI WG have reviewed this document and > had reasonably strong WG consensus. There has been no dissent in the > last two calls for comment within the WG. > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > >No. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > >Yes, I have checked it. There is one outdated reference: A later > version (-13) exists of draft-ietf-eai-rfc5336bis-07 > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > >Yes. There are normative references to [I-D.ietf-eai-frmwrk-4952bis] >and [I-D.ietf-eai-rfc5336bis], which are part of this package. The >former is already in the RFC Editor queue awaiting approval of this >document and draft-ietf-eai-rfc5336bis before being published. This >document and draft-ietf-eai-rfc5336bis resolve those downward or >missing references; they do not introduce new ones. > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? > >Yes. > > > If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? > >No new registries, but IANA is requested to update the registration of >the message/global MIME type > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > >Yes. > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > >This document specifies an enhancement to the Internet Message Format >that allows use of Unicode in mail addresses and most header field >content. > > > > Working Group Summary > >This document has been discussed in EAI WG for a very long time. >The WG came to consensus on this document. > > > > Document Quality > >The documents have been extensively reviewed by people with mail >expertise. It is in very good shape. > >(end) > > >------------------------------------------------------------------- > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www.ietf.org/mailman/listinfo/ima From chl@clerew.man.ac.uk Thu Oct 6 02:37:45 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7821F8B48 for ; Thu, 6 Oct 2011 02:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-1, 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 l32GEfRpMMT4 for ; Thu, 6 Oct 2011 02:37:41 -0700 (PDT) Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7A35521F8B54 for ; Thu, 6 Oct 2011 02:37:40 -0700 (PDT) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id 4CD0122047 for ; Thu, 6 Oct 2011 10:40:48 +0100 (BST) Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 06 Oct 2011 10:40:47 +0100 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 p969ekEB020982 for ; Thu, 6 Oct 2011 10:40:47 +0100 (BST) Date: Thu, 06 Oct 2011 10:40:46 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> <4E8CCDDC.7010908@trigofacile.com> <20E612AF4F05B85D980028A1@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20E612AF4F05B85D980028A1@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4e8d779f.103a2-4760-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Oct 2011 09:37:45 -0000 On Thu, 06 Oct 2011 01:11:53 +0100, John C Klensin wrote: > I believe it leaves us with the following cases for Message-IDs > in mail<->news gateways: > > Direction news -> mail > > Since 5322 Message-IDs are less restrictive than 5536 > ones, there should be no need to change anything.... Actually, the difference between 5322 and 5536, as it finally ended up, is miniscule (5536 does not permit a '>' inside a Message-ID, but it is wildly improbable that one would see such a '>' in a real-world email). > Direction mail -> news > > Case 1: The Message-ID is all-ASCII and otherwise > conforms to the 5536 requirements. No transformation > other than copying is necessary. If a change is made, > it would presumably be to assure uniqueness on the news > side. Nothing new here. > > Case 2: The Message-ID is all-ASCII but does not conform > to the 5536 requirements. The gateway is required to > change the mail Message-ID to a 5536 conforming one. > Whatever happens, the two Message-IDs are no longer the > same. > > Case 3: The Message-ID contains some non-ASCII > characters. That doesn't conform to 5536, so the > gateway is required to change it to something else, > something that is 5536 conforming. Whatever happens, > the two Message-IDs are no longer the same. Actually no. The best thing for a gateway to do (in the sense that it will cause the least damage/misrouting/looping/whatever) is to leave the utf-8 untouched. If some subsequent server gets upset, then its connected clients will suffer, but the article will still route its way through other servers anr thus propagate throughout the network. Maybe not standards conforming, but that is what will work best. There might just be some slight benefit in NFC normalization at that point. Standards might eventually catch up, but in the meantime servers that refused such articles would get heavily leant upon to let them through. As you say, gatewaying is a messy business, and attempts to fix "broken" messages usually make things worse. What I have suggested is well within the spirit of the gatewaying guidelines from 5537 that were quoted. My only complaint is that if EAI had required that NFC normalization in any utf-8 message-id, then that would have been one issue less for those qateways. Indeed it would have also been one issue less for _email_ user agents that like to do threading. -- 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 iesg-secretary@ietf.org Thu Oct 6 08:08:35 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AFF21F8DAC; Thu, 6 Oct 2011 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 Yim6G2+rhwBo; Thu, 6 Oct 2011 08:08:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6064121F8CFC; Thu, 6 Oct 2011 08:08:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111006150835.14243.64310.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 08:08:35 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (Internationalized Email Headers) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:08:36 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Internationalized Email Headers' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. But full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like From:, To:, and Subject:, without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format that allows use of Unicode in mail addresses and most header field content. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Oct 6 08:08:59 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9221F8DC0; Thu, 6 Oct 2011 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 qgFk9BPfKyuS; Thu, 6 Oct 2011 08:08:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8721F8D22; Thu, 6 Oct 2011 08:08:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111006150858.14577.68091.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 08:08:58 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (SMTP Extension for Internationalized Email) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:08:59 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'SMTP Extension for Internationalized Email' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5336bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5336bis/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Oct 6 08:09:24 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927D321F8DD7; Thu, 6 Oct 2011 08:09:24 -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 LGC9mpeFwI1g; Thu, 6 Oct 2011 08:09:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F2821F8DB6; Thu, 6 Oct 2011 08:09:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111006150920.14400.59919.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 08:09:20 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (Internationalized Delivery Status and Disposition Notifications) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:09:24 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Internationalized Delivery Status and Disposition Notifications' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798. It replaces the experimental RFC 5337. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5337bis-dsn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5337bis-dsn/ No IPR declarations have been submitted directly on this I-D. From julien@trigofacile.com Thu Oct 6 12:50:00 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C93111E80D4 for ; Thu, 6 Oct 2011 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.204, 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 8Y3F5ygXQC2Q for ; Thu, 6 Oct 2011 12:50:00 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id 025B311E808F for ; Thu, 6 Oct 2011 12:49:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 2E77B8169 for ; Thu, 6 Oct 2011 21:53:03 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSgjHKMpobY4 for ; Thu, 6 Oct 2011 21:53:03 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id AFDC98168 for ; Thu, 6 Oct 2011 21:53:02 +0200 (CEST) Message-ID: <4E8E071E.6060200@trigofacile.com> Date: Thu, 06 Oct 2011 21:53:02 +0200 From: =?UTF-8?B?SnVsaWVuIMOJTElF?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: IMA References: <20111004014257.8027.qmail@joyce.lan> <34E8E4E5F1CBE344994E3F8B@PST.JCK.COM> <4E8CCDDC.7010908@trigofacile.com> <20E612AF4F05B85D980028A1@PST.JCK.COM> In-Reply-To: <20E612AF4F05B85D980028A1@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] UTF-8 in Message-IDs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Oct 2011 19:50:00 -0000 Hi John, > Direction mail -> news > > Case 1: The Message-ID is all-ASCII and otherwise > conforms to the 5536 requirements. No transformation > other than copying is necessary. If a change is made, > it would presumably be to assure uniqueness on the news > side. Nothing new here. > > Case 2: The Message-ID is all-ASCII but does not conform > to the 5536 requirements. The gateway is required to > change the mail Message-ID to a 5536 conforming one. > Whatever happens, the two Message-IDs are no longer the > same. > > Case 3: The Message-ID contains some non-ASCII > characters. That doesn't conform to 5536, so the > gateway is required to change it to something else, > something that is 5536 conforming. Whatever happens, > the two Message-IDs are no longer the same. > > Case 3 is the only case that is dependent on or influenced by > EAI/ UTF8SMTPbis. Everything else is the same. And, possible > implementation details aside, there is really no difference > between Case 2 and Case 3. Any competent existing gateway has > to contain a test for 5536 conformance and has to contain code > to generate a new Message-ID if the mail one does not conform. Existing gateways conforming to RFC 5322 may also decide to reject mails containing non-ASCII chars in their Message-IDs. We would then notice a loss of articles in Netnews. Such gateways need being updated. (Which is also the case for any mail agent not knowing EAI / UTF8SMTPbis.) So, yes, I agree that Case 2 and Case 3 are the same for EAI-aware gateways. > Of course, if the mail-> news gateway doesn't enforce 5536, one > can have all sorts of interesting problems at the news reader. > But that is also true with or without the EAI work. Yes, I agree. The issue also affects Supersedes:, Control: and References: header fields, to mention only the most frequently used. > Right? I think you're right. -- Julien ÉLIE « Rien, ce n'est pas rien ! La preuve, c'est que l'on peut le soustraire. Exemple : rien moins rien = moins que rien ! » (Raymond Devos) From julien@trigofacile.com Thu Oct 6 12:59:00 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281CA21F8D92 for ; Thu, 6 Oct 2011 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE6G2zL8XyRC for ; Thu, 6 Oct 2011 12:58:59 -0700 (PDT) Received: from denver.dinauz.org (denver.dinauz.org [91.121.7.193]) by ietfa.amsl.com (Postfix) with ESMTP id A189021F8D84 for ; Thu, 6 Oct 2011 12:58:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id D48EC8169 for ; Thu, 6 Oct 2011 22:02:10 +0200 (CEST) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5octJpcVILL for ; Thu, 6 Oct 2011 22:02:10 +0200 (CEST) Received: from MacBook-Pro-de-Julien-Elie.local (AAubervilliers-552-1-113-19.w86-218.abo.wanadoo.fr [86.218.80.19]) by denver.dinauz.org (Postfix) with ESMTPSA id A8A4C8168 for ; Thu, 6 Oct 2011 22:02:10 +0200 (CEST) Message-ID: <4E8E0942.80109@trigofacile.com> Date: Thu, 06 Oct 2011 22:02:10 +0200 From: =?UTF-8?B?SnVsaWVuIMOJTElF?= Organization: TrigoFACILE -- http://www.trigofacile.com/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ima@ietf.org References: <4E8CB3EE.10500@trigofacile.com> <01O6V25Y505G014O5Z@mauve.mrochek.com> In-Reply-To: <01O6V25Y505G014O5Z@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [EAI] Question about draft-ietf-eai-rfc5335bis-12.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 19:59:00 -0000 Hi Ned, > Longer answer: There is no expectation that the current use of utf-8 will ever > be "upgraded" to utf-16, utf-32, or anything else. Utf-8 is where we're headed. > See RFC 2277. OK, thanks for your answer. Also many thanks to Frank for his detailed history on this subject. >>> Background: Normally, transfer of message/global will be done in >>> 8-bit-clean channels, and body parts will have "identity" encodings, >>> that is, no decoding is necessary. > >> Two spaces after ":", as it is already the case in the rest of the document. > > I just checked; there is no other place where two spaces are used. I dislike > this sort of double spacing and so don't use it. (If the RFC Editor disagrees > that's fine too.) Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted. Security considerations: See Section 4. […] >> [Section 3.7] >>> Encoding considerations: […] >>> The 8-bit or binary content-transfer-encodings are recommended >>> where permitted. >>> […] >>> Restrictions on usage: […] The 8-bit or binary content-transfer- >>> encoding SHOULD be used unless this media type is sent over a >>> 7-bit-only transport. > >> Shouldn't "content-transfer-encoding" be written similarly? (either >> in plural form or in singular form) > > No, this one looks right to me as-is. The same construction "The 8-bit or binary content-transfer-encoding(s)" is used in the quoted paragraphs above. I thought it should be homogenized. -- Julien ÉLIE « – C'est un drôle de nom, HCL. – C'est son immatriculation d'espion. Son vrai nom, c'est Acidcloridrix… » (Astérix) From ned+ima@mrochek.com Thu Oct 6 14:54:07 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C190421F8D3A for ; Thu, 6 Oct 2011 14:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-SkukkPQCxV for ; Thu, 6 Oct 2011 14:54:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0763B21F8D37 for ; Thu, 6 Oct 2011 14:54:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O6WG3P2O1S0164T6@mauve.mrochek.com> for ima@ietf.org; Thu, 6 Oct 2011 14:55:14 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O6N7EP1TCG014O5Z@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 6 Oct 2011 14:55:12 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01O6WG3NQFAU014O5Z@mauve.mrochek.com> Date: Thu, 06 Oct 2011 14:52:35 -0700 (PDT) In-reply-to: "Your message dated Thu, 06 Oct 2011 22:02:10 +0200" <4E8E0942.80109@trigofacile.com> References: <4E8CB3EE.10500@trigofacile.com> <01O6V25Y505G014O5Z@mauve.mrochek.com> <4E8E0942.80109@trigofacile.com> To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Cc: ima@ietf.org Subject: Re: [EAI] Question about draft-ietf-eai-rfc5335bis-12.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 21:54:07 -0000 > Hi Ned, > > Longer answer: There is no expectation that the current use of utf-8 will ever > > be "upgraded" to utf-16, utf-32, or anything else. Utf-8 is where we're headed. > > See RFC 2277. > OK, thanks for your answer. > Also many thanks to Frank for his detailed history on this subject. > >>> Background: Normally, transfer of message/global will be done in > >>> 8-bit-clean channels, and body parts will have "identity" encodings, > >>> that is, no decoding is necessary. > > > >> Two spaces after ":", as it is already the case in the rest of the document. > > > > I just checked; there is no other place where two spaces are used. I dislike > > this sort of double spacing and so don't use it. (If the RFC Editor disagrees > > that's fine too.) > Encoding considerations: Any content-transfer-encoding is permitted. > The 8-bit or binary content-transfer-encodings are recommended > where permitted. > Security considerations: See Section 4. > […] I'm talking about the source file, not the xml2rfc output. I have no control over whether or not xml2rfc double spaces after colons or periods. > >> [Section 3.7] > >>> Encoding considerations: […] > >>> The 8-bit or binary content-transfer-encodings are recommended > >>> where permitted. > >>> […] > >>> Restrictions on usage: […] The 8-bit or binary content-transfer- > >>> encoding SHOULD be used unless this media type is sent over a > >>> 7-bit-only transport. > > > >> Shouldn't "content-transfer-encoding" be written similarly? (either > >> in plural form or in singular form) > > > > No, this one looks right to me as-is. > The same construction "The 8-bit or binary content-transfer-encoding(s)" > is used in the quoted paragraphs above. I thought it should be homogenized. And I disagree. The mistake is the choice of article, not the use of singular or plural. Ned From duerst@it.aoyama.ac.jp Thu Oct 13 23:39:34 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8412921F8C46 for ; Thu, 13 Oct 2011 23:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.49 X-Spam-Level: X-Spam-Status: No, score=-98.49 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 VPTV0Kh60SsA for ; Thu, 13 Oct 2011 23:39:33 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8C31721F8C04 for ; Thu, 13 Oct 2011 23:39:33 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9E6dPaL027413 for ; Fri, 14 Oct 2011 15:39:25 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4dc4_7125_426c4ad6_f62f_11e0_ae55_001d096c5782; Fri, 14 Oct 2011 15:39:25 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44033) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 14 Oct 2011 15:39:28 +0900 Message-ID: <4E97D91B.7090006@it.aoyama.ac.jp> Date: Fri, 14 Oct 2011 15:39:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "idna-update@alvestrand.no" , "public-iri@w3.org" , "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [EAI] Fwd: PRI #185 Reminder (Revision of UBA for improved display of URL/IRIs) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Oct 2011 06:39:34 -0000 I'm forwarding this here because I think comments from the IETF, and coordination between the IETF and the Unicode Consortium, are very important. This is about the display of RTL (right-to-left) and bidirectional IRIs, IDNs, and email addresses. I'm at the Unicode Conference next week, so I'll be able to talk to some people directly, but I'm not sure I'll be able to submit comments. Regards, Martin. -------- Original Message -------- Subject: PRI #185 Reminder (Revision of UBA for improved display of URL/IRIs) Date: Thu, 13 Oct 2011 13:33:51 -0700 From: Rick McGowan CC: Mark Davis ☕ Hello Everyone, You are receiving this because you submitted comments on PRI #185 in the past. The PRI background document and statement of the issue have changed since the previous review period prior to the August UTC meeting, so you may want to review the updated documents and submit new comments before this review period closes on October 24. This PRI and feedback will be discussed at the next UTC meeting, October 31 - November 4. The PRI page is here: http://www.unicode.org/review/pri185/ including links to relevant documents. This is a moderated PRI, and the discussion forum is here: http://www.unicode.org/forum/viewforum.php?f=34 Regards, Rick From jyee@afilias.info Fri Oct 14 14:18:33 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B846A21F8B48 for ; Fri, 14 Oct 2011 14:18:33 -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 UnEhSjO+uGpA for ; Fri, 14 Oct 2011 14:18:16 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7682721F8B1A for ; Fri, 14 Oct 2011 14:18:15 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1REp8w-00066v-4j for ima@ietf.org; Fri, 14 Oct 2011 21:18:14 +0000 Received: from mail-yw0-f50.google.com ([209.85.213.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1REp8w-0002JC-47 for ima@ietf.org; Fri, 14 Oct 2011 21:18:14 +0000 Received: by ywm13 with SMTP id 13so2710982ywm.9 for ; Fri, 14 Oct 2011 14:18:13 -0700 (PDT) Received: by 10.236.184.10 with SMTP id r10mr14879711yhm.81.1318627093479; Fri, 14 Oct 2011 14:18:13 -0700 (PDT) Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id p8sm6645535yhe.17.2011.10.14.14.18.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 14:18:12 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 17:18:11 -0400 To: "ima@ietf.org WG" Message-Id: <9883F525-ABA5-46C5-9F3C-AB709D8489DE@afilias.info> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] session scheduled for IETF82 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Oct 2011 21:18:33 -0000 All, The IETF82 tentative schedule and agenda are available now: https://datatracker.ietf.org/meeting/82/agenda.txt EAI is scheduled for Tuesday 1pm - 3pm 1300-1500 Afternoon Session I 101D APP eai Email Address = Internationalization WG 101B INT multimob Multicast = Mobility WG 102 INT trill = Transparent Interconnection of Lots of Links WG 201 ABC IRTF IRTF IRTF Open Meeting=20 101C OPS netmod NETCONF Data Modeling = Language WG 201 DEF RAI dispatch Dispatch WG 3F Banquet RTG ccamp Common Control and Measurement = Plane WG 101A SEC krb-wg Kerberos WG Please let John and I know for any conflict. Thanks Joseph From internet-drafts@ietf.org Fri Oct 21 20:28:32 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F16611E8091; Fri, 21 Oct 2011 20:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 zvzOg4cWI5y1; Fri, 21 Oct 2011 20:28:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC80F21F8669; Fri, 21 Oct 2011 20:28:31 -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: 3.61 Message-ID: <20111022032831.9354.77950.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2011 20:28:31 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-13.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: Sat, 22 Oct 2011 03:28:32 -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 : Internationalized Email Headers Author(s) : Abel Yang Shawn Steele Ned Freed Filename : draft-ietf-eai-rfc5335bis-13.txt Pages : 14 Date : 2011-10-21 Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. But full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like From:, To:, and Subject:, without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification replaces RFC 5335. This specification also updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer-encodings on subtypes of "message/". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-13.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-rfc5335bis-13.txt From klensin@jck.com Mon Oct 24 12:22:32 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDBA21F8BD7 for ; Mon, 24 Oct 2011 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZChVubcxCOy for ; Mon, 24 Oct 2011 12:22:28 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id E1D2421F8BD8 for ; Mon, 24 Oct 2011 12:22:15 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RIQ64-0007ks-SJ; Mon, 24 Oct 2011 15:22:13 -0400 Date: Mon, 24 Oct 2011 15:22:03 -0400 From: John C Klensin To: ima@ietf.org, Joseph Yee Message-ID: <6176C39A9E52DA71C816F24B@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========C6C543B10401EB114DF5==========" Subject: [EAI] State of the core 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: Mon, 24 Oct 2011 19:22:32 -0000 --==========C6C543B10401EB114DF5========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. We have some problems/ issues with the documents. The co-chairs and editor team have developed a strategy that Pete is ok with if the WG is. The strategy is outlined below; this is your chance to object if you have serious problems with it. However, most of the issues are procedural; as far as I can tell, only one of them has any effect on the protocols at all and it is very narrow (and one that neither the WG nor the IESG caught). Joseph is out of pocket due to the ICANN meeting so I'm taking the liberty of asking the questions. If anyone has strong opinions, we will wait for him to evaluate the consensus. I will, however, take even a couple of days of silence as an indication that we should go ahead as outlined below. Note that the recently-posted version of 5335bis and a version of 5336bis that is now in the pipeline are consistent with this strategy. As many of you know, the IESG has raised many issues with the three core documents (5335bis, 5336bis, and 5337bis). While many of these have been comments, rather than (blocking) DISCUSS positions, we need to respond to the comments (like any other Last Call comments) in some way. The vast majority of the comments fall into three categories: (1) We failed to properly identify downrefs to informational documents. One of the problem target documents (for both 5335bis and 5336bis) is 4952bis (framework). The others vary from one of the new documents to the next but all of them are only questionably normative or required. They can be moved to informative or standards track documents substituted with, at most, a little rewording. The problem was due in part to a communications disconnect between Pete and the co-chairs: the shepherd reports identified the issues, Pete didn't mention it in the Last Call, and Joseph and I didn't catch that immediately. This would be trivial except that unless we do "something else", the documents will need to be put through IETF Last Call again. See below for "something else". (2) We failed to say explicitly that the new documents should cause the experimental ones to be reclassified as Historic. Reclassifying them is probably reasonable but, given the nature of the experimental specs and the care we have taken to make sure that implementations of them cannot interfere with the final versions, it really doesn't make a lot of difference, at least IMO. (3) Several IESG members have asked for more detail in the documents about changes from the experimental documents. Some want a little more, some want a lot more. Several of us are, to put it mildly, not impressed with those requests: it is not that the experimental specs are actually widely-deployed standards-track specs with implementers and users to whom we have to explain differences. In addition, a great deal of the material that has been asked for is already in 4952bis. That is exactly where we decided to put it, but the IESG approved 4952bis around 13 months ago and have collectively forgotten it. In the process of trying to sort things out, I went back and looked carefully at 4952bis and discovered that it violates a number of rules that the IESG is now taking very seriously. In particular, it contains a good deal of normative requirements language. We gave the IESG its choice as to whether to process it as Informational or Standards Track. They selected Informational, which made sense at the time. In the light of the new rules (or newly-enforced rules), that was a mistake -- it should have been treated as standards track. In addition, as an accident of how the document was published, it contains normative references to documents that have not yet been approved yet (the POP/ IMAP/ POP-IMAP-downgrade specs) and documents that haven't been written yet (various of the things we've been referring to as "advice" documents). The RFC Editor didn't catch those and list them in the queue, probably because of the way the references were constructed, but I'm quite sure that, if they start editing, they will find the references and everything will go into "Missref hold". That, from my point of view, would be a disaster. So I/we propose the following wrt the IESG comments. This note is to see if anyone in WG has strong objections. -- We fix 5335bis, 5336bis, and 5337bis as required/ suggested by the IESG comments, including fixing things so that only references to each other and 4952bis are normative and explicitly moving their obsolete predecessors to Historic. We don't do an in-depth change summary in any of them but instead point the reader to 4952bis. That does not require a new Last Call on any of them if 4952bis is processed as Standards Track. -- We reopen 4952bis to eliminate the normative dependences on documents that aren't finished (or written), clean up the change descriptions a bit, and update references before someone whines about those. We then ask Pete to issue a Last Call on the changes only and to target it for Proposed Standard, eliminating the problem with the normative language and with references from the other docs. The 4952bis revision is ready; I will post it relatively soon unless people object. Even if we don't ask the IESG to process it for Proposed Standard, most of the changes are needed to permit 5335bis-5337bis and it to be published without waiting for everyone else, so, unless people are willing to wait (probably a year or more at the WG's current speed) for publication, the WG presumably should review it in any event. Pete and I believe that it will then have to be put out for a two-week Last Call on the changes whether we try to move it to Standard Track or not -- it would be hard to justify these changes as mere editorial tuning of the kind that we might otherwise apply at AUTH48. The non-IESG issue is that there is a table of trace field "WITH" keywords in 5336bis. It clearly needs correction so its descriptions point to UTF8SMTPbis, rather than UTF8SMTP. But the keywords are the same as those used in 5336. Alexey believes we discussed the issue and concluded that we should retain the keywords unaltered. I don't remember but assume that he is correct. One way or the other, this is your last chance to object: if you are convinced the WITH keywords should be changed, speak up. If you are convinced that they absolutely should not be changed, explain why. If there is controversy, Joseph will have to sort it out (and those who care will have to take responsibility for the delay). Otherwise, the keywords in the document (which have been around for a _long_ time without objections) will be retained. Questions or comments welcome, but, if you have any, make them soon, please. And, please, in the interest of WG progress, please do not use this as an excuse to revisit old issues: Joseph and I hope that the Taipei meeting can concentrate on the POP, IMAP, and related downgrade specs and on a discussion about how (or if) we want to proceed on the other documents. If we get bogged down now, we will need to put these documents on the agenda, probably resulting in considerable further delays. best, john --==========C6C543B10401EB114DF5========== Content-Type: text/plain; charset=us-ascii; name="eai-frmwrk-4952bis-11a.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="eai-frmwrk-4952bis-11a.txt"; size=78761 Email Address Internationalization J. Klensin (EAI) Internet-Draft Y. Ko Obsoletes: 4952, 5504, 5825 ICU (if approved) October 21, 2011 Intended status: Standards Track Expires: April 23, 2012 Overview and Framework for Internationalized Email draft-ietf-eai-frmwrk-4952bis-11a Abstract Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952; it reflects additional issues identified since that document was published. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 23, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Klensin & Ko Expires April 23, 2012 [Page 1] Internet-Draft EAI Framework October 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Role of This Specification . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8 4.6. Conventional Message and Internationalized Message . . . . 8 4.7. Undeliverable Messages, Notification, and Delivery Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Overview of the Approach and Document Plan . . . . . . . . . . 9 6. Review of Experimental Results . . . . . . . . . . . . . . . . 10 7. Overview of Protocol Extensions and Changes . . . . . . . . . 10 7.1. SMTP Extension for Internationalized Email Address . . . . 10 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12 8. Downgrading before and after SMTP Transactions . . . . . . . . 12 8.1. Downgrading before or during Message Submission . . . . . 13 8.2. Downgrading or Other Processing After Final SMTP Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15 10. User Interface and Configuration Issues . . . . . . . . . . . 15 Klensin & Ko Expires April 23, 2012 [Page 2] Internet-Draft EAI Framework October 2011 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 16 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18 11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18 11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19 12. Key Changes From the Experimental Protocols and Framework . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21 16.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 27 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 28 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 29 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 29 A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 29 A.8. Changes between -07 and -08 (after IETF Last Call) . . . . 29 A.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 29 A.10. Changes between -09 and -10 . . . . . . . . . . . . . . . 29 A.11. Changes between -10 and -11 . . . . . . . . . . . . . . . 29 Klensin & Ko Expires April 23, 2012 [Page 3] Internet-Draft EAI Framework October 2011 1. Introduction Note in Draft and to RFC Editor: The keyword represented in this document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;) is a placeholder. The actual keyword will be assigned when the standards track SMTP extension in this series [RFC5336bis-SMTP] is approved for publication and should be substituted here. This paragraph should be treated as normative reference to that SMTP extension draft, creating a reference hold until it is approved by the IESG. The paragraph should be removed before RFC publication. In order to use internationalized email addresses, we need to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC5890], while the local part is not. Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME [RFC2045] enables the transport of non-ASCII data, it does not provide a mechanism for internationalized email addresses. In RFC 2047 [RFC2047], MIME defines an encoding mechanism for some specific message header fields to accommodate non-ASCII data. However, it does not permit the use of email addresses that include non-ASCII characters. Without the extensions defined here, or some equivalent set, the only way to incorporate non-ASCII characters in any part of email addresses is to use RFC 2047 coding to embed them in what RFC 5322 [RFC5322] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant header fields. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all. This document is a replacement for RFC 4952 [RFC4952]; it reflects additional issues, shared terminology, and some architectural changes identified since that document was published. It obsoletes that document and RFCs 5504 [RFC5504] and 5825 [RFC5825], which are no longer needed due to the changes discussed in Section 12. The RFC Editor is requested to move all three of those documents to Historic. The pronouns "he" and "she" are used interchangeably to indicate a human of indeterminate gender. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Although this document is Informational, those requirements are consistent with requirements specified in the Standards Track documents in this set as described in Section 5. Klensin & Ko Expires April 23, 2012 [Page 4] Internet-Draft EAI Framework October 2011 2. Role of This Specification This document presents the overview and framework for an approach to the next stage of email internationalization. This new stage requires not only internationalization of addresses and header fields, but also associated transport and delivery models. A prior version of this specification, RFC 4952 [RFC4952], also provided an introduction to a series of experimental protocols [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This revised form provides overview and conceptual information for the standards-track successors of a subset of those protocols. Details of the documents and the relationships among them appear in Section 5 and a discussion of what was learned from the Experimental protocols and their implementations appears in Section 6. Taken together, these specifications provide the details for a way to implement and support internationalized email. The document itself describes how the various elements of email internationalization fit together and the relationships among the primary specifications associated with message transport, header formats, and handling. This document, and others that comprise the collection described above, assume a reasonable familiarity with the basic Internet electronic mail specifications and terminology [RFC5321][RFC5322] and the MIME [RFC2045] and 8BITMIME [RFC6152] ones as well. While not strictly required to implement this specification, a general familiarity with the terminology and functions of IDNA [RFC5890][RFC5891] [RFC5892][RFC5893] [RFC5894] are also assumed. 3. Problem Statement Internationalizing Domain Names in Applications (IDNA) [RFC5890] permits internationalized domain names, but deployment has not yet reached most users. One of the reasons for this is that we do not yet have fully internationalized naming schemes. Domain names are just one of the various names and identifiers that are required to be internationalized. In many contexts, until more of those identifiers are internationalized, internationalized domain names alone have little value. Email addresses are prime examples of why it is not good enough to just internationalize the domain name. As most observers have learned from experience, users strongly prefer email addresses that resemble names or initials to those involving seemingly meaningless strings of letters or numbers. Unless the entire email address can use familiar characters and formats, users will perceive email as being culturally unfriendly. If the names and initials used in email addresses can be expressed in the native languages and writing Klensin & Ko Expires April 23, 2012 [Page 5] Internet-Draft EAI Framework October 2011 systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script. Internationalization of email addresses is not merely a matter of changing the SMTP envelope; or of modifying the From, To, and Cc header fields; or of permitting upgraded Mail User Agents (MUAs) to decode a special coding and respond by displaying local characters. To be perceived as usable, the addresses must be internationalized and handled consistently in all of the contexts in which they occur. This requirement has far-reaching implications: collections of patches and workarounds are not adequate. Even if they were adequate, a workaround-based approach may result in an assortment of implementations with different sets of patches and workarounds having been applied with consequent user confusion about what is actually usable and supported. Instead, we need to build a fully internationalized email environment, focusing on permitting efficient communication among those who share a language or other community. That, in turn, implies changes to the mail header environment to permit the full range of Unicode characters where that makes sense, an SMTP Extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing and delivery of those extended header fields, support for internationalization of delivery and service notifications [RFC3461] [RFC3464], and (finally) a requirement for support of the 8BITMIME SMTP Extension [RFC6152] so that all of these can be transported through the mail system without having to overcome the limitation that header fields do not have content-transfer-encodings. 4. Terminology This document assumes a reasonable understanding of the protocols and terminology of the core email standards as documented in [RFC5321] and [RFC5322]. 4.1. Mail User and Mail Transfer Agents Much of the description in this document depends on the abstractions of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). However, it is important to understand that those terms and the underlying concepts postdate the design of the Internet's email architecture and the application of the "protocols on the wire" principle to it. That email architecture, as it has evolved, and that "on the wire" principle have prevented any strong and standardized distinctions about how MTAs and MUAs interact on a given origin or destination host (or even whether they are separate). However, the term "final delivery MTA" is used in this document in a fashion equivalent to the term "delivery system" or "final delivery Klensin & Ko Expires April 23, 2012 [Page 6] Internet-Draft EAI Framework October 2011 system" of RFC 5321. This is the SMTP server that controls the format of the local parts of addresses and is permitted to inspect and interpret them. It receives messages from the network for delivery to mailboxes or for other local processing, including any forwarding or aliasing that changes envelope addresses, rather than relaying. From the perspective of the network, any local delivery arrangements such as saving to a message store, handoff to specific message delivery programs or agents, and mechanisms for retrieving messages are all "behind" the final delivery MTA and hence are not part of the SMTP transport or delivery process. 4.2. Address Character Sets In this document, an address is "all-ASCII", or just an "ASCII address", if every character in the address is in the ASCII character repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address", if any character is not in the ASCII character repertoire. Such addresses MAY be restricted in other ways, but those restrictions are not relevant to this definition. The term "all-ASCII" is also applied to other protocol elements when the distinction is important, with "non-ASCII" or "internationalized" as its opposite. The umbrella term to describe the email address internationalization specified by this document and its companion documents is "UTF8SMTPbis". [[anchor3: Note in Draft: Keyword to be changed before publication.]] For example, an address permitted by this specification is referred to as a "UTF8SMTPbis (compliant) address". Please note that, according to the definitions given here, the set of all "all-ASCII" addresses and the set of all "non-ASCII" addresses are mutually exclusive. The set of all addresses permitted when UTF8SMTPbis appears is the union of these two sets. 4.3. User Types An "ASCII user" (i) exclusively uses email addresses that contain ASCII characters only, and (ii) cannot generate recipient addresses that contain non-ASCII characters. An "i18mail user" has one or more non-ASCII email addresses, or is able to generate recipient addresses that contain non-ASCII characters. Such a user may have ASCII addresses too; if the user has more than one email account and a corresponding address, or more than one alias for the same address, he or she has some method to choose which address to use on outgoing email. Note that under this definition, it is not possible to tell from an ASCII address if the owner of that address is an i18mail user or not. (A non-ASCII Klensin & Ko Expires April 23, 2012 [Page 7] Internet-Draft EAI Framework October 2011 address implies a belief that the owner of that address is an i18mail user.) There is no such thing as an "i18mail message"; the term applies only to users and their agents and capabilities. In particular, the use of non-ASCII message content is an integral part of the MIME specifications [RFC2045] and does not require these extensions (although it is compatible with them). 4.4. Messages A "message" is sent from one user (sender) using a particular email address to one or more other recipient email addresses (often referred to just as "users" or "recipient users"). 4.5. Mailing Lists A "mailing list" is a mechanism whereby a message may be distributed to multiple recipients by sending it to one recipient address. An agent (typically not a human being) at that single address then causes the message to be redistributed to the target recipients. This agent sets the envelope return address of the redistributed message to a different address from that of the original single recipient message. Using a different envelope return address (reverse-path) causes error (and other automatically generated) messages to go to an error handling address. Special provisions for managing mailing lists that might contain non- ASCII addresses are discussed in a document that is specific to that topic [RFC5983] [RFC5983bis-MailingList]. 4.6. Conventional Message and Internationalized Message o A conventional message is one that does not use any extension defined in the SMTP extension document [RFC5336] or in the UTF8header specification [RFC5335], and is strictly conformant to RFC 5322 [RFC5322]. o An internationalized message is a message utilizing one or more of the extensions defined in this set of specifications, so that it is no longer conformant to the traditional specification of an email message or its transport. 4.7. Undeliverable Messages, Notification, and Delivery Receipts As specified in RFC 5321, a message that is undeliverable for some reason is expected to result in notification to the sender. This can occur in either of two ways. One, typically called "Rejection", occurs when an SMTP server returns a reply code indicating a fatal error (a "5yz" code) or persistently returns a temporary failure Klensin & Ko Expires April 23, 2012 [Page 8] Internet-Draft EAI Framework October 2011 error (a "4yz" code). The other involves accepting the message during SMTP processing and then generating a message to the sender, typically known as a "Non-delivery Notification" or "NDN". Current practice often favors rejection over NDNs because of the reduced likelihood that the generation of NDNs will be used as a spamming technique. The latter, NDN, case is unavoidable if an intermediate MTA accepts a message that is then rejected by the next-hop server. A sender MAY also explicitly request message receipts [RFC3461] that raise the same issues for these internationalization extensions as NDNs. 5. Overview of the Approach and Document Plan This set of specifications changes both SMTP and the character encoding of email message headers to permit non-ASCII characters to be represented directly. Each important component of the work is described in a separate document. The document set, whose members are described below, also contains informational documents whose purpose is to provide implementation suggestions and guidance for the protocols. In addition to this document, the following documents make up this specification and provide advice and context for it. o SMTP extension. The SMTP extension document [RFC5336bis-SMTP] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses. o Email message headers in UTF-8. The email message header document [RFC5335bis-Hdrs] essentially updates RFC 5322 to permit some information in email message headers to be expressed directly by Unicode characters encoded in UTF-8 when the SMTP extension described above is used. This document, possibly with one or more supplemental ones, will also need to address the interactions with MIME, including relationships between UTF8SMTPbis and internal MIME headers and content types. o Extensions to delivery status and notification handling to adapt to internationalized addresses [RFC5337bis-DSN]. o Forthcoming documents will specify extensions to the IMAP protocol [RFC3501] to support internationalized message headers [RFC5738bis-IMAP], Parallel extensions to the POP protocol [RFC5721] [RFC5721bis-POP3], and some common properties of the two [POPIMAP-downgrade]. Klensin & Ko Expires April 23, 2012 [Page 9] Internet-Draft EAI Framework October 2011 6. Review of Experimental Results The key difference between this set of protocols and the experimental set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a mechanism for in-transit downgrading of messages (described in detail in RFC 5504). That mechanism permitted, and essentially required, that each non-ASCII address be accompanied by an all-ASCII equivalent. That, in turn, raised security concerns associated with pairing of addresses that could not be authenticated. It also introduced the first incompatible change to Internet mail addressing in many years, raising concerns about interoperability issues if the new address forms "leaked" into legacy email implementations. The WG concluded that the advantages of in-transit downgrading, were it feasible operationally, would be significant enough to overcome those concerns. Operationally that turned out to not be the case, with interoperability problems among initial implementations. Prior to starting on the work that led to this set of specifications, the WG concluded that the combination of requirements and long-term implications of that earlier model were too complex to be satisfactory and that work should move ahead without it. The other significant change to the protocols themselves is that the UTF8SMTPbis keyword is now required as an SMTP client announcement if the extension is needed; in the experimental version, only the server announcement that an extended envelope and/or content were permitted was necessary. 7. Overview of Protocol Extensions and Changes 7.1. SMTP Extension for Internationalized Email Address An SMTP extension, "UTF8SMTPbis" is specified as follows: o Permits the use of UTF-8 strings in email addresses, both local parts and domain names. o Permits the selective use of UTF-8 strings in email message headers (see Section 7.2). o Requires that the server advertise the 8BITMIME extension [RFC6152] and that the client support 8-bit transmission so that header information can be transmitted without using a special content-transfer-encoding. Some general principles affect the development decisions underlying Klensin & Ko Expires April 23, 2012 [Page 10] Internet-Draft EAI Framework October 2011 this work. 1. Email addresses enter subsystems (such as a user interface) that may perform charset conversions or other encoding changes. When the local part of the address includes characters outside the ASCII character repertoire, use of ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to promote consistent processing of characters throughout the address. 2. An SMTP relay MUST * Either recognize the format explicitly, agreeing to do so via an ESMTP option, or * Reject the message or, if necessary, return a non-delivery notification message, so that the sender can make another plan. 3. If the message cannot be forwarded because the next-hop system cannot accept the extension it MUST be rejected or a non-delivery message MUST be generated and sent. 4. In the interest of interoperability, charsets other than UTF-8 are prohibited in mail addresses and message headers being transmitted over the Internet. There is no practical way to identify multiple charsets properly with an extension similar to this without introducing great complexity. Conformance to the group of standards specified here for email transport and delivery requires implementation of the SMTP Extension specification and the UTF-8 Header specification. If the system implements IMAP or POP, it MUST conform to the i18n IMAP [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications respectively. 7.2. Transmission of Email Header Fields in UTF-8 Encoding There are many places in MUAs or in a user presentation in which email addresses or domain names appear. Examples include the conventional From, To, or Cc header fields; Message-ID and In-Reply-To header fields that normally contain domain names (but that may be a special case); and in message bodies. Each of these must be examined from an internationalization perspective. The user will expect to see mailbox and domain names in local characters, and to see them consistently. If non-obvious encodings, such as protocol-specific ASCII-Compatible Encoding (ACE) variants, are used, the user will inevitably, if only occasionally, see them rather than Klensin & Ko Expires April 23, 2012 [Page 11] Internet-Draft EAI Framework October 2011 "native" characters and will find that discomfiting or astonishing. Similarly, if different codings are used for mail transport and message bodies, the user is particularly likely to be surprised, if only as a consequence of the long-established "things leak" principle. The only practical way to avoid these sources of discomfort, in both the medium and the longer term, is to have the encodings used in transport be as similar to the encodings used in message headers and message bodies as possible. When email local parts are internationalized, they SHOULD be accompanied by arrangements for the message headers to be in the fully internationalized form. That form SHOULD use UTF-8 rather than ASCII as the base character set for the contents of header fields (protocol elements such as the header field names themselves are unchanged and remain entirely in ASCII). For transition purposes and compatibility with legacy systems, this can done by extending the traditional MIME encoding models for non-ASCII characters in headers [RFC2045] [RFC2231], but even these should be based on UTF-8, rather than other encodings, if at all possible [RFC6055]. However, the target is fully internationalized message headers, as discussed in [RFC5335bis-Hdrs] and not an extended and painful transition. 7.3. SMTP Service Extension for DSNs The existing Draft Standard Delivery status notifications (DSNs) specification [RFC3461] is limited to ASCII text in the machine readable portions of the protocol. "International Delivery and Disposition Notifications" [RFC5337bis-DSN] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the UTF8SMTPbis and the DSN extension, that server MUST implement internationalized DSNs including support for the ORCPT parameter specified in RFC 3461 [RFC3461]. 8. Downgrading before and after SMTP Transactions An important issue with these extensions is how to handle interactions between systems that support non-ASCII addresses and legacy systems that expect ASCII. There is, of course, no problem with ASCII-only systems sending to those that can handle internationalized forms because the ASCII forms are just a proper subset. But, when systems that support these extensions send mail, they MAY include non-ASCII addresses for senders, receivers, or both and might also provide non-ASCII header information other than addresses. If the extension is not supported by the first-hop system (SMTP server accessed by the Submission server acting as an SMTP client), message originating systems SHOULD be prepared to either Klensin & Ko Expires April 23, 2012 [Page 12] Internet-Draft EAI Framework October 2011 send conventional envelopes and message headers or to return the message to the originating user so the message may be manually downgraded to the traditional form, possibly using encoded words [RFC2047] in the message headers. Of course, such transformations imply that the originating user or system must have ASCII-only addresses available for all senders and recipients. Mechanisms by which such addresses may be found or identified are outside the scope of these specifications as are decisions about the design of originating systems such as whether any required transformations are made by the user, the originating MUA, or the Submission server. A somewhat more complex situation arises when the first-hop system supports these extensions but some subsequent server in the SMTP transmission chain does not. It is important to note that most cases of that situation with forward-pointing addresses will be the result of configuration errors: especially if it hosts non-ASCII addresses, a final delivery MTA that accepts these extensions SHOULD NOT be configured with lower-preference MX hosts that do not. When the only non-ASCII address being transmitted is backward-pointing (e.g., in an SMTP MAIL command), recipient configuration can not help in general. On the other hand, alternate, all-ASCII, addresses for senders are those most likely to be authoritatively known by the submission environment or the sender herself. Consequently, if an intermediate SMTP relay that requires these extensions then discovers that the next system in the chain does not support them, it will have little choice other than to reject or return the message. As discussed above, downgrading to an ASCII-only form may occur before or during the initial message submission. It might also occur after the delivery to the final delivery MTA in order to accommodate messages stores or IMAP or POP servers or clients that have different capabilities than the delivery MTA. These two cases are discussed in the subsections below. 8.1. Downgrading before or during Message Submission The IETF has traditionally avoided specifying the precise behavior of MUAs to provide maximum flexibility in the associated user interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide latitude to MUAs and Submission servers as to what might be supplied by the user as long as the result conforms with "on the wire" standards once it is injected into the public Internet. In that tradition, the discussion in the remainder of this section is provided as general guidance rather than normative requirements. Messages that require these extensions will sometimes be transferred to a system that does not support these extensions; it is likely that the most common cases will involve the combination of ASCII-only Klensin & Ko Expires April 23, 2012 [Page 13] Internet-Draft EAI Framework October 2011 forward-pointing addresses with a non-ASCII backward-pointing one. Until the extensions described here have been universally implemented in the Internet email environment, senders who prefer to use non- ASCII addresses (or raw UTF-8 characters in header fields) even when their intended recipients use and expect all-ASCII ones will need to be especially careful about the error conditions that can arise, especially if they are working in an environment in which non- delivery messages (or other indications from submission servers) are routinely dropped or ignored. Perhaps obviously, the most convenient time to find an ASCII address corresponding to an internationalized address is at the originating MUA or closely-associated systems. This can occur either before the message is sent or after the internationalized form of the message is rejected. It is also the most convenient time to convert a message from the internationalized form into conventional ASCII form or to generate a non-delivery message to the sender if either is necessary. At that point, the user has a full range of choices available, including changing backward-pointing addresses, contacting the intended recipient out of band for an alternate address, consulting appropriate directories, arranging for translation of both addresses and message content into a different language, and so on. While it is natural to think of message downgrading as optimally being a fully-automated process, we should not underestimate the capabilities of a user of at least moderate intelligence who wishes to communicate with another such user. In this context, one can easily imagine modifications to message submission servers (as described in RFC 4409 [RFC4409]) so that they would perform downgrading operations or perhaps even upgrading ones. Such operations would permit receiving messages with one or more of the internationalization extensions discussed here and adapting the outgoing message, as needed, to respond to the delivery or next-hop environment the submission server encounters. 8.2. Downgrading or Other Processing After Final SMTP Delivery When an email message is received by a final delivery MTA, it is usually stored in some form. Then it is retrieved either by software that reads the stored form directly or by client software via some email retrieval mechanisms such as POP or IMAP. The SMTP extension described in Section 7.1 provides protection only in transport. It does not prevent MUAs and email retrieval mechanisms that have not been upgraded to understand internationalized addresses and UTF-8 message headers from accessing stored internationalized emails. Klensin & Ko Expires April 23, 2012 [Page 14] Internet-Draft EAI Framework October 2011 Since the final delivery MTA (or, to be more specific, its corresponding mail storage agent) cannot safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY downgrade internationalized emails, specially identify messages that utilize these extensions, or both. If this is done, the final delivery MTA SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss to support access by UTF8SMTPbis-aware agents. 9. Downgrading in Transit The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321]) states that "due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address". This is not a new requirement; equivalent statements appeared in specifications in 2001 [RFC2821] and even in 1989 [RFC1123]. Adherence to this rule means that a downgrade mechanism that transforms the local-part of an email address cannot be utilized in transit. It can only be applied at the endpoints, specifically by the MUA or submission server or by the final delivery MTA. One of the reasons for this rule has to do with legacy email systems that embed mail routing information in the local-part of the address field. Transforming the email address destroys such routing information. There is no way a server other than the final delivery server can know, for example, whether the local-part of user%foo@example.com is a route ("user" is reached via "foo") or simply a local address. 10. User Interface and Configuration Issues Internationalization of addresses and message headers, especially in combination with variations on character coding that are inherent to Unicode, may make careful choices of addresses and careful configuration of servers and DNS records even more important than they are for traditional Internet email. It is likely that, as experience develops with the use of these protocols, it will be desirable to produce one or more additional documents that offer guidance for configuration and interfaces. A document that discusses issues with mail user agents (MUAs), especially with regard to downgrading, is expected to be developed in the EAI Working Group. The subsections below address some other issues. Klensin & Ko Expires April 23, 2012 [Page 15] Internet-Draft EAI Framework October 2011 10.1. Choices of Mailbox Names and Unicode Normalization It has long been the case that the email syntax permits choices about mailbox names that are unwise in practice if one actually intends the mailboxes to be accessible to a broad range of senders. The most- often-cited examples involve the use of case-sensitivity and tricky quoting of embedded characters in mailbox local parts. These deliberately-unusual constructions are permitted by the protocols and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity. In the absence of these extensions, SMTP clients and servers are constrained to using only those addresses permitted by RFC 5321. The local parts of those addresses MAY be made up of any ASCII characters except the control characters that 5321 prohibits, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321 because it requires a backspace character (a prohibited C0 control). Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of this character in ASCII mailbox names and it is even more problematic (for canonicalization and normalization reasons) in non-ASCII strings, backspace MUST NOT appear in UTF8SMTPbis mailbox names. For the particular case of mailbox names that contain non-ASCII characters in the local part, domain part, or both, special attention MUST be paid to Unicode normalization [Unicode-UAX15], in part because Unicode strings may be normalized by other processes independent of what a mail protocol specifies (this is exactly analogous to what may happen with quoting and dequoting in traditional addresses). Consequently, the following principles are offered as advice to those who are selecting names for mailboxes: o In general, it is wise to support addresses in Normalized form, using at least Normalization Form NFC. Except in circumstances in which NFKC would map characters together that the parties responsible for the destination mail server would prefer to be kept distinguishable, supporting the NFKC-conformant form would yield even more predictable behavior for the typical user. o It will usually be wise to support other forms of the same local- part string, either as aliases or by normalization of strings reaching the delivery server: the sender should not be depended Klensin & Ko Expires April 23, 2012 [Page 16] Internet-Draft EAI Framework October 2011 upon to send the strings in normalized form. o Stated differently and in more specific terms, the rules of the protocol for local-part strings essentially provide that: * Unnormalized strings are valid, but sufficiently bad practice that they may not work reliably on a global basis. Servers should not depend on clients to send normalized forms but should be aware that procedures on client machines outside the control of the MUA may cause normalized strings to be sent regardless of user intent. * C0 (and presumably C1) controls (see The Unicode Standard [Unicode]) are prohibited, the first in RFC 5321 and the second by an obvious extension from it [RFC5198]. * Other kinds of punctuation, spaces, etc., are risky practice. Perhaps they will work, and SMTP receiver code is required to handle them without severe errors (even if such strings are not accepted in addresses to be delivered on that server), but creating dependencies on them in mailbox names that are chosen is usually a bad practice and may lead to interoperability problems. 11. Additional Issues This section identifies issues that are not covered, or not covered comprehensively, as part of this set of specifications, but that will require ongoing review as part of deployment of email address and header internationalization. 11.1. Impact on URIs and IRIs The mailto: schema [RFC6068], and the discussion of it in the Internationalized Resource Identifier (IRI) specification [RFC3987] may need to be modified when this work is completed and standardized. 11.2. Use of Email Addresses as Identifiers There are a number of places in contemporary Internet usage in which email addresses are used as identifiers for individuals, including as identifiers to Web servers supporting some electronic commerce sites and in some X.509 certificates [RFC5280]. These documents do not address those uses, but it is reasonable to expect that some difficulties will be encountered when internationalized addresses are first used in those contexts, many of which cannot even handle the full range of addresses permitted today. Klensin & Ko Expires April 23, 2012 [Page 17] Internet-Draft EAI Framework October 2011 11.3. Encoded Words, Signed Messages, and Downgrading One particular characteristic of the email format is its persistency: MUAs are expected to handle messages that were originally sent decades ago and not just those delivered seconds ago. As such, MUAs and mail filtering software, such as that specified in Sieve [RFC5228], will need to continue to accept and decode header fields that use the "encoded word" mechanism [RFC2047] to accommodate non- ASCII characters in some header fields. While extensions to both POP3 [RFC1939] and IMAP [RFC3501] have been defined that include automatic upgrading of messages that carry non-ASCII information in encoded form -- including RFC 2047 decoding -- of messages by the POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are message structures and MIME content-types for which that cannot be done or where the change would have unacceptable side effects. For example, message parts that are cryptographically signed, using e.g., S/MIME [RFC5751] or Pretty Good Privacy (PGP) [RFC3156], cannot be upgraded from the RFC 2047 form to normal UTF-8 characters without breaking the signature. Similarly, message parts that are encrypted may contain, when decrypted, header fields that use the RFC 2047 encoding; such messages cannot be 'fully' upgraded without access to cryptographic keys. Similar issues may arise if messages are signed and then subsequently downgraded, e.g., as discussed in Section 8.1, and then an attempt is made to upgrade them to the original form and then verify the signatures. Even the very subtle changes that may result from algorithms to downgrade and then upgrade again may be sufficient to invalidate the signatures if they impact either the primary or MIME bodypart headers. When signatures are present, downgrading MUST be performed with extreme care if at all. 11.4. Other Uses of Local Parts Local parts are sometimes used to construct domain labels, e.g., the local part "user" in the address user@domain.example could be converted into a vanity host user.domain.example with its Web space at and the catchall addresses any.thing.goes@user.domain.example. Such schemes are obviously limited by, among other things, the SMTP rules for domain names, and will not work without further restrictions for other local parts such as the specified in [RFC5335bis-Hdrs]. Whether those limitations are relevant to these specifications is an open question. It may be simply another case of the considerable flexibility accorded to delivery MTAs in determining the mailbox names they will accept and Klensin & Ko Expires April 23, 2012 [Page 18] Internet-Draft EAI Framework October 2011 how they are interpreted. 11.5. Non-Standard Encapsulation Formats Some applications use formats similar to the application/mbox format defined in [RFC4155] instead of the message/digest form described in RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as single units. Insofar as such applications assume that all stored messages use the message/rfc822 format described in RFC 2046, Section 5.2.1 [RFC2046] with ASCII message headers, they are not ready for the extensions specified in this series of documents and special measures may be needed to properly detect and process them. 12. Key Changes From the Experimental Protocols and Framework The original framework for internationalized email addresses and headers was described in RFC 4952 and a subsequent set of experimental protocol documents. Those relationships are described in Section 3. The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading. Those mechanisms included the definition of syntax and functions to support passing alternate, all-ASCII, addresses with the non-ASCII ones as well as special headers to indicate the downgraded status of messages. Those features were eliminated after experimentation indicated that they were more complex and less necessary than had been assumed earlier. Those issues are described in more detail in Section 6 and Section 9. 13. IANA Considerations This overview description and framework document does not contemplate any IANA registrations or other actions. Some of the documents in the group have their own IANA considerations sections and requirements. 14. Security Considerations Any expansion of permitted characters and encoding forms in email addresses raises some risks. There have been discussions on so called "IDN-spoofing" or "IDN homograph attacks". These attacks allow an attacker (or "phisher") to spoof the domain or URLs of businesses. The same kind of attack is also possible on the local part of internationalized email addresses. It should be noted that the proposed fix involving forcing all displayed elements into normalized lower-case works for domain names in URLs, but not email local parts since those are case sensitive. Since email addresses are often transcribed from business cards and Klensin & Ko Expires April 23, 2012 [Page 19] Internet-Draft EAI Framework October 2011 notes on paper, they are subject to problems arising from confusable characters (see [RFC4690]). These problems are somewhat reduced if the domain associated with the mailbox is unambiguous and supports a relatively small number of mailboxes whose names follow local system conventions. They are increased with very large mail systems in which users can freely select their own addresses. The internationalization of email addresses and message headers must not leave the Internet less secure than it is without the required extensions. The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues. They do require a review of issues associated with confusable characters -- a topic that is being explored thoroughly elsewhere (see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other transformations. Normalization and other issues associated with transformations and standard forms are also part of the subject of work described elsewhere [RFC5198] [RFC5893] [RFC6055]. Some issues specifically related to internationalized addresses and message headers are discussed in more detail in the other documents in this set. However, in particular, caution should be taken that any "downgrading" mechanism, or use of downgraded addresses, does not inappropriately assume authenticated bindings between the internationalized and ASCII addresses. This potential problem can be mitigated somewhat by enforcing the expectation that most or all such transformations will be performed prior to final delivery by systems that are presumed to be under the administrative control of the sending user (as opposed to being performed in transit by entities that are not under the administrative control of the sending user). The new UTF-8 header and message formats might also raise, or aggravate, another known issue. If the model creates new forms of an 'invalid' or 'malformed' message, then a new email attack is created: in an effort to be robust, some or most agents will accept such message and interpret them as if they were well-formed. If a filter interprets such a message differently than the MUA used by the recipient, then it may be possible to create a message that appears acceptable under the filter's interpretation but that should be rejected under the interpretation given to it by that MUA. Such attacks already exist for existing messages and encoding layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid coding of particular image types. In addition, email addresses are used in many contexts other than sending mail, such as for identifiers under various circumstances (see Section 11.2). Each of those contexts will need to be Klensin & Ko Expires April 23, 2012 [Page 20] Internet-Draft EAI Framework October 2011 evaluated, in turn, to determine whether the use of non-ASCII forms is appropriate and what particular issues they raise. This work will clearly affect any systems or mechanisms that are dependent on digital signatures or similar integrity protection for email message headers (see also the discussion in Section 11.3). Many conventional uses of PGP and S/MIME are not affected since they are used to sign body parts but not message headers. On the other hand, the developing work on domain keys identified mail (DKIM) [RFC5863] will eventually need to consider this work and vice versa: while this specification does not address or solve the issues raised by DKIM and other signed header mechanisms, the issues will have to be coordinated and resolved eventually if the two sets of protocols are to co-exist. In addition, to the degree to which email addresses appear in PKI (Public Key Infrastructure) certificates [RFC5280], standards addressing such certificates will need to be upgraded to address these internationalized addresses. Those upgrades will need to address questions of spoofing by look-alikes of the addresses themselves. 15. Acknowledgments This document is an update to, and derived from, RFC 4952. This document would have been impossible without the work and contributions acknowledged in it. The present document benefited significantly from discussions in the EAI WG and elsewhere after RFC 4952 was published, especially discussions about the experimental versions of other documents in the internationalized email collection, and from RFC errata on RFC 4952 itself. Special thanks are due to Ernie Dainow for careful reviews and suggested text in this version and to several IESG members for a careful review and specific suggestions. 16. References 16.1. Normative References [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. Klensin & Ko Expires April 23, 2012 [Page 21] Internet-Draft EAI Framework October 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5335bis-Hdrs] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", September 2011, . [RFC5336bis-SMTP] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", August 2011, . [RFC5337bis-DSN] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", October 2011, < https://datatracker.ietf.org/doc/ draft-ietf-eai-rfc5337bis-dsn/>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011. 16.2. Informative References [POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", Work in Progress, July 2011, . Klensin & Ko Expires April 23, 2012 [Page 22] Internet-Draft EAI Framework October 2011 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Characte r Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Klensin & Ko Expires April 23, 2012 [Page 23] Internet-Draft EAI Framework October 2011 Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008. [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008. [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008. [RFC5337] Newman, C. and A. Melnikov, Klensin & Ko Expires April 23, 2012 [Page 24] Internet-Draft EAI Framework October 2011 "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008. [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009. [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010. [RFC5721bis-POP3] Gellens, R., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, July 2011, . [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010. [RFC5738bis-IMAP] Resnick, P., Newman, C., and S. Shen, "IMAP Support for UTF-8", Work in Progress, July 2011, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010. [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010. Klensin & Ko Expires April 23, 2012 [Page 25] Internet-Draft EAI Framework October 2011 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010. [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010. [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010. [RFC5983bis-MailingList] "Mailing Lists and Internationalized Email Addresses", Unwritten waiting for I-D, 2011. [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011. [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010. [Unicode] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by:, "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9)., . [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", March 2008, . Appendix A. Change Log [[RFC Editor: Please remove this section prior to publication.]] A.1. Changes between -00 and -01 o Because there has been no feedback on the mailing list, updated the various questions to refer to this version as well. Klensin & Ko Expires April 23, 2012 [Page 26] Internet-Draft EAI Framework October 2011 o Reflected RFC Editor erratum #1507 by correcting terminology for headers and header fields and distinguishing between "message headers" and different sorts of headers (e.g., the MIME ones). A.2. Changes between -01 and -02 Note that section numbers in the list that follows may refer to -01 and not -02. o Discussion of RFC 5825 ("downgraded display") has been removed per the earlier note and on-list discussion. Any needed discussion about reconstructed messages will need to appear in the IMAP and POP documents. However, the introductory material has been reworded to permit keeping 5504 and 5825 on the list there, without which the back chain would not be complete. For consistency with this change, 5504 and 5825 have been added to the "Obsoletes" list (as far as I know, an Informational spec can obsolete or update Experimental ones, so no downref problem here --JcK). o Reference to alternate addresses dropped from (former) Section 7.1. o Reference to RFC 5504 added to (former) Section 8 for completeness. o Ernie's draft comments added (with some minor edits) to replace the placeholder in (former) Section 9 ("Downgrading in Transit"). It is intended to capture at least an introduction the earlier discussions of algorithmic downgrading generally and ACE/Punycode transformations in particular. Anyone who is unhappy with it should say so and propose alternate text. RSN. o In the interest of clarity and consistency with the terminology in Section 4.1, all uses of "final delivery SMTP server" and "final delivery server" have been changed to "final delivery MTA". o Placeholder at the end of Section 2 has been removed and the text revised to promise less. The "Document Plan" (Section 5) has been revised accordingly. We need to discuss this at IETF 78 if not sooner. o Sections 5 and 6 have been collapsed into one -- there wasn't enough left in the former Section 5 to justify a separate section. o Former Section 11.1 has been dropped and the DSN document moved up into the "Document Plan" as suggested earlier. Klensin & Ko Expires April 23, 2012 [Page 27] Internet-Draft EAI Framework October 2011 o Section 12, "Experimental Targets", has been removed. o Updated references for the new version EAI documents and added placeholders for all of the known remaining drafts that will become part of the core EAI series but that have not been written. o Inserted an additional clarification about the relationship of these extensions to non-ASCII messages. o Changed some normative/informative reference classifications based on review of the new text. o Removed references to the pre-EAI documents that were cited for historical context in 4952. o Got rid of a remaining pointer to address downgrading in the discussion of an updated MAILTO URI. o Minor additional editorial cleanups and tuning. A.3. Changes between -02 and -03 o Inserted paragraph clarifying the status of the UTF8SMTPbis keyword as a result of discussion prior to and during IETF 79. o Adjusted some references including adding an explicit citation of RFC 821. o Removed the discussion of the experimental work from an inline aside to a separate section, Section 6. o Rewrote the discussion of configuration errors in MX setups to make it clear that they are an issue with forward-pointing addresses only and improved the discussion of backward-pointing addresses. o Removed some now-obsolete placeholder notes and resolved the remaining one to a dangling reference. A.4. Changes between -03 and -04 o Several minor editorial changes. o Added a discussion of the relationship to the base email, MIME, and IDNA specifications. Klensin & Ko Expires April 23, 2012 [Page 28] Internet-Draft EAI Framework October 2011 A.5. Changes between -04 and -05 o Several more minor editorial changes. A.6. Changes between -05 and -06 o Corrections to more precisely reflect RFC 2119 language requirements and closely-related issues.. A.7. Changes between -06 and -07 o Added a new section (now Section 12) to explicitly discuss the changes from the previous version. o Removed the discussion of LMTP from Section 11; it is more appropriately placed in the SMTP Extension document (5336bis). A.8. Changes between -07 and -08 (after IETF Last Call) o Modified Section 7.2 to make the last paragraph less tentative and more clear. o Modified Section 8.1 to add an introductory paragraph that clarifies what the IETF does and does not specify about email protocols. A.9. Changes between -08 and -09 This version incorporates responses to a last set of public comments and changes made in response to IESG discussion and comments as part of the balloting process. o Many small editorial changes made at IESG request. o Several other small editorial corrections, removal of uncited reference to LMTP, added a few citations for clarity. A.10. Changes between -09 and -10 This version contains additional small editorial changes resulting from IESG comments and review of -09 changes. Some more significant clarifications appear in Section 10.1 A.11. Changes between -10 and -11 While -10 was approved for publication by the IESG (after IETF Last Call) in September 2010, the document then went into a reference hold in the RFC Editor queue. Issued identified during and after Last Klensin & Ko Expires April 23, 2012 [Page 29] Internet-Draft EAI Framework October 2011 Call for the other three core EAI documents (5335bis, 5336bis, and 5337bis) required reopening this document and making some minor additional changes. o Reworded the descriptions of the POP, IMAP, and mailing list documents and moved them to Informative. Notes in the XML of earier versions of this draft indicate that they were listed as Normative merely as a temporary convenience. Examination and reclassification of them apparently slipped through the cracks. o Reclassified the document to standards track to eliminate normative reference problems from other EAI documents. o References, other than the two Unicode ones, have been updated for the convenience of reviewers and the RFC Editor. A note has been inserted into the XML requesting that the RFC Editor update the Unicode references to be current at the time of publication. o Explicitly notes status of documents obsoleted by this one and moves them to Historic. Authors' Addresses John C KLENSIN 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com YangWoo KO ICU 119 Munjiro Yuseong-gu, Daejeon 305-732 Republic of Korea EMail: yw@mrko.pe.kr Klensin & Ko Expires April 23, 2012 [Page 30] --==========C6C543B10401EB114DF5==========-- From duerst@it.aoyama.ac.jp Mon Oct 24 23:45:53 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949E11E80D9 for ; Mon, 24 Oct 2011 23:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.37 X-Spam-Level: X-Spam-Status: No, score=-99.37 tagged_above=-999 required=5 tests=[AWL=0.420, 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 ZK74IawnZ-pl for ; Mon, 24 Oct 2011 23:45:52 -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 65F4211E8086 for ; Mon, 24 Oct 2011 23:45:51 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9P6jofw009818 for ; Tue, 25 Oct 2011 15:45:50 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1894_1776_fa1bfa20_fed4_11e0_8338_001d096c5782; Tue, 25 Oct 2011 15:45:50 +0900 Received: from [IPv6:::1] ([133.2.210.1]:43447) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 25 Oct 2011 15:45:54 +0900 Message-ID: <4EA65B1D.7090305@it.aoyama.ac.jp> Date: Tue, 25 Oct 2011 15:45:49 +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: <6176C39A9E52DA71C816F24B@PST.JCK.COM> In-Reply-To: <6176C39A9E52DA71C816F24B@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Joseph Yee , ima@ietf.org Subject: Re: [EAI] State of the core 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: Tue, 25 Oct 2011 06:45:53 -0000 Hello John, others, For the record, I have read your explanations in detail and agree with all the proposals. Regards, Martin. On 2011/10/25 4:22, John C Klensin wrote: > Hi. > > We have some problems/ issues with the documents. The co-chairs > and editor team have developed a strategy that Pete is ok with > if the WG is. The strategy is outlined below; this is your > chance to object if you have serious problems with it. However, > most of the issues are procedural; as far as I can tell, only > one of them has any effect on the protocols at all and it is > very narrow (and one that neither the WG nor the IESG caught). > > Joseph is out of pocket due to the ICANN meeting so I'm taking > the liberty of asking the questions. If anyone has strong > opinions, we will wait for him to evaluate the consensus. I > will, however, take even a couple of days of silence as an > indication that we should go ahead as outlined below. > > Note that the recently-posted version of 5335bis and a version > of 5336bis that is now in the pipeline are consistent with this > strategy. > > As many of you know, the IESG has raised many issues with the > three core documents (5335bis, 5336bis, and 5337bis). While > many of these have been comments, rather than (blocking) DISCUSS > positions, we need to respond to the comments (like any other > Last Call comments) in some way. The vast majority of the > comments fall into three categories: > > (1) We failed to properly identify downrefs to > informational documents. One of the problem target > documents (for both 5335bis and 5336bis) is 4952bis > (framework). The others vary from one of the new > documents to the next but all of them are only > questionably normative or required. They can be moved > to informative or standards track documents substituted > with, at most, a little rewording. The problem was due > in part to a communications disconnect between Pete and > the co-chairs: the shepherd reports identified the > issues, Pete didn't mention it in the Last Call, and > Joseph and I didn't catch that immediately. This would > be trivial except that unless we do "something else", > the documents will need to be put through IETF Last Call > again. See below for "something else". > > (2) We failed to say explicitly that the new documents > should cause the experimental ones to be reclassified as > Historic. Reclassifying them is probably reasonable > but, given the nature of the experimental specs and the > care we have taken to make sure that implementations of > them cannot interfere with the final versions, it really > doesn't make a lot of difference, at least IMO. > > (3) Several IESG members have asked for more detail in > the documents about changes from the experimental > documents. Some want a little more, some want a lot > more. Several of us are, to put it mildly, not > impressed with those requests: it is not that the > experimental specs are actually widely-deployed > standards-track specs with implementers and users to > whom we have to explain differences. In addition, a > great deal of the material that has been asked for is > already in 4952bis. That is exactly where we decided to > put it, but the IESG approved 4952bis around 13 months > ago and have collectively forgotten it. > > In the process of trying to sort things out, I went back and > looked carefully at 4952bis and discovered that it violates a > number of rules that the IESG is now taking very seriously. In > particular, it contains a good deal of normative requirements > language. We gave the IESG its choice as to whether to > process it as Informational or Standards Track. They selected > Informational, which made sense at the time. In the light of > the new rules (or newly-enforced rules), that was a mistake -- > it should have been treated as standards track. In addition, > as an accident of how the document was published, it contains > normative references to documents that have not yet been > approved yet (the POP/ IMAP/ POP-IMAP-downgrade specs) and > documents that haven't been written yet (various of the things > we've been referring to as "advice" documents). The RFC Editor > didn't catch those and list them in the queue, probably because > of the way the references were constructed, but I'm quite sure > that, if they start editing, they will find the references and > everything will go into "Missref hold". That, from my point of > view, would be a disaster. > > So I/we propose the following wrt the IESG comments. This note > is to see if anyone in WG has strong objections. > > -- We fix 5335bis, 5336bis, and 5337bis as required/ suggested > by the IESG comments, including fixing things so that only > references to each other and 4952bis are normative and > explicitly moving their obsolete predecessors to Historic. We > don't do an in-depth change summary in any of them but instead > point the reader to 4952bis. That does not require a new Last > Call on any of them if 4952bis is processed as Standards Track. > > -- We reopen 4952bis to eliminate the normative dependences on > documents that aren't finished (or written), clean up the change > descriptions a bit, and update references before someone whines > about those. We then ask Pete to issue a Last Call on the > changes only and to target it for Proposed Standard, eliminating > the problem with the normative language and with references from > the other docs. > > The 4952bis revision is ready; I will post it relatively soon > unless people object. Even if we don't ask the IESG to process > it for Proposed Standard, most of the changes are needed to > permit 5335bis-5337bis and it to be published without waiting > for everyone else, so, unless people are willing to wait > (probably a year or more at the WG's current speed) for > publication, the WG presumably should review it in any event. > Pete and I believe that it will then have to be put out for a > two-week Last Call on the changes whether we try to move it to > Standard Track or not -- it would be hard to justify these > changes as mere editorial tuning of the kind that we might > otherwise apply at AUTH48. > > The non-IESG issue is that there is a table of trace field > "WITH" keywords in 5336bis. It clearly needs correction so its > descriptions point to UTF8SMTPbis, rather than UTF8SMTP. But > the keywords are the same as those used in 5336. Alexey > believes we discussed the issue and concluded that we should > retain the keywords unaltered. I don't remember but assume that > he is correct. One way or the other, this is your last chance > to object: if you are convinced the WITH keywords should be > changed, speak up. If you are convinced that they absolutely > should not be changed, explain why. If there is controversy, > Joseph will have to sort it out (and those who care will have to > take responsibility for the delay). Otherwise, the keywords in > the document (which have been around for a _long_ time without > objections) will be retained. > > Questions or comments welcome, but, if you have any, make them > soon, please. And, please, in the interest of WG progress, > please do not use this as an excuse to revisit old issues: > Joseph and I hope that the Taipei meeting can concentrate on the > POP, IMAP, and related downgrade specs and on a discussion about > how (or if) we want to proceed on the other documents. If we > get bogged down now, we will need to put these documents on the > agenda, probably resulting in considerable further delays. > > best, > john > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Oct 25 02:08:13 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6F21F8BAC for ; Tue, 25 Oct 2011 02:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.792 X-Spam-Level: X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 RVSyafhEptF5 for ; Tue, 25 Oct 2011 02:08:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0AEC21F8BA7 for ; Tue, 25 Oct 2011 02:08:12 -0700 (PDT) Received: by wyh22 with SMTP id 22so322379wyh.31 for ; Tue, 25 Oct 2011 02:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Naq2TCAkT7hVPnWnQwpDVA8bGSE9KZmMLNE9AmIbuB4=; b=iGodR/XnQKs58GQI/GUWpU6ODtDC0Nkn53CL6JvzMkMF8EeQ+3TcpEZXkFNqQA1jsy LVWWg4Bk0q6yB8WaxVbNvcctpAeC45Jym2ebkNFyqeutoeyDregv1i2BB+sxJUSj0JCM 9qS8+Czmt0LdfWl1k/0EcFO0U/mhAsUMi4bh4= Received: by 10.216.221.157 with SMTP id r29mr4716095wep.66.1319533565099; Tue, 25 Oct 2011 02:06:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 25 Oct 2011 02:05:24 -0700 (PDT) In-Reply-To: <6176C39A9E52DA71C816F24B@PST.JCK.COM> References: <6176C39A9E52DA71C816F24B@PST.JCK.COM> From: Frank Ellermann Date: Tue, 25 Oct 2011 11:05:24 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Joseph Yee , ima@ietf.org Subject: Re: [EAI] State of the core 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: Tue, 25 Oct 2011 09:08:13 -0000 On 24 October 2011 21:22, John C Klensin wrote: >=A0(2) We failed to say explicitly that the new > documents=A0should cause the experimental ones to > be reclassified as=A0Historic. The IESG ION^D^D^Dhow-to is very new; no one could foresee that "obsoletes" is not more good enough. If a PS obsoletes an experiment I'd consider the experiment as implicitly finished. If that SHOULD be now done explicitly it's also fine, but in that case I'd also like to see this SHOULD in an RFC, not only in a "how-to". As it happens I stumbled over the link in a "daily dose" just this morning, but missed that it's related to the EAI Last Call. > given the nature of the experimental specs and the >=A0care we have taken to make sure that implementations > of=A0them cannot interfere with the final versions, it > really=A0doesn't make a lot of difference, at least > IMO. If "historic" offers you the opportunity to recycle the term UTF8SMTP instead of UTF8SMTPBIS I'd like it. > I'm quite sure that, if they start editing, they > will find the references and everything will go into > "Missref hold". =A0That, from my point of view, would > be a disaster. Maybe you could replace the "missrefs" by vague words in AUTH84, e.g., instead of "" how about "a successor of "? > We reopen 4952bis to eliminate the normative > dependences on documents that aren't finished (or > written), clean up the change descriptions a bit, > and update references before someone whines about > those. That sounds slightly more convoluted than my idea... What's wrong with the (approved) status of 4952bis, why do you think it needs to be on standards track? Just in case, I'm not against a status change, but I don't see the purpose yet, it sounds like more work than necessary. (((If I could pick a -bis where you spend your time it would start with 5..., not 4...))) > And, please, in the interest of WG progress, please > do not use this as an excuse to revisit old issues: Apropos, I liked the "duck or grouse" in the shepherd summary. And (ab)used it as an excuse for posting no additional comment about said "old issues" in the LC. -Frank From klensin@jck.com Tue Oct 25 07:50:16 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BD721F8BAC for ; Tue, 25 Oct 2011 07:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 T4aVonxm6j0B for ; Tue, 25 Oct 2011 07:50:15 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2177621F8BAA for ; Tue, 25 Oct 2011 07:50:14 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RIiKT-0004J9-Gp; Tue, 25 Oct 2011 10:50:13 -0400 Date: Tue, 25 Oct 2011 10:50:12 -0400 From: John C Klensin To: Frank Ellermann Message-ID: <53452CAC44C1AE6BA956BEAF@PST.JCK.COM> In-Reply-To: References: <6176C39A9E52DA71C816F24B@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: Joseph Yee , ima@ietf.org Subject: Re: [EAI] State of the core 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: Tue, 25 Oct 2011 14:50:16 -0000 --On Tuesday, October 25, 2011 11:05 +0200 Frank Ellermann wrote: >... >> =C2=A0(2) We failed to say explicitly that the new >> documents=C2=A0should cause the experimental ones to >> be reclassified as=C2=A0Historic. >=20 > The IESG ION^D^D^Dhow-to is very new; no one could > foresee that "obsoletes" is not more good enough. > If a PS obsoletes an experiment I'd consider the > experiment as implicitly finished. If that SHOULD > be now done explicitly it's also fine, but in that > case I'd also like to see this SHOULD in an RFC, > not only in a "how-to". As it happens I stumbled > over the link in a "daily dose" just this morning, > but missed that it's related to the EAI Last Call. Tell it to the IESG, preferably after these documents are all in the RFC Editor queue. Put differently, we could fight this, but I'd much prefer to get these documents signed off and published so the WG (and implementations) can move forward. >> given the nature of the experimental specs and the >> =C2=A0care we have taken to make sure that implementations >> of=C2=A0them cannot interfere with the final versions, it >> really=C2=A0doesn't make a lot of difference, at least >> IMO. >=20 > If "historic" offers you the opportunity to recycle > the term UTF8SMTP instead of UTF8SMTPBIS I'd like it. It does not. The reason for changing the keyword was to eliminate the risk of experimental implementations, or anticipatory implementations, causing interoperability problems. If we change the extension keyword, we more or less guarantee that anything advertising it (and implemented in good faith) will be using it to describe the final protocol. Without the keyword change, the IESG would be entirely justified in insisting that we do an interoperability and risk analysis on the difference between the experimental and standards-track protocols. If I were on the IESG, I certainly would insist. We don't want to go there, if only because it would be a huge waste of time and energy. >> I'm quite sure that, if they start editing, they >> will find the references and everything will go into >> "Missref hold". =C2=A0That, from my point of view, would >> be a disaster. >=20 > Maybe you could replace the "missrefs" by vague words > in AUTH84, e.g., instead of "" how about > "a successor of "? Race condition. The RFC Editor won't generally start editing until missing references are cleared and certainly won't announce AUTH48 until that is done. So one cannot get to AUTH48 to make the change you suggest for AUTH48, even if the ADs and RFC Editor would consider that a legitimate AUTH48 change. (yes, the idea did occur to me, but...) >> We reopen 4952bis to eliminate the normative >> dependences on documents that aren't finished (or >> written), clean up the change descriptions a bit, >> and update references before someone whines about >> those. >=20 > That sounds slightly more convoluted than my idea... But it works. See above. > What's wrong with the (approved) status of 4952bis, > why do you think it needs to be on standards track? I thought this was clear from my earlier note, but let me try again. If it is Informational, all normative references in it to I-Ds have to be eliminated. Because of the race condition, that isn't possible without reissuing the draft. While a variation on your suggestion would work for the "Advice" documents (and -11 does that), the POP/IMAP ones pretty much need to be discussed, even if only with a "work in progress" designation (still requiring that they be non-normative). I don't see any way to reissue the draft, even with only changes to muddy over the references, without going through another Last Call. If we go through another Last Call, some IESG member is certain to spot the normative language and want to debate it, wasting more time. _And_ we would still have to put 5335bis-5337bis back through another Last Call to get approval for referencing the Informational 4952bis normatively (no way to avoid that without transferring a lot of text to 5335bis and 5336bis -- text that doesn't belong in them). If we take advantage of having to go through another Last Call on 4952bis anyway to fix a couple of extra things and then move it toward standards track, we eliminate the need to do another Last Call on 5335bis-5337bis, lower the risk of "another pass means we have to find something else" problems, and generally move things forward. > Just in case, I'm not against a status change, but I > don't see the purpose yet, it sounds like more work > than necessary. (((If I could pick a -bis where you > spend your time it would start with 5..., not 4...))) Understood. But, for better or worse, they went through WG LC recently with substantially no comment. And the IESG is ready to let them move forward, so I think we move them along. =20 >> And, please, in the interest of WG progress, please >> do not use this as an excuse to revisit old issues: >=20 > Apropos, I liked the "duck or grouse" in the shepherd > summary. And (ab)used it as an excuse for posting no > additional comment about said "old issues" in the LC. thanks. john From internet-drafts@ietf.org Tue Oct 25 08:42:34 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081C021F8C18; Tue, 25 Oct 2011 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 eGbI4cjYXsPS; Tue, 25 Oct 2011 08:42:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734C621F8C15; Tue, 25 Oct 2011 08:42:33 -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: 3.61 Message-ID: <20111025154233.23663.58446.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 08:42:33 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-frmwrk-4952bis-11.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:42:34 -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 : Overview and Framework for Internationalized Email Author(s) : John C Klensin YangWoo Ko Filename : draft-ietf-eai-frmwrk-4952bis-11.txt Pages : 30 Date : 2011-10-25 Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952; it reflects additional issues identified since that document was published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-frmwrk-4952bis-11.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-frmwrk-4952bis-11.txt From sm@resistor.net Tue Oct 25 10:13:20 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9730221F8B07 for ; Tue, 25 Oct 2011 10:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 Twn0KC7hCri9 for ; Tue, 25 Oct 2011 10:13:19 -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 8E8B921F8AD8 for ; Tue, 25 Oct 2011 10:13:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p9PHD73I011047; Tue, 25 Oct 2011 10:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1319562793; bh=Ok68vZ2349/rgsniITZ4OsGyaDAuOAeDRFPqW1ysjkg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=x1ni9OnXGURtFK12/6vSP+RUS+LIhD7XJzPW8gKwNptRX+U9tBiUMC4nKmvWJH61X wka2iB4sUjZWvSZCYj4xVSfMcXVTZ3bNAfPQFIxJVHgsulOzKO0jEIAfUAeGDwUgVP rZxirTwvef9o6JC12nA55v0k+wQOMA8cim96ztdo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1319562793; bh=Ok68vZ2349/rgsniITZ4OsGyaDAuOAeDRFPqW1ysjkg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=zWBYXOPfVKXM4tjdit54oTNeYfUcyi3iZ002AFIY7rDVY/8I+xRDHTWzBbvPhgGqE ELptwiVkS1yHEvErLB1/qkR6P6JPpzbOQNCPpMWre5MSfdJJBcgbc+OTZW5e/ouIkN 5y6vRcYcjcIhMlBBTuYGDgmNieFvb0/tb8BFuXiY= Message-Id: <6.2.5.6.2.20111025094046.09d59540@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 25 Oct 2011 10:11:43 -0700 To: John C Klensin From: SM In-Reply-To: <6176C39A9E52DA71C816F24B@PST.JCK.COM> References: <6176C39A9E52DA71C816F24B@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] State of the core 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: Tue, 25 Oct 2011 17:13:20 -0000 Hi John, At 12:22 24-10-2011, John C Klensin wrote: >As many of you know, the IESG has raised many issues with the >three core documents (5335bis, 5336bis, and 5337bis). While >many of these have been comments, rather than (blocking) DISCUSS >positions, we need to respond to the comments (like any other >Last Call comments) in some way. The vast majority of the >comments fall into three categories: > > (1) We failed to properly identify downrefs to > informational documents. One of the problem target > documents (for both 5335bis and 5336bis) is 4952bis > (framework). The others vary from one of the new > documents to the next but all of them are only > questionably normative or required. They can be moved > to informative or standards track documents substituted > with, at most, a little rewording. The problem was due > in part to a communications disconnect between Pete and > the co-chairs: the shepherd reports identified the > issues, Pete didn't mention it in the Last Call, and > Joseph and I didn't catch that immediately. This would > be trivial except that unless we do "something else", > the documents will need to be put through IETF Last Call > again. See below for "something else". I would consider a second Last Call if the IESG considers the downref to be a serious issue instead of having a tedious workaround. > (2) We failed to say explicitly that the new documents > should cause the experimental ones to be reclassified as > Historic. Reclassifying them is probably reasonable > but, given the nature of the experimental specs and the > care we have taken to make sure that implementations of > them cannot interfere with the final versions, it really > doesn't make a lot of difference, at least IMO. The short answer is that it is not worth arguing about this one. The documents will still need a second Last-Call. If you do not want to change the documents, you can defer this as the Last Call for such a reclassification can be done separately. >-- We fix 5335bis, 5336bis, and 5337bis as required/ suggested >by the IESG comments, including fixing things so that only >references to each other and 4952bis are normative and >explicitly moving their obsolete predecessors to Historic. We >don't do an in-depth change summary in any of them but instead >point the reader to 4952bis. That does not require a new Last >Call on any of them if 4952bis is processed as Standards Track. See above. I am Ok with any path the WG Chairs pick. >The non-IESG issue is that there is a table of trace field >"WITH" keywords in 5336bis. It clearly needs correction so its >descriptions point to UTF8SMTPbis, rather than UTF8SMTP. But >the keywords are the same as those used in 5336. Alexey >believes we discussed the issue and concluded that we should >retain the keywords unaltered. I don't remember but assume that >he is correct. One way or the other, this is your last chance >to object: if you are convinced the WITH keywords should be >changed, speak up. If you are convinced that they absolutely >should not be changed, explain why. If there is controversy, >Joseph will have to sort it out (and those who care will have to >take responsibility for the delay). Otherwise, the keywords in >the document (which have been around for a _long_ time without >objections) will be retained. Alexey performed an AD review in November 2010 and asked about the "WITH" keyword. As mentioned above, the correction is to the trace field table. Regards, -sm From internet-drafts@ietf.org Thu Oct 27 09:40:53 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C273821F8BAC; Thu, 27 Oct 2011 09:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 c5iG6hWF2mhP; Thu, 27 Oct 2011 09:40:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D4F21F8B92; Thu, 27 Oct 2011 09:40:53 -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: 3.62 Message-ID: <20111027164053.23075.86367.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2011 09:40:53 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-15.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:40:54 -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 : SMTP Extension for Internationalized Email Author(s) : Jiankang Yao Wei Mao Filename : draft-ietf-eai-rfc5336bis-15.txt Pages : 21 Date : 2011-10-27 This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. This specification replaces RFC 5336. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-15.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-rfc5336bis-15.txt From internet-drafts@ietf.org Sat Oct 29 10:49:46 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C889921F85A7; Sat, 29 Oct 2011 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 DAnLWOiwKUsu; Sat, 29 Oct 2011 10:49:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4065021F847D; Sat, 29 Oct 2011 10:49:46 -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: 3.62 Message-ID: <20111029174946.8435.85085.idtracker@ietfa.amsl.com> Date: Sat, 29 Oct 2011 10:49:46 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-frmwrk-4952bis-12.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: Sat, 29 Oct 2011 17:49:47 -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 : Overview and Framework for Internationalized Email Author(s) : John C Klensin YangWoo Ko Filename : draft-ietf-eai-frmwrk-4952bis-12.txt Pages : 30 Date : 2011-10-29 Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-frmwrk-4952bis-12.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-frmwrk-4952bis-12.txt From internet-drafts@ietf.org Sun Oct 30 21:15:59 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A54E1F0C6B; Sun, 30 Oct 2011 21:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 ZwEUY7672ap0; Sun, 30 Oct 2011 21:15:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37DC1F0C3E; Sun, 30 Oct 2011 21:15:58 -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: 3.62 Message-ID: <20111031041558.19878.68765.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 21:15:58 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5337bis-dsn-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 04:15:59 -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 : Internationalized Delivery Status and Disposition Notifi= cations Author(s) : Tony Hansen Chris Newman Alexey Melnikov Filename : draft-ietf-eai-rfc5337bis-dsn-05.txt Pages : 20 Date : 2011-10-30 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798. It replaces the experimental RFC 5337. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5337bis-dsn-05.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-rfc5337bis-dsn-05.txt From iesg-secretary@ietf.org Mon Oct 31 07:08:39 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60E421F8CE2; Mon, 31 Oct 2011 07:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 2e4G7HAApYLi; Mon, 31 Oct 2011 07:08:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ECB21F8C9E; Mon, 31 Oct 2011 07:08:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031140838.3060.2826.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 07:08:38 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (Overview and Framework for Internationalized Email) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:08:39 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Overview and Framework for Internationalized Email' as a Proposed Standard Please note that an earlier revision of this document was already approved by the IESG for publication as Informational. This document has references to and from draft-ietf-eai-5335bis and draft-ietf-eai-5336bis. As a result of IESG comments during IESG Evaluation of those two documents, the WG felt that they needed to make changes to this document and change its status to Standards Track from Informational. It is now being re-considered for Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Mon Oct 31 08:21:58 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A63B1F0C4E; Mon, 31 Oct 2011 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 r7QNvAtvrt44; Mon, 31 Oct 2011 08:21:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6911F0C44; Mon, 31 Oct 2011 08:21:55 -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: 3.62 Message-ID: <20111031152155.5832.21783.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 08:21:55 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-popimap-downgrade-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:21:58 -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 : Post-delivery Message Downgrading for Internationalized = Email Messages Author(s) : Kazunori Fujiwara Filename : draft-ietf-eai-popimap-downgrade-03.txt Pages : 19 Date : 2011-10-31 The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in mail header fields. POP and IMAP servers support internationalized email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot send Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be traditional message format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-03.txt