From jyee@afilias.info Mon Jul 4 03:01: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 1F7E421F862C for ; Mon, 4 Jul 2011 03:01:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRUi-dVInNHK for ; Mon, 4 Jul 2011 03:01:49 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDC421F8623 for ; Mon, 4 Jul 2011 03:01:49 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QdfyO-0003x8-8p for ima@ietf.org; Mon, 04 Jul 2011 10:01:48 +0000 Received: from mail-gx0-f178.google.com ([209.85.161.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QdfyO-0007Mo-8K for ima@ietf.org; Mon, 04 Jul 2011 10:01:48 +0000 Received: by gxk8 with SMTP id 8so1980128gxk.9 for ; Mon, 04 Jul 2011 03:01:48 -0700 (PDT) Received: by 10.236.154.138 with SMTP id h10mr7347770yhk.41.1309773707939; Mon, 04 Jul 2011 03:01:47 -0700 (PDT) Received: from [192.168.0.106] (76-10-183-60.dsl.teksavvy.com [76.10.183.60]) by mx.google.com with ESMTPS id c63sm3967781yhe.32.2011.07.04.03.01.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 03:01:47 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2011 06:01:44 -0400 To: "ima@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Jul 2011 10:01:50 -0000 All, Following discussion, the WG agreed that message under SMTP without the = EAI parameter at MAIL FROM must conform to RFC5321 regardless the = server's capability. Trace field values must conform to RFC5321, = whether it's an initial submission or relay. For message under SMTP with EAI parameter at MAIL FROM, an EAI-capable = client SHOULD send messages what require EAI functionality in UTF-8 form = to servers that do support EAI functionality. Trace field values (the = domain name) in the "from" clause of "Received:" should use U-label. The exact wording will be determined by editors of RFC5336bis, with help = from everyone in the WG. The principle text derived during discussion = can be served as guideline: An EAI-capable client MUST either be able to send a 5321-conformant message to a non-EAI-capable server or MUST reject or return the message. Only the second is plausible in the absence of downgrading facilities if the message requires EAI capabilities. =09 An EAI-capable client SHOULD send messages what require EAI functionality in UTF-8 form to servers that do support EAI functionality. Last Call announcement will follow very soon once the revision = published. =20 [ Note: I leave out whether MTA can drop or promote the EAI parameter. This is = an implementation issue (as mentioned by John Levine and Ned Freed) and = not scope of RFC5336bis. Personally I believed that it would be good to = say something like "It's up to the MTA but iff the message is all ASCII" = but don't go into details . An advise (informational) doc, or BCP, or = AS doc would be the best place to discuss such in details. Open to WG's = suggestion. ] If you believed that there are any issues not covered that could change = the consensus result, please post as soon as possible. I will post a = revised result at July 5, 23:59 US Eastern if necessary. Thanks. Regards, Joseph Yee, co-chair of EAI= From healthyao@gmail.com Mon Jul 4 05:47: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 AD9621F0C65 for ; Mon, 4 Jul 2011 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5tb70qyEPAz for ; Mon, 4 Jul 2011 05:47:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC26E1F0C3B for ; Mon, 4 Jul 2011 05:47:09 -0700 (PDT) Received: by pzk5 with SMTP id 5so859165pzk.31 for ; Mon, 04 Jul 2011 05:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gsIf82pIcOt+6PWX7ijpSJbEqpvd84Nvx3A/6nvzaSI=; b=SjtP8GpwG06aUd7hAmndc2Dt+gUaoC1Mk6Hbi6dkv8fSb4ppIkdC50H+qZtN5dMKVW mJCN+DZm6I3lRdJHQPKqtp/8444ycjbSfN3+rOWv/eYjbXEv0zwoFhPBXQyw9xDPDPgE 0zWA/h+M7vs6GN55hfx03holoW3EdD6rkjT6w= MIME-Version: 1.0 Received: by 10.68.28.132 with SMTP id b4mr7530354pbh.433.1309783629313; Mon, 04 Jul 2011 05:47:09 -0700 (PDT) Received: by 10.68.71.135 with HTTP; Mon, 4 Jul 2011 05:47:09 -0700 (PDT) Date: Mon, 4 Jul 2011 20:47:09 +0800 Message-ID: From: health yao To: jyee@afilias.info, ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Jul 2011 12:47:10 -0000 Thanks for your result. Based on your result, I propose the followin text to 3.7.3 of rfc5336bis: ---------------------------------------------- 3.7.3. Trace Information The trace information , and their related rules have been defined in in section 4.4 of RFC 5321 [RFC5321]. This document has updated and to support non-ASCII characters. So Return-path-line may include the 'Reverse-path' clause where internationalized domain name with the U-label form may be used. Time-stamp-line may include the 'Stamp' clause where the internationalized domain name with the U-label form may be used. If the message including the trace field values are sent by the EAI-aware SMTP client or relay server without the EAI parameter at MAIL command, they MUST conform to RFC5321 regardless the server's capability. If the message including trace field values are sent by the EAI-aware SMTP client or relay server with the EAI parameter at MAIL command, trace field values in the "from" clause of "Received:" SHOULD use the U-label form for the internationalized domain name. An EAI-aware SMTP client MUST either be able to send a RFC 5321-conformant message to a non-EAI-aware server or MUST reject or return the message. Only the second is plausible in the absence of downgrading facilities if the message requires EAI capabilities. The protocol value of the 'WITH' clause when this extension is used is one of the UTF8SMTPbis values specified in the "IANA Considerations" section of this document. ---------------------------------------------------- Jiankang Yao ----- Original Message ----- From: "Joseph Yee" To: Sent: Monday, July 04, 2011 6:01 PM Subject: [EAI] Consensus Result - trace fields and RFC5336bis > All, > > Following discussion, the WG agreed that message under SMTP without the E= AI parameter at MAIL FROM must conform to RFC5321 regardless the server's c= apability. Trace field values must conform to RFC5321, whether it's an ini= tial submission or relay. > > For message under SMTP with EAI parameter at MAIL FROM, an EAI-capable cl= ient SHOULD send messages what require EAI functionality in UTF-8 form to s= ervers that do support EAI functionality. Trace field values (the domain n= ame) in the "from" clause of "Received:" should use U-label. > > The exact wording will be determined by editors of RFC5336bis, with help = from everyone in the WG. The principle text derived during discussion can = be served as guideline: > > An EAI-capable client MUST either be able to send a > 5321-conformant message to a non-EAI-capable server or > MUST reject or return the message. Only the second is > plausible in the absence of downgrading facilities if > the message requires EAI capabilities. > > An EAI-capable client SHOULD send messages what require > EAI functionality in UTF-8 form to servers that do > support EAI functionality. > > Last Call announcement will follow very soon once the revision published. > > [ > Note: > > I leave out whether MTA can drop or promote the EAI parameter. This is a= n implementation issue (as mentioned by John Levine and Ned Freed) and not = scope of RFC5336bis. Personally I believed that it would be good to say so= mething like "It's up to the MTA but iff the message is all ASCII" but don= 't go into details . An advise (informational) doc, or BCP, or AS doc woul= d be the best place to discuss such in details. Open to WG's suggestion. > > ] > > If you believed that there are any issues not covered that could change t= he consensus result, please post as soon as possible. I will post a revise= d result at July 5, 23:59 US Eastern if necessary. Thanks. > > Regards, > Joseph Yee, co-chair of EAI > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From healthyao@gmail.com Mon Jul 4 05:58: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 BE89A21F8670 for ; Mon, 4 Jul 2011 05:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIR6ud1KTb3X for ; Mon, 4 Jul 2011 05:58:00 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A37A21F8668 for ; Mon, 4 Jul 2011 05:58:00 -0700 (PDT) Received: by pzk5 with SMTP id 5so869891pzk.31 for ; Mon, 04 Jul 2011 05:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IRh/gvkjlxEgKw2MvsN6S4Na0NWnVWswEm9oYvyjaQk=; b=nQFNd2gCmUsvfXLXizuLHGsdcMNVEaC05ikLY+08IcCOMXwxLsX/DGoqync6paxb7V eQGVBKMsckm+JeV9Ht8uwJgJ3hynGnngVcSrLzw54upCMCBHYJ/nsuGalFinYZTqJB9V i1QIdeLuk7kAXvRUfYiKUvpHCI3gIRkz0h+p4= MIME-Version: 1.0 Received: by 10.68.60.136 with SMTP id h8mr7790554pbr.366.1309784279985; Mon, 04 Jul 2011 05:57:59 -0700 (PDT) Received: by 10.68.71.135 with HTTP; Mon, 4 Jul 2011 05:57:59 -0700 (PDT) Date: Mon, 4 Jul 2011 20:57:59 +0800 Message-ID: From: Jiankang Yao To: Joseph Yee , "ima@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Jul 2011 12:58:00 -0000 ----- Original Message ----- From: "Joseph Yee" To: Sent: Monday, July 04, 2011 6:01 PM Subject: [EAI] Consensus Result - trace fields and RFC5336bis > All, > > Following discussion, the WG agreed that message under SMTP without the E= AI parameter at MAIL FROM must conform to RFC5321 regardless the server's c= apability. Trace field values must conform to RFC5321, whether it's an ini= tial submission or relay. > > For message under SMTP with EAI parameter at MAIL FROM, an EAI-capable cl= ient SHOULD send messages what require EAI functionality in UTF-8 form to s= ervers that do support EAI functionality. Trace field values (the domain n= ame) in the "from" clause of "Received:" should use U-label. > > In this case, only the "from" clause of "Received:" use u-label? other clauses such as "for" still use A-label? Jiankang Yao From klensin@jck.com Mon Jul 4 06:24:47 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 76FCB21F85FA for ; Mon, 4 Jul 2011 06:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOuJsRNGIJeU for ; Mon, 4 Jul 2011 06:24:47 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id BE9AE21F85AF for ; Mon, 4 Jul 2011 06:24:46 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qdj8m-0009AI-D1; Mon, 04 Jul 2011 09:24:44 -0400 X-Vipre-Scanned: 078738A7002628078739F4-TDI Date: Mon, 04 Jul 2011 09:24:43 -0400 From: John C Klensin To: Jiankang Yao , Joseph Yee , "ima@ietf.org WG" Message-ID: <21E7FA2B278DEF851AFB6441@[192.168.1.128]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Jul 2011 13:24:47 -0000 --On Monday, July 04, 2011 20:57 +0800 Jiankang Yao wrote: >... >> For message under SMTP with EAI parameter at MAIL FROM, an >> EAI-capable client SHOULD send messages what require EAI >> functionality in UTF-8 form to servers that do support EAI >> functionality. Trace field values (the domain name) in the >> "from" clause of "Received:" should use U-label. > In this case, only the "from" clause of "Received:" use > u-label? > > other clauses such as "for" still use A-label? Personal opinion (but I think consistent with the WG discussion): once one starts putting any UTF-8-encoded material (U-labels or text) into the headers, there is little reason to try to say "use it here, but not there". If the receiver can handle that material, then it can handle it; if it cannot, it is in big trouble and whether that trouble is about one subfield or about several makes no difference. So, if U-labels are used in "Received ...from" clauses, there is not reason at all to require that A-labels be used in "for" clauses and many reasons to prefer U-labels. Note in addition that "for" with A-labels would be useful only in what we've called the ASCII@IDN case. For the non-ASCII@IDN case, UTF-8 is going to appear in the local-part so there is no advantage at all to avoiding it in the domain-part. FWIW, I believe that, in practical terms, the ASCII@IDN case will be fairly rare. If an IDN-style domain name is used for the destination mail server, people will want, and we will see, EAI-style addresses in the local-part. An exception might arise for a given person trying to maintain both EAI and ASCII local-part addresses but, if I were writing that particular bit of guidance today, I'd recommend that user configured alternate addresses be in domains consisting entirely of LDH labels. The many discussions in the WG in the last several weeks illustrate why: if one has a 5321-conformant message, one is better off making sure that it stays that way rather than having A-labels converted to U-labels by an enthusiastic intermediary and then having the message bounced somewhere downstream. But, again, that is just my opinion. john From johnl@iecc.com Mon Jul 4 10:41: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 DD21C1F0C98 for ; Mon, 4 Jul 2011 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.946 X-Spam-Level: X-Spam-Status: No, score=-109.946 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRKaO9dom4zC for ; Mon, 4 Jul 2011 10:41:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B67611F0C8E for ; Mon, 4 Jul 2011 10:41:56 -0700 (PDT) Received: (qmail 22533 invoked from network); 4 Jul 2011 17:41:55 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 4 Jul 2011 17:41:55 -0000 Received: (qmail 43907 invoked from network); 4 Jul 2011 17:41:55 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 4 Jul 2011 17:41:55 -0000 Date: 4 Jul 2011 17:41:33 -0000 Message-ID: <20110704174133.27822.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <21E7FA2B278DEF851AFB6441@[192.168.1.128]> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 04 Jul 2011 17:42:00 -0000 >Personal opinion (but I think consistent with the WG >discussion): once one starts putting any UTF-8-encoded material >(U-labels or text) into the headers, there is little reason to >try to say "use it here, but not there". If the receiver can >handle that material, then it can handle it; if it cannot, it is >in big trouble and whether that trouble is about one subfield or >about several makes no difference. Agreed. I'd offer language but it appears that other people have it under control. R's, John From healthyao@gmail.com Mon Jul 4 20:32: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 4554111E80A1 for ; Mon, 4 Jul 2011 20:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhxsaFwER76Z for ; Mon, 4 Jul 2011 20:32:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E83111E8096 for ; Mon, 4 Jul 2011 20:32:30 -0700 (PDT) Received: by iwn39 with SMTP id 39so6029416iwn.31 for ; Mon, 04 Jul 2011 20:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=d3p1OGefHQfz8Tg99p2e50ikJKwgIKMAFxCUrHyni5k=; b=cmYyDOO2m88HKQzOj3A0vz5SaQrc3GwIFpUGZxIcU8symAFCIM4p42rSshayBUyI+1 i1Ac6EwfYTHxZh8XCeEKFYHVQ/57A+jlqfFQs9LmisBXGL08ILaK2Y8MYU3CMv82wIv2 /rjfaIcT8oO2Y0vYLJVfUdPXAqXu4s3hAno6U= Received: by 10.42.8.212 with SMTP id j20mr2061822icj.287.1309836750054; Mon, 04 Jul 2011 20:32:30 -0700 (PDT) Received: from LENOVO47E041CF ([218.241.111.35]) by mx.google.com with ESMTPS id j7sm7134145icq.2.2011.07.04.20.32.27 (version=SSLv3 cipher=OTHER); Mon, 04 Jul 2011 20:32:29 -0700 (PDT) Message-ID: <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> From: "Jiankang Yao" To: References: <509783640.06768@cnnic.cn> Date: Tue, 5 Jul 2011 11:32:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: [EAI] proposed text Re: Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Jul 2011 03:32:31 -0000 DQoNCg0KcmVtb3Zpbmcgc29tZSBwcmluY2lwbGUgdGV4dCB0aGF0IGhhcyBiZWVuIHJlcGVhdGVk IGluIG90aGVyIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwNCnRoZSBuZXcgcHJvcG9zZWQgdGV4dCBm b3Igc2VjdGlvbiAzLjcuMyAgaXMgdGhlIGZvbGxvd2luZzoNCg0KDQoNCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KVGhlIHRyYWNlIGluZm9ybWF0aW9uIDxSZXR1 cm4tcGF0aC1saW5lPiwgPFRpbWUtc3RhbXAtbGluZT4gYW5kIHRoZWlyDQogICByZWxhdGVkIHJ1 bGVzIGhhdmUgYmVlbiBkZWZpbmVkIGluIGluIHNlY3Rpb24gNC40IG9mIFJGQyA1MzIxDQogICBb UkZDNTMyMV0uICBUaGlzIGRvY3VtZW50IGhhcyB1cGRhdGVkIDxNYWlsYm94PiBhbmQgPERvbWFp bj4gdG8NCiAgIHN1cHBvcnQgbm9uLUFTQ0lJIGNoYXJhY3RlcnMuICBTbyBSZXR1cm4tcGF0aC1s aW5lIG1heSBpbmNsdWRlIHRoZQ0KICAgJ1JldmVyc2UtcGF0aCcgY2xhdXNlIHdoZXJlIGludGVy bmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lIHdpdGggdGhlDQogICBVLWxhYmVsIGZvcm0gbWF5IGJl IHVzZWQuICBUaW1lLXN0YW1wLWxpbmUgbWF5IGluY2x1ZGUgdGhlICdTdGFtcCcNCiAgIGNsYXVz ZSB3aGVyZSB0aGUgaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIG5hbWUgd2l0aCB0aGUgVS1sYWJl bCBmb3JtDQogICBtYXkgYmUgdXNlZC4NCg0KSWYgdGhlIG1lc3NhZ2VzIGluY2x1ZGluZyB0aGUg dHJhY2UgZmllbGQgdmFsdWVzIGFyZSBzZW50IGJ5IHRoZSBFQUktDQogICBhd2FyZSBTTVRQIGNs aWVudCBvciByZWxheSBzZXJ2ZXIgd2l0aG91dCB0aGUgRUFJIHBhcmFtZXRlciBhdCBNQUlMDQog ICBjb21tYW5kcywgIHRyYWNlIGZpZWxkIHZhbHVlcyAgbXVzdCBjb25mb3JtIHRvIFJGQyA1MzIx IHJlZ2FyZGxlc3MgdGhlIFNNVFAgc2VydmVyJ3MNCiAgIGNhcGFiaWxpdHkuICANCiAgIElmIHRo ZSBtZXNzYWdlcyBpbmNsdWRpbmcgdHJhY2UgZmllbGQgdmFsdWVzIGFyZSBzZW50IGJ5IHRoZSBF QUktDQogICBhd2FyZSBTTVRQIGNsaWVudCBvciByZWxheSBzZXJ2ZXIgd2l0aCB0aGUgRUFJIHBh cmFtZXRlciBhdCBNQUlMDQogICBjb21tYW5kcywgdHJhY2UgZmllbGQgdmFsdWVzIFNIT1VMRCB1 c2UgdGhlIFUtbGFiZWwgZm9ybSBmb3IgdGhlDQogICBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4g bmFtZS4gIA0KDQogICBUaGUgcHJvdG9jb2wgdmFsdWUgb2YgdGhlICdXSVRIJyBjbGF1c2Ugd2hl biB0aGlzIGV4dGVuc2lvbiBpcyB1c2VkDQogICBpcyBvbmUgb2YgdGhlIFVURjhTTVRQYmlzIHZh bHVlcyBzcGVjaWZpZWQgaW4gdGhlICJJQU5BDQogICBDb25zaWRlcmF0aW9ucyIgc2VjdGlvbiBv ZiB0aGlzIGRvY3VtZW50Lg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCg0KDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJoZWFs dGggeWFvIiA8aGVhbHRoeWFvQGdtYWlsLmNvbT4NClRvOiA8anllZUBhZmlsaWFzLmluZm8+OyA8 aW1hQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBKdWx5IDA0LCAyMDExIDg6NDcgUE0NClN1Ympl Y3Q6IFJlOiBbRUFJXSBDb25zZW5zdXMgUmVzdWx0IC0gdHJhY2UgZmllbGRzIGFuZCBSRkM1MzM2 YmlzDQoNCg0KPiBUaGFua3MgZm9yIHlvdXIgcmVzdWx0Lg0KPiANCj4gQmFzZWQgb24geW91ciBy ZXN1bHQsDQo+IEkgcHJvcG9zZSB0aGUgZm9sbG93aW4gdGV4dCB0byAzLjcuMyBvZiByZmM1MzM2 YmlzOg0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gMy43LjMuICBUcmFjZSBJbmZvcm1hdGlvbg0KPiANCj4gDQo+ICAgVGhlIHRyYWNl IGluZm9ybWF0aW9uIDxSZXR1cm4tcGF0aC1saW5lPiwgPFRpbWUtc3RhbXAtbGluZT4gYW5kIHRo ZWlyDQo+ICAgcmVsYXRlZCBydWxlcyBoYXZlIGJlZW4gZGVmaW5lZCBpbiBpbiBzZWN0aW9uIDQu NCBvZiBSRkMgNTMyMQ0KPiAgIFtSRkM1MzIxXS4gIFRoaXMgZG9jdW1lbnQgaGFzIHVwZGF0ZWQg PE1haWxib3g+IGFuZCA8RG9tYWluPiB0bw0KPiAgIHN1cHBvcnQgbm9uLUFTQ0lJIGNoYXJhY3Rl cnMuICBTbyBSZXR1cm4tcGF0aC1saW5lIG1heSBpbmNsdWRlIHRoZQ0KPiAgICdSZXZlcnNlLXBh dGgnIGNsYXVzZSB3aGVyZSBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFtZSB3aXRoIHRoZQ0K PiAgIFUtbGFiZWwgZm9ybSBtYXkgYmUgdXNlZC4gIFRpbWUtc3RhbXAtbGluZSBtYXkgaW5jbHVk ZSB0aGUgJ1N0YW1wJw0KPiAgIGNsYXVzZSB3aGVyZSB0aGUgaW50ZXJuYXRpb25hbGl6ZWQgZG9t YWluIG5hbWUgd2l0aCB0aGUgVS1sYWJlbCBmb3JtDQo+ICAgbWF5IGJlIHVzZWQuDQo+IA0KPiAg SWYgdGhlIG1lc3NhZ2UgaW5jbHVkaW5nIHRoZSB0cmFjZSBmaWVsZCB2YWx1ZXMgYXJlIHNlbnQg YnkgdGhlDQo+IEVBSS1hd2FyZSBTTVRQIGNsaWVudCBvciByZWxheSBzZXJ2ZXIgd2l0aG91dCB0 aGUgRUFJIHBhcmFtZXRlciBhdA0KPiBNQUlMIGNvbW1hbmQsIHRoZXkgTVVTVCBjb25mb3JtIHRv IFJGQzUzMjEgcmVnYXJkbGVzcyB0aGUgc2VydmVyJ3MNCj4gY2FwYWJpbGl0eS4NCj4gDQo+IElm IHRoZSBtZXNzYWdlIGluY2x1ZGluZyB0cmFjZSBmaWVsZCB2YWx1ZXMgYXJlIHNlbnQgYnkgdGhl ICBFQUktYXdhcmUNCj4gU01UUCBjbGllbnQgb3IgcmVsYXkgc2VydmVyIHdpdGggdGhlIEVBSSBw YXJhbWV0ZXIgYXQgTUFJTCBjb21tYW5kLA0KPiB0cmFjZSBmaWVsZCB2YWx1ZXMgaW4gdGhlICJm cm9tIiBjbGF1c2Ugb2YgIlJlY2VpdmVkOiIgU0hPVUxEIHVzZSB0aGUNCj4gVS1sYWJlbCBmb3Jt IGZvciB0aGUgaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIG5hbWUuDQo+IA0KPiBBbiBFQUktYXdh cmUgU01UUCBjbGllbnQgTVVTVCBlaXRoZXIgYmUgYWJsZSB0byBzZW5kIGENCj4gUkZDIDUzMjEt Y29uZm9ybWFudCBtZXNzYWdlIHRvIGEgbm9uLUVBSS1hd2FyZSBzZXJ2ZXIgb3INCj4gTVVTVCBy ZWplY3Qgb3IgcmV0dXJuIHRoZSBtZXNzYWdlLiAgT25seSB0aGUgc2Vjb25kIGlzDQo+IHBsYXVz aWJsZSBpbiB0aGUgYWJzZW5jZSBvZiBkb3duZ3JhZGluZyBmYWNpbGl0aWVzIGlmDQo+IHRoZSBt ZXNzYWdlIHJlcXVpcmVzIEVBSSBjYXBhYmlsaXRpZXMuDQo+IA0KPiBUaGUgcHJvdG9jb2wgdmFs dWUgb2YgdGhlICdXSVRIJyBjbGF1c2UNCj4gICB3aGVuIHRoaXMgZXh0ZW5zaW9uIGlzIHVzZWQg aXMgb25lIG9mIHRoZSBVVEY4U01UUGJpcyB2YWx1ZXMNCj4gICBzcGVjaWZpZWQgaW4gdGhlICJJ QU5BIENvbnNpZGVyYXRpb25zIiBzZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAN Cj4gSmlhbmthbmcgWWFvDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZy b206ICJKb3NlcGggWWVlIiA8anllZUBhZmlsaWFzLmluZm8+DQo+IFRvOiA8aW1hQGlldGYub3Jn Pg0KPiBTZW50OiBNb25kYXksIEp1bHkgMDQsIDIwMTEgNjowMSBQTQ0KPiBTdWJqZWN0OiBbRUFJ XSBDb25zZW5zdXMgUmVzdWx0IC0gdHJhY2UgZmllbGRzIGFuZCBSRkM1MzM2YmlzDQo+IA0KPiAN Cj4+IEFsbCwNCj4+DQo+PiBGb2xsb3dpbmcgZGlzY3Vzc2lvbiwgdGhlIFdHIGFncmVlZCB0aGF0 IG1lc3NhZ2UgdW5kZXIgU01UUCB3aXRob3V0IHRoZSBFQUkgcGFyYW1ldGVyIGF0IE1BSUwgRlJP TSBtdXN0IGNvbmZvcm0gdG8gUkZDNTMyMSByZWdhcmRsZXNzIHRoZSBzZXJ2ZXIncyBjYXBhYmls aXR5LiAgVHJhY2UgZmllbGQgdmFsdWVzIG11c3QgY29uZm9ybSB0byBSRkM1MzIxLCB3aGV0aGVy IGl0J3MgYW4gaW5pdGlhbCBzdWJtaXNzaW9uIG9yIHJlbGF5Lg0KPj4NCj4+IEZvciBtZXNzYWdl IHVuZGVyIFNNVFAgd2l0aCBFQUkgcGFyYW1ldGVyIGF0IE1BSUwgRlJPTSwgYW4gRUFJLWNhcGFi bGUgY2xpZW50IFNIT1VMRCBzZW5kIG1lc3NhZ2VzIHdoYXQgcmVxdWlyZSBFQUkgZnVuY3Rpb25h bGl0eSBpbiBVVEYtOCBmb3JtIHRvIHNlcnZlcnMgdGhhdCBkbyBzdXBwb3J0IEVBSSBmdW5jdGlv bmFsaXR5LiAgVHJhY2UgZmllbGQgdmFsdWVzICh0aGUgZG9tYWluIG5hbWUpIGluIHRoZSAiZnJv bSIgY2xhdXNlIG9mICJSZWNlaXZlZDoiIHNob3VsZCB1c2UgVS1sYWJlbC4NCj4+DQo+PiBUaGUg ZXhhY3Qgd29yZGluZyB3aWxsIGJlIGRldGVybWluZWQgYnkgZWRpdG9ycyBvZiBSRkM1MzM2Ymlz LCB3aXRoIGhlbHAgZnJvbSBldmVyeW9uZSBpbiB0aGUgV0cuICBUaGUgcHJpbmNpcGxlIHRleHQg ZGVyaXZlZCBkdXJpbmcgZGlzY3Vzc2lvbiBjYW4gYmUgc2VydmVkIGFzIGd1aWRlbGluZToNCj4+ DQo+PiBBbiBFQUktY2FwYWJsZSBjbGllbnQgTVVTVCBlaXRoZXIgYmUgYWJsZSB0byBzZW5kIGEN Cj4+IDUzMjEtY29uZm9ybWFudCBtZXNzYWdlIHRvIGEgbm9uLUVBSS1jYXBhYmxlIHNlcnZlciBv cg0KPj4gTVVTVCByZWplY3Qgb3IgcmV0dXJuIHRoZSBtZXNzYWdlLiAgT25seSB0aGUgc2Vjb25k IGlzDQo+PiBwbGF1c2libGUgaW4gdGhlIGFic2VuY2Ugb2YgZG93bmdyYWRpbmcgZmFjaWxpdGll cyBpZg0KPj4gdGhlIG1lc3NhZ2UgcmVxdWlyZXMgRUFJIGNhcGFiaWxpdGllcy4NCj4+DQo+PiBB biBFQUktY2FwYWJsZSBjbGllbnQgU0hPVUxEIHNlbmQgbWVzc2FnZXMgd2hhdCByZXF1aXJlDQo+ PiBFQUkgZnVuY3Rpb25hbGl0eSBpbiBVVEYtOCBmb3JtIHRvIHNlcnZlcnMgdGhhdCBkbw0KPj4g c3VwcG9ydCBFQUkgZnVuY3Rpb25hbGl0eS4NCj4+DQo+PiBMYXN0IENhbGwgYW5ub3VuY2VtZW50 IHdpbGwgZm9sbG93IHZlcnkgc29vbiBvbmNlIHRoZSByZXZpc2lvbiBwdWJsaXNoZWQuDQo+Pg0K Pj4gWw0KPj4gTm90ZToNCj4+DQo+PiBJIGxlYXZlIG91dCB3aGV0aGVyIE1UQSBjYW4gZHJvcCBv ciBwcm9tb3RlIHRoZSBFQUkgcGFyYW1ldGVyLiAgVGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBp c3N1ZSAoYXMgbWVudGlvbmVkIGJ5IEpvaG4gTGV2aW5lIGFuZCBOZWQgRnJlZWQpIGFuZCBub3Qg c2NvcGUgb2YgUkZDNTMzNmJpcy4gIFBlcnNvbmFsbHkgSSBiZWxpZXZlZCB0aGF0IGl0IHdvdWxk IGJlIGdvb2QgdG8gc2F5IHNvbWV0aGluZyBsaWtlICJJdCdzIHVwIHRvIHRoZSBNVEEgYnV0IGlm ZiB0aGUgbWVzc2FnZSBpcyBhbGwgQVNDSUkiICBidXQgZG9uJ3QgZ28gaW50byBkZXRhaWxzIC4g IEFuIGFkdmlzZSAoaW5mb3JtYXRpb25hbCkgZG9jLCBvciBCQ1AsIG9yIEFTIGRvYyB3b3VsZCBi ZSB0aGUgYmVzdCBwbGFjZSB0byBkaXNjdXNzIHN1Y2ggaW4gZGV0YWlscy4gIE9wZW4gdG8gV0cn cyBzdWdnZXN0aW9uLg0KPj4NCj4+IF0NCj4+DQo+PiBJZiB5b3UgYmVsaWV2ZWQgdGhhdCB0aGVy ZSBhcmUgYW55IGlzc3VlcyBub3QgY292ZXJlZCB0aGF0IGNvdWxkIGNoYW5nZSB0aGUgY29uc2Vu c3VzIHJlc3VsdCwgcGxlYXNlIHBvc3QgYXMgc29vbiBhcyBwb3NzaWJsZS4gIEkgd2lsbCBwb3N0 IGEgcmV2aXNlZCByZXN1bHQgYXQgSnVseSA1LCAyMzo1OSBVUyBFYXN0ZXJuIGlmIG5lY2Vzc2Fy eS4gIFRoYW5rcy4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gSm9zZXBoIFllZSwgY28tY2hhaXIgb2Yg RUFJDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gSU1BIG1haWxpbmcgbGlzdA0KPj4gSU1BQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= From dhc2@dcrocker.net Tue Jul 5 08:39: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 BCDB721F8682 for ; Tue, 5 Jul 2011 08:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjuxUqMs9+Mg for ; Tue, 5 Jul 2011 08:39:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2EA21F867F for ; Tue, 5 Jul 2011 08:39:19 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p65FdDx2028121 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2011 08:39:18 -0700 Message-ID: <4E13301E.4040300@dcrocker.net> Date: Tue, 05 Jul 2011 08:39:10 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ima@ietf.org, YAO Jiankang References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> In-Reply-To: <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 05 Jul 2011 08:39:18 -0700 (PDT) Subject: Re: [EAI] proposed text Re: Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:39:20 -0000 Jiankang, On 7/4/2011 8:32 PM, Jiankang Yao wrote: > If the messages including the trace field values are sent by the EAI- > aware SMTP client or relay server without the EAI parameter at MAIL > commands, trace field values must conform to RFC 5321 regardless the SMTP server's > capability. I just noticed that the term "EAI" is not defined in the document; it is used quite a bit. Whatever term is used, it needs to be defined. For simplicity, I suggest that the term XXX-aware have the XXX be the same as the actual parameter name. Currently, that is: UTF8SMTPbis (to be replaced when the working group chooses the final name of the parameter.) Much more significantly: In Section 3.2, there is extended text that covers the case of an EAI-aware SMTP client attempting to transfer a UTF-8 message to a non EAI-aware server. That text ends with: > This document applies only when an EAI-aware SMTP client is trying to > send an internationalized message to an EAI-aware SMTP server. The text that you are have just circulated runs contrary to this statement of the document's limits. I also believe that there is no other place in the document that specifies interactions with non-EAI-aware servers. If the above sentence is removed from your new text, then the text will read well and will stay within the defined limits of the document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From klensin@jck.com Tue Jul 5 10:17: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 C2652228024 for ; Tue, 5 Jul 2011 10:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAf0EJdaOjJT for ; Tue, 5 Jul 2011 10:17:12 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1352C228022 for ; Tue, 5 Jul 2011 10:16:57 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qe9F1-0006e2-V7; Tue, 05 Jul 2011 13:16:56 -0400 Date: Tue, 05 Jul 2011 13:16:55 -0400 From: John C Klensin To: Jiankang Yao Message-ID: <52667A700E32776FEFF37767@PST.JCK.COM> In-Reply-To: <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] proposed text Re: Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Jul 2011 17:17:13 -0000 Hi. Several small editorial suggestions... (personal opinions only, not as co-chair) --On Tuesday, July 05, 2011 11:32 +0800 Jiankang Yao wrote: >... > **************************************** > > The trace information , > and their related rules have been defined in in section 4.4 s/have been defined in in section/were defined in section/ > of RFC 5321 [RFC5321]. This document has updated s/has updated/updates/ > and to support non-ASCII characters. So > Return-path-line may include the 'Reverse-path' clause > where internationalized domain name with the U-label form > may be used. s/So...used/When this extension is used, the 'Reverse-path' clause of the Return-path-line may include an internationalized domain name that uses the U-label form./ or something more like that. The next sentence might use a parallel organization. > Time-stamp-line may include the 'Stamp' > clause where the internationalized domain name with the > U-label form may be used. > If the messages including the trace field values are sent by > the EAI- aware SMTP client or relay server without the EAI Do you mean "messages that include trace fields"? If so, maybe you don't care because the issue is just "messages" (see below). s/sent by the EAI-aware/sent by an/ Comment: An EAI-aware server that receives a message doesn't have any way to know whether a client that sends it a message without the UTF8SMTPbis parameter (I agree with Dave about that usage) is EAI-aware or not. Fortunately, it also doesn't care: the only things with which it should be interested are what it receives and what it is supposed to do with it. > parameter at MAIL commands, trace field values must > conform to RFC 5321 regardless the SMTP server's s/regardless/regardless of/ > capability. > If the messages including trace field values are sent by > the EAI- aware SMTP client or relay server with the EAI > parameter at MAIL commands, trace field values SHOULD use > the U-label form for the internationalized domain name. Same comment as above. Here, if the UTF8SMTPbis parameter is sent, the information that the sender is EAI-aware is just useless noise -- it has to be to send the parameter (or there are far more serious problems that you don't need to discuss). >... john From klensin@jck.com Tue Jul 5 10:27: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 8814B1F0C38 for ; Tue, 5 Jul 2011 10:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SERoWm4oYSQc for ; Tue, 5 Jul 2011 10:27:18 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 4436C1F0C36 for ; Tue, 5 Jul 2011 10:27:18 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qe9Om-0006iz-FQ; Tue, 05 Jul 2011 13:27:00 -0400 Date: Tue, 05 Jul 2011 13:26:59 -0400 From: John C Klensin To: dcrocker@bbiw.net, ima@ietf.org, YAO Jiankang Message-ID: In-Reply-To: <4E13301E.4040300@dcrocker.net> References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <4E13301E.4040300@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] proposed text Re: Consensus Result - trace fields and RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 05 Jul 2011 17:27:19 -0000 --On Tuesday, July 05, 2011 08:39 -0700 Dave CROCKER wrote: > Jiankang, > > On 7/4/2011 8:32 PM, Jiankang Yao wrote: >> If the messages including the trace field values are sent by >> the EAI- aware SMTP client or relay server without the EAI >> parameter at MAIL commands, trace field values must >> conform to RFC 5321 regardless the SMTP server's >> capability. > I just noticed that the term "EAI" is not defined in the > document; it is used quite a bit. Whatever term is used, it > needs to be defined. For simplicity, I suggest that the term > XXX-aware have the XXX be the same as the actual parameter > name. Currently, that is: UTF8SMTPbis (to be replaced when > the working group chooses the final name of the parameter.) This works for me and is consistent with usage elsewhere. Thanks for catching it. > Much more significantly: > > In Section 3.2, there is extended text that covers the > case of an EAI-aware SMTP client attempting to transfer a > UTF-8 message to a non EAI-aware server. That text ends with: > >> This document applies only when an EAI-aware SMTP client is >> trying to send an internationalized message to an EAI-aware >> SMTP server. > > The text that you are have just circulated runs contrary > to this statement of the document's limits. I also believe > that there is no other place in the document that specifies > interactions with non-EAI-aware servers. > > If the above sentence is removed from your new text, then > the text will read well and will stay within the defined > limits of the document. Agreed. john From healthyao@gmail.com Tue Jul 5 22:47: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 A8A6B21F852F for ; Tue, 5 Jul 2011 22:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd-oAAeXvfX3 for ; Tue, 5 Jul 2011 22:47:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2E321F852C for ; Tue, 5 Jul 2011 22:47:18 -0700 (PDT) Received: by iye7 with SMTP id 7so7155206iye.31 for ; Tue, 05 Jul 2011 22:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=frKkWxBYtCKzh9Cf7e3CVfXE/PXcc3DZz7sMbSK47r8=; b=BICSJZc3U69BmjA7hizWi6n3rBAEkLSLzWUCE/o9TdcFTm/i/taTAQp95ZyZenv9rQ VZoNk/M9k+v080sQ9TRfjklloSwrDIDDZV4Lu78UzHTGoAGA88StRbtd1CUEh8STSHJ0 cP6w2UEiivO1RaIORQAFWv/986P1rfBKTGP7w= Received: by 10.42.177.4 with SMTP id bg4mr8451329icb.164.1309931237519; Tue, 05 Jul 2011 22:47:17 -0700 (PDT) Received: from LENOVO47E041CF ([218.241.103.12]) by mx.google.com with ESMTPS id j1sm4664600ibg.21.2011.07.05.22.47.14 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 22:47:16 -0700 (PDT) Message-ID: From: "Jiankang Yao" To: "Dave CROCKER" , References: <509783640.06768@cnnic.cn><36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <509880557.08490@cnnic.cn> Date: Wed, 6 Jul 2011 13:47:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Jul 2011 05:47:18 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRo YzJAZGNyb2NrZXIubmV0Pg0KVG86IDxpbWFAaWV0Zi5vcmc+OyAiWUFPIEppYW5rYW5nIiA8aGVh bHRoeWFvQGhvdG1haWwuY29tPg0KU2VudDogVHVlc2RheSwgSnVseSAwNSwgMjAxMSAxMTozOSBQ TQ0KU3ViamVjdDogUmU6IFtFQUldIHByb3Bvc2VkIHRleHQgUmU6IENvbnNlbnN1cyBSZXN1bHQg LSB0cmFjZSBmaWVsZHNhbmQgUkZDNTMzNmJpcw0KDQoNCj4gSmlhbmthbmcsDQo+IA0KPiBPbiA3 LzQvMjAxMSA4OjMyIFBNLCBKaWFua2FuZyBZYW8gd3JvdGU6DQo+PiBJZiB0aGUgbWVzc2FnZXMg aW5jbHVkaW5nIHRoZSB0cmFjZSBmaWVsZCB2YWx1ZXMgYXJlIHNlbnQgYnkgdGhlIEVBSS0NCj4+ ICAgICBhd2FyZSBTTVRQIGNsaWVudCBvciByZWxheSBzZXJ2ZXIgd2l0aG91dCB0aGUgRUFJIHBh cmFtZXRlciBhdCBNQUlMDQo+PiAgICAgY29tbWFuZHMsICB0cmFjZSBmaWVsZCB2YWx1ZXMgIG11 c3QgY29uZm9ybSB0byBSRkMgNTMyMSByZWdhcmRsZXNzIHRoZSBTTVRQIHNlcnZlcidzDQo+PiAg ICAgY2FwYWJpbGl0eS4NCj4gDQo+IA0KPiBJIGp1c3Qgbm90aWNlZCB0aGF0IHRoZSB0ZXJtICJF QUkiIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBkb2N1bWVudDsgaXQgaXMgdXNlZCANCj4gcXVpdGUg YSBiaXQuICBXaGF0ZXZlciB0ZXJtIGlzIHVzZWQsIGl0IG5lZWRzIHRvIGJlIGRlZmluZWQuIA0K Pg0KDQp0aGVyZSBhcmUgZG96ZW5zIG9mICJFQUkiIGluIHRoZSBkb2N1bWVudHMuDQoNCiBJIHBy b3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uOg0KDQoi VGhlIHRlcm0gIkVBSSIgcmVmZXJzIHRvIEVtYWlsIEFkZHJlc3MgSW50ZXJuYXRpb25hbGl6YXRp b24uDQpJZiB0aGUgY2xpZW50cyBvciBzZXJ2ZXJzIGFyZSAiRUFJLWF3YXJlIiwgaXQgbWVhbnMg dGhhdCB0aGV5IHN1cHBvcnQgdGhlICImRUFJU01UUGtleXdvcmQ7IiBleHRlbnNpb24NCmRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudC4iDQoNCnRoYW5rcyBmb3IgY2F0Y2hpbmcgaXQuDQoNCg0KDQo+ IA0KPiBNdWNoIG1vcmUgc2lnbmlmaWNhbnRseToNCj4gDQo+ICAgIEluIFNlY3Rpb24gMy4yLCB0 aGVyZSBpcyBleHRlbmRlZCB0ZXh0IHRoYXQgY292ZXJzIHRoZSBjYXNlIG9mIGFuIEVBSS1hd2Fy ZSANCj4gU01UUCBjbGllbnQgYXR0ZW1wdGluZyB0byB0cmFuc2ZlciBhIFVURi04IG1lc3NhZ2Ug dG8gYSBub24gRUFJLWF3YXJlIHNlcnZlci4gDQo+IFRoYXQgdGV4dCBlbmRzIHdpdGg6DQo+IA0K Pj4gVGhpcyBkb2N1bWVudCBhcHBsaWVzIG9ubHkgd2hlbiBhbiBFQUktYXdhcmUgU01UUCBjbGll bnQgaXMgdHJ5aW5nIHRvDQo+PiAgICBzZW5kIGFuIGludGVybmF0aW9uYWxpemVkIG1lc3NhZ2Ug dG8gYW4gRUFJLWF3YXJlIFNNVFAgc2VydmVyLg0KPiANCj4gICAgVGhlIHRleHQgdGhhdCB5b3Ug YXJlIGhhdmUganVzdCBjaXJjdWxhdGVkIHJ1bnMgY29udHJhcnkgdG8gdGhpcyBzdGF0ZW1lbnQg DQo+IG9mIHRoZSBkb2N1bWVudCdzIGxpbWl0cy4gIEkgYWxzbyBiZWxpZXZlIHRoYXQgdGhlcmUg aXMgbm8gb3RoZXIgcGxhY2UgaW4gdGhlIA0KPiBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyBpbnRl cmFjdGlvbnMgd2l0aCBub24tRUFJLWF3YXJlIHNlcnZlcnMuDQo+IA0KPiANCj4gICAgSWYgdGhl IGFib3ZlIHNlbnRlbmNlIGlzIHJlbW92ZWQgZnJvbSB5b3VyIG5ldyB0ZXh0LCB0aGVuIHRoZSB0 ZXh0IHdpbGwgcmVhZCANCj4gd2VsbCBhbmQgd2lsbCBzdGF5IHdpdGhpbiB0aGUgZGVmaW5lZCBs aW1pdHMgb2YgdGhlIGRvY3VtZW50Lg0KPg0KDQp0aGUgb3JpZ2luYWwgdGV4dCBpbiB0aGlzIHBh cmFncmFwaCBpcyANCiIgVGhpcyBkb2N1bWVudCBhcHBsaWVzIG9ubHkgd2hlbiBhbiBFQUktYXdh cmUgU01UUCBjbGllbnQgaXMgdHJ5aW5nIHRvDQogICBzZW5kIGFuIGludGVybmF0aW9uYWxpemVk IG1lc3NhZ2UgdG8gYW4gRUFJLWF3YXJlIFNNVFAgc2VydmVyLiAgRm9yDQogICBhbGwgb3RoZXIg Y2FzZXMsIGFuZCBmb3IgYWRkcmVzc2VzIGFuZCBtZXNzYWdlcyB0aGF0IGRvIG5vdCByZXF1aXJl DQogICBhbiBVVEY4U01UUGJpcyBleHRlbnNpb24sIEVBSS1hd2FyZSBTTVRQIGNsaWVudHMgYW5k IHNlcnZlcnMgZG8gbm90DQogICBjaGFuZ2UgdGhlIGJlaGF2aW9yIHNwZWNpZmllZCBpbiBbUkZD NTMyMV0uDQoNCiINCg0KSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dA0KDQoiVGhpcyBkb2N1 bWVudCBhcHBsaWVzIHdoZW4gYW4gRUFJLWF3YXJlIFNNVFAgY2xpZW50IG9yIHNlcnZlciBzdXBw b3J0cyB0aGUgVVRGOFNNVFBiaXMgZXh0ZW5zaW9uLg0KRm9yIGFsbCBvdGhlciBjYXNlcywgYW5k IGZvciBhZGRyZXNzZXMgYW5kIG1lc3NhZ2VzIA0KdGhhdCBkbyBub3QgcmVxdWlyZSBhbiAmRUFJ U01UUGtleXdvcmQ7IGV4dGVuc2lvbiwgRUFJLWF3YXJlIFNNVFAgY2xpZW50cyBhbmQgc2VydmVy cyBkbyANCm5vdCBjaGFuZ2UgdGhlIGJlaGF2aW9yIHNwZWNpZmllZCBpbiAgUkZDNTMyMS4gIg0K DQpUaGFua3MgYSBsb3QgZm9yIHlvdXIga2luZCBjb21tZW50cy4NCg0KSmlhbmthbmcgWWFvDQo= From yangwooko@gmail.com Tue Jul 5 23:05:27 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 27D3221F85E4 for ; Tue, 5 Jul 2011 23:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB5cUuGwKn18 for ; Tue, 5 Jul 2011 23:05:26 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5821F85E2 for ; Tue, 5 Jul 2011 23:05:25 -0700 (PDT) Received: by vws12 with SMTP id 12so5884117vws.31 for ; Tue, 05 Jul 2011 23:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=XcBSzmSW0wxnqf4Km/n7u+7pAfcE/8o+q872zPzj3yw=; b=FKh6sc5XNiGO0xkVl/Iczp2YFAJ8Xgi3j50M6uVs94YRANt1G7/XKlXjQNB6SrWM3P E3CZefIZJMY4QN4f/+nMTKOPmkqx9+ry7Y3gUu2+mGNLcPx4orLQJcnyYv+qBEJqi+w0 SGCxCwH5xx7LHun2+n4FYtahpWThulpn4U+j8= Received: by 10.52.94.110 with SMTP id db14mr7096258vdb.256.1309932325069; Tue, 05 Jul 2011 23:05:25 -0700 (PDT) MIME-Version: 1.0 Sender: yangwooko@gmail.com Received: by 10.52.164.201 with HTTP; Tue, 5 Jul 2011 23:05:05 -0700 (PDT) In-Reply-To: References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <509880557.08490@cnnic.cn> From: Yangwoo Ko Date: Wed, 6 Jul 2011 15:05:05 +0900 X-Google-Sender-Auth: msyCcjISPkBKFNLv9Q8v8wijSQM Message-ID: To: Jiankang Yao Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Dave CROCKER , ima@ietf.org Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Jul 2011 06:05:27 -0000 On Wed, Jul 6, 2011 at 2:47 PM, Jiankang Yao wrote: > > > > ----- Original Message ----- > From: "Dave CROCKER" > To: ; "YAO Jiankang" > Sent: Tuesday, July 05, 2011 11:39 PM > Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand R= FC5336bis > > >> Jiankang, >> >> On 7/4/2011 8:32 PM, Jiankang Yao wrote: >>> If the messages including the trace field values are sent by the EAI- >>> =C2=A0 =C2=A0 aware SMTP client or relay server without the EAI paramet= er at MAIL >>> =C2=A0 =C2=A0 commands, =C2=A0trace field values =C2=A0must conform to = RFC 5321 regardless the SMTP server's >>> =C2=A0 =C2=A0 capability. >> >> >> I just noticed that the term "EAI" is not defined in the document; it is= used >> quite a bit. =C2=A0Whatever term is used, it needs to be defined. >> > > there are dozens of "EAI" in the documents. > > =C2=A0I propose the following text in the terminology section: > > "The term "EAI" refers to Email Address Internationalization. > If the clients or servers are "EAI-aware", it means that they support the= "&EAISMTPkeyword;" extension > defined in this document." > > thanks for catching it. > > > >> >> Much more significantly: >> >> =C2=A0 =C2=A0In Section 3.2, there is extended text that covers the case= of an EAI-aware >> SMTP client attempting to transfer a UTF-8 message to a non EAI-aware se= rver. >> That text ends with: >> >>> This document applies only when an EAI-aware SMTP client is trying to >>> =C2=A0 =C2=A0send an internationalized message to an EAI-aware SMTP ser= ver. >> >> =C2=A0 =C2=A0The text that you are have just circulated runs contrary to= this statement >> of the document's limits. =C2=A0I also believe that there is no other pl= ace in the >> document that specifies interactions with non-EAI-aware servers. >> >> >> =C2=A0 =C2=A0If the above sentence is removed from your new text, then t= he text will read >> well and will stay within the defined limits of the document. >> > > the original text in this paragraph is > " This document applies only when an EAI-aware SMTP client is trying to > =C2=A0 send an internationalized message to an EAI-aware SMTP server. =C2= =A0For > =C2=A0 all other cases, and for addresses and messages that do not requir= e > =C2=A0 an UTF8SMTPbis extension, EAI-aware SMTP clients and servers do no= t > =C2=A0 change the behavior specified in [RFC5321]. > > " > > I propose the following text > > "This document applies when an EAI-aware SMTP client or server supports t= he UTF8SMTPbis extension. > For all other cases, and for addresses and messages > that do not require an &EAISMTPkeyword; extension, EAI-aware SMTP clients= and servers do > not change the behavior specified in =C2=A0RFC5321. " A standard document specifies what is the right thing for a standard conformant program (or whatever) to do. You don't need to specify how all other non conformant programs should do unless such an explanation is useful for readers to understand what the document specifies. > > Thanks a lot for your kind comments. > > Jiankang Yao > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > --=20 a human known as yangwooko@gmail.com @ gtalk From healthyao@gmail.com Tue Jul 5 23:12: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 842B221F862F for ; Tue, 5 Jul 2011 23:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT8xl8OA4KWL for ; Tue, 5 Jul 2011 23:12:34 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD01C21F862D for ; Tue, 5 Jul 2011 23:12:27 -0700 (PDT) Received: by iwn39 with SMTP id 39so7170035iwn.31 for ; Tue, 05 Jul 2011 23:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=eU9KMFcebWYcFdP5FMhGvwPVqWpUbzpYiGsCG97oa/M=; b=P0AZeoI/cdq+zgaDlB5B3e5EBjtiK+jsfxSGUHryDGoca9DDmfMFo8+Ze+yJQWpS8t By+Q03igkcQoP0BYUJjAgDYQLLfI42qd+oA6aWTEAJszvE3xipiXKu5q3OwapmUMvvNv zpwTE8uthBF3pecY5l3RH+3ORsMHXQn4cbmf0= Received: by 10.42.177.133 with SMTP id bi5mr8616345icb.36.1309932747130; Tue, 05 Jul 2011 23:12:27 -0700 (PDT) Received: from LENOVO47E041CF ([218.241.103.12]) by mx.google.com with ESMTPS id q13sm2150077ibi.60.2011.07.05.23.12.24 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 23:12:26 -0700 (PDT) Message-ID: <7BD2876309CB4597A2EFBC7954E3B22E@LENOVO47E041CF> From: "Jiankang Yao" To: "Yangwoo Ko" References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <509880557.08490@cnnic.cn> Date: Wed, 6 Jul 2011 14:12:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Dave CROCKER , ima@ietf.org Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Jul 2011 06:12:34 -0000 DQpJdCBpcyBkdWUgdG8gdGhlIHByZXZpb3VzIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBpc3N1ZS4N Cg0KSXQgaXMgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBJZiB5b3UgZGlnIHRoaXMgaXNzdWUsIHlv dSB3aWxsIGZpbmQgc29tZSByZWxhdGVkIGRpc2N1c3Npb24uDQoNClNvbWUgY29sbGVhZ3VlcyBz dWdnZXN0cyB0byBjbGFyaWZ5IHdoYXQgcmZjNTMzNmJpcyBkb2VzIGFuZCAgc29tZSByZWxhdGlv biB0byByZmM1MzIxLg0KDQpKaWFua2FuZyBZYW8NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJZYW5nd29vIEtvIiA8bmV3Y2F0QGljdS5hYy5rcj4NClRvOiAiSmlhbmth bmcgWWFvIiA8aGVhbHRoeWFvQGdtYWlsLmNvbT4NCkNjOiAiRGF2ZSBDUk9DS0VSIiA8ZGNyb2Nr ZXJAYmJpdy5uZXQ+OyA8aW1hQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAy MDExIDI6MDUgUE0NClN1YmplY3Q6IFJlOiBbRUFJXSBwcm9wb3NlZCB0ZXh0IFJlOiBDb25zZW5z dXMgUmVzdWx0IC0gdHJhY2UgZmllbGRzYW5kIFJGQzUzMzZiaXMNCg0KDQo+ICINCj4NCj4gSSBw cm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dA0KPg0KPiAiVGhpcyBkb2N1bWVudCBhcHBsaWVzIHdo ZW4gYW4gRUFJLWF3YXJlIFNNVFAgY2xpZW50IG9yIHNlcnZlciBzdXBwb3J0cyB0aGUgVVRGOFNN VFBiaXMgZXh0ZW5zaW9uLg0KPiBGb3IgYWxsIG90aGVyIGNhc2VzLCBhbmQgZm9yIGFkZHJlc3Nl cyBhbmQgbWVzc2FnZXMNCj4gdGhhdCBkbyBub3QgcmVxdWlyZSBhbiAmRUFJU01UUGtleXdvcmQ7 IGV4dGVuc2lvbiwgRUFJLWF3YXJlIFNNVFAgY2xpZW50cyBhbmQgc2VydmVycyBkbw0KPiBub3Qg Y2hhbmdlIHRoZSBiZWhhdmlvciBzcGVjaWZpZWQgaW4gUkZDNTMyMS4gIg0KDQpBIHN0YW5kYXJk IGRvY3VtZW50IHNwZWNpZmllcyB3aGF0IGlzIHRoZSByaWdodCB0aGluZyBmb3IgYSBzdGFuZGFy ZA0KY29uZm9ybWFudCBwcm9ncmFtIChvciB3aGF0ZXZlcikgdG8gZG8uIFlvdSBkb24ndCBuZWVk IHRvIHNwZWNpZnkgaG93DQphbGwgb3RoZXIgbm9uIGNvbmZvcm1hbnQgcHJvZ3JhbXMgc2hvdWxk IGRvIHVubGVzcyBzdWNoIGFuIGV4cGxhbmF0aW9uDQppcyB1c2VmdWwgZm9yIHJlYWRlcnMgdG8g dW5kZXJzdGFuZCB3aGF0IHRoZSBkb2N1bWVudCBzcGVjaWZpZXMuDQoNCj4NCj4gVGhhbmtzIGEg bG90IGZvciB5b3VyIGtpbmQgY29tbWVudHMuDQo+DQo+IEppYW5rYW5nIFlhbw0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBs aXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ltYQ0KPg0KDQoNCg0KLS0gDQphIGh1bWFuIGtub3duIGFzIHlhbmd3b29rb0BnbWFpbC5j b20gQCBndGFsaw== From klensin@jck.com Wed Jul 6 03:21: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 8D41D21F874E for ; Wed, 6 Jul 2011 03:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zviw+A8WwWIm for ; Wed, 6 Jul 2011 03:21:04 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id E686121F874D for ; Wed, 6 Jul 2011 03:21:03 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QePE4-000LkP-Q8; Wed, 06 Jul 2011 06:21:00 -0400 Date: Wed, 06 Jul 2011 06:21:00 -0400 From: John C Klensin To: Jiankang Yao , Dave CROCKER , ima@ietf.org Message-ID: In-Reply-To: References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <509880557.08490@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Terminology using "EAI" (was: Re: proposed text Re: Consensus Result - trace fields and RFC5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Jul 2011 10:21:04 -0000 --On Wednesday, July 06, 2011 13:47 +0800 Jiankang Yao wrote: > there are dozens of "EAI" in the documents. > > I propose the following text in the terminology section: > > "The term "EAI" refers to Email Address Internationalization. > If the clients or servers are "EAI-aware", it means that they > support the "&EAISMTPkeyword;" extension defined in this > document." Personal opinion: Filling these documents with more and more acronyms and abbreviations, no matter how well defined, makes them hard to read (and easy to misunderstand when readers can't keep track of the abbreviations). If possible, consider eliminating the term, as Dave suggested. I've done a small sample and it appears to me that most or all of the cases that cannot be fixed by substituting "&EAISMTPkeyword;" and appropriate wording can be fixed with language like "conforming to this specification" or "conforming to this set of specifications". If you need a definition of the latter, point to the framework spec (4592bis). We do owe ourselves (and the community) a final check on the contents of that document when 5335bis...5337bis are ready to go. john From chl@clerew.man.ac.uk Wed Jul 6 04:28: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 7FAF021F860F for ; Wed, 6 Jul 2011 04:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBWLobYvgQyo for ; Wed, 6 Jul 2011 04:28:07 -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 788B521F860B for ; Wed, 6 Jul 2011 04:28:06 -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 95EBE22151 for ; Wed, 6 Jul 2011 12:28:05 +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, 06 Jul 2011 12:28:05 +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 p66BS3v0001991 for ; Wed, 6 Jul 2011 12:28:04 +0100 (BST) Date: Wed, 06 Jul 2011 12:28:03 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <509880557.08490@cnnic.cn> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4e1446c5.255-fd0-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand RFC5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Jul 2011 11:28:08 -0000 On Wed, 06 Jul 2011 06:47:13 +0100, Jiankang Yao wrote: > ----- Original Message ----- > From: "Dave CROCKER" > To: ; "YAO Jiankang" > Sent: Tuesday, July 05, 2011 11:39 PM > Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand > RFC5336bis > > >> Jiankang, >> >> On 7/4/2011 8:32 PM, Jiankang Yao wrote: >>> If the messages including the trace field values are sent by the EAI- >>> aware SMTP client or relay server without the EAI parameter at MAIL >>> commands, trace field values must conform to RFC 5321 regardless >>> the SMTP server's >>> capability. >> >> >> I just noticed that the term "EAI" is not defined in the document; it >> is used >> quite a bit. Whatever term is used, it needs to be defined. >> > > there are dozens of "EAI" in the documents. > > I propose the following text in the terminology section: Alternatively, abolish the term "EAI" and use something else. It is an historical artefact of the way we got here, and is well past its sell-by-date. Perhaps this problem should be considered alongside the question of what to use in place of "UTF8SMTPbis". -- 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 ned+ima@mrochek.com Wed Jul 6 11:48:01 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 9360E21F8A41 for ; Wed, 6 Jul 2011 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKFOKwzEnhyl for ; Wed, 6 Jul 2011 11:47:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 89C4721F8A46 for ; Wed, 6 Jul 2011 11:47:57 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O3BQPWVYOG00W1ET@mauve.mrochek.com> for ima@ietf.org; Wed, 6 Jul 2011 11:47:18 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O3BPBM35VK00RCTX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 6 Jul 2011 11:47:14 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01O3BQPUTNUQ00RCTX@mauve.mrochek.com> Date: Wed, 06 Jul 2011 11:46:38 -0700 (PDT) In-reply-to: "Your message dated Wed, 06 Jul 2011 06:21:00 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <509783640.06768@cnnic.cn> <36C4E10D9BCC4312B2CB55402590C611@LENOVO47E041CF> <509880557.08490@cnnic.cn> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1309977612; bh=IbT8twYXbwXabd6yCViE6mtBzeBL+tLjJjHqFB1acN8=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=GuPOMi9E6dYgHPJmEvbbnQA+GU1ARPvYrFDygXC1njh0IvAkq//CrEUsbBg3uIoPe Qa2mIjrIDeD0v/mw+szDaVvwnyRIiyRFMHLfbyfKJ8jNf5+1VZWlvnrxAPRL9kLUMD zsyH3q9/KHLXlAuEyXRFOrj4HwXmHatx6QpGkiwM= Cc: ima@ietf.org, Dave CROCKER , Jiankang Yao Subject: Re: [EAI] Terminology using "EAI" (was: Re: proposed text Re: Consensus Result - trace fields and RFC5336bis) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 06 Jul 2011 18:48:01 -0000 +1 Ned > Filling these documents with more and more acronyms and > abbreviations, no matter how well defined, makes them hard to > read (and easy to misunderstand when readers can't keep track of > the abbreviations). If possible, consider eliminating the > term, as Dave suggested. I've done a small sample and it > appears to me that most or all of the cases that cannot be fixed > by substituting "&EAISMTPkeyword;" and appropriate wording can > be fixed with language like "conforming to this specification" > or "conforming to this set of specifications". If you need a > definition of the latter, point to the framework spec (4592bis). > We do owe ourselves (and the community) a final check on the > contents of that document when 5335bis...5337bis are ready to go. > john From jyee@afilias.info Thu Jul 7 15:20: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 8678621F8973 for ; Thu, 7 Jul 2011 15:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trVvKn0uK9EV for ; Thu, 7 Jul 2011 15:20:18 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id C90D521F8971 for ; Thu, 7 Jul 2011 15:20:17 -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 1Qewvg-0003CC-6q for ima@ietf.org; Thu, 07 Jul 2011 22:20:16 +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 1Qewvf-00006o-6M for ima@ietf.org; Thu, 07 Jul 2011 22:20:16 +0000 Received: by ywa6 with SMTP id 6so581484ywa.9 for ; Thu, 07 Jul 2011 15:20:15 -0700 (PDT) Received: by 10.90.13.15 with SMTP id 15mr1407890agm.156.1310077215220; Thu, 07 Jul 2011 15:20:15 -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 h26sm5240882anp.39.2011.07.07.15.20.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 15:20:14 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 18:20:13 -0400 To: "ima@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] RFC5721bis (POP3 UTF8) review X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 07 Jul 2011 22:20:18 -0000 Hi, I read the the recent (-01) draft-ietf-eai-rfc5721bis. Changes and = suggestions below: (1) Header: remove "Updates RFC1939" Similar to RFC5336bis, the draft extends rather than changes the base = specification of POP3 (RFC1939). (2) Section 1 Introduction, 2nd paragraph, words suggestion Original "It also adds a mechanism to support login names and passwords outside the ASCII character set, and a mechanism to support UTF-8 protocol-level error strings in a language appropriate for the user." Suggestion "It also adds a mechanism to support login names and passwords with = UTF-8 charset beyond ASCII, and a mechanism to support UTF-8 charset in = protocol level response strings for languages beyond English." Note: +OK carries message too, not just -ERR) (3) "UTF-8 mode" definition The term "UTF-8 mode" was used a lot in Section 3 but didn't explain = explain in details what is "UTF-8 mode". Suggest to define the term in = Section 1 Introduction or at the beginning of Section 3. The Abstract = section has the explanation, but without the term "UTF-8 mode". (4) Section 2 LANG Capability Commands valid in states: original: =20 AUTHENTICATION, TRANSACTION correction:=20 AUTHORIZATION, TRANSACTION (5)=20 Section 3.1, 4th paragraph, minor/nit editing Original "need not to be accurate, but it is preferable if they are" Edit "need not to be accurate, but it is preferable if they were" (6) Section 3.2, 4th paragraph The terms "query string" and "stored string" are terms from stringprep = rather than saslprep. Although saslprep references stringprep, saslprep = does not have these two terms. Suggest to append [RFC3454] to both = terms, and add RFC3454 as Normative references. (7) Reference of [popimap-downgrade] is Informative now. Personal thought: Should it be Normative references instead? (8) Appendix A, 4th paragraph The whole paragraph explains the lack of useful examples due to = limitation of the document format, and=20 "As a result, there are no plans to provide examples for that = part of the specification as long as this remains an experimental = proposal" This draft already notifies and explains the absence of character = accents in example, and this draft is not an experimental proposal = anymore. I recommend to either rewrite the explanation & take out text = about experimental proposal, or just remove the whole paragraph. Thanks Joseph From jyee@afilias.info Thu Jul 7 15:20:22 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 7F12F21F8986 for ; Thu, 7 Jul 2011 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.065 X-Spam-Level: X-Spam-Status: No, score=-5.065 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Eqdynm-Z69 for ; Thu, 7 Jul 2011 15:20:22 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 99FA921F8983 for ; Thu, 7 Jul 2011 15:20:21 -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 1Qewvl-0000Aj-3o for ima@ietf.org; Thu, 07 Jul 2011 22:20:21 +0000 Received: from mail-yx0-f178.google.com ([209.85.213.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Qewvl-00006x-3K for ima@ietf.org; Thu, 07 Jul 2011 22:20:21 +0000 Received: by yxm8 with SMTP id 8so599796yxm.9 for ; Thu, 07 Jul 2011 15:20:20 -0700 (PDT) Received: by 10.101.128.20 with SMTP id f20mr1127088ann.162.1310077220361; Thu, 07 Jul 2011 15:20:20 -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 h26sm5240882anp.39.2011.07.07.15.20.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 15:20:19 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 18:20:19 -0400 To: "ima@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] RFC5738bis (IMAP UTF8) review X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 07 Jul 2011 22:20:22 -0000 Hi, I read the recent (-00) draft-ietf-eai-rfc5738bis. Changes and = suggestions below: (1) Header: add "Obsoletes: RFC5738 (if approved)" (2) Section 1, 1st paragraph, RFC5335/RFC5335bis referencing It references "Internationalized Email Headers" to [RFC5335] now. It = should reference to RFC5335bis. Normative References section needs = update (RFC5335 --> RFC5335bis) as well. (3) Section 3.1, ABNF, minor improvement for readability The term "utf8-quoted' was used through out Section 3. Although it's = meant for uQuoted defined in the previous ABNF subsection, it's not = linked. Suggestion: Add the following ABNF comment under uQuoted uQuoted =3D "*" DQUOTE *uQUOTED-CHAR DQUOTE ; referred as 'utf8-quote' in this = document <---- or something similar (4) Section 3.4.2 ABNF uList-select-independent-opt is neither defined nor referenced = by other rules =09 It should be 'list-select-independent-opt'. (5) Section 3.4.2 ABNF, minor improvement Since this part of ABNF references from 2 RFCs, I suggested to = add comment of their sources for easier referencing. list-select-indenpendent-opt list-select-base-opt return-option ;RFC 5258 Section 6 mbx-list-oflag resp-text-code ;RFC 3501 Section 9 (6) Section 10, minor/nit edit 1st paragraph original "This adds five new...." suggestion "This document adds five new..." 2nd paragraph original "This adds two new ..." suggestion "This document adds two new...." (7) Normative Reference, ordering, very minor All RFC references were sorted, except RFC5890 (8) Appendix A, 5th paragraph, at the end The text mentions up-conversion on POP3-UTF8 and references to RFC5721. = The reference needs to update to RFC5721bis in the text and in = Informative References as well. (9) Reference of [popimap-downgrade] is Informative now. Personal thought: Similar to POP3 UTF8, should it be Normative = references instead? Thanks Joseph= From internet-drafts@ietf.org Thu Jul 7 18:23: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 2CDD921F8942; Thu, 7 Jul 2011 18:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNxyW+Z8JpBI; Thu, 7 Jul 2011 18:23:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7933321F8930; Thu, 7 Jul 2011 18:23:52 -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.55 Message-ID: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 18:23:52 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-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: Fri, 08 Jul 2011 01:23:53 -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-11.txt Pages : 20 Date : 2011-07-07 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-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-rfc5336bis-11.txt From internet-drafts@ietf.org Sun Jul 10 19:21: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 1070D21F861A; Sun, 10 Jul 2011 19:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P46WR8ickBxz; Sun, 10 Jul 2011 19:21:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D421F84EC; Sun, 10 Jul 2011 19:21:48 -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.55 Message-ID: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 19:21:48 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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: Mon, 11 Jul 2011 02:21:49 -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-11.txt Pages : 13 Date : 2011-07-10 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-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-rfc5335bis-11.txt From internet-drafts@ietf.org Mon Jul 11 00:08:09 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 10DB221F8A68; Mon, 11 Jul 2011 00:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC0GzLJ0bl+b; Mon, 11 Jul 2011 00:08:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C421F86AF; Mon, 11 Jul 2011 00:08:08 -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.55 Message-ID: <20110711070808.21862.93387.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 00:08:08 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5721bis-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 07:08:09 -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 : POP3 Support for UTF-8 Author(s) : Randall Gellens Chris Newman Jiankang Yao Kazunori Fujiwara Filename : draft-ietf-eai-rfc5721bis-02.txt Pages : 13 Date : 2011-07-11 This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual strings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5721bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-rfc5721bis-02.txt From internet-drafts@ietf.org Mon Jul 11 03:04: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 C85C521F8AFF; Mon, 11 Jul 2011 03:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8gzyhcAvJ4e; Mon, 11 Jul 2011 03:04:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5534B21F8AF4; Mon, 11 Jul 2011 03:04:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 03:04:44 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:04:45 -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 : IMAP Support for UTF-8 Author(s) : Pete Resnick Chris Newman Sean Shen Filename : draft-ietf-eai-5738bis-01.txt Pages : 16 Date : 2011-07-11 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-5738bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-5738bis-01.txt From internet-drafts@ietf.org Mon Jul 11 12:18: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 16A051F0C54; Mon, 11 Jul 2011 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUkA8telEYIu; Mon, 11 Jul 2011 12:18:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2EA1F0C52; Mon, 11 Jul 2011 12:17:49 -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.55 Message-ID: <20110711191749.16395.89211.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 12:17:49 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-popimap-downgrade-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 19:18:04 -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-02.txt Pages : 17 Date : 2011-07-11 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-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-02.txt From internet-drafts@ietf.org Mon Jul 11 16:12: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 6118A11E82BD; Mon, 11 Jul 2011 16:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mihJpj+35ueE; Mon, 11 Jul 2011 16:12:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D62E11E8327; Mon, 11 Jul 2011 16:12:13 -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.55 Message-ID: <20110711231213.13281.36812.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 16:12:13 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5337bis-dsn-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, 11 Jul 2011 23:12:53 -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-03.txt Pages : 21 Date : 2011-07-11 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-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-rfc5337bis-dsn-03.txt From aharon@google.com Thu Jul 14 06:09:27 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 7086721F87C9 for ; Thu, 14 Jul 2011 06:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFwwvTw8CL-r for ; Thu, 14 Jul 2011 06:09:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DB9B921F87BA for ; Thu, 14 Jul 2011 06:09:22 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p6ED9LvP006360 for ; Thu, 14 Jul 2011 06:09:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310648961; bh=ZeoxcOB/5xnLEt4YlKk96gu4eJ8=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type: Content-Transfer-Encoding; b=GLl9t5xmVh1dJlNIlSZnUoWQNIiksBnE+NXUI7FE8d7zdW8iR7G3A3aqUDi+jeVLV zwPDAS8eoI2CVnGnXn+/Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:from:date:message-id:subject:to: content-type:content-transfer-encoding:x-system-of-record; b=QOwI9+ILPQljGIcdkXd3DbpYMPBPWhUPGV3SP+3JkBdbIDvelIrVmUEVt4HUvbjQU nOpouEnsT84LBNjL0ystg== Received: from wyh21 (wyh21.prod.google.com [10.241.226.213]) by kpbe19.cbf.corp.google.com with ESMTP id p6ED8qtS013974 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 14 Jul 2011 06:09:19 -0700 Received: by wyh21 with SMTP id 21so173788wyh.24 for ; Thu, 14 Jul 2011 06:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=nLpe5Fz1LCJjxy9qwWul++3KR92L6908i2LkwFt2U9g=; b=tb7WgOqwTA5LNZLZx73zZigeOUYk0X8wCU756OtSGKpYflkZE9PcThl5wmKIHPUIaZ vFOyds05hYcPcK3RcDLg== Received: by 10.216.79.74 with SMTP id h52mr6364646wee.38.1310648958127; Thu, 14 Jul 2011 06:09:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.81.73 with HTTP; Thu, 14 Jul 2011 06:08:58 -0700 (PDT) From: "Aharon (Vladimir) Lanin" Date: Thu, 14 Jul 2011 16:08:58 +0300 Message-ID: To: ima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Jul 2011 13:09:27 -0000 Just in case this is news for anyone here, the Unicode Technical Committee is considering=C2=A0PRI #185:=C2=A0"Revision of UBA for improved display of URL/IRIs". (UBA stands for Unicode Bidirectional Algorithm.) The intent of the proposal is to improve the display of bidirectional IRIs. The same problems (if not worse) that exist for bidi IRIs also exist for bidi email addresses. I have submitted a comment on PRI #185 suggesting that it be extended to cover email addresses. Aharon Lanin Here is the announcement of PRI #185: The Unicode Technical Committee has posted a new issue for public review and comment. Details are on the following web page: =C2=A0 =C2=A0http://www.unicode.org/review/ Review period for the new item closes on July 27, 2011. Please see the page for links to discussion and relevant documents. Briefly, the new issue is: PRI #185=C2=A0=C2=A0 =C2=A0Revision of UBA for improved display of URL/IRIs The Unicode Bidirectional Algorithm (UBA), specified in UAX #9, was designed for handling ordinary text, and predated the rise of the web. Unfortunately, IRI/URLs are not ordinary text; they are syntactically complex in ways that don=E2=80=99t work well with the UBA. That causes IRIs that contain right-to-left text (such as Arabic or Hebrew) to appear jumbled, to the point where the IRIs are either uninterpretable, misleading, or ambiguous. In particular the ambiguous displays could cause security problems. The background document for this PRI provides a detailed description of the problem, and proposes a solution. The Unicode Technical Committee would like feedback on the feasibility of the proposal, and in particular, on the open issues listed in the background document. If you have comments for official UTC consideration, please post them by submitting your comments through our feedback & reporting page: =C2=A0 =C2=A0http://www.unicode.org/reporting.html If you wish to discuss issues on the Unicode forum or the Unicode mail list, then please use the following links to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as input to the UTC. You must use the reporting link above to generate comments for UTC consideration. =C2=A0 =C2=A0http://www.unicode.org/forum/ =C2=A0 =C2=A0http://www.unicode.org/consortium/distlist.html From arnt@gulbrandsen.priv.no Thu Jul 14 06:32: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 D438A21F86A3 for ; Thu, 14 Jul 2011 06:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE-Mt8lsfYh6 for ; Thu, 14 Jul 2011 06:32:46 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781F21F85A3 for ; Thu, 14 Jul 2011 06:32:45 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id 93105FA0075; Thu, 14 Jul 2011 13:32:44 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.3) with esmtpsa id 1310650363-1279-1278/9/879; Thu, 14 Jul 2011 15:32:43 +0200 Message-Id: <4E1EEFFA.1080007@gulbrandsen.priv.no> Date: Thu, 14 Jul 2011 15:32:42 +0200 From: Arnt Gulbrandsen Organization: Me, http://arnt.gulbrandsen.priv.no User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 Mime-Version: 1.0 To: ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Jul 2011 13:32:46 -0000 On 07/14/2011 03:08 PM, Aharon (Vladimir) Lanin wrote: > Just in case this is news for anyone here, the Unicode Technical > Committee is considering PRI #185: "Revision of UBA for improved > display of URL/IRIs". (UBA stands for Unicode Bidirectional > Algorithm.) The intent of the proposal is to improve the display of > bidirectional IRIs. > > The same problems (if not worse) that exist for bidi IRIs also exist > for bidi email addresses. Why would the problems be worse for email? Bad, yes, no disagreement at all. My question is specifically about the "if not worse" bit. > I have submitted a comment on PRI #185 > suggesting that it be extended to cover email addresses. Excellent. Arnt From aharon@google.com Thu Jul 14 07:19:01 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 8C81F21F8AEC for ; Thu, 14 Jul 2011 07:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.144 X-Spam-Level: X-Spam-Status: No, score=-106.144 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52UOz2BVPttX for ; Thu, 14 Jul 2011 07:18:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 44EB721F8AE4 for ; Thu, 14 Jul 2011 07:18:57 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p6EEItqS031198 for ; Thu, 14 Jul 2011 07:18:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310653136; bh=Bev6+cIdLiGV2Ls0D+BAJfQtDgE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kPXF+1A6dhAbWwdRnzvPxEOfI7GT9cCa6zkclOHJQ01L27UP2Gt0wZaVb3NWFA8t+ aJx2yhhBffvosHYUEeeow== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=PyR44qvOzA5DdASowLbbc1XFEuHfrmmC5e/FgiptBhPaPGusKylHcMwv6940IY6K2 hbFrDyi3tutbT1vD4GbLw== Received: from wyf22 (wyf22.prod.google.com [10.241.226.86]) by kpbe18.cbf.corp.google.com with ESMTP id p6EEIrYo025196 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 14 Jul 2011 07:18:54 -0700 Received: by wyf22 with SMTP id 22so211460wyf.15 for ; Thu, 14 Jul 2011 07:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JhD4/gjfG7f+iJIjg5+Nd8O8zFKI02bwfZeovuurNu0=; b=IXEMnFbfuKveF4xtqchACbKQCdEgJ+CQdst9vjVKrKsSgiofyFyGZrKBslKl6ChYtm IWKxWjQBSnr8p8O11qJw== Received: by 10.216.185.19 with SMTP id t19mr2129253wem.8.1310653133087; Thu, 14 Jul 2011 07:18:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.81.73 with HTTP; Thu, 14 Jul 2011 07:18:33 -0700 (PDT) In-Reply-To: <4E1EEFFA.1080007@gulbrandsen.priv.no> References: <4E1EEFFA.1080007@gulbrandsen.priv.no> From: "Aharon (Vladimir) Lanin" Date: Thu, 14 Jul 2011 17:18:33 +0300 Message-ID: To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=0016e64984446be2cf04a808360a X-System-Of-Record: true Cc: ima@ietf.org Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Jul 2011 14:19:01 -0000 --0016e64984446be2cf04a808360a Content-Type: text/plain; charset=UTF-8 It's not an important point. I guess email addresses are just so deceptively simple. In RTL, jennings@a-well-known-bank.com.GEORGE.pl (where uppercase Latin letters stand for RTL characters) is displayed as pl.EGROEG.jennings@a-well-known-bank.com A large number of users will think that they are talking to someone at a-well-known-bank.com. Aharon On Thu, Jul 14, 2011 at 4:32 PM, Arnt Gulbrandsen wrote: > On 07/14/2011 03:08 PM, Aharon (Vladimir) Lanin wrote: > >> Just in case this is news for anyone here, the Unicode Technical >> Committee is considering PRI #185: "Revision of UBA for improved >> display of URL/IRIs". (UBA stands for Unicode Bidirectional >> Algorithm.) The intent of the proposal is to improve the display of >> bidirectional IRIs. >> >> The same problems (if not worse) that exist for bidi IRIs also exist >> for bidi email addresses. >> > > Why would the problems be worse for email? > > Bad, yes, no disagreement at all. My question is specifically about the "if > not worse" bit. > > > I have submitted a comment on PRI #185 >> suggesting that it be extended to cover email addresses. >> > > Excellent. > > Arnt > ______________________________**_________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/**listinfo/ima > --0016e64984446be2cf04a808360a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's not an important point. I guess email addresses a= re just so deceptively simple. In RTL, jennings@a-well-known-bank.com.GEORGE.pl (where= uppercase Latin letters stand for RTL characters) is displayed as


A lar= ge number of users will think that they are talking to someone at=C2=A0a-well-known-bank.com.

Aharon

On Thu, Jul 14= , 2011 at 4:32 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no&g= t; wrote:
On 07/14/2011 03:08 PM, Aharon (Vladimi= r) Lanin wrote:
Just in case this is news for anyone here, the Unicode Technical
Committee is considering PRI #185: "Revision of UBA for improved
display of URL/IRIs". (UBA stands for Unicode Bidirectional
Algorithm.) The intent of the proposal is to improve the display of
bidirectional IRIs.

The same problems (if not worse) that exist for bidi IRIs also exist
for bidi email addresses.

Why would the problems be worse for email?

Bad, yes, no disagreement at all. My question is specifically about the &qu= ot;if not worse" bit.


I have submitted a comment on PRI #185
suggesting that it be extended to cover email addresses.

Excellent.

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

--0016e64984446be2cf04a808360a-- From klensin@jck.com Thu Jul 14 12:31:22 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 EFEF721F8C41 for ; Thu, 14 Jul 2011 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.673 X-Spam-Level: X-Spam-Status: No, score=-3.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUmhacxJ3GF4 for ; Thu, 14 Jul 2011 12:31:19 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id B049B21F8B8E for ; Thu, 14 Jul 2011 12:31:18 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QhRcs-000K1O-O7; Thu, 14 Jul 2011 15:31:11 -0400 Date: Thu, 14 Jul 2011 15:31:09 -0400 From: John C Klensin To: "Aharon (Vladimir) Lanin" , Arnt Gulbrandsen Message-ID: In-Reply-To: References: <4E1EEFFA.1080007@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Jul 2011 19:31:23 -0000 Aharon, There are a number of different issues associated with this. It is probably useful to try to separate out at least three of them. (1) Neither the IDNA2008 Standards nor the EMA work take any position on how domain names or email addresses (including but not limited to strings that would invoke the various Bidi rules) are presented to users or provided by them. So the suppositions that lead to a display of "pl.EGROEG.jennings@a-well-known-bank.com" may be correct, or not, but the IETF specs don't have an opinion on the matter. For the record, they also don't formally have an opinion as to whether, in parts of the world in which family names are typically written before personal names, etc., the string that SMTP sees as joe.bloggs@mail.example.com is displayed as joe.bloggs@mail.example.com mail.example.com@joe.bloggs mail.example.com@bloggs.joe or even com.example.mail##bloggs.joe or some other variation (where "##" is some relatively arbitrary delimiter). That flexibility is even true when the local-part and domain-part consist exclusively of ASCII characters. The fact that we don't see those variations very often depends more on designers exercising what they consider sensible behavior than on anything that the standards or working drafts do or do not require. (2) While many of those involved are not aware that they are making the assumption and understand its implications even less, many folks around ICANN are assuming that FQDNs will be script homogeneous and directionality-property homogeneousl (maybe even language-homogeneous, but no one really knows what that means). They also assume that those homogeneity rules can and will be enforced, either by DNS software (pretty much impossible) or by administrative mechanisms (probably possible only if a series of fairly tough conditions exist administratively). If one does believe that myth, a-well-known-bank.com.GEORGE.pl is essentially not possible. One could need to have either a-well-known-bank.com.george.pl or A-WELL-KNOWN-BANK.COM.GEORGE.PL and the more mixed cases are, in the same myth, presumably expected to atrophy. (3) Many SDOs, including the IETF, have taken the position that having other SDOs develop modifications, interpretations, or even extensions to standards developed by the first body is a really bad idea (see RFC 5704 for a discussion about a topic unrelated to i18n). If this piece's interactions with IRIs and UTR46 are examples, it has apparently become the norm in the relatioship between UTC and the IETF. Perhaps that is A Good Thing but, if some parties rely only on the IETF specs and others rely on some combination or a "pick what is convenient" model, the opportunities for interoperability problems, user astonishment, and other difficulties are considerable. best, john --On Thursday, July 14, 2011 17:18 +0300 "Aharon (Vladimir) Lanin" wrote: > It's not an important point. I guess email addresses are just > so deceptively simple. In RTL, > jennings@a-well-known-bank.com.GEORGE.pl (where uppercase > Latin letters stand for RTL characters) is displayed as > > pl.EGROEG.jennings@a-well-known-bank.com > > A large number of users will think that they are talking to > someone at a-well-known-bank.com. > > Aharon > > On Thu, Jul 14, 2011 at 4:32 PM, Arnt Gulbrandsen > wrote: > >> On 07/14/2011 03:08 PM, Aharon (Vladimir) Lanin wrote: >> >>> Just in case this is news for anyone here, the Unicode >>> Technical Committee is considering PRI #185: "Revision of >>> UBA for improved display of URL/IRIs". (UBA stands for >>> Unicode Bidirectional Algorithm.) The intent of the proposal >>> is to improve the display of bidirectional IRIs. >>> >>> The same problems (if not worse) that exist for bidi IRIs >>> also exist for bidi email addresses. >>> >> >> Why would the problems be worse for email? >> >> Bad, yes, no disagreement at all. My question is specifically >> about the "if not worse" bit. >> >> >> I have submitted a comment on PRI #185 >>> suggesting that it be extended to cover email addresses. >>> >> >> Excellent. >> >> Arnt >> ______________________________**_________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/**listinfo/ima> org/mailman/listinfo/ima> >> From Shawn.Steele@microsoft.com Thu Jul 14 14:38: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 04F3411E80B7 for ; Thu, 14 Jul 2011 14:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw40+MG9Uz7Z for ; Thu, 14 Jul 2011 14:38:06 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5C11E807D for ; Thu, 14 Jul 2011 14:38:05 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 14 Jul 2011 14:38:05 -0700 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.61]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.002; Thu, 14 Jul 2011 14:38:05 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Unicode's PRI #185 & EAI: should the UBA be revised to Thread-Index: AcxCbhep3fxBXLP2T/yzyHSaoLbDYw== Date: Thu, 14 Jul 2011 21:38:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 14 Jul 2011 21:38:07 -0000 > It's not an important point. I guess email addresses are just so deceptiv= ely simple. > In RTL, jennings@a-well-known-bank.com.GEORGE.pl (where uppercase Latin l= etters > stand for RTL characters) is displayed as > pl.EGROEG.jennings@a-well-known-bank.com But mailto:pl.EGROEG.jennings@a-well-known-bank.com is an IRI, so it should= be covered by the document being discussed, and the solutions being discus= sed avoid that aspect of the problem. W/o the mailto: it's not really an IRI, though the same solution could be a= pplied. -Shawn From chl@clerew.man.ac.uk Fri Jul 15 09:10: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 D0E6521F8A58 for ; Fri, 15 Jul 2011 09:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.527 X-Spam-Level: X-Spam-Status: No, score=-4.527 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2GWpEaFYijI for ; Fri, 15 Jul 2011 09:10:15 -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 6D22121F8ADC for ; Fri, 15 Jul 2011 09:10:14 -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 C5B4821E4C for ; Fri, 15 Jul 2011 17:09:51 +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; Fri, 15 Jul 2011 17:09:51 +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 p6FG9ntD006883 for ; Fri, 15 Jul 2011 17:09:50 +0100 (BST) Date: Fri, 15 Jul 2011 17:09:49 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.25 (SunOS) X-Gradwell-MongoId: 4e20664f.f24a-db9-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 15 Jul 2011 16:10:19 -0000 On Thu, 14 Jul 2011 22:38:04 +0100, Shawn Steele wrote: > But mailto:pl.EGROEG.jennings@a-well-known-bank.com is an IRI, so it > should be covered by the document being discussed, and the solutions > being discussed avoid that aspect of the problem. > > W/o the mailto: it's not really an IRI, though the same solution could > be applied. I think that is the clue to the matter. Whatever happens to IRI ordering and (perhaps separately) to email-address ordering, there should be an invariance rule which states that whatever exists to the right of any "mailto:" should always be a valid email-address (obviously, ignoring any fancy flags at the end of the mailto for setting subjects, etc). -- 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 Fri Jul 15 10:05:37 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 B747121F8A55 for ; Fri, 15 Jul 2011 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiBV8-OIO1lx for ; Fri, 15 Jul 2011 10:05:37 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 067D421F8A51 for ; Fri, 15 Jul 2011 10:05:37 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QhlpX-000EmL-KR; Fri, 15 Jul 2011 13:05:35 -0400 Date: Fri, 15 Jul 2011 13:05:34 -0400 From: John C Klensin To: Charles Lindsey , IMA Message-ID: <29DB7C69C7E7542CF7D88432@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 15 Jul 2011 17:05:37 -0000 --On Friday, July 15, 2011 17:09 +0100 Charles Lindsey wrote: > On Thu, 14 Jul 2011 22:38:04 +0100, Shawn Steele > wrote: > >> But mailto:pl.EGROEG.jennings@a-well-known-bank.com is an >> IRI, so it should be covered by the document being >> discussed, and the solutions being discussed avoid that >> aspect of the problem. >> >> W/o the mailto: it's not really an IRI, though the same >> solution could be applied. > > I think that is the clue to the matter. Whatever happens to > IRI ordering and (perhaps separately) to email-address > ordering, there should be an invariance rule which states that > whatever exists to the right of any "mailto:" should always be > a valid email-address (obviously, ignoring any fancy flags at > the end of the mailto for setting subjects, etc). Charles (and others), There is one way to make this really simple and globally consistent and that is to treat the "@" (for email addresses) and "." label separator for domain names as absolute delimiters. That makes jennings@a-well-known-bank.com.GEORGE.pl display is as either jennings@a-well-known-bank.com.GEORGE.pl or jennings@a-well-known-bank.com.EGROEG.pl but is the end of the high-risk cases. Unfortunately, it also prohibits any sort of localized display decisions. That might be a fine idea for those of us who use Latin script in a predictable way, but it just won't happen in some local contexts: if we (or Unicode) say something that sounds culturally inappropriate or severely surprising to users, it will be ignored by at least some implementers. Worse, unless someone managed a clear and 100% accurate way to distinguish various pieces of protocol from running text (not just clever heuristics), there will be periodic dramatic failures. Consider, for example, the use of "joe at example-dot-com" to discourage address harvesting. Whether it is actually good at that or not, it would very effectively defeat any sort of rendering system that depends on "@" to identify an email address in order to handle those addresses in a special way. In retrospect and in a more perfect world, the decision to not require special introducer and terminator characters for URIs and then to get specific code points assigned by Unicode that were not to be used for anything else were probably mistakes. But we are stuck with them. john From aharon@google.com Sat Jul 16 23:14: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 4A27421F86D7 for ; Sat, 16 Jul 2011 23:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.06 X-Spam-Level: X-Spam-Status: No, score=-106.06 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfKNufJYjS1e for ; Sat, 16 Jul 2011 23:14:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 150AE21F869E for ; Sat, 16 Jul 2011 23:14:17 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p6H6EGVV004489 for ; Sat, 16 Jul 2011 23:14:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310883256; bh=vMdsUypWZZBmEPeXJAeMF7K0lfA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=NGsyZFCs8vCjbOwlV+LZKu/5neBhEEZ9Q+m/JOeztwDyZFXokPC/wwSeUlNowwLvm NMgljqojfpupdTQXv2yLA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=ntwUEq5Y6sttk6N4G0EjFHynRYbNj8eRlH7qCUxpuj6R3zGvUpM63XtmMi0RtFlry qvycaaBSUVXGps5LfWlSg== Received: from fxh2 (fxh2.prod.google.com [10.184.8.2]) by hpaq1.eem.corp.google.com with ESMTP id p6H6EFJg009234 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 16 Jul 2011 23:14:15 -0700 Received: by fxh2 with SMTP id 2so3402797fxh.37 for ; Sat, 16 Jul 2011 23:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hc0J17tVPEQj7b/RIfPrmeqRyZF5O5FuO+8q80/pe/w=; b=mBRh/vx5ynq0KwHfNxYPg2Y2l9dVzjWiKB/oTbDFLQ780IRojvYsCZAb3Xr98EJvtw Ev9N02TiwiF80vLv8AiQ== Received: by 10.223.24.92 with SMTP id u28mr7917994fab.148.1310883255115; Sat, 16 Jul 2011 23:14:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.159.138 with HTTP; Sat, 16 Jul 2011 23:13:55 -0700 (PDT) In-Reply-To: <29DB7C69C7E7542CF7D88432@PST.JCK.COM> References: <29DB7C69C7E7542CF7D88432@PST.JCK.COM> From: "Aharon (Vladimir) Lanin" Date: Sun, 17 Jul 2011 09:13:55 +0300 Message-ID: To: John C Klensin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Charles Lindsey , IMA Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 06:14:19 -0000 > But mailto:pl.EGROEG.jennings@a-well-known-bank.com=C2=A0is an IRI, > so it should be covered by the document being discussed Well, actually, I don't think that the specifics proposed in PRI #185 cover all possible IRIs; it's more focused on the IRIs containing a path. I don't think that the syntax given there covers the mailto: IRI because of the @. It should be trivial to extend the syntax to cover email addresses both with and without the mailto:. > and the solutions being discussed avoid that aspect of the problem. Not sure what you mean. > There is one way to make this really simple and globally > consistent and that is to treat the "@" (for email addresses) > and "." label separator for domain names as absolute delimiters. Not sure what you mean by absolute delimiters, but the proposal is indeed, after identifying an IRI, to treat its "field separators" (e.g. the dots in the domain name, the slash in the path, etc.) as strongly LTR instead of neutral, and the IRI as a whole as LTR. That means that the components of the IRI are ordered consistently LTR, while usual UBA rules are applied withing a component. > That makes > jennings@a-well-known-bank.com.GEORGE.pl > display is as either > jennings@a-well-known-bank.com.GEORGE.pl or > jennings@a-well-known-bank.com.EGROEG.pl > but is the end of the high-risk cases. It's the latter. GEORGE is always disdplayed as EGROEG. > Unfortunately, it also prohibits any sort of localized display > decisions. Although it is not the preferred option, the proposal also discusses the possibility of sometimes ordering IRI components RTL. The two possibilities mentioned are either to make the IRI come out RTL when it is in an RTL context, or to make it come out RTL when it contains RTL characters, regardless of context. They want feedback on whether people would want that, despite the problems. Please see there. > unless someone managed a clear and 100% accurate way to distinguish > various pieces of protocol from running text (not just clever > heuristics), there will be periodic dramatic failures. There is no way to achieve 100%, and PRI #185 acknowledges that and does not strive for 100%. On Fri, Jul 15, 2011 at 8:05 PM, John C Klensin wrote: > > > --On Friday, July 15, 2011 17:09 +0100 Charles Lindsey > wrote: > > > On Thu, 14 Jul 2011 22:38:04 +0100, Shawn Steele > > wrote: > > > >> But mailto:pl.EGROEG.jennings@a-well-known-bank.com is an > >> IRI, so it =C2=A0 should be covered by the document being > >> discussed, and the solutions =C2=A0 being discussed avoid that > >> aspect of the problem. > >> > >> W/o the mailto: it's not really an IRI, though the same > >> solution could =C2=A0 be applied. > > > > I think that is the clue to the matter. Whatever happens to > > IRI ordering and (perhaps separately) to email-address > > ordering, there should be an invariance rule which states that > > whatever exists to the right of any "mailto:" should always be > > a valid email-address (obviously, ignoring any fancy flags at > > the end of the mailto for setting subjects, etc). > > Charles (and others), > > There is one way to make this really simple and globally > consistent and that is to treat the "@" (for email addresses) > and "." label separator for domain names as absolute delimiters. > That makes > =C2=A0 =C2=A0jennings@a-well-known-bank.com.GEORGE.pl > display is as either > =C2=A0 jennings@a-well-known-bank.com.GEORGE.pl =C2=A0 or > =C2=A0 jennings@a-well-known-bank.com.EGROEG.pl > but is the end of the high-risk cases. > > Unfortunately, it also prohibits any sort of localized display > decisions. =C2=A0That might be a fine idea for those of us who use > Latin script in a predictable way, but it just won't happen in > some local contexts: if we (or Unicode) say something that > sounds culturally inappropriate or severely surprising to users, > it will be ignored by at least some implementers. =C2=A0Worse, unless > someone managed a clear and 100% accurate way to distinguish > various pieces of protocol from running text (not just clever > heuristics), there will be periodic dramatic failures. > Consider, for example, the use of > "joe at example-dot-com" to discourage address harvesting. > Whether it is actually good at that or not, it would very > effectively defeat any sort of rendering system that depends on > "@" to identify an email address in order to handle those > addresses in a special way. =C2=A0 In retrospect and in a more > perfect world, the decision to not require special introducer > and terminator characters for URIs and then to get specific code > points assigned by Unicode that were not to be used for anything > else were probably mistakes. =C2=A0But we are stuck with them. > > =C2=A0 =C2=A0john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From aharon@google.com Sat Jul 16 23:35:37 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 7570421F86A1 for ; Sat, 16 Jul 2011 23:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.032 X-Spam-Level: X-Spam-Status: No, score=-107.032 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tz8eGbp3FI1 for ; Sat, 16 Jul 2011 23:35:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1788E21F8585 for ; Sat, 16 Jul 2011 23:35:35 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p6H6ZZMg024420 for ; Sat, 16 Jul 2011 23:35:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310884535; bh=EGoyK/K52YhiASYUKyDChFa2blE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=bn14ao95hjhLo106vvej2NsnH6BXjx1l/2NARU1kS6t5/YGTzuRVKWVEzfWESp/lx DH7meads3y5COF6Td4pSg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=nMgHxQzTFLj5P1M/fvhGgRyLauZkxt071mO1hSmtzRo1TDinzeqs2RPvCuEDzHS2D gwIfsrZm1V28+48L4XIbA== Received: from fxg11 (fxg11.prod.google.com [10.184.7.11]) by hpaq11.eem.corp.google.com with ESMTP id p6H6ZYCp025070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 16 Jul 2011 23:35:34 -0700 Received: by fxg11 with SMTP id 11so4896240fxg.6 for ; Sat, 16 Jul 2011 23:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=w3ySrONjKVIdviVWxkN3Z1cCxauu7Kbtse3MCkiFBIg=; b=e33+pRchAnlhUv+yD1gLRcWhEtB5oU0TV0E0YljdNd7uUxxljoOcTwCRgQUfXCI6FH QN/et4Hsqs6xvsnLdCNQ== Received: by 10.223.143.17 with SMTP id s17mr8053345fau.34.1310884533176; Sat, 16 Jul 2011 23:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.159.138 with HTTP; Sat, 16 Jul 2011 23:35:13 -0700 (PDT) In-Reply-To: References: <4E1EEFFA.1080007@gulbrandsen.priv.no> From: "Aharon (Vladimir) Lanin" Date: Sun, 17 Jul 2011 09:35:13 +0300 Message-ID: To: John C Klensin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 06:35:37 -0000 > (1) Neither the IDNA2008 Standards nor the EMA work take any > position on how domain names or email addresses (including but > not limited to strings that would invoke the various Bidi rules) > are presented to users or provided by them. =C2=A0 So the > suppositions that lead to a display of > "pl.EGROEG.jennings@a-well-known-bank.com" may be correct, or > not, but the IETF specs don't have an opinion on the matter. I am not suggesting that they should. I was just bringing a related matter to the attention of the people on this list. The fact is that your garden-variety mailer UI applies the UBA to email addresses without treating them differently from plain text. > (2) While many of those involved are not aware that they are > making the assumption and understand its implications even less, > many folks around ICANN are assuming that FQDNs will be script > homogeneous and directionality-property homogeneousl (maybe even > language-homogeneous, but no one really knows what that means). > They also assume that those homogeneity rules can and will be > enforced, either by DNS software (pretty much impossible) or by > administrative mechanisms (probably possible only if a series of > fairly tough conditions exist administratively). I personally heartily wish that this were true, but don't put much faith in it. That's why I think that a UBA change that would prevent bidi-itis in email addresses would be very significant. On Thu, Jul 14, 2011 at 10:31 PM, John C Klensin wrote: > Aharon, > > There are a number of different issues associated with this. =C2=A0It > is probably useful to try to separate out at least three of them. > > (1) Neither the IDNA2008 Standards nor the EMA work take any > position on how domain names or email addresses (including but > not limited to strings that would invoke the various Bidi rules) > are presented to users or provided by them. =C2=A0 So the > suppositions that lead to a display of > "pl.EGROEG.jennings@a-well-known-bank.com" may be correct, or > not, but the IETF specs don't have an opinion on the matter. > For the record, they also don't formally have an opinion as to > whether, in parts of the world in which family names are > typically written before personal names, etc., the string that > SMTP sees as joe.bloggs@mail.example.com is displayed as > > =C2=A0joe.bloggs@mail.example.com > =C2=A0mail.example.com@joe.bloggs > =C2=A0mail.example.com@bloggs.joe > =C2=A0 or even > =C2=A0com.example.mail##bloggs.joe > =C2=A0 or some other variation > > (where "##" is some relatively arbitrary delimiter). =C2=A0That > flexibility is even true when the local-part and domain-part > consist exclusively of ASCII characters. =C2=A0The fact that we don't > see those variations very often depends more on designers > exercising what they consider sensible behavior than on anything > that the standards or working drafts do or do not require. > > > (2) While many of those involved are not aware that they are > making the assumption and understand its implications even less, > many folks around ICANN are assuming that FQDNs will be script > homogeneous and directionality-property homogeneousl (maybe even > language-homogeneous, but no one really knows what that means). > They also assume that those homogeneity rules can and will be > enforced, either by DNS software (pretty much impossible) or by > administrative mechanisms (probably possible only if a series of > fairly tough conditions exist administratively). =C2=A0If one does > believe that myth, a-well-known-bank.com.GEORGE.pl is > essentially not possible. =C2=A0One could need to have either > =C2=A0a-well-known-bank.com.george.pl =C2=A0 or > =C2=A0A-WELL-KNOWN-BANK.COM.GEORGE.PL > and the more mixed cases are, in the same myth, presumably > expected to atrophy. > > > (3) Many SDOs, including the IETF, have taken the position that > having other SDOs develop modifications, interpretations, or > even extensions to standards developed by the first body is a > really bad idea (see RFC 5704 for a discussion about a topic > unrelated to i18n). =C2=A0If this piece's interactions with IRIs and > UTR46 are examples, it has apparently become the norm in the > relatioship between UTC and the IETF. =C2=A0Perhaps that is A Good > Thing but, if some parties rely only on the IETF specs and > others rely on some combination or a "pick what is convenient" > model, the opportunities for interoperability problems, user > astonishment, and other difficulties are considerable. > > best, > =C2=A0 =C2=A0 john > > > > --On Thursday, July 14, 2011 17:18 +0300 "Aharon (Vladimir) > Lanin" wrote: > >> It's not an important point. I guess email addresses are just >> so deceptively simple. In RTL, >> jennings@a-well-known-bank.com.GEORGE.pl (where uppercase >> Latin letters stand for RTL characters) is displayed as >> >> pl.EGROEG.jennings@a-well-known-bank.com >> >> A large number of users will think that they are talking to >> someone at a-well-known-bank.com. >> >> Aharon >> >> On Thu, Jul 14, 2011 at 4:32 PM, Arnt Gulbrandsen >> wrote: >> >>> On 07/14/2011 03:08 PM, Aharon (Vladimir) Lanin wrote: >>> >>>> Just in case this is news for anyone here, the Unicode >>>> Technical Committee is considering PRI #185: "Revision of >>>> UBA for improved display of URL/IRIs". (UBA stands for >>>> Unicode Bidirectional Algorithm.) The intent of the proposal >>>> is to improve the display of bidirectional IRIs. >>>> >>>> The same problems (if not worse) that exist for bidi IRIs >>>> also exist for bidi email addresses. >>>> >>> >>> Why would the problems be worse for email? >>> >>> Bad, yes, no disagreement at all. My question is specifically >>> about the "if not worse" bit. >>> >>> >>> =C2=A0I have submitted a comment on PRI #185 >>>> suggesting that it be extended to cover email addresses. >>>> >>> >>> Excellent. >>> >>> Arnt >>> ______________________________**_________________ >>> IMA mailing list >>> IMA@ietf.org >>> https://www.ietf.org/mailman/**listinfo/ima>> org/mailman/listinfo/ima> >>> > > > > > From jyee@afilias.info Mon Jul 18 16:19:25 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 B1E5621F89CC for ; Mon, 18 Jul 2011 16:19:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBDYysmlVDKv for ; Mon, 18 Jul 2011 16:19:24 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0C21F88DC for ; Mon, 18 Jul 2011 16:19:24 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Qix5w-0008FS-3V for ima@ietf.org; Mon, 18 Jul 2011 23:19:24 +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 1Qix5v-0008WF-9U for ima@ietf.org; Mon, 18 Jul 2011 23:19:24 +0000 Received: by ywa6 with SMTP id 6so1576629ywa.9 for ; Mon, 18 Jul 2011 16:19:23 -0700 (PDT) Received: by 10.236.155.41 with SMTP id i29mr4447735yhk.1.1311031163414; Mon, 18 Jul 2011 16:19:23 -0700 (PDT) Received: from [192.168.0.106] (75-119-252-185.dsl.teksavvy.com [75.119.252.185]) by mx.google.com with ESMTPS id f4sm3135210yhn.13.2011.07.18.16.19.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 16:19:22 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 19:19:20 -0400 To: "ima@ietf.org WG" Message-Id: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] Summary of issues and agenda for Quebec meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:19:25 -0000 Hi all, Below is summary of issues the WG needs to address, and they will be = agenda item for the Quebec meeting. I will update the agenda after this = email. If anything missing, please reply to this thread and I will = update as soon as possible. (1) Allowing 8-bit or not to Message-ID (also IN-REPLY-TO field & = REFERENCES field) in RFC5335bis Recently the WG made a consensus to allow 8-bit in trace fields. = Message-ID is in similar situation that it value contain local value and = domains. The recent revision (-11) of RFC5335bis ABNF allows 8-bit in = domain part. =20 The WG need to review and determine whether Message-ID allows 8-bit = fully, partially, or not allowing 8-bit. And what's the impact (for = example: mixed of non UTF8 capable mail client with UTF8 capable = pop/imap server) of each option. (2) ABNF in popimap-downgrade-display section 3 In IETF Beijing the WG agreed to adopt group syntax. In the revision = (-02) of popimap-downgrade-display, the ABNF syntax extends to "from", = "resent-from", "sender" and "resent-sender" to allow group. The syntax = is not yet complete. More notes documented in the draft's section 3. Direct copy over for = quick read: =09 1. RFC 5322 does not allow group syntax in =46rom and Sender header fields. Existing MUAs may become very confused when they see group syntax in originator fields. 2. Use of group syntax in this way will essentially make it impossible to reply to a message. 3. "Reply-To:" header field allows the group syntax in [RFC5322]. Is it correct ? 4. The ABNF syntax here is not yet complete. 5. Should the document explicitly recommend the use of comments, possibly with encoded words, to document the original non-ASCII mailboxes? Other items that are not issues but need review from WG All recent active drafts - RFC5336bis-11 (SMTP Extension) - RFC5335bis-11 (Message Headers) - RFC5337bis-03 (DSN) - RFC5721bis-02 (POP3) - RFC5738bis-01 (IMAP) - draft-eai-popimap-downgrade-02 Review of the latest RFC5336bis, any issues before last call? The current draft agenda is available at = http://tools.ietf.org/wg/eai/agenda?item=3Dagenda81.html Will update the agenda text as soon as possible Thanks Joseph From trac+eai@trac.tools.ietf.org Mon Jul 18 11:59: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 AC66121F8BB2 for ; Mon, 18 Jul 2011 11:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DykYwzqmIRdh for ; Mon, 18 Jul 2011 11:59:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 57C5221F8B66 for ; Mon, 18 Jul 2011 11:59:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qit2B-0001lT-Ml; Mon, 18 Jul 2011 11:59:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Mon, 18 Jul 2011 18:59:15 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/8#comment:2 Message-ID: <070.8299c788437880907ffdcea0d7e62153@trac.tools.ietf.org> References: <061.7ec4029a1a8bfcd35fb70a71da9f27ba@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <061.7ec4029a1a8bfcd35fb70a71da9f27ba@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac+eai@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 18 Jul 2011 18:07:14 -0700 Cc: ima@ietf.org Subject: Re: [EAI] [eai] #8: POLL: new text in Abstract section in RFC5335bis to replace the original X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:59:16 -0000 #8: POLL: new text in Abstract section in RFC5335bis to replace the original Changes (by jyee@…): * status: new => closed * resolution: => fixed Comment: New text in version -11 -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: closed Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: poll | ----------------------------------+----------------------------------------- Ticket URL: eai From trac+eai@trac.tools.ietf.org Mon Jul 18 11:59:38 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 BCBCC21F8BAF for ; Mon, 18 Jul 2011 11:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WBKcOlLfj3a for ; Mon, 18 Jul 2011 11:59:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 61FCA21F8BAD for ; Mon, 18 Jul 2011 11:59:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qit2Y-0001lp-BL; Mon, 18 Jul 2011 11:59:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Mon, 18 Jul 2011 18:59:38 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/9#comment:1 Message-ID: <070.cf6fba9e05431882f2bf5e63a9f295de@trac.tools.ietf.org> References: <061.f6dd7ddac0864b015aa8d8a42d505635@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <061.f6dd7ddac0864b015aa8d8a42d505635@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac+eai@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 18 Jul 2011 18:07:14 -0700 Cc: ima@ietf.org Subject: Re: [EAI] [eai] #9: POLL: new text in Introduction in RFC5335bis to replace the original X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:59:38 -0000 #9: POLL: new text in Introduction in RFC5335bis to replace the original Changes (by jyee@…): * status: new => closed * resolution: => fixed Comment: New text in version -11 -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: closed Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: poll | ----------------------------------+----------------------------------------- Ticket URL: eai From trac+eai@trac.tools.ietf.org Mon Jul 18 11:59: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 9B4FD21F8BB4 for ; Mon, 18 Jul 2011 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bc695jZEh6O for ; Mon, 18 Jul 2011 11:59:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 20D3821F8BAD for ; Mon, 18 Jul 2011 11:59:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qit2m-0001mJ-2p; Mon, 18 Jul 2011 11:59:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eai issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jyee@ca.afilias.info X-Trac-Project: eai Date: Mon, 18 Jul 2011 18:59:52 -0000 X-URL: http://tools.ietf.org/wg/eai/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eai/trac/ticket/10#comment:1 Message-ID: <070.7379f7583694e3ecb536ea65b2df27ea@trac.tools.ietf.org> References: <061.b8d85652120b4a3876444913cb96953e@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <061.b8d85652120b4a3876444913cb96953e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jyee@ca.afilias.info, ima@ietf.org X-SA-Exim-Mail-From: trac+eai@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 18 Jul 2011 18:07:14 -0700 Cc: ima@ietf.org Subject: Re: [EAI] [eai] #10: POLL: new text to insert as subsection (1.x) under section Introduction X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ima@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:59:56 -0000 #10: POLL: new text to insert as subsection (1.x) under section Introduction Changes (by jyee@…): * status: new => closed * resolution: => fixed Comment: New text in version -11 -- ----------------------------------+----------------------------------------- Reporter: jyee@… | Owner: Type: state | Status: closed Priority: major | Milestone: Component: rfc5335bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: poll | ----------------------------------+----------------------------------------- Ticket URL: eai From ned+ima@mrochek.com Mon Jul 18 19:40: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 D07C021F87C3 for ; Mon, 18 Jul 2011 19:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOI2qcpYDXKo for ; Mon, 18 Jul 2011 19:40:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 52AF221F8788 for ; Mon, 18 Jul 2011 19:40:09 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O3SYPC6LM800WTSU@mauve.mrochek.com> for ima@ietf.org; Mon, 18 Jul 2011 19:39:22 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O3R1W8PRSW00RCTX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 18 Jul 2011 19:39:17 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01O3SYP91X4200RCTX@mauve.mrochek.com> Date: Mon, 18 Jul 2011 19:35:03 -0700 (PDT) In-reply-to: "Your message dated Mon, 18 Jul 2011 19:19:20 -0400" <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> To: Joseph Yee DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311043146; bh=kWN1dq4MOvau95J9cOsfiMqp/JvqCy7PUsF7RNWfdfk=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=l6PWewxL6Q/byaIuCErif7nfbOYSnwTYqW4ez3fBzFg4YsqrD9WK4Ivclj5ZhF9Ge UjXRnV4m9H52YVv+V6YBZJguutyskEhUFJozxGgMh6LueC7s1nc7bFOVl/EKUDSBru GNbzouzvfKHXBpuCnxM5zhkv8h8JBkvNIoJ76Iws= Cc: "ima@ietf.org WG" Subject: Re: [EAI] Summary of issues and agenda for Quebec meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 02:40:13 -0000 > Hi all, > Below is summary of issues the WG needs to address, and they will be agenda > item for the Quebec meeting. I will update the agenda after this email. If > anything missing, please reply to this thread and I will update as soon as > possible. > (1) Allowing 8-bit or not to Message-ID (also IN-REPLY-TO field & REFERENCES > field) in RFC5335bis > Recently the WG made a consensus to allow 8-bit in trace fields. Message-ID > is in similar situation that it value contain local value and domains. The > recent revision (-11) of RFC5335bis ABNF allows 8-bit in domain part. Not exactly. The latest revision does redefine dpart so 8-bit is allowed in domains, but it also redefines message id syntax to use a new itext rule that doesn't allow 8-bit. So the domains in addresses can contain 8-bit but the domains in message-ids do not. My personal preference is to simply eliminate the redefinition ABNF and allow 8-bit in message-ids, but OTOH the ABNF involved isn't especially complex or difficult to understand. Ned From duerst@it.aoyama.ac.jp Mon Jul 18 21:30: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 443CA21F86CA for ; Mon, 18 Jul 2011 21:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.739 X-Spam-Level: X-Spam-Status: No, score=-99.739 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm-hrG+M6PQf for ; Mon, 18 Jul 2011 21:30:50 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1E921F862F for ; Mon, 18 Jul 2011 21:30:47 -0700 (PDT) Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6J4Uehx026967 for ; Tue, 19 Jul 2011 13:30:41 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 166a_243d_dbcfc61c_b1bf_11e0_9d2e_001d096c5b62; Tue, 19 Jul 2011 13:30:40 +0900 Received: from [IPv6:::1] ([133.2.210.5]:32801) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jul 2011 13:30:41 +0900 Message-ID: <4E250842.8060305@it.aoyama.ac.jp> Date: Tue, 19 Jul 2011 13:29:54 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 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: Joseph Yee References: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> In-Reply-To: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org WG" Subject: Re: [EAI] Summary of issues and agenda for Quebec meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 04:30:51 -0000 On 2011/07/19 8:19, Joseph Yee wrote: > Hi all, > > Below is summary of issues the WG needs to address, and they will be agenda item for the Quebec meeting. I will update the agenda after this email. If anything missing, please reply to this thread and I will update as soon as possible. > > (1) Allowing 8-bit or not to Message-ID (also IN-REPLY-TO field& REFERENCES field) in RFC5335bis > > Recently the WG made a consensus to allow 8-bit in trace fields. Message-ID is in similar situation that it value contain local value and domains. The recent revision (-11) of RFC5335bis ABNF allows 8-bit in domain part. > > The WG need to review and determine whether Message-ID allows 8-bit fully, partially, or not allowing 8-bit. And what's the impact (for example: mixed of non UTF8 capable mail client with UTF8 capable pop/imap server) of each option. It says '8-bit' here, and not 'UTF-8'. Does this mean that any kind of 8-bit is okay? Does that mean that 'UTF-8' is preferred, but not required? Or what else? I'd of course personally prefer "UTF-8 only". Regards, Martin. From jyee@afilias.info Tue Jul 19 06:56: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 9AA4D21F86A0 for ; Tue, 19 Jul 2011 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uXAVqzzp4FY for ; Tue, 19 Jul 2011 06:56:50 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id B112421F8698 for ; Tue, 19 Jul 2011 06:56:50 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QjAn4-0006FN-3m for ima@ietf.org; Tue, 19 Jul 2011 13:56:50 +0000 Received: from mail-qw0-f50.google.com ([209.85.216.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QjAn3-0000XV-9R for ima@ietf.org; Tue, 19 Jul 2011 13:56:50 +0000 Received: by qwe5 with SMTP id 5so2211939qwe.9 for ; Tue, 19 Jul 2011 06:56:49 -0700 (PDT) Received: by 10.224.179.12 with SMTP id bo12mr4137115qab.81.1311083809345; Tue, 19 Jul 2011 06:56:49 -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 o4sm3132893qct.13.2011.07.19.06.56.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 06:56:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <01O3SYP91X4200RCTX@mauve.mrochek.com> Date: Tue, 19 Jul 2011 09:56:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0EFEB4DA-59BE-4BB2-82E2-ADDB68FFA2A3@afilias.info> References: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> <01O3SYP91X4200RCTX@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) Cc: "ima@ietf.org WG" Subject: Re: [EAI] Summary of issues and agenda for Quebec meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:56:51 -0000 Thanks for clarifying and correcting the issue. Joseph On 2011-07-18, at 10:35 PM, Ned Freed wrote: >> Hi all, >=20 >> Below is summary of issues the WG needs to address, and they will be = agenda >> item for the Quebec meeting. I will update the agenda after this = email. If >> anything missing, please reply to this thread and I will update as = soon as >> possible. >=20 >> (1) Allowing 8-bit or not to Message-ID (also IN-REPLY-TO field & = REFERENCES >> field) in RFC5335bis >=20 >> Recently the WG made a consensus to allow 8-bit in trace fields. = Message-ID >> is in similar situation that it value contain local value and = domains. The >> recent revision (-11) of RFC5335bis ABNF allows 8-bit in domain part. >=20 > Not exactly. The latest revision does redefine dpart so 8-bit is = allowed > in domains, but it also redefines message id syntax to use a new itext > rule that doesn't allow 8-bit. So the domains in addresses can contain > 8-bit but the domains in message-ids do not. >=20 > My personal preference is to simply eliminate the redefinition ABNF = and allow > 8-bit in message-ids, but OTOH the ABNF involved isn't especially = complex or > difficult to understand. >=20 > Ned From jyee@afilias.info Tue Jul 19 06:58: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 1AA0321F86AB for ; Tue, 19 Jul 2011 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmstRqJHmHRt for ; Tue, 19 Jul 2011 06:58:50 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 919BE21F873F for ; Tue, 19 Jul 2011 06:58:50 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QjAp0-0004LQ-72 for ima@ietf.org; Tue, 19 Jul 2011 13:58:50 +0000 Received: from mail-qw0-f50.google.com ([209.85.216.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QjAoz-0000Zm-9T for ima@ietf.org; Tue, 19 Jul 2011 13:58:50 +0000 Received: by qwe5 with SMTP id 5so2212921qwe.9 for ; Tue, 19 Jul 2011 06:58:49 -0700 (PDT) Received: by 10.229.51.67 with SMTP id c3mr6044150qcg.12.1311083929279; Tue, 19 Jul 2011 06:58:49 -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 b6sm3088385qcb.35.2011.07.19.06.58.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 06:58:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joseph Yee In-Reply-To: <4E250842.8060305@it.aoyama.ac.jp> Date: Tue, 19 Jul 2011 09:58:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> <4E250842.8060305@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1084) Cc: "ima@ietf.org WG" Subject: Re: [EAI] Summary of issues and agenda for Quebec meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:58:51 -0000 On 2011-07-19, at 12:29 AM, Martin J. D=FCrst wrote: >=20 >=20 > On 2011/07/19 8:19, Joseph Yee wrote: >> Hi all, >>=20 >> Below is summary of issues the WG needs to address, and they will be = agenda item for the Quebec meeting. I will update the agenda after this = email. If anything missing, please reply to this thread and I will = update as soon as possible. >>=20 >> (1) Allowing 8-bit or not to Message-ID (also IN-REPLY-TO field& = REFERENCES field) in RFC5335bis >>=20 >> Recently the WG made a consensus to allow 8-bit in trace fields. = Message-ID is in similar situation that it value contain local value and = domains. The recent revision (-11) of RFC5335bis ABNF allows 8-bit in = domain part. >>=20 >> The WG need to review and determine whether Message-ID allows 8-bit = fully, partially, or not allowing 8-bit. And what's the impact (for = example: mixed of non UTF8 capable mail client with UTF8 capable = pop/imap server) of each option. >=20 > It says '8-bit' here, and not 'UTF-8'. Does this mean that any kind of = 8-bit is okay? Does that mean that 'UTF-8' is preferred, but not = required? Or what else? >=20 > I'd of course personally prefer "UTF-8 only". >=20 Hi Martin, Sorry I'm a bit lax on terminology. It is "UTF-8 only" when I'm = referring "8-bit" above. Joseph > Regards, Martin. From chris.newman@oracle.com Mon Jul 25 09:09: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 2277321F861A for ; Mon, 25 Jul 2011 09:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTuOaSufRTWB for ; Mon, 25 Jul 2011 09:09:14 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1E78F21F85F5 for ; Mon, 25 Jul 2011 07:16:46 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6PEGjkO012094 for ; Mon, 25 Jul 2011 14:16:45 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL, v2.4) with ESMTP id p6PEGiha031125 for ; Mon, 25 Jul 2011 14:16:44 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_6JKL8bneiHTH3Vhy1ptAxQ)" Received: from [10.159.40.53] (dhcp-rmdc-twvpn-2-vpnpool-10-159-40-53.vpn.oracle.com [10.159.40.53]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LOW00F1X7NTZ700@gotmail.us.oracle.com> for ima@ietf.org; Mon, 25 Jul 2011 07:16:43 -0700 (PDT) Date: Mon, 25 Jul 2011 10:16:41 -0400 From: Chris Newman To: ima@ietf.org Message-id: <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> In-reply-to: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-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: Mon, 25 Jul 2011 16:09:18 -0000 --Boundary_(ID_6JKL8bneiHTH3Vhy1ptAxQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline --On July 7, 2011 18:23:52 -0700 internet-drafts@ietf.org wrote: > Title : SMTP Extension for Internationalized Email > Author(s) : Jiankang Yao > W. Mao > Filename : draft-ietf-eai-rfc5336bis-11.txt > Pages : 20 > Date : 2011-07-07 I've done an extensive "clean slate" review on this document. I found a number of issues I consider largely editorial and some I consider substantive (in that the decision has technical impact). I've attached my full review with editorial notes embedded in the text. Here are the substantive issues: 1. Somewhere this needs to say: If a server advertises both UTF8SMTPbis and DSN, then that server MUST support UTF-8 in the ORCPT parameter. This also has ABNF impact. We need to add: ehlo-param =/ UTF8-non-ascii to allow UTF-8 in mail, rcpt and data parameters. 2. I would prefer this ABNF rule be removed: quoted-pairSMTP =/ %d92 UTF8-non-ascii ; extend the definition of quoted-pairSMTP in RFC5321, section 4.1.2 This is an unnecessary change and makes 5336bis quoting even less consistent with 5335bis quoting. Conservative generators should never emit \ followed by anything other than \ or double-quote anyway, so adding complexity to explicitly allow generation of useless forms is not helpful. 3. I suggest adding a statement to the end of section 3.5: SMTP servers are encouraged to detect that recipients can not accept internationalized email headers and return an error earlier in the transaction whenever possible. 4. In section 3.5, I suggest adding an enhanced status code for the case where a U-label can not be converted to an A-label. This is semantically quite different from X.6.7 and X.6.9 5. Section 3.7 says the A-label form SHOULD be used. While I don't object to that for relay, I believe it should also say that submission clients MAY use U-labels. 6. Section 3.7.3: > If the messages that include trace fields are sent by an UTF8SMTPbis- > aware SMTP client or relay server with the UTF8SMTPbis parameter at > MAIL commands, trace field values SHOULD use the U-label form for the > internationalized domain name. This wording suggests servers need to convert from A-label to U-label if a previous server did the wrong thing. I don't think that's reasonable. I suggest rewording: When an SMTP server adds a trace field to a message that was or will be transmitted with the UTF8SMTPbis MAIL FROM parameter, that server SHOULD use the U-label form for internationalized domain names in that new trace field. 7. Section 3.7.3 needs to say (given the current ABNF): The Atom form of the ID clause can contain non-ASCII characters. --Boundary_(ID_6JKL8bneiHTH3Vhy1ptAxQ) Content-type: text/plain; CHARSET=US-ASCII; name=draft-ietf-eai-rfc5336bis-11.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-eai-rfc5336bis-11.txt; size=47147 ***7 issues Network Working Group J. Yao Internet-Draft W. Mao Obsoletes: 5336 (if approved) CNNIC Intended status: Standards Track July 7, 2011 Expires: January 8, 2012 SMTP Extension for Internationalized Email draft-ietf-eai-rfc5336bis-11.txt Abstract This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. 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 January 8, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Yao & Mao Expires January 8, 2012 [Page 1] Internet-Draft EAI SMTP Extension July 2011 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. Yao & Mao Expires January 8, 2012 [Page 2] Internet-Draft EAI SMTP Extension July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Role of This Specification . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Updates to Other Specifications . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 3.1. Framework for the Internationalization Extension . . . . . 5 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 16 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 17 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 18 7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18 7.13. draft-ietf-eai-rfc5336bis: Version 11 . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Yao & Mao Expires January 8, 2012 [Page 3] Internet-Draft EAI SMTP Extension July 2011 1. Introduction The Simple Mail Transfer Protocol [RFC5321] provides a negotiation mechanism about service extension by which SMTP clients can discover SMTP server capabilities and make decisions for further processing. This document uses this mechanism and specifies an SMTP extension to permit internationalized email addresses (see section 1.2) in the SMTP envelope, and Unicode characters encoded in UTF-8 [RFC3629] in the headers. ***Suggest alternate text: The document defines a Simple Mail Transfer Protocol [RFC5321] extension so servers can advertise the ability to accept and process internationalized email addresses (see section 1.2), and internationalized email headers [RFC5335bis]. ... An extended overview of the extension model for internationalized email addresses and the email header appears in [RFC4952bis], referred to as "the framework document" or just as "framework" elsewhere in this specification. [[anchor1: Note in Draft and to RFC Editor: The keyword represented in this document by "UTF8SMTPbis" (and in the XML source byUTF8SMTPbis) 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. This paragraph should be removed before RFC publication.]] 1.1. Role of This Specification The framework document [RFC4952bis] specifies the requirements for, and describes components of, full internationalization of electronic mail. A thorough understanding of the information in that document and in the base Internet email specifications [RFC5321] [RFC5322] is necessary to understand and implement this specification. This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension for internationalized email address transport delivery. *** this entire section is redundant with previous section, suggest deleting it. 1.2. Terminology 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 RFC 2119 [RFC2119]. The terms "UTF-8 string" or "UTF-8 character" are used to refer to Unicode characters encoded in UTF-8. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "UTF8SMTPbis", "internationalized message", and "message" are used in this document according to the definitions in the framework document. Yao & Mao Expires January 8, 2012 [Page 4] Internet-Draft EAI SMTP Extension July 2011 Non-ASCII characters or strings referred in this document MUST be expressed in UTF-8, a standard Unicode Encoding Form. This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some basic rules in this document can be found from [RFC5234] or [RFC5321] under the same names. 1.3. Updates to Other Specifications This specification extends some syntax rules defined in RFC 5321 and permits internationalized email address in the envelope, but it does *** s/address/addresses/ not modify RFC 5321. It permits data formats defined in [RFC5335bis], but it does not modify RFC 5322. It does require that the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis- aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis- aware SMTP client, but it does not modify the 8BITMIME specification in any way. 2. Overview of Operation This specification describes an optional extension to the email transport mechanism that permits non-ASCII characters in both the envelope and header fields of messages, which are encoded in UTF-8. The extension is identified with the token "UTF8SMTPbis". The internationalized email headers specification [RFC5335bis] provides the details of email header features enabled by this extension *** redundant section, suggest deleting this 3. Mail Transport-Level Protocol 3.1. Framework for the Internationalization Extension The following service extension is defined: 1. The name of the SMTP service extension is "Internationalized Email". 2. The EHLO keyword value associated with this extension is "UTF8SMTPbis". 3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword. The UTF8SMTPbis-aware SMTP client MUST ignore any parameters if they appear for this keyword; that is, the UTF8SMTPbis-aware SMTP client MUST behave as if the parameters do not appear. If an SMTP server includes UTF8SMTPbis in its EHLO response, it MUST be fully compliant with this version of this specification. Yao & Mao Expires January 8, 2012 [Page 5] Internet-Draft EAI SMTP Extension July 2011 4. One OPTIONAL parameter "UTF8SMTPbis" is added to the MAIL command. The parameter has no value. If this parameter is set in the MAIL command, it indicates that the SMTP client is UTF8SMTPbis-aware and asserts that the envelope includes the non-ASCII address or the message being sent is internationalized message or the message being sent needs the UTF8SMTPbis support. 5. The maximum length of a MAIL command line is increased by 13 characters by the possible addition of the UTF8SMTPbis parameter. [[anchor6: RFC Editor: the number '13' will be replaced by the new number (2 spaces + length of the new keyword supposed to replace "UTF8SMTPbis").]] 6. One OPTIONAL parameter "UTF8SMTPbis" is added to the VRFY and EXPN commands. The parameter UTF8SMTPbis has no value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands. 7. No additional SMTP verbs are defined by this extension. 8. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152]. 9. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses). 10. The mail message body is extended as specified in [RFC5335bis]. 11. The UTF8SMTPbis extension is valid on the submission port [RFC4409], and can be used with LMTP [RFC2033]. 3.2. The UTF8SMTPbis Extension An SMTP server that announces this UTF8SMTPbis extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a can appear. Although the characters in the are permitted to contain non-ASCII characters, actual parsing of the , and the delimiters used, are unchanged from the base email specification [RFC5321]. Any domain names to be looked up in the DNS MUST allow for [RFC5890] behavior. When doing lookups, the UTF8SMTPbis-aware SMTP client or server MUST either use a Unicode aware DNS library, or transform it to A-label defined in [RFC5890]. s/it to A-label defined/the domain name to an A-label as described/ An SMTP client that receives the UTF8SMTPbis extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form. It MAY send a UTF-8 header [RFC5335bis] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. The presence of the UTF8SMTPbis extension does not change RFC 5321 server relaying behaviors. Yao & Mao Expires January 8, 2012 [Page 6] Internet-Draft EAI SMTP Extension July 2011 If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, the UTF8SMTPbis-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in [RFC5335bis] at any level within its MIME structure [RFC2045] and [RFC2047]. (For this paragraph, the internationalized domain name in the form of A-labels as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) Instead, if an UTF8SMTPbis-aware SMTP client (UTF8SMTPbis-aware SMTP sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, it MUST make one of the following three choices and the priority order is 1, 2 and 3. 1. It MAY either reject the message during the SMTP transaction or accept the message and then generate and transmit a notification of non-deliverability. Such notification MUST be done as specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the internationalized delivery status and disposition notifications specification [RFC5337bis]. 2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a Message Submission Agent ("MSA") [RFC4409] [RFC5598], it may choose its own way to deal with this scenario according to the provisions of [RFC4409] or its future versions. But the detailed specification of this process and its results are outside the scope of this document. 3. It MAY find an alternate route to the destination that permits UTF8SMTPbis. That route MAY be discovered by trying alternate Mail eXchanger (MX) hosts (using preference rules as specified in RFC 5321) or using other means available to the UTF8SMTPbis-aware SMTP client. This document applies when an UTF8SMTPbis-aware SMTP client or server supports the UTF8SMTPbis extension. For all other cases, and for addresses and messages that do not require an UTF8SMTPbis extension, UTF8SMTPbis-aware SMTP clients and servers do not change the behavior specified in [RFC5321]. ***this last paragraph is unnecessary. ****!ORCPT UTF-8 allowed should probably be mentioned here. 3.3. Extended Mailbox Address Syntax RFC 5321, section 4.1.2, defines the syntax of a entirely in terms of ASCII characters. This document extends to add support of non-ASCII characters. The key changes made by this specification include: o In order to update the to support the internationalized email address, the ABNF rule will be imported from RFC 5321 directly, and other related rules are imported from RFC 5321, RFC 5234, RFC 5890 or RFC 5335bis, or are extended in this Yao & Mao Expires January 8, 2012 [Page 7] Internet-Draft EAI SMTP Extension July 2011 document. o Extend the definition of to permit both the RFC 5321 definition and a UTF-8 string in a DNS label that is conforming with IDNA definitions [RFC5890]. o Extend the definition of to permit both the RFC 5321 definition and a UTF-8 string. That string MUST NOT contain any of the ASCII graphics or controls characters. The following ABNF rules will be imported from RFC 5321, section 4.1.2 directly: o o o o o o o The following ABNF rule will be imported from RFC 5335bis, section 4.1 directly: o The following ABNF rule will be imported from RFC 5234, appendix B.1 directly: o The following ABNF rule will be imported from RFC 5890, section 2.3.2.1 directly: o The following rules are extended in ABNF [RFC5234] as follows. sub-domain =/ U-label ; extend the definition of sub-domain in RFC5321, section 4.1.2 atext =/ UTF8-non-ascii ; extend the definition of atext in RFC5321, section 4.1.2 ****! Missing: ehlo-param =/ UTF8-non-ascii quoted-pairSMTP =/ %d92 UTF8-non-ascii ; extend the definition of quoted-pairSMTP in RFC5321, section 4.1.2 ****! unnecessary rule change, suggest removing to avoid escaping multi-byte characters that need no escaping, and to keep symmetry with 5335 ABNF. qtextSMTP =/ UTF8-non-ascii ; extend the definition of qtextSMTP in RFC5321, section 4.1.2 Yao & Mao Expires January 8, 2012 [Page 8] Internet-Draft EAI SMTP Extension July 2011 3.4. MAIL Command Parameter Usage If the envelope or message being sent requires the capabilities of the UTF8SMTPbis extension, the UTF8SMTPbis-aware SMTP client MUST supply the UTF8SMTPbis parameter with the MAIL command. If this parameter is provided, it MUST have no value. If the UTF8SMTPbis- aware SMTP client is aware that neither the envelope nor the message being sent requires any of the UTF8SMTPbis extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command. Because there is no guarantee that a next-hop SMTP server will support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension always carries a risk of transmission failure. In fact, during the early stages of deployment for the UTF8SMTPbis extension, the risk will be quite high. Hence there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting ASCII [ASCII] characters(0x7f and below) as UTF-8 form is that it permits pure-Unicode environments. **** Last sentence isn't useful. Suggest dropping it. This specification does not require that the UTF8SMTPbis-aware SMTP client inspect the message or otherwise go to extraordinary lengths to assure itself whether the UTF8SMTPbis extension is REQUIRED for the particular message. **** Confusing paragraph because it potentially contradicts the MUST above. Suggest dropping it. 3.5. Non-ASCII addresses and Reply-codes An UTF8SMTPbis-aware SMTP client MUST only send an internationalized message to an SMTP server that supports UTF8SMTPbis. If the SMTP server does not support this option, then the UTF8SMTPbis-aware SMTP client has three choices according to section 3.2 of this specification. The three-digit Reply-codes used in this section are based on their meanings as defined in RFC 5321. **** First two paragraphs are redundant with previous material, suggest removal. When messages are rejected because the RCPT command requires an ASCII address, the reply-code 553 is returned with the meaning "mailbox name not allowed". When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". When the UTF8SMTPbis-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.7" [RFC5248] is used, meaning that "non-ASCII addresses not permitted for that sender/recipient". **** reference to [RFC5248] should be replaced with forward reference to IANA considerations section. When messages are rejected for other reasons, the server follows the model of the base email specifications in RFC 5321; this extension does not change those circumstances or reply messages. Yao & Mao Expires January 8, 2012 [Page 9] Internet-Draft EAI SMTP Extension July 2011 If the reply-code is issued after the final "." of the DATA command, the reply-code "554" is used with the meaning "Transaction failed". When the UTF8SMTPbis-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.9" [RFC5248] is used, meaning that "UTF-8 header message can not be transmitted to one or more recipients, so the message MUST be rejected". **** Paragraph doesn't make sense. needs to be re-ordered to explain the error condition first, and then introduce the "554" and "X.6.9" codes. Suggest: If a message is rejected after the final "." of the DATA command because one or more recipient is unable to accept and process a message with internationalized email headers, the reply-code "554" is used. If the UTF8SMTPbis-aware SMTP server supports enhanced mail system status codes [RFC3463], reply code "X.6.9" (see section 4) is used to indicate this condition. ****! Suggest adding: SMTP servers are encouraged to detect that recipients can not accept internationalized email headers and return an error earlier in the transaction whenever possible. ****! Suggest adding a reply code for the case where the U-label can not be converted to an A-label. 3.6. Body Parts and SMTP Extensions The MAIL command parameter UTF8SMTPbis asserts that a message is an internationalized message or the message being sent needs the UTF8SMTPbis support. The message being sent via the MAIL command with the UTF8SMTPbis parameter has still a chance of that the message transmitted is not an internationalized message. An UTF8SMTPbis- aware SMTP client or server that requires accurate knowledge of whether a message is internationalized needs to parse all message header fields and MIME header fields [RFC2045] and [RFC2047] in the message body. However, this specification does not require that the UTF8SMTPbis-aware SMTP client or server inspects the message. **** Redundant with section 3.4, delete previous paragraph. While this specification requires that UTF8SMTPbis-aware SMTP servers support the 8BITMIME extension [RFC6152] to ensure that servers have adequate handling capability for 8-bit data and to avoid a number of complex encoding problems, the use of internationalized email addresses obviously does not require non-ASCII body parts in the MIME message in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with the BODY=8BITMIME parameter [RFC6152] if that is appropriate given the body content or, with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030] and that is appropriate. 3.7. Additional ESMTP Changes and Clarifications The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that, when RFC 5321 specifies a mailbox, this SMTP extension requires UTF-8 form to be used for the entire string; when RFC 5321 specifies a domain name, the name SHOULD be in the form of A-label if this domain name is an internationalized domain name[RFC5890]. ****! SHOULD is reasonable for relay, but with a submission server, I believe clients should be free to use a U-label. The following subsections list and discuss all of the relevant cases. 3.7.1. The Initial SMTP Exchange When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The Yao & Mao Expires January 8, 2012 [Page 10] Internet-Draft EAI SMTP Extension July 2011 SMTP client then sends the EHLO command. Since the SMTP client cannot know whether the SMTP server supports UTF8SMTPbis until after it receives the response from EHLO, the UTF8SMTPbis-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890] ) domains in the EHLO command and that, if the UTF8SMTPbis-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels. 3.7.2. Mail eXchangers If multiple DNS MX records are used to specify multiple servers for a domain in section 5 of [RFC5321], it is strongly advised that all or none of them SHOULD support the UTF8SMTPbis extension. Otherwise, surprising rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues. 3.7.3. Trace Information The trace information , and their related rules are defined in in section 4.4 of RFC 5321 [RFC5321]. This document updates and to support non-ASCII characters. When the UTF8SMTPbis extension is used, the 'Reverse- path' clause of the Return-path-line may include an internationalized domain name that uses the U-label form; The 'Stamp' clause ot the Time-stamp-line may include an internationalized domain name that uses the U-label form. If the messages that include trace fields are sent by an UTF8SMTPbis- aware SMTP client or relay server without the UTF8SMTPbis parameter at MAIL commands, trace field values must conform to RFC 5321 regardless of the SMTP server's capability. If the messages that include trace fields are sent by an UTF8SMTPbis- aware SMTP client or relay server with the UTF8SMTPbis parameter at MAIL commands, trace field values SHOULD use the U-label form for the internationalized domain name. ****! This wording suggests servers need to convert from A-label to U-label if a previous server did the wrong thing. I don't think that's reasonable. I suggest rewording: When an SMTP server adds a trace field to a message that was or will be transmitted with the UTF8SMTPbis MAIL FROM parameter, that server SHOULD use the U-label form for internationalized domain names in that new trace field. The protocol value of the 'WITH' clause when this extension is used is one of the UTF8SMTPbis values specified in the "IANA Considerations" section of this document. ****! Missing: The Atom form of the ID clause can contain non-ASCII characters. 3.7.4. UTF-8 Strings in Replies 3.7.4.1. MAIL Command If an SMTP client follows this specification and sends any MAIL commands containing the UTF8SMTPbis parameter, the UTF8SMTPbis-aware SMTP server is permitted to use UTF-8 characters in the email address Yao & Mao Expires January 8, 2012 [Page 11] Internet-Draft EAI SMTP Extension July 2011 associated with 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them. If a given MAIL command does not include the UTF8SMTPbis parameter, the UTF8SMTPbis-aware SMTP server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses. 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter If the VRFY and EXPN commands are transmitted with the parameter "UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings in replies to those commands. This parameter for the VRFY and EXPN commands SHOULD only be used after the SMTP client sees the EHLO response with the UTF8SMTPbis keyword. This allows the UTF8SMTPbis- aware SMTP server to use UTF-8 strings in mailbox names and full names that occur in replies without concern that the SMTP client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies from the VRFY and EXPN commands that contain UTF-8 strings. However, the UTF8SMTPbis-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter. Most replies do not require that a mailbox name be included in the returned text, and therefore UTF-8 string is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox. VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: vrfy = "VRFY" SP String [ SP "UTF8SMTPbis" ] CRLF ; String may include Non-ASCII characters expn = "EXPN" SP String [ SP "UTF8SMTPbis" ] CRLF ; String may include Non-ASCII characters The "UTF8SMTPbis" parameter does not use a value. If the reply to a *** s/use/have/ VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the *** s/requires UTF-8/requires a UTF-8/ SMTP client did not use the "UTF8SMTPbis" parameter, then the UTF8SMTPbis-aware SMTP server MUST use either the reply-code 252 or 550. Reply-code 252, defined in [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". Reply-code 550, also defined in [RFC5321], means "Requested action not taken: mailbox unavailable". When the UTF8SMTPbis-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code as specified below is used. Using the "UTF8SMTPbis" Yao & Mao Expires January 8, 2012 [Page 12] Internet-Draft EAI SMTP Extension July 2011 parameter with a VERIFY (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that command only. If a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms: User Name ; Mailbox is defined in section 3.3 of this document. ; User Name can contain non-ASCII characters. Mailbox ; Mailbox is defined in section 3.3 of this document. If the SMTP reply requires UTF-8 strings, but UTF-8 string is not *** s/UTF-8 string/UTF-8/ allowed in the reply, and the UTF8SMTPbis-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code is "X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is REQUIRED to show the mailbox name, but that form of response is not permitted by the SMTP client". If the SMTP client does not support the UTF8SMTPbis extension, but receives a UTF-8 string in a reply, it may not be able to properly report the reply to the user, and some clients might crash. **** s/crash/mishandle that reply/ Internationalized messages in replies are only allowed in the commands under the situations described above. Under any other circumstances, UTF-8 string MUST NOT appear in the reply. Although UTF-8 form is needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 string for any other purposes. UTF8SMTPbis-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section. **** Suggest deleting this paragraph. It's not misleading as written and not necessary. 4. IANA Considerations IANA is requested to add a new value "UTF8SMTPbis" to the SMTP Service Extension subregistry of the Mail Parameters registry, according to the following data: +-------------+---------------------------------+-----------+ | Keywords | Description | Reference | +-------------+---------------------------------+-----------+ | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | +-------------+---------------------------------+-----------+ Yao & Mao Expires January 8, 2012 [Page 13] Internet-Draft EAI SMTP Extension July 2011 This document updates the values to the SMTP Enhanced Status Code subregistry of the Mail Parameters registry, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and being based on [RFC5248]. The registration data is as follows: Code: X.6.7 Sample Text: non-ASCII addresses not permitted for that sender/recipient Associated basic status code: 550, 553 Description: This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted Defined: RFC XXXX (Standard track) Submitter: Jiankang YAO Change controller: ima@ietf.org Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the SMTP client Associated basic status code: 252, 550, 553 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client. Defined: RFC XXXX (Standard track) Submitter: Jiankang YAO Change controller: ima@ietf.org Code: X.6.9 Sample Text: UTF-8 header message can not be transferred to one or more recipient so the message must be rejected Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC XXXX (Standard track) Submitter: Jiankang YAO Change controller: ima@ietf.org Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated. The following entries SHOULD be updated or added in the "Mail Transmission Types" registry under the Mail Parameters registry. Yao & Mao Expires January 8, 2012 [Page 14] Internet-Draft EAI SMTP Extension July 2011 +--------------+-------------------------------+--------------------+ | WITH | Description | Reference | | protocol | | | | types | | | +--------------+-------------------------------+--------------------+ | UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | | UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | | | AUTH | [RFCXXXX] | | UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | | | STARTTLS | [RFCXXXX] | | UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | | | STARTTLS and SMTP AUTH | [RFC4954] | | | | [RFCXXXX] | | UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | | UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | | | AUTH | [RFCXXXX] | | UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | | | STARTTLS | [RFCXXXX] | | UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | | | STARTTLS and LMTP AUTH | [RFC4954] | | | | [RFCXXXX] | +--------------+-------------------------------+--------------------+ 5. Security Considerations The extended security considerations discussion in the framework document [RFC4952bis] will be applied here. *** s/will be applied/apply/ More security considerations are discussed below: Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other cases, in particular: o the logging systems of SMTP transactions and other logs to monitor the email systems; o the trouble ticket systems used by Security Teams to manage security incidents, when an email address is involved; In order to avoid problems that could cause loss of data, this will likely require extending these systems to support full UTF-8, or to require to provide an adequate mechanisms for mapping non-ASCII strings to ASCII. Another security aspect to be considered is related to the ability by security team members to quickly understand, read and identify email addresses from the logs, when they are tracking an incident. Yao & Mao Expires January 8, 2012 [Page 15] Internet-Draft EAI SMTP Extension July 2011 Mechanims to automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use also by log readers which cannot read easily non-ASCII information. ****I don't understand what this is trying to say. Suggest deleting this paragraph. The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). RFC 5321 section 3.5 and 7.3 give some detailed description of use and possible behaviours. Implementation of internationalized addrsses can affect also logs and actions by these tools. **** s/addrsses/addresses/ 6. Acknowledgements This document revised the [RFC5336]document based on the Email Address Internationalization (EAI) WG's discussion result. Many EAI WG members did some tests and implementations to move this document to the Standard Track document. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the WG and design team. Those contributions include material from John C Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. Thanks a lot to Dave Crocker for his comments and helping of ABNF refinement. 7. Change History [[anchor14: RFC Editor: Please remove this section.]] 7.1. draft-yao-eai-rfc5336bis: Version 00 Applied errata suggested by Alfred Hoenes. Yao & Mao Expires January 8, 2012 [Page 16] Internet-Draft EAI SMTP Extension July 2011 7.2. draft-ietf-eai-rfc5336bis: Version 00 Applied the changes suggested by the EAI new charter. 7.3. draft-ietf-eai-rfc5336bis: Version 01 Applied the changes suggested by 78 IETF EAI meeting. 7.4. draft-ietf-eai-rfc5336bis: Version 02 remove the appendix since rfc4952bis has added this material improve the text remove the text about no body parameter 7.5. draft-ietf-eai-rfc5336bis: Version 03 improve the text 7.6. draft-ietf-eai-rfc5336bis: Version 04 update the abstract improve the text 7.7. draft-ietf-eai-rfc5336bis: Version 05 improve the text based on AD and Co-chairs 7.8. draft-ietf-eai-rfc5336bis: Version 06 update the iana consideration 7.9. draft-ietf-eai-rfc5336bis: Version 07 improve the iana consideration 7.10. draft-ietf-eai-rfc5336bis: Version 08 improve the texts add the mail parameter add the new section about mail command parameter usage update the security consideration Yao & Mao Expires January 8, 2012 [Page 17] Internet-Draft EAI SMTP Extension July 2011 7.11. draft-ietf-eai-rfc5336bis: Version 09 improve the texts 7.12. draft-ietf-eai-rfc5336bis: Version 10 refine the ABNF definitions improve the texts 7.13. draft-ietf-eai-rfc5336bis: Version 11 remove the update of RFC5321 and RFC5322 change the title from "SMTP Extension for Internationalized Email Address" to "SMTP Extension for Internationalized Email" based on Ernie's comment the trace field of section 3.7.3 is updated to reflect the WG's conclusion improve the texts 8. References 8.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. [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. Yao & Mao Expires January 8, 2012 [Page 18] Internet-Draft EAI SMTP Extension July 2011 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC4952bis] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", I-D rfc4952bis, September 2010. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5335bis] Abel, Y. and S. Steel, "Internationalized Email Headers", I-D rfc5335bis, March 2011. [RFC5337bis] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", I-D 5337bis, October 2010. [RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 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. 8.2. Informative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. Yao & Mao Expires January 8, 2012 [Page 19] Internet-Draft EAI SMTP Extension July 2011 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007. [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. Authors' Addresses Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813007 Email: yaojk@cnnic.cn Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58812230 Email: maowei_ietf@cnnic.cn Yao & Mao Expires January 8, 2012 [Page 20] --Boundary_(ID_6JKL8bneiHTH3Vhy1ptAxQ)-- From chris.newman@oracle.com Mon Jul 25 09:11:21 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 9764111E80AD for ; Mon, 25 Jul 2011 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0pG6sFXaAVp for ; Mon, 25 Jul 2011 09:11:21 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0521F8C37 for ; Mon, 25 Jul 2011 07:34:44 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6PEYgcv024287 for ; Mon, 25 Jul 2011 14:34:43 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL, v2.4) with ESMTP id p6PEYguX050845 for ; Mon, 25 Jul 2011 14:34:42 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.40.53] (dhcp-rmdc-twvpn-2-vpnpool-10-159-40-53.vpn.oracle.com [10.159.40.53]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LOW00F208HRZ700@gotmail.us.oracle.com> for ima@ietf.org; Mon, 25 Jul 2011 07:34:41 -0700 (PDT) Date: Mon, 25 Jul 2011 10:34:39 -0400 From: Chris Newman To: ima@ietf.org Message-id: In-reply-to: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> References: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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: Mon, 25 Jul 2011 16:11:22 -0000 --On July 10, 2011 19:21:48 -0700 internet-drafts@ietf.org wrote: > Title : Internationalized Email Headers > Author(s) : Abel Yang > Shawn Steele > Ned Freed > Filename : draft-ietf-eai-rfc5335bis-11.txt > Pages : 13 > Date : 2011-07-10 I did a detailed review of this document, and found two issues I consider substantial: 1. End of Section 3.2. I suggest adding a statement at least discouraging use of RFC 2047 encoding. Perhaps go so far as to say that submission servers MAY convert RFC 2047 encoding to UTF-8 when the UTF8SMTPbis parameter is used. Perhaps also say that clients including the UTF8SMTPbis parameter SHOULD NOT use RFC 2047 encoding in the headers. 2. A discussion of the impact to RFC 5322 section 2.1.1 (line length limits) is needed. Specifically, the hard 998 character limit becomes a 998 octet limit for 5335bis. However, the conservative 78 character soft-limit should remain based on characters, even if those characters are multi-octet UTF-8. This could also go at the end of section 3.2. Editorial issues: Section 2 I find the first paragraph useless and suggest removing it. Section 4, paragraph 2 I suggest replacing all but the last sentence with a reference to UTF-8 [RFC3629] security considerations which basically all apply and include this issue. Otherwise I think this document is in good shape and ready for standardization. - Chris From chris.newman@oracle.com Mon Jul 25 09:12: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 9B6FF11E8155 for ; Mon, 25 Jul 2011 09:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asqMZ6Jd2oSl for ; Mon, 25 Jul 2011 09:12:15 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68621F855B for ; Mon, 25 Jul 2011 07:49:01 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6PEmxJ4018127; Mon, 25 Jul 2011 14:48:59 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p6PEmw5l001501; Mon, 25 Jul 2011 14:48:59 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.40.53] (dhcp-rmdc-twvpn-2-vpnpool-10-159-40-53.vpn.oracle.com [10.159.40.53]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LOW00F2495KZ700@gotmail.us.oracle.com>; Mon, 25 Jul 2011 07:48:58 -0700 (PDT) Date: Mon, 25 Jul 2011 10:48:56 -0400 From: Chris Newman To: Joseph Yee , "ima@ietf.org WG" Message-id: <94E8901DD55A43FBF20282E0@96B2F16665FF96BAE59E9B90> In-reply-to: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> References: <215DB2DE-CB11-42E9-B25F-EBC0E165FF39@afilias.info> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] Summary of issues and agenda for Quebec meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:12:16 -0000 I decided to investigate the impact to IMAP of these open issues. --On July 18, 2011 19:19:20 -0400 Joseph Yee wrote: > (1) Allowing 8-bit or not to Message-ID (also IN-REPLY-TO field & > REFERENCES field) in RFC5335bis The way we did uQuoted for 5738bis makes this not a problem -- the Message-ID field would simply be uQuoted in the IMAP envelope for this case. > (2) ABNF in popimap-downgrade-display section 3 > > In IETF Beijing the WG agreed to adopt group syntax. In the revision > (-02) of popimap-downgrade-display, the ABNF syntax extends to "from", > "resent-from", "sender" and "resent-sender" to allow group. The syntax > is not yet complete. FYI, the base IMAP specification (RFC 3501) uses a generalized address model for the parsed IMAP envelope that implicitly allows group syntax in both From and Sender. While it's possible IMAP clients won't expect this, it's permitted by the IMAP ABNF. - Chris From dhc2@dcrocker.net Mon Jul 25 14:36: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 9723211E80BA for ; Mon, 25 Jul 2011 14:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO59xDmY4MAO for ; Mon, 25 Jul 2011 14:36:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 04BDA11E80C4 for ; Mon, 25 Jul 2011 14:36:59 -0700 (PDT) Received: from [130.129.85.251] ([130.129.85.251]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6PLapnL015500 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2011 14:36:58 -0700 Message-ID: <4E2DE1F2.1040906@dcrocker.net> Date: Mon, 25 Jul 2011 17:36:50 -0400 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Chris Newman References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> In-Reply-To: <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 25 Jul 2011 14:36:58 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 21:36:59 -0000 Chris, I'm only going some points needing clarification... On 7/25/2011 10:16 AM, Chris Newman wrote: > 3. I suggest adding a statement to the end of section 3.5: > > SMTP servers are encouraged to detect that recipients can not > accept internationalized email headers and return an error > earlier in the transaction whenever possible. MDAs are often (almost always?) the only entities that know anything about recipient capabilities. The statement should probably be revised so that it does not confuse transit relay operators. In addition, I don't know what you mean by "earlier in the transaction". Do you really mean the difference between responding to a RCPT command, versus a DATA command in the same session, or did you mean something about the mail relaying sequence? -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned+ima@mrochek.com Mon Jul 25 18:04:06 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 5209221F8B81 for ; Mon, 25 Jul 2011 18:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD2EwQlDpzD1 for ; Mon, 25 Jul 2011 18:04:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 622E821F8B74 for ; Mon, 25 Jul 2011 18:04:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O42NDMR2K000YGFF@mauve.mrochek.com> for ima@ietf.org; Mon, 25 Jul 2011 18:03:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O41983WUXC00RCTX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 25 Jul 2011 18:03:13 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01O42NDKVA8W00RCTX@mauve.mrochek.com> Date: Mon, 25 Jul 2011 17:00:56 -0700 (PDT) In-reply-to: "Your message dated Mon, 25 Jul 2011 10:34:39 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> To: Chris Newman DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311642161; bh=FyKcEm6mYdKx+6+jzbBuAszBJG8NEvsZlzvikvtu8BA=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=sk+pi1W8PS9rvv26XVfDP/Xcu49oN0n4zh35EWj0TnW46FLmkgBe2ZGQuzFDiShfh TziMVPGiob9kkQO2/jdr8EanKZW7KW2jQN5lwiTB9XzB+OM2lYA+0UdlpsBcPnfbUH i+9T0Ik+1VTEj4pGSDOD67/vQxDOv2kpD41vCoho= Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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, 26 Jul 2011 01:04:06 -0000 > --On July 10, 2011 19:21:48 -0700 internet-drafts@ietf.org wrote: > > Title : Internationalized Email Headers > > Author(s) : Abel Yang > > Shawn Steele > > Ned Freed > > Filename : draft-ietf-eai-rfc5335bis-11.txt > > Pages : 13 > > Date : 2011-07-10 > I did a detailed review of this document, and found two issues I consider > substantial: > 1. End of Section 3.2. I suggest adding a statement at least discouraging > use of RFC 2047 encoding. Perhaps go so far as to say that submission > servers MAY convert RFC 2047 encoding to UTF-8 when the UTF8SMTPbis > parameter is used. Perhaps also say that clients including the UTF8SMTPbis > parameter SHOULD NOT use RFC 2047 encoding in the headers. I agree this needs to be in there but I think it belongs in a separate section, not at the end of the one about the ABNF changes. How about:
The MIME encoded-words facility provides the ability to place non-ASCII text, but only in a subset of the places allowed by this extension. Additionally, encoded-words are substantially more complex since they allow the use of arbitrary charsets. Accordingly, encoded-words SHOULD NOT be used when generating header fields for messages employing this extension. Agents MAY, when incorporating material from another message, convert encoded-word use to direct use of UTF-8. Note that care must be taken when decoding encoded-words because the results after replacing an encoded-word with its decoded equivalent in UTF-8 may be syntactically invalid. Processors that elect to decode encoded-words MUST NOT generate syntactically invalid fields.
> 2. A discussion of the impact to RFC 5322 section 2.1.1 (line length > limits) is needed. Specifically, the hard 998 character limit becomes a 998 > octet limit for 5335bis. However, the conservative 78 character soft-limit > should remain based on characters, even if those characters are multi-octet > UTF-8. This could also go at the end of section 3.2. I have to say I regard it as an error that RFC 5322 talks about characters and not octets. But then again, if memory serves, this whole discussion is only present in the document because of a rubbish comment from the IESG eons ago. Anyway, this also really calls for another (short) section. How about:
Section 2.1.1 of 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.
> Editorial issues: > Section 2 > I find the first paragraph useless and suggest removing it. I agree but I'm reluctant to remove it without some additional feedback. Comments from others as to whether this paragraph: A plain ASCII string is fully compatible with [RFC5321] and [RFC5322]. In this document, non-ASCII strings are UTF-8 strings if they are in header field values which contain at least one (see Section 3.1). should be removed? > Section 4, paragraph 2 > I suggest replacing all but the last sentence with a reference to UTF-8 > [RFC3629] security considerations which basically all apply and include > this issue. Agreed and done. > Otherwise I think this document is in good shape and ready for > standardization. Thanks for the review; these suggestions were very helpful. I'll post an updated draft in a bit if no further comments are received. Ned From jyee@afilias.info Mon Jul 25 22:21:36 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 7D3CB21F8772 for ; Mon, 25 Jul 2011 22:21:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fkhFL0uJ74B for ; Mon, 25 Jul 2011 22:21:36 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id D08F521F877D for ; Mon, 25 Jul 2011 22:21:35 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Qla5G-0000pA-5I for ima@ietf.org; Tue, 26 Jul 2011 05:21:34 +0000 Received: from mail-yi0-f50.google.com ([209.85.218.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Qla5G-0004GY-83 for ima@ietf.org; Tue, 26 Jul 2011 05:21:34 +0000 Received: by yib19 with SMTP id 19so40746yib.9 for ; Mon, 25 Jul 2011 22:21:34 -0700 (PDT) Received: by 10.142.164.21 with SMTP id m21mr3329199wfe.116.1311657693646; Mon, 25 Jul 2011 22:21:33 -0700 (PDT) Received: from ?IPv6:2001:df8::64:21f:f3ff:fed2:cd5b? ([2001:df8:0:64:21f:f3ff:fed2:cd5b]) by mx.google.com with ESMTPS id d14sm97275wfh.13.2011.07.25.22.21.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 22:21:32 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 01:21:23 -0400 To: "ima@ietf.org WG" Message-Id: <92ED41DE-948C-4A61-979A-F73F6899FE93@afilias.info> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] recap from IETF79 (Beijing) discussion on POPIMAP-Downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 05:21:36 -0000 All, Below is recap for WG discussion & consensus during IETF79 (Beijing) on = interfacing between ASCII-only mail client with UTF8-capable POP/IMAP = servers where mail stores hold UTF8-native messages. =20 ------ The WG concluded that there is a need to relax RFC5322 to allow group = syntax, with the intention that i. the message preserve the information that legacy mail client can = display to end users ii. the message has higher chance be parse-able by legacy mail client = so it's not lost iii. although the legacy client cannot reply back, there's no security = concern of reply to wrong people The goal is to make message readable for legacy client by RFC2047 (or by = MIME Extension) Various forms of presentation discussed, and agreed that group syntax = works best for both issue 1 and issue 2 with the following details Issue 1 Providing nested group (or even group with long list of addresses) is = complex, and fragile (easy to break, not get parse properly as = expected). So the recommendation is create group only for the outermost = group, any group within needed to be MIME encoded by RFC2047. Issue 2 To use group syntax. MIME encode the string (address) as group name, = append :; to form an empty group list. Additional changes to popimap-downgrade-display: The draft popimap-downgrade UPDATES RFC5322. This draft allows group = syntax on backward pointing addresses (From, Resent-From, Sender, = Resent-Sender) where RFC5322 prohibited. RFC5322 intends to make sure = message reply to a legit address, where EAI intends to display the = message to end users, where users can take the internationalized = string/address outside legacy mail client for further use, but not = allowing the legacy client to reply. Legacy client has no UTF8SMTPbis = capability to reply. ---- Regards, Joseph= From jyee@afilias.info Mon Jul 25 22:21:36 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 8735F21F8779 for ; Mon, 25 Jul 2011 22:21:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhXGTwQLLorN for ; Mon, 25 Jul 2011 22:21:35 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5B21F877F for ; Mon, 25 Jul 2011 22:21:35 -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 1Qla5E-0000p2-3E for ima@ietf.org; Tue, 26 Jul 2011 05:21:32 +0000 Received: from mail-gy0-f178.google.com ([209.85.160.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Qla5D-00045T-60 for ima@ietf.org; Tue, 26 Jul 2011 05:21:31 +0000 Received: by gyf1 with SMTP id 1so40485gyf.9 for ; Mon, 25 Jul 2011 22:21:31 -0700 (PDT) Received: by 10.142.209.12 with SMTP id h12mr2291110wfg.428.1311657690726; Mon, 25 Jul 2011 22:21:30 -0700 (PDT) Received: from ?IPv6:2001:df8::64:21f:f3ff:fed2:cd5b? ([2001:df8:0:64:21f:f3ff:fed2:cd5b]) by mx.google.com with ESMTPS id d14sm97275wfh.13.2011.07.25.22.21.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 22:21:30 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jul 2011 01:21:21 -0400 To: "ima@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [EAI] Revised Agenda and Slides for IETF81 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 26 Jul 2011 05:21:36 -0000 Hi all, Revised agenda and slides for IETF81 are available at link below. Agenda: http://www.ietf.org/proceedings/81/agenda/eai.txt EAI Discusion Slide: http://www.ietf.org/proceedings/81/slides/eai-0.pdf POPIMAP-Downgrade Discussion Slide: http://www.ietf.org/proceedings/81/slides/eai-1.pdf Thanks Joseph From klensin@jck.com Tue Jul 26 01:46:03 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 4F9C421F8B87 for ; Tue, 26 Jul 2011 01:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3e7wz25bQLy for ; Tue, 26 Jul 2011 01:46:02 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id A566921F85AE for ; Tue, 26 Jul 2011 01:46:02 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QldH4-0001De-3e; Tue, 26 Jul 2011 04:45:58 -0400 Date: Tue, 26 Jul 2011 04:45:57 -0400 From: John C Klensin To: ned+ima@mrochek.com, Chris Newman Message-ID: <25B00C19DAB850F028F04115@JCK-EEE10> In-Reply-To: <01O42NDKVA8W00RCTX@mauve.mrochek.com> References: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> <01O42NDKVA8W00RCTX@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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, 26 Jul 2011 08:46:03 -0000 --On Monday, 25 July, 2011 17:00 -0700 ned+ima@mrochek.com wrote: >... > 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 think this is about the best we can do despite the fact that it will lead to shorter lines than the "78" was intended to permit. The problem is that, in Unicode-speak, combining characters are really characters. In a different world, we might be talking about 78 "character positions", but attempting to introduce that term always causes a world of woe. >> Editorial issues: > >> Section 2 > >> I find the first paragraph useless and suggest removing it. > > I agree but I'm reluctant to remove it without some additional > feedback. > Comments from others as to whether this paragraph: > > A plain ASCII string is fully compatible with [RFC5321] and > [RFC5322]. In this document, non-ASCII strings are UTF-8 > strings if > they are in header field values which contain at least one > ascii> (see Section 3.1). > > should be removed? No strong opinion. We should talk about the relationship between 3536bis (recently approved by the IESG) and the EAI documents during the meeting. john From duerst@it.aoyama.ac.jp Tue Jul 26 02:26:57 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 0894D21F8C12 for ; Tue, 26 Jul 2011 02:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.866 X-Spam-Level: X-Spam-Status: No, score=-99.866 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwAhNAUMbv2h for ; Tue, 26 Jul 2011 02:26:56 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7350C21F8C0F for ; Tue, 26 Jul 2011 02:26:54 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p6Q9Qjln002927 for ; Tue, 26 Jul 2011 18:26:46 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 3a13_6dc4_61a6755c_b769_11e0_bcb1_001d096c566a; Tue, 26 Jul 2011 18:26:45 +0900 Received: from [IPv6:::1] ([133.2.210.5]:60479) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 26 Jul 2011 18:26:43 +0900 Message-ID: <4E2E881E.9000909@it.aoyama.ac.jp> Date: Tue, 26 Jul 2011 18:25:50 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 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: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> <01O42NDKVA8W00RCTX@mauve.mrochek.com> <25B00C19DAB850F028F04115@JCK-EEE10> In-Reply-To: <25B00C19DAB850F028F04115@JCK-EEE10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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, 26 Jul 2011 09:26:57 -0000 Hello John, others, On 2011/07/26 17:45, John C Klensin wrote: > > > --On Monday, 25 July, 2011 17:00 -0700 ned+ima@mrochek.com wrote: > >> ... >> 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 think this is about the best we can do I agree. > despite the fact that > it will lead to shorter lines than the "78" was intended to > permit. Not so fast, not so fast. This is internationalization, it can't be that easy :-). It may also lead to longer lines. CJK Ideographs, Kana, and Hangul usually take two 'display cells'. Regards, Martin. > The problem is that, in Unicode-speak, combining > characters are really characters. In a different world, we > might be talking about 78 "character positions", but attempting > to introduce that term always causes a world of woe. > >>> Editorial issues: >> >>> Section 2 >> >>> I find the first paragraph useless and suggest removing it. >> >> I agree but I'm reluctant to remove it without some additional >> feedback. >> Comments from others as to whether this paragraph: >> >> A plain ASCII string is fully compatible with [RFC5321] and >> [RFC5322]. In this document, non-ASCII strings are UTF-8 >> strings if >> they are in header field values which contain at least one >> > ascii> (see Section 3.1). >> >> should be removed? > > No strong opinion. We should talk about the relationship > between 3536bis (recently approved by the IESG) and the EAI > documents during the meeting. > > john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Tue Jul 26 02:38: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 009AE21F8B66 for ; Tue, 26 Jul 2011 02:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTgn3R1x8gZP for ; Tue, 26 Jul 2011 02:38:34 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E421F8B69 for ; Tue, 26 Jul 2011 02:38:32 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qle5Y-00023f-6d; Tue, 26 Jul 2011 05:38:09 -0400 Date: Tue, 26 Jul 2011 05:37:46 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <50C2CF6912CD8AAA394609A2@JCK-EEE10> In-Reply-To: <4E2E881E.9000909@it.aoyama.ac.jp> References: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> <01O42NDKVA8W00RCTX@mauve.mrochek.com> <25B00C19DAB850F028F04115@JCK-EEE10> <4E2E881E.9000909@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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, 26 Jul 2011 09:38:35 -0000 --On Tuesday, 26 July, 2011 18:25 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: > Hello John, others, >=20 > On 2011/07/26 17:45, John C Klensin wrote: >>=20 >>=20 >> --On Monday, 25 July, 2011 17:00 -0700 ned+ima@mrochek.com >> wrote: >>=20 >>> ... >>> 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. >>> >>=20 >> I think this is about the best we can do >=20 > I agree. >=20 >> despite the fact that >> it will lead to shorter lines than the "78" was intended to >> permit. >=20 > Not so fast, not so fast. This is internationalization, it > can't be that easy :-). >=20 > It may also lead to longer lines. CJK Ideographs, Kana, and > Hangul usually take two 'display cells'. Depends entirely on the typestyles, rendering machinery, and counting mechanism used. This of course proves your "can't be that easy" point and my point about worlds of woe :-( john From dhc2@dcrocker.net Tue Jul 26 04:13:03 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 E417F21F8ABD for ; Tue, 26 Jul 2011 04:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKp+sOv13wmH for ; Tue, 26 Jul 2011 04:13:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26821F8AB8 for ; Tue, 26 Jul 2011 04:13:03 -0700 (PDT) Received: from [172.16.58.236] (modemcable252.155-70-69.static.videotron.ca [69.70.155.252]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6QBCuC9001082 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 04:13:02 -0700 Message-ID: <4E2EA136.4010508@dcrocker.net> Date: Tue, 26 Jul 2011 07:12:54 -0400 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ned+ima@mrochek.com References: <20110711022148.29878.42062.idtracker@ietfa.amsl.com> <01O42NDKVA8W00RCTX@mauve.mrochek.com> In-Reply-To: <01O42NDKVA8W00RCTX@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 26 Jul 2011 04:13:03 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-11.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:13:04 -0000 On 7/25/2011 8:00 PM, ned+ima@mrochek.com wrote: >> 2. A discussion of the impact to RFC 5322 section 2.1.1 (line length >> limits) is needed. Specifically, the hard 998 character limit becomes a 998 >> octet limit for 5335bis. However, the conservative 78 character soft-limit >> should remain based on characters, ... > > Section 2.1.1 of 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'll ask a "due diligence" question: Are we certain that this long-standing 78-character limit has not produced hard buffering limits in software that really make it an installed base of 78-octets? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From healthyao@gmail.com Tue Jul 26 04:51:37 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 B37C221F8C72 for ; Tue, 26 Jul 2011 04:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUGAYpKHRL4a for ; Tue, 26 Jul 2011 04:51:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED7FE21F8785 for ; Tue, 26 Jul 2011 04:51:36 -0700 (PDT) Received: by iye7 with SMTP id 7so644182iye.31 for ; Tue, 26 Jul 2011 04:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=LonqwPgvscKU9FhFvg1U7BnQ1+vrjys2ohJKOvWttRo=; b=UVdzAyxfiXYNS09TWFMfEwjzeJnfnLQm+d008V8qtChEhw22dhNMfj2TsWf0jZWURk DDuJKjSUdyxr3z2x2fJ1uTd1Nwr6Rd2V3s7d8OfZSdtA8wPVZq/tgiO7FoQY2dbEKqdY q/lncGiJdC1GqRmD909vFfwXpwAmXpcKz2fUw= Received: by 10.231.181.79 with SMTP id bx15mr5650265ibb.125.1311681096220; Tue, 26 Jul 2011 04:51:36 -0700 (PDT) Received: from LENOVO47E041CF (modemcable194.226-81-70.mc.videotron.ca [70.81.226.194]) by mx.google.com with ESMTPS id b6sm287725ibg.31.2011.07.26.04.51.30 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 04:51:31 -0700 (PDT) Message-ID: From: "Jiankang Yao" To: "Chris Newman" , References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> Date: Tue, 26 Jul 2011 19:51:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-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, 26 Jul 2011 11:51:38 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPGNo cmlzLm5ld21hbkBvcmFjbGUuY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXks IEp1bHkgMjUsIDIwMTEgMTA6MTYgUE0NClN1YmplY3Q6IFJlOiBbRUFJXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTExLnR4dA0KDQoNCj4gLS1PbiBKdWx5IDcsIDIwMTEg MTg6MjM6NTIgLTA3MDAgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPj4gVGl0bGUg ICAgICAgICAgIDogU01UUCBFeHRlbnNpb24gZm9yIEludGVybmF0aW9uYWxpemVkIEVtYWlsDQo+ PiBBdXRob3IocykgICAgICAgOiBKaWFua2FuZyBZYW8NCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgVy4gTWFvDQo+PiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM2 YmlzLTExLnR4dA0KPj4gUGFnZXMgICAgICAgICAgIDogMjANCj4+IERhdGUgICAgICAgICAgICA6 IDIwMTEtMDctMDcNCj4gDQo+IEkndmUgZG9uZSBhbiBleHRlbnNpdmUgImNsZWFuIHNsYXRlIiBy ZXZpZXcgb24gdGhpcyBkb2N1bWVudC4gSSBmb3VuZCBhIA0KPiBudW1iZXIgb2YgaXNzdWVzIEkg Y29uc2lkZXIgbGFyZ2VseSBlZGl0b3JpYWwgDQo+DQoNCnRoYW5rcyBhIGxvdCBmb3IgeW91ciBr aW5kIGFuZCBkZXRhaWxlZCByZXZpZXcuDQoNClNvbWUgb2YgeW91ciBzdWdnZXN0ZWQgZWRpdG9y aWFsIHRleHRzIGhhcyBiZWVuIGNoYW5nZWQgYmFjayBhbmQgZm9ydGggbWFueSB0aW1lcy4NCkkg YW0gc29ycnkgdGhhdCB0aGUgdGV4dHMgY2FuIG5vdCBtYWtlIGV2ZXJ5b25lIGhhcHB5Lg0KSSB3 aWxsIHRyeSB0byBhZGp1c3QgdGhlIHRleHRzIGJhc2VkIG9uIHlvdXIgZWRpdG9yaWFsIHN1Z2dl c3Rpb24sIGJ1dCB3aWxsIGFsc28gZm9sbG93IHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uIGFib3V0 DQp0aGlzIHRvcGljIHRvIGF2b2lkIHRoZSAiYmFjayBhbmQgZm9ydGgiIHRleHQgcHJvYmxlbS4N Cg0KPmFuZCBzb21lIEkgY29uc2lkZXIgDQo+IHN1YnN0YW50aXZlIChpbiB0aGF0IHRoZSBkZWNp c2lvbiBoYXMgdGVjaG5pY2FsIGltcGFjdCkuIEkndmUgYXR0YWNoZWQgbXkgDQo+IGZ1bGwgcmV2 aWV3IHdpdGggZWRpdG9yaWFsIG5vdGVzIGVtYmVkZGVkIGluIHRoZSB0ZXh0LiBIZXJlIGFyZSB0 aGUgDQo+IHN1YnN0YW50aXZlIGlzc3VlczoNCj4gDQo+IDEuIFNvbWV3aGVyZSB0aGlzIG5lZWRz IHRvIHNheTogSWYgYSBzZXJ2ZXIgYWR2ZXJ0aXNlcyBib3RoIFVURjhTTVRQYmlzIGFuZCANCj4g RFNOLCB0aGVuIHRoYXQgc2VydmVyIE1VU1Qgc3VwcG9ydCBVVEYtOCBpbiB0aGUgT1JDUFQgcGFy YW1ldGVyLiBUaGlzIGFsc28gDQo+IGhhcyBBQk5GIGltcGFjdC4gDQo+DQoNCm15IGNvbmNlcm4g aXMgdGhhdCwgaWYgd2UgY2hvb3NlIHRvIGFkZCB0aGUgc2VudGVuY2UgYWJvdmUgd2UgY2F1c2Ug YW5vdGhlciBwcm9ibGVtcy4NCg0KSXMgaXQgcmVhbGx5IG5lY2Vzc2FyeSB0byBhZGQgc3VjaCBh IHNlbnRlbmNlPw0KDQoNCj4NCj5XZSBuZWVkIHRvIGFkZDoNCj4gDQo+ICAgZWhsby1wYXJhbSAg PS8gVVRGOC1ub24tYXNjaWkNCj4gDQo+IHRvIGFsbG93IFVURi04IGluIG1haWwsIHJjcHQgYW5k IGRhdGEgcGFyYW1ldGVycy4NCj4gDQo+IDIuIEkgd291bGQgcHJlZmVyIHRoaXMgQUJORiBydWxl IGJlIHJlbW92ZWQ6DQo+IA0KPiAgIHF1b3RlZC1wYWlyU01UUCAgPS8gJWQ5MiBVVEY4LW5vbi1h c2NpaQ0KPiAgICA7IGV4dGVuZCB0aGUgZGVmaW5pdGlvbiBvZiBxdW90ZWQtcGFpclNNVFAgaW4g UkZDNTMyMSwgc2VjdGlvbiA0LjEuMg0KPiANCj4gVGhpcyBpcyBhbiB1bm5lY2Vzc2FyeSBjaGFu Z2UgYW5kIG1ha2VzIDUzMzZiaXMgcXVvdGluZyBldmVuIGxlc3MgDQo+IGNvbnNpc3RlbnQgd2l0 aCA1MzM1YmlzIHF1b3RpbmcuIENvbnNlcnZhdGl2ZSBnZW5lcmF0b3JzIHNob3VsZCBuZXZlciBl bWl0IA0KPiBcIGZvbGxvd2VkIGJ5IGFueXRoaW5nIG90aGVyIHRoYW4gXCBvciBkb3VibGUtcXVv dGUgYW55d2F5LCBzbyBhZGRpbmcgDQo+IGNvbXBsZXhpdHkgdG8gZXhwbGljaXRseSBhbGxvdyBn ZW5lcmF0aW9uIG9mIHVzZWxlc3MgZm9ybXMgaXMgbm90IGhlbHBmdWwuDQo+IA0KDQpJIGFncmVl ZCBpdCBoZXJlLg0KDQpIb3cgYWJvdXQgRGF2ZSdzIGNvbW1lbnRzIGFib3V0IHRoaXMgaXNzdWU/ DQoNCg0KPg0KPiAzLiBJIHN1Z2dlc3QgYWRkaW5nIGEgc3RhdGVtZW50IHRvIHRoZSBlbmQgb2Yg c2VjdGlvbiAzLjU6DQo+IA0KPiAgICAgIFNNVFAgc2VydmVycyBhcmUgZW5jb3VyYWdlZCB0byBk ZXRlY3QgdGhhdCByZWNpcGllbnRzIGNhbiBub3QNCj4gICAgICBhY2NlcHQgaW50ZXJuYXRpb25h bGl6ZWQgZW1haWwgaGVhZGVycyBhbmQgcmV0dXJuIGFuIGVycm9yDQo+ICAgICAgZWFybGllciBp biB0aGUgdHJhbnNhY3Rpb24gd2hlbmV2ZXIgcG9zc2libGUuDQo+IA0KDQpzaW1pbGFyIGNvbW1l bnRzIHRvIERhdmUncw0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaW1h L2N1cnJlbnQvbXNnMDQyODUuaHRtbA0KDQphbm90aGVyIHF1ZXN0aW9uIGlzIA0KDQphZGRpbmcg dGhpcyBzZW50ZW5jZSBpcyBtb3JlIGNsZWFyIHRoYW4gd2l0aG91dCBpdD8NCg0KDQo+IDQuIElu IHNlY3Rpb24gMy41LCBJIHN1Z2dlc3QgYWRkaW5nIGFuIGVuaGFuY2VkIHN0YXR1cyBjb2RlIGZv ciB0aGUgY2FzZSANCj4gd2hlcmUgYSBVLWxhYmVsIGNhbiBub3QgYmUgY29udmVydGVkIHRvIGFu IEEtbGFiZWwuIFRoaXMgaXMgc2VtYW50aWNhbGx5IA0KPiBxdWl0ZSBkaWZmZXJlbnQgZnJvbSBY LjYuNyBhbmQgWC42LjkNCj4gDQoNCg0KYmFzZWQgb24gcmZjNTg5MCwgVS1sYWJlbCBtdXN0IGJl IHRyYW5zZm9ybWVkIHRvIEEtbGFiZWwsIG90aGVyd2lzZSwgaXQgY2FuIG5vdCBiZSBjYWxsZWQg VS1sYWJlbC4NCg0KSm9obiBzaG91bGQgYmUgYXV0aG9yaXRpdmUgYWJvdXQgdGhlIGRlZmludGlv biBvZiBVLWxhYmVsLg0KDQo+IDUuIFNlY3Rpb24gMy43IHNheXMgdGhlIEEtbGFiZWwgZm9ybSBT SE9VTEQgYmUgdXNlZC4gV2hpbGUgSSBkb24ndCBvYmplY3QgDQo+IHRvIHRoYXQgZm9yIHJlbGF5 LCBJIGJlbGlldmUgaXQgc2hvdWxkIGFsc28gc2F5IHRoYXQgc3VibWlzc2lvbiBjbGllbnRzIE1B WSANCj4gdXNlIFUtbGFiZWxzLg0KPiANCg0KYWdyZWUuDQoNCg0KPiA2LiBTZWN0aW9uIDMuNy4z Og0KPiANCj4+ICAgSWYgdGhlIG1lc3NhZ2VzIHRoYXQgaW5jbHVkZSB0cmFjZSBmaWVsZHMgYXJl IHNlbnQgYnkgYW4gVVRGOFNNVFBiaXMtDQo+PiAgIGF3YXJlIFNNVFAgY2xpZW50IG9yIHJlbGF5 IHNlcnZlciB3aXRoIHRoZSBVVEY4U01UUGJpcyBwYXJhbWV0ZXIgYXQNCj4+ICAgTUFJTCBjb21t YW5kcywgdHJhY2UgZmllbGQgdmFsdWVzIFNIT1VMRCB1c2UgdGhlIFUtbGFiZWwgZm9ybSBmb3Ig dGhlDQo+PiAgIGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lLg0KPiANCj4gICAgICBUaGlz IHdvcmRpbmcgc3VnZ2VzdHMgc2VydmVycyBuZWVkIHRvIGNvbnZlcnQgZnJvbSBBLWxhYmVsIHRv DQo+ICAgICAgVS1sYWJlbCBpZiBhIHByZXZpb3VzIHNlcnZlciBkaWQgdGhlIHdyb25nIHRoaW5n LiBJIGRvbid0IHRoaW5rDQo+ICAgICAgdGhhdCdzIHJlYXNvbmFibGUuIEkgc3VnZ2VzdCByZXdv cmRpbmc6DQo+IA0KPiAgICBXaGVuIGFuIFNNVFAgc2VydmVyIGFkZHMgYSB0cmFjZSBmaWVsZCB0 byBhIG1lc3NhZ2UgdGhhdCB3YXMgb3INCj4gICAgd2lsbCBiZSB0cmFuc21pdHRlZCB3aXRoIHRo ZSBVVEY4U01UUGJpcyBNQUlMIEZST00gcGFyYW1ldGVyLCB0aGF0DQo+ICAgIHNlcnZlciBTSE9V TEQgdXNlIHRoZSBVLWxhYmVsIGZvcm0gZm9yIGludGVybmF0aW9uYWxpemVkIGRvbWFpbg0KPiAg ICBuYW1lcyBpbiB0aGF0IG5ldyB0cmFjZSBmaWVsZC4NCj4gDQoNCm9rLCB0aGFua3MuDQoNCg0K PiA3LiBTZWN0aW9uIDMuNy4zIG5lZWRzIHRvIHNheSAoZ2l2ZW4gdGhlIGN1cnJlbnQgQUJORik6 DQo+IA0KPiAgIFRoZSBBdG9tIGZvcm0gb2YgdGhlIElEIGNsYXVzZSBjYW4gY29udGFpbiBub24t QVNDSUkgY2hhcmFjdGVycy4NCj4NCg0KSSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHdvcmRpbmcg YmVsb3cgY292ZXJzIHRoZSAiSUQgY2xhdXNlIiBjYXNlOg0KDQoiV2hlbiB0aGUgVVRGOFNNVFBi aXMgZXh0ZW5zaW9uIGlzIHVzZWQsIHRoZSAnUmV2ZXJzZS0NCiAgIHBhdGgnIGNsYXVzZSBvZiB0 aGUgUmV0dXJuLXBhdGgtbGluZSBtYXkgaW5jbHVkZSBhbiBpbnRlcm5hdGlvbmFsaXplZA0KICAg ZG9tYWluIG5hbWUgdGhhdCB1c2VzIHRoZSBVLWxhYmVsIGZvcm07IFRoZSAnU3RhbXAnIGNsYXVz ZSBvdCB0aGUNCiAgIFRpbWUtc3RhbXAtbGluZSBtYXkgaW5jbHVkZSBhbiBpbnRlcm5hdGlvbmFs aXplZCBkb21haW4gbmFtZSB0aGF0DQogICB1c2VzIHRoZSBVLWxhYmVsIGZvcm0uDQoNCiINCg0K DQp0aGFua3MgYSBsb3QuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4= From healthyao@gmail.com Tue Jul 26 04:53:21 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 5A69F21F8C83 for ; Tue, 26 Jul 2011 04:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03vehOePkchm for ; Tue, 26 Jul 2011 04:53:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16DD721F8C7D for ; Tue, 26 Jul 2011 04:53:21 -0700 (PDT) Received: by iye7 with SMTP id 7so645858iye.31 for ; Tue, 26 Jul 2011 04:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=LonqwPgvscKU9FhFvg1U7BnQ1+vrjys2ohJKOvWttRo=; b=rgBsyd/qnc57lMHuWeAjQ9fJp8hern02PdDYFPQXGfbN2MtHmsuhVB5JSP5RcRkNrW vDGY8lVMa5IMyV5v5rn6uJFXS4e6EvCum8mlNMCbLuRNMGiEabPEgg7voKNSfJSMvGll RVfBsarm0UdvCGq/ebChCtMsBZiOeZelp5M0U= Received: by 10.231.117.35 with SMTP id o35mr5500183ibq.160.1311681200312; Tue, 26 Jul 2011 04:53:20 -0700 (PDT) Received: from LENOVO47E041CF (modemcable194.226-81-70.mc.videotron.ca [70.81.226.194]) by mx.google.com with ESMTPS id a9sm561365icy.18.2011.07.26.04.53.17 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 04:53:19 -0700 (PDT) Message-ID: From: "Jiankang Yao" To: "Chris Newman" , References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> Date: Tue, 26 Jul 2011 19:53:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-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, 26 Jul 2011 11:53:21 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPGNo cmlzLm5ld21hbkBvcmFjbGUuY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXks IEp1bHkgMjUsIDIwMTEgMTA6MTYgUE0NClN1YmplY3Q6IFJlOiBbRUFJXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTExLnR4dA0KDQoNCj4gLS1PbiBKdWx5IDcsIDIwMTEg MTg6MjM6NTIgLTA3MDAgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPj4gVGl0bGUg ICAgICAgICAgIDogU01UUCBFeHRlbnNpb24gZm9yIEludGVybmF0aW9uYWxpemVkIEVtYWlsDQo+ PiBBdXRob3IocykgICAgICAgOiBKaWFua2FuZyBZYW8NCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgVy4gTWFvDQo+PiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM2 YmlzLTExLnR4dA0KPj4gUGFnZXMgICAgICAgICAgIDogMjANCj4+IERhdGUgICAgICAgICAgICA6 IDIwMTEtMDctMDcNCj4gDQo+IEkndmUgZG9uZSBhbiBleHRlbnNpdmUgImNsZWFuIHNsYXRlIiBy ZXZpZXcgb24gdGhpcyBkb2N1bWVudC4gSSBmb3VuZCBhIA0KPiBudW1iZXIgb2YgaXNzdWVzIEkg Y29uc2lkZXIgbGFyZ2VseSBlZGl0b3JpYWwgDQo+DQoNCnRoYW5rcyBhIGxvdCBmb3IgeW91ciBr aW5kIGFuZCBkZXRhaWxlZCByZXZpZXcuDQoNClNvbWUgb2YgeW91ciBzdWdnZXN0ZWQgZWRpdG9y aWFsIHRleHRzIGhhcyBiZWVuIGNoYW5nZWQgYmFjayBhbmQgZm9ydGggbWFueSB0aW1lcy4NCkkg YW0gc29ycnkgdGhhdCB0aGUgdGV4dHMgY2FuIG5vdCBtYWtlIGV2ZXJ5b25lIGhhcHB5Lg0KSSB3 aWxsIHRyeSB0byBhZGp1c3QgdGhlIHRleHRzIGJhc2VkIG9uIHlvdXIgZWRpdG9yaWFsIHN1Z2dl c3Rpb24sIGJ1dCB3aWxsIGFsc28gZm9sbG93IHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uIGFib3V0 DQp0aGlzIHRvcGljIHRvIGF2b2lkIHRoZSAiYmFjayBhbmQgZm9ydGgiIHRleHQgcHJvYmxlbS4N Cg0KPmFuZCBzb21lIEkgY29uc2lkZXIgDQo+IHN1YnN0YW50aXZlIChpbiB0aGF0IHRoZSBkZWNp c2lvbiBoYXMgdGVjaG5pY2FsIGltcGFjdCkuIEkndmUgYXR0YWNoZWQgbXkgDQo+IGZ1bGwgcmV2 aWV3IHdpdGggZWRpdG9yaWFsIG5vdGVzIGVtYmVkZGVkIGluIHRoZSB0ZXh0LiBIZXJlIGFyZSB0 aGUgDQo+IHN1YnN0YW50aXZlIGlzc3VlczoNCj4gDQo+IDEuIFNvbWV3aGVyZSB0aGlzIG5lZWRz IHRvIHNheTogSWYgYSBzZXJ2ZXIgYWR2ZXJ0aXNlcyBib3RoIFVURjhTTVRQYmlzIGFuZCANCj4g RFNOLCB0aGVuIHRoYXQgc2VydmVyIE1VU1Qgc3VwcG9ydCBVVEYtOCBpbiB0aGUgT1JDUFQgcGFy YW1ldGVyLiBUaGlzIGFsc28gDQo+IGhhcyBBQk5GIGltcGFjdC4gDQo+DQoNCm15IGNvbmNlcm4g aXMgdGhhdCwgaWYgd2UgY2hvb3NlIHRvIGFkZCB0aGUgc2VudGVuY2UgYWJvdmUgd2UgY2F1c2Ug YW5vdGhlciBwcm9ibGVtcy4NCg0KSXMgaXQgcmVhbGx5IG5lY2Vzc2FyeSB0byBhZGQgc3VjaCBh IHNlbnRlbmNlPw0KDQoNCj4NCj5XZSBuZWVkIHRvIGFkZDoNCj4gDQo+ICAgZWhsby1wYXJhbSAg PS8gVVRGOC1ub24tYXNjaWkNCj4gDQo+IHRvIGFsbG93IFVURi04IGluIG1haWwsIHJjcHQgYW5k IGRhdGEgcGFyYW1ldGVycy4NCj4gDQo+IDIuIEkgd291bGQgcHJlZmVyIHRoaXMgQUJORiBydWxl IGJlIHJlbW92ZWQ6DQo+IA0KPiAgIHF1b3RlZC1wYWlyU01UUCAgPS8gJWQ5MiBVVEY4LW5vbi1h c2NpaQ0KPiAgICA7IGV4dGVuZCB0aGUgZGVmaW5pdGlvbiBvZiBxdW90ZWQtcGFpclNNVFAgaW4g UkZDNTMyMSwgc2VjdGlvbiA0LjEuMg0KPiANCj4gVGhpcyBpcyBhbiB1bm5lY2Vzc2FyeSBjaGFu Z2UgYW5kIG1ha2VzIDUzMzZiaXMgcXVvdGluZyBldmVuIGxlc3MgDQo+IGNvbnNpc3RlbnQgd2l0 aCA1MzM1YmlzIHF1b3RpbmcuIENvbnNlcnZhdGl2ZSBnZW5lcmF0b3JzIHNob3VsZCBuZXZlciBl bWl0IA0KPiBcIGZvbGxvd2VkIGJ5IGFueXRoaW5nIG90aGVyIHRoYW4gXCBvciBkb3VibGUtcXVv dGUgYW55d2F5LCBzbyBhZGRpbmcgDQo+IGNvbXBsZXhpdHkgdG8gZXhwbGljaXRseSBhbGxvdyBn ZW5lcmF0aW9uIG9mIHVzZWxlc3MgZm9ybXMgaXMgbm90IGhlbHBmdWwuDQo+IA0KDQpJIGFncmVl ZCBpdCBoZXJlLg0KDQpIb3cgYWJvdXQgRGF2ZSdzIGNvbW1lbnRzIGFib3V0IHRoaXMgaXNzdWU/ DQoNCg0KPg0KPiAzLiBJIHN1Z2dlc3QgYWRkaW5nIGEgc3RhdGVtZW50IHRvIHRoZSBlbmQgb2Yg c2VjdGlvbiAzLjU6DQo+IA0KPiAgICAgIFNNVFAgc2VydmVycyBhcmUgZW5jb3VyYWdlZCB0byBk ZXRlY3QgdGhhdCByZWNpcGllbnRzIGNhbiBub3QNCj4gICAgICBhY2NlcHQgaW50ZXJuYXRpb25h bGl6ZWQgZW1haWwgaGVhZGVycyBhbmQgcmV0dXJuIGFuIGVycm9yDQo+ICAgICAgZWFybGllciBp biB0aGUgdHJhbnNhY3Rpb24gd2hlbmV2ZXIgcG9zc2libGUuDQo+IA0KDQpzaW1pbGFyIGNvbW1l bnRzIHRvIERhdmUncw0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaW1h L2N1cnJlbnQvbXNnMDQyODUuaHRtbA0KDQphbm90aGVyIHF1ZXN0aW9uIGlzIA0KDQphZGRpbmcg dGhpcyBzZW50ZW5jZSBpcyBtb3JlIGNsZWFyIHRoYW4gd2l0aG91dCBpdD8NCg0KDQo+IDQuIElu IHNlY3Rpb24gMy41LCBJIHN1Z2dlc3QgYWRkaW5nIGFuIGVuaGFuY2VkIHN0YXR1cyBjb2RlIGZv ciB0aGUgY2FzZSANCj4gd2hlcmUgYSBVLWxhYmVsIGNhbiBub3QgYmUgY29udmVydGVkIHRvIGFu IEEtbGFiZWwuIFRoaXMgaXMgc2VtYW50aWNhbGx5IA0KPiBxdWl0ZSBkaWZmZXJlbnQgZnJvbSBY LjYuNyBhbmQgWC42LjkNCj4gDQoNCg0KYmFzZWQgb24gcmZjNTg5MCwgVS1sYWJlbCBtdXN0IGJl IHRyYW5zZm9ybWVkIHRvIEEtbGFiZWwsIG90aGVyd2lzZSwgaXQgY2FuIG5vdCBiZSBjYWxsZWQg VS1sYWJlbC4NCg0KSm9obiBzaG91bGQgYmUgYXV0aG9yaXRpdmUgYWJvdXQgdGhlIGRlZmludGlv biBvZiBVLWxhYmVsLg0KDQo+IDUuIFNlY3Rpb24gMy43IHNheXMgdGhlIEEtbGFiZWwgZm9ybSBT SE9VTEQgYmUgdXNlZC4gV2hpbGUgSSBkb24ndCBvYmplY3QgDQo+IHRvIHRoYXQgZm9yIHJlbGF5 LCBJIGJlbGlldmUgaXQgc2hvdWxkIGFsc28gc2F5IHRoYXQgc3VibWlzc2lvbiBjbGllbnRzIE1B WSANCj4gdXNlIFUtbGFiZWxzLg0KPiANCg0KYWdyZWUuDQoNCg0KPiA2LiBTZWN0aW9uIDMuNy4z Og0KPiANCj4+ICAgSWYgdGhlIG1lc3NhZ2VzIHRoYXQgaW5jbHVkZSB0cmFjZSBmaWVsZHMgYXJl IHNlbnQgYnkgYW4gVVRGOFNNVFBiaXMtDQo+PiAgIGF3YXJlIFNNVFAgY2xpZW50IG9yIHJlbGF5 IHNlcnZlciB3aXRoIHRoZSBVVEY4U01UUGJpcyBwYXJhbWV0ZXIgYXQNCj4+ICAgTUFJTCBjb21t YW5kcywgdHJhY2UgZmllbGQgdmFsdWVzIFNIT1VMRCB1c2UgdGhlIFUtbGFiZWwgZm9ybSBmb3Ig dGhlDQo+PiAgIGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lLg0KPiANCj4gICAgICBUaGlz IHdvcmRpbmcgc3VnZ2VzdHMgc2VydmVycyBuZWVkIHRvIGNvbnZlcnQgZnJvbSBBLWxhYmVsIHRv DQo+ICAgICAgVS1sYWJlbCBpZiBhIHByZXZpb3VzIHNlcnZlciBkaWQgdGhlIHdyb25nIHRoaW5n LiBJIGRvbid0IHRoaW5rDQo+ICAgICAgdGhhdCdzIHJlYXNvbmFibGUuIEkgc3VnZ2VzdCByZXdv cmRpbmc6DQo+IA0KPiAgICBXaGVuIGFuIFNNVFAgc2VydmVyIGFkZHMgYSB0cmFjZSBmaWVsZCB0 byBhIG1lc3NhZ2UgdGhhdCB3YXMgb3INCj4gICAgd2lsbCBiZSB0cmFuc21pdHRlZCB3aXRoIHRo ZSBVVEY4U01UUGJpcyBNQUlMIEZST00gcGFyYW1ldGVyLCB0aGF0DQo+ICAgIHNlcnZlciBTSE9V TEQgdXNlIHRoZSBVLWxhYmVsIGZvcm0gZm9yIGludGVybmF0aW9uYWxpemVkIGRvbWFpbg0KPiAg ICBuYW1lcyBpbiB0aGF0IG5ldyB0cmFjZSBmaWVsZC4NCj4gDQoNCm9rLCB0aGFua3MuDQoNCg0K PiA3LiBTZWN0aW9uIDMuNy4zIG5lZWRzIHRvIHNheSAoZ2l2ZW4gdGhlIGN1cnJlbnQgQUJORik6 DQo+IA0KPiAgIFRoZSBBdG9tIGZvcm0gb2YgdGhlIElEIGNsYXVzZSBjYW4gY29udGFpbiBub24t QVNDSUkgY2hhcmFjdGVycy4NCj4NCg0KSSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHdvcmRpbmcg YmVsb3cgY292ZXJzIHRoZSAiSUQgY2xhdXNlIiBjYXNlOg0KDQoiV2hlbiB0aGUgVVRGOFNNVFBi aXMgZXh0ZW5zaW9uIGlzIHVzZWQsIHRoZSAnUmV2ZXJzZS0NCiAgIHBhdGgnIGNsYXVzZSBvZiB0 aGUgUmV0dXJuLXBhdGgtbGluZSBtYXkgaW5jbHVkZSBhbiBpbnRlcm5hdGlvbmFsaXplZA0KICAg ZG9tYWluIG5hbWUgdGhhdCB1c2VzIHRoZSBVLWxhYmVsIGZvcm07IFRoZSAnU3RhbXAnIGNsYXVz ZSBvdCB0aGUNCiAgIFRpbWUtc3RhbXAtbGluZSBtYXkgaW5jbHVkZSBhbiBpbnRlcm5hdGlvbmFs aXplZCBkb21haW4gbmFtZSB0aGF0DQogICB1c2VzIHRoZSBVLWxhYmVsIGZvcm0uDQoNCiINCg0K DQp0aGFua3MgYSBsb3QuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4= From klensin@jck.com Tue Jul 26 05:03: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 A299621F8AD9 for ; Tue, 26 Jul 2011 05:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqxRKPSZbk1O for ; Tue, 26 Jul 2011 05:03:40 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 015A521F8AD6 for ; Tue, 26 Jul 2011 05:03:39 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QlgMF-00040u-Md; Tue, 26 Jul 2011 08:03:31 -0400 Date: Tue, 26 Jul 2011 08:03:28 -0400 From: John C Klensin To: dcrocker@bbiw.net, ned+ima@mrochek.com Message-ID: <13981F8F92EEA278CEF5C9DA@JCK-EEE10> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-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, 26 Jul 2011 12:03:40 -0000 --On Tuesday, 26 July, 2011 07:12 -0400 Dave CROCKER wrote: >> 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'll ask a "due diligence" question: > > Are we certain that this long-standing 78-character limit > has not produced hard buffering limits in software that really > make it an installed base of 78-octets? Dave, I've seen far more MUAs in recent years that pay no attention to the 78 character limit then I have ones that, e.g., build fragile buffers around it. Indeed, any contemporary MUA that supports "flowed", binary (BDAT) input, or a few other things already has to be adequately careful about that. However, the question is reasonable. I'd think a reasonable response might be to add a comment in the Security Considerations section to the effect that the use of UTF-8 --and hence inherently variable-length strings that might turn out to be longer than one might naively expect-- calls for caution about buffer sizes and overflows. That would cover not only this case but a number of others in which software might reasonably buffer subfields. For example, A-label to U-label conversion can produce either longer or shorter U-label strings than the A-label original and only the latter is constrained by the DNS limit on label length. I note that this issue is not covered in the Security Considerations section of RFC 3629. john From johnl@iecc.com Tue Jul 26 06:48: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 C992321F8B6A for ; Tue, 26 Jul 2011 06:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLjob9Sld6bG for ; Tue, 26 Jul 2011 06:48:24 -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 1A29621F8B77 for ; Tue, 26 Jul 2011 06:48:23 -0700 (PDT) Received: (qmail 87079 invoked from network); 26 Jul 2011 13:48:23 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 26 Jul 2011 13:48:23 -0000 Received: (qmail 21947 invoked from network); 26 Jul 2011 13:48:22 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 26 Jul 2011 13:48:22 -0000 Date: 26 Jul 2011 13:48:01 -0000 Message-ID: <20110726134801.14575.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: [EAI] EAI additions to POP and IMAP X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 26 Jul 2011 13:48:24 -0000 I've looked at 5721bis and 5738bis. They add a lot more states to the POP and IMAP state machines. So far as I can tell from a read-through, they're OK, but I worry that the new state machines might have dead ends or conflicts. To what extent have either or both of these been implemented, or have people worked out the state machines? R's from Quebec, John From chris.newman@oracle.com Tue Jul 26 07:04:37 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 DC58321F8C92 for ; Tue, 26 Jul 2011 07:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNsNUP9rf-5n for ; Tue, 26 Jul 2011 07:04:37 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6519F21F8B39 for ; Tue, 26 Jul 2011 07:04:37 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6QE4aOY007593; Tue, 26 Jul 2011 14:04:36 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p6QE4ZkC031223; Tue, 26 Jul 2011 14:04:36 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.33.218] (dhcp-rmdc-twvpn-2-vpnpool-10-159-33-218.vpn.oracle.com [10.159.33.218]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LOY0001U1RE2H00@gotmail.us.oracle.com>; Tue, 26 Jul 2011 07:04:35 -0700 (PDT) Date: Tue, 26 Jul 2011 09:57:21 -0400 From: Chris Newman To: Jiankang Yao , ima@ietf.org Message-id: In-reply-to: References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-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, 26 Jul 2011 14:04:38 -0000 --On July 26, 2011 19:51:37 +0800 Jiankang Yao wrote: >> 1. Somewhere this needs to say: If a server advertises both UTF8SMTPbis >> and DSN, then that server MUST support UTF-8 in the ORCPT parameter. >> This also has ABNF impact. >> > > my concern is that, if we choose to add the sentence above we cause > another problems. > > Is it really necessary to add such a sentence? Yes. Without this sentence, a server can implement old DSN and be compliant with the old DSN spec and implement UTF8SMTPbis and be compliant with rfc5336bis, and not support UTF-8 in ORCPT. Such a server will break interoperability with clients that are compliant with 4952bis which requires this behavior. >> 3. I suggest adding a statement to the end of section 3.5: >> >> SMTP servers are encouraged to detect that recipients can not >> accept internationalized email headers and return an error >> earlier in the transaction whenever possible. >> > > similar comments to Dave's > > http://www.ietf.org/mail-archive/web/ima/current/msg04285.html > > another question is > > adding this sentence is more clear than without it? Let me attempt to re-word based on Dave's feedback: SMTP servers are encouraged to detect that recipients can not accept internationalized email headers and generate an error after the RCPT command rather than waiting until after the DATA command to issue an error. >> 4. In section 3.5, I suggest adding an enhanced status code for the case >> where a U-label can not be converted to an A-label. This is semantically >> quite different from X.6.7 and X.6.9 > > based on rfc5890, U-label must be transformed to A-label, otherwise, it > can not be called U-label. > > John should be authoritive about the defintion of U-label. This does not prevent a broken client from generating a UTF-8 domain that is not a valid U-label and thus can not be converted to an A-label. It's an error a well-intentioned client implementer can make by mistake. And it's a subtle error condition a processor may not expect. For those reasons, I think it's useful to distinguish it from the class of "recipient-can't-handle" errors. - Chris From chris.newman@oracle.com Tue Jul 26 07:04:47 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 3CC6621F8C9B for ; Tue, 26 Jul 2011 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-uJ41z-RXCI for ; Tue, 26 Jul 2011 07:04:46 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E721F8C9C for ; Tue, 26 Jul 2011 07:04:46 -0700 (PDT) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6QE4Y7i009819; Tue, 26 Jul 2011 14:04:35 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p6QE4Yed016560; Tue, 26 Jul 2011 14:04:34 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.33.218] (dhcp-rmdc-twvpn-2-vpnpool-10-159-33-218.vpn.oracle.com [10.159.33.218]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LOY0001U1RE2H00@gotmail.us.oracle.com>; Tue, 26 Jul 2011 07:04:33 -0700 (PDT) Date: Tue, 26 Jul 2011 09:41:11 -0400 From: Chris Newman To: dcrocker@bbiw.net Message-id: In-reply-to: <4E2DE1F2.1040906@dcrocker.net> References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <4E2DE1F2.1040906@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-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, 26 Jul 2011 14:04:47 -0000 --On July 25, 2011 17:36:50 -0400 Dave CROCKER wrote: > I'm only going some points needing clarification... > > On 7/25/2011 10:16 AM, Chris Newman wrote: >> 3. I suggest adding a statement to the end of section 3.5: >> >> SMTP servers are encouraged to detect that recipients can not >> accept internationalized email headers and return an error >> earlier in the transaction whenever possible. > > MDAs are often (almost always?) the only entities that know anything > about recipient capabilities. The statement should probably be revised > so that it does not confuse transit relay operators. Often there is an MTA adjacent to an MDA that might be acting like an SMTP proxy or a conditional SMTP proxy. Such an MTA can get rejections from the MDA in response to the RCPT command. > In addition, I don't know what you mean by "earlier in the transaction". > Do you really mean the difference between responding to a RCPT command, > versus a DATA command in the same session, or did you mean something > about the mail relaying sequence? Yes, that's what I meant. - Chris From chris.newman@oracle.com Thu Jul 28 16:51:28 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 DAB8C11E8104 for ; Thu, 28 Jul 2011 16:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.984 X-Spam-Level: X-Spam-Status: No, score=-105.984 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzkfwXWqLhKZ for ; Thu, 28 Jul 2011 16:51:28 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by ietfa.amsl.com (Postfix) with ESMTP id CC8DB11E80A2 for ; Thu, 28 Jul 2011 16:51:25 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6SNpOxu020728 for ; Thu, 28 Jul 2011 23:51:24 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL, v2.4) with ESMTP id p6SNpOE0029595 for ; Thu, 28 Jul 2011 23:51:24 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.46.79] (dhcp-rmdc-twvpn-2-vpnpool-10-159-46-79.vpn.oracle.com [10.159.46.79]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP20013MI9LOF00@gotmail.us.oracle.com> for ima@ietf.org; Thu, 28 Jul 2011 16:51:23 -0700 (PDT) Date: Thu, 28 Jul 2011 18:30:31 -0400 From: Chris Newman To: ima@ietf.org Message-id: <3DA67019F7D7311B2120C842@96B2F16665FF96BAE59E9B90> In-reply-to: <20110711231213.13281.36812.idtracker@ietfa.amsl.com> References: <20110711231213.13281.36812.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5337bis-dsn-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:51:29 -0000 --On July 11, 2011 16:12:13 -0700 internet-drafts@ietf.org wrote: > Title : Internationalized Delivery Status and Disposition Notifications > Author(s) : Tony Hansen > Chris Newman > Alexey Melnikov > Filename : draft-ietf-eai-rfc5337bis-dsn-03.txt > Pages : 21 > Date : 2011-07-11 Although I wrote the bulk of the initial text, I am no longer primary editor and have not reviewed this since a draft of 5337 so was able to look at it with fresh eyes. I believe this is ready for last call and ready to publish. Some very minor issues: 1. The references to UTF8SMTP need to be changed to the UTF8SMTPbis placeholder throughout the document. 2. My company affiliation is out-of-date. It is now Oracle (postal address is still valid). 3. I suggest renaming utf-8-addr-xtext to utf-8-addr-7bit to improve readability. 4. Section 6.2 should say that RFC XXXX replaces the reference to RFC 5337 in the registry. I saw no other issues. - Chris From chris.newman@oracle.com Thu Jul 28 16:51:28 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 EEEFE11E80A2 for ; Thu, 28 Jul 2011 16:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.991 X-Spam-Level: X-Spam-Status: No, score=-105.991 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDHmdhaFLX6s for ; Thu, 28 Jul 2011 16:51:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id 920B811E80D1 for ; Thu, 28 Jul 2011 16:51:26 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6SNpOD2011303 for ; Thu, 28 Jul 2011 23:51:25 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL, v2.4) with ESMTP id p6SNpOE2029595 for ; Thu, 28 Jul 2011 23:51:24 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.46.79] (dhcp-rmdc-twvpn-2-vpnpool-10-159-46-79.vpn.oracle.com [10.159.46.79]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP20013MI9LOF00@gotmail.us.oracle.com> for ima@ietf.org; Thu, 28 Jul 2011 16:51:24 -0700 (PDT) Date: Thu, 28 Jul 2011 18:48:35 -0400 From: Chris Newman To: ima@ietf.org Message-id: In-reply-to: <20110711070808.21862.93387.idtracker@ietfa.amsl.com> References: <20110711070808.21862.93387.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5721bis-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:51:29 -0000 --On July 11, 2011 0:08:08 -0700 internet-drafts@ietf.org wrote: > Title : POP3 Support for UTF-8 > Author(s) : Randall Gellens > Chris Newman > Jiankang Yao > Kazunori Fujiwara > Filename : draft-ietf-eai-rfc5721bis-02.txt > Pages : 13 > Date : 2011-07-11 I have reviewed this document and saw two extremely minor nits: Change "UTF8 Commands" to "UTF8 Command" in section 3.1. Might want to add a note to the RFC editor in section 7 to remove the change history when this is published as an RFC. - Chris From chris.newman@oracle.com Thu Jul 28 16:51:29 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 438A811E80A2 for ; Thu, 28 Jul 2011 16:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.996 X-Spam-Level: X-Spam-Status: No, score=-105.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFfWTjLzEYlu for ; Thu, 28 Jul 2011 16:51:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id BCFAF11E80EF for ; Thu, 28 Jul 2011 16:51:26 -0700 (PDT) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6SNpQKb011308 for ; Thu, 28 Jul 2011 23:51:26 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL, v2.4) with ESMTP id p6SNpPWo038741 for ; Thu, 28 Jul 2011 23:51:25 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.46.79] (dhcp-rmdc-twvpn-2-vpnpool-10-159-46-79.vpn.oracle.com [10.159.46.79]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP20013MI9LOF00@gotmail.us.oracle.com> for ima@ietf.org; Thu, 28 Jul 2011 16:51:25 -0700 (PDT) Date: Thu, 28 Jul 2011 19:39:28 -0400 From: Chris Newman To: ima@ietf.org Message-id: <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> In-reply-to: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> References: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:51:29 -0000 --On July 11, 2011 3:04:44 -0700 internet-drafts@ietf.org wrote: > Title : IMAP Support for UTF-8 > Author(s) : Pete Resnick > Chris Newman > Sean Shen > Filename : draft-ietf-eai-5738bis-01.txt > Pages : 16 > Date : 2011-07-11 I re-read this and tried putting on my somewhat dusty "IMAP implementer hat" rather than my "protocol designer" hat. This unfortunately resulted in a lot of substantive issues :-( There is one change I feel would be most helpful to make. I have learned that LIST extended is quite difficult to implement in a distributed server deployment and I believe that requirement will be a barrier to deployment of this extension. I suggest the document be changed so that the UTF8 LIST selection and return options can be used without requiring full implementation of the LIST extended extension. If the working group has rough consensus to go this direction, then I can provide the ABNF and text so that capability can be provided with or without the LIST extended extension. This benefits servers because servers that make simpler implementation choices (such as UTF-8-only mailboxes) would no longer be forced to implement the entire LIST extended structure to allow interoperability. It also removes a "conditional" from the client (the code the client uses presently has to be different based on the presence of the LIST-EXTENDED capability). I then subsequently asked myself what features could be removed from this document while keeping the document sufficiently complete. There are three options here: 1. Remove the "UTF8=USER" capability. Since there's no password change or account creation command in IMAP, this information is not strictly necessary for clients. UTF-8 usernames and passwords will either work or not based on the identity subsystem. The client doesn't have to know, so unless there's a client that really needs to know for some reason, this should probably be removed just to make the protocol less cluttered. The same could be done for POP3, FYI. 2. Remove the up-conversion requirements. The goal was to make it simpler for clients by allowing clients without 2047/2231 to work sooner. But this might be an additional barrier to server implementers, especially now that down-conversion has become more prominent than in the previous model. I'm thinking the deployment concern may be more important now than the hope of a protocol-designer to get rid of the ugly encodings sooner. 3. Remove the UTF8=APPEND capability. This is a direct server-implementer vs. client-implementer tradeoff. Not having that capability and requiring servers to support this in any mailbox that supports SELECT/EXAMINE UTF8 makes things simpler and more predictable for clients, but at the expense of the server implementer. In hindsight, I think this is one where the server implementers should suffer to make things easier for the clients and to make the protocol look simpler. And yes, you can be annoyed at me proposing simplifications/changes that remove things I put into the original document several years ago ;-) But I must admit that working in the more constrained post-bubble environment has given me a greater respect and attention to the nuances of simplicity. Note that I did not see any technical errors in the current document, so if the WG decided to ignore my guilt-in-hindsight-for-unnecessary-complexity, I would not object to publishing the current document. But I do think it could be made more deployable and that is a significant concern. I'd really appreciate if others spoke up on this topic. - Chris From tony@att.com Thu Jul 28 22:10: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 E871021F8B06 for ; Thu, 28 Jul 2011 22:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9uIWJP7vPW9 for ; Thu, 28 Jul 2011 22:10:18 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6765C21F8B0B for ; Thu, 28 Jul 2011 22:10:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1311916204!30226265!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 7633 invoked from network); 29 Jul 2011 05:10:05 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2011 05:10:05 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6T5AS7a002773 for ; Fri, 29 Jul 2011 01:10:29 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6T5AMRk002588 for ; Fri, 29 Jul 2011 01:10:23 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6T59vWl025838 for ; Fri, 29 Jul 2011 01:09:57 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6T59pN7025762 for ; Fri, 29 Jul 2011 01:09:52 -0400 Received: from [135.70.211.4] (vpn-135-70-211-4.vpn.east.att.com[135.70.211.4]) by maillennium.att.com (mailgw1) with ESMTP id <20110729050950gw100e4li0e> (Authid: tony); Fri, 29 Jul 2011 05:09:50 +0000 X-Originating-IP: [135.70.211.4] Message-ID: <4E32409C.7050203@att.com> Date: Fri, 29 Jul 2011 01:09:48 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Chris Newman References: <20110711231213.13281.36812.idtracker@ietfa.amsl.com> <3DA67019F7D7311B2120C842@96B2F16665FF96BAE59E9B90> In-Reply-To: <3DA67019F7D7311B2120C842@96B2F16665FF96BAE59E9B90> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5337bis-dsn-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: Fri, 29 Jul 2011 05:10:19 -0000 Thanks for the review Chris. More below. On 7/28/2011 6:30 PM, Chris Newman wrote: > --On July 11, 2011 16:12:13 -0700 internet-drafts@ietf.org wrote: >> Title : Internationalized Delivery Status and Disposition > Notifications >> Author(s) : Tony Hansen >> Chris Newman >> Alexey Melnikov >> Filename : draft-ietf-eai-rfc5337bis-dsn-03.txt >> Pages : 21 >> Date : 2011-07-11 > > Although I wrote the bulk of the initial text, I am no longer primary > editor and have not reviewed this since a draft of 5337 so was able to > look at it with fresh eyes. I believe this is ready for last call and > ready to publish. Some very minor issues: > > 1. The references to UTF8SMTP need to be changed to the UTF8SMTPbis > placeholder throughout the document. Where is there an instance where it does *not* reference 5336bis? > 2. My company affiliation is out-of-date. It is now Oracle (postal > address is still valid). fixed > 3. I suggest renaming utf-8-addr-xtext to utf-8-addr-7bit to improve > readability. Seems reasonable. > 4. Section 6.2 should say that RFC XXXX replaces the reference to RFC > 5337 in the registry. Okay. > I saw no other issues. > > - Chris Merci! Tony Hansen From duerst@it.aoyama.ac.jp Fri Jul 29 03:36:01 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 4E14F21F8620 for ; Fri, 29 Jul 2011 03:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.859 X-Spam-Level: X-Spam-Status: No, score=-99.859 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObEzyULyQIP1 for ; Fri, 29 Jul 2011 03:36:00 -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 3332721F85FE for ; Fri, 29 Jul 2011 03:35:59 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p6TAZuOA001773 for ; Fri, 29 Jul 2011 19:35:56 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6969_139b_8aab9056_b9ce_11e0_9cab_001d096c5782; Fri, 29 Jul 2011 19:35:56 +0900 Received: from [IPv6:::1] ([133.2.210.5]:60434) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 29 Jul 2011 19:35:51 +0900 Message-ID: <4E328CFC.2010502@it.aoyama.ac.jp> Date: Fri, 29 Jul 2011 19:35:40 +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: "Aharon (Vladimir) Lanin" References: <4E1EEFFA.1080007@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.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, 29 Jul 2011 10:36:01 -0000 [This is a copy of a comment that I submitted via the Unicode Review Form and posted on the member-only Unicode mailing list. I'm sending it here to have a public record, because this's the mailing list where most of the discussion about this draft in the IETF happened, as far as I'm aware of.] Context ======= I'm an individual Unicode member, but I'll paste this in to the reporting form because that's easier. Please make a 'document' out of it (or more than one, if that helps to better address the issues raised here). I apologize for being late with my comments. Substantive Comments ==================== On substance, I don't agree with every detail of what Jonathan Rosenne, Behdad Esfahbod, Aharon Lanin and others have said, I agree with them in general. If their documents/messages are not properly submitted, I include them herewith by reference. The proposal is an enormous change in the Bidi algorithm, changing its nature in huge ways. Whatever the details eventually may look like, it won't be possible to get everything right in one step, and probably countless tweaks will follow (not that they necessarily will make things better, though). Also, dealing with IRIs will increase the appetite/pressure for dealing with various other syntactical constructs in texts. The introduction of the new algorithm will create numerous compatibility issues (and attack surfaces for phishing, the main thing the proposal tries to address) for a long period of time. Given that the Unicode Consortium has been working hard to address (compared to this issue) even extremely minor compatibility issues re. IDNs in TR46, it's difficult for me to see how this fits together. Taking One Step Back ==================== As one of the first people involved with what's now called IDNs and IRIs, I know that the problem of such Bidi identifiers is extremely hard. The IETF, as the standards organization responsible for (Internationalized) Domain Names and for URIs/IRIs, has taken some steps to address it (there's a Bidi section in RFC 3987 (http://tools.ietf.org/html/rfc3987#section-4), and for IDNs, there is http://tools.ietf.org/html/rfc5893). I don't think these are necessarily sufficient or anything. And I don't think that the proposal at hand is completely useless. However, the proposal touches many aspects (e.g. recognizing IRIs in plain text,...) that are vastly more adequate for definition in another standards organization or where a high-bandwidth coordination with such an organization is crucial (roughly speaking, first on feasibility of various approaches, then on how to split up the work between the relevant organizations, then on coordination in details.) Without such a step back and high-bandwidth coordination, there is a strong chance of producing something highly suboptimal. (Side comment on detail: It would be better for the document to use something like http://tools.ietf.org/html/rfc3987#section-2.2 rather than the totally obscure and no longer maintained http://rfc-ref.org/RFC-TEXTS/3987/chapter2.html, in the same way the Unicode Consortium would probably prefer to have its own Web site referenced for its work rather than some third-party Web site.) Taking Another Step Back ======================== I mention 'high-bandwidth' above. The Unicode "Public Review" process is definitely not suited for this. It has various problems: - The announcements are often very short, formalistic, and cryptic (I can dig up examples if needed.) - The announcements go to a single list; forwarding them to other relevant places is mostly a matter of chance. This should be improved by identifying the relevant parties and contacting them directly. - To find the Web form, one has to traverse several links. - The submission is via a Web form, without any confirmation that the comment has been received. - The space for comments on the form is very small. - There is no way to make a comment public (except for publishing it separately). - There is no official response to a comment submitted to the Web form. One finds out about what happened by chance or not at all. (compare to W3C process, where WGs are required to address each comment formally, and most of them including the responses are public) - The turnaround is slow. Decisions get made (or postponed) at UTCs only. Overall, from an outsider's point of view, the review process and the review form feel like a needle's ear connected to a black hole. [I very much understand that part of the reason the UTC works the way it works is because of its collaboration with ISO/IEC committees. And I don't think any other standards organization has a perfect process. But what's appropriate for one part of the UTCs work may not be appropriate for other parts of its work (such as the matter at hand).] Conclusion ========== I herewith very strongly recommend that the UTC, besides using the upcoming meeting to advance discussion on the technical issues that the proposal raises, a) Postpone the decision to adopt any of the proposed changes, independent of details, until such time as point b) is implemented and executed. b) Swiftly take the necessary steps for a much better, high-bandwith coordination of this topic and the various issues it encompasses, both using the existing liaison mechanism and using public discussion on an appropriate forum (e.g. one of the relevant IETF mailing lists (idna/eai/iri)). c) Seriously work on improving the process for soliciting and addressing comments from the public and relevant stakeholders. Regards, Martin. From chris.newman@oracle.com Fri Jul 29 21:05: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 85A6821F8C70 for ; Fri, 29 Jul 2011 21:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.464 X-Spam-Level: X-Spam-Status: No, score=-105.464 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03a92zNKwIGX for ; Fri, 29 Jul 2011 21:05:18 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF321F8C5F for ; Fri, 29 Jul 2011 21:05:03 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p6U3xMOI015035; Sat, 30 Jul 2011 03:59:22 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p6U3xK4J055159; Sat, 30 Jul 2011 03:59:21 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.50.151] (dhcp-rmdc-twvpn-2-vpnpool-10-159-50-151.vpn.oracle.com [10.159.50.151]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP400F04OESJB00@gotmail.us.oracle.com>; Fri, 29 Jul 2011 20:59:20 -0700 (PDT) Date: Fri, 29 Jul 2011 10:26:36 -0400 From: Chris Newman To: Tony Hansen Message-id: In-reply-to: <4E32409C.7050203@att.com> References: <20110711231213.13281.36812.idtracker@ietfa.amsl.com> <3DA67019F7D7311B2120C842@96B2F16665FF96BAE59E9B90> <4E32409C.7050203@att.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5337bis-dsn-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: Sat, 30 Jul 2011 04:05:18 -0000 --On July 29, 2011 1:09:48 -0400 Tony Hansen wrote: > Thanks for the review Chris. More below. > > On 7/28/2011 6:30 PM, Chris Newman wrote: >> --On July 11, 2011 16:12:13 -0700 internet-drafts@ietf.org wrote: >>> Title : Internationalized Delivery Status and Disposition >> Notifications >>> Author(s) : Tony Hansen >>> Chris Newman >>> Alexey Melnikov >>> Filename : draft-ietf-eai-rfc5337bis-dsn-03.txt >>> Pages : 21 >>> Date : 2011-07-11 >> >> Although I wrote the bulk of the initial text, I am no longer primary >> editor and have not reviewed this since a draft of 5337 so was able to >> look at it with fresh eyes. I believe this is ready for last call and >> ready to publish. Some very minor issues: >> >> 1. The references to UTF8SMTP need to be changed to the UTF8SMTPbis >> placeholder throughout the document. > > Where is there an instance where it does *not* reference 5336bis? The text in RFC 5336 implies that the "UTF8SMTPbis" keyword will be changed to some as-yet-unspecified value at publication. RFC 5337bis needs to use that same unspecified value. If that as-yet-unspecified value is anything other than "UTF8SMTP", then RFC 5337 has a bug. - Chris From alexey.melnikov@isode.com Sun Jul 31 22:18:57 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 A2CFB11E8071 for ; Sun, 31 Jul 2011 22:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qK2kqMhJm4d for ; Sun, 31 Jul 2011 22:18:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id B61C911E8070 for ; Sun, 31 Jul 2011 22:18:56 -0700 (PDT) Received: from [192.168.0.193] (d173-181-76-129.abhsia.telus.net [173.181.76.129]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 1 Aug 2011 06:19:00 +0100 Message-ID: <4E360132.3050803@isode.com> Date: Sun, 31 Jul 2011 21:28:18 -0400 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Chris Newman References: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> In-Reply-To: <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 05:18:57 -0000 Hi Chris, Chris Newman wrote: > --On July 11, 2011 3:04:44 -0700 internet-drafts@ietf.org wrote: >> Title : IMAP Support for UTF-8 >> Author(s) : Pete Resnick >> Chris Newman >> Sean Shen >> Filename : draft-ietf-eai-5738bis-01.txt >> Pages : 16 >> Date : 2011-07-11 > I re-read this and tried putting on my somewhat dusty "IMAP > implementer hat" rather than my "protocol designer" hat. This > unfortunately resulted in a lot of substantive issues :-( > > There is one change I feel would be most helpful to make. I have > learned that LIST extended is quite difficult to implement in a > distributed server deployment and I believe that requirement will be a > barrier to deployment of this extension. I suggest the document be > changed so that the UTF8 LIST selection and return options can be used > without requiring full implementation of the LIST extended extension. > If the working group has rough consensus to go this direction, then I > can provide the ABNF and text so that capability can be provided with > or without the LIST extended extension. > > This benefits servers because servers that make simpler implementation > choices (such as UTF-8-only mailboxes) would no longer be forced to > implement the entire LIST extended structure to allow > interoperability. It also removes a "conditional" from the client (the > code the client uses presently has to be different based on the > presence of the LIST-EXTENDED capability). I might be agreeable to this change, but I would like to see a bit more details before unconditionally supporting it. Can you suggest some text/show an example on how this would look like? > I then subsequently asked myself what features could be removed from > this document while keeping the document sufficiently complete. There > are three options here: > > 1. Remove the "UTF8=USER" capability. Since there's no password change > or account creation command in IMAP, this information is not strictly > necessary for clients. UTF-8 usernames and passwords will either work > or not based on the identity subsystem. I tend to agree. > The client doesn't have to know, so unless there's a client that > really needs to know for some reason, this should probably be removed > just to make the protocol less cluttered. The same could be done for > POP3, FYI. Base IMAP (RFC 3501) doesn't require support for non-ASCII usernames. In practice I suspect that many server implementations are ignoring the "ASCII-only" restriction and that UTF-8 usernames are just going to work. I am undecided on whether this capability should be removed or not. I think it is basically advertising whether the identity subsystem supports non-ASCII usernames/passwords or not, so adding advertisement of this capability if a particular identity subsystem is compliant should be easy. If we are going to remove this capability, I would like to at least have a SHOULD about supporting UTF-8 username/passwords. As email addresses are frequently used as IMAP usernames, this can even be a MUST. > 2. Remove the up-conversion requirements. The goal was to make it > simpler for clients by allowing clients without 2047/2231 to work > sooner. But this might be an additional barrier to server > implementers, especially now that down-conversion has become more > prominent than in the previous model. I'm thinking the deployment > concern may be more important now than the hope of a protocol-designer > to get rid of the ugly encodings sooner. +1. > 3. Remove the UTF8=APPEND capability. This is a direct > server-implementer vs. client-implementer tradeoff. Not having that > capability and requiring servers to support this in any mailbox that > supports SELECT/EXAMINE UTF8 makes things simpler and more predictable > for clients, but at the expense of the server implementer. In > hindsight, I think this is one where the server implementers should > suffer to make things easier for the clients and to make the protocol > look simpler. Just to clarify: are you saying that this functionality should always be supported by compliant servers? If yes, do you also propose to remove the UTF-8 signaling in the APPEND command? > And yes, you can be annoyed at me proposing simplifications/changes > that remove things I put into the original document several years ago > ;-) But I must admit that working in the more constrained post-bubble > environment has given me a greater respect and attention to the > nuances of simplicity. > > Note that I did not see any technical errors in the current document, > so if the WG decided to ignore my > guilt-in-hindsight-for-unnecessary-complexity, I would not object to > publishing the current document. But I do think it could be made more > deployable and that is a significant concern. I'd really appreciate if > others spoke up on this topic.