From yaojk@cnnic.cn Mon Jul 2 00:22:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84E811E8183 for ; Mon, 2 Jul 2012 00:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.446 X-Spam-Level: X-Spam-Status: No, score=-98.446 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvdQRB-js8jg for ; Mon, 2 Jul 2012 00:22:19 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id AB1F611E8136 for ; Mon, 2 Jul 2012 00:22:17 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 02 Jul 2012 15:22:14 +0800 Message-ID: <4F5AA2C9DCED4C6FB0BD4C9CA98319B9@LENOVO47E041CF> From: "Jiankang YAO" To: References: <20120629.200541.22052742.fujiwara@jprs.co.jp> Date: Mon, 2 Jul 2012 15:22: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.6157 Subject: Re: [EAI] Test event? 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, 02 Jul 2012 07:22:19 -0000 aXQgaXMgbm90IGEgdGVzdC4gSXQgaXMgYSBmb3JtYWwgc2VuZGluZyBvZiBFQUkgbWFpbCBiYXNl ZCBvbiBFQUkgY29yZW1haWwgc3lzdGVtLg0KVGhlIHRlc3QgaGFzIGJlZW4gZG9uZSBiZWZvcmUg dGhpcyBldmVudCBtYW55IHRpbWVzLg0KDQpKaWFua2FuZyBZYW8NCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206IDxmdWppd2FyYUBqcHJzLmNvLmpwPg0KVG86IDxpbWFAaWV0 Zi5vcmc+DQpTZW50OiBGcmlkYXksIEp1bmUgMjksIDIwMTIgNzowNSBQTQ0KU3ViamVjdDogW0VB SV0gVGVzdCBldmVudD8NCg0KDQo+SSBoZWFyZCB0aGF0IHRlc3QgZXZlbnQgIkdsb2JhbCBUZXN0 IG9mIE11bHRpbGluZ3VhbCBJRE4gRW1haWwiIHdhcw0KPiBob2xkIGxhc3Qgd2Vlay4NCj4gDQo+ IGh0dHA6Ly93d3cuYWZpbGlhcy5pbmZvL2Jsb2dzL3ZoZWRkZXJlbC9hZmlsaWFzLXBhcnRpY2lw YXRlcy1nbG9iYWwtdGVzdC1tdWx0aWxpbmd1YWwtaWRuLWVtYWlsDQo+IA0KPiBEb2VzIHNvbWVv bmUga25vdyBkZXRhaWxzPw0KPiANCj4gLS0NCj4gS2F6dW5vcmkgRnVqaXdhcmEsIEpQUlMgPGZ1 aml3YXJhQGpwcnMuY28uanA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From duerst@it.aoyama.ac.jp Mon Jul 2 03:37:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1AB21F8961 for ; Mon, 2 Jul 2012 03:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.547 X-Spam-Level: X-Spam-Status: No, score=-99.547 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7Rtts3-QifR for ; Mon, 2 Jul 2012 03:37:54 -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 B284521F8964 for ; Mon, 2 Jul 2012 03:37:53 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q62AbkjY009325 for ; Mon, 2 Jul 2012 19:37:48 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5310_0fee_f6ab6812_c431_11e1_b6f9_001d096c5782; Mon, 02 Jul 2012 19:37:46 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39387) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Jul 2012 19:37:47 +0900 Message-ID: <4FF179F8.80607@it.aoyama.ac.jp> Date: Mon, 02 Jul 2012 19:37:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John Levine References: <20120624044616.83062.qmail@joyce.lan> In-Reply-To: <20120624044616.83062.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: internet-drafts@ietf.org, ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-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, 02 Jul 2012 10:37:55 -0000 Hello John, On 2012/06/24 13:46, John Levine wrote: > You can see a diff from -01 here: > > http://www.taugh.com/draft-ietf-eai-mailinglistbis-02-from-1.diff.html > > I went through all the comments and think I addressed them all (which > is not the same as accepting all the suggestions.) Tell me what you > hate, preferably with text. I liked most of what I saw! A few comments: Schemes that permit both URI and IRI forms should use the URI-encoded form described in [RFC3987] abd [RFC6068]. First, "abd" -> "and". Second, "Schemes should" doesn't exactly feel right. Even if this isn't a "normative should", a scheme by itself can do neither right nor wrong. Better change to "For schemes that permit both URI and IRI forms, the URI-encoded form described in [RFC3987] and [RFC6068] should be used." (Passive voice isn't very good either, and I welcome improvements, but I think passive voice (leaving the actor open) is still better than making something an actor which can't act.) The encoding technique specified in [RFC3986] and [RFC3987] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which can lead to unfortunate interactions with percent- encoded URIs or any URI that includes one of those characters. I think this still somewhat misses the point. If mail software forbids %, that's better than if it would treat it as routing, because the % characters in URIs will then be rejected rather than misinterpreted. Second, the text doesn't say how things are actually supposed to work, just what may go wrong. That's a disservice to implementers who may want to get this right. So what about a rewrite along the following lines: The encoding technique specified in [RFC3986] and [RFC3987] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. The correct processing steps when interpreting a mailto: URI are to unescape %-encoding and then to interpret the resulting mail addresses and other information. Unfortunately, not all mail software does this correctly. As a result, % characters indicating URI encoding can be erroneously included in actual mail addresses. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which will make incorrectly un-decoded mail addresses undeliverable, or in very rare, accidental cases, delivered to the wrong addressee. If a program interpreting a mailto: URI knew that the MUA in use were able to handle UTF-8 data, the program could pass the URI in unencoded UTF-8, avoiding problems with misinterpreted percent signs, but at this point there is no standard or even informal way for MUAs to signal EAI capabilities. "Handle UTF-8 data" and "EAI capabilities" are not the same, or don't have to be, at least in the above scenario. And I personally have at least a glimmer of hope that MUAs that are EAI-capable also get the %-encoding thing right. So we may have the following situations: a) IRI in UTF-8, non-EAI MUA, rejects: fine, because we cannot send EAI mail with a non-EAI MUA anyway. b) IRI in UTF-8, non-EAI MUA, blows up or drops (MSB) bits or other havoc: bad! c) IRI in UTF-8, EAI MUA which grocks it: good! d) IRI in UTF-8, EAI MUA which only understands %-encoding: We missed a chance. The right text to write really depends on our judgment about the frequencies of a) vs. b), and c) vs. d). I'd hope that c) and d) are equally frequent, but I have no clue about a) vs. b), sorry. If you give me an estimate, I'll try to prepare some text. Also, note that whether internationalized domain names should be percent-encoded or puny-coded is currently unresolved. This is an improvement on what was there before, but it's still misleading. It's not that this issue is currently unresolved, and in a month or two, or in a year or two, or whatever time frame, it will be resolved. It's that there are two alternatives, and there are reasons for choosing one or the other. So I'd propose to reword this as follows: Also, note that whether internationalized domain names should be percent-encoded or puny-coded depends on the usage context. (You can cite RFC 3986 and/or 3987 here if you want.) References: [I-D.duerst-iri-bis] seems to be superfluous now. Regards, Martin. > R's, > John > > In article<20120624043323.23441.76216.idtracker@ietfa.amsl.com> you write: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Email Address Internationalization Working Group of the IETF. >> >> Title : Mailing Lists and UTF-8 Addresses >> Author(s) : John Levine >> Randall Gellens >> Filename : draft-ietf-eai-mailinglistbis-02.txt >> Pages : 9 >> Date : 2012-06-23 > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Mon Jul 2 05:20:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095F821F88CA for ; Mon, 2 Jul 2012 05:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuV6ltUD8BoJ for ; Mon, 2 Jul 2012 05:20:44 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4168421F88C3 for ; Mon, 2 Jul 2012 05:20:44 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SlfVn-000GNu-6m; Mon, 02 Jul 2012 08:13:51 -0400 Date: Mon, 02 Jul 2012 08:20:34 -0400 From: John C Klensin To: Jiankang YAO , ima@ietf.org Message-ID: <96376E667F8B1B9D3A466759@JcK-HP8200.jck.com> In-Reply-To: <4F5AA2C9DCED4C6FB0BD4C9CA98319B9@LENOVO47E041CF> References: <20120629.200541.22052742.fujiwara@jprs.co.jp> <4F5AA2C9DCED4C6FB0BD4C9CA98319B9@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Test event? 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, 02 Jul 2012 12:20:45 -0000 --On Monday, July 02, 2012 15:22 +0800 Jiankang YAO wrote: > it is not a test. It is a formal sending of EAI mail based on > EAI coremail system. The test has been done before this event > many times. You should confirm this, but my impression was that the meeting was focused almost entirely on Chinese use and conducted primarily (if not exclusively) in Chinese. I think part of the question that is being asked isn't "what was the test?" but "why weren't others invited?". If that is the case, then "discussion about EAI in one language environment" would presumably be the answer. john From barryleiba.mailing.lists@gmail.com Mon Jul 2 07:52:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D172321F85D3 for ; Mon, 2 Jul 2012 07:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri-KKfNLN9X0 for ; Mon, 2 Jul 2012 07:52:34 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A42E221F85C7 for ; Mon, 2 Jul 2012 07:52:33 -0700 (PDT) Received: by bkty8 with SMTP id y8so5020185bkt.31 for ; Mon, 02 Jul 2012 07:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=er4yuBDHaBqKvTFgYAr07o0inD0A3qLux94TvdmzU8c=; b=VorsJ4MWp9C+0pLtquKBNmJfY2vZq+7WZenndEBsbyPtYLM3csFd2sdAIwBEY7av4D gWtCCEQzPQZ6X+kCAR0b5QpLO2UUEzMCiNhJyz1f/SwGuocuObsVaN5yOFe3F/GINSk0 64JdBDuEzy2/KYHyibY5LSQ+lgdt5czob1VhO7EeIMKpbN7kSpQwIiG/F92iXKx+B0Mx JH7hgayYj+eQZ72V5FDk9xlEiAaUQ0c2sN2C+u5LkGnXDohLqcUuirore5sE/vZqNq04 9SVc+bPUSMuj/JsPX6FGx18YE/XwaeNulV7d1PKKvpxxC7wuaPG8EINituZr7EK/TRZU 5NRg== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr8304786lab.23.1341240758161; Mon, 02 Jul 2012 07:52:38 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Mon, 2 Jul 2012 07:52:38 -0700 (PDT) In-Reply-To: References: <20120629.194600.267954516.fujiwara@jprs.co.jp> <47E23F82DAC4C3759799FC7D@JcK-HP8200.jck.com> Date: Mon, 2 Jul 2012 10:52:38 -0400 X-Google-Sender-Auth: FCeiq8aOj7Sa3QN9K6-DqhEN254 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ima@ietf.org Subject: Re: [EAI] popimap-downgrade: How to refer Barry's mini doc ? 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, 02 Jul 2012 14:52:35 -0000 >>> Can we at least get a title and proposed name that can be >>> included in a forward-pointing informative reference? =A0Even if >>> the document is delayed, I'd prefer to see a posted version of >>> the popimap-downgrade draft (so we can start WG LC) RSN. >> >> Sorry: I forgot I had this action item. =A0I'll put a first >> draft out ASAP. =A0I presume it will go as AD sponsored, not as >> a WG item, right? > > Assuming you can find an AD to sponsor it, yes, please. Here's the document, http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group We'll deal with seeing whether Pete will sponsor it next. Note that the first version is -01, because I decided the best way to do it was to replace Section 3.6.2 of RFC 5322, and I posted -00 with an unchanged version of that section, to make DIFFs easier. Barry On Mon, Jul 2, 2012 at 10:46 AM, wrote: > > A new version of I-D, draft-leiba-5322upd-from-group-01.txt > has been successfully submitted by Barry Leiba and posted to the > IETF repository. > > Filename: draft-leiba-5322upd-from-group > Revision: 01 > Title: Update to Internet Message Format to Allow Group Syntax = in the 'From:' Header Field > Creation date: 2012-07-02 > WG ID: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-leiba-5322upd-= from-group-01.txt > Status: http://datatracker.ietf.org/doc/draft-leiba-5322upd-from= -group > Htmlized: http://tools.ietf.org/html/draft-leiba-5322upd-from-grou= p-01 > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-leiba-5322upd= -from-group-01 > > Abstract: > The Internet Message Format (RFC 5322) allows "group" syntax in some > email header fields, such as "To:" and "CC:", but not in "From:". > This document updates RFC 5322 to relax that restriction, allowing > group syntax in "From:". > > > The IETF Secretariat From barryleiba@gmail.com Mon Jul 2 07:57:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3490C21F8512 for ; Mon, 2 Jul 2012 07:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG+JZCpwdPdj for ; Mon, 2 Jul 2012 07:57:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB421F850F for ; Mon, 2 Jul 2012 07:57:46 -0700 (PDT) Received: by qadz3 with SMTP id z3so1909413qad.10 for ; Mon, 02 Jul 2012 07:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=WbMGM2hfankj/SP8QYfRTuRzXosd91oDX/LcbuSV2L8=; b=YJcbChG5pFpjvIahwQgdIf3SrrPbJUfNQQ4O/DgQp69vyoRSFztxqFOltW52r11Ph7 AUZIyx4iBfkOoF/r2+AEPOI3Y4qdAzjFfxcEdc5P6kCRLrapR33r13EHUuL4SWFnjCW/ Pgf/DhPC2QEYMt5u5jQ/dgWViA7obpnk4bmEdUXMivPz0yqpUfLur55crA4e5JwoZKj3 iPXfjHUlT++3LaVQCluxx0+gxOQHilnDyNGDyrGEyfssNTEHIoCcQHAV/u48Ct+cggvb HRCf/c8wtj8hsdt+SK6guSaG/D20h3Ov8to3j9olx3J71CMVddj7buvePl2ML5HBFdWI YK6A== MIME-Version: 1.0 Received: by 10.229.137.9 with SMTP id u9mr6826577qct.107.1341241071438; Mon, 02 Jul 2012 07:57:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Mon, 2 Jul 2012 07:57:51 -0700 (PDT) Date: Mon, 2 Jul 2012 10:57:51 -0400 X-Google-Sender-Auth: bZ0NMYj0j3cH9oQ3YjOQj0qDJMc Message-ID: From: Barry Leiba To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [EAI] draft-leiba-5322upd-from-group discussion 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, 02 Jul 2012 14:57:47 -0000 I think the subject document will do; please review it: http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group The "replacement for 3.6.2" section should be solid except for one issue, noted: one sentence needs to change, for our purposes, and we need to decide how to make the change. If the from field contains more than one address in the address-list, then the sender field, containing the field name "Sender" and a single mailbox specification, MUST appear in the message. I don't believe that we plan to use the "Sender" field in the cases where we'll use group syntax in "From", so that MUST can't stay. The simple change would be to make it SHOULD and have done with it, but I'm not entirely happy with that. The alternative is to leave the MUST, but add "unless...", and then we have to craft the "unless" text. Please also review the Security Considerations, and make sure I got that right. Barry From alexey.melnikov@isode.com Mon Jul 2 09:12:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90A321F86D6 for ; Mon, 2 Jul 2012 09:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKKMafDxodjc for ; Mon, 2 Jul 2012 09:12:06 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3857421F86AF for ; Mon, 2 Jul 2012 09:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1341245530; d=isode.com; s=selector; i=@isode.com; bh=XAHMmKt58R9NY+I7PpvlI3JqpLC7D/dSr5f4defXnNw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vrlaRucWRuWX7ozexMb4Jj2ENkfA/kYnstTd52UHfrt0lVsEdVFFdaqocQ1QASzQgk6ofX tVjlK45qYEeSPaQMmBLhcGyeKbNroIAYPuk2gxo95yhtHdH8DyMjorwgNXYnl88LXaaKvF hY6Em22gvc36jy0K4jlOkkF9h09jcFg=; Received: from [192.168.1.137] ((unknown) [62.3.217.253]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 2 Jul 2012 17:12:09 +0100 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov Message-Id: Date: Mon, 2 Jul 2012 17:12:15 +0100 To: ima@ietf.org X-Mailer: iPad Mail (9B206) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [EAI] Comments on draft-ietf-eai-mailinglistbis-01 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, 02 Jul 2012 16:12:07 -0000 Sorry, forgot to send these earlier: In Section 1, [listheaders] is missing the corresponding reference definition In Section 2.3 VERP probably needs an Informative reference. Section 3.1 will need updating as per existence of the EAI mailto: draft. In 3.1, Sieve needs an Informative reference. Otherwise I thought the document was in a good shape. From duerst@it.aoyama.ac.jp Mon Jul 2 18:39:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5069E21F859B for ; Mon, 2 Jul 2012 18:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.829 X-Spam-Level: X-Spam-Status: No, score=-98.829 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG49YTGaqgaa for ; Mon, 2 Jul 2012 18:39:00 -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 768BB21F859A for ; Mon, 2 Jul 2012 18:38:59 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q631d0Sh027151 for ; Tue, 3 Jul 2012 10:39:00 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2a7f_560b_dce990c4_c4af_11e1_8c35_001d096c566a; Tue, 03 Jul 2012 10:39:00 +0900 Received: from [IPv6:::1] ([133.2.210.1]:46391) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 10:39:04 +0900 Message-ID: <4FF24D31.5050705@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 10:38:57 +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: Alexey Melnikov References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-mailinglistbis-01 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, 03 Jul 2012 01:39:01 -0000 Hello Alex, On 2012/07/03 1:12, Alexey Melnikov wrote: > Sorry, forgot to send these earlier: > > In Section 1, [listheaders] is missing the corresponding reference definition > > In Section 2.3 VERP probably needs an Informative reference. > > Section 3.1 will need updating as per existence of the EAI mailto: draft. Can you say what you think needs updating? Regards, Martin. > In 3.1, Sieve needs an Informative reference. > > > Otherwise I thought the document was in a good shape. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From yaojk@cnnic.cn Tue Jul 3 00:25:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF23311E8147 for ; Tue, 3 Jul 2012 00:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.418 X-Spam-Level: X-Spam-Status: No, score=-98.418 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-qzyeQZuSaW for ; Tue, 3 Jul 2012 00:25:34 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 58D9C11E814E for ; Tue, 3 Jul 2012 00:25:31 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 03 Jul 2012 15:25:14 +0800 Message-ID: <8C987E8C95F7407AB51B95CE95895BAD@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <20120629.200541.22052742.fujiwara@jprs.co.jp> <4F5AA2C9DCED4C6FB0BD4C9CA98319B9@LENOVO47E041CF> <96376E667F8B1B9D3A466759@JcK-HP8200.jck.com> Date: Tue, 3 Jul 2012 15:25: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.6157 Subject: Re: [EAI] Test event? 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, 03 Jul 2012 07:25:36 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47IDxp bWFAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1bHkgMDIsIDIwMTIgODoyMCBQTQ0KU3ViamVj dDogUmU6IFtFQUldIFRlc3QgZXZlbnQ/DQoNCg0KPiANCj4gDQo+IC0tT24gTW9uZGF5LCBKdWx5 IDAyLCAyMDEyIDE1OjIyICswODAwIEppYW5rYW5nIFlBTw0KPiA8eWFvamtAY25uaWMuY24+IHdy b3RlOg0KPiANCj4+IGl0IGlzIG5vdCBhIHRlc3QuIEl0IGlzIGEgZm9ybWFsIHNlbmRpbmcgb2Yg RUFJIG1haWwgYmFzZWQgb24NCj4+IEVBSSBjb3JlbWFpbCBzeXN0ZW0uIFRoZSB0ZXN0IGhhcyBi ZWVuIGRvbmUgYmVmb3JlIHRoaXMgZXZlbnQNCj4+IG1hbnkgdGltZXMuDQo+IA0KPiBZb3Ugc2hv dWxkIGNvbmZpcm0gdGhpcywgYnV0IG15IGltcHJlc3Npb24gd2FzIHRoYXQgdGhlIG1lZXRpbmcN Cj4gd2FzIGZvY3VzZWQgYWxtb3N0IGVudGlyZWx5IG9uIENoaW5lc2UgdXNlIGFuZCBjb25kdWN0 ZWQNCj4gcHJpbWFyaWx5IChpZiBub3QgZXhjbHVzaXZlbHkpIGluIENoaW5lc2UuICBJIHRoaW5r IHBhcnQgb2YgdGhlDQo+IHF1ZXN0aW9uIHRoYXQgaXMgYmVpbmcgYXNrZWQgaXNuJ3QgIndoYXQg d2FzIHRoZSB0ZXN0PyIgYnV0ICJ3aHkNCj4gd2VyZW4ndCBvdGhlcnMgaW52aXRlZD8iLiAgSWYg dGhhdCBpcyB0aGUgY2FzZSwgdGhlbiAiZGlzY3Vzc2lvbg0KPiBhYm91dCBFQUkgaW4gb25lIGxh bmd1YWdlIGVudmlyb25tZW50IiB3b3VsZCBwcmVzdW1hYmx5IGJlIHRoZQ0KPiBhbnN3ZXIuDQo+ IA0KDQoiZGlzY3Vzc2lvbiBhYm91dCBFQUkgaW4gb25lIGxhbmd1YWdlIGVudmlyb25tZW50IiAg bWFrZXMgc2Vuc2UuDQpPbmUgb2YgdGhlIHJlYXNvbnMgdG8gdXNlIGNoaW5lc2UgY2hhcmFjdGVy cyhpbmNsdWRpbmcgc2ltcGxpZmllZCBhbmQgdHJhZHRpb25hbCkgYW5kIGFzY2lpIGNoYXJhY3Rl cnMgaXMgZm9yIGVhc2lseSBoYXZpbmcgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFByb2Zlc3NvciBR aWFuIGFuZCB0aGUgcGFydGljaXBhbnRzLg0KVGhlIGNvbnRlbnRzIG9mIHRoZSBlbWFpbCBpcyBD aGluZXNlLCBhbmQgdGhlIFBob25lIGNhbGwgb3IgdmlkZW8gY2FsbCBpbiB0aGUgbWVldGluZyBh bHNvIHVzZSBDaGluZXNlLg0KVGhlIG1haW4gYXVkaWVuY2Ugb2YgdGhpcyBtZWV0aW5nIGlzIGFs c28gQ2hpbmVzZS4NCg0KTmV4dCB0aW1lLCBJIGhvcGUgdGhhdCBtb3JlIHVzZXJzIG9yIG9yZ2Fu aXphaW9ucyBmcm9tIG1vcmUgY291bnRyaWVzIHN1Y2ggYXMgamFwYW4sICBrb3JlYSwgQXJhYiAg dG8gaGF2ZSBhIGRlbW8uDQoNCkJUVywgaWYgc2VuZG1haWwgLCBxbWFpbCwgcG9zdGZpeCBjYW4g dXBncmFkZSB0byBzdXBwb3J0IEVBSSwgdGhhdCBjb3VsZCBiZSBwZXJmZWN0Lg0KDQpBbnlvbmUg aGFzIHRoZSBuZXdzIGFib3V0IGl0Pw0KDQpKaWFua2FuZyBZYW8NCg0KPiAgICBqb2huDQo+ From sm@resistor.net Tue Jul 3 01:16:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AF921F86EF for ; Tue, 3 Jul 2012 01:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTaiGubeuEz9 for ; Tue, 3 Jul 2012 01:15:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2281521F87C7 for ; Tue, 3 Jul 2012 01:15:58 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q638FqqM017400; Tue, 3 Jul 2012 01:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341303360; bh=HHOfPNBb0F+eVH31kBnD14KS7AUqBHWtO10vGk6PPTU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BoXvSPIaUFiNJ0UHHSLHJtvtxImUw1ZCGHTSbKBe2x9y7Nmv/2zMG9KAet3IFXmrY yQvB0ObNcqyc1TJEEzQv7qD5Sc9Qgsp/CM5c5HGU8obkRRsytt8DF0wVE6adn62yTL qp69VUmw3l7tBinZQMOfzEKbpkylvGdz9j2SpcOk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341303360; i=@resistor.net; bh=HHOfPNBb0F+eVH31kBnD14KS7AUqBHWtO10vGk6PPTU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DA7YEMH0nj5N+10VUf1tfQca9ECJ7MM8TOVLR0bF6zpx2g++sNhqp7iZCuzd0saGW 8r+IyHwGpZB3MJPFUe+vywXs/u34P9m4y4QcqzCXiEGDRvw0O0S7LFsXJkfxxUi0ST xTY8VyiPIGkuyQe04d2t9GtzMzv/9h820/ru142Q= Message-Id: <6.2.5.6.2.20120703004525.091f02b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jul 2012 01:13:00 -0700 To: Jiankang YAO From: SM In-Reply-To: <8C987E8C95F7407AB51B95CE95895BAD@LENOVO47E041CF> References: <20120629.200541.22052742.fujiwara@jprs.co.jp> <4F5AA2C9DCED4C6FB0BD4C9CA98319B9@LENOVO47E041CF> <96376E667F8B1B9D3A466759@JcK-HP8200.jck.com> <8C987E8C95F7407AB51B95CE95895BAD@LENOVO47E041CF> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Test event? 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, 03 Jul 2012 08:16:02 -0000 Hi Jiankang, At 00:25 03-07-2012, Jiankang YAO wrote: >BTW, if sendmail , qmail, postfix can upgrade to support EAI, that >could be perfect. There is a thread at http://news.gmane.org/gmane.mail.postfix.devel/cutoff=2555 for Postfix. There was a change in Postfix not to enforce the strict_mime_encoding_domain check on unknown message subtypes such as message/global. For sendmail, it would likely be "send patch". Regards, -sm From fujiwara@jprs.co.jp Tue Jul 3 03:57:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9724221F87B0 for ; Tue, 3 Jul 2012 03:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn-mq-hBh7sw for ; Tue, 3 Jul 2012 03:57:36 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8656A21F8775 for ; Tue, 3 Jul 2012 03:57:36 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q63AvYxI004851; Tue, 3 Jul 2012 19:57:35 +0900 X-AuditID: ac120820-b7fe56d000000cec-66-4ff2d01e32fd Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 15.F3.03308.E10D2FF4; Tue, 3 Jul 2012 19:57:34 +0900 (JST) Date: Tue, 03 Jul 2012 19:57:34 +0900 (JST) Message-Id: <20120703.195734.183055657.fujiwara@jprs.co.jp> To: barryleiba@computer.org From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsWyRoiFT1fuwid/g9d3dSwOLb7EanF96Tp2 i/YrDewOzB4tq3qZPZYs+cnkcXnla+YA5igum5TUnMyy1CJ9uwSujFv/pzIWLGCuePtkPnMD 4z2mLkZODgkBE4lza1exQNhiEhfurWfrYuTiEBI4yShx4NVsNpAEi4C2xJuba8GKeAWsJT6+ fs8KYosISEss/38aLM4soCjR/nQJ2FBhAVeJD4dPgtlsApISmz+3MoPYnAKBEofedDNBLNjH KDHpywFmiM12EieerwAaygG0QFDi7w5hiJlaEj0zHrND2PIS29/OYZ7AyD8LoWoWkqpZSKoW MDKvYpTJT0vTLU7NSynOTTcw1CupzNfLKigq1ksG0ZsYweHJobCDccYpg0OMAhyMSjy8rfM/ +QuxJpYVV+YeYpTkYFIS5VU6BxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwst9BijHm5JYWZVa lA+TkuZgURLnPX52h5+QQHpiSWp2ampBahFMVoaDQ0mCN/A8UKNgUWp6akVaZk4JQpqJgxNk OA/Q8FiQGt7igsTc4sx0iPwpRkkpcV5BkIQASCKjNA+u9xWjONALwryGIFkeYKqB63oFNJAJ aGDeYrCBJYkIKakGRr0gm7TVx23mmZTHH7/W7brWd+XyAr3Z07yrONZ3zW7KmBgiqW33jO1K pcb7cq/tgTpudf+ua5dXXknwmuEa2/rgzx53mxO3Hn98u3R6zKn6E3vnsqSo3Y2tfGZ+8c/t 5pJZ4T8DnnJWrH8eX8d8KfNhu9seI/eL1QsePl8azCnxsTHg3e66ICWW4oxEQy3mouJEALzy c/vyAgAA Cc: ima@ietf.org Subject: Re: [EAI] popimap-downgrade: How to refer Barry's mini doc ? 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, 03 Jul 2012 10:57:37 -0000 > From: Barry Leiba > Here's the document, > http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group Thank you for very quick submission. I changed popimap-downgrade-06 to refer it. Recent version is here: http://member.wide.ad.jp/~fujiwara/diff.html I will submit popimap-downgrade-06 in this week. Regards, -- Kazunori Fujiwara, JPRS From fujiwara@jprs.co.jp Tue Jul 3 04:13:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD5E21F87F2 for ; Tue, 3 Jul 2012 04:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWFCi1dazIOR for ; Tue, 3 Jul 2012 04:13:28 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 997F421F85D4 for ; Tue, 3 Jul 2012 04:13:28 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q63BDZtv005692 for ; Tue, 3 Jul 2012 20:13:35 +0900 X-AuditID: ac120820-b7fe56d000000cec-dc-4ff2d3dfd84b Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id B5.04.03308.FD3D2FF4; Tue, 3 Jul 2012 20:13:35 +0900 (JST) Date: Tue, 03 Jul 2012 20:13:35 +0900 (JST) Message-Id: <20120703.201335.39184375.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <4F5AA2C9DCED4C6FB0BD4C9CA98319B9@LENOVO47E041CF> <8C987E8C95F7407AB51B95CE95895BAD@LENOVO47E041CF> References: <20120629.200541.22052742.fujiwara@jprs.co.jp> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsWyRoiFT/f+5U/+Bh9fmlpcX7qO3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGcdbVrEULGCpOPjwFXsD4wHmLkZODgkBE4mNKzYxQdhiEhfu rWfrYuTiEBI4ySjRfvsRUBEHB4uAtsTbZUEgNbwCVhIrF1xhA7FFBAQklr1dwAhiCwvISSz6 /g5sDpuApMTmz63MIHM4BXYySqx+B+EICTQySvQ/mckOsc1O4sTzFawgC3gFBCX+7hAGCTML aEn0zHjMDmHLS2x/O4d5AiPfLISqWUiqZiGpWsDIvIpRJj8tTbc4NS+lODfdwFCvpDJfL6ug qFgvGURvYgSHF4fCDsYZpwwOMQpwMCrx8LbO/+QvxJpYVlyZe4hRkoNJSZRX9RJQiC8pP6Uy I7E4I76oNCe1+BCjBAezkggv9xmgHG9KYmVValE+TEqag0VJnPf42R1+QgLpiSWp2ampBalF MFkZDg4lCV4hYBwJCRalpqdWpGXmlCCkmTg4QYbzAA1fCrKYt7ggMbc4Mx0if4pRlWPprRM3 GIVY8vLzUqXEeRlABgmAFGWU5sHNecUoDvSOMO93kBE8wBQCN+EV0HAmoOF5i8GGlyQipKQa GNfp+x6JbltUGF+cuere91PN7Asq8qW7vC517/FfsvpJ2KIlJ3v35/t9/zzZL3kid69NYNqv Le0Hp5Tqr59uG3Vunoue1N1E7SVcNqf22/9ayTBVtebkrfXase4HRVXqH236luYYx2Ol2SQU IvF28etzj8zYlTTv1t47baXk2NBx4M+6+kdFlUosxRmJhlrMRcWJAHWUpAzeAgAA Subject: Re: [EAI] Test event? 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, 03 Jul 2012 11:13:29 -0000 Thanks for Joseph and Yao. > From: Joseph Yee > http://cnnic.cn/dtygg/dtgg/201206/t20120619_29969.html > From: "Jiankang YAO" > it is not a test. It is a formal sending of EAI mail based on EAI coremail system. > From: "Jiankang YAO" > "discussion about EAI in one language environment" makes sense. In many cases, we cannot type another languages. One language environment, people can type email addresses each other. -- Kazunori Fujiwara, JPRS From ned+ima@mrochek.com Sun Jul 8 22:19:46 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D4821F881D for ; Sun, 8 Jul 2012 22:19: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQKb--XfBCo3 for ; Sun, 8 Jul 2012 22:19:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C24921F8818 for ; Sun, 8 Jul 2012 22:19:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHMFVDZI2O00503E@mauve.mrochek.com> for ima@ietf.org; Sun, 8 Jul 2012 22:15:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHLKS3CK340006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 8 Jul 2012 22:15:02 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OHMFVC3IY00006TF@mauve.mrochek.com> Date: Sun, 08 Jul 2012 22:10:55 -0700 (PDT) In-reply-to: "Your message dated Mon, 02 Jul 2012 10:57:51 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Barry Leiba Cc: ima@ietf.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 09 Jul 2012 05:19:46 -0000 > I think the subject document will do; please review it: > http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group > The "replacement for 3.6.2" section should be solid except for one > issue, noted: one sentence needs to change, for our purposes, and we > need to decide how to make the change. > If the from field contains more than one address in the address-list, > then the sender field, containing the field name "Sender" and a > single mailbox specification, MUST appear in the message. > I don't believe that we plan to use the "Sender" field in the cases > where we'll use group syntax in "From", so that MUST can't stay. Then I guess I'm confused. The cases I'm familiar with in EAI at least involve constructing empty groups. The text says "more than one", not "anything other than one", so the MUST would not be violated. If there's a use-case for creating a From: field using a group that ends up containing multiple addreseses, I'd like to know what it is so I can evaluate whether it warrants overrding the MUST. > The > simple change would be to make it SHOULD and have done with it, but > I'm not entirely happy with that. The alternative is to leave the > MUST, but add "unless...", and then we have to craft the "unless" > text. > Please also review the Security Considerations, and make sure I got that > right. The one I don't see is possible exploits involving different clients handling of something that used to not be allowed. Ned From internet-drafts@ietf.org Mon Jul 9 04:23:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D0721F85BB; Mon, 9 Jul 2012 04:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyoJ0rY6jEeW; Mon, 9 Jul 2012 04:23:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF88021F85C5; Mon, 9 Jul 2012 04:23:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120709112346.27684.24793.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 04:23:46 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-popimap-downgrade-06.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, 09 Jul 2012 11:23:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g Group of the IETF. Title : Post-delivery Message Downgrading for Internationalized = Email Messages Author(s) : Kazunori Fujiwara Filename : draft-ietf-eai-popimap-downgrade-06.txt Pages : 20 Date : 2012-07-09 Abstract: The Email Address Internationalization (SMTPUTF8) extension allows UTF-8 characters in mail header fields. Upgraded 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 in traditional message format. In the process, message elements requiring internationalized treatment are recoded or removed and receivers are able to know that they received messages containing such elements even if they cannot treat the internationalized elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-popimap-downgrade-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-popimap-downgrade-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jyee@afilias.info Tue Jul 10 09:13:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA2E11E808C for ; Tue, 10 Jul 2012 09:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.568 X-Spam-Level: X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6881M0ThW3dp for ; Tue, 10 Jul 2012 09:13:19 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1582611E8080 for ; Tue, 10 Jul 2012 09:13:18 -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 1Sod4L-0007Uu-6Q for ima@ietf.org; Tue, 10 Jul 2012 16:13:46 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Sod4L-00063N-8k for ima@ietf.org; Tue, 10 Jul 2012 16:13:45 +0000 Received: by vbal1 with SMTP id l1so132984vba.9 for ; Tue, 10 Jul 2012 09:13:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=mjo/UDjJAL/8e0P/Bp+p6Ap8oAohzJZIy1tLcb+Hxhs=; b=TydQEdhGV50IiTZvszKJI7t5pYjCnQa+QxJIL+sICWVcqFES3M+c+qBgxzJzbQ6rkD GRlyBq2NqbXM9vXNUscHzsvnl8wX36BrKA6y641VOB10u5kVvDjRbkC0lOlGGFg2RMkL QJHmhnkoPYVFJGQmN+CPhOBkao5h4O8IwT8UiNvJtxJ5Kyl/O04MODGKxKTR/nBO6RTd HhCdz54xsyAuyG7XtmYZPX+EdiLj9m7r+wWnBi4rLKHITb7M6GlyaaLzqaZ2kMKwJV9l qAVYrPqqPcLuh4vyTHAg0cg/twOkEHiOqzylTKLqvqzJwqvwBFwseMCox1tFAMHlSBJD fdGw== MIME-Version: 1.0 Received: by 10.221.12.81 with SMTP id ph17mr21292671vcb.47.1341936825011; Tue, 10 Jul 2012 09:13:45 -0700 (PDT) Received: by 10.52.158.34 with HTTP; Tue, 10 Jul 2012 09:13:44 -0700 (PDT) Date: Tue, 10 Jul 2012 12:13:44 -0400 Message-ID: From: Joseph Yee To: John Levine , EAI WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmZ3eZ2sULpOUbRi6Xpltztl6uqcbnmIJjWuIviJsgV/Yvr4AAjPub2DKMkyibCQiJNZhU2 Subject: [EAI] Shepherd report review of mailinglist-02 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, 10 Jul 2012 16:13:20 -0000 Hi. We have just completed a draft of the Shepherd's report and corresponding pass through the document prior to handing the mailinglist document off to IESG. The review turned up several editorial and related issues. =C2=A0If possible, we would like to see them corrected into a -03 before the document is handed off for IETF Last Call. =C2=A0 Getting nits fixed at this point often saves a lot of time quibbling about them later. WG participants: some of these issues are substantive, see notes 8, 9, and 11 below. Authors of other documents. =C2=A0This type of review is a painful and time-consuming process. =C2=A0I used to defer parts of it until AUTH48, but have learned my lesson: it needs to be done either before we request IETF Last Call, during or after that Last Call when ADs or other members of the community start nit-picking, or during AUTH48. =C2=A0It only gets more painful at later stages. =C2=A0 If possible, review your own documents to see if you can spot and fix these sorts of things before I/we have to. John, if you don't have time to make these changes within the next few days but can supply document source and any comments, we will try to get a new version out. =C2=A0we really, really want this document in IETF LC before Vancouver if that is at all all possible and we are running out of time. (1) Abstract Please change "does not offer implementation or deployment advice." to "does not specify a protocol or offer implementation or deployment advice." or, if you prefer "does not specify protocol changes or offer implementation or deployment advice." =C2=A0 =C2=A0 Reason: The Shepherd's Report format contains a lot of =C2=A0 =C2=A0 =C2=A0 =C2=A0 questions that are really relevant only to prot= ocol specs. =C2=A0 =C2=A0 =C2=A0 =C2=A0 The writeup becomes much more clear if one can = say "not a =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol spec" and that is less likely to be ni= t-picked if =C2=A0 =C2=A0 =C2=A0 =C2=A0 the abstract says that up front. (2) Introduction, paragraph 3. Text reads "...This agent sets the envelope return address..." Please either insert "normally" or "usually" in front of "sets" or provide a citation to something that requires this. =C2=A0If you want to go down the latter path, the relevant citation is Section 3.9 of RFC 5321 but note that a narrow reading of those text essentially prohibits a mail exploder from adding "List-*" headers. Nit: s/rathern/rather/ (3) Section 1.1, 1.2, and maybe elsewhere. Nit: "mailing list agent" is fine, as is "mailing list exploder" (the term used in RFC 5321) but making mailing lists animate can only cause confusion. =C2=A0So "Some mailing lists alter message header fields..." needs adjustment. (4) Section 1.2, first sentence Did you want "...mail transport protocol does not differentiate between..." (5) Section 1.2, paragraph 3 Old: =C2=A0 =C2=A0 =C2=A0 =C2=A0 "first, mailing lists might choose to reject al= l messages =C2=A0 =C2=A0 =C2=A0 =C2=A0 from internationalized addresses." New: =C2=A0 =C2=A0 =C2=A0 =C2=A0 "first, mailing list agents might choose to rej= ect all messages =C2=A0 =C2=A0 =C2=A0 =C2=A0 from internationalized addresses perhaps becaus= e they have =C2=A0 =C2=A0 =C2=A0 =C2=A0 not been upgraded to handle such messages." Reason: A little obscure otherwise. =C2=A0And see note (3) supra. Old: =C2=A0 =C2=A0 =C2=A0 =C2=A0 if the members are UTF-8 New: =C2=A0 =C2=A0 =C2=A0 =C2=A0 if the members are SMTPUTF8 Reason: That has been the convention in the WG and we really don't need someone reminding us during IETF LC that a message that contains nothing but ASCII characters is perfectly valid UTF-8. =C2=A0Same comment about "EAI messages", etc. (6) Section 1.2, paragraph 4. The antecedents in this paragraph are ambiguous. =C2=A0Since the paragraph is important, it should be painfully clear. =C2=A0Suggest (without changing more of your text than necessary): =C2=A0 =C2=A0Conceptually, a mailing list's internationalization can be divided =C2=A0 =C2=A0into three capabilities: First, does the list itself have a =C2=A0 =C2=A0non-ASCII submission address or does the message submitter =C2=A0 =C2=A0use a non-ASCII return-path address? =C2=A0Second, does the li= st =C2=A0 =C2=A0manager accept subscriptions for addresses containing =C2=A0 =C2=A0non-ASCII character? =C2=A0And third, does the agent accept =C2=A0 =C2=A0messages that require SMTPUTF8 capabilities even if neither =C2=A0 =C2=A0of the other two conditions apply? Is that what you meant? =C2=A0Note that the rewording also got rid of the idea of a UTF-8 address (see note 5). =C2=A0 FWIW, RFC 5321 thinks that a "return-path" is the name of a header field that doesn't exist prior to final delivery (and a mailing list exploder is essentially prohibited from adding one and is supposed to remove it if it appears). =C2=A0The term you are looking for is probably "reverse-path" or "backward-pointing address" but probably no one will notice this unless he or she spent too much time buried in 5321 and its predecessors. =C2=A0The return-path issue also appears in Section 2.3 and perhaps elsewhere. Also s/EAI messages/SMTPUTF8 messages/, probably globally. (7) Section 2, first paragraph. The paragraph seems to be more confusing than it needs to be. For example, Old: =C2=A0 =C2=A0In both cases, =C2=A0 =C2=A0the message might have only one recipient, or might have =C2=A0 =C2=A0multiple recipients. New: =C2=A0 =C2=A0In both cases, =C2=A0 =C2=A0the message might be addressed only to the list address, or =C2=A0 =C2=A0might have recipients in addition to the lis6. Then the next sentence, which mixes what is coming into the list exploder with what goes out, could be made single-purpose. FWIW, I've never seen a large list handled by putting hundreds of messages into a single SMTP envelope and handing off to a conventional submission server. =C2=A0Even with pipelining, the requirement for a response to each RCPT command is excessive. Unless that has changed since I've been actively involved with email operations, you might want to tone "Often" down a bit. (8) Section 2.1 (warning: substantive) In a world in which we encourage explicit confirmation as part of an email subscription process for other reasons (ones with which you are thoroughly familiar), putting something that requires SMTPUTF8 handling into the automated confirmation message would not be burdensome. =C2=A0Things get complicated if the list management software wants to take some other action if the message is rejected at SMTP time (SMTPUTF8 is not offered by the recipient (would-be subscriber's MTA) or the confirmation does not arrive. =C2=A0But, if the policy is "no address that is not SMTPUTF8-capable need apply" as this paragraph suggests, that seems fairly easy. Whether that is worth mentioning is up to you, or, if anyone has a strong opinion, the WG. (9) Section 2.2. =C2=A0(Substantive) We've essentially said that in-transit message downgrading is impossible unless the message contains no non-ASCII addresses and has non-ASCII material only in header fields in which encoded words can be used. =C2=A0Absent a whole series of provisions that you haven't discussed, a mailing list exploder is in no better shape to downgrade messages for ASCII-only recipients than a relay. =C2=A0But here the text says: =C2=A0 =C2=A0...list =C2=A0 =C2=A0software might divide the recipients into two sets, EAI and ASCII =C2=A0 =C2=A0recipients, and create a downgraded version of EAI list messages to =C2=A0 =C2=A0send to ASCII recipients. Which sounds misleading and/or like handwaving. =C2=A0 =C2=A0It seems to me that you either need to spell out the cases of interest (e.g., "no backward-pointing or additional recipient non-ASCII addresses, no funky headers that cannot be forced into encoded words, no signatures over anything relevant") or otherwise respecify this section. (10) Section 2.3 "EAI name", "EAI bounce address", etc. =C2=A0See note 5. The notion of "modifying" an address is confusing here. =C2=A0What you are really suggesting is the use of an ASCII address instead of the SMTPUTF8 forms that would normally result from applying traditional rules. The RFC Editor will =C2=A0require that you spell out VERP, supply a reference, or both. =C2=A0"Both" is almost certainly preferable. (11) Section 3.1 =C2=A0(possibly substantive in part) Title should be "Internationalized List Headers", "Non-ASCII List Headers", or "SMTPUTF8 List Headers", not "EAI list headers". In paragraph 3: =C2=A0 =C2=A0The most commonly-used URI schemes in List-* headers tend to be HTTP =C2=A0 =C2=A0and mailto, although they sometimes include HTTPS and FTP, and in =C2=A0 =C2=A0principle can contain any valid URI. Use "MAILTO", not "mailto" unless you want you waste your time and ours in a silly argument. Paragraph 4 is problematic because the whole state of IRIs is up in the air right now. =C2=A0It might be better to say something like: =C2=A0 =C2=A0Even if a scheme permits an internationalized form, it =C2=A0 =C2=A0should use a pure ASCII form of the URI described in =C2=A0 =C2=A0[RFC3986]. =C2=A0Future work may extend =C2=A0 =C2=A0these header fields or define replacements to directly support non-encoded UTF-8 outside the ASCII repertoire in these and other header fields, but in the absence of such extension =C2=A0 =C2=A0or replacement, non-ASCII characters can only be included by encoding them as ASCII. That avoids references to anything but 3986, which is very stable. =C2=A0Even though this is an Informational document, the statement as originally written creates normative references to 3867 =C2=A0and should create one to [I-D.duerst-iri-bis]. =C2=A0We really don't want to go there if it can be avoided. Nit: s/abd/and/ (12) While there have been periodic discussions in the community about whether the "Normative/ Informative" split really makes sense for Informational documents, the current rule is that it is required for the IETF Stream. =C2=A0While we could, in principle, make an issue of it, it hardly seems worth it. =C2=A0So please split the list up. =C2=A0 Note also that [I-D.duerst-iri-bis] does not appear to be =C2=A0not cited in the current draft and the reference is outdated. =C2=A0Please get rid of it unless you have reason to retain it _and_ are absolutely certain that reason doesn't involve a normative reference. I think that ends up with the following Normative: =C2=A0RFC 3986; RFC6409 (marginal, but a full standard and hence harmless) Informative: RFC 2369, RFC 2919 (both mentioned only as examples) Questionable: RFC 3987 and RFC 6068 =C2=A0(used only as part of the specification of "the URI-encoded form" in Section 3.1). =C2=A0I urge getting rid of them entirely since it is easy to have the discussion that is relevant to this document without them and they (especially 3987, which draft-ietf-iri-3987bis (the real [I-D.duerst-iri-bis] proposes to obsolete incompatibly. (13) ID nits tool considers the lack of IANA section an issue, even this document does not specify any protocol. Best, John Klensin and Joseph Yee, co-chair of EAI From johnl@taugh.com Tue Jul 10 09:46:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532B011E81AE for ; Tue, 10 Jul 2012 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5nuC4G90OA0 for ; Tue, 10 Jul 2012 09:46:15 -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 3456511E81A1 for ; Tue, 10 Jul 2012 09:46:13 -0700 (PDT) Received: (qmail 37335 invoked from network); 10 Jul 2012 16:46:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=91d6.4ffc5c70.k1207; bh=KmYtxELHu5R8L2DxLLKYj3iHq63eTr53V+urhAhYNm8=; b=LGHQb73aqd3+0qtlpcm7hp68uXnAbBEe/qnpOaLi6pYwMGPcwXPaPVQY2X+k/S7XYFWXamdCQoUrwZSHjmvX/k5PStkZ/Ytagq2qlqgJ6t0MloHknr+S8QOdAta6N7mDe2ba/R6ELUNssOJSZFI75ilyvzwb/8x8f1PmIA3Blxk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=91d6.4ffc5c70.k1207; bh=KmYtxELHu5R8L2DxLLKYj3iHq63eTr53V+urhAhYNm8=; b=T4TNA3dTKuz83fPSFJKQETwonkCEsrjzlDcSJpJrv4ieZIdkJh9r1X+MFSs2QpaIijAJ5+q7K65PXG9FWKu4UKXtialHoj2R056a4vnS7zBUNtkGTT5ELEk0P2snhckPYGGVP21oP2LIFrpi2cho8pfDQrFGplCoKaqVcsx+BB0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 10 Jul 2012 16:46:18 -0000 Date: 10 Jul 2012 12:46:39 -0400 Message-ID: From: "John R Levine" To: "Joseph Yee" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-1866700939-1341938800=:42005" Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 10 Jul 2012 16:46:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1866700939-1341938800=:42005 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Thanks for this, I'll do a new version later this week. I also have some= =20 comments from the WG that I was waiting to fold in. R's, John On Tue, 10 Jul 2012, Joseph Yee wrote: > Hi. > > We have just completed a draft of the Shepherd's report and > corresponding pass through the document prior to handing > the mailinglist document off to IESG. > > The review turned up several editorial and related issues. =C2=A0If > possible, we would like to see them corrected into a -03 before > the document is handed off for IETF Last Call. =C2=A0 Getting nits > fixed at this point often saves a lot of time quibbling about > them later. > > WG participants: some of these issues are substantive, see > notes 8, 9, and 11 below. > > Authors of other documents. =C2=A0This type of review is a painful > and time-consuming process. =C2=A0I used to defer parts of it until > AUTH48, but have learned my lesson: it needs to be done either > before we request IETF Last Call, during or after that Last > Call when ADs or other members of the community start > nit-picking, or during AUTH48. =C2=A0It only gets more painful at > later stages. =C2=A0 If possible, review your own documents to see > if you can spot and fix these sorts of things before I/we have > to. > > John, if you don't have time to make these changes within the > next few days but can supply document source and any comments, > we will try to get a new version out. =C2=A0we really, really want > this document in IETF LC before Vancouver if that is at all all > possible and we are running out of time. > > (1) Abstract > > Please change "does not offer implementation or deployment > advice." to "does not specify a protocol or offer > implementation or deployment advice." or, if you prefer "does > not specify protocol changes or offer implementation or > deployment advice." > > =C2=A0 =C2=A0 Reason: The Shepherd's Report format contains a lot of > =C2=A0 =C2=A0 =C2=A0 =C2=A0 questions that are really relevant only to pr= otocol specs. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 The writeup becomes much more clear if one ca= n say "not a > =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol spec" and that is less likely to be = nit-picked if > =C2=A0 =C2=A0 =C2=A0 =C2=A0 the abstract says that up front. > > (2) Introduction, paragraph 3. > > Text reads "...This agent sets the envelope return address..." > Please either insert "normally" or "usually" in front of "sets" > or provide a citation to something that requires this. =C2=A0If you > want to go down the latter path, the relevant citation is > Section 3.9 of RFC 5321 but note that a narrow reading of those > text essentially prohibits a mail exploder from adding "List-*" > headers. > > Nit: s/rathern/rather/ > > (3) Section 1.1, 1.2, and maybe elsewhere. > > Nit: "mailing list agent" is fine, as is "mailing list exploder" > (the term used in RFC 5321) but making mailing lists animate > can only cause confusion. =C2=A0So "Some mailing lists alter > message header fields..." needs adjustment. > > (4) Section 1.2, first sentence > > Did you want "...mail transport protocol does not differentiate > between..." > > (5) Section 1.2, paragraph 3 > > Old: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 "first, mailing lists might choose to reject = all messages > =C2=A0 =C2=A0 =C2=A0 =C2=A0 from internationalized addresses." > New: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 "first, mailing list agents might choose to r= eject all messages > =C2=A0 =C2=A0 =C2=A0 =C2=A0 from internationalized addresses perhaps beca= use they have > =C2=A0 =C2=A0 =C2=A0 =C2=A0 not been upgraded to handle such messages." > Reason: A little obscure otherwise. =C2=A0And see note (3) supra. > > Old: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 if the members are UTF-8 > New: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 if the members are SMTPUTF8 > Reason: That has been the convention in the WG and we really > don't need someone reminding us during IETF LC that a message > that contains nothing but ASCII characters is perfectly valid > UTF-8. =C2=A0Same comment about "EAI messages", etc. > > (6) Section 1.2, paragraph 4. > > The antecedents in this paragraph are ambiguous. =C2=A0Since the > paragraph is important, it should be painfully clear. =C2=A0Suggest > (without changing more of your text than necessary): > > =C2=A0 =C2=A0Conceptually, a mailing list's internationalization can be > divided > =C2=A0 =C2=A0into three capabilities: First, does the list itself have a > =C2=A0 =C2=A0non-ASCII submission address or does the message submitter > =C2=A0 =C2=A0use a non-ASCII return-path address? =C2=A0Second, does the = list > =C2=A0 =C2=A0manager accept subscriptions for addresses containing > =C2=A0 =C2=A0non-ASCII character? =C2=A0And third, does the agent accept > =C2=A0 =C2=A0messages that require SMTPUTF8 capabilities even if neither > =C2=A0 =C2=A0of the other two conditions apply? > > Is that what you meant? =C2=A0Note that the rewording also got rid > of the idea of a UTF-8 address (see note 5). =C2=A0 FWIW, RFC 5321 > thinks that a "return-path" is the name of a header field that > doesn't exist prior to final delivery (and a mailing list > exploder is essentially prohibited from adding one and is > supposed to remove it if it appears). =C2=A0The term you are looking > for is probably "reverse-path" or "backward-pointing address" > but probably no one will notice this unless he or she spent too > much time buried in 5321 and its predecessors. =C2=A0The return-path > issue also appears in Section 2.3 and perhaps elsewhere. > > Also s/EAI messages/SMTPUTF8 messages/, probably globally. > > > (7) Section 2, first paragraph. > > The paragraph seems to be more confusing than it needs to be. > > For example, > > Old: > =C2=A0 =C2=A0In both cases, > =C2=A0 =C2=A0the message might have only one recipient, or might have > =C2=A0 =C2=A0multiple recipients. > New: > =C2=A0 =C2=A0In both cases, > =C2=A0 =C2=A0the message might be addressed only to the list address, or > =C2=A0 =C2=A0might have recipients in addition to the lis6. > > Then the next sentence, which mixes what is coming into the > list exploder with what goes out, could be made single-purpose. > > FWIW, I've never seen a large list handled by putting hundreds > of messages into a single SMTP envelope and handing off to a > conventional submission server. =C2=A0Even with pipelining, the > requirement for a response to each RCPT command is excessive. > Unless that has changed since I've been actively involved with > email operations, you might want to tone "Often" down a bit. > > (8) Section 2.1 (warning: substantive) > > In a world in which we encourage explicit confirmation as part > of an email subscription process for other reasons (ones with > which you are thoroughly familiar), putting something that > requires SMTPUTF8 handling into the automated confirmation > message would not be burdensome. =C2=A0Things get complicated if the > list management software wants to take some other action if the > message is rejected at SMTP time (SMTPUTF8 is not offered by > the recipient (would-be subscriber's MTA) or the confirmation > does not arrive. =C2=A0But, if the policy is "no address that is not > SMTPUTF8-capable need apply" as this paragraph suggests, that > seems fairly easy. > > Whether that is worth mentioning is up to you, or, if anyone > has a strong opinion, the WG. > > > (9) Section 2.2. =C2=A0(Substantive) > > We've essentially said that in-transit message downgrading is > impossible unless the message contains no non-ASCII addresses > and has non-ASCII material only in header fields in which > encoded words can be used. =C2=A0Absent a whole series of provisions > that you haven't discussed, a mailing list exploder is in no > better shape to downgrade messages for ASCII-only recipients > than a relay. =C2=A0But here the text says: > > =C2=A0 =C2=A0...list > =C2=A0 =C2=A0software might divide the recipients into two sets, EAI and > ASCII > =C2=A0 =C2=A0recipients, and create a downgraded version of EAI list > messages to > =C2=A0 =C2=A0send to ASCII recipients. > > Which sounds misleading and/or like handwaving. =C2=A0 =C2=A0It seems to > me that you either need to spell out the cases of interest > (e.g., "no backward-pointing or additional recipient non-ASCII > addresses, no funky headers that cannot be forced into encoded > words, no signatures over anything relevant") or otherwise > respecify this section. > > (10) Section 2.3 > > "EAI name", "EAI bounce address", etc. =C2=A0See note 5. > > The notion of "modifying" an address is confusing here. =C2=A0What > you are really suggesting is the use of an ASCII address > instead of the SMTPUTF8 forms that would normally result from > applying traditional rules. > > The RFC Editor will =C2=A0require that you spell out VERP, > supply a reference, or both. =C2=A0"Both" is almost certainly > preferable. > > (11) Section 3.1 =C2=A0(possibly substantive in part) > > Title should be "Internationalized List Headers", "Non-ASCII > List Headers", or "SMTPUTF8 List Headers", not "EAI list > headers". > > In paragraph 3: > =C2=A0 =C2=A0The most commonly-used URI schemes in List-* headers tend to > be HTTP > =C2=A0 =C2=A0and mailto, although they sometimes include HTTPS and FTP, > and in > =C2=A0 =C2=A0principle can contain any valid URI. > > Use "MAILTO", not "mailto" unless you want you waste your time > and ours in a silly argument. > > Paragraph 4 is problematic because the whole state of IRIs is > up in the air right now. =C2=A0It might be better to say something > like: > > =C2=A0 =C2=A0Even if a scheme permits an internationalized form, it > =C2=A0 =C2=A0should use a pure ASCII form of the URI described in > =C2=A0 =C2=A0[RFC3986]. =C2=A0Future work may extend > =C2=A0 =C2=A0these header fields or define replacements to directly > support non-encoded UTF-8 outside the ASCII repertoire in these > and other header fields, but in the absence of such extension > =C2=A0 =C2=A0or replacement, non-ASCII characters can only be included by > encoding them as ASCII. > > That avoids references to anything but 3986, which is very > stable. =C2=A0Even though this is an Informational document, the > statement as originally written creates normative references > to 3867 =C2=A0and should create one to [I-D.duerst-iri-bis]. =C2=A0We > really don't want to go there if it can be avoided. > > Nit: s/abd/and/ > > (12) While there have been periodic discussions in the > community about whether the "Normative/ Informative" split > really makes sense for Informational documents, the current > rule is that it is required for the IETF Stream. =C2=A0While we > could, in principle, make an issue of it, it hardly seems worth > it. =C2=A0So please split the list up. =C2=A0 Note also that > [I-D.duerst-iri-bis] does not appear to be =C2=A0not cited in the > current draft and the reference is outdated. =C2=A0Please get rid of > it unless you have reason to retain it _and_ are absolutely > certain that reason doesn't involve a normative reference. > > I think that ends up with the following > > Normative: =C2=A0RFC 3986; RFC6409 (marginal, but a full standard > and hence harmless) > > Informative: RFC 2369, RFC 2919 (both mentioned only as > examples) > > Questionable: RFC 3987 and RFC 6068 =C2=A0(used only as part of > the specification of "the URI-encoded form" in Section 3.1). =C2=A0I > urge getting rid of them entirely since it is easy to have the > discussion that is relevant to this document without them and > they (especially 3987, which draft-ietf-iri-3987bis (the real > [I-D.duerst-iri-bis] proposes to obsolete incompatibly. > > (13) ID nits tool considers the lack of IANA section an issue, even > this document does not specify any protocol. > > > Best, > John Klensin and Joseph Yee, co-chair of EAI > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1866700939-1341938800=:42005-- From klensin@jck.com Tue Jul 10 09:54:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996C821F8634 for ; Tue, 10 Jul 2012 09:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwrDh4ldPOWy for ; Tue, 10 Jul 2012 09:54:09 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EAE8321F85FF for ; Tue, 10 Jul 2012 09:54:08 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sodch-000LHx-Ra; Tue, 10 Jul 2012 12:49:15 -0400 Date: Tue, 10 Jul 2012 12:54:18 -0400 From: John C Klensin To: John R Levine , Joseph Yee Message-ID: 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 Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 10 Jul 2012 16:54:09 -0000 --On Tuesday, July 10, 2012 12:46 -0400 John R Levine wrote: > Thanks for this, I'll do a new version later this week. I > also have some comments from the WG that I was waiting to fold > in. Excellent. Thanks (from both of us) john From jyee@afilias.info Tue Jul 10 15:31:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23CC21F8600 for ; Tue, 10 Jul 2012 15:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.583 X-Spam-Level: X-Spam-Status: No, score=-5.583 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+HQTdR74NVt for ; Tue, 10 Jul 2012 15:31:49 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74321F85FF for ; Tue, 10 Jul 2012 15:31:46 -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 1Soiyc-0002iK-9f for ima@ietf.org; Tue, 10 Jul 2012 22:32:15 +0000 Received: from mail-vc0-f178.google.com ([209.85.220.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Soiyc-00017E-90 for ima@ietf.org; Tue, 10 Jul 2012 22:32:14 +0000 Received: by vcdm8 with SMTP id m8so388554vcd.9 for ; Tue, 10 Jul 2012 15:32:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=l09WRBrAv19yvPCnVQB5iaJBwnC2k1vxrh1pVXTAEWA=; b=TkjcroDarEnFWjFQZedBItjIWZ2gSMDYLdYSpf4Y/pB7t4I5ex6DveT0XGJu2LNjto 4yMfQGbWXDpoHzTU7H6z4S1/ppALhQhiikf+IE7PANuGWghxoNDZRnXvPX9DQO1aFo8j 0S8VJN0O8oR9qI/QqqjVWu69HfN7h9mbnkc2pY8N5W3/e5N/ENdWO6Q0YL8MG9R+lgOc FZHPzz2lEEmLd0/gIuDCRgVPdNzN/LdpyjH2zn1//X6TAq02ylMOFh6ghvOSXnFDhVKI rHJy2Kwi5qZS9CnSCJKUl6t5oDqMzzQPfnmljzswPvhSE4AsgcHxFIFjm8fQfDawbORj zQFQ== MIME-Version: 1.0 Received: by 10.52.173.39 with SMTP id bh7mr17939495vdc.101.1341959534127; Tue, 10 Jul 2012 15:32:14 -0700 (PDT) Received: by 10.52.158.34 with HTTP; Tue, 10 Jul 2012 15:32:14 -0700 (PDT) Date: Tue, 10 Jul 2012 18:32:14 -0400 Message-ID: From: Joseph Yee To: EAI WG Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkK9sAx5w5gbcM8HMiQKwUN9E4LPt1ntBkCn5hECmRObVZRGontG4eUZcK9Ureg4oHCkEBw Subject: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 22:31:51 -0000 Hi all, This is the WG Last Call of the following four documents: draft-ietf-eai-rfc5721bis-05 POP3 Support for UTF-8 draft-ietf-eai-5738bis-04 IMAP Support for UTF-8 draft-ietf-eai-popimap-downgrade-06 Post-delivery Message Downgrading for Internationalized Email Messages draft-ietf-eai-simpledowngrade-05 EAI: Simplified POP/IMAP downgrading The Last Call runs for 1 week - from Tuesday July 10 22:00 UTC to Tuesday July 17 23:59 UTC. Regards, Joseph Yee, co-chair of EAI From duerst@it.aoyama.ac.jp Wed Jul 11 02:09:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFC21F864B for ; Wed, 11 Jul 2012 02:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.553 X-Spam-Level: X-Spam-Status: No, score=-99.553 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIkf2LAukV6a for ; Wed, 11 Jul 2012 02:09:16 -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 2CADD21F8623 for ; Wed, 11 Jul 2012 02:09:15 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6B99aGQ031650 for ; Wed, 11 Jul 2012 18:09:36 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 025e_0855_22f391d0_cb38_11e1_9009_001d096c5782; Wed, 11 Jul 2012 18:09:35 +0900 Received: from [IPv6:::1] ([133.2.210.1]:42479) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Jul 2012 18:09:40 +0900 Message-ID: <4FFD42CC.2050109@it.aoyama.ac.jp> Date: Wed, 11 Jul 2012 18:09:32 +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: Joseph Yee References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Levine , EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 11 Jul 2012 09:09:17 -0000 Hello Joseph, John, John, and others, On 2012/07/11 1:13, Joseph Yee wrote: > (11) Section 3.1 > In paragraph 3: > The most commonly-used URI schemes in List-* headers tend to > be HTTP > and mailto, although they sometimes include HTTPS and FTP, > and in > principle can contain any valid URI. > > Use "MAILTO", not "mailto" unless you want you waste your time > and ours in a silly argument. Scheme names are usually written lower-case, so I suggest to streamline this as: The most commonly-used URI schemes in List-* headers tend to be http and mailto, although they sometimes include https and ftp, and in principle can contain any valid URI. > Paragraph 4 is problematic because the whole state of IRIs is > up in the air right now. It might be better to say something > like: > > Even if a scheme permits an internationalized form, it > should use a pure ASCII form of the URI described in > [RFC3986]. Future work may extend > these header fields or define replacements to directly > support non-encoded UTF-8 outside the ASCII repertoire in these > and other header fields, but in the absence of such extension > or replacement, non-ASCII characters can only be included by > encoding them as ASCII. This text would work for me. > That avoids references to anything but 3986, which is very > stable. Even though this is an Informational document, the > statement as originally written creates normative references > to 3867 and should create one to [I-D.duerst-iri-bis]. We > really don't want to go there if it can be avoided. That's fine with me, but I don't really see any problem with referencing RFC 3987. > (12) While there have been periodic discussions in the > community about whether the "Normative/ Informative" split > really makes sense for Informational documents, the current > rule is that it is required for the IETF Stream. While we > could, in principle, make an issue of it, it hardly seems worth > it. So please split the list up. Note also that > [I-D.duerst-iri-bis] does not appear to be not cited in the > current draft and the reference is outdated. Please get rid of > it unless you have reason to retain it _and_ are absolutely > certain that reason doesn't involve a normative reference. Yes, please. I think this is just a leftover from a previous version of the draft. > I think that ends up with the following > > Normative: RFC 3986; RFC6409 (marginal, but a full standard > and hence harmless) > > Informative: RFC 2369, RFC 2919 (both mentioned only as > examples) > > Questionable: RFC 3987 and RFC 6068 (used only as part of > the specification of "the URI-encoded form" in Section 3.1). I > urge getting rid of them entirely since it is easy to have the > discussion that is relevant to this document without them and > they (especially 3987, which draft-ietf-iri-3987bis (the real > [I-D.duerst-iri-bis] proposes to obsolete incompatibly. As draft-ietf-iri-3987bis isn't yet done, its difficult to say exactly, but while there are many changes and tweaks in the details, the basic principles are exactly the same. Saying that you can't cite RFC 3987 because there's a WG that is working on updating it would be about the same as saying you can't cite RFC 2616 (HTTP) because there's a WG working on updating it. Regards, Martin. From klensin@jck.com Wed Jul 11 05:23:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B98F21F8540 for ; Wed, 11 Jul 2012 05:23:02 -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.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHgF+XsiZOIM for ; Wed, 11 Jul 2012 05:23:01 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9282A21F851C for ; Wed, 11 Jul 2012 05:23:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sovrr-000Nb8-A1; Wed, 11 Jul 2012 08:18:07 -0400 Date: Wed, 11 Jul 2012 08:23:09 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Joseph Yee Message-ID: <1D9CE813F887BED5617677D2@JcK-HP8200.jck.com> In-Reply-To: <4FFD42CC.2050109@it.aoyama.ac.jp> References: <4FFD42CC.2050109@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: John Levine , EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 11 Jul 2012 12:23:02 -0000 Hi Martin, Thanks for the comments -- partial responses below. --On Wednesday, July 11, 2012 18:09 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: >... >> (11) Section 3.1 >=20 >> In paragraph 3: >> The most commonly-used URI schemes in List-* headers tend >> to be HTTP >> and mailto, although they sometimes include HTTPS and = FTP, >> and in >> principle can contain any valid URI. >>=20 >> Use "MAILTO", not "mailto" unless you want you waste your = time >> and ours in a silly argument. >=20 > Scheme names are usually written lower-case, so I suggest to > streamline this as: >=20 > The most commonly-used URI schemes in List-* headers tend to > be http > and mailto, although they sometimes include https and ftp, and > in principle can contain any valid URI. wfm. Our concern was only about having some in upper case and some in lower. >... > As draft-ietf-iri-3987bis isn't yet done, its difficult to say > exactly, but while there are many changes and tweaks in the > details, the basic principles are exactly the same. Saying > that you can't cite RFC 3987 because there's a WG that is > working on updating it would be about the same as saying you > can't cite RFC 2616 (HTTP) because there's a WG working on The difference is that the group revising HTTP seems to be bound by strict upward compatibility. The (tentative) decision to change the role of IRIs from "UI overlay" to "separate protocol element mostly suitable for new protocols" is a significant modification that calls 3987 into question. My own guess is that, even if IRIs continue down that path, a profile will evolve that is strictly upward compatible with 3987 and that would be suitable for discussion in this sort of paragraph. But the timing of development of the two specs is exquisitely bad. thanks and regards, john From johnl@taugh.com Wed Jul 11 07:16:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4521F865F for ; Wed, 11 Jul 2012 07:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZgKLWner6Wz for ; Wed, 11 Jul 2012 07:16:48 -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 6E39721F8642 for ; Wed, 11 Jul 2012 07:16:34 -0700 (PDT) Received: (qmail 52710 invoked from network); 11 Jul 2012 14:17:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=cde5.4ffd8ae0.k1207; bh=zVg8p04BL5PvRRqomWAgvGwmPaWw6p+clBG26nAdzWU=; b=On8RiukQbQqRW90Rq/9H1U9xET8PrW+EKA0uaxQHDQv8Rl9zQbIxM5EmNB3J7M7FymgJF65qoVSeZKG5a7w1UpPk/ISeh21Yhiqhx5iDSSXu7kJxhav4jl6FJzdCtxj647S9JBtZ1Pyvc+Vq+WDpcJgypJSNwBbMQA05SeARO7w= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=cde5.4ffd8ae0.k1207; bh=zVg8p04BL5PvRRqomWAgvGwmPaWw6p+clBG26nAdzWU=; b=hYAwJCGxLwVrHr18RbZb/eGPBTTT0icOSjINJ8UiMAhwwC4m/vaodbf7hVQtAKA6pecbU0hDmvCltRxMghZkJHjDqvENGyWirrOUMs4Zro/ZBvGARujVR9QpuDhtiFtB6X+1enVOliKSxjVXun3o6R9dKF7R5pAyvM9Vo3uOd10= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 11 Jul 2012 14:16:42 -0000 Date: 11 Jul 2012 10:17:03 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <1D9CE813F887BED5617677D2@JcK-HP8200.jck.com> References: <4FFD42CC.2050109@it.aoyama.ac.jp> <1D9CE813F887BED5617677D2@JcK-HP8200.jck.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 11 Jul 2012 14:16:49 -0000 >> The most commonly-used URI schemes in List-* headers tend to >> be http and mailto, although they sometimes include https and ftp, and >> in principle can contain any valid URI. > > wfm. Our concern was only about having some in upper case and > some in lower. The editors have a style book, and I presume that they will adjust stuff like this to match the style as they do the normal copy edit. Why argue about it here? R's, John From barryleiba.mailing.lists@gmail.com Wed Jul 11 12:02:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB1B11E8101 for ; Wed, 11 Jul 2012 12:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKPZJnKgSOQP for ; Wed, 11 Jul 2012 12:01:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7E11E809B for ; Wed, 11 Jul 2012 12:01:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2291714lbb.31 for ; Wed, 11 Jul 2012 12:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dCeN3/okJ48MKO2D4ApnuzLFiwNw4T9QsgFcJZmz2Sc=; b=PJxKO3Z87Tiv0gsDm/rnweltYcIhMPpasyI/zLwdwXVOBLVSSxcYfd/73MNSYzFyEi 1OBmK2uswnLo/+gENaVuADrRjgs7uYFzEftmVH6sXxbu9+ymo4Uqk7dkXSVVUrD2rjz0 VOyuegE8yx0oEpY0QINTfjU4O3vrwyyCxnsthOg6t8ClIuGkQfvcMiGu5gDrGGqK1Okd ELw5F4unz4XHondXlYQ8/X91nPG0/BiHgJvytB1EnWXRQCQ7QLVbl4h2hyE2wYPcKwSy 9sUr2C7/g/t81dK10W8Ui6pzMJv1DnKdiFRRjZjqwDPOGBSChSEOMzRS8R7xoQl/UJu2 UY8g== MIME-Version: 1.0 Received: by 10.112.36.130 with SMTP id q2mr22008006lbj.44.1342033349560; Wed, 11 Jul 2012 12:02:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Wed, 11 Jul 2012 12:02:29 -0700 (PDT) In-Reply-To: <01OHMFVC3IY00006TF@mauve.mrochek.com> References: <01OHMFVC3IY00006TF@mauve.mrochek.com> Date: Wed, 11 Jul 2012 15:02:29 -0400 X-Google-Sender-Auth: Ao3te2UCwO24dZgrvC2lqexQfI8 Message-ID: From: Barry Leiba To: ned+ima@mrochek.com Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 11 Jul 2012 19:02:00 -0000 >> If the from field contains more than one address in the address-list, >> then the sender field, containing the field name "Sender" and a >> single mailbox specification, MUST appear in the message. > >> I don't believe that we plan to use the "Sender" field in the cases >> where we'll use group syntax in "From", so that MUST can't stay. > > Then I guess I'm confused. The cases I'm familiar with in EAI at least involve > constructing empty groups. The text says "more than one", not "anything > other than one", so the MUST would not be violated. > > If there's a use-case for creating a From: field using a group that > ends up containing multiple addreseses, I'd like to know what it is so I can > evaluate whether it warrants overrding the MUST. Hm, good point. The text in question was written with the idea of "from" being mailboxes, and it's not clear that the sender always knows how groups will expand. But now that you say this, I think we can consider that a "group" is a single "address" (as opposed to a multi-address list), and so we can leave that paragraph as is, with the MUST. And so I don't think this is a problem. Does anyone think otherwise? >> Please also review the Security Considerations, and make sure I got that >> right. > > The one I don't see is possible exploits involving different clients handling > of something that used to not be allowed. Good point; I'll craft something for that and post an updated draft. b From internet-drafts@ietf.org Thu Jul 12 14:36:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3D111E80A6; Thu, 12 Jul 2012 14:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is8QfyER2MnZ; Thu, 12 Jul 2012 14:36:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD4A11E80F3; Thu, 12 Jul 2012 14:36: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: 4.30p3 Message-ID: <20120712213648.7450.32408.idtracker@ietfa.amsl.com> Date: Thu, 12 Jul 2012 14:36:48 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-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, 12 Jul 2012 21:36: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 Workin= g Group of the IETF. Title : Mailing Lists and non-ASCII Addresses Author(s) : John Levine Randall Gellens Filename : draft-ietf-eai-mailinglistbis-03.txt Pages : 9 Date : 2012-07-12 Abstract: This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses, but does not specify protocol changes or offer implementation or deployment advice. *NOTE TO REVIEWERS: Missing or odd-looking references between sections are due to bugs in xml2rfc. The XML is OK, and the HTML output looks reasonable.* The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-mailinglistbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-mailinglistbis-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-mailinglistbis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnl@taugh.com Thu Jul 12 14:44:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F9611E80CB for ; Thu, 12 Jul 2012 14:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDI4-Khg5I2k for ; Thu, 12 Jul 2012 14:44:28 -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 F367811E80BB for ; Thu, 12 Jul 2012 14:44:27 -0700 (PDT) Received: (qmail 32958 invoked from network); 12 Jul 2012 21:45:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=80bc.4fff455d.k1207; bh=mBCgF6T8xmRw+i8dCDGm0Ldou822iaYW+K6QSpb0hTY=; b=Yht3z3hc458Gg//Kj8KcYlaJgQKbT2mcZJnIk4TPxF3mVExLpCItM3ClFNl2RyyUaP9507A3AOYAsyo7fadG/8kY5IZHqjODUy9NjctBQIWOC8rFrLhnYB0onpTIFw8WHao8CX1gwjWqDljpkeKz6TKLwDIPXzwUGZ3CzsnGfDs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=80bc.4fff455d.k1207; bh=mBCgF6T8xmRw+i8dCDGm0Ldou822iaYW+K6QSpb0hTY=; b=Ad495vNk+aZDZ8GSs+4K+droJL7Gf5AeU9kS14W3q7TiI0PVgLyUdZYBO0khXh8sqoRsF7tUVGxWNb13pXrnpo8G306wuymRNs+hGfeOmTx3MoaIG9NUEQbBbYYe9l8FW2vVhCuf8eZTGDYx4O/FjDnPElrP17MhGQ+2dy3HJUY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 12 Jul 2012 21:44:39 -0000 Date: 12 Jul 2012 17:45:01 -0400 Message-ID: From: "John R Levine" To: "Joseph Yee" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-1805897199-1342129501=:66870" Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 12 Jul 2012 21:44:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1805897199-1342129501=:66870 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE OK, I've posted an -03 that I think takes into consideration everyone's=20 comments. The comment that lists are inanimate messages while list agents= =20 are software was a good one, that let me go through and make the document= =20 (I think) considerably clearer. Just so you don't think I ignored you: > FWIW, I've never seen a large list handled by putting hundreds > of messages into a single SMTP envelope and handing off to a > conventional submission server. It's quite common now, e.g., one of Mailman's normal config options. > In a world in which we encourage explicit confirmation as part > of an email subscription process for other reasons (ones with > which you are thoroughly familiar), putting something that > requires SMTPUTF8 handling into the automated confirmation > message would not be burdensome. I didn't do that for two reasons. One is that while requiring signup=20 confirmation usually a good idea, there are real situations where it's not= =20 needed, and this is the wrong place to argue about list policies. Also,=20 this could apply to lists where the manager is upgrading an existing list= =20 to EAI, and getting all of a list's subscribers to reconfirm is, ah,=20 challenging. So it mentions it as an option, not as advice. > We've essentially said that in-transit message downgrading is > impossible unless the message contains no non-ASCII addresses > and has non-ASCII material only in header fields in which > encoded words can be used. =C2=A0Absent a whole series of provisions > that you haven't discussed, a mailing list exploder is in no > better shape to downgrade messages for ASCII-only recipients > than a relay. Already discussed later on, added references. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1805897199-1342129501=:66870-- From klensin@jck.com Thu Jul 12 16:08:24 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1D21F8602 for ; Thu, 12 Jul 2012 16:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH1L+xVOzs6X for ; Thu, 12 Jul 2012 16:08:23 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CD51821F8601 for ; Thu, 12 Jul 2012 16:08:23 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SpSQ0-00020c-SK; Thu, 12 Jul 2012 19:03:32 -0400 Date: Thu, 12 Jul 2012 19:08:42 -0400 From: John C Klensin To: John R Levine , Joseph Yee Message-ID: In-Reply-To: References: 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: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 12 Jul 2012 23:08:24 -0000 WG participants, I've responded to some of John L's points below -- read or not as you like. Either way, consider this a heads-up that we will ask Pete to start the process of initiating an IETF Last Call in circa 24 hours. So, if there is anything here you don't like, this is your last chance to speak up inside the WG. John, Inline. john --On Thursday, July 12, 2012 17:45 -0400 John R Levine wrote: > OK, I've posted an -03 that I think takes into consideration > everyone's comments. The comment that lists are inanimate > messages while list agents are software was a good one, that > let me go through and make the document (I think) considerably clearer. >=20 > Just so you don't think I ignored you: >=20 >> FWIW, I've never seen a large list handled by putting = hundreds >> of messages into a single SMTP envelope and handing off to a >> conventional submission server. >=20 > It's quite common now, e.g., one of Mailman's normal config options. Ack. Thanks for clarifying. >> In a world in which we encourage explicit confirmation as = part >> of an email subscription process for other reasons (ones with >> which you are thoroughly familiar), putting something that >> requires SMTPUTF8 handling into the automated confirmation >> message would not be burdensome. >=20 > I didn't do that for two reasons. One is that while requiring > signup confirmation usually a good idea, there are real > situations where it's not needed, and this is the wrong place > to argue about list policies.=20 Absolutely. > Also, this could apply to lists > where the manager is upgrading an existing list to EAI, and > getting all of a list's subscribers to reconfirm is, ah, > challenging. So it mentions it as an option, not as advice. Wfm. I just wanted to be sure that, if anyone asked, Joseph and I could say "yes, we considered doing that and decided no to". =20 >> We've essentially said that in-transit message downgrading is >> impossible unless the message contains no non-ASCII addresses >> and has non-ASCII material only in header fields in which >> encoded words can be used. =C2=A0Absent a whole series of >> provisions that you haven't discussed, a mailing list >> exploder is in no better shape to downgrade messages for >> ASCII-only recipients than a relay. >=20 > Already discussed later on, added references. Again, thanks. From duerst@it.aoyama.ac.jp Fri Jul 13 04:04:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5B321F86AF for ; Fri, 13 Jul 2012 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.559 X-Spam-Level: X-Spam-Status: No, score=-99.559 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPRHaIBfIwKR for ; Fri, 13 Jul 2012 04:04:16 -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 EA5BC21F86A6 for ; Fri, 13 Jul 2012 04:04:14 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6DB4bf3001557 for ; Fri, 13 Jul 2012 20:04:39 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0e2f_fbcb_892cabf0_ccda_11e1_937d_001d096c566a; Fri, 13 Jul 2012 20:04:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38032) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 13 Jul 2012 20:04:40 +0900 Message-ID: <500000BE.50706@it.aoyama.ac.jp> Date: Fri, 13 Jul 2012 20:04:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <4FFD42CC.2050109@it.aoyama.ac.jp> <1D9CE813F887BED5617677D2@JcK-HP8200.jck.com> In-Reply-To: <1D9CE813F887BED5617677D2@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Levine , EAI WG Subject: [EAI] Confusion about backwards-compatibility of 3987bis/IRIs (was: Re: Shepherd report review of mailinglist-02) 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, 13 Jul 2012 11:04:16 -0000 [cc'ed to the mailing list of the IRI WG] [IRI WG: This came up in the EAI (email address internationalization) WG when discussing http://tools.ietf.org/rfcdiff?url2=draft-ietf-eai-mailinglistbis-03, but it's highly relevant to the work of the IRI WG.] [Everybody, please remove the EAI mailing list if you continue discussing IRIs, and the IRI mailing list if you discuss the mailinglistbis draft, thanks!] Hello John, On 2012/07/11 21:23, John C Klensin wrote: > Hi Martin, >> ... >> As draft-ietf-iri-3987bis isn't yet done, its difficult to say >> exactly, but while there are many changes and tweaks in the >> details, the basic principles are exactly the same. Saying >> that you can't cite RFC 3987 because there's a WG that is >> working on updating it would be about the same as saying you >> can't cite RFC 2616 (HTTP) because there's a WG working on > > The difference is that the group revising HTTP seems to be bound > by strict upward compatibility. The (tentative) decision to > change the role of IRIs from "UI overlay" to "separate protocol > element mostly suitable for new protocols" is a significant > modification that calls 3987 into question. My own guess is > that, even if IRIs continue down that path, a profile will > evolve that is strictly upward compatible with 3987 and that > would be suitable for discussion in this sort of paragraph. But > the timing of development of the two specs is exquisitely bad. While busy with my day job, I have been able to think about the above. I think that what you say above is factually mistaken, but I'm starting to see where in the IRI discussion you might have picked up some faint signals (one of your many strengths) that let to your interpretation. But let's go back to the facts: First (I'm probably writing this for the third time), IRIs as defined in RFC 3987 are not "UI overlay". They are clearly defined as protocol elements. Of course, they can also be used as "UI overlay", http would be a good example. IDNs are a parallel. Second, of course IRIs are suitable for new protocols. But that also has been the case in RFC 3987. Third, as far as I know, there is no need for a "profile" that is strictly upward compatible with RFC 3987. Although the 'modus operandi' of the IRI WG may be a bit more chaotic than the well-oiled machine of the httpbis WG, the goal, at least as far as I am concerned, is exactly the same: To update the spec so that it can be clearer and better aligned with actual practice. Fourth, possibly the most serious compatibility issue between RFC 3987 as written and 3987bis as it is currently written is the change from IDNA 2003 to IDNA 2008. There are varying opinions on whether the change from IDNA 2003 to 2008 was the right thing to do. But given that you are one of the main contributors to IDNA 2008, I wouldn't expect you to throw the first stone at 3987bis. Fifth, while there have been some proposals in the IRI WG (and before in chartering it) to be more liberal with backwards compatibility and compatibility with URIs, I have tried hard (and I think up to now succeeded) to make sure that this is preserved. As an example, the charter of the IRI WG contains an explicit provision that a rechartering is needed should any updates to RFC 3986 become necessary. So I think what's unfortunate is not the timing of development of the two specs, but the timing of your confusion. I hope this can be cleared up very soon. If you can point out anything in the actual current 3987bis draft (rather than the discussion surrounding it) that let to your confusion, I'd appreciate it if you could tell the IRI WG, so that we can (if necessary after discussion) fix this as soon as possible. Regards, Martin. From alexey.melnikov@isode.com Fri Jul 13 04:09:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1121F869F for ; Fri, 13 Jul 2012 04:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mMtZ7mZuJAu for ; Fri, 13 Jul 2012 04:09:36 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C721F8688 for ; Fri, 13 Jul 2012 04:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342177834; d=isode.com; s=selector; i=@isode.com; bh=oo+FWywpjBMXT0PDgn7V2ZFZUxLSINSZASW7dFqaL6A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bPomstNAXxfszES+6lNPpUb3wQ+u/4jfuzehSNX+RJLXwPvxxurTqTZxLuFvwcFqn4YToY FAZrVlPz/lX4dPRdBswbOcSKVtZs/ZZxuXwcBr7z7TgBsrATVNdelZhtQzrJ+ex2xyoU9X kPJR/QG9nlPa86Y3urN/wQMIAwrG1Bo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 12:10:34 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5000022C.5020207@isode.com> Date: Fri, 13 Jul 2012 12:10:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: John R Levine References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 11:09:37 -0000 Hi John, On 12/07/2012 22:45, John R Levine wrote: > OK, I've posted an -03 that I think takes into consideration > everyone's comments. The comment that lists are inanimate messages > while list agents are software was a good one, that let me go through > and make the document (I think) considerably clearer. I think you need Informative references for mailto:, http: and ftp: URI schemes. I am not sure why you removed the mailto: reference from the document. But otherwise this looks good to me. From alexey.melnikov@isode.com Fri Jul 13 04:15:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330A921F85B1 for ; Fri, 13 Jul 2012 04:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeKAOnTmIa8i for ; Fri, 13 Jul 2012 04:15:12 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A03521F85AE for ; Fri, 13 Jul 2012 04:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342178171; d=isode.com; s=selector; i=@isode.com; bh=fBhB75WUTIBhEyXSS6Z27GaAYKXhyRKmsqKpYJYbXaQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=V/IzW3C8OIIfg04Ohv3e8bT93IcYNkWlSDAOTAUtbtloc1gWLRulfpwiaBdTZ4op2jFYhw HWNV5qFqFvehkN4iLdoYCxInvitR/LiCljLFBQKv3W0+sC75m7ddRhIZ37Ol6moq6Xjf5w iyRCb1h0hltgSwh1NM1KOs14DcBCpxs=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 12:16:11 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5000037E.2060303@isode.com> Date: Fri, 13 Jul 2012 12:16:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Joseph Yee References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Levine , EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 11:15:13 -0000 On 10/07/2012 17:13, Joseph Yee wrote: > Questionable: RFC 3987 and RFC 6068 (used only as part of > the specification of "the URI-encoded form" in Section 3.1). I > urge getting rid of them entirely since it is easy to have the > discussion that is relevant to this document without them and > they (especially 3987, which draft-ietf-iri-3987bis (the real > [I-D.duerst-iri-bis] proposes to obsolete incompatibly. Sorry, missed this earlier: all URI mentioned in the document need Informative references. I don't think just assuming that readers can find relevant documents is Ok. From duerst@it.aoyama.ac.jp Fri Jul 13 04:26:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8CF21F86EF for ; Fri, 13 Jul 2012 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.565 X-Spam-Level: X-Spam-Status: No, score=-99.565 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXelxUjnQcSZ for ; Fri, 13 Jul 2012 04:26:38 -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 A904521F86EA for ; Fri, 13 Jul 2012 04:26:37 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6DBRD1u017438 for ; Fri, 13 Jul 2012 20:27:13 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0e31_fd5c_b12a5c44_ccdd_11e1_9b24_001d096c566a; Fri, 13 Jul 2012 20:27:12 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52391) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 13 Jul 2012 20:27:15 +0900 Message-ID: <50000609.4020509@it.aoyama.ac.jp> Date: Fri, 13 Jul 2012 20:27:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John R Levine , EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 11:26:38 -0000 Hello John, others, On 2012/07/13 8:08, John C Klensin wrote: > WG participants, > > I've responded to some of John L's points below -- read or not > as you like. Either way, consider this a heads-up that we will > ask Pete to start the process of initiating an IETF Last Call in > circa 24 hours. So, if there is anything here you don't like, > this is your last chance to speak up inside the WG. I'm sorry, but I feel I have to take this chance. As you can see in detail in a mail that I sent a few minutes ago (Subject: Confusion about backwards-compatibility of 3987bis/IRIs), I think that the very recent removal of the reference to RFC 3987 (and possibly also RFC 6068, but then other URI schemes are also not mentioned with a reference) is based on confusion only and is a disservice to the reader. Also, my proposal of different text for the "%-routing problem", which is clearer about the source of the problem, in particular that it's an implementation problem (correct escaping/unescaping) and not an a-priori problem, hasn't been taken into account, and I don't know why. For your reference, here is the current draft text: <<<< The encoding technique specified in [RFC3986] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which can lead to unfortunate interactions with percent-encoded URIs or any URI that includes one of those characters. <<<< and here is (roughly) what I proposed (and still think) it be replaced with: >>>> The encoding technique specified in [RFC3986] and [RFC3987] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. The correct processing steps when interpreting a mailto: URI are to unescape %-encoding and then to interpret the resulting mail addresses and other information. Unfortunately, not all mail software does this correctly. As a result, % characters indicating URI encoding can be erroneously included in actual mail addresses. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which will make incorrectly un-decoded mail addresses undeliverable, or in very rare, accidental cases, delivered to the wrong addressee. <<<< There is some more in http://www.ietf.org/mail-archive/web/ima/current/msg04924.html, which may also benefit from a more careful consideration. Regards, Martin. > John, > > Inline. > > john > > > > --On Thursday, July 12, 2012 17:45 -0400 John R Levine > wrote: > >> OK, I've posted an -03 that I think takes into consideration >> everyone's comments. The comment that lists are inanimate >> messages while list agents are software was a good one, that >> let me go through and make the document (I think) considerably > clearer. >> >> Just so you don't think I ignored you: >> >>> FWIW, I've never seen a large list handled by putting hundreds >>> of messages into a single SMTP envelope and handing off to a >>> conventional submission server. >> >> It's quite common now, e.g., one of Mailman's normal config > options. > > Ack. Thanks for clarifying. > >>> In a world in which we encourage explicit confirmation as part >>> of an email subscription process for other reasons (ones with >>> which you are thoroughly familiar), putting something that >>> requires SMTPUTF8 handling into the automated confirmation >>> message would not be burdensome. >> >> I didn't do that for two reasons. One is that while requiring >> signup confirmation usually a good idea, there are real >> situations where it's not needed, and this is the wrong place >> to argue about list policies. > > Absolutely. > >> Also, this could apply to lists >> where the manager is upgrading an existing list to EAI, and >> getting all of a list's subscribers to reconfirm is, ah, >> challenging. So it mentions it as an option, not as advice. > > Wfm. I just wanted to be sure that, if anyone asked, Joseph and > I could say "yes, we considered doing that and decided no to". > >>> We've essentially said that in-transit message downgrading is >>> impossible unless the message contains no non-ASCII addresses >>> and has non-ASCII material only in header fields in which >>> encoded words can be used. Absent a whole series of >>> provisions that you haven't discussed, a mailing list >>> exploder is in no better shape to downgrade messages for >>> ASCII-only recipients than a relay. >> >> Already discussed later on, added references. > > Again, thanks. > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From alexey.melnikov@isode.com Fri Jul 13 04:51:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCAB21F86B4 for ; Fri, 13 Jul 2012 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXyZvUIbZMyx for ; Fri, 13 Jul 2012 04:51:26 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4521F86AF for ; Fri, 13 Jul 2012 04:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342180345; d=isode.com; s=selector; i=@isode.com; bh=vPJyIe9C7FQKc2QM7S+MJ4OBchSj2ZPr+XE+N1XRqhY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=hz/PtYoSJFDAQ4eLePPWvOSZOfKRN5qGNGATNX4fujfCcqi/P9xC9DTPV3NKfXBAYrXsxY U4T15BsmaNTLA7yBc6m+kM68s33J0Wk1qI8uu7eb2Qe/ixPOuy0Jj0ji1/uiNPO/g0a+Ak qI4gz189R7tFtU8BGslDrOKkjE8rIZM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 12:52:24 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50000BFB.3050405@isode.com> Date: Fri, 13 Jul 2012 12:52:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Joseph Yee References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 11:51:27 -0000 On 10/07/2012 23:32, Joseph Yee wrote: > Hi all, > > This is the WG Last Call of the following four documents: [...] > draft-ietf-eai-5738bis-04 > IMAP Support for UTF-8 This document needs another revision: it has remains of removed functionality all over the remaining sections, in particular: > 1. Introduction > > This specification extends IMAP4rev1 [RFC3501] to permit UTF-8 > [RFC3629] in headers as described in "Internationalized Email > Headers" [RFC6532] . It also adds a mechanism to support mailbox > names, login names, and passwords using the UTF-8 charset. This document doesn't add UTF-8 login names/passwords, as this functionality is already present in the AUTHENTICATE command. > 3. UTF8=ACCEPT IMAP Capability > > The "UTF8=ACCEPT" capability indicates that the server supports UTF-8 > quoted strings, the "UTF8" parameter to SELECT and EXAMINE, UTF8 parameter to SELECT/EXAMINE was removed, so this is no longer correct. However something need to be said about SELECT/EXAMINE, so maybe: -------- the ability to open mailboxes containing EAI messages(*) with SELECT and EXAMINE, -------- (*) - or whatever we call these beasts now... > and UTF-8 > responses from the LIST and LSUB commands. > > > 4. IMAP UTF8 Append Data Extension > > If the "UTF8=ACCEPT" capability is advertised, then the server > accepts UTF-8 headers in the APPEND command message argument. A > client that sends a message with UTF-8 headers to the server MUST > send them using the "UTF8" APPEND data extension. If the server also > advertises the CATENATE capability (as specified in [RFC4469]), the > client can use the same data extension to include such a message in a > CATENATE message part. The ABNF for the APPEND data extension and > CATENATE extension follows: > > utf8-literal = "UTF8" SP "(" literal8 ")" > > append-data =/ utf8-literal > > cat-part =/ utf8-literal > > A server that advertises "UTF8=ACCEPT" MAY fail for \NotUTF8 > mailboxes with a NOT-UTF-8 response code. Delete the above sentence, as this functionality was removed. > If this command does not > fail, it MAY follow the requirements of the IMAP base specification > and [RFC5322] for message fetching. > > 6. UTF8=ONLY Capability > > The "UTF8=ONLY" capability permits an IMAP server to advertise that > it does not support the international mailbox name convention > (modified UTF-7), and does not permit selection or examination of any > mailbox unless the "UTF8" parameter is provided. Delete everything starting from ", and does not permit". > 8. Issues with UTF-8 Header Mailstore > > When an IMAP server uses a mailbox format that supports UTF-8 headers > and it permits selection or examination of that mailbox without the > "UTF8" parameter, Remove "and it permits ... "UTF-8" parameter". > it is the responsibility of the server to comply > with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with > respect to all header information transmitted over the wire. > Mechanisms for 7-bit downgrading to help comply with the standards > are discussed in [popimap-downgrade]. And finally, if we are making all sorts of other simplifications, can be please also drop the whole section 3.1 (as suggested by Dave Cridland and discussed by Arnt and myself)? Thank you, Alexey From alexey.melnikov@isode.com Fri Jul 13 05:12:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27F121F87A9 for ; Fri, 13 Jul 2012 05:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeBc0GkYfRos for ; Fri, 13 Jul 2012 05:12:01 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5427421F87A7 for ; Fri, 13 Jul 2012 05:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342181448; d=isode.com; s=selector; i=@isode.com; bh=sncVib7tADpAcJB8fxoxggBAenLx0YfN91RoMDGdJF4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cGsdZGUGdVz9uAdW8C35ZtUzQZdnBq3SNlJIOnGT9BhKsb4Uw4/osuPDNcZeZbbgNAAYhB CMY6gtq+9jtqCBxuAt1TJGWo57rl2yGDDcwWezYWaf2zdTFWa3XBtRG52/ExFbOHdidmDa /AgietU/RZiVy05LeakfmvAiCfXBEQg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 13:10:48 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5000104D.8010105@isode.com> Date: Fri, 13 Jul 2012 13:10:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Joseph Yee References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:12:02 -0000 On 10/07/2012 23:32, Joseph Yee wrote: > Hi all, > > This is the WG Last Call of the following four documents: > > draft-ietf-eai-rfc5721bis-05 > POP3 Support for UTF-8 I've reviewed this document and it looks ready to me. > draft-ietf-eai-simpledowngrade-05 > EAI: Simplified POP/IMAP downgrading This looks Ok to me as well. From arnt@gulbrandsen.priv.no Fri Jul 13 05:53:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CE621F8802 for ; Fri, 13 Jul 2012 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4zHd1k7c5Vd for ; Fri, 13 Jul 2012 05:53:41 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 361F421F8710 for ; Fri, 13 Jul 2012 05:53:40 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5D570F8EF25; Fri, 13 Jul 2012 12:54:16 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342184055-28531-28530/10/7; Fri, 13 Jul 2012 12:54:15 +0000 Message-Id: <50001A76.9080207@gulbrandsen.priv.no> Date: Fri, 13 Jul 2012 14:54:14 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <50000BFB.3050405@isode.com> In-Reply-To: <50000BFB.3050405@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:53:42 -0000 Alexey wrote: > And finally, if we are making all sorts of other simplifications, can be > please also drop the whole section 3.1 (as suggested by Dave Cridland > and discussed by Arnt and myself)? Uhm. I think you mean to drop the starry quote stuff and allow quoted-string to contain UTF8. Right? If so, a hearty +1 from me. Arnt From alexey.melnikov@isode.com Fri Jul 13 06:09:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2221F880D for ; Fri, 13 Jul 2012 06:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kiSNJmvit0k for ; Fri, 13 Jul 2012 06:09:39 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7846421F880E for ; Fri, 13 Jul 2012 06:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342185038; d=isode.com; s=selector; i=@isode.com; bh=Vd4lcab/JT7EK12zRGa+BvkpHI/lBiKfZ8SDM310H/4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cxqVdqioXu4dr79btDkzMbG5EM/bcdsGDYRTVguRBd4dL4j0D/CXdrMFcdOgMORoL4NTkY h3Ge2IY104kPN0R8/nKEkKkxGigPOdH3Bhrljm9jCd8A2W3spXXkTVB6ooXNo4i3wtgBYH 3iGBAV/nmYxohMuJe5UftQpNBgJ2etc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 14:10:38 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50001E51.40803@isode.com> Date: Fri, 13 Jul 2012 14:10:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Arnt Gulbrandsen References: <50000BFB.3050405@isode.com> <50001A76.9080207@gulbrandsen.priv.no> In-Reply-To: <50001A76.9080207@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 13:09:41 -0000 On 13/07/2012 13:54, Arnt Gulbrandsen wrote: > Alexey wrote: >> And finally, if we are making all sorts of other simplifications, can be >> please also drop the whole section 3.1 (as suggested by Dave Cridland >> and discussed by Arnt and myself)? > > Uhm. I think you mean to drop the starry quote stuff and allow > quoted-string to contain UTF8. ... after ENABLE UTF8=ACCEPT or ENABLE UTF=ONLY. > Right? If so, a hearty +1 from me. Yes. From johnl@taugh.com Fri Jul 13 06:35:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBB21F8686 for ; Fri, 13 Jul 2012 06:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sCH37z42euk for ; Fri, 13 Jul 2012 06:35:55 -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 1C2A621F8671 for ; Fri, 13 Jul 2012 06:35:54 -0700 (PDT) Received: (qmail 40139 invoked from network); 13 Jul 2012 13:36:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=9cca.5000245e.k1207; bh=D6cQFxJRf6ricehcIlYPqBTcVhxcsUsTm+/GH3G6S+w=; b=Fo9sKRS06qDXQZrlL7qnMYarUhzoq+ezinDabzYZUXy4fAEzQ5gAiMM8XC8kQuCm/MsseU1McstiuCWWooWrh0PBVr/1dIQm8pogLvs3LA2ipaeFKbGPQJCSsWS7OZHcJxrXhVu+3+MqI/kO9OuUyevksrClxCa8nWo2/S1laS8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=9cca.5000245e.k1207; bh=D6cQFxJRf6ricehcIlYPqBTcVhxcsUsTm+/GH3G6S+w=; b=l2s1Ozvcw+KMknvyThptVtQSb7WhABHP/4ZjkOj+39ZCgyp9RMUUAt3qvHqbK77Na0fffZ6teisSjh2GH4EZjhSOu15kG3g3qdAuG0NhL5JYxRHRpX5NN/MQ0+OAc/kAIcbKS9FIrUp+tKiBAZ0imEIIs7GdqKOBf2SVKnhP2JY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 13 Jul 2012 13:36:08 -0000 Date: 13 Jul 2012 09:36:29 -0400 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Martin_J=2E_D=C3=BCrst?=" In-Reply-To: <50000609.4020509@it.aoyama.ac.jp> References: <50000609.4020509@it.aoyama.ac.jp> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 13:35:56 -0000 > Also, my proposal of different text for the "%-routing problem", which is > clearer about the source of the problem, in particular that it's an > implementation problem (correct escaping/unescaping) and not an a-priori > problem, hasn't been taken into account, and I don't know why. I looked at your language, and it seemed to me less clear than what's there. The problem is very simple, some MTAs mishandle addresses that contain % signs. All we need to do is note it, not tell people how we think they should fix it or work around it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From johnl@taugh.com Fri Jul 13 06:38:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5921F86C9 for ; Fri, 13 Jul 2012 06:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C8HU8OGC-c8 for ; Fri, 13 Jul 2012 06:38:45 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D8EDE21F86A7 for ; Fri, 13 Jul 2012 06:38:44 -0700 (PDT) Received: (qmail 40638 invoked from network); 13 Jul 2012 13:39:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=9ebb.50002508.k1207; bh=VFVfgPyI8Evs7nZ9OtepDS9wGx8SQh04Bmid8iTfXbk=; b=NXA/9XRfm0tGCFP024A2PkrwOMZIBj2gWq/DLwl9wwxhvffOL8C5v7IeqS7+Ffyte3nXCPCzIy1yCS9xjSxvcu+JClv7lSEv8LHAkR8kLAPjabGccEfphYibgVI8cPHO1VmZBduEChVFwwYNAbp/dyFX+oJ9zNmmQCrUfIz+HeE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=9ebb.50002508.k1207; bh=VFVfgPyI8Evs7nZ9OtepDS9wGx8SQh04Bmid8iTfXbk=; b=oDqzHWTTHKlwsvK58jcaRLj9pfBxWJ8zOs+eBEkHmnWi2qlZnb3jHmiBVTmmsBniRtBMXtMUktL3omoiEFvzP/S/5hWMHO1XL9Z492qBV4BRYsDw9i425u9gIXWaJtfTWldmoaiLgHr1GBPlMGbYE9veKbIyfCvPW4V8z16TeOk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 13 Jul 2012 13:38:58 -0000 Date: 13 Jul 2012 09:39:20 -0400 Message-ID: From: "John R Levine" To: "Alexey Melnikov" In-Reply-To: <5000022C.5020207@isode.com> References: <5000022C.5020207@isode.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 13:38:45 -0000 > I think you need Informative references for mailto:, http: and ftp: URI > schemes. I am not sure why you removed the mailto: reference from the > document. The various URIs only come up in the context of list headers, and there's refefrence to RFC 2369 which defines them and does refer to the sources of the various schemes. If you really think we need to tell people where to find mailto: and http: I can add refererences, but since the only discussion is with respect to % signs in the syntax, not to what they do, I don't see the need. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From alexey.melnikov@isode.com Fri Jul 13 08:08:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC721F8522 for ; Fri, 13 Jul 2012 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrXh6TzlB7LY for ; Fri, 13 Jul 2012 08:08:27 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6010221F851E for ; Fri, 13 Jul 2012 08:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342192167; d=isode.com; s=selector; i=@isode.com; bh=QoToThlKcx/ORve11puNK/rcOj9mEg2zO74VofIiBIU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UIoIXMjIrZSOkIPLJTVyGdtzLq9fpyesyaBnrGRZ5C0QWjQ1i2FwqfMQhNsYE+WGe17vo2 balAROZuvIk1mqXH2MkQRVBWAgCXaEUuNhwziECYgkwyesIalel8XIMdFyhzPgd9xVz3bn XzyWBRZBrS72Y0nQjO0jDxAzoX776Bs=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 16:09:26 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50003A2A.5080005@isode.com> Date: Fri, 13 Jul 2012 16:09:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: John R Levine References: <5000022C.5020207@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 15:08:28 -0000 On 13/07/2012 14:39, John R Levine wrote: >> I think you need Informative references for mailto:, http: and ftp: >> URI schemes. I am not sure why you removed the mailto: reference from >> the document. > > The various URIs only come up in the context of list headers, and > there's refefrence to RFC 2369 which defines them and does refer to > the sources of the various schemes. If you really think we need to > tell people where to find mailto: and http: I can add refererences, > but since the only discussion is with respect to % signs in the > syntax, not to what they do, I don't see the need. I believe the rule is that anything mentioned in the document that is not defined in it needs to be referenced. From johnl@taugh.com Fri Jul 13 08:34:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA54821F85B4 for ; Fri, 13 Jul 2012 08:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXHciri2rDhb for ; Fri, 13 Jul 2012 08:34:21 -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 C36D121F8559 for ; Fri, 13 Jul 2012 08:34:19 -0700 (PDT) Received: (qmail 62258 invoked from network); 13 Jul 2012 15:34:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f330.5000401c.k1207; bh=kzIIoDgJ/vVCDRYYHXMU9GkmXlZ93yfPsTUXNpSUXK4=; b=vPRxrpgfFdOAMfDoKKwOjuYZK/8ZjrSzyjKUkoGFe8aDnedeQIdy3UjYIBiuTCpCLi1BI55578D9qQrj0Jff9QLycj5EYhIq6GoDr9MJ3sR3cDz8omwPZjsKjfSZcm3VnMDE1DFSg6pgAHD5WqGpV8mdHoTY7LM6ubj8722oLjE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f330.5000401c.k1207; bh=kzIIoDgJ/vVCDRYYHXMU9GkmXlZ93yfPsTUXNpSUXK4=; b=d9XO4sTVPUwnUZr4/strUoc9Zs2Esh4pxjW6Vv8fITXPrrQIqOErkbPr3bVk86XCMRmYPO8hfWNIhhvRTEtShvgJPjVsgWA4apxdQ0q4+YsuPTk9NjFvMkBHPROtZa+F6cp0YYlGrvPNe9fzV/kK7hPVmeSEpapExzwzzUR4MOE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 13 Jul 2012 15:34:30 -0000 Date: 13 Jul 2012 11:34:49 -0400 Message-ID: From: "John R Levine" To: "Alexey Melnikov" In-Reply-To: <50003A2A.5080005@isode.com> References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 15:34:21 -0000 > I believe the rule is that anything mentioned in the document that is not > defined in it needs to be referenced. My. there's a can of worms. We don't reference RFC 6531 for SMTPUTF8, 6532 for non-ASCII headers, 5322 for the From, Reply-To, and Sender headers, 5598 for MTA, MDA, and MUA, or 20 for ASCII. RFC 3986, which we do reference, describes all of the URI schemes that we mention. It probably would be a good idea to reference 6531 and 6532, though. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From klensin@jck.com Fri Jul 13 09:03:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5BF21F872A for ; Fri, 13 Jul 2012 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUe7sBi7GpvC for ; Fri, 13 Jul 2012 09:03:41 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77A21F8722 for ; Fri, 13 Jul 2012 09:03:41 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SpiGX-0004QO-5G; Fri, 13 Jul 2012 11:58:49 -0400 Date: Fri, 13 Jul 2012 12:03:59 -0400 From: John C Klensin To: John R Levine , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: <6C34D20CA95EC47E952D8C22@JcK-HP8200.jck.com> In-Reply-To: References: <50000609.4020509@it.aoyama.ac.jp> 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: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 16:03:42 -0000 --On Friday, July 13, 2012 09:36 -0400 John R Levine wrote: >> Also, my proposal of different text for the "%-routing >> problem", which is clearer about the source of the problem, >> in particular that it's an implementation problem (correct >> escaping/unescaping) and not an a-priori problem, hasn't >> been taken into account, and I don't know why. > > I looked at your language, and it seemed to me less clear than > what's there. The problem is very simple, some MTAs mishandle > addresses that contain % signs. All we need to do is note it, > not tell people how we think they should fix it or work around > it. Agreed, but I suggest that there are really two separate problems. The first is the one you mention. The second is that there is a mismatch between the MAILTO syntax and definition (necessitated by the URI syntax) and the specification of 5321, essentially "no one gets to interpret the local part string at all". It is correct to talk about that as an implementation problem, but it is an implementation problem that is so widespread as to justify security warnings, etc. Similar problems --and probably similar appropriate warnings-- apply to the use of a number of special characters (notably "+" and "/" in local parts versus the use of those characters in URIs and HTML. Not the fault of mailto, but traps for the unwary. And we have ample empirical evidence that there are lots of unwary (or indifferent) implementers and implementations out there. These are important issues. Probably RFC 3696 should be updated some day to be more careful and explicit about it. Or perhaps 5321 should be updated to complement the warning that while the spec says that local-parts are case-sensitive one shouldn't depend on it working with one that notes that, while the special characters used in URIs are perfectly valid in local parts according to the spec, one shouldn't plan on having them work either. But I see no advantages, and several disadvantages, of opening up any of that discussion in this document. Again, just my opinion and YMMD. john From klensin@jck.com Fri Jul 13 09:04:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F41721F87DA for ; Fri, 13 Jul 2012 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbQ-xL+F1BZZ for ; Fri, 13 Jul 2012 09:04:11 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5462421F8722 for ; Fri, 13 Jul 2012 09:04:11 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SpiH1-0004Qa-Q2; Fri, 13 Jul 2012 11:59:19 -0400 Date: Fri, 13 Jul 2012 12:04:30 -0400 From: John C Klensin To: Alexey Melnikov , John R Levine Message-ID: <2279587D95E0BCE4B5CDED1E@JcK-HP8200.jck.com> In-Reply-To: <50003A2A.5080005@isode.com> References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 16:04:15 -0000 --On Friday, July 13, 2012 16:09 +0100 Alexey Melnikov wrote: > On 13/07/2012 14:39, John R Levine wrote: >>> I think you need Informative references for mailto:, http: >>> and ftp: URI schemes. I am not sure why you removed the >>> mailto: reference from the document. >> >> The various URIs only come up in the context of list headers, >> and there's refefrence to RFC 2369 which defines them and >> does refer to the sources of the various schemes. If you >> really think we need to tell people where to find mailto: >> and http: I can add refererences, but since the only >> discussion is with respect to % signs in the syntax, not to >> what they do, I don't see the need. > > I believe the rule is that anything mentioned in the document > that is not defined in it needs to be referenced. Then, partially following John's logic, it would be as reasonable (or more so) to clarify that the particular URIs and references to them appear in 2369. Precisely because this document is an informational one that identifies issues rather than a standards track protocol spec, I'd like to minimize the number of reference dependencies to the degree possible. That makes saying (whether explicitly or not) "if you want to understand this part of the discussion, you had better understand 2369, just as other parts of the discussion require some understanding of 5321/5322" more reasonable that trying to review 2369 in line and thereby talking about the particular URIs that might be relevant. Just my opinion, YMMD. john From klensin@jck.com Fri Jul 13 10:11:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5910E21F8690 for ; Fri, 13 Jul 2012 10:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWtDP6GOBZ7V for ; Fri, 13 Jul 2012 10:11:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9363421F8680 for ; Fri, 13 Jul 2012 10:11:16 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SpjK0-0004VK-9B; Fri, 13 Jul 2012 13:06:28 -0400 Date: Fri, 13 Jul 2012 13:11:39 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: <1E40DAB9AEA4D7981FFC7C98@JcK-HP8200.jck.com> In-Reply-To: <50000BFB.3050405@isode.com> References: <50000BFB.3050405@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:11:17 -0000 Grump. All of this was supposed to be cleared up after the Jabber chat. It seems that we cannot get anyone to check the specs until either there is an immanent meeting or a Last Call. So, Steve and/or Chris, when can we expect an update (noting the Monday cutoff)? Or should Joseph and I be looking for a new editor? john --On Friday, July 13, 2012 12:52 +0100 Alexey Melnikov wrote: > On 10/07/2012 23:32, Joseph Yee wrote: >> Hi all, >> >> This is the WG Last Call of the following four documents: > [...] >> draft-ietf-eai-5738bis-04 >> IMAP Support for UTF-8 > This document needs another revision: it has remains of > removed functionality all over the remaining sections, in > particular: > >> 1. Introduction >> >> This specification extends IMAP4rev1 [RFC3501] to permit >> UTF-8 [RFC3629] in headers as described in >> "Internationalized Email Headers" [RFC6532] . It also >> adds a mechanism to support mailbox names, login names, >> and passwords using the UTF-8 charset. > > This document doesn't add UTF-8 login names/passwords, as this > functionality > is already present in the AUTHENTICATE command. > >> 3. UTF8=ACCEPT IMAP Capability >> >> The "UTF8=ACCEPT" capability indicates that the server >> supports UTF-8 quoted strings, the "UTF8" parameter to >> SELECT and EXAMINE, > > UTF8 parameter to SELECT/EXAMINE was removed, so this is no > longer correct. However something need to be said about > SELECT/EXAMINE, so maybe: > > -------- > the ability to open mailboxes containing EAI messages(*) > with SELECT and EXAMINE, > -------- > > (*) - or whatever we call these beasts now... > >> and UTF-8 >> responses from the LIST and LSUB commands. >> >> >> 4. IMAP UTF8 Append Data Extension >> >> If the "UTF8=ACCEPT" capability is advertised, then the >> server accepts UTF-8 headers in the APPEND command message >> argument. A client that sends a message with UTF-8 headers >> to the server MUST send them using the "UTF8" APPEND data >> extension. If the server also advertises the CATENATE >> capability (as specified in [RFC4469]), the client can use >> the same data extension to include such a message in a >> CATENATE message part. The ABNF for the APPEND data >> extension and CATENATE extension follows: >> >> utf8-literal = "UTF8" SP "(" literal8 ")" >> >> append-data =/ utf8-literal >> >> cat-part =/ utf8-literal >> >> A server that advertises "UTF8=ACCEPT" MAY fail for >> \NotUTF8 mailboxes with a NOT-UTF-8 response code. > > Delete the above sentence, as this functionality was removed. > >> If this command does not >> fail, it MAY follow the requirements of the IMAP base >> specification and [RFC5322] for message fetching. >> >> 6. UTF8=ONLY Capability >> >> The "UTF8=ONLY" capability permits an IMAP server to >> advertise that it does not support the international >> mailbox name convention (modified UTF-7), and does not >> permit selection or examination of any mailbox unless the >> "UTF8" parameter is provided. > Delete everything starting from ", and does not permit". > > >> 8. Issues with UTF-8 Header Mailstore >> >> When an IMAP server uses a mailbox format that supports >> UTF-8 headers and it permits selection or examination of >> that mailbox without the "UTF8" parameter, > Remove "and it permits ... "UTF-8" parameter". >> it is the responsibility of the server to comply >> with the IMAP4rev1 base specification [RFC3501] and >> [RFC5322] with respect to all header information >> transmitted over the wire. Mechanisms for 7-bit >> downgrading to help comply with the standards are >> discussed in [popimap-downgrade]. > > And finally, if we are making all sorts of other > simplifications, can be please also drop the whole section 3.1 > (as suggested by Dave Cridland and discussed by Arnt and > myself)? > > Thank you, > Alexey > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From alexey.melnikov@isode.com Fri Jul 13 10:27:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6086D21F8741 for ; Fri, 13 Jul 2012 10:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB5P+QL6muc9 for ; Fri, 13 Jul 2012 10:27:04 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCE821F8736 for ; Fri, 13 Jul 2012 10:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342200459; d=isode.com; s=selector; i=@isode.com; bh=1UnaqBBbEGf/KTcXRsLoJyI6qTEKUnAmbQFsdjNGGgQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FMFs3gv7yKYD5On3Aj1TQMD3qHrzPN+a8hx7OV9o4fsZPR97YbWjpx5uW+ARe1iLtri4FC XQwQC/fSK4Yg1vrWlN6t13UjnI2AWezq12PAvD7boPruZicJYq1AxI9dNg5XxWNcxZp/4L IIRzt3AsYzcSF3BW4Q7EC95IDzuYK/Q=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Jul 2012 18:27:39 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50005AA5.8030400@isode.com> Date: Fri, 13 Jul 2012 18:28:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: John R Levine References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 17:27:05 -0000 On 13/07/2012 16:34, John R Levine wrote: >> I believe the rule is that anything mentioned in the document that is >> not defined in it needs to be referenced. > > My. there's a can of worms. It can be. > We don't reference RFC 6531 for SMTPUTF8, 6532 for non-ASCII headers, > 5322 for the From, Reply-To, and Sender headers, 5598 for MTA, MDA, > and MUA, or 20 for ASCII. > > RFC 3986, which we do reference, describes all of the URI schemes that > we mention. Well, no. It describes the generic syntax. But if one wants to study mailto: definition in more details, there is no reference. > It probably would be a good idea to reference 6531 and 6532, though. Yes. And ASCII, because it is kind of required to understand "non-ASCII" ;-). From jyee@afilias.info Fri Jul 13 12:11:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41FF11E80D2 for ; Fri, 13 Jul 2012 12:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iOlqfK9j7zP for ; Fri, 13 Jul 2012 12:11:28 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4011E8097 for ; Fri, 13 Jul 2012 12:11:27 -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 1SplHX-0005mL-5N for ima@ietf.org; Fri, 13 Jul 2012 19:12:03 +0000 Received: from mail-vc0-f178.google.com ([209.85.220.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SplHX-0000dW-7x for ima@ietf.org; Fri, 13 Jul 2012 19:12:03 +0000 Received: by mail-vc0-f178.google.com with SMTP id m8so2663268vcd.9 for ; Fri, 13 Jul 2012 12:12:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zezNbR7txoq33h1F/g9oD8k3uWP0G7uNv13wgCWMbac=; b=i2NEcJ3PrKmmVZjqtiiSmkKqqAOWsHCvbLjUIdVMnhxcGDjbGohX6uzGiWASs+K4AW 9z2rK0ssZfQcSj0klspj7gwD+9q3Q0czjdPVcRRtlymdgifvrRlbsr1Ms+c8/veBcg29 juyNdVr1pqVPtx8Ym3fNc7toVP4rkmwGLfOBlOYi7Qy5/CjqxabpOBTFsPyylI6x1yQL AxH2eRiQbSaPMZ5GEU8kSabAl8dgXZ7gAImEKf4v5+BRmbL27S1n48NarJ7DWgQDFQh/ FyrMouqycQ1+aeiCWSHgs5ic50BYj3eTtSk8FG2W97rm4cE2HmxDkggygG/mnVoycsYk kj+g== MIME-Version: 1.0 Received: by 10.220.107.198 with SMTP id c6mr1130098vcp.54.1342206723244; Fri, 13 Jul 2012 12:12:03 -0700 (PDT) Received: by 10.52.158.34 with HTTP; Fri, 13 Jul 2012 12:12:03 -0700 (PDT) In-Reply-To: References: <50000609.4020509@it.aoyama.ac.jp> Date: Fri, 13 Jul 2012 15:12:03 -0400 Message-ID: From: Joseph Yee To: John R Levine Content-Type: multipart/alternative; boundary=f46d0438ee5bf4415104c4badab4 X-Gm-Message-State: ALoCoQmqcQheJKwe0Z1gjLYVU9gPN1Q38eSi6Q/84cCF6urNx/W/npUGHSwhf7faBGX/79n+mMDQ Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 19:11:28 -0000 --f46d0438ee5bf4415104c4badab4 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 13, 2012 at 9:36 AM, John R Levine wrote: > Also, my proposal of different text for the "%-routing problem", which is >> clearer about the source of the problem, in particular that it's an >> implementation problem (correct escaping/unescaping) and not an a-priori >> problem, hasn't been taken into account, and I don't know why. >> > > I looked at your language, and it seemed to me less clear than what's > there. The problem is very simple, some MTAs mishandle addresses that > contain % signs. All we need to do is note it, not tell people how we > think they should fix it or work around it. > > > Agreed that describing how to manage % sign is out of scope for this document, but noting it helps readers. Joseph > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > ______________________________**_________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/**listinfo/ima > --f46d0438ee5bf4415104c4badab4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 13, 2012 at 9:36 AM, John R = Levine <johnl@taugh.com> wrote:
Also, my proposal of different text for the "%-routing problem", = which is clearer about the source of the problem, in particular that it'= ;s an implementation problem (correct escaping/unescaping) and not an a-pri= ori problem, hasn't been taken into account, and I don't know why.<= br>

I looked at your language, and it seemed to me less clear than what's t= here. =C2=A0The problem is very simple, some MTAs mishandle addresses that = contain % signs. =C2=A0All we need to do is note it, not tell people how we= think they should fix it or work around it.


<thought type=3D"personal">

Agreed that describing how to manage % sign is out of= scope for this document, but noting it helps readers.

</>
Joseph
=C2=A0
Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
IMA mailing list
IMA@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ima

--f46d0438ee5bf4415104c4badab4-- From klensin@jck.com Fri Jul 13 12:36:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1106111E80C7 for ; Fri, 13 Jul 2012 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef7C1zX7e7EB for ; Fri, 13 Jul 2012 12:36:58 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 70DF911E808C for ; Fri, 13 Jul 2012 12:36:58 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Splay-0004d7-Er; Fri, 13 Jul 2012 15:32:08 -0400 Date: Fri, 13 Jul 2012 15:37:19 -0400 From: John C Klensin To: Joseph Yee , John R Levine Message-ID: <918CA67046C709D33387ABC3@JcK-HP8200.jck.com> In-Reply-To: References: <50000609.4020509@it.aoyama.ac.jp> 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: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 19:36:59 -0000 --On Friday, July 13, 2012 15:12 -0400 Joseph Yee wrote: >> > > Agreed that describing how to manage % sign is out of scope > for this document, but noting it helps readers. Once we get EAI wound down or suspended, I want to have a discussion with the ADs (and maybe the IAB, who have expressed interest in the past) about re-doing RFC 3696 and/or 4084 to reflect a whole series of things that either weren't handled well the first time or need updating to reflect i18n (among other things). I'd be delighted to retire to junior author if someone else is interested in what I think is the right place to discuss advice about funky characters in mail and how careful one needs to be if one is going to transform things from one set of syntax conventions to another one. Consider that both an offer and, for people who like putting their names on RFCs, a bribe. john From johnl@iecc.com Fri Jul 13 12:41:30 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AF011E80C7 for ; Fri, 13 Jul 2012 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.124 X-Spam-Level: X-Spam-Status: No, score=-111.124 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLZyt67tttFU for ; Fri, 13 Jul 2012 12:41:29 -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 3A82311E808C for ; Fri, 13 Jul 2012 12:41:28 -0700 (PDT) Received: (qmail 8213 invoked from network); 13 Jul 2012 19:42:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jul 2012 19:42:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50007a0c.xn--yuvv84g.k1207; i=johnl@user.iecc.com; bh=MoEVpSV5CB7BnoqdF5ObokkmVHBLQ/EJyL6qU1cFz7E=; b=tXg6HiPUNrI/86jN09WTSs+bfQGtks2tKCtwngO721oEezh1BU68SsVh/aM8Q6pZaJhDCYzg0abkrBd6dkIOmvw4N90N5iGBO7I0ut0uukmW6a8o6r54xjQZF2WzEOcABNiSp9M08Kd89Q6heoJIPb8ZG3hzTrhJgXlpHiEstEM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50007a0c.xn--yuvv84g.k1207; olt=johnl@user.iecc.com; bh=MoEVpSV5CB7BnoqdF5ObokkmVHBLQ/EJyL6qU1cFz7E=; b=WuLht0lrCUp4oL5YcKqBc+9lVID9HCQrjMGYJNsZHwKTwrPy+JTJjacFLM0embIgAiW+o1o7bROu/7z4PBoP7mExE7uWKTOdRAalyXSmf8q5tshl1FLni5p6kYMr6PTJEayHlq1kPxQFfW+Xto2gtSjlCJqnbBi6GuaSjHGLkRY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Jul 2012 19:41:42 -0000 Message-ID: <20120713194142.2377.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <2279587D95E0BCE4B5CDED1E@JcK-HP8200.jck.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] references, was Shepherd report review of mailinglist-02 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, 13 Jul 2012 19:41:30 -0000 I don't have strong religious beliefs about references, if we need them we can put them in. When I look at the IESG statement about references, it says "It is not considered necessary to cite basic specifications that may be safely assumed to be known to practitioners" which I think lets us off the hook for RFC 20* for ASCII, 5321 for bounce addresses, and 5322 for common mail message headers. How about if I add normative refs to 6531 for SMTPUTF8 and 6532 for non-ASCII headers, and put back 6068 for mailto:, since that's the only URI scheme we talk about beyond a simple mention? R's, John http://www.ietf.org/iesg/statement/normative-informative.html * - for which I just filed an erratum, by the way From arnt@gulbrandsen.priv.no Fri Jul 13 12:59:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563E611E809B for ; Fri, 13 Jul 2012 12:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M48o1UYj-g9h for ; Fri, 13 Jul 2012 12:59:49 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id A405411E80EA for ; Fri, 13 Jul 2012 12:59:48 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 64237F8D754; Fri, 13 Jul 2012 20:00:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342209624-10397-10396/10/1; Fri, 13 Jul 2012 20:00:24 +0000 Message-Id: <50007E58.8010802@gulbrandsen.priv.no> Date: Fri, 13 Jul 2012 22:00:24 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> In-Reply-To: <50003A2A.5080005@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 19:59:50 -0000 On 07/13/2012 05:09 PM, Alexey Melnikov wrote: > I believe the rule is that anything mentioned in the document that is > not defined in it needs to be referenced. Hi Alexey, I noticed that all of your drafts mention the IETF, but you=20 neither define it nor reference a definition ;) Seriously, that rule is generally taken seriously only for terms that=20 affect the meaning of the document. "Copyright 2012 trustees of the=20 IETF" has no impact on the document's meaning =97 it could be IBM, the=20 document would still say the same thing. IMO mailto does not need a reference. No matter what mailto actually=20 means, the document still says the same thing. Arnt From sm@resistor.net Fri Jul 13 13:20:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F511E80E2 for ; Fri, 13 Jul 2012 13:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6bF+g+eVa4d for ; Fri, 13 Jul 2012 13:20:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E38C511E80C7 for ; Fri, 13 Jul 2012 13:20:17 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6DKKhQ9005576; Fri, 13 Jul 2012 13:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342210848; bh=uk0/Le41EsD7J11/x9L62wvRFb7lZBYuiwooIPq9dhk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4infAw4NrJsItOiQP2ZfJzedkbdXoj00TQQqHWjsVFkkanp9TllnJ4qkOS8JoK0Uk JrCqMydmN7pM2xRRTLcPg1sHaQ9RIi0C8yigAPK7w0B1bXYnHm7ZmrGvR7sOizBieB fH2XOo9pELP+LlrMuWxHqR9xJ6t+Rl2WYgQi7R1I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342210848; i=@resistor.net; bh=uk0/Le41EsD7J11/x9L62wvRFb7lZBYuiwooIPq9dhk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L7AbbTO1UhdobpGHf6k2QUcxq+YNVWOjipNLXirGxsVd9Wl3qKQXeYijzUsT3M41+ Sd2Bgy2tL5U4cvsvot1BKnMbfw9kUcv45OCr9/V34OuLN4ieWLdmdZ7vuqCuWHvVKh k7iqf8lIbx4Jn7z7iGggpQwZSbhMlxMLwREdYl/A= Message-Id: <6.2.5.6.2.20120713130919.09ac4c60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Jul 2012 13:18:59 -0700 To: Arnt Gulbrandsen From: SM In-Reply-To: <50007E58.8010802@gulbrandsen.priv.no> References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> <50007E58.8010802@gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 20:20:22 -0000 At 13:00 13-07-2012, Arnt Gulbrandsen wrote: >Hi Alexey, I noticed that all of your drafts mention the IETF, but >you neither define it nor reference a definition ;) +1 :-) >IMO mailto does not need a reference. No matter what mailto actually >means, the document still says the same thing. I included a reference to "mailto" in a draft as a pointer for an implementer to see what's the relevant specification quickly. I have heard of the thing called a search engine. The short answer is that it is more of a matter of style. Regards, -sm From klensin@jck.com Fri Jul 13 16:25:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BED11E80EB for ; Fri, 13 Jul 2012 16:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVQdG2+Ag1Ry for ; Fri, 13 Jul 2012 16:25:18 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8789911E80E7 for ; Fri, 13 Jul 2012 16:25:18 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Spp9s-0004qT-BF; Fri, 13 Jul 2012 19:20:24 -0400 Date: Fri, 13 Jul 2012 19:25:35 -0400 From: John C Klensin To: S Moonesamy , John R Levine Message-ID: In-Reply-To: <6.2.5.6.2.20120713124847.0bc41e50@resistor.net> References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> <2279587D95E0BCE4B5CDED1E@JcK-HP8200.jck.com> <6.2.5.6.2.20120713124847.0bc41e50@resistor.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 Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 23:25:19 -0000 --On Friday, July 13, 2012 12:56 -0700 S Moonesamy wrote: > Hi John, > At 09:04 13-07-2012, John C Klensin wrote: >> Then, partially following John's logic, it would be as >> reasonable (or more so) to clarify that the particular URIs >> and references to them appear in 2369. > > If I recall correctly we discussed about URIs for > draft-moonesamy-rfc2369bis-04 [1]. Could you refresh my > memory about what to clarify to help mailinglist-02? As far as mailinglist-02 (or -03) is concerned, I think John L is on the right track, I agree that we don't need references to "IETF" or "email", that the issue has gotten down to where "editor's discretion" sets in, and I'm willing to let him apply that discretion. john From internet-drafts@ietf.org Fri Jul 13 17:23:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52021F8505; Fri, 13 Jul 2012 17:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jF+vzptSn5o; Fri, 13 Jul 2012 17:23:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA50B21F8517; Fri, 13 Jul 2012 17:23:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120714002319.30056.83927.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 17:23:19 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:23:21 -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 Workin= g Group of the IETF. Title : Mailing Lists and non-ASCII Addresses Author(s) : John Levine Randall Gellens Filename : draft-ietf-eai-mailinglistbis-04.txt Pages : 10 Date : 2012-07-13 Abstract: This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses, but does not specify protocol changes or offer implementation or deployment advice. *NOTE TO REVIEWERS: Missing or odd-looking references between sections are due to bugs in xml2rfc. The XML is OK, and the HTML output looks reasonable.* The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-mailinglistbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-mailinglistbis-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-mailinglistbis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnl@iecc.com Fri Jul 13 17:35:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4D21F8694 for ; Fri, 13 Jul 2012 17:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.129 X-Spam-Level: X-Spam-Status: No, score=-111.129 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yooxvEvD5DT for ; Fri, 13 Jul 2012 17:35:53 -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 4D0C721F8680 for ; Fri, 13 Jul 2012 17:35:53 -0700 (PDT) Received: (qmail 49337 invoked from network); 14 Jul 2012 00:36:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Jul 2012 00:36:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5000bf0c.xn--yuvv84g.k1207; i=johnl@user.iecc.com; bh=CZwuYJpxOLFvTgLc+wCoPmacI//9nuSvEhm0055KCUs=; b=gxL0iUZ4VVYMzP5xkPtFF3pSoG7nqQ7f6ACVe0gRJAytQRPDHlgx7WghtBITLfdB9V2pK7046w0Sx5AvLebe+IY902OXrcUpUJaw/rRdoR90/Ao47ZRn6ME1HleXZXY/cW2Y+fg86LMrIpFfQqL3av4fCJKS1pfHPGuEBZ4bJuY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5000bf0c.xn--yuvv84g.k1207; olt=johnl@user.iecc.com; bh=CZwuYJpxOLFvTgLc+wCoPmacI//9nuSvEhm0055KCUs=; b=VIZIewiW1/c6WlYyMFLsuPUUrxRz9S8kA78fevjYYQTFhGLn8g8gulCBBrS9r55wTSru2baym9krFpKxytQScxG37xQLxtjb4bJNuhTpdFjpi3tdX+6+1PyUUg52XGECVdaUS1YCkRkg/259eEVhUSySRbJe1Df0ykbOLfH1h18= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Jul 2012 00:36:06 -0000 Message-ID: <20120714003606.86727.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <20120713194142.2377.qmail@joyce.lan> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] references, was Shepherd report review of mailinglist-02 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, 14 Jul 2012 00:35:54 -0000 I just submitted -04 which differs from -03 only in that there is a new sentence in the introduction with a normative referenc to RFC 6530, which describes all the EAI stuff including SMTPUTF8 and non-ASCII addresses in mail headers, and a normative reference to RFC 6068 which describes percent encoded addresses in mailto URIs. R's, John PS: Since the point of a normative reference is that a reader is expected to be familiar with the reference to understand the document, I'm asuming that means that readers are familiar with the normative references in the normative references and so forth. So now that I've added a reference to RFC 6530, you might want to reread RFC20, RFC791, RFC821, RFC822, RFC974, RFC1034, RFC1035, RFC1047, RFC1123, RFC1305, RFC1652, RFC1869, RFC1870, RFC1894, RFC1970, RFC2026, RFC2028, RFC2033, RFC2034, RFC2045, RFC2046, RFC2048, RFC2119, RFC2192, RFC2234, RFC2244, RFC2246, RFC2277, RFC2279, RFC2327, RFC2387, RFC2396, RFC2434, RFC2460, RFC2554, RFC2743, RFC2782, RFC2821, RFC2822, RFC2860, RFC2978, RFC3023, RFC3190, RFC3207, RFC3280, RFC3339, RFC3454, RFC3461, RFC3462, RFC3463, RFC3464, RFC3501, RFC3550, RFC3551, RFC3555, RFC3629, RFC3798, RFC3848, RFC3864, RFC3885, RFC3886, RFC3887, RFC3888, RFC3986, RFC4013, RFC4234, RFC4288, RFC4291, RFC4409, RFC4422, RFC4467, RFC4468, RFC4646, RFC4647, RFC4648, RFC4954, RFC5198, RFC5226, RFC5234, RFC5248, RFC5321, RFC5322, RFC5646, RFC5890, RFC6152, RFC6409, RFC6522, RFC6531, RFC6532, RFC6533, ISO 639, NIST SHA-1, and the Apple AIFF-C spec. From duerst@it.aoyama.ac.jp Fri Jul 13 19:06:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7184121F85B1 for ; Fri, 13 Jul 2012 19:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.57 X-Spam-Level: X-Spam-Status: No, score=-99.57 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5ZMkYKYfCjJ for ; Fri, 13 Jul 2012 19:06:36 -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 9B4F821F85AD for ; Fri, 13 Jul 2012 19:06:35 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6E273Ao007101 for ; Sat, 14 Jul 2012 11:07:05 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4aad_3f5a_9af2fe6a_cd58_11e1_a1d8_001d096c566a; Sat, 14 Jul 2012 11:07:03 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48378) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 14 Jul 2012 11:07:06 +0900 Message-ID: <5000D440.1000503@it.aoyama.ac.jp> Date: Sat, 14 Jul 2012 11:06:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John R Levine References: <50000609.4020509@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 14 Jul 2012 02:06:37 -0000 Hello John, Thanks for your mail. I think we are getting closer to where we have a misunderstanding. On 2012/07/13 22:36, John R Levine wrote: >> Also, my proposal of different text for the "%-routing problem", which >> is clearer about the source of the problem, in particular that it's an >> implementation problem (correct escaping/unescaping) and not an >> a-priori problem, hasn't been taken into account, and I don't know why. > > I looked at your language, and it seemed to me less clear than what's > there. Sorry about that. I don't claim that my text is perfect. > The problem is very simple, some MTAs mishandle addresses that > contain % signs. Here is where we have the misunderstanding/disagreement. The original problem is NOT what MTAs do with addresses that contain % signs. If e.g. I enter something like gorby%kremvax@example.com into a To field in my MUA, then that might work somehow, or not, but that's secondary. To continue, if there is an URI mailto:gorby%25kremvax@example.com, and it gets correctly converted to gorby%kremvax@example.com, then that might work somehow, or not, but that's again irrelevant. The actual problem we want to discuss (on which point I very strongly agree with John Klensin) is the case where there is e.g. an URI of the form mailto:unlikely%3Faddress@example.com, which should end up in a mail to unlikely?address@example.com, but because the unescaping is missing, produces a mail to unlikely%3Faddress@example.com. The address unlikely%3Faddress@example.com is essentially wrong. What some mailers do with such an address, or with addresses containing % in general, just affects who wrongly gets (or doesn't get) the mail, and how easy it might be to debug the problem. But the problem happened earlier. > All we need to do is note it, not tell people how we > think they should fix it or work around it. Just to note it may be okay (a nugde in the right direction for a fix can't hurt though), but what's important is that the focus has to be on unescaping %-encoding when moving from mailto: to raw email addresses, rather than on what mailers do with mail addresses that have a % in them. BTW, the examples are all taken from RFC 6068, so again it might not be such a bad idea to reference it. Regards, Martin. > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > From duerst@it.aoyama.ac.jp Fri Jul 13 19:13:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642DC21F85AD for ; Fri, 13 Jul 2012 19:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.576 X-Spam-Level: X-Spam-Status: No, score=-99.576 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDYKCYSuWOKu for ; Fri, 13 Jul 2012 19:13:40 -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 A637621F8568 for ; Fri, 13 Jul 2012 19:13:39 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6E2EGcg011997 for ; Sat, 14 Jul 2012 11:14:16 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4aaf_59b2_9d0eda74_cd59_11e1_824c_001d096c566a; Sat, 14 Jul 2012 11:14:16 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41386) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 14 Jul 2012 11:14:19 +0900 Message-ID: <5000D5F1.8000909@it.aoyama.ac.jp> Date: Sat, 14 Jul 2012 11:14:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John R Levine References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 14 Jul 2012 02:13:40 -0000 On 2012/07/14 0:34, John R Levine wrote: > My. there's a can of worms. We don't reference RFC 6531 for SMTPUTF8, > 6532 for non-ASCII headers, 5322 for the From, Reply-To, and Sender > headers, 5598 for MTA, MDA, and MUA, or 20 for ASCII. > > RFC 3986, which we do reference, describes all of the URI schemes that > we mention. Small detail, maybe relevant, maybe not: RFC 3986 only describes the general syntax of URIs. It does not define individual schemes. The last time general URI syntax and individual schemes were described in the same spec was in RFC 1738, which is two generations ago (with RFC 2396 in between). > It probably would be a good idea to reference 6531 and 6532, though. Yes indeed. Regards, Martin. From sm@elandsys.com Fri Jul 13 13:00:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A529B11E80EA for ; Fri, 13 Jul 2012 13:00:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T9DUcY3vgxy for ; Fri, 13 Jul 2012 13:00:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBBE11E809B for ; Fri, 13 Jul 2012 13:00:21 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6DK0iNX016217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 13:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342209657; bh=lu1VtDb5cdZrUvLA/yi815e5q6mqns1lLRrKt/8SQWA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rcMOBGOh5I94KtE+/+1QqdAgPukma1VaQK03Oh5Ma7F6Sw2G2lj7KG5qGOP8QtMCK O3yEkwp0AXieuMm099zaalBWovobkSsQqoZJ1LaVlrbtDG9rx7bPHg5rRQv7JaueVS PTavZ52m+fHQkBw49D2m/jqoRufGzYZeyB7Yv/fA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342209657; i=@elandsys.com; bh=lu1VtDb5cdZrUvLA/yi815e5q6mqns1lLRrKt/8SQWA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HUqfQKvANUhG/+ZcxnbaVuCyxSUo3ky9CpvYAkP4Db8BW73Owo8AYzbTYgoFI3tEv fxjXdRYHGut690dj+Gyrs6v2wj4uDspaFw/rB+LO3Il+tWj3nDzpASDH3zINSU6Ev9 Hg0yFjUtjIBWwdm4NBuB8gSVsScTKY93bwm89W6c= Message-Id: <6.2.5.6.2.20120713124847.0bc41e50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Jul 2012 12:56:13 -0700 To: John R Levine From: S Moonesamy In-Reply-To: <2279587D95E0BCE4B5CDED1E@JcK-HP8200.jck.com> References: <5000022C.5020207@isode.com> <50003A2A.5080005@isode.com> <2279587D95E0BCE4B5CDED1E@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 13 Jul 2012 19:38:52 -0700 Cc: EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 13 Jul 2012 20:00:33 -0000 Hi John, At 09:04 13-07-2012, John C Klensin wrote: >Then, partially following John's logic, it would be as >reasonable (or more so) to clarify that the particular URIs and >references to them appear in 2369. If I recall correctly we discussed about URIs for draft-moonesamy-rfc2369bis-04 [1]. Could you refresh my memory about what to clarify to help mailinglist-02? Thanks, S. Moonesamy 1. http://tools.ietf.org/html/draft-moonesamy-rfc2369bis-04 From yaojk@cnnic.cn Fri Jul 13 21:33:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D8411E8080 for ; Fri, 13 Jul 2012 21:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=2.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4ybKqN6490F for ; Fri, 13 Jul 2012 21:33:40 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 71AB011E8072 for ; Fri, 13 Jul 2012 21:33:34 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 14 Jul 2012 12:34:04 +0800 Message-ID: <00d301cd6179$e6f75b80$c801a8c0@computer> From: "Jiankang Yao" To: "Alexey Melnikov" , "Joseph Yee" References: <50000BFB.3050405@isode.com> Date: Sat, 14 Jul 2012 12:34:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: EAI WG Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 04:33:43 -0000 ----- Original Message ----- From: "Alexey Melnikov" To: "Joseph Yee" Cc: "EAI WG" Sent: Friday, July 13, 2012 7:52 PM Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade .... > > And finally, if we are making all sorts of other simplifications, can be > please also drop the whole section 3.1 (as suggested by Dave Cridland and > discussed by Arnt and myself)? > If section 3.1 "IMAP UTF-8 Quoted Strings" is removed, that will give this document more simplifications. I just checked section 3.1 and its relationship with other sections of this document, and found that it is fine to remove the whole section 3.1. Jiankang Yao > Thank you, > Alexey > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From internet-drafts@ietf.org Sat Jul 14 03:30:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879B921F86CA; Sat, 14 Jul 2012 03:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR1ymFrwyG+0; Sat, 14 Jul 2012 03:30:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E9021F86D3; Sat, 14 Jul 2012 03:30:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2012 03:30:18 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-5738bis-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 10:30:20 -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 Workin= g Group of the IETF. Title : IMAP Support for UTF-8 Author(s) : Pete Resnick Chris Newman Sean Shen Filename : draft-ietf-eai-5738bis-05.txt Pages : 9 Date : 2012-07-14 Abstract: 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. This specification replaces RFC 5738. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-5738bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-5738bis-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-5738bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From arnt@gulbrandsen.priv.no Sat Jul 14 04:12:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0122C21F8736 for ; Sat, 14 Jul 2012 04:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSkb3TH-DZtf for ; Sat, 14 Jul 2012 04:12:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FF721F8735 for ; Sat, 14 Jul 2012 04:12:25 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 611D0F8E03C; Sat, 14 Jul 2012 11:13:02 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342264381-20772-20771/10/1; Sat, 14 Jul 2012 11:13:01 +0000 User-Agent: Kaiten Mail In-Reply-To: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> References: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----5NQATQXA61J5XEGDIL6PHV0YQ7DQLM From: Arnt Gulbrandsen Date: Sat, 14 Jul 2012 13:08:02 +0200 Cc: ima@ietf.org Message-Id: <255e9b7d-644e-45bf-8087-3bcec85d618f@email.android.com> Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 11:12:26 -0000 ------5NQATQXA61J5XEGDIL6PHV0YQ7DQLM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Now the ability to send Utf8 in quoted strings is completely gone. I an = sorry about that. While it is not critical to correctness, I think it is = important to ease of implementation. A client that sent select commands using printf no longer can do that: = the printf format has to change a lot and formally speaking the client = has to wait on a literal. Alexey, can you suggest a syntax change to allow utf8 in quited-strings? = (i am afk, sorry.) Arnt ------5NQATQXA61J5XEGDIL6PHV0YQ7DQLM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Now the ability to send Utf8 in quoted strings is = completely gone. I an sorry about that. While it is not critical to = correctness, I think it is important to ease of implementation.

A client that sent select commands using printf no longer can do = that: the printf format has to change a lot and formally speaking the = client has to wait on a literal.

Alexey, can you suggest a syntax change to allow utf8 in quited-string= s? (i am afk, sorry.)


Arnt ------5NQATQXA61J5XEGDIL6PHV0YQ7DQLM-- From sm@resistor.net Sat Jul 14 04:31:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA1021F8667 for ; Sat, 14 Jul 2012 04:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqj-eMdXZLVn for ; Sat, 14 Jul 2012 04:31:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EA721F864E for ; Sat, 14 Jul 2012 04:31:26 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6EBVwtT003675; Sat, 14 Jul 2012 04:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342265523; bh=oxtvH62hy6RJl1SOvMjv6FD1N2eV6i5LhAhc2+O+jok=; h=Date:To:From:Subject:Cc; b=xR3FOyB2pvh1J3Qof4ZhFkuPRxh5xRxEM3CZbxE4hnuWopzLCFmyO6RQw1jjbJ/3E H1N019n+ZC5gpOYnFVEUHZ2VKh84gdzJ08q97irmRHIi3MrzLQ7mV6uiuOWP2Db8Mw PLv99XRJdHR6wZcxfpvOYucHke7Pr8uJqTdGmj3o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342265523; i=@resistor.net; bh=oxtvH62hy6RJl1SOvMjv6FD1N2eV6i5LhAhc2+O+jok=; h=Date:To:From:Subject:Cc; b=1tY7ol6bfBca5M6+yz+H9BZNjgpoZLFghTXWAJN44K5XNZ9PAuCpd+eRzL1hkpFD+ r/iUvkbGOSkm55cPwicJwQA8pUPQA6bC/PonnjuNylJUaUPhAxHFCsTCzFvC/1bL4U KG9TkVWGKE3ETnUgQTG0t3DbMdS+X7FLTifs3JMk= Message-Id: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Jul 2012 04:31:43 -0700 To: John Levine From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: EAI WG Subject: [EAI] Comments on draft-ietf-eai-mailinglistbis-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 11:31:29 -0000 Hi John, Here are some comments about draft-ietf-eai-mailinglistbis-04. The document uses a style which is easy to understand. It tackles mailing lists and non-ASCII email addresses from a mail transport and message header perspective only. I mentioned these points as there are other questions which MLM implementers take into consideration, e.g. for archival [1]: - Which identifier to use for the list [2] - Which identifier to use for a message - Compatibility with the NNTP environment [3] There are questions such as de-duplication (how to prevent duplicate copies of a message), message digests, HTML downgrades, etc. As all this is likely out of scope for EAI I am not suggesting that the document address these questions. The main issue is what to do about mixed SMTPUTF8 and ASCII mailing lists (Section 2.2). The idea of sending a probe message sounds practical. In Section 2.2: "To determine whether a message needs to be downgraded for ASCII recipients, list software might assume that any message received via an SMTPUTF8 SMTP session is an SMTPUTF8 message, or might examine the headers and body of the message to see whether it needs SMTPUTF8 treatment." Why not test for "message/global" instead of inspecting message content? In Section 3.1: "[RFC2919] specifies that "The list identifier will, in most cases, appear like a host name in a domain of the list owner." Since these headers were defined in the context of ASCII mail, these headers permit only ASCII text including in the URLs. I suggest moving the last sentence in that paragraph before the "[RFC2919]" sentence as it applies to the RFC 2369 header fields. The List-Post: header needs the "mailto". Part of the remaining (2369) List- headers (List-Unsubscribe:, List-Archive:, List-Help:) can be handled through HTTP. The List-Id: header can be considered as an opaque string. The information which is displayed can be passed as a comment. That allows the issue of IDNs to be side-stepped. You can also avoid the question of downgrading if you use a randomly generated string. I would treat the 2369 and 2919 List- header separately as you have more leeway for the latter (see above paragraph). Per-header issues could be identified and discussed on an issue-basis. Section 3.2 discusses the "mailto" issue (re percentage sign and source routing). There is one sentence about the IDN angle which does not say much. In Section 3.3: "List software typically leaves the original submitter's address in the From: line, both so that recipients can tell who wrote the message" I suggest author instead of submitter. The Security Considerations section is going to raise questions. Given the approach taken to discuss the subject, there's not much to say. It's difficult to pick a solution for mailing lists. I am not being critical about the trade-offs as I don't have a fix to suggest. Regards, -sm 1. The archives may be managed by the mailing list operator or by a third-party. 2. I assumed that RFC 2919 answered that question. The implementer tried to devise a unique id even though there was a RFC published years ago about that. 3. http://packages.python.org/mailman/src/mailman/handlers/docs/nntp.html From klensin@jck.com Sat Jul 14 08:48:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D9221F8518 for ; Sat, 14 Jul 2012 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmmtbs4q-8CO for ; Sat, 14 Jul 2012 08:48:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4A421F84F6 for ; Sat, 14 Jul 2012 08:48:47 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sq4Vb-00067p-L1; Sat, 14 Jul 2012 11:43:51 -0400 Date: Sat, 14 Jul 2012 11:49:04 -0400 From: John C Klensin To: SM , John Levine Message-ID: <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> In-Reply-To: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> References: <6.2.5.6.2.20120713233300.08ad7478@elandnews.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: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-mailinglistbis-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 15:48:48 -0000 SM, Let's be careful here. A number of the issues you raise are really about the fundamentals of mailing list management. I agree that it would be good if the IETF developed up to date protocol specifications or best practices guidance in this area. But they are not in scope for EAI. For EAI, I think it is in our interest to keep this document as narrowly focused on i18n-specific problems as possible. The WG has discussed the scope of this document several times since John agreed to do a draft (and discussed the scope of its predecessor several times since before it was published). Moreover, the model in this document (also discussed several times in the WG and agreed) is to identify issues, not try to fix the problems or propose protocol changes. In the hope of actually finishing this document (including IETF LC) in the next several weeks (or even in our lifetimes given how controversial MLM topics, among others, tend to be), I'd really like to keep this focused. And, again, those broader issues aren't in charter. Details inline below. --On Saturday, July 14, 2012 04:31 -0700 SM wrote: > Hi John, > > Here are some comments about draft-ietf-eai-mailinglistbis-04. > The document uses a style which is easy to understand. It > tackles mailing lists and non-ASCII email addresses from a > mail transport and message header perspective only. I > mentioned these points as there are other questions which MLM > implementers take into consideration, e.g. for archival [1]: > > - Which identifier to use for the list [2] > > - Which identifier to use for a message > > - Compatibility with the NNTP environment [3] All fundamental list management issues. Out of scope here. And the NNTP environment is not inherently more important than any other environments into which mailing lists might be gatewayed. For example, I note that you do not discuss the content and format of mailing list archives, which might be equally relevant -- and equally out of scope for EAI. > There are questions such as de-duplication (how to prevent > duplicate copies of a message), message digests, HTML > downgrades, etc. As all this is likely out of scope for EAI I > am not suggesting that the document address these questions. I agree, they are out of scope for EAI and the document should not try to take them on. > The main issue is what to do about mixed SMTPUTF8 and ASCII > mailing lists (Section 2.2). The idea of sending a probe > message sounds practical. And is part of the solution space, not the issue description space. > In Section 2.2: > > "To determine whether a message needs to be downgraded for > ASCII > recipients, list software might assume that any message > received via > an SMTPUTF8 SMTP session is an SMTPUTF8 message, or might > examine the > headers and body of the message to see whether it needs > SMTPUTF8 > treatment." > > Why not test for "message/global" instead of inspecting > message content? IMO, testing for message/global is a subset of inspecting message content and, in particular, of "examining the headers and body". Even if one asked for that text in particular, the statement above would still have to be present because there are many ways to have messages that require SMTPUTF8 features without having message/global present. >...> > The List-Post: header needs the "mailto". Part of the > remaining (2369) List- headers (List-Unsubscribe:, > List-Archive:, List-Help:) can be handled through HTTP. > > The List-Id: header can be considered as an opaque string. > The information which is displayed can be passed as a comment. > That allows the issue of IDNs to be side-stepped. You can > also avoid the question of downgrading if you use a randomly > generated string. > > I would treat the 2369 and 2919 List- header separately as you > have more leeway for the latter (see above paragraph). > Per-header issues could be identified and discussed on an > issue-basis. You are getting very far into the implementation details of these various headers. In the case of List-* header fields, that requires updating the base documents. That has been discussed previously and is not on the agenda for this WG. What the document says is consistent with the current specs, i.e., that anything that is present has to be conformant to them. > Section 3.2 discusses the "mailto" issue (re percentage sign > and source routing). There is one sentence about the IDN > angle which does not say much. So what are you suggesting be done about it. I recommended removing that discussion; several people in the WG wanted something minimal there. The present text appears to meet that minimal requirement. > In Section 3.3: > > "List software typically leaves the original submitter's > address in > the From: line, both so that recipients can tell who wrote > the > message" > > I suggest author instead of submitter. Submitter was, I believe, deliberate because "author" rapidly takes on all sorts of ambiguity. I recommend this issue be deferred to those hypothetical mailing list management documents and that the author/editor use his discretion. > The Security Considerations section is going to raise > questions. Given the approach taken to discuss the subject, > there's not much to say. Yes. But this is an issues report, not a protocol spec, so the problem you anticipate may be unavoidable. > It's difficult to pick a solution for mailing lists. I am not > being critical about the trade-offs as I don't have a fix to > suggest. Except for "submitter", I've omitted the editorial nit-picking and will leave them to John's discretion. But, more generally, I really hope that we can focus now on what is absolutely necessary to get this document out, plus any newly-discovered showstoppers that show up. As a preview and unless the WG disagrees, it is my intention (and, I believe, Joseph's) to deal with any IETF Last Call comments that open up larger mailing list issues in much the style of my comments above: they are out of scope and this document is an issues report not a protocol specification. I imagine we made need to repeat that a lot (and it is said proactively in the draft shepherd's report), but the alternatives of opening up the general mailing list issues or trying to revise the List-* header specs would be a disaster (at least as far as getting the document finished in a timely fashion). best, john From johnl@taugh.com Sat Jul 14 09:09:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F2A21F8716 for ; Sat, 14 Jul 2012 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNT8V7FzMbRT for ; Sat, 14 Jul 2012 09:09:41 -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 CFB7D21F8713 for ; Sat, 14 Jul 2012 09:09:40 -0700 (PDT) Received: (qmail 93274 invoked from network); 14 Jul 2012 16:10:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=16c59.500199ea.k1207; bh=5S8zAn/Si1HE8JZQM/j8lMbgj7v21n6BqIEZgUbDKho=; b=OoNZ8MZK4LGxcjZX4WaFKMb6suKTv0vvG3e7zzHL+WMjYWPvjl431dPoi3xAdZ7K3lnsOccnLbS+F4t6YF3M+jCEGOZ0iBMpoSNv2t7F/9pIVrQcFqkRMiOd8u4jwmigYv/GXC2yJbNbnQ7PwEarHRidN/pl7Etl9f9tfXJX3Ro= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=16c59.500199ea.k1207; bh=5S8zAn/Si1HE8JZQM/j8lMbgj7v21n6BqIEZgUbDKho=; b=fPhbYLCmUs6mbiMd1H+A1TP//97wZl3mWVStuZl9W3W42i2XdDj/nwIJWbPDCyqgZFIC65TP2OY13rKZ+shFybu7IofAS/ZiwWchyQ0vl75iPltFHvabdK5hESrpBlZd70opHHCTL2i2r9WQp+Y8guAh4oSyvbWElTP599b6k5s= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Jul 2012 16:09:56 -0000 Date: 14 Jul 2012 12:10:18 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> References: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: EAI WG Subject: Re: [EAI] [taugh.com-standards] Re: Comments on draft-ietf-eai-mailinglistbis-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 16:09:41 -0000 I thought that they were perfectly reasonable suggestions (other than message/global, which was a misunderstanding), and I'm not planning to address any of them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From arnt@gulbrandsen.priv.no Sat Jul 14 09:38:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B387021F85F9 for ; Sat, 14 Jul 2012 09:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAQB4dRHY4vW for ; Sat, 14 Jul 2012 09:38:38 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBCC21F8549 for ; Sat, 14 Jul 2012 09:38:37 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 08C93F8E2F1; Sat, 14 Jul 2012 16:39:17 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342283956-20772-20771/11/1; Sat, 14 Jul 2012 16:39:16 +0000 Message-Id: <5001A0B6.7090401@gulbrandsen.priv.no> Date: Sat, 14 Jul 2012 18:39:18 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] [taugh.com-standards] Re: Comments on draft-ietf-eai-mailinglistbis-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 16:38:39 -0000 On 07/14/2012 06:10 PM, John R Levine wrote: > I thought that they were perfectly reasonable suggestions (other than > message/global, which was a misunderstanding), and I'm not planning to > address any of them. Thanks. I dreaded the coming thread. Arnt From klensin@jck.com Sat Jul 14 09:45:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC8121F866B for ; Sat, 14 Jul 2012 09:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuEFUhssuRxp for ; Sat, 14 Jul 2012 09:45:18 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B54A321F8525 for ; Sat, 14 Jul 2012 09:45:18 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sq5OS-0006Ay-BV; Sat, 14 Jul 2012 12:40:32 -0400 Date: Sat, 14 Jul 2012 12:45:44 -0400 From: John C Klensin To: John R Levine Message-ID: <8245019B28A5A1E9148A9C8C@JcK-HP8200.jck.com> In-Reply-To: References: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] [taugh.com-standards] Re: Comments on draft-ietf-eai-mailinglistbis-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 16:45:19 -0000 --On Saturday, July 14, 2012 12:10 -0400 John R Levine wrote: > I thought that they were perfectly reasonable suggestions > (other than message/global, which was a misunderstanding), and > I'm not planning to address any of them. I didn't mean to suggest that they were unreasonable. I am just trying to carry out my perceived mandate as co-chair to get this done. Now. john From sm@resistor.net Sat Jul 14 10:52:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173021F85C4 for ; Sat, 14 Jul 2012 10:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GhsrIV2WpJ0 for ; Sat, 14 Jul 2012 10:52:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2F421F8564 for ; Sat, 14 Jul 2012 10:52:36 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6EHr9c7021492; Sat, 14 Jul 2012 10:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342288394; bh=xV5+HveGBAJObVtjLjmU8HG1A4z5Nao2PBXwah+H3CI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GMzfNvHCOqv7Esa6YvXcIBAKTOMP+WNzW8FS341dZxvJNx13QltwBxxu1l2m4BmRk clfa82gGvlnwdRkReF0BvELJ9rIOi29380vJ837nOnuJkb9a54GLaeZqsOUfRq065W dlZvcluZdlOYbgS91neA+Os3ThvXOZnvgUB+4A00= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342288394; i=@resistor.net; bh=xV5+HveGBAJObVtjLjmU8HG1A4z5Nao2PBXwah+H3CI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vNMhpiMicXQGLaFgd2NDTXteGJq3MyAqRUfszDa4ckrSvA1nN76Dt40YetrpErkHo BMQvNVBBemU2eXjZ6+6JWGhB1Tu/qGF+IfkIK7iY1XI9U79cjJaHLiO/3eveHQ3CD4 YDsmaMCHEeEGgn0GlflOdat4On0BoFjwAXdmADC4= Message-Id: <6.2.5.6.2.20120714095535.09dd7020@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Jul 2012 10:31:55 -0700 To: John C Klensin , John Levine From: SM In-Reply-To: <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> References: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: EAI WG Subject: Re: [EAI] Comments on draft-ietf-eai-mailinglistbis-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 17:52:41 -0000 Hello, At 08:49 14-07-2012, John C Klensin wrote: >Let's be careful here. A number of the issues you raise are >really about the fundamentals of mailing list management. I >agree that it would be good if the IETF developed up to date >protocol specifications or best practices guidance in this area. I'll preface this message by saying that I consider my comments as addressed. It would be good but I don't think it's realistic to ask for that in this document. >But they are not in scope for EAI. For EAI, I think it is in Ok. >IMO, testing for message/global is a subset of inspecting >message content and, in particular, of "examining the headers >and body". Even if one asked for that text in particular, the >statement above would still have to be present because there are >many ways to have messages that require SMTPUTF8 features >without having message/global present. Ok. >You are getting very far into the implementation details of >these various headers. In the case of List-* header fields, >that requires updating the base documents. That has been >discussed previously and is not on the agenda for this WG. What >the document says is consistent with the current specs, i.e., >that anything that is present has to be conformant to them. Ok. >So what are you suggesting be done about it. I recommended >removing that discussion; several people in the WG wanted >something minimal there. The present text appears to meet that >minimal requirement. I'll go with the WG view to have something minimal (no change suggested). >Submitter was, I believe, deliberate because "author" rapidly >takes on all sorts of ambiguity. I recommend this issue be >deferred to those hypothetical mailing list management documents >and that the author/editor use his discretion. Ok. At 09:10 14-07-2012, John R Levine wrote: >I thought that they were perfectly reasonable suggestions (other >than message/global, which was a misunderstanding), and I'm not >planning to address any of them. Ok. Regards, -sm From internet-drafts@ietf.org Sat Jul 14 11:08:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2148721F8650; Sat, 14 Jul 2012 11:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtMwEImU9IzR; Sat, 14 Jul 2012 11:08:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0821F865E; Sat, 14 Jul 2012 11:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120714180850.14284.73474.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2012 11:08:50 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:08:51 -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 Workin= g Group of the IETF. Title : Mailing Lists and non-ASCII Addresses Author(s) : John Levine Randall Gellens Filename : draft-ietf-eai-mailinglistbis-05.txt Pages : 10 Date : 2012-07-14 Abstract: This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses, but does not specify protocol changes or offer implementation or deployment advice. *NOTE TO REVIEWERS: Missing or odd-looking references between sections are due to bugs in xml2rfc. The XML is OK, and the HTML output looks reasonable.* The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-mailinglistbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-mailinglistbis-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-mailinglistbis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnl@taugh.com Sat Jul 14 11:09:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F4B21F86EA for ; Sat, 14 Jul 2012 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8sNcU6dsjo6 for ; Sat, 14 Jul 2012 11:09:31 -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 63EFF21F86BA for ; Sat, 14 Jul 2012 11:09:30 -0700 (PDT) Received: (qmail 10730 invoked from network); 14 Jul 2012 18:10:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=29e8.5001b601.k1207; bh=0KhUBW4r66WWFgzCrgCONbhxZpa/lTA/ivpm7OD0Ooo=; b=kNJt1xkM/dcVG2bSE6+EpVSSSmdGR0AySgDsE21yQDLPwF4RDEMYgb+6OiARKpYuBypzHb+PvA3m9kuy9exwiXKlfDWFTh3+4sGeF7YmPXOdAjKm7U8L0Cu6qAjYQuU4egUiw7fQfaHYEO3QTLCl0S+/AMMXLbFgceia7ovSMJA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=29e8.5001b601.k1207; bh=0KhUBW4r66WWFgzCrgCONbhxZpa/lTA/ivpm7OD0Ooo=; b=VssfPKcYuW5Zg0UPYM5XbxhZkRGQU+JpxAtvw/e42zvuSn8wKOKzBMOrBOTCrNW8VE8RCgQNmLQHk74wiJfq8gPW8mQO13l++u5qmQ39Il4gmkGKD3R9/Co3ttAyfCEHLK60ExRifOmdxLuxJzJCbsQMa8xqzqCPHeMpvM2pe1A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Jul 2012 18:09:47 -0000 Date: 14 Jul 2012 14:10:09 -0400 Message-ID: From: "John R Levine" To: "EAI WG" In-Reply-To: <8245019B28A5A1E9148A9C8C@JcK-HP8200.jck.com> References: <6.2.5.6.2.20120713233300.08ad7478@elandnews.com> <5128EE77B65F81C7A0FA0D9D@JcK-HP8200.jck.com> <8245019B28A5A1E9148A9C8C@JcK-HP8200.jck.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [EAI] draft-ietf-eai-mailinglistbis-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:09:31 -0000 The only difference is a placeholder IANA considerations section, which I forgot to add last time around. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From barryleiba.mailing.lists@gmail.com Sat Jul 14 12:55:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5212921F85A0 for ; Sat, 14 Jul 2012 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzvD5oI9jaC8 for ; Sat, 14 Jul 2012 12:55:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 641D721F8595 for ; Sat, 14 Jul 2012 12:55:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so6467794lbb.31 for ; Sat, 14 Jul 2012 12:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kt5+Aew3YigGpGnaj/zjcpHM+WeuvXof1xZCHhJ1kDc=; b=0qUOPX3NDQqwSnVPpFFRDr/DKjtnKHM4faLsrjHn61BEbfQ+eLYERcliUjMvah2slQ 7Qs9QfG//9ITvNq3u4bLAL9l3qYsZIj/zYC56R8gHIWoMuSN73KTox/UaS70YWoKbaWy T7cTxAZPlAaACgZXBzY+8k/ur9qFpff6uJnNUjJ1tJNrhe3J38O7k7F6r+fx1cPw1X1l pQDMu3PYC3fM/B7UEj9cDODAi3KmUFBwc0D1UA1w51xG6fKmRYKsmT9zyhaGhUBPc6lD GxXpxlEiB4r8B3L56wfsCsdftkUBZmEOm3XFfmvDNpj6o9gfPHOdL5fRZmG+I+i30E9Y 2OzA== MIME-Version: 1.0 Received: by 10.112.26.131 with SMTP id l3mr2897253lbg.80.1342295767212; Sat, 14 Jul 2012 12:56:07 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sat, 14 Jul 2012 12:56:07 -0700 (PDT) In-Reply-To: References: <01OHMFVC3IY00006TF@mauve.mrochek.com> Date: Sat, 14 Jul 2012 15:56:07 -0400 X-Google-Sender-Auth: OcXpLNC64hh0k8pJjS0k0DXA-e8 Message-ID: From: Barry Leiba To: ned+ima@mrochek.com Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 14 Jul 2012 19:55:29 -0000 >>> Please also review the Security Considerations, and make sure I got that >>> right. >> >> The one I don't see is possible exploits involving different clients handling >> of something that used to not be allowed. > > Good point; I'll craft something for that and post an updated draft. I have updated the security considerations with this new paragraph in -02: Because group syntax in the "From" header field has previously not been allowed, it is possible that some implementations that conform to RFC 5322 might not be prepared to handle the syntax, and, indeed, might not even recognize that group syntax is being used. Of those implementations, some subset might, when presented with "From" group syntax, behave in a way that is exploitable by an attacker. It is deemed unlikely that this will be a serious problem in practice: address field parsing is generally an integral component of implementations, and address field parsers are required to understand group syntax. In addition, if any implementations should be exploitable through this mechanism, it is already possible for attackers to do it by violating RFC 5322, and other RFC 5322 violations are commonly used by malefactors. Here's the current -02 version: https://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group To compare the changed text with the original text from RFC 5322, diff this version against the -00 version: https://tools.ietf.org/rfcdiff?url1=draft-leiba-5322upd-from-group-00.txt&url2=draft-leiba-5322upd-from-group-02.txt I believe -02 is ready for me to send to Pete for sponsorship. Will folks please review this and give your assessment of that? And will someone please volunteer to be the document shepherd, and to do a shepherd writeup ( https://www.ietf.org/iesg/template/individual-doc-writeup.txt ) ? Barry From presnick@qualcomm.com Sat Jul 14 13:35:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE49C21F861E for ; Sat, 14 Jul 2012 13:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzRh6Kekf3pH for ; Sat, 14 Jul 2012 13:35:22 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0821F85E3 for ; Sat, 14 Jul 2012 13:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1342298163; x=1373834163; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=JoRfIUyhJoG9oFM2/T4OD3eZer5RqchE/njhn7bcG3M=; b=Lte3d0Fj8jOB/JuW4HT7yoQ9bvPrGGMT6AlRvdhyenMlTGnL5tGr3HF5 ybdJDYAX6N844tOiCmvOkTRSijYVMbYIJRSavGN49mIiKRdGAQAKyexel izwFgnZpRjPIpAdarKxG0VIeK+vY3LahRYIQ4OjFcAyNKZ75Q5IXKqBvZ 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6772"; a="210692690" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 14 Jul 2012 13:36:03 -0700 X-IronPort-AV: E=Sophos;i="4.77,584,1336374000"; d="scan'208";a="289776016" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jul 2012 13:36:02 -0700 Received: from Macintosh-5.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 14 Jul 2012 13:36:01 -0700 Message-ID: <5001D818.4050503@qualcomm.com> Date: Sat, 14 Jul 2012 15:35:36 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: ima@ietf.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 14 Jul 2012 20:35:23 -0000 On 7/2/12 9:57 AM, Barry Leiba wrote: > I think the subject document will do; please review it: > http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group > IANA Considerations should update the Permanent Header Field Registry so that the "From" entry points to this document *in addition to* RFC 5322. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From barryleiba@gmail.com Sat Jul 14 14:01:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6230F21F860D for ; Sat, 14 Jul 2012 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJdvziUpk35c for ; Sat, 14 Jul 2012 14:01:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A459821F8609 for ; Sat, 14 Jul 2012 14:01:06 -0700 (PDT) Received: by qcac10 with SMTP id c10so3023921qca.31 for ; Sat, 14 Jul 2012 14:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EP3zNcyvE05mX0nMOBpl5B+3J5SinxSYCcyM2zh91Xw=; b=nc0DlyLz6jY5rilS+bnWREWfzBQh2gz/xKoKEuN25mb+Mb2gn03VPAq0dXJaXH1bBc 4Ge1Alq05R6qj5lsisYD3J58g+Kc+qnH7KRTxUO2/Ju3ntecisnBKvj1tVfc2Yy8ACEU 3FRHnvADTEc6nP+LLzQv3CQ0Vzb3Jenw1Kj5TvmEtOlNxQfMYQUDYMOtOAeCut+ZUz5Y NTMJunbfjJm2WeD+zYRsCaLnNVqgIDHCuP6zTmbYeOSeBZnjTf//Vacx/0XMPT2nTKd/ jvgq++fbQIA51x05Ncw/Dru36GkvXhTfEFz5QtYA80MmpUHgUXmgp3FylgcMFBqVnjIF p/Wg== MIME-Version: 1.0 Received: by 10.224.196.135 with SMTP id eg7mr11786935qab.24.1342299706208; Sat, 14 Jul 2012 14:01:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Sat, 14 Jul 2012 14:01:45 -0700 (PDT) In-Reply-To: <5001D818.4050503@qualcomm.com> References: <5001D818.4050503@qualcomm.com> Date: Sat, 14 Jul 2012 17:01:45 -0400 X-Google-Sender-Auth: -Z6LvI__hotEPR6Hr4A1fP9lW_U Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 14 Jul 2012 21:01:07 -0000 > IANA Considerations should update the Permanent Header Field Registry > so that > the "From" entry points to this document *in addition to* RFC 5322. Good catch; thanks. Updated -03 submitted. b From alexey.melnikov@isode.com Sun Jul 15 02:39:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821B121F85C4 for ; Sun, 15 Jul 2012 02:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.472 X-Spam-Level: X-Spam-Status: No, score=-101.472 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66bbhb1FEgZl for ; Sun, 15 Jul 2012 02:39:54 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C824521F85C3 for ; Sun, 15 Jul 2012 02:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342345261; d=isode.com; s=selector; i=@isode.com; bh=4W/KZL8l8t0CIUay5o3AWVGCgaqLsSCDe7wpd6J7L5k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Wq6JvjPj3WxFb+hnUDx/0xn8J8e0BqI+jI1+4ilC/mrMTnFB2z1EOKiefXLwYLlbyE8Ukw NATThjknvZHndxXSHYztHX5MbD9mOlVV8Cd6JEUUzY7bq7PReTofZPAx1W8LsOCubarBws JgSZlRXrSG6ROgEunaMZWjCoItt7+Kk=; Received: from [188.28.22.24] (188.28.22.24.threembb.co.uk [188.28.22.24]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 15 Jul 2012 10:41:01 +0100 References: <50000BFB.3050405@isode.com> <00d301cd6179$e6f75b80$c801a8c0@computer> In-Reply-To: <00d301cd6179$e6f75b80$c801a8c0@computer> Message-Id: <5C6AD687-E2EF-476B-92E1-51B209DC060A@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 15 Jul 2012 10:40:26 +0100 To: Jiankang Yao MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: EAI WG Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-popimap-downgrade, draft-ietf-eai-simpledowngrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 09:39:54 -0000 On 14 Jul 2012, at 05:34, "Jiankang Yao" wrote: > ----- Original Message ----- From: "Alexey Melnikov" > To: "Joseph Yee" > Cc: "EAI WG" > Sent: Friday, July 13, 2012 7:52 PM > Subject: Re: [EAI] WG Last Call to RFC5721bis, RFC5738bis, draft-ietf-eai-= popimap-downgrade, draft-ietf-eai-simpledowngrade >=20 >=20 > .... >>=20 >> And finally, if we are making all sorts of other simplifications, can be p= lease also drop the whole section 3.1 (as suggested by Dave Cridland and dis= cussed by Arnt and myself)? >>=20 >=20 > If section 3.1 "IMAP UTF-8 Quoted Strings" is removed, that will give this= document more simplifications. >=20 > I just checked section 3.1 and its relationship with other sections of thi= s document, and found > that it is fine to remove the whole section 3.1. I should have been more specific: the existing "quoted" string should have b= een extended to allow UTF-8. I propose some ABNF changes. >=20 From klensin@jck.com Sun Jul 15 08:48:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC8421F850F for ; Sun, 15 Jul 2012 08:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEGqGLvFWikC for ; Sun, 15 Jul 2012 08:48:50 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D59D221F8508 for ; Sun, 15 Jul 2012 08:48:48 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SqQzL-0008gc-5C for ima@ietf.org; Sun, 15 Jul 2012 11:44:03 -0400 X-Vipre-Scanned: 038E5F0D002C31038E605A-TDI Date: Sun, 15 Jul 2012 11:49:30 -0400 From: John C Klensin To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 15 Jul 2012 15:48:50 -0000 Hi. Just checking that what this document says is what everyone wants... Section 3.2 of draft-ietf-eai-rfc5721bis-05 is very heavily dependent on SASLprep [RFC4013], including MUST requirements. SASLPrep is, in turn, dependent on Stringprep, which is tied to Unicode 3.2. Questions: (1) Could someone who is closer to SASLPrep and the PRECIS work tell us whether they are comfortable with this or whether the text in this spec should be modified somewhat? If any changes are likely to be completely compatible, I don't think there is a problem. However,... (2) If changes are needed, should Section 3.2 be rewritten to explicitly allow conformance with the successors of 4013 as an alternative? I think that would require only a few changes of wording. (3) Or are we better off just leaving this alone and monitoring any 4013bis efforts to make sure they contain provisions to explicitly update our spec when the time comes? These are just questions --if the WG is ok with things as they are, so am I. But I can see this causing questions during IETF Last Call and want to be sure we have considered the issue. john From alexey.melnikov@isode.com Mon Jul 16 08:01:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBFE21F873E for ; Mon, 16 Jul 2012 08:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiuDnpbhxG4k for ; Mon, 16 Jul 2012 08:01:47 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF321F86E4 for ; Mon, 16 Jul 2012 08:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342450982; d=isode.com; s=selector; i=@isode.com; bh=+sb4yELJjOCfbDAEf6OGCMePrxtMFJgp5+yz3GWciVE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tEx+6XT4UWANzVP2hV1bBzNFfzDc2eWVho+RMqkL+GrkzfFrS0JriNlo+d5A1PETe7aqWE v7cMlP1DN2YrZGejTvlxYgjuGBxr/dYYs37KhE2cx3VbJ8ZUFcRHeHrN5NeeibHq2MPFME lAZsJA33YoA1TH83TE9MGK5Ha5Kua8w=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Jul 2012 16:03:02 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50042D03.4060607@isode.com> Date: Mon, 16 Jul 2012 16:02:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Arnt Gulbrandsen References: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> <255e9b7d-644e-45bf-8087-3bcec85d618f@email.android.com> In-Reply-To: <255e9b7d-644e-45bf-8087-3bcec85d618f@email.android.com> 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-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:01:48 -0000 On 14/07/2012 12:08, Arnt Gulbrandsen wrote: > > Now the ability to send Utf8 in quoted strings is completely gone. I > an sorry about that. While it is not critical to correctness, I think > it is important to ease of implementation. > > A client that sent select commands using printf no longer can do that: > the printf format has to change a lot and formally speaking the client > has to wait on a literal. > > Alexey, can you suggest a syntax change to allow utf8 in > quited-strings? (i am afk, sorry.) > Here is the proposed change: 3. UTF8=ACCEPT IMAP Capability The "UTF8=ACCEPT" capability indicates that the server supports the ability to open mailboxes containing internationalized messages with SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB commands. A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in [RFC5161]) to indicate to the server that the client accepts UTF-8 Insert "in" here quoted-strings. Add back the Section 3.1 (slightly modified): 3.1. UTF-8 in IMAP Quoted Strings The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit characters in atoms or quoted strings. Thus, a UTF-8 string can only be sent as a literal. This can be inconvenient from a coding standpoint, and unless the server offers IMAP4 non-synchronizing literals [RFC2088], this requires an extra round trip for each UTF-8 string sent by the client. When the IMAP server advertises the "UTF8=ACCEPT" capability, it informs the client that it supports UTF-8 in quoted-strings with the following syntax: quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE ; QUOTED-CHAR is not modified, as it will affect ; other RFC 3501 ABNF non terminal. uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = UTF8-3 = UTF8-4 = When this extended quoting mechanism is used by the client, then the server MUST reject octet sequences with the high bit set that fail to comply with the formal syntax in [RFC3629] with a BAD response. The IMAP server MUST NOT send UTF-8 in quoted strings to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command. If the server advertises the "UTF8=ACCEPT" capability, the client MAY use extended quoted syntax with any IMAP argument that permits a string (including astring and nstring). However, if characters outside the US-ASCII repertoire are used in an inappropriate place, the results would be the same as if other syntactically valid but semantically invalid characters were used. Specific cases where UTF-8 characters are permitted or not permitted are described in the following paragraphs. All IMAP servers that advertise the "UTF8=ACCEPT" capability SHOULD accept UTF-8 in mailbox names, and those that also support the "Mailbox International Naming Convention" described in RFC 3501, Section 5.1.3 MUST accept utf8-quoted mailbox names and convert them to the appropriate internal format. Mailbox names MUST comply with the Net-Unicode Definition (Section 2 of [RFC5198]) with the specific exception that they MUST NOT contain control characters (0000-001F, 0080-009F), delete (007F), line separator (2028), or paragraph separator (2029). An IMAP client MUST NOT issue a SEARCH command that uses a mixture of UTF-8 in quoted strings and a SEARCH CHARSET other than UTF-8. If an IMAP server receives such a SEARCH command, it SHOULD reject the command with a BAD response (due to the conflicting charset labels). (And add back the removed references: RFC 2088 and RFC 5198) 4. IMAP UTF8 Append Data Extension [...] utf8-literal = "UTF8" SP "(" literal8 ")" It might be worth adding here: literal8 = From arnt@gulbrandsen.priv.no Mon Jul 16 08:15:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E2C21F8675 for ; Mon, 16 Jul 2012 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrRHBHXhBJ8Q for ; Mon, 16 Jul 2012 08:15:55 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 153F221F8673 for ; Mon, 16 Jul 2012 08:15:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id B20CBF8E176; Mon, 16 Jul 2012 15:16:38 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342451796-20772-20771/11/6; Mon, 16 Jul 2012 15:16:36 +0000 Message-Id: <5004305A.10300@gulbrandsen.priv.no> Date: Mon, 16 Jul 2012 17:16:42 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> <255e9b7d-644e-45bf-8087-3bcec85d618f@email.android.com> <50042D03.4060607@isode.com> In-Reply-To: <50042D03.4060607@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:15:56 -0000 On 07/16/2012 05:02 PM, Alexey Melnikov wrote: > Here is the proposed change: I like it, except one thing. > An IMAP client MUST NOT issue a SEARCH command that uses a mixture of > UTF-8 in quoted strings and a SEARCH CHARSET other than UTF-8. If an > IMAP > server receives such a SEARCH command, it SHOULD reject the command > with a BAD response (due to the conflicting charset labels). I implemented that, it wasn't too bad. But I don't really like it. I would feel happier with either a simpler rule like "an IMAP client MUST NOT issue a SEARCH command using CHARSET after enabling blah" or not mentioning CHARSET at all. The rule as proposed is neither very simple nor very good. Arnt From alexey.melnikov@isode.com Mon Jul 16 08:31:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6721F8643 for ; Mon, 16 Jul 2012 08:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKdsEKCGsuU9 for ; Mon, 16 Jul 2012 08:31:05 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6819421F8634 for ; Mon, 16 Jul 2012 08:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342452708; d=isode.com; s=selector; i=@isode.com; bh=6ZWGuXlPTpFOSysyrtYfCpqaWKFd8caPc75Ydt0ZFB8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qiould427CX4GpIab9BWmvlFaaR61710ShSbFZpn2HG5VrVq5f2X5/1EZOY/nVzhBL/xnT iy1ZmINL8ek6667lG0NtWZA0plRgQUiCqWPs4vQgQc1EaGrQjdUAD6EkCjd7dPCPetvrfY ZVFwZRvlD2nzhnDrNVWt0qmlU/kmSPc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Jul 2012 16:31:48 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <500433E3.7010504@isode.com> Date: Mon, 16 Jul 2012 16:31:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Arnt Gulbrandsen References: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> <255e9b7d-644e-45bf-8087-3bcec85d618f@email.android.com> <50042D03.4060607@isode.com> <5004305A.10300@gulbrandsen.priv.no> In-Reply-To: <5004305A.10300@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:31:07 -0000 On 16/07/2012 16:16, Arnt Gulbrandsen wrote: > On 07/16/2012 05:02 PM, Alexey Melnikov wrote: >> Here is the proposed change: > > I like it, except one thing. > >> An IMAP client MUST NOT issue a SEARCH command that uses a >> mixture of >> UTF-8 in quoted strings and a SEARCH CHARSET other than UTF-8. If an >> IMAP >> server receives such a SEARCH command, it SHOULD reject the command >> with a BAD response (due to the conflicting charset labels). > > I implemented that, it wasn't too bad. But I don't really like it. I > would feel happier with either a simpler rule like "an IMAP client > MUST NOT issue a SEARCH command using CHARSET after enabling blah" or > not mentioning CHARSET at all. I don't like the latter. I think the default is US-ASCII, so we need to say that we are changing the default if UTF-8 is used in quoted strings or something like that. > The rule as proposed is neither very simple nor very good. Please explain, I think this is a very simple check. From arnt@gulbrandsen.priv.no Mon Jul 16 08:50:58 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F311E80C1 for ; Mon, 16 Jul 2012 08:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0VtyaXGMVjd for ; Mon, 16 Jul 2012 08:50:57 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9069411E8079 for ; Mon, 16 Jul 2012 08:50:57 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 10F42F8E183; Mon, 16 Jul 2012 15:51:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342453901-27311-27310/10/1; Mon, 16 Jul 2012 15:51:41 +0000 Message-Id: <50043892.3010806@gulbrandsen.priv.no> Date: Mon, 16 Jul 2012 17:51:46 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <20120714103018.10197.33704.idtracker@ietfa.amsl.com> <255e9b7d-644e-45bf-8087-3bcec85d618f@email.android.com> <50042D03.4060607@isode.com> <5004305A.10300@gulbrandsen.priv.no> <500433E3.7010504@isode.com> In-Reply-To: <500433E3.7010504@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:50:58 -0000 On 07/16/2012 05:31 PM, Alexey Melnikov wrote: > Please explain, I think this is a very simple check. It's not related to actual needs. Good checks prevent breakage, that=20 check prevents nothing at all. The server has to parse and handle=20 CHARSET with any and all values, unless it's willing to turn away=20 clients that do not send the ENABLE. Since the server has the code to do that, why not let all the clients=20 use it? IMO CHARSET is an offensive mess and should be taken out and shot. But=20 if we're going to keep it we should keep it. The rule you're suggesting=20 is neither here nor there. Think about it: You're suggesting that both d=20 and e are legal, but not f: a enable utf8=3Daccept b login alexey foo c select inbox d search charset iso64610 subject "bl}b{rsyltet|y" e search subject "bl=E5b=E6rsyltet=F8y" f search charset iso64610 subject "bl}b{rsyltet|y" text "bl=E5b=E6rsy= ltet=F8y" I'm saying that if d is legal after a, so is f, and that f is illegal=20 after a, then so is d. (Yes, the example looks a lot worse if you use latin1 or viscii or=20 something, with ugly literals and blah. The point is unchanged.) Arnt From alexey.melnikov@isode.com Mon Jul 16 09:59:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC311E8157 for ; Mon, 16 Jul 2012 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.017 X-Spam-Level: X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG7g6bVZcf8J for ; Mon, 16 Jul 2012 09:59:18 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3032211E8158 for ; Mon, 16 Jul 2012 09:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342458002; d=isode.com; s=selector; i=@isode.com; bh=9oUAiz+M6mhQ4KOTMeNQA2w62aQv2N19bmDifqrpSrM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=liiHZGOdztUUQikdTVhWR6+VVIX44lHqTsGrmZcvhF6x5OAYNYMrq36CJ2aEAkLgDg06eQ fHJeEhG2rhs3pP0Aq/FP/MqbIq19yAacOchcCz4TJQxczIYYB+DP1MMj7uLoH6kDTro8Aj IAwc9vyXaQZuSIcR/vQOQsrY2yNY4Sc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Jul 2012 18:00:02 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5004488E.4020307@isode.com> Date: Mon, 16 Jul 2012 17:59:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: John C Klensin References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 16 Jul 2012 16:59:19 -0000 On 15/07/2012 16:49, John C Klensin wrote: > Hi. Hi John, > Just checking that what this document says is what everyone > wants... > > Section 3.2 of draft-ietf-eai-rfc5721bis-05 is very heavily > dependent on SASLprep [RFC4013], including MUST requirements. > SASLPrep is, in turn, dependent on Stringprep, which is tied to > Unicode 3.2. Questions: > > (1) Could someone who is closer to SASLPrep and the PRECIS work > tell us whether they are comfortable with this or whether the > text in this spec should be modified somewhat? If any changes > are likely to be completely compatible, I don't think there is a > problem. However,... > > (2) If changes are needed, should Section 3.2 be rewritten to > explicitly allow conformance with the successors of 4013 as an > alternative? I think that would require only a few changes of > wording. But that would require pointing to a document with unclear date of completion... > (3) Or are we better off just leaving this alone and monitoring > any 4013bis efforts to make sure they contain provisions to > explicitly update our spec when the time comes? > > These are just questions --if the WG is ok with things as they > are, so am I. But I can see this causing questions during IETF > Last Call and want to be sure we have considered the issue. I think (3) is the best way forward, but just my 2 pence. From klensin@jck.com Mon Jul 16 10:09:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD521F879C for ; Mon, 16 Jul 2012 10:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqV9Qs7IRcHb for ; Mon, 16 Jul 2012 10:09:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 760F721F8793 for ; Mon, 16 Jul 2012 10:09:16 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sqoim-000Aqm-3w; Mon, 16 Jul 2012 13:04:32 -0400 Date: Mon, 16 Jul 2012 13:09:48 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> In-Reply-To: <5004488E.4020307@isode.com> References: <5004488E.4020307@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 16 Jul 2012 17:09:17 -0000 --On Monday, July 16, 2012 17:59 +0100 Alexey Melnikov wrote: Alexey, thanks. >... >> (2) If changes are needed, should Section 3.2 be rewritten to >> explicitly allow conformance with the successors of 4013 as an >> alternative? I think that would require only a few changes of >> wording. > But that would require pointing to a document with unclear > date of completion... Nope. It would require saying something like "MUST conform to 4013 or one of its standards-track successors". That doesn't promise that there will be such successors much less when they will be done. And it ties the MUST to any version, not the particular version represented by 4013. I am _not_ suggesting that is the best thing to do, only that it wouldn't be hard if we decided to do it. >> (3) Or are we better off just leaving this alone and >> monitoring any 4013bis efforts to make sure they contain >> provisions to explicitly update our spec when the time comes? >> >> These are just questions --if the WG is ok with things as they >> are, so am I. But I can see this causing questions during >> IETF Last Call and want to be sure we have considered the >> issue. > > I think (3) is the best way forward, but just my 2 pence. Wfm. I just need some signs of consensus, rough or otherwise. john From arnt@gulbrandsen.priv.no Mon Jul 16 10:22:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2945A11E823E for ; Mon, 16 Jul 2012 10:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO4EVGtCYXRF for ; Mon, 16 Jul 2012 10:22:00 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF111E823B for ; Mon, 16 Jul 2012 10:21:59 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 150DEF8E1D5; Mon, 16 Jul 2012 17:22:44 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342459363-27311-27310/10/2; Mon, 16 Jul 2012 17:22:43 +0000 Message-Id: <50044DE9.9030901@gulbrandsen.priv.no> Date: Mon, 16 Jul 2012 19:22:49 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 16 Jul 2012 17:22:01 -0000 I think the substance of the requirements is fine. On 07/15/2012 05:49 PM, John C Klensin wrote: > (3) Or are we better off just leaving this alone and monitoring > any 4013bis efforts to make sure they contain provisions to > explicitly update our spec when the time comes? I'm sure some pedant will scan for 4013 references if/when 4013 is updated, so let's just leverage that pedantry for our comfort. Arnt (occasional pedant) From internet-drafts@ietf.org Mon Jul 16 16:48:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B70C11E8333; Mon, 16 Jul 2012 16:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47r+i6Z5vgeo; Mon, 16 Jul 2012 16:48:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057B411E8335; Mon, 16 Jul 2012 16:48:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716234853.11029.69290.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:48:53 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5721bis-06.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, 16 Jul 2012 23:48:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g 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-06.txt Pages : 13 Date : 2012-07-16 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-rfc5721bis-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-rfc5721bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaojk@cnnic.cn Mon Jul 16 16:50:24 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991B411E831D for ; Mon, 16 Jul 2012 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=1.839, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7p7laZbgKTC for ; Mon, 16 Jul 2012 16:50:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 402C511E82F9 for ; Mon, 16 Jul 2012 16:50:22 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 17 Jul 2012 07:51:03 +0800 Message-ID: <003e01cd63ad$dd1c3dc0$c801a8c0@computer> From: "Jiankang Yao" To: "Arnt Gulbrandsen" , References: <50044DE9.9030901@gulbrandsen.priv.no> Date: Tue, 17 Jul 2012 07:51:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 16 Jul 2012 23:50:24 -0000 ----- Original Message ----- From: "Arnt Gulbrandsen" To: Sent: Tuesday, July 17, 2012 1:22 AM Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep >I think the substance of the requirements is fine. > > On 07/15/2012 05:49 PM, John C Klensin wrote: >> (3) Or are we better off just leaving this alone and monitoring >> any 4013bis efforts to make sure they contain provisions to >> explicitly update our spec when the time comes? > > I'm sure some pedant will scan for 4013 references if/when 4013 is > updated, so let's just leverage that pedantry for our comfort. > I think that adding the sentence similar to "MUST conform to 4013 or one of its standards-track successors" is to help readers to look for the new version of rfc 4013, instead of depending on pedant tools only. Since the new version of rfc 4013 is very likely to come, I add the " one of its standards-track successors" to the new version. I think that it is a very small change. Jiankang Yao > Arnt > (occasional pedant) > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From internet-drafts@ietf.org Mon Jul 16 17:05:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB211E812C; Mon, 16 Jul 2012 17:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4wPgorQGgRG; Mon, 16 Jul 2012 17:05:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9390311E8155; Mon, 16 Jul 2012 17:05:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120717000553.26102.60535.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 17:05:53 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-5738bis-06.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, 17 Jul 2012 00:05:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g Group of the IETF. Title : IMAP Support for UTF-8 Author(s) : Pete Resnick Chris Newman Sean Shen Filename : draft-ietf-eai-5738bis-06.txt Pages : 10 Date : 2012-07-16 Abstract: 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. This specification replaces RFC 5738. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-5738bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-5738bis-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-5738bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaojk@cnnic.cn Mon Jul 16 17:07:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E09611E812C for ; Mon, 16 Jul 2012 17:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.927 X-Spam-Level: X-Spam-Status: No, score=-100.927 tagged_above=-999 required=5 tests=[AWL=1.671, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmZxFQqC0s-S for ; Mon, 16 Jul 2012 17:07:51 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 82A6321F876D for ; Mon, 16 Jul 2012 17:07:49 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 17 Jul 2012 08:08:29 +0800 Message-ID: <008201cd63b0$4cd27fb0$c801a8c0@computer> From: "Jiankang Yao" To: "John C Klensin" , "Alexey Melnikov" References: <5004488E.4020307@isode.com> <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> Date: Tue, 17 Jul 2012 08:08:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 17 Jul 2012 00:07:51 -0000 ----- Original Message ----- From: "John C Klensin" To: "Alexey Melnikov" Cc: "EAI WG" Sent: Tuesday, July 17, 2012 1:09 AM Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep > > > --On Monday, July 16, 2012 17:59 +0100 Alexey Melnikov > wrote: > > Alexey, thanks. >>... >>> (2) If changes are needed, should Section 3.2 be rewritten to >>> explicitly allow conformance with the successors of 4013 as an >>> alternative? I think that would require only a few changes of >>> wording. > >> But that would require pointing to a document with unclear >> date of completion... > > Nope. It would require saying something like "MUST conform to > 4013 or one of its standards-track successors". That doesn't > promise that there will be such successors much less when they > will be done. And it ties the MUST to any version, not the > particular version represented by 4013. I am _not_ suggesting > that is the best thing to do, only that it wouldn't be hard if > we decided to do it. > I think that your suggestion saying something like "MUST conform to 4013 or one of its standards-track successors" is something between choice 2 and 3. Since the time to submission cut off is coming, I have submitted the new version. If the WG has the consensus on it, we can update it or keep it. Jiankang Yao >>> (3) Or are we better off just leaving this alone and >>> monitoring any 4013bis efforts to make sure they contain >>> provisions to explicitly update our spec when the time comes? >>> >>> These are just questions --if the WG is ok with things as they >>> are, so am I. But I can see this causing questions during >>> IETF Last Call and want to be sure we have considered the >>> issue. >> >> I think (3) is the best way forward, but just my 2 pence. > > Wfm. I just need some signs of consensus, rough or otherwise. > > john > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From duerst@it.aoyama.ac.jp Tue Jul 17 00:53:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C9521F8593 for ; Tue, 17 Jul 2012 00:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.708 X-Spam-Level: X-Spam-Status: No, score=-99.708 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xid-ZGpv9Ep6 for ; Tue, 17 Jul 2012 00:53:37 -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 2FC2521F84B5 for ; Tue, 17 Jul 2012 00:53:36 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6H7sI4x032112 for ; Tue, 17 Jul 2012 16:54:18 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7fc1_a45e_9c65fbc4_cfe4_11e1_9168_001d096c566a; Tue, 17 Jul 2012 16:54:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41699) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 17 Jul 2012 16:54:22 +0900 Message-ID: <50051A25.3040708@it.aoyama.ac.jp> Date: Tue, 17 Jul 2012 16:54:13 +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: ima@ietf.org References: <20120717000553.26102.60535.idtracker@ietfa.amsl.com> In-Reply-To: <20120717000553.26102.60535.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-06.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, 17 Jul 2012 07:53:38 -0000 This is a minor comment, and can be ignored if it has been discussed already. On 2012/07/17 9:05, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email Address Internationalization Working Group of the IETF. > > Title : IMAP Support for UTF-8 > Author(s) : Pete Resnick > Chris Newman > Sean Shen > Filename : draft-ietf-eai-5738bis-06.txt > Pages : 10 > Date : 2012-07-16 > > Abstract: > 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. This > specification replaces RFC 5738. Title : POP3 Support for UTF-8 Author(s) : Randall Gellens Chris Newman Jiankang Yao Kazunori Fujiwara Filename : draft-ietf-eai-rfc5721bis-06.txt Pages : 13 Date : 2012-07-16 Abstract: 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. I suggest streamlining the abstracts. In particular, it would be better to have "UTF-8 encoded" rather than "un-encoded" in the POP3 abstract. I was also thinking about titles with a bit more detail (after all, UTF-8 can be used in mail messages with these protocols today), but I haven't come up with a good solution yet. Regards, Martin. From arnt@gulbrandsen.priv.no Tue Jul 17 01:15:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DB621F8666 for ; Tue, 17 Jul 2012 01:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 979NhWa7cmDQ for ; Tue, 17 Jul 2012 01:15:22 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3D21F8665 for ; Tue, 17 Jul 2012 01:15:21 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 15AEEF8E085; Tue, 17 Jul 2012 08:16:07 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1342512966-27311-27310/10/4; Tue, 17 Jul 2012 08:16:06 +0000 Message-Id: <50051F4D.2020302@gulbrandsen.priv.no> Date: Tue, 17 Jul 2012 10:16:13 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: ima@ietf.org References: <20120717000553.26102.60535.idtracker@ietfa.amsl.com> In-Reply-To: <20120717000553.26102.60535.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-06.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, 17 Jul 2012 08:15:24 -0000 On 07/17/2012 02:05 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Email Address Internationalization = Working Group of the IETF. > > Title : IMAP Support for UTF-8 I've read the -05 document and the 05-06 diff and am happy, except that=20 my comment about CHARSET stands. I'll check my code against -06 later this week. Arnt From klensin@jck.com Tue Jul 17 05:35:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45D21F86DA for ; Tue, 17 Jul 2012 05:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omD807rXghJD for ; Tue, 17 Jul 2012 05:35:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA1F21F86BA for ; Tue, 17 Jul 2012 05:35:26 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr6vB-000CVy-RD; Tue, 17 Jul 2012 08:30:33 -0400 Date: Tue, 17 Jul 2012 08:35:51 -0400 From: John C Klensin To: Jiankang Yao , Alexey Melnikov Message-ID: <88119810B6E1D0E369999538@JcK-HP8200.jck.com> In-Reply-To: <008201cd63b0$4cd27fb0$c801a8c0@computer> References: <5004488E.4020307@isode.com> <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> <008201cd63b0$4cd27fb0$c801a8c0@computer> 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: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 17 Jul 2012 12:35:26 -0000 --On Tuesday, July 17, 2012 08:08 +0800 Jiankang Yao wrote: >... >... >>>> (2) If changes are needed, should Section 3.2 be rewritten >>>> to explicitly allow conformance with the successors of 4013 >>>> as an alternative? I think that would require only a few >>>> changes of wording. >> >>> But that would require pointing to a document with unclear >>> date of completion... >> >> Nope. It would require saying something like "MUST conform to >> 4013 or one of its standards-track successors". That doesn't >> promise that there will be such successors much less when they >> will be done. And it ties the MUST to any version, not the >> particular version represented by 4013. I am _not_ suggesting >> that is the best thing to do, only that it wouldn't be hard if >> we decided to do it. >> > > I think that your suggestion saying something like "MUST > conform to > 4013 or one of its standards-track successors" is something > between choice 2 and 3. > Since the time to submission cut off is coming, I have > submitted the new version. > If the WG has the consensus on it, we can update it or keep it. Thanks. What do others think? john From klensin@jck.com Tue Jul 17 05:52:30 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B364F21F86E1 for ; Tue, 17 Jul 2012 05:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd8r98n5FHDL for ; Tue, 17 Jul 2012 05:52:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CCA7521F86E0 for ; Tue, 17 Jul 2012 05:52:29 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr7Bq-000CXI-He for ima@ietf.org; Tue, 17 Jul 2012 08:47:46 -0400 Date: Tue, 17 Jul 2012 08:53:04 -0400 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] EAI agenda for IETF 84 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, 17 Jul 2012 12:52:30 -0000 Hi. The agendas are now due. I believe that our agenda is: 1 Intro and agenda bash 2 Review of status of mailinglist draft. We expect this draft to be somewhere in the IETF Last Call/ IESG review process, so, if we are lucky, this is a non-item. 3 Status and any required actions on the four POP-IMAP drafts. We hope to have IETF LC started on them before the meeting starts, but something will undoubtedly need to be discussed. 4 MAILTO and and other related protocol items 5 Plans for the WG, including any discussion that is needed about the "advice" drafts 6 AOB Any additions or comments? john From jyee@afilias.info Tue Jul 17 06:42:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E56921F86C1 for ; Tue, 17 Jul 2012 06:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.481 X-Spam-Level: X-Spam-Status: No, score=-5.481 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVa8dsNPxLdh for ; Tue, 17 Jul 2012 06:41:59 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A221F86B6 for ; Tue, 17 Jul 2012 06:41:59 -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 1Sr833-0002p2-9W for ima@ietf.org; Tue, 17 Jul 2012 13:42:46 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Sr833-0002SO-5Z for ima@ietf.org; Tue, 17 Jul 2012 13:42:45 +0000 Received: by mail-vb0-f50.google.com with SMTP id l1so266539vba.9 for ; Tue, 17 Jul 2012 06:42:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vHyPzuJ8bPqxaGYWTpdoZKaKKGt9rMPVz1X+Ljwv3Fk=; b=KJUWDYspH5RIiKkp8NlaaJz27Y6aKrjeEQW/cCO9aUqPEZUexDkX8fXRQ3mJYM5kjR u26W5RoW9QLeXaX+/FDRk/7lZqteAM3aP86/H9DzDPWtA9OHbbS0A2W66ZbPxs1NB3ju Yk+Ub9c2ZbIY3IRN7Xghf+KN4zju8ebWdJAGWu/6ekzcBtn9BQpLb8CW0pN891nUnJDD 6ZlT1rcdP8rTzuNtKt8BxtHeLTbrnlyVOO6gD7D8wX/ZWl9WEVgYNH0gsXeRiE9Pfy2p wfzii2AQdMxwon/t8uUxv1HrSkgV4cuXa/OjZfDxY5mJxNOrC6lCgKl9QASvZ4bQ6+iw ebeA== MIME-Version: 1.0 Received: by 10.52.95.110 with SMTP id dj14mr1022085vdb.69.1342532565432; Tue, 17 Jul 2012 06:42:45 -0700 (PDT) Received: by 10.52.158.34 with HTTP; Tue, 17 Jul 2012 06:42:45 -0700 (PDT) In-Reply-To: <88119810B6E1D0E369999538@JcK-HP8200.jck.com> References: <5004488E.4020307@isode.com> <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> <008201cd63b0$4cd27fb0$c801a8c0@computer> <88119810B6E1D0E369999538@JcK-HP8200.jck.com> Date: Tue, 17 Jul 2012 09:42:45 -0400 Message-ID: From: Joseph Yee To: John C Klensin Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlqALNf/c/VSGYGNTJ7okbODFgjYfsl8RiaWDMY5MYGb9QbGDByT5CNFAgFQ7fMkM+H0Pxj Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 17 Jul 2012 13:42:00 -0000 Personal thought. If we picked (2) with "... or one of its standards-track successors", then I have some concern whether the following paragraph (the 4th in section 3.2, about how to apply SASLprep on different arguments) may trip or confuse readers. I may simply worry too much [I hope]. If we picked (3), are we meant to write another bis when RFC4013 being updated/obsoleted? That say, I prefer (2), and would like to ask others if leaving the 4th paragraph unchanged ok. Joseph On Tue, Jul 17, 2012 at 8:35 AM, John C Klensin wrote: > > > --On Tuesday, July 17, 2012 08:08 +0800 Jiankang Yao > wrote: > >>... >>... >>>>> (2) If changes are needed, should Section 3.2 be rewritten >>>>> to explicitly allow conformance with the successors of 4013 >>>>> as an alternative? I think that would require only a few >>>>> changes of wording. >>> >>>> But that would require pointing to a document with unclear >>>> date of completion... >>> >>> Nope. It would require saying something like "MUST conform to >>> 4013 or one of its standards-track successors". That doesn't >>> promise that there will be such successors much less when they >>> will be done. And it ties the MUST to any version, not the >>> particular version represented by 4013. I am _not_ suggesting >>> that is the best thing to do, only that it wouldn't be hard if >>> we decided to do it. >>> >> >> I think that your suggestion saying something like "MUST >> conform to >> 4013 or one of its standards-track successors" is something >> between choice 2 and 3. >> Since the time to submission cut off is coming, I have >> submitted the new version. >> If the WG has the consensus on it, we can update it or keep it. > > Thanks. What do others think? > > john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Tue Jul 17 07:03:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3815421F86AB for ; Tue, 17 Jul 2012 07:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n5nSPFA3tmU for ; Tue, 17 Jul 2012 07:03:21 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id AA8A221F86A5 for ; Tue, 17 Jul 2012 07:03:21 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr8IL-000Cc0-EX; Tue, 17 Jul 2012 09:58:33 -0400 Date: Tue, 17 Jul 2012 10:03:51 -0400 From: John C Klensin To: Joseph Yee Message-ID: <8713159766AF3B2C9C88DD98@JcK-HP8200.jck.com> In-Reply-To: References: <5004488E.4020307@isode.com> <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> <008201cd63b0$4cd27fb0$c801a8c0@computer> <88119810B6E1D0E369999538@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 17 Jul 2012 14:03:22 -0000 --On Tuesday, July 17, 2012 09:42 -0400 Joseph Yee wrote: > Personal thought. > > If we picked (2) with "... or one of its standards-track > successors", then I have some concern whether the following > paragraph (the 4th in section 3.2, about how to apply SASLprep > on different arguments) may trip or confuse readers. I may > simply worry too much [I hope]. See the notes I am about to post. Already noted that. Sometimes Jiankang reacts a bit too quickly and doesn't bother to think about context, but this isn't the first time. > If we picked (3), are we meant to write another bis when > RFC4013 being updated/obsoleted? I'd hope that 4013bis would explicitly update this document. > That say, I prefer (2), and would like to ask others if > leaving the 4th paragraph unchanged ok. Wait for my notes to appear on the list. john From klensin@jck.com Tue Jul 17 07:13:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5304721F86F9 for ; Tue, 17 Jul 2012 07:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRNZtG1WQqmL for ; Tue, 17 Jul 2012 07:13:01 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id C903821F86F4 for ; Tue, 17 Jul 2012 07:13:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr8Rm-000Ccd-FH for ima@ietf.org; Tue, 17 Jul 2012 10:08:18 -0400 Date: Tue, 17 Jul 2012 10:13:31 -0400 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] In-depth reviews of POP and IMAP specs 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, 17 Jul 2012 14:13:02 -0000 Hi. I had intended to wait until I had all four reviews ready, but the process is going much more slowly than I had expected (unfortunately, other things, such as responses to Martin's notes are backed up behind them). So I'm going to send the reviews out separately -- POP and IMAP today and I hope the two "downgrade" docs later in the week. As with the detailed review on mailinglist, a lot of these comments are editorial issues. Resolving them now is quite likely to lower the pain level during Last Call, IESG review, and interactions with the RFC Editor (before and after AUTH48). Other issues are raised to help me/us write Shepherd's reports -- having them on these lists and having people review them puts us on much firmer ground when we say "yes the WG reviewed that issue". If there are any questions raised in or by these notes (they do contain some semi-substantive stuff), I hope we can resolve them well before various of us head for Vancouver. best, john From klensin@jck.com Tue Jul 17 07:16:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55021F8702 for ; Tue, 17 Jul 2012 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEJ6eRUr1UBY for ; Tue, 17 Jul 2012 07:16:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 36B7D21F853B for ; Tue, 17 Jul 2012 07:16:30 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr8V9-000CdB-0U for ima@ietf.org; Tue, 17 Jul 2012 10:11:47 -0400 Date: Tue, 17 Jul 2012 10:17:04 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <94F2925BA3119ED310C5A8AA@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========DFF10572CCBD41000FFE==========" Subject: [EAI] Comprehensive WG LC review of draft-ietf-eai-5738bis-06 (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, 17 Jul 2012 14:16:31 -0000 --==========DFF10572CCBD41000FFE========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. Review attached as promised. The funky numbering is due to this having been mostly complete on -04. There might still be some residual issues from it. Martin raised the question of whether the titles of these documents are really what we want. This is just about the last chance if anyone has strong feelings and specific suggestions. best, john --==========DFF10572CCBD41000FFE========== Content-Type: text/plain; charset=utf-8; name="eai-imap-review.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eai-imap-review.txt"; size=5934 draft-ietf-eai-5738bis-06 (1) Introduction, paragraph 1 Nit: Extra space after "[RFC6532]" and before "." in the first sentence.=20 I believe that the Introduction would be improved by starting it with a paragraph very similar to the first paragraph of the introduction to draft-ietf-eai-rfc5721bis (ideally as modified in response to this set of comments). (1a) Introduction, paragraph 3 I believe this is sufficient, but someone is almost certain to want a complete discussion about differences from 5738. We should prepare for a small snit about refusing. I note that the POP spec (5271bis) provides a pointer to RFC 6530, but it is mostly handwaving. (2) Section 2. =20 Having read through this and had to go back and check the IMAPspec to be sure I understoods parts of what was being said, I suggest inserting a sentence into Section 2 that says that, in addition to the ABNF, this document assumes that the reader will have a reasonably good understanding of RFC 3501 and = itvarious update. (3) Section 3, Second Paragraph: The text reads A client MUST use the "ENABLE UTF8=3DACCEPT" command (defined = in [RFC5161]) ... But RFC 5161 defines "ENABLE", but not "ENABLE UTF8". Please clarify. One way to do that would be to say something like: A client MUST use the "ENABLE" command (defined in [RFC5161]) with the "UTF8=3DACCEPT" option (defined in = Section 4 below)... (3a) Section 3.1 (new in -06 Nit: The RFC Editor is unlikely to like a Section 3.1 without a Section 3.2. Either change the numbering/structuring or be prepared to defend it. Placeholder note: See Arnt's comments about literals and SEARCH parameters on the mailing list; WG should be sure we are ok with where the text stands.. (4) (fixed in -06) =20 (5) Section 4, second paragraph and Section 8. The Section 4 text reads: Mechanisms for 7-bit downgrading to help comply with the standards are discussed in [popimap-downgrade]. I think we have agreed to make the POP and IMAP documents agnostic about downgrading mechanisms. This sentence therefore needs to be eliminated or replaced by something like=20 Some examples of mechanisms for 7-bit downgrading to help comply with the standards are discussed in [popimap-downgrade] and [simpledowngrade]. or The issue of handling messages containing non-ASCII characters in legacy environments is discussed in Section 7. There may be better ways to handle that problem, but something should be done. The same problem occurs in Section 8 and should be fixed there as well. (6) Section 5, 2nd paragraph: Typo: "syntacically" should be "syntactically". And consider changing "Although this" to "Although the use of the IMAP AUTHENTICATE command in this way". But I'm not sure that paragraph is needed at all. It changes nothing from what is already in the IMAP AUTHENTICATE definition. (7) Section 6, paragraph 2, Section 3 paragraph 2, and Section 4 paragraph 4. The text in Section 6 reads: The "UTF8=3DONLY" capability implies the "UTF8=3DACCEPT" = capability. UTF8=3DACCEPT and UTF8=3DONLY SHOULD be mutually exclusive. = An IMAP server can advertise one of them, but never both. That isn't what "implies" means to me. Using an EAI SMTP example, SMTPUTF8 can be said to imply 8BITMIME because a server is forbidden to advertise SMTPUTF8 without also advertising 8BITMIME. The WG chose to require that 8BITMIME be advertised explicitly rather than implied by the presence of SMTPUTF8, but there would not be an issue of "mutually exclusive". Please either fix this (and adjust the other two sections or reduce the redundancy) or explain the intent better. =20 I think what is intended could be expressed in the last paragraph of this section with something like: If the "UTF8=3DONLY" capability is specified, UTF-8 must be accepted as if the "UTF8=3DACCEPT" had been specified. For convenience, the explicit combination of "UTF8=3DONLY" and "UTF8=3DACCPET" is not allowed. The first sentence of that section is already a bit long, but could be made more specific by saying: The "UTF8=3DONLY" capability permits an IMAP server to advertise that it does not support the international mailbox name convention (modified UTF-7), allows all of the capabilities that are allowed by "UTF8=3DACCEPT" (see Section 4), and does not permit... In other words, "UTF8=3DONLY" is not mutually exclusive (except in syntax) with "UTF8=3DALLOW", nor does it imply the latter. = It basically specifies the same capability as "UTF8=3DALLOW" and adds a restriction. (8) Section 7, paragraph 2 The text reads=20 "include hiding the problematic message(s) as outlined elsewhere in this specification," I couldn't easily find that discussion. Please insert an explicit cross-reference instead of "elsewhere in this specification" or make this clause unnecessary. (9) Section 7, paragraph 3 (editorial nit) Old: not really "downgraded" (ones although New: not really "downgraded" ones) although (10) Section 7, last paragraph (editorial nit) Old: impossible, at least at the time, New: impossible, at least at the present time, (11) Section 11.1 and 11.2 (references). These are in sort of random order within each subsection. Pleaes either alphabetize them by author name or list the citation anchors in alphabetical/ numerical order. (12) Appendix B. The title of this appendix came out "Appendix B. Appendix B. ...". The usual style in the RFC series is to make the acknowledgments a numbered section, not an appendix. I recommend making that change before the RFC Editor does. (13) Change log I hope no one will ask why there is no version-to-version change log in this document, but we certainly should not go to the effort to add one now. --==========DFF10572CCBD41000FFE==========-- From klensin@jck.com Tue Jul 17 07:19:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC021F86F2 for ; Tue, 17 Jul 2012 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnDChiLyOL0T for ; Tue, 17 Jul 2012 07:19:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9E321F86EF for ; Tue, 17 Jul 2012 07:19:35 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr8Y7-000CdN-R2 for ima@ietf.org; Tue, 17 Jul 2012 10:14:51 -0400 Date: Tue, 17 Jul 2012 10:20:09 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <4B6B135AC1F3A7A8A2C6F6B7@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========0E08BA8E6BE71F15A7BD==========" Subject: [EAI] Comprehensive WG LC review of draft-ietf-eai-rfc5721bis-06.txt (POP3) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 14:19:36 -0000 --==========0E08BA8E6BE71F15A7BD========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. Review attached as promised. The funky numbering is due to this having been mostly complete on -05. There might still be some residual issues from it. Martin raised the question of whether the titles of these documents are really what we want. This is just about the last chance if anyone has strong feelings and specific suggestions. best, john --==========0E08BA8E6BE71F15A7BD========== Content-Type: text/plain; charset=utf-8; name="eai-pop-review.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eai-pop-review.txt"; size=11666 draft-ietf-eai-rfc5721bis-06.txt General observation: The core of this specification as far as the EAI work is concerned is the UTF8 Capability, commands, etc. (Section 3). LANG is useful but less important. Think about whether you want to reverse the order of Sections 2 and 3. I think this is a matter of author discretion, but wanted to mention it. The vast majority of these comments are just editorial issues, even though some people may feel strongly about some of them. The suggestions in notes 13 (partially a placeholder) and 15 are most likely substantive. (1) Abstract Given that all characters used on computers are coded, would "conventionally encoded", "non-ASCII", or, with a bit of restructuring "characters outside the ASCII repertoire without special coding" be better than "un-encoded"?. See also = Martin D=FCrst's Tuesday, July 17, 2012 16:54 +0900 email about using "UTF-8 encoded" as another alternative. Note that the IMAP spec uses "UTF-8 encoded", so there is also an argument for consistency. See the Introduction for more of this. (2) Introduction, paragraph 1 Please try to eliminate the term "EAI" from this paragraph. It is really just the accidental name of a WG. "Email Address Internationalization" is ok. There is really no such thing as a "UTF-8 Character". There are only Unicode characters encoded in UTF-8. Similarly, "un-encoded UTF-8 characters" should probably be "un-encoded UTF-8 strings containing characters outside the ASCII repertoire" or words to that effect in the paragraph and the next one. (3) Section 1, paragraph 2 Nit: Missing right parenthesis after the citation. I.e., the end of the sentence should be=20 as described in "Internationalized Email Headers" [RFC6532]). Nit: As the second sentence is now constructed, the comma before "and a mechanism to support" doesn't belong there. (3) Section 1, paragraph 3 doesn't quite parse. Perhaps: This specification also adds a new response code to indicate that a message was not delivered because it required UTF-8 mode and the server was unable or unwilling to create and deliver a variant form of the message as discussed in Section 7 of [I-D.ietf-eai-5738bis].=20 That might be further improved by breaking into two sentences.=20 Also, "UTF-8 mode" is not defined. That could be handled with a sentence or even a parenthetical note in one of the prior paragraphs. It could also be done with a forward reference to the "Discussion" in Section 3, but that is a fairly large jump. (4) Section 1, paragraph 4.=20 Opinions differ as to whethr or not "Section 6 of [RFC6530]" represents an acceptable writing style and conversely whether "between RFC 5721 [RFC5721]" is just too clumsy. Until and unless the RFC Editor says something definitive, I believe it should be a matter of editorial discretion. But please pick a convention and stick to it, especially within the same sentence. Also, the pointer to RFC 6530 is mostly hand waving because it = doesn't explicitly mention the IMAP or POP work at all. Perhaps it = would be better if the sentence read more like "Section 6 of [RFC6530] describes the motivation for most of the substantive changes in approach between RFC 5721 and this specification." (the citation = for RFC 5721 is not needed because it is cited in the prior = sentence). But even that isn't quite true because we don't forbid = downgrading between the POP or IMAP server and the client. You might just = drop the sentence. Someone will probably complain that we haven't provided a = complete description of the changes. I so, we will just need to push = back -- the issue was discussed at length in the WG.=20 (5) Section 1.1, paragraph 3 Editorial discretion here, but note that there is no such thing as an "ASCII character" with more than seven bits in it. Consequently "always use 7-bit ASCII characters" is at least redundant and may be confusing. I have no idea what=20 "...format; Otherwise, some examples for the "LANG" command may appear incorrectly as a result. Means, but "Otherwise" should not be capitalized and the combination of "otherwise" and "as a result" is redundant. (6) Section 2, 3rd paragraph, 2nd sentence of "Discussion" This sentence doesn't work. Try If the command succeeds, the server returns a +OK response followed by a single space, the exact language tag selected, abd another space. Human-readable text in the appropriate language then appears in the rest of the line. (7) Section 2, 4th paragraph of "Discussion" This paragraph should be explicit about what "language was previously active" before any LANG command was specified. (8) Section 2, 6th and 7th paragraph This is harder to follow than it needs to be. The first of these paragraphs would probably be improved by saying If the client issues a LANG command with the special "*" language range argument, it indicates... Similarly, consider substituting If no argument is given and the server issues a positive response, that response will usually consist of multiple lines. For the first sentence of=20 (9) Section 2, Examples Pointed brackets, as in "< Note that some ... of this document format. >" and similar text below are rarely, if ever, used in RFCs to set text off. Probably nothing is necessary other than the separate paragraph. If you prefer, use parentheses or square brackets, indent things differently, and/or put in an explicit note asking the RFC Editor to apply their talents to making it readable (author discretion). In any event this doesn't need to be said more than once (see note 5 above). Also, (Old): < If a server does not support the requested primary language, responses will continue to be returned in the current language the server is using. > Should proably be something like (New): If a server returns an -ERR response to a LANG command that specifies a primary language, the current language for responses remains in effect. (10) Section 3, first paragraph (may also apply to the first paragraph of Section 2. =20 The statement seems excessively convoluted. Try something like This specification adds a new POP3 Extension [RFC2449] capability response tag and command to specify support for header field information in UTF-8 rather than only ASCII. =20 The capability tag and new command and functionality are described below. (11) Section 3, "Discussion". This doesn't really define "UTF-8 = mode" either. You need an explicit statement telling the reader what = "UTF-8 mode" and "ASCII mode" are. A forward reference might suffice, = but forward references to fundamental definitions are fairly = irritating. In this particular sentence, that could be as simple as saying = "The UTF8 command switches the session from the ASCII-only mode of = RFC 1939 to UTF-8 mode as specified in this document", but that doesn't eliminate the need to define the term as discussed in Note 3. (12) Section 3.1, 2nd paragraph (and also Section 4) I feel like we have discussed this before. The text says "Maildrops can natively store UTF-8 or be limited to ASCII." The reality is that maildrops can natively store anything they like. That can include Unicode in any of the 16 bit or 32 bit forms, assorted national character sets, code pages with 2022 introducers or some other identifying mechanism, and so on. Our requirement is that they be able to accept and produce UTF-8 (including the ASCII subset) when they need to. We just can't say the above or anything else about what they can "natively store" so this whole paragraph must be rewritten in terms of inputs and outputs. Similarly, paragraph 5 should probably start "Normal operation maildrops that natively support non-ASCII characters..."=20 (13) Section 3.2 (Substantive) Dependency on SASLPrep (RFCs 4013 and 5034) - see mailing list discussion. -06 has been modified to contain "or successor" = language in paragraphs 2 and 3 but not in paragraph 4 (which might = introduce confusion rather than help, or might help. =20 This entry is just a placeholder to be sure that things don't = get lost. Note in particular that distinctions about unassigned = code points run head-on into the difference in philosophy between = IDNA2003 (and Stringprep) and IDNA2008. (14) Section 3.2, paragraph 4. Nit: We really don't need two citations for the same spec in the same sentence, do we? So, in When applying SASLprep [RFC4013], servers MUST reject UTF-8 = user names or passwords that contain a Unicode character listed in = Section 2.3 of SASLprep [RFC4013].=20 please drop the second instance of "[RFC4013]". (15) Section 4. Parts of this section seem redundant with the paragraph starting "Normal operation for UTF-8 maildrops..." in Section 3.1. Please see if it is possible to clean one or the other out a bit. See also Note 12 above about "[native] UTF-8 maildrops" -- most of these comments would apply to any other maildrop that stores non-ASCII characters in some native form. (16) Section 7 (Security Considerations), paragraph 1. Substantive: Please consider whether some of the remarks about non-canonical forms, etc., in RFC 5198 apply here and should be mentioned. (17) Section 7, paragraph 3 The second sentence contains a spare comma and space. Old: session, such as , Transport Layer Security (TLS) New: session, such as Transport Layer Security (TLS) (18) Section 7, last paragraph This is true of any such modification and not unique to this specification. I suggest saying that. Given the issue of "native UTF-8 maildrops" and associated authentication databases, perhaps a better statement would be: As with other internationalization upgrades, modifications to server authentication code (in this case, to support non-ASCII strings) needs to be done with care to avoid introducing vulnerabilities (for example, in string parsing or matching). This is particularly important if the native databases or mailstore of the operating system use some character set or encoding other than Unicode in UTF-8. =20 (19) Section 8 Unless you specifically want this to be retained (in which case, please explain that to the WG since it is not being retained in = the other specs and the IMAP one doesn't even have one), please = insert a note to the RFC Editor that explicitly calls for its removal = prior to publication. That can be as simple as=20 [[RFC Editor: please remove this section prior to publication]] if you do want to retain it, the section needs work, e.g., "...based on Joseph's comments" may not be helpful to a reader some years from now. Note also that -06 does not contain a subsection (8.7?) that = discussed changes for that version. Presumably it should just say = something like "updated section 3.2 to provide for SASL successor specs." And, whichever way, you decide about retaining this section, we = might want to make it Appendix B rather than having it in the middle = of the document. It certainly is not normative material. (20) Appendix A, third paragraph I suggest this paragraph would be more helpful if it said The USER capability (Section 3.2) and hence the upgraded USER command and additional support for non-ASCII credentials, are optional because...=20 If that is not the intent, it needs to be clarified in some other way. thanks, john --==========0E08BA8E6BE71F15A7BD==========-- From yaojk@cnnic.cn Tue Jul 17 07:24:12 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5FC21F86EF for ; Tue, 17 Jul 2012 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.066 X-Spam-Level: X-Spam-Status: No, score=-101.066 tagged_above=-999 required=5 tests=[AWL=1.532, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH9jqacSRd2E for ; Tue, 17 Jul 2012 07:24:10 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2547E21F856D for ; Tue, 17 Jul 2012 07:24:04 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 17 Jul 2012 22:24:41 +0800 Message-ID: <001201cd6427$e89937f0$c801a8c0@computer> From: "Jiankang Yao" To: "Joseph Yee" , "John C Klensin" References: <5004488E.4020307@isode.com><1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com><008201cd63b0$4cd27fb0$c801a8c0@computer><88119810B6E1D0E369999538@JcK-HP8200.jck.com> Date: Tue, 17 Jul 2012 22:24:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 17 Jul 2012 14:24:12 -0000 ----- Original Message ----- From: "Joseph Yee" To: "John C Klensin" Cc: "Jiankang Yao" ; "Alexey Melnikov" ; "EAI WG" Sent: Tuesday, July 17, 2012 9:42 PM Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep > Personal thought. > > If we picked (2) with "... or one of its standards-track successors", > then I have some concern whether the following paragraph (the 4th in > section 3.2, about how to apply SASLprep on different arguments) may > trip or confuse readers. > I do not think that it will cause confusion. The fourth paragraph of section said "When applying SASLprep [RFC4013], servers MUST reject UTF-8 user names or passwords that contain a Unicode character listed in Section 2.3 of SASLprep [RFC4013]. " That paragraph is for RFC4013- SASLprep , not for its standards-track successors since the reference to SASLprep is rfc4013 not its standards-track successors . So it will not cause confusion. Before adding the words "one of its standards-track successors", I actually consider the fourth paragraph. My personal judgement is that it is ok to add it without causing the confusion. Jiankang Yao > I may simply worry too much [I hope]. > If we picked (3), are we meant to write another bis when RFC4013 being > updated/obsoleted? > > That say, I prefer (2), and would like to ask others if leaving the > 4th paragraph unchanged ok. > > Joseph > > On Tue, Jul 17, 2012 at 8:35 AM, John C Klensin wrote: >> >> >> --On Tuesday, July 17, 2012 08:08 +0800 Jiankang Yao >> wrote: >> >>>... >>>... >>>>>> (2) If changes are needed, should Section 3.2 be rewritten >>>>>> to explicitly allow conformance with the successors of 4013 >>>>>> as an alternative? I think that would require only a few >>>>>> changes of wording. >>>> >>>>> But that would require pointing to a document with unclear >>>>> date of completion... >>>> >>>> Nope. It would require saying something like "MUST conform to >>>> 4013 or one of its standards-track successors". That doesn't >>>> promise that there will be such successors much less when they >>>> will be done. And it ties the MUST to any version, not the >>>> particular version represented by 4013. I am _not_ suggesting >>>> that is the best thing to do, only that it wouldn't be hard if >>>> we decided to do it. >>>> >>> >>> I think that your suggestion saying something like "MUST >>> conform to >>> 4013 or one of its standards-track successors" is something >>> between choice 2 and 3. >>> Since the time to submission cut off is coming, I have >>> submitted the new version. >>> If the WG has the consensus on it, we can update it or keep it. >> >> Thanks. What do others think? >> >> john >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Tue Jul 17 07:34:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97B421F864B for ; Tue, 17 Jul 2012 07:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XNlUP7dUSaR for ; Tue, 17 Jul 2012 07:34:54 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0007E21F8533 for ; Tue, 17 Jul 2012 07:34:53 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Sr8mu-000CeZ-5b; Tue, 17 Jul 2012 10:30:08 -0400 Date: Tue, 17 Jul 2012 10:35:25 -0400 From: John C Klensin To: Jiankang Yao , Joseph Yee Message-ID: <16ECF5DD09441784FDB7A2C5@JcK-HP8200.jck.com> In-Reply-To: <001201cd6427$e89937f0$c801a8c0@computer> References: <5004488E.4020307@isode.com> <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> <008201cd63b0$4cd27fb0$c801a8c0@computer> <88119810B6E1D0E369999538@JcK-HP8200.jck.com> <001201cd6427$e89937f0$c801a8c0@computer> 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: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 17 Jul 2012 14:34:55 -0000 Jiankang, My apologies. If you considered the fourth paragraph carefully before making the changes, I think the changes are reasonable. My personal preference, although not a strong one, is that we try to future-proof these documents -- and raise the odds as much as possible that an update to SASLPrep will explicitly update this and other documents as needed. I had assumed that you had not considered those issues (similar things did occur with some changes in prior versions) and erroneously assumed that you had not done so here. Again, I apologize for jumping to that conclusion and for any comments I made as a result. I take the point make by others that either the authors of such a SASLprep revision or various people reviewing that spec will spot this. But there are a _lot_ of interconnections. I'd really prefer to avoid having to reopen this spec when a revision to SASLprep occurs -- the difficulty getting reviews and comments while this WG is active predicts that it might be even more difficult if/when revisions are needed after the WG has concluded its work. john --On Tuesday, July 17, 2012 22:24 +0800 Jiankang Yao wrote: >> If we picked (2) with "... or one of its standards-track >> successors", then I have some concern whether the following >> paragraph (the 4th in section 3.2, about how to apply >> SASLprep on different arguments) may trip or confuse readers. >> > > > I do not think that it will cause confusion. > > The fourth paragraph of section said "When applying SASLprep > [RFC4013], servers MUST reject UTF-8 user > names or passwords that contain a Unicode character listed > in Section > 2.3 of SASLprep [RFC4013]. " > > That paragraph is for RFC4013- SASLprep , not for its > standards-track successors since the reference to SASLprep is > rfc4013 not its standards-track successors . > So it will not cause confusion. >... From ned+ima@mrochek.com Tue Jul 17 20:28:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0279E21F8505 for ; Tue, 17 Jul 2012 20:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgZwcZny2QHc for ; Tue, 17 Jul 2012 20:28:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9A821F8504 for ; Tue, 17 Jul 2012 20:27:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHYWM7HK28005POX@mauve.mrochek.com> for ima@ietf.org; Tue, 17 Jul 2012 20:23:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHQN2U9IY80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 17 Jul 2012 20:23:32 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OHYWM5Z3YW0006TF@mauve.mrochek.com> Date: Tue, 17 Jul 2012 20:17:01 -0700 (PDT) In-reply-to: "Your message dated Tue, 17 Jul 2012 08:35:51 -0400" <88119810B6E1D0E369999538@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <5004488E.4020307@isode.com> <1FF35DCEEF4FBDCB987245CD@JcK-HP8200.jck.com> <008201cd63b0$4cd27fb0$c801a8c0@computer> <88119810B6E1D0E369999538@JcK-HP8200.jck.com> To: John C Klensin Cc: EAI WG Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep 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, 18 Jul 2012 03:28:01 -0000 > --On Tuesday, July 17, 2012 08:08 +0800 Jiankang Yao > wrote: > >... > >... > >>>> (2) If changes are needed, should Section 3.2 be rewritten > >>>> to explicitly allow conformance with the successors of 4013 > >>>> as an alternative? I think that would require only a few > >>>> changes of wording. > >> > >>> But that would require pointing to a document with unclear > >>> date of completion... > >> > >> Nope. It would require saying something like "MUST conform to > >> 4013 or one of its standards-track successors". That doesn't > >> promise that there will be such successors much less when they > >> will be done. And it ties the MUST to any version, not the > >> particular version represented by 4013. I am _not_ suggesting > >> that is the best thing to do, only that it wouldn't be hard if > >> we decided to do it. > >> > > > > I think that your suggestion saying something like "MUST > > conform to > > 4013 or one of its standards-track successors" is something > > between choice 2 and 3. > > Since the time to submission cut off is coming, I have > > submitted the new version. > > If the WG has the consensus on it, we can update it or keep it. > Thanks. What do others think? Well, if you want my honest and frank opinion, I think this stuff qualifies as "Mostly Harmless". I view the chances of people implementing Xprep in protocol Y, for pretty much any value of X or Y, as fairly low, and the chances of implementations keeping this sort of thing up to date as about as likely as my winning the lottery. That said, I don't see any downside either. If what we say doesn't matter, it doesn't matter what we say. Ned P.S. I've never purchased a lottery ticket. From duerst@it.aoyama.ac.jp Tue Jul 17 21:50:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3BC11E80AE for ; Tue, 17 Jul 2012 21:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.254 X-Spam-Level: X-Spam-Status: No, score=-100.254 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XzDh88e2yHZ for ; Tue, 17 Jul 2012 21:50:21 -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 032BA21F85D4 for ; Tue, 17 Jul 2012 21:50:17 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6I4oqML002664 for ; Wed, 18 Jul 2012 13:50:52 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2d08_b5fe_26ea7d10_d094_11e1_979b_001d096c5782; Wed, 18 Jul 2012 13:50:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36027) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 18 Jul 2012 13:50:56 +0900 Message-ID: <500640A7.40107@it.aoyama.ac.jp> Date: Wed, 18 Jul 2012 13:50:47 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <94F2925BA3119ED310C5A8AA@JcK-HP8200.jck.com> In-Reply-To: <94F2925BA3119ED310C5A8AA@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Comprehensive WG LC review of draft-ietf-eai-5738bis-06 (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: Wed, 18 Jul 2012 04:50:22 -0000 Very small nit: On 2012/07/17 23:17, John C Klensin wrote: > Hi. Review attached as promised. > (10) Section 7, last paragraph (editorial nit) > > Old: > impossible, at least at the time, > New: > impossible, at least at the present time, I suggest "impossible, at least at the time of writing[/publication] of this specification". Otherwise, the spec reads strange in a few years. Regards, Martin. From klensin@jck.com Wed Jul 18 02:41:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE11621F86DB for ; Wed, 18 Jul 2012 02:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSwgsC5hGA0i for ; Wed, 18 Jul 2012 02:41:00 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 605D621F86B6 for ; Wed, 18 Jul 2012 02:41:00 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SrQg4-000E7P-DH; Wed, 18 Jul 2012 05:36:16 -0400 Date: Wed, 18 Jul 2012 05:41:35 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <8779ADC26D72CC866387B1BE@JcK-HP8200.jck.com> In-Reply-To: <500640A7.40107@it.aoyama.ac.jp> References: <94F2925BA3119ED310C5A8AA@JcK-HP8200.jck.com> <500640A7.40107@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] Comprehensive WG LC review of draft-ietf-eai-5738bis-06 (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: Wed, 18 Jul 2012 09:41:00 -0000 Definitely better. thanks, john --On Wednesday, July 18, 2012 13:50 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: > Very small nit: >=20 > On 2012/07/17 23:17, John C Klensin wrote: >> Hi. Review attached as promised. >=20 > > (10) Section 7, last paragraph (editorial nit) > > > > Old: > > impossible, at least at the time, > > New: > > impossible, at least at the present time, >=20 > I suggest "impossible, at least at the time of > writing[/publication] of this specification". >=20 > Otherwise, the spec reads strange in a few years. >=20 > Regards, Martin. From alexey.melnikov@isode.com Wed Jul 18 03:34:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1466621F861D for ; Wed, 18 Jul 2012 03:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.001 X-Spam-Level: X-Spam-Status: No, score=-103.001 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpxuZA4WorZv for ; Wed, 18 Jul 2012 03:34:09 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8251C21F8619 for ; Wed, 18 Jul 2012 03:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342607735; d=isode.com; s=selector; i=@isode.com; bh=tYFQzazkyw3aJ/wWVqpuasWXWsG97O3dOYv9NPgwbUU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=N0MO7l62lfHKPRyy2pm65VfrXP+eXWnzpP/WwxSRC2cLSRLxt4WnVLFlq0JmhoC6tRGv8x CmwTFr/Mu/huM6EnA7z0bBS21FsT0b/T1FeHAaHFT5zIbVlTCJIAO4E5CmMoliQhM8SS7j H50kn+H2WPTYAMG3CjMDQDxoNBzqdI0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 18 Jul 2012 11:35:35 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50069153.5080006@isode.com> Date: Wed, 18 Jul 2012 11:34:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: John C Klensin References: In-Reply-To: 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] EAI agenda for IETF 84 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, 18 Jul 2012 10:34:10 -0000 On 17/07/2012 13:53, John C Klensin wrote: > Hi. Hi John, > The agendas are now due. > > I believe that our agenda is: > > 1 Intro and agenda bash > > 2 Review of status of mailinglist draft. We expect this draft > to be somewhere in the IETF Last Call/ IESG review process, so, > if we are lucky, this is a non-item. > > 3 Status and any required actions on the four POP-IMAP drafts. > We hope to have IETF LC started on them before the meeting > starts, but something will undoubtedly need to be discussed. > > 4 MAILTO and and other related protocol items PKIX EAI draft (expired), if you want to discuss it > 5 Plans for the WG, including any discussion that is needed > about the "advice" drafts > > 6 AOB > > Any additions or comments? This looks good. From jyee@afilias.info Wed Jul 18 09:01:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E057111E80C2 for ; Wed, 18 Jul 2012 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezBS3-WoihTd for ; Wed, 18 Jul 2012 09:01:38 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id D48D011E80DB for ; Wed, 18 Jul 2012 09:01:37 -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 1SrWhn-0004eY-8B for ima@ietf.org; Wed, 18 Jul 2012 16:02:27 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SrWhn-0005HA-4P for ima@ietf.org; Wed, 18 Jul 2012 16:02:27 +0000 Received: by mail-vb0-f50.google.com with SMTP id l1so1298979vba.9 for ; Wed, 18 Jul 2012 09:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=TBEEiuyLOCIAJ9aLsq4SLIp6ZOi+GSfRb7Z4hMXQcBc=; b=ovkE8wp5ug0hsqmbm0RKgrvBcK/TldGX/adqdfScfUU2t2lzPhtdeGsVvTwaRqnB0j CRKl3OCCylagFT16jYlrt/v9c0LqBME6iYliYDgfvXnyBUSKO8wSvHzvh1G0CTSe4am4 Pi6mHXw8U6R571EJS91Soet5Z/SbEzOfHGHQTdr4E8xOaDbigZQebMcGJjo76lSXmHNm Emh8EFPgfS1hxGVpUXEGewDzF4C4IsIGOQ+Ob3jMA87RlLA3aPV4AkNkG/bvYgw6TjUE gNuCduJjXbq6K0IYbOO8yAfGj7lkdcbhkhCa0A45fcT+0v1rpot0OLpE5thnjDiluYek ulvA== MIME-Version: 1.0 Received: by 10.52.33.47 with SMTP id o15mr991093vdi.73.1342627346942; Wed, 18 Jul 2012 09:02:26 -0700 (PDT) Received: by 10.52.158.34 with HTTP; Wed, 18 Jul 2012 09:02:26 -0700 (PDT) Date: Wed, 18 Jul 2012 12:02:26 -0400 Message-ID: From: Joseph Yee To: "ima@ietf.org WG" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl1LDWmM0pEZMFAvDsUm6RSxGoWvkquz+kNhiag4er3HW/t/YzRchdGRxtTe608ftfA+b1A Subject: [EAI] IETF 84 EAI Agenda 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, 18 Jul 2012 16:01:39 -0000 All, Agenda is available at the link below (also part of the email). For all presenters, please send your presentation to chairs no later than July 25 Wednesday. Best, Joseph http://www.ietf.org/proceedings/84/agenda/agenda-84-eai ---- IETF 84 Vancouver - Email Address Internationalization (EAI) WG Meeting Date: August 2, 2012 Time: 9:00am - 11:30am (Pacific Time Zone) Room: Georgia A Chairs: John Klensin Joseph Yee Agenda: 1 Intro, Agenda bash, Blue sheet, Scribe 2 Review of status of draft-ietf-eai-mailinglistbis-05 [We expect this draft to be somewhere in the IETF Last Call/ IESG review process, so, if we are lucky, this is a non-item.] 3 Status and any required actions on the four POP-IMAP drafts. [We hope to have IETF LC started on them before the meeting starts, but something will undoubtedly need to be discussed.] draft-ietf-eai-rfc5721bis-06 draft-ietf-eai-5738bis-06 draft-ietf-eai-popimap-downgrade-06 draft-ietf-eai-simpledowngrade-05 4 MAILTO and and other related protocol items 5 Presentation: EAI deployment in China & Concerns from software and service providers (YAO, JianKang) 6 Plans for the WG, including any discussion that is needed about the "advice" drafts 7 AOB 8 Adjourn From ned+ima@mrochek.com Sun Jul 22 07:59:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ACB21F8608 for ; Sun, 22 Jul 2012 07:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV-iuD5pMKF1 for ; Sun, 22 Jul 2012 07:59:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5F68521F85D8 for ; Sun, 22 Jul 2012 07:59:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OI55XLXD000060R3@mauve.mrochek.com> for ima@ietf.org; Sun, 22 Jul 2012 07:55:36 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 22 Jul 2012 07:55:33 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OI55XK6XSG0006TF@mauve.mrochek.com> Date: Sun, 22 Jul 2012 07:53:40 -0700 (PDT) In-reply-to: "Your message dated Sat, 14 Jul 2012 15:56:07 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OHMFVC3IY00006TF@mauve.mrochek.com> To: Barry Leiba Cc: ima@ietf.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 22 Jul 2012 14:59:36 -0000 I was going to suggest that we might want to emphasize the possibility of exploiting differences in behavior between different implementations, but on reflection this issue is so generally pervasive that it really makes no sense to call it out in this narrow context. In other words, I think what you have is fine. Ned > >>> Please also review the Security Considerations, and make sure I got that > >>> right. > >> > >> The one I don't see is possible exploits involving different clients handling > >> of something that used to not be allowed. > > > > Good point; I'll craft something for that and post an updated draft. > I have updated the security considerations with this new paragraph in -02: > Because group syntax in the "From" header field has previously not > been allowed, it is possible that some implementations that conform > to RFC 5322 might not be prepared to handle the syntax, and, indeed, > might not even recognize that group syntax is being used. Of those > implementations, some subset might, when presented with "From" group > syntax, behave in a way that is exploitable by an attacker. It is > deemed unlikely that this will be a serious problem in practice: > address field parsing is generally an integral component of > implementations, and address field parsers are required to understand > group syntax. In addition, if any implementations should be > exploitable through this mechanism, it is already possible for > attackers to do it by violating RFC 5322, and other RFC 5322 > violations are commonly used by malefactors. > Here's the current -02 version: > https://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group > To compare the changed text with the original text from RFC 5322, diff > this version against the -00 version: > https://tools.ietf.org/rfcdiff?url1=draft-leiba-5322upd-from-group-00.txt&url2=draft-leiba-5322upd-from-group-02.txt > I believe -02 is ready for me to send to Pete for sponsorship. Will > folks please review this and give your assessment of that? And will > someone please volunteer to be the document shepherd, and to do a > shepherd writeup ( > https://www.ietf.org/iesg/template/individual-doc-writeup.txt ) ? > Barry From barryleiba.mailing.lists@gmail.com Mon Jul 23 06:19:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2233F21F846A for ; Mon, 23 Jul 2012 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.986 X-Spam-Level: X-Spam-Status: No, score=-102.986 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Desu3kldIY0O for ; Mon, 23 Jul 2012 06:19:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21DE321F86C2 for ; Mon, 23 Jul 2012 06:19:46 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8780515lbb.31 for ; Mon, 23 Jul 2012 06:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=bAnEf93p6RyFCX68UsCF/Lz+qmbFV2e9qylHm8V46Ck=; b=o3qkQ6SuiyZ8uRTfNpsIpVUkU7vQ4PhKZEX1u7PbbfPhZrG3lK5rSXtoUheDvPMvz3 it8TmzsnB5ZMo0EIywIUNtYeVgPk/uL5McWeefzyIQ10Ry4+FywG375fWS7IV6BFYeph rvvpXUdG3dIomx4hQxv0ijl138dQKK1xr8+ZWrPAJO5f5AKqy5JfVyfKAjS+MtQ+R3Dg UqNhq3yKfmMwAt/YcobHsWeXW8O1DASSHAFlPstsLU+07naIQSlVHmoiw/g1rlJ3bagN on+Oeqnr24byXONeQZAipCAzl7O0nMhE2TdsJIYK/wSQWV9NXqARy1mtL98RFu/EP9kC OSsw== MIME-Version: 1.0 Received: by 10.112.44.163 with SMTP id f3mr7616725lbm.59.1343049585919; Mon, 23 Jul 2012 06:19:45 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Mon, 23 Jul 2012 06:19:45 -0700 (PDT) In-Reply-To: References: <01OHMFVC3IY00006TF@mauve.mrochek.com> Date: Mon, 23 Jul 2012 09:19:45 -0400 X-Google-Sender-Auth: 8vYOAhuosqymkIFEBBxXXs7iy04 Message-ID: From: Barry Leiba To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 23 Jul 2012 13:19:48 -0000 Updated for -03: > https://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group > > To compare the changed text with the original text from RFC 5322, diff > this version against the -00 version: > https://tools.ietf.org/rfcdiff?url1=draft-leiba-5322upd-from-group-00.txt&url2=draft-leiba-5322upd-from-group-03.txt > > I believe -03 is ready for me to send to Pete for sponsorship. Will > folks please review this and give your assessment of that? And will > someone please volunteer to be the document shepherd, and to do a > shepherd writeup ( > https://www.ietf.org/iesg/template/individual-doc-writeup.txt ) ? Thanks to Ned for his review. Any other reviews? I'd be happiest with at least a couple more. Any volunteers to shepherd it? Barry From johnl@iecc.com Mon Jul 23 11:01:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1FA11E80D7 for ; Mon, 23 Jul 2012 11:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.133 X-Spam-Level: X-Spam-Status: No, score=-111.133 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUZNwKSPLgIm for ; Mon, 23 Jul 2012 11:01:12 -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 DE60D11E80D0 for ; Mon, 23 Jul 2012 11:01:11 -0700 (PDT) Received: (qmail 16413 invoked from network); 23 Jul 2012 18:01:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Jul 2012 18:01:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=500d9166.xn--30v786c.k1207; i=johnl@user.iecc.com; bh=ECbAG6lHR5c7DFqpTO0SC4+Bkyw2IhrRldMHDZxq80A=; b=akeI7WRkZCokNchsAZvPpJjGoomGlfLVmnpZcCys3bRfLtWy+fWIEIwEKt8xGzkyylBDffozy7S08WdD9LY0QOBjXZwRlQPVQtWdCy/UivmxNX6wO6YSO12BPuGTNZrzDUkov3S9Ig69ExpntcUgZtCW2G/Z8BAS8uwBW2ihTW4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=500d9166.xn--30v786c.k1207; olt=johnl@user.iecc.com; bh=ECbAG6lHR5c7DFqpTO0SC4+Bkyw2IhrRldMHDZxq80A=; b=bHnVgMYQaWO5ZfpLwFRUdll07dP5r+CARsV8taQkJK9cciXxLsysgEJBNXxAIqe2Zs82K70Q7CLS33EnwVrIXGn830mjjV9Bj4rYEzR+cGPfo15Ikq2V73iVBeJwC36JLJFbecwOvFuGvcTHptSz/nQnM+lAZFnPowasqFDeyzs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Jul 2012 18:00:48 -0000 Message-ID: <20120723180048.56092.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: barryleiba@computer.org Subject: Re: [EAI] draft-leiba-5322upd-from-group discussion 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, 23 Jul 2012 18:01:13 -0000 >Thanks to Ned for his review. Any other reviews? I'd be happiest >with at least a couple more. Technically it's almost fine. The Note: in section 3.6.2 says "The transmitter information is always present" which is no longer true. if there's no Sender hader and the From header is something like this: From: downgraded from an EAI address :; I'd suggest rewording the note to: Note: The transmitter information is usually present. The absence of the "Sender:" field is sometimes mistakenly taken to mean that the agent responsible for transmission of the message has not been specified. This absence merely means that the transmitter is identical to the author, which is found in the "From:" field. The only case when there is no transmitter information is one where there is no "Sender:" field and the "From:" field contains only groups with no mailboxes. The last part of the security considerations is a bit convoluted. Perhaps rewrite it as: This problem is unlikely to occor in practice: implmentations typically use a single parser for all address fields in a message, so the parsers have to handle group syntax, and in all likelihood they will already handle it in From: headers. Also, since few if any implementations validate header syntax before attempting to parse it, such an attack is already possible by violating RFC 5322 syntax. Other RFC 5322 violations are commonly used by malefactors. > Any volunteers to shepherd it? If you don't already have another suc^W^Wan enthusiastic volunteer, I'll do it. R's, John From klensin@jck.com Mon Jul 23 16:29:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4626D21F8484 for ; Mon, 23 Jul 2012 16:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9mlqM3P6iCU for ; Mon, 23 Jul 2012 16:29:48 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7671A21F8460 for ; Mon, 23 Jul 2012 16:29:48 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1StRyv-0004ok-Ox for ima@ietf.org; Mon, 23 Jul 2012 19:24:05 -0400 Date: Mon, 23 Jul 2012 19:29:34 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Last Call question about encoding of in 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: Mon, 23 Jul 2012 23:29:49 -0000 Hi. This is another "are we sure?" question. I'm happy if the answer is "yes" or "makes no difference", but am obligated to ask. The current text of Section 4.1.7 of popimap-downgrade-06 requires that any that contains and that contains non-ASCII characters be rewritten into a Group with encoded words. In the spirit of the rest of popimap-downgrade, that is certainly the right thing to do if the has non-ASCII characters in the local-part, e.g., non-ASCII@ASCII-FQDN or non-ASCII@non-ASCII-FQDN but, suppose the were ASCII-local-part@non-ASCII-FQDN A clever downgrader could rewrite the non-ASCII-FQDN into A-labels if needed and thereby avoid the Group stuff and preserve a deliverable address. Do we want to explicitly allow that option? My personal guess is that any IMAP or POP server implementation that decides to go to the trouble of this downgrading model will figure out that possibility and ignore us if we do not, but I could be wrong. best, john From klensin@jck.com Mon Jul 23 17:39:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0011E80FF for ; Mon, 23 Jul 2012 17:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyMjjmHp5aTV for ; Mon, 23 Jul 2012 17:39:01 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6711E80F3 for ; Mon, 23 Jul 2012 17:39:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1StT3r-0004ww-Hc for ima@ietf.org; Mon, 23 Jul 2012 20:33:15 -0400 Date: Mon, 23 Jul 2012 20:38:30 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <3F8B8F7E54FCF53AE5C26147@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========18787127A701DDD567D3==========" Subject: [EAI] Comprehensive WG LC review of draft-ietf-eai-simpledowngrade-05 and draft-ietf-eai-popimap-downgrade-06 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, 24 Jul 2012 00:39:05 -0000 --==========18787127A701DDD567D3========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. The other two reviews are attached. Depending on what the authors and WG have to say, I hope to have the Shepherd's reports and requests to initiate IETF LC in Pete's hands before I leave for Vancouver. The Last Call can't actually be started until new documents are posted, but I hope that can happen a week from today. happy reading, john --==========18787127A701DDD567D3========== Content-Type: text/plain; charset=utf-8; name="eai-popimap-downgrade-review.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eai-popimap-downgrade-review.txt"; size=7027 draft-ietf-eai-popimap-downgrade-06.txt In-depth review comments (trivial editorial/typographic comments ignored)... (1) Abstract "... (SMTPUTF8) extension..." should probably be "... (SMTPUTF8) extension to SMTP..." and "treat" in the last sentence might better be "process" or something equivalent. (2) If you are going to ask that the change history (now Section 10) be removed, please make it Appendix B. Doing so will make it easier for all concerned and, in particular, make comparison of the last I-D with the AUTH48 version somewhat easier.=20 (3) Section 1.1, first sentence Old: Traditional (legacy) mail systems, which are defined by [RFC5322],=20 New: Traditional (legacy) mail systems, which are defined by [RFC5322] and other specifications, Certainly RFC 5322 isn't all of it. In particular, POP and IMAP have their own rules. (4) Section 1.1 second paragraph and elsewhere Author discretion, but, especially for POP, I think it would be much more clear if you talked in terms of allowing a client to retrieve a message, or even having a server deliver a message, rather than having the server "send" the message. These are client-pull protocols. Talking about them as if they were client-push (like SMTP) or server-push may be really confusing for some people. (5) Section 1.3 last paragraph The "UTF8 extension" is mentioned here for the first time without a hint to the user about what it is about. Please explicitly reference the POP and IMAP documents (e.g., "the UTF8 extensions as defined for POP3 [...] and IMAP [...] ...") or incorporate some words into Section 2 and put a forward reference here. I have a slight preference for the former, but will leave it up to the author. (6) Section 3 and 4. Pretending to read this with fresh eyes, I got completely confused about whether Downgraded- headers were required for the transformations in Section 4. The answer appears to be "sometimes", which adds to the confusion. The last sentence in Section 3, "3. Remove the original header field." makes things worse because it really isn't part of "New Header Fields Definition". Moreover, if one applies these operations sequentially, there is nothing useful left for Section 4 to operate on. =20 Recommendation (ignore if others think this doesn't help): (6.1) Switch Section 4 and 3 (so that the current 4 comes first). It might be even better to make the sequence 4, 5, 3 (author discretion). (6.2) Change the introduction to the current 4.1 (new 3.1 if the above is applied) to indicate that these are operations applied to ABNF elements within the header fields discussed in 4.2. (6.3) Drop the current 4.1.8 entirely and put a forward reference into 4.1.9 pointing to the old Section 3. Even better, get rid of 4.1.9 as well and strengthen 4.2.2 to describe what is actually done rather than indirecting people all over the document. (6.4) In 4.2.1, first real paragraph, add: Old: downgrading, and downgrading. New: downgrading, and downgrading as described in the corresponding subsections of Section 4.1. Optionally add those words where appropriate to the next paragraph, but I think once will make it clear. (6.5) In 4.2.4 say "Perform ENCAPSULATION Downgrading as specified in Section 3" (that is the old Section 3, new section 4). (6.5) Now, in the former Section 3 (new 4), retitle to "Encapsulation" or even "Encapsulation: A Last Resort" and write a new introduction that reads something like: As a last resort when header fields cannot be converted as discussed in the previous section, the fields are deleted and replaced by specialized new header fields. Those fields are defined to preserve, in encoded form, as much information as possible from the header field values of the incoming message. The syntax of these new header fields is: (7) Current Section 4 paragraph 2 What does "[RFC6532] expands "Received:" header fields;" mean? (8) Section 4.1.6 I think this is probably ok, but, just to be sure: the pseudo-ABNF display-name ENCODED_WORD " :;" Would convert "Big, Silly List": = =D0=B3=D0=BB=D1=83=D0=BF=D1=8B=D0=B9-=D1=81=D0=BF=D0=B8=D1=81=D0=BE= =D0=BA@example.com; into "Big, Silly List" SOME-ENCODED-WORDS :; (I'm too lazy to do the UTF-8 conversion to encoded words right now). Are we sure that is what we want in terms of quoting, etc.? Are we willing to leave that up to the implementation? Or do we want=20 "Big, Silly List SOME-ENCODED-WORDS" :; ?? (9) Section 4.1.7. This is more confusing than it needs to be because the text seems to say "you can't do it, but do it anyway". Suggestion:=20 Old: The elements have no equivalent format for non-ASCII addresses. If the header field has any elements that contain non-ASCII strings in their element, rewrite each element to ASCII-only format.=20 New:=20 The elements have no equivalent format for non-ASCII addresses. If the header field has any elements that contain non-ASCII strings in their element, rewrite each element to ASCII-only group format following the model above.=20 (10) Placeholder: see note to list about encoding of s. (11) Section 4.2.5 (Received headers) The WG has a long and painful discussion about whether IDN = domain names in "Received:" fields should be forced into A-labels or retained as U-labels (in UTF-8). The conclusion was the latter and the base specs say that. So the statement "Other parts should not contain non-ASCII strings." (other than FOR) is incorrect and you need to say something about BY (at least). =20 Recommendation: Possibly for "Received:" header fields only (but see (10) above and the note to the list, define a domain name downgrading operation that forces U-labels into A-labels as specified in IDNA. =20 (12) The title of Section 4.2.9 might be improved by calling it "List- Header Fields and Other Header Fields" or something like that. (13) In Section 5, be sure that whatever is being used to assemble the document corrects the "Section 4" citation as needed. (14) Section 6 (Security Considerations), paragraph 3 The phrasing "...or in newly defined header fields which traditional MUAs do not care." doesn't make sense in English. Perhaps something like "or in newly defined header fields for which traditional MUAs have no special processing procedures." (15) Section 6 paragraph 5 "Information in the new Downgraded-* header fields is not inspected by MUAs,..." Should probably be "Information in the new Downgraded-* header fields is not inspected by traditional MUAs,..." (16) In the Appendix, Figure 1, the Date: field is shown as=20 Date: DATE Shouldn't that be=20 Date: data or, for increased clarity, something that actually looks like a date field? --==========18787127A701DDD567D3========== Content-Type: text/plain; charset=us-ascii; name="eai-simpledowngrade-review.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="eai-simpledowngrade-review.txt"; size=3708 draft-ietf-eai-simpledowngrade-05.txt In-depth review comments... (1) Please remove "EAI:" from the title (see comment on base drafts). Perhaps something like "Simplified POP/IMAP Downgrading for Internationalized Email" or, if you must "Simplified POP/IMAP Downgrading for SMTPUTF8 Messages". Other ideas welcome. (2) Abstract and Overview: I'm ok with this, but note that, technically, a simple MIME message with Content-type text/plain and a non-ASCII charset is an "internationalized message". At a minimum, Section 1 should define an ""internationalized message" as one that uses characters in the envelope (if preserved) or message header fields that are outside the ASCII repertoire and/or that requires SMTPUTF8 processing facilities (the latter with a normative reference to RFC 6530). (3) I don't think the RFC Editor is going to like some of the sentences in the Overview. They are also going to rewrite several uses of "which" into "that", etc. Let's let them deal with those issues and push back on anyone who wants to do that sort of editing in Last Call. (4) Section 2, paragraph 2. While I think the intent of this sentence is clear to participants in the WG and to other email experts, it may be confusing to the casual reader. Consider rewording to, e.g., "The synthetic message is not intended to convey any information to the client software itself." or "The synthetic message is not intended to convey any information to the client software that would require or enable it to apply special handling to the message." You might add a reference to, or version of, the comment about just upgrading here or a comment that, if the client needed to be modified to deal intelligently with this downgrading method, it would make far more sense to just modify it to handle SMTPUTF8 messages. Author's discretion as to whether that would add clarity or just more words. (5) Section 2, paragraph 3: The definition of ".com domain" is problematic. Perhaps better to say "EXAMPLE.com represents a non-ASCII subdomain within the 'com' TLD." or words to that effect. You could also say that it is an IDN and refere to IDNA, but that would introduce the A-label mess and require more fussy language. (6) Section 2.1, last paragraph. It would probably be helpful to explicitly exclude trace fields. Suggested text: "Any addresses present in other header fields, such as Received header fields, are not regarded as addresses by this specification. " (7) Section 5 (Security Considerations) (7.1) YOu might add to your first paragraph that, if the internationalized message is associated with signed header fields, the odds that the signature will be valid are just about zero. (7.2) I don't think it is worth fussing with at this point, but you should be prepared for someone to ask for informative references for Fetchmail and/or "the stock Android client". (8) Section 7 (IANA Considerations) Please remove the RFC Editor note or replace it with one asking that they clear up tense. The current norm is that the IANA Cnosiderations section stays in the published RFC if it contains any action(s) for IANA to take. That is necessary so they can refer back to the RFC as an authority. See the note in popimap-downgrade for how this is usually handled. (9) Sections 8 and 9 (References) The organizational affiliations listed with several of these imply that U Tennessee, U Washington, Bay Networks, etc., are the publisher of the RFCs, which is incorrect. Please either remove those or insert a note asking that the RFC Editor fix them as needed. --==========18787127A701DDD567D3==========-- From duerst@it.aoyama.ac.jp Mon Jul 23 18:15:11 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B96111E80F1 for ; Mon, 23 Jul 2012 18:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=1.513, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1z3d8Ibt2NW for ; Mon, 23 Jul 2012 18:15:10 -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 EE53011E8085 for ; Mon, 23 Jul 2012 18:15:09 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6O1F0bt027276 for ; Tue, 24 Jul 2012 10:15:01 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1b70_68ca_fd901914_d52c_11e1_bed3_001d096c5782; Tue, 24 Jul 2012 10:15:00 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52545) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 24 Jul 2012 10:15:04 +0900 Message-ID: <500DF710.8010504@it.aoyama.ac.jp> Date: Tue, 24 Jul 2012 10:14:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> In-Reply-To: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Last Call question about encoding of in 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, 24 Jul 2012 01:15:11 -0000 I agree with John's conclusion that a clever implementer will ignore the document. I'm not sure what John is implying, document change or no document change. I'd probably favor a document change unless this affects the schedule too much. Regards, Martin. On 2012/07/24 8:29, John C Klensin wrote: > Hi. > > This is another "are we sure?" question. I'm happy if the > answer is "yes" or "makes no difference", but am obligated to > ask. > > The current text of Section 4.1.7 of popimap-downgrade-06 > requires that any that contains and that > contains non-ASCII characters be rewritten into a Group with > encoded words. In the spirit of the rest of popimap-downgrade, > that is certainly the right thing to do if the has > non-ASCII characters in the local-part, e.g., > non-ASCII@ASCII-FQDN > or > non-ASCII@non-ASCII-FQDN > > but, suppose the were > ASCII-local-part@non-ASCII-FQDN > > A clever downgrader could rewrite the non-ASCII-FQDN into > A-labels if needed and thereby avoid the Group stuff and > preserve a deliverable address. > > Do we want to explicitly allow that option? My personal guess > is that any IMAP or POP server implementation that decides to go > to the trouble of this downgrading model will figure out that > possibility and ignore us if we do not, but I could be wrong. > > best, > john > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Mon Jul 23 20:09:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B353121F8518 for ; Mon, 23 Jul 2012 20:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALmNhdtdmZpQ for ; Mon, 23 Jul 2012 20:09:12 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCF921F8517 for ; Mon, 23 Jul 2012 20:09:12 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1StVPE-0005Ch-Jv; Mon, 23 Jul 2012 23:03:28 -0400 Date: Mon, 23 Jul 2012 23:08:57 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <4526529FDD71E2FE4601AFA4@JcK-HP8200.jck.com> In-Reply-To: <500DF710.8010504@it.aoyama.ac.jp> References: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> <500DF710.8010504@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] Last Call question about encoding of in 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, 24 Jul 2012 03:09:13 -0000 --On Tuesday, July 24, 2012 10:14 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: > I agree with John's conclusion that a clever implementer will > ignore the document. >=20 > I'm not sure what John is implying, document change or no > document change. I'd probably favor a document change unless > this affects the schedule too much. As you will see when you go through the review notes, I don't think it makes any schedule difference unless we have to spend a lot of energy getting the wording right. I see no reason why that should happen, but I've been wrong about that sort of thing before. Personally, I always prefer to have things worded so that implementers don't have to ignore us. I believe that it weakens our credibility, however slightly, each time someone does have to ignore a standards-track document. I'd be arguing strongly for a change if the text outright prohibited making the conversion to A-labels. But it doesn't do that. Instead, what it says is, IMO, slightly fuzzy. So, while I'd personally prefer to see it changed, I don't believe that it will have any real effect on quality implementations one way or the other, so I can't feel really strongly on the subject. I think that probably puts the two of us in agreement. best, john > On 2012/07/24 8:29, John C Klensin wrote: >> Hi. >>=20 >> This is another "are we sure?" question. I'm happy if the >> answer is "yes" or "makes no difference", but am obligated to >> ask. >>=20 >> The current text of Section 4.1.7 of popimap-downgrade-06 >> requires that any that contains and = that >> contains non-ASCII characters be rewritten into a Group with >> encoded words. In the spirit of the rest of >> popimap-downgrade, that is certainly the right thing to do if >> the has non-ASCII characters in the local-part, >> e.g., >> non-ASCII@ASCII-FQDN >... From arnt@gulbrandsen.priv.no Tue Jul 24 01:21:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52B21F85E0 for ; Tue, 24 Jul 2012 01:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+5-z+Y12njz for ; Tue, 24 Jul 2012 01:21:16 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA16A21F853F for ; Tue, 24 Jul 2012 01:21:16 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2FB77FA04A3; Tue, 24 Jul 2012 08:21:16 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343118075-24130-24129/11/2; Tue, 24 Jul 2012 08:21:15 +0000 Message-Id: <500E5AFE.4020100@gulbrandsen.priv.no> Date: Tue, 24 Jul 2012 10:21:18 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: ima@ietf.org References: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> <500DF710.8010504@it.aoyama.ac.jp> <4526529FDD71E2FE4601AFA4@JcK-HP8200.jck.com> In-Reply-To: <4526529FDD71E2FE4601AFA4@JcK-HP8200.jck.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] Last Call question about encoding of in 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, 24 Jul 2012 08:21:17 -0000 I don't think popimap-downgrade should regulate that, at least not too closely. Cc: a@B, c@F, E@f Suppose the server can downgrade two of those, the third not. Anyone doing a group reply may then reply to some people, not all. Is that better than nothing or dangerously misleading? I can see sense in both viewpoints and neither is much better than the other, and so I think it's bad to disallow one of them. RFC should not contain rules with which a sensible implementer can/will strongly disagree. I realise that's not always possible. Arnt From duerst@it.aoyama.ac.jp Tue Jul 24 01:30:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D5421F8642 for ; Tue, 24 Jul 2012 01:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=1.495, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aFUQbBlnvhM for ; Tue, 24 Jul 2012 01:30:19 -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 0902021F863C for ; Tue, 24 Jul 2012 01:30:18 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6O8U84x013243 for ; Tue, 24 Jul 2012 17:30:12 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1b6e_f412_c73783c4_d569_11e1_a061_001d096c5782; Tue, 24 Jul 2012 17:30:08 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33289) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 24 Jul 2012 17:30:13 +0900 Message-ID: <500E5D0B.1070905@it.aoyama.ac.jp> Date: Tue, 24 Jul 2012 17:30:03 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <50000609.4020509@it.aoyama.ac.jp> <918CA67046C709D33387ABC3@JcK-HP8200.jck.com> In-Reply-To: <918CA67046C709D33387ABC3@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John R Levine , EAI WG Subject: Re: [EAI] Shepherd report review of mailinglist-02 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, 24 Jul 2012 08:30:20 -0000 Hello John, On 2012/07/14 4:37, John C Klensin wrote: > > > Once we get EAI wound down or suspended, I want to have a > discussion with the ADs (and maybe the IAB, who have expressed > interest in the past) about re-doing RFC 3696 and/or 4084 to > reflect a whole series of things that either weren't handled > well the first time or need updating to reflect i18n (among > other things). I plan to have a look at RFC 3696. Ideally, the issues described therein should be clear from the base specs. If we can do anything in 3987bis or in the mailto draft, let's do that. > I'd be delighted to retire to junior author if > someone else is interested in what I think is the right place to > discuss advice about funky characters in mail and how careful > one needs to be if one is going to transform things from one set > of syntax conventions to another one. There are most possibly other cases where funky characters in mail are relevant, but for the origin of these discussions, I think first and foremost, it would be good to make sure that whatever is needed is in the mailto draft. My personal guess is that we have enough examples in there to make any serious implementer aware of the issues (and superficial implementers won't read the document anyway), but if you see any way to be clearer, please propose additional text or examples. I'll very gladly integrate them into the draft. Regards, Martin. > Consider that both an offer and, for people who like putting > their names on RFCs, a bribe. > > john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Mon Jul 30 10:47:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C003321F8673 for ; Mon, 30 Jul 2012 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPpJIwfJCiYi for ; Mon, 30 Jul 2012 10:47:09 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27421F8661 for ; Mon, 30 Jul 2012 10:47:09 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Svtxx-000A3p-5p; Mon, 30 Jul 2012 13:41:13 -0400 Date: Mon, 30 Jul 2012 13:47:05 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <07C040412CE5237C850BE452@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: Joseph Yee Subject: [EAI] New documents coming? 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, 30 Jul 2012 17:47:09 -0000 Hi. My "comprehensive review" notes were posted to this list on 17 July for 5738bis (IMAP) and 5721bis (POP) 23 July for simpledowngrade and popimap-downgrade Questions: (1) Do authors believe updates are needed? The alternative is that we attach those review comments as outstanding issues to the shepherd's report. I think that would make an unpleasant Last Call, but it is up to the WG. (2) Are we going to see new drafts early enough to be useful to the W meeting on Thursday? I think a "yes" answer for one of these drafts means that it needs to be posted no later than mid-day, Vancouver time on Tuesday? (3) If the answer is "no", can we at least get enough responses from authors to the postings that the WG has, well before Thursday, a pretty good understanding of whether and where we have controversy about the points I identified? (4) And, if the answer is "no" (or silence) even to (3), I expect that we will push the comprehensive reviews onto Thursday's agenda and expect authors and others to be able to respond to questions about what they expect to do. That is a recipe for a very tedious meeting, but may be unavoidable. best, john From yaojk@cnnic.cn Mon Jul 30 10:55:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA0E21F85F9 for ; Mon, 30 Jul 2012 10:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.641 X-Spam-Level: X-Spam-Status: No, score=-100.641 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QxnUt1WLgmh for ; Mon, 30 Jul 2012 10:55:19 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 1751021F8629 for ; Mon, 30 Jul 2012 10:55:18 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 31 Jul 2012 01:55:13 +0800 Message-ID: From: "Jiankang YAO" To: "John C Klensin" , References: <07C040412CE5237C850BE452@JCK-EEE10> Date: Tue, 31 Jul 2012 01:55:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Joseph Yee Subject: Re: [EAI] New documents coming? 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, 30 Jul 2012 17:55:20 -0000 SSAgdGhpbmsgdGhhdCB1cGRhdGVzIGFyZSBuZWNlc3NhcnkuDQoNCkkgd2lsbCB0cnkgdG8gdXBk YXRlIHRoZSByZmM1NzIxYmlzIEFTQVAuDQoNCkppYW5rYW5nIFlhbw0KDQpKaWFua2FuZyBZYW8N Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9obiBDIEtsZW5zaW4iIDxr bGVuc2luQGpjay5jb20+DQpUbzogPGltYUBpZXRmLm9yZz4NCkNjOiAiSm9zZXBoIFllZSIgPGp5 ZWVAY2EuYWZpbGlhcy5pbmZvPg0KU2VudDogVHVlc2RheSwgSnVseSAzMSwgMjAxMiAxOjQ3IEFN DQpTdWJqZWN0OiBbRUFJXSBOZXcgZG9jdW1lbnRzIGNvbWluZz8NCg0KDQo+IEhpLg0KPiANCj4g TXkgImNvbXByZWhlbnNpdmUgcmV2aWV3IiBub3RlcyB3ZXJlIHBvc3RlZCB0byB0aGlzIGxpc3Qg b24NCj4gDQo+ICAxNyBKdWx5IGZvciA1NzM4YmlzIChJTUFQKSBhbmQgNTcyMWJpcyAoUE9QKQ0K PiAgMjMgSnVseSBmb3Igc2ltcGxlZG93bmdyYWRlIGFuZCBwb3BpbWFwLWRvd25ncmFkZQ0KPiAN Cj4gUXVlc3Rpb25zOg0KPiANCj4gKDEpIERvIGF1dGhvcnMgYmVsaWV2ZSB1cGRhdGVzIGFyZSBu ZWVkZWQ/ICBUaGUgYWx0ZXJuYXRpdmUgaXMNCj4gdGhhdCB3ZSBhdHRhY2ggdGhvc2UgcmV2aWV3 IGNvbW1lbnRzIGFzIG91dHN0YW5kaW5nIGlzc3VlcyB0bw0KPiB0aGUgc2hlcGhlcmQncyByZXBv cnQuICBJIHRoaW5rIHRoYXQgd291bGQgbWFrZSBhbiB1bnBsZWFzYW50DQo+IExhc3QgQ2FsbCwg YnV0IGl0IGlzIHVwIHRvIHRoZSBXRy4NCj4gDQo+ICgyKSBBcmUgd2UgZ29pbmcgdG8gc2VlIG5l dyBkcmFmdHMgZWFybHkgZW5vdWdoIHRvIGJlIHVzZWZ1bCB0bw0KPiB0aGUgVyBtZWV0aW5nIG9u IFRodXJzZGF5PyAgSSB0aGluayBhICJ5ZXMiIGFuc3dlciBmb3Igb25lIG9mDQo+IHRoZXNlIGRy YWZ0cyBtZWFucyB0aGF0IGl0IG5lZWRzIHRvIGJlIHBvc3RlZCBubyBsYXRlciB0aGFuDQo+IG1p ZC1kYXksIFZhbmNvdXZlciB0aW1lIG9uIFR1ZXNkYXk/ICANCj4gDQo+ICgzKSBJZiB0aGUgYW5z d2VyIGlzICJubyIsIGNhbiB3ZSBhdCBsZWFzdCBnZXQgZW5vdWdoIHJlc3BvbnNlcw0KPiBmcm9t IGF1dGhvcnMgdG8gdGhlIHBvc3RpbmdzIHRoYXQgdGhlIFdHIGhhcywgd2VsbCBiZWZvcmUNCj4g VGh1cnNkYXksIGEgcHJldHR5IGdvb2QgdW5kZXJzdGFuZGluZyBvZiAgd2hldGhlciBhbmQgd2hl cmUgd2UNCj4gaGF2ZSBjb250cm92ZXJzeSBhYm91dCB0aGUgcG9pbnRzIEkgaWRlbnRpZmllZD8N Cj4gDQo+ICg0KSBBbmQsIGlmIHRoZSBhbnN3ZXIgaXMgIm5vIiAob3Igc2lsZW5jZSkgZXZlbiB0 byAoMyksIEkNCj4gZXhwZWN0IHRoYXQgd2Ugd2lsbCBwdXNoIHRoZSBjb21wcmVoZW5zaXZlIHJl dmlld3Mgb250bw0KPiBUaHVyc2RheSdzIGFnZW5kYSBhbmQgZXhwZWN0IGF1dGhvcnMgYW5kIG90 aGVycyB0byBiZSBhYmxlIHRvDQo+IHJlc3BvbmQgdG8gcXVlc3Rpb25zIGFib3V0IHdoYXQgdGhl eSBleHBlY3QgdG8gZG8uICBUaGF0IGlzIGENCj4gcmVjaXBlIGZvciBhIHZlcnkgdGVkaW91cyBt ZWV0aW5nLCBidXQgbWF5IGJlIHVuYXZvaWRhYmxlLg0KPiANCj4gYmVzdCwNCj4gICBqb2huDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJ TUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ltYQ== From fujiwara@jprs.co.jp Mon Jul 30 11:11:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1829621F84FE for ; Mon, 30 Jul 2012 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnKPzeJ7ip4p for ; Mon, 30 Jul 2012 11:11:18 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81821F84F2 for ; Mon, 30 Jul 2012 11:11:18 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q6UIAtkO004755; Tue, 31 Jul 2012 03:10:55 +0900 X-AuditID: ac120820-b7fe56d000000cec-ff-5016ce2eb985 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 29.A7.03308.E2EC6105; Tue, 31 Jul 2012 03:10:54 +0900 (JST) Date: Tue, 31 Jul 2012 03:10:54 +0900 (JST) Message-Id: <20120731.031054.200370176.fujiwara@jprs.co.jp> To: klensin@jck.com From: fujiwara@jprs.co.jp In-Reply-To: <07C040412CE5237C850BE452@JCK-EEE10> References: <07C040412CE5237C850BE452@JCK-EEE10> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsWyRoiFT1fvnFiAwfbX1hbXl65jt1h+dQmT RfuVBnYHZo8vLVtYPJYs+cnkcXnla+YA5igum5TUnMyy1CJ9uwSujP1rtrAUPGWu2H63gbmB sZm5i5GTQ0LARGLZqatQtpjEhXvr2boYuTiEBE4ySuxfeYYNJMEioC3x7tFBdhCbV8Ba4uuZ BrAGEQFhibalBxlBbGYBNYlp03tZQGxhAQ2J30fegdWzCUhKbP7cClbPKWAocebBYSYQW0jA QGLT5lXsEIvtJE48X8HaxcgBNF9Q4u8OYYiRWhI9Mx6zQ9jyEtvfzmGewMg/C6FqFpKqWUiq FjAyr2KUyU9L0y1OzUspzk03MNQrqczXyyooKtZLBtGbGMHByaGwg3HGKYNDjAIcjEo8vFOv igYIsSaWFVfmHmKU5GBSEuXtPiUWIMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE9+IJoBxvSmJl VWpRPkxKmoNFSZz3+NkdfkIC6YklqdmpqQWpRTBZGQ4OJQlerbNAjYJFqempFWmZOSUIaSYO TpDhPEDDI0BqeIsLEnOLM9Mh8qcYJaXEeStBEgIgiYzSPLjeV4ziQC8I88qDZHmAiQau6xXQ QCaggSEOYANLEhFSUg2MfkGmFVuDjuWreXHO9bB6q2Nz8Mvapy3zN3qK9Wa1eCheqUwXXu2+ cPUOj6RvwuufBLqcC23d4X1c9nB2a8DTriu9brc4Hdz6/fZmH5M+9OSFHU99U1Bzw8Y1M2wS 319ac4lJz721UFm1aa7hQstv5y2/3CgPSrQ/9HaXxGKX9zf9PjbL3S1QYinOSDTUYi4qTgQA Pxn3WfECAAA= Cc: jyee@ca.afilias.info, ima@ietf.org Subject: Re: [EAI] New documents coming? 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, 30 Jul 2012 18:11:19 -0000 > From: John C Klensin > 23 July for simpledowngrade and popimap-downgrade > (1) Do authors believe updates are needed? The alternative is > that we attach those review comments as outstanding issues to > the shepherd's report. I think that would make an unpleasant > Last Call, but it is up to the WG. Yes, I will try to update popimap-downgrade document today and submit it tomorrow. Regards, -- Kazunori Fujiwara, JPRS From jyee@afilias.info Mon Jul 30 11:19:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1792F11E80E5 for ; Mon, 30 Jul 2012 11:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-3.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i26EJ2ROgWer for ; Mon, 30 Jul 2012 11:19:00 -0700 (PDT) Received: from outbound.afilias.info (unknown [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50C11E80A5 for ; Mon, 30 Jul 2012 11:19:00 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1SvuXm-0007C3-44 for ima@ietf.org; Mon, 30 Jul 2012 18:18:14 +0000 Received: from mail-ob0-f171.google.com ([209.85.214.171]) by smtp.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1SvuXm-0004Tf-3f for ima@ietf.org; Mon, 30 Jul 2012 18:18:14 +0000 Received: by obqv19 with SMTP id v19so9592363obq.2 for ; Mon, 30 Jul 2012 11:18:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=yTlfk+ol/8SZ5F2JDdYVkKyw6kL/UgyeBo538UmCe4c=; b=VoLpa+xDIfi5hq354gTfDO+rgX9BkBwk43EYME/nK27QpAdEjoNVxRU6BPQJw6UPNJ 9WYbeg3wFZbdcqo0DZmSMDvQt5kXo+I7NljgiwAaVor3O2UkSJQ4+blcsQtESCoFY60c 6qKmloA5Bb/2lruQ5ZxigSuQ5HGKwFDYuTXz3B8p+SCFGb4xAuiED8q6HBLVwQbtwgoP 1QfEQii9wNIalLqwD3CIro3XEOU1ozL4hLLTzz1Hda9boaoaJit/aYIwTz4vDE2gZQ3o 1zqD7J34FDkMLGcvdVwVwLV1SOx5if5KNjsv/whUmHm6EBa8SvM4fC5SaLl3tf+I5IaJ Jelg== MIME-Version: 1.0 Received: by 10.182.50.68 with SMTP id a4mr18762386obo.59.1343672288609; Mon, 30 Jul 2012 11:18:08 -0700 (PDT) Received: by 10.182.108.4 with HTTP; Mon, 30 Jul 2012 11:18:08 -0700 (PDT) In-Reply-To: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> References: <103098ACFA1F9309539FFA6E@JcK-HP8200.jck.com> Date: Mon, 30 Jul 2012 14:18:08 -0400 Message-ID: From: Joseph Yee To: John C Klensin Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk4c1iPgC3gmK6CQ3WLKTc1wxcPbBn5hfkX1YsMHprCkpe8d+6GNybCa7L1OIlcrKu7Lt1K Cc: ima@ietf.org Subject: Re: [EAI] Last Call question about encoding of in 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: Mon, 30 Jul 2012 18:19:05 -0000 On Mon, Jul 23, 2012 at 7:29 PM, John C Klensin wrote: > Hi. > > This is another "are we sure?" question. I'm happy if the > answer is "yes" or "makes no difference", but am obligated to > ask. > > The current text of Section 4.1.7 of popimap-downgrade-06 > requires that any that contains and that > contains non-ASCII characters be rewritten into a Group with > encoded words. In the spirit of the rest of popimap-downgrade, > that is certainly the right thing to do if the has > non-ASCII characters in the local-part, e.g., > non-ASCII@ASCII-FQDN > or > non-ASCII@non-ASCII-FQDN > > but, suppose the were > ASCII-local-part@non-ASCII-FQDN > > A clever downgrader could rewrite the non-ASCII-FQDN into > A-labels if needed and thereby avoid the Group stuff and > preserve a deliverable address. > > Do we want to explicitly allow that option? My personal guess > is that any IMAP or POP server implementation that decides to go > to the trouble of this downgrading model will figure out that > possibility and ignore us if we do not, but I could be wrong. > > best, > john I see this has no harm, or in the "make no difference" category. The deployment and configuration of the whole mail infrastructure matters more than the address format display in order for non SMTPUTF8 MUA to make use (mostly reply) without fail. Joseph > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From arnt@gulbrandsen.priv.no Mon Jul 30 11:23:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00F21F8617 for ; Mon, 30 Jul 2012 11:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvV79ShzbbTQ for ; Mon, 30 Jul 2012 11:23:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5B221F85DF for ; Mon, 30 Jul 2012 11:23:25 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2E135FA0FF4; Mon, 30 Jul 2012 18:23:24 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343672603-23929-23928/10/7; Mon, 30 Jul 2012 18:23:23 +0000 Message-Id: <5016D121.1070500@gulbrandsen.priv.no> Date: Mon, 30 Jul 2012 20:23:29 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: ima@ietf.org References: <07C040412CE5237C850BE452@JCK-EEE10> In-Reply-To: <07C040412CE5237C850BE452@JCK-EEE10> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] New documents coming? 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, 30 Jul 2012 18:23:26 -0000 On 07/30/2012 07:47 PM, John C Klensin wrote: > (1) Do authors believe updates are needed? Im my case: No. Several of the points warrant wording changes, and I don't accept every suggestion, but that's nothing the WG members need to be bothered with. One of the points is substantive, but noncontroversial. Nothing warrants WG discussion. I'm not sure I can update tomorrow. Unlikely. Sorry, I'm in catchup mode after some illness. Arnt From klensin@jck.com Mon Jul 30 11:32:53 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1614621F86DC for ; Mon, 30 Jul 2012 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcVaB0cFDTkr for ; Mon, 30 Jul 2012 11:32:52 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8789A21F86DB for ; Mon, 30 Jul 2012 11:32:52 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SvugD-000AFg-5i; Mon, 30 Jul 2012 14:26:57 -0400 Date: Mon, 30 Jul 2012 14:32:49 -0400 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: <78F457593C1910CCBD98F3C3@JCK-EEE10> In-Reply-To: <5016D121.1070500@gulbrandsen.priv.no> References: <07C040412CE5237C850BE452@JCK-EEE10> <5016D121.1070500@gulbrandsen.priv.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] New documents coming? 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, 30 Jul 2012 18:32:53 -0000 --On Monday, 30 July, 2012 20:23 +0200 Arnt Gulbrandsen wrote: > On 07/30/2012 07:47 PM, John C Klensin wrote: >> (1) Do authors believe updates are needed? > > Im my case: No. > > Several of the points warrant wording changes, and I don't > accept every suggestion, but that's nothing the WG members > need to be bothered with. One of the points is substantive, > but noncontroversial. > > Nothing warrants WG discussion. > > I'm not sure I can update tomorrow. Unlikely. Sorry, I'm in > catchup mode after some illness. Assuming the WG agrees with you that we don't need a new draft before discussion on Thursday, it would be reasonable for you to wait until the end of this week or beginning of next to generate a new draft. If you had the energy to prepare a short note listing those changes that you consider substantive but uncontroversial, that would be helpful. good luck with the catchup process -- hope you are fully recovered at least. Thanks, john From klensin@jck.com Mon Jul 30 12:42:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831F111E81D4 for ; Mon, 30 Jul 2012 12:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHq2zppArjpo for ; Mon, 30 Jul 2012 12:42:39 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7D11E81D2 for ; Mon, 30 Jul 2012 12:42:38 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Svvlk-000AUK-4z; Mon, 30 Jul 2012 15:36:44 -0400 Date: Mon, 30 Jul 2012 15:42:36 -0400 From: John C Klensin To: fujiwara@jprs.co.jp Message-ID: In-Reply-To: <20120731.031054.200370176.fujiwara@jprs.co.jp> References: <07C040412CE5237C850BE452@JCK-EEE10> <20120731.031054.200370176.fujiwara@jprs.co.jp> 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: jyee@ca.afilias.info, ima@ietf.org Subject: Re: [EAI] New documents coming? 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, 30 Jul 2012 19:42:39 -0000 --On Tuesday, 31 July, 2012 03:10 +0900 fujiwara@jprs.co.jp wrote: > Yes, I will try to update popimap-downgrade document today > and submit it tomorrow. Excellent. Thanks in advance to both you and Jiankang. john From internet-drafts@ietf.org Tue Jul 31 17:25:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E111E80FA; Tue, 31 Jul 2012 17:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8bHm6DrkA+x; Tue, 31 Jul 2012 17:25:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA64921F8813; Tue, 31 Jul 2012 17:25:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120801002521.20724.64906.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 17:25:21 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5721bis-07.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:25:22 -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 Workin= g 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-07.txt Pages : 14 Date : 2012-07-31 Abstract: This specification extends the Post Office Protocol version 3 (POP3) to support UTF-8 encoded international string in user names, passwords, mail addresses, message headers, and protocol-level textual strings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-rfc5721bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-rfc5721bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/