From ima-bounces@ietf.org Mon Nov 3 12:56:28 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C243A6C55; Mon, 3 Nov 2008 12:56:28 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A76A3A6C55 for ; Mon, 3 Nov 2008 12:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kudbeZeo8MWz for ; Mon, 3 Nov 2008 12:56:17 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9C1443A6C48 for ; Mon, 3 Nov 2008 12:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1225745776; x=1257281776; h=mime-version:x-sender:message-id:user-agent:date:to:from: subject:content-type:x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|User-Agent:=20Eudora=206.2.5b1 (Macintosh)|Date:=20Mon,=203=20Nov=202008=2014:55:44=20-0 600|To:=20|From:=20Pete=20Resnick=20|Subject:=20New=20IMAP=20draft |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"510 0,188,5422"=3B=20a=3D"11796086"; bh=JklqZoEiTBzfhVpaNwKo4qmzUyGuM2gzWtV/k+g7OD0=; b=PjqlAErNd2jLGE8I4JAviaMYPtcB3iqAu+sr1tfw6JOkyu0hruPX+Y39 +YleqKJZqOFjQ7CGwBNHI9dSzx73807gi+uYyMtmx6Rz9wcAw3DT6iojw /TaoMor8I2tnsYDQ6m0rw+xIQc76+V5QkztLnRu7j+crMiYrMXI3DG1hO M=; X-IronPort-AV: E=McAfee;i="5100,188,5422"; a="11796086" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2008 12:55:55 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA3KttWl005009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Nov 2008 12:55:55 -0800 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA3KtkfO016773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 3 Nov 2008 12:55:55 -0800 Received: from nasanexhub06.na.qualcomm.com (129.46.134.254) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 3 Nov 2008 12:55:48 -0800 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 3 Nov 2008 12:55:48 -0800 Received: from [75.145.176.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 3 Nov 2008 12:55:47 -0800 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: User-Agent: Eudora 6.2.5b1(Macintosh) Date: Mon, 3 Nov 2008 14:55:44 -0600 To: From: Pete Resnick Subject: [EAI] New IMAP draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Having had no comments on the draft since the last IETF, I simply updated some references and reposted the IMAP draft. I'd be inclined to hear feedback. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 3 13:00:04 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AC83A6C8D; Mon, 3 Nov 2008 13:00:04 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 23A773A6C7B; Mon, 3 Nov 2008 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103210002.23A773A6C7B@core3.amsl.com> Date: Mon, 3 Nov 2008 13:00:02 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart 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) : P. Resnick, C. Newman Filename : draft-ietf-eai-imap-utf8-04.txt Pages : 15 Date : 2008-11-03 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eai-imap-utf8-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03125335.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Nov 7 22:19:44 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7B53A68D4; Fri, 7 Nov 2008 22:19:44 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731B63A68D4 for ; Fri, 7 Nov 2008 22:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcUFqoqvppw7 for ; Fri, 7 Nov 2008 22:19:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 9CDBD3A6811 for ; Fri, 7 Nov 2008 22:19:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E184839E44F for ; Sat, 8 Nov 2008 07:18:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOCiarVn18D5 for ; Sat, 8 Nov 2008 07:18:26 +0100 (CET) Received: from [192.168.16.100] (unknown [84.205.101.12]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F19EC39E24E for ; Sat, 8 Nov 2008 07:18:25 +0100 (CET) Message-ID: <49152F79.6070609@alvestrand.no> Date: Sat, 08 Nov 2008 07:19:37 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: EAI WG Subject: [EAI] Call for agenda items X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org I now discover that I as a chair have not done my duty as of a month ago and posted an agenda and a proposed workplan for this meeting. On the principle of "better late than never", I am calling for anyone who wishes to raise something with the WG to post a note here. The ones I intend to add are: - Status and plans for next round - Downgraded-display - Experience (yao-eai-deployment, dainow-eai-email-clients) - IMAP Possible issues (if someone wants to discuss these, I'll add): - POP (no updated draft, no discussion, no agenda slot) - draft-ellermann-spf-eai - draft-ietf-eai-mailto Anything else people want on the agenda? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 11 13:32:58 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397D93A697A; Tue, 11 Nov 2008 13:32:58 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1903A697A for ; Tue, 11 Nov 2008 13:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgNOGaZAI2W5 for ; Tue, 11 Nov 2008 13:32:55 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id E89A13A677E for ; Tue, 11 Nov 2008 13:32:54 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mABLWo5Z010483 for ; Tue, 11 Nov 2008 13:32:55 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA600601UA5JJ00@fe-sfbay-09.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 11 Nov 2008 13:32:50 -0800 (PST) Received: from [10.0.243.250] ([10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA600EEHUHM97C0@fe-sfbay-09.sun.com>; Tue, 11 Nov 2008 13:32:12 -0800 (PST) Date: Tue, 11 Nov 2008 13:32:10 -0800 From: Chris Newman In-reply-to: <49152F79.6070609@alvestrand.no> To: Harald Alvestrand , EAI WG Message-id: <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline References: <49152F79.6070609@alvestrand.no> Subject: Re: [EAI] Call for agenda items X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org [if you respond to the technical content of this on the list, please change the subject] While I haven't finished my AD review of eai-downgrade, there are a couple issues I'd like the WG to discuss so we have a rough consensus: Topic: New address header format introduced by downgrade: ---- Section 3.1: >downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] > "<" Mailbox ">" [FWS] CRLF >downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] > "<" Mailbox ">" [FWS] CRLF This ABNF introduces yet-another new address format. I think that's a bad idea and a topic the WG should discuss further prior to progressing this. The alternative I would suggest is to use a subset of the same syntax used in other UTF-8 address headers so that the same parser can be reused: downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox FWS "<" Mailbox ">" ">" [CFWS] ---- Topic: Overlong 2047 encoded-words on downgrade. ---- Section 3.3: > 2. Encode the generated header field value according to [RFC2047] > with charset='UTF-8'. This is problematic because 2047 can't be applied to all structured fields. How about the following: 2. Treat the generated header field content as if it were unstructured, and then apply [RFC2047] encoding with charset UTF-8 as necessary so the result is ASCII. > To preserve space characters, the whole > header field value which include space characters SHOULD be > encoded. This second sentence is also problematic. RFC 2822 says lines SHOULD be 78 characters. The new SHOULD is contradictory to that statement, and thus problematic. The simple solution would be to simply delete that sentence. An alternative would be to say something like: While RFC 2047 has a specific algorithm to deal with whitespace in adjacent encoded-words, there are a number of deployed implementations that fail to implement the algorithm correctly. As a result, whitespace behavior is somewhat unpredictable in practice when multiple encoded words are used. While RFC 2822 states that implementations SHOULD limit lines to not more than 78 characters, implementations MAY choose to allow overlong encoded words in order to work around faulty RFC 2047 implementations. Implementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters. I'm not sure it's worth that much text in the specification just to cater to software that mis-implemented RFC 2047. What do others think? ---- Topic: Completeness of downgrade for standards track headers We have several standards track headers that are not included in the lists for downgrading but can be downgraded relatively easily. Of particular note are "Auto-Submitted" since we have a BCP recommending Internet software generate it, and "Content-Language" which is simple since it only requires comment downgrading. Is what we have "good enough" for the working group, should we add BCP/IETF "recommended" headers to the list, and/or should we evaluate all standards-track mail headers in the registry for inclusion? - Chris --On November 8, 2008 7:19:37 +0100 Harald Alvestrand wrote: > I now discover that I as a chair have not done my duty as of a month ago > and posted an agenda and a proposed workplan for this meeting. > > On the principle of "better late than never", I am calling for anyone who > wishes to raise something with the WG to post a note here. > > The ones I intend to add are: > > - Status and plans for next round > - Downgraded-display > - Experience (yao-eai-deployment, dainow-eai-email-clients) > - IMAP > > Possible issues (if someone wants to discuss these, I'll add): > > - POP (no updated draft, no discussion, no agenda slot) > - draft-ellermann-spf-eai > - draft-ietf-eai-mailto > > Anything else people want on the agenda? > > Harald > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 11 14:05:42 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040533A6A7F; Tue, 11 Nov 2008 14:05:42 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC813A6A85 for ; Tue, 11 Nov 2008 14:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxfetmu9Yd8v for ; Tue, 11 Nov 2008 14:05:40 -0800 (PST) Received: from vgateway.libertyrms.info (vgateway.libertyrms.info [207.219.45.62]) by core3.amsl.com (Postfix) with ESMTP id 676E43A6A7F for ; Tue, 11 Nov 2008 14:05:40 -0800 (PST) Received: from dev19.int.libertyrms.com ([10.1.3.136]) by vgateway.libertyrms.info with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L01Mf-0000Rf-8U; Tue, 11 Nov 2008 17:05:37 -0500 Message-ID: <491A0354.8000206@ca.afilias.info> Date: Tue, 11 Nov 2008 17:12:36 -0500 From: Ernie Dainow User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Harald Alvestrand References: <49152F79.6070609@alvestrand.no> In-Reply-To: <49152F79.6070609@alvestrand.no> Cc: EAI WG Subject: Re: [EAI] Call for agenda items - eai-email-clients X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org There were a few comments on this document leading up to the Philadelphia meeting (John K, Randy G) but we were waiting for a bit more discussion before doing an update. I won't be in Minneapolis but would like to see this document advance. There are a number of places marked TBD. It would be good if others can provide some input on these in particular. Ernie Harald Alvestrand wrote: > I now discover that I as a chair have not done my duty as of a month > ago and posted an agenda and a proposed workplan for this meeting. > > On the principle of "better late than never", I am calling for anyone > who wishes to raise something with the WG to post a note here. > > The ones I intend to add are: > > - Status and plans for next round > - Downgraded-display > - Experience (yao-eai-deployment, dainow-eai-email-clients) > - IMAP > > Possible issues (if someone wants to discuss these, I'll add): > > - POP (no updated draft, no discussion, no agenda slot) > - draft-ellermann-spf-eai > - draft-ietf-eai-mailto > > Anything else people want on the agenda? > > Harald > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 12 02:52:09 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE703A691C; Wed, 12 Nov 2008 02:52:09 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883273A691C for ; Wed, 12 Nov 2008 02:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Euhri8YKPeL for ; Wed, 12 Nov 2008 02:52:06 -0800 (PST) Received: from v-smtp-auth-relay-6.gradwell.net (v-smtp-auth-relay-6.gradwell.net [79.135.125.112]) by core3.amsl.com (Postfix) with ESMTP id 6B4163A68A5 for ; Wed, 12 Nov 2008 02:52:03 -0800 (PST) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew$man$ac#uk) by v-smtp-auth-relay-6.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 491ab553.154f.1561 for ima@ietf.org; Wed, 12 Nov 2008 10:52:03 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id mACApxV7009271 for ; Wed, 12 Nov 2008 10:52:01 GMT Date: Wed, 12 Nov 2008 10:51:59 -0000 To: IMA From: "Charles Lindsey" MIME-Version: 1.0 References: <49152F79.6070609@alvestrand.no> <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> Message-ID: In-Reply-To: <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> User-Agent: Opera Mail/9.25 (SunOS) Subject: [EAI] downgrade topics X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Tue, 11 Nov 2008 21:32:10 -0000, Chris Newman = wrote: > [if you respond to the technical content of this on the list, please = > change the subject] Done! > Topic: Overlong 2047 encoded-words on downgrade. > ---- > Section 3.3: > >> 2. Encode the generated header field value according to [RFC2047] >> with charset=3D'UTF-8'. > > This is problematic because 2047 can't be applied to all structured = > fields. How about the following: > > 2. Treat the generated header field content as if it were = > unstructured, > and then apply [RFC2047] encoding with charset UTF-8 as necessary = > so > the result is ASCII. Yes, I think that is better. For sure that was the intent, and I thought = we had managed to get into the syntax in the proper places = to make it clear. Tne only oddity is that the body of the Downgraded = header is not all . The first part of that body is the name = of the header, which is followd by the . So we have a = structured header which contains an within it, and it is = only that portion which I would expect to be 2047-encoded. > >> To preserve space characters, the whole >> header field value which include space characters SHOULD be >> encoded. > > This second sentence is also problematic. RFC 2822 says lines SHOULD be = > 78 characters. The new SHOULD is contradictory to that statement, and = > thus problematic. The simple solution would be to simply delete that = > sentence. An alternative would be to say something like: I think it would be simpler just to add a further sentence of the form: "Note that [RFC2047] requires header field lines containing = s to be folded so as the keep their length to within 76 = characters; if done correctly, this enables the original spacing to be = restored upon decoding." > > Topic: Completeness of downgrade for standards track headers > > We have several standards track headers that are not included in the = > lists for downgrading but can be downgraded relatively easily. Of = > particular note are "Auto-Submitted" since we have a BCP recommending = > Internet software generate it, and "Content-Language" which is simple = > since it only requires comment downgrading. Is what we have "good = > enough" for the working group, should we add BCP/IETF "recommended" = > headers to the list, and/or should we evaluate all standards-track mail = > headers in the registry for inclusion? I think specifications for other headers should be encouraged to define = explicit downgrading extensions to our document for such headers wherever = they feel it beneficial to do so. Having said that, I have no problem if = somone wants to go through the list of registered headers and pick out = candidates that we should deal with at this stage. Note that, where some other document _does_ provide such an extension for = some new header, existing implementations may continue to just use the = Downgraded form alone. I see no problem with that. -- = Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing----= -------------------- Tel:=A0+44=A0161=A0436=A06131=A0 = =A0=A0=A0Web:=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0Ave= ,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0A0= =A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 13 04:06:51 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D6E3A68B4; Thu, 13 Nov 2008 04:06:51 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB8A3A689E for ; Thu, 13 Nov 2008 04:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81pTPZzkXRYW for ; Thu, 13 Nov 2008 04:06:49 -0800 (PST) Received: from send01.jprs.co.jp (send01.jprs.co.jp [202.11.17.113]) by core3.amsl.com (Postfix) with ESMTP id D520A3A6864 for ; Thu, 13 Nov 2008 04:06:48 -0800 (PST) Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id mADC6kmK014313 for ; Thu, 13 Nov 2008 21:06:48 +0900 (JST) Received: (from localhost [172.18.4.44]) by send01.jprs.co.jp (SMSSMTP 4.1.16.48) with SMTP id M2008111321064619804 for ; Thu, 13 Nov 2008 21:06:46 +0900 Date: Thu, 13 Nov 2008 21:06:46 +0900 (JST) Message-Id: <20081113.210646.71105717.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> References: <49152F79.6070609@alvestrand.no> <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: Re: [EAI] downgrade topics X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org > From: Chris Newman > While I haven't finished my AD review of eai-downgrade, there are a couple issues I'd like the WG to discuss so we have a rough consensus: > > Topic: New address header format introduced by downgrade: > ---- > Section 3.1: > > >downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] > > "<" Mailbox ">" [FWS] CRLF > >downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] > > "<" Mailbox ">" [FWS] CRLF > > This ABNF introduces yet-another new address format. I think that's a bad idea and a topic the WG should discuss further prior to progressing this. The alternative I would suggest is to use a subset of the same syntax used in other UTF-8 address headers so that the same parser can be reused: > > downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox > FWS "<" Mailbox ">" ">" [CFWS] This syntax is easy to understand. But it is different from SMTP command. (The original format is also different from SMTP command.) I have one another idea. downgraded-envelope-addr = [FWS] uPath 1*[FWS] "ALT-ADDRESS=" ALT-ADDRESS-value [FWS] Which is better, " ", ">" or " ALT-ADDRESS=ASCII ? > From: "Charles Lindsey" > > > Topic: Overlong 2047 encoded-words on downgrade. > > ---- > > Section 3.3: > > > >> 2. Encode the generated header field value according to [RFC2047] > >> with charset='UTF-8'. > > > > This is problematic because 2047 can't be applied to all structured fields. How about the following: > > > > 2. Treat the generated header field content as if it were unstructured, > > and then apply [RFC2047] encoding with charset UTF-8 as necessary so > > the result is ASCII. > > Yes, I think that is better. For sure that was the intent, and I thought we had managed to get into the syntax in the proper places to make it clear. Tne only oddity is that the body of the Downgraded header is not all . The first part of that body is the name of the header, which is followd by the . So we have a structured header which contains an within it, and it is only that portion which I would expect to be 2047-encoded. Section 3.1 and 3.2 have same issue. (I missed RFC 2047 encoding in section 3.1). > >> To preserve space characters, the whole > >> header field value which include space characters SHOULD be > >> encoded. > > > > > This second sentence is also problematic. RFC 2822 says lines SHOULD be 78 characters. The new SHOULD is contradictory to that statement, and thus problematic. The simple solution would be to simply delete that sentence. An alternative would be to say something like: > > I think it would be simpler just to add a further sentence of the form: > > "Note that [RFC2047] requires header field lines containing s to be folded so as the keep their length to within 76 characters; if done correctly, this enables the original spacing to be restored upon decoding." This is simple and enough. > > Topic: Completeness of downgrade for standards track headers > > > > We have several standards track headers that are not included in the lists for downgrading but can be downgraded relatively easily. Of particular note are "Auto-Submitted" since we have a BCP recommending Internet software generate it, and "Content-Language" which is simple since it only requires comment downgrading. Is what we have "good enough" for the working group, should we add BCP/IETF "recommended" headers to the list, and/or should we evaluate all standards-track mail headers in the registry for inclusion? > > I think specifications for other headers should be encouraged to define explicit downgrading extensions to our document for such headers wherever they feel it beneficial to do so. Having said that, I have no problem if somone wants to go through the list of registered headers and pick out candidates that we should deal with at this stage. > > Note that, where some other document _does_ provide such an extension for some new header, existing implementations may continue to just use the Downgraded form alone. I see no problem with that. I agree. Newly extended or defined header fields which contain UTF-8 non-ASCII characeters require definitions for downgrading. If there are some missing header fields which are allowed to use UTF-8 non-ASCII characters in RFC 5335, please inform me. The "Auto-Submitted" header field may contain UTF-8 characters in CFWS. It is covered in "COMMENT downgrading" in section 5. But it is not listed in Section 5.1. Regards, -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 13 11:54:42 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DFE3A69DE; Thu, 13 Nov 2008 11:54:42 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1293A69DE for ; Thu, 13 Nov 2008 11:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSoerd0rvKuw for ; Thu, 13 Nov 2008 11:54:40 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 4B21D3A69D1 for ; Thu, 13 Nov 2008 11:54:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9E1339E44F for ; Thu, 13 Nov 2008 20:53:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWatdCJazJAb for ; Thu, 13 Nov 2008 20:53:20 +0100 (CET) Received: from [192.168.1.198] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6BFC539E40A for ; Thu, 13 Nov 2008 20:53:20 +0100 (CET) Message-ID: <491C85FD.50403@alvestrand.no> Date: Thu, 13 Nov 2008 20:54:37 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: EAI WG Content-Type: multipart/mixed; boundary="------------020700020008020005000902" Subject: [EAI] Proposed agenda, Minneapolis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------020700020008020005000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is a proposed agenda for Minneapolis (at last). Comments, please! Harald --------------020700020008020005000902 Content-Type: text/plain; name="minneapolis-agenda.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minneapolis-agenda.txt" Email Address Internationalization (EAI) Agenda Meeting: IETF 73, Minneapolis Date and time: Thursday, November 20, 2008, 1520-1720 Place: Rochester room Chairs: Harald Alvestrand , Xiaodong Lee Version: 1.0 ---------------------------------------------------- 1520 - Scribe, blue sheet, agenda bashing 1530 - Status report on documents in processing Documents: draft-ietf-eai-smtpext-13.txt -> RFC 5336 draft-ietf-eai-utf8headers-12.txt -> RFC 5335 draft-ietf-eai-dsn-06.txt -> RFC 5337 draft-ietf-eai-downgrade-09.txt -> AD review 1535 - Addressing issues with -downgrade found in AD review Documents: draft-ietf-eai-downgrade-09.txt 1600 - Downgraded-display Documents: draft-ietf-eai-downgraded-display-00.txt 1615 - Deployment experience Documents: draft-yao-eai-deployment-00.txt draft-dainow-eai-email-clients-01.txt 1630 - IMAP Documents: draft-ietf-eai-imap-utf8-04.txt 1645 - Planning for the progress to standards track - What volunteers do we have for editors? - What changes in the document set do we need? 1710 - Summary of decisions, action items 1720 - End of meeting --------------020700020008020005000902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima --------------020700020008020005000902-- From ima-bounces@ietf.org Thu Nov 13 16:45:37 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE9C3A676A; Thu, 13 Nov 2008 16:45:37 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C791F3A676A for ; Thu, 13 Nov 2008 16:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U+-IsPJ1wVT for ; Thu, 13 Nov 2008 16:45:36 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E2C2B3A66B4 for ; Thu, 13 Nov 2008 16:45:35 -0800 (PST) Received: from [192.168.1.137] ((unknown) [75.146.152.44]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Nov 2008 00:45:35 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <491CCA1C.3010105@isode.com> Date: Fri, 14 Nov 2008 00:45:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Harald Alvestrand References: <491C85FD.50403@alvestrand.no> In-Reply-To: <491C85FD.50403@alvestrand.no> MIME-Version: 1.0 Cc: EAI WG Subject: Re: [EAI] Proposed agenda, Minneapolis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > Attached is a proposed agenda for Minneapolis (at last). > > Comments, please! Works for me. BTW, I will be posting some comments on draft-ietf-eai-imap-utf8-04.txt shortly. _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 14 09:50:56 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1733A69B0; Fri, 14 Nov 2008 09:50:56 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20B23A6985 for ; Fri, 14 Nov 2008 09:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-yIjIwNqGsx for ; Fri, 14 Nov 2008 09:50:54 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EF9123A69B0 for ; Fri, 14 Nov 2008 09:50:53 -0800 (PST) Received: from [192.168.1.137] ((unknown) [75.146.152.44]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Nov 2008 17:50:52 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <491DBA66.5010903@isode.com> Date: Fri, 14 Nov 2008 17:50:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Pete Resnick MIME-Version: 1.0 Cc: ima@ietf.org Subject: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Pete, I've done a detailed review of the latest IMAP draft. You can consider it my WGLC-style review. The document is in a good shape, but I think it would need 1 more revision before going to IETF LC. > 3.1. IMAP UTF-8 Quoted Strings [...] > All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP > servers which 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. [TBD > stringprep for mailbox names? Can we reuse SASLprep?]. Note that I was faced with a similar issue in the ManageSieve protocol, where script names are in UTF-8. After some discussion in the Sieve WG we've decided to go with something like this: A Sieve script name is a sequence of Unicode characters encoded in UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition (Section 2 of [NET-UNICODE]), with the following additional restrictions: o 0000-001F; [CONTROL CHARACTERS] o 007F; DELETE o 0080-009F; [CONTROL CHARACTERS] o 2028; LINE SEPARATOR o 2029; PARAGRAPH SEPARATOR Where: [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008. > IMAP servers MUST NOT accept UTF-8 characters when storing a new > message keyword, unless the mailbox is UTF-8 only, in which case IMAP > servers SHOULD accept UTF-8 in message keywords. [TBD stringprep for > message keywords? Can we reuse SASLprep?] Haven't we decided to leave keywords as ASCII some time ago? I don't have a strong opinion either way. But anyway, this should be similar to the above, with some additional restrictions imposed by IMAP: spaces and some US-ASCII separator characters are not allowed. > 3.2. UTF8 Parameter to SELECT and EXAMINE > > The "UTF8" capability also indicates the server supports the UTF8 > parameter to SELECT and EXAMINE. When a mailbox is selected with the > UTF8 parameter, it alters the behavior of all IMAP commands related > > to message sizes, message headers and MIME body headers so they refer > to the message with UTF-8 headers. If the mailstore is not UTF-8 > header native and the SELECT or EXAMINE command with UTF-8 header > modifier succeeds, then the server MUST return results as if the > mailstore was UTF-8 header native with upconversion requirements as > described in Section 8. The server MAY reject the SELECT or EXAMINE > command with the [NOT-UTF-8] response code, unless the UTF8=ALL or > UTF8=ONLY capability is advertised. > > Servers MAY include mailboxes which can only be selected or examined > if the UTF8 parameter is provided. However, such mailboxes MUST NOT > be included in the output of an unextended LIST, LSUB or equivalent > command. If a client attempts to SELECT or EXAMINE such mailboxes > without the UTF8 parameter, the server MUST reject the command with a > [UTF-8-ONLY] response code. As a result, such mailboxes will not > accessible by IMAP clients written prior to this specification and > are discouraged unless the server advertises UTF8=ONLY or the server > implements IMAP4 LIST Command Extensions [RFC5258]. > > TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. I think I can help with that ;-): utf8-select-param = "UTF8" ;; Conforms to from RFC 4466. > 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions > > When an IMAP server advertises both the "UTF8" capability and the > "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the > LIST extensions described in this section. When an IMAP server > advertises the UTF8=ONLY capability and the LIST-EXTENDED capability, > the server MUST reject these LIST extensions with a BAD response. Ok, I might be confused here, but I think this contradicts description of the UTF8=ONLY capability in section 7: This 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. > 3.4.1. UTF8 and UTF8ONLY LIST Selection Options > > The UTF8 LIST selection option tells the server to include mailboxes > that only support UTF-8 headers in the output of the list command. > The UTF8ONLY LIST selection option tells the server to include all > mailboxes that support UTF-8 headers and to exclude mailboxes that > don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it > is not necessary for the client to request both. Use of either > selection option will also result in UTF-8 mailbox names in the > result as described in Section 3.3. This need to clarify that either selection option implies the UTF8 return option described in section 3.4.2, which in its term means that "\NoUTF8" and "\UTF8Only" mailbox attributes need to be returned when necessary. The only place where this information can be found is in the IANA registration itself. I think most readers would miss that. > 3.4.2. UTF8 LIST Return Option > > If the client supplies the UTF8 LIST return option, then the server > MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as > appropriate. The \NoUTF8 mailbox attribute indicates an attempt to > SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with > a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute > indicates an attempt to SELECT or EXAMINE that mailbox without the > UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note > that computing this information may be expensive on some server > implementations so this return option should not be used unless > necessary. > > The ABNF [RFC5234] for these LIST extensions follows: > > list-select-independent-opt =/ "UTF8" / "UTF8ONLY" This has some implications that you might have not thought about: extending this productions means that these options don't interact with other options, such as RECURSIVEMATCH. While I think the UTF8 option should behave in the same way as the REMOTE option (as it might potentially extend the list of returned mailboxes), I think UTF8ONLY should be treated more like SUBSCRIBED (as it subsets the list of returned mailboxes). So, if you agree, I suggest changing this to: list-select-independent-opt =/ "UTF8" list-select-base-opt =/ "UTF8ONLY" > mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" I think you've copied typo from an old LIST-EXTENDED draft: please change "mbox-list-oflag" to "mbx-list-oflag". [...] > 4. UTF8=APPEND Capability > > If the UTF8=APPEND capability is advertised, then the server accepts > UTF-8 headers in the APPEND command message argument. A client which > sends a message with UTF-8 headers to the server MUST include the > UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: > > append-ext =/ "UTF8" This is probably Ok, but note that RFC 4466 required each label to have a parameter. Whether this is a bug, or there was a reason for that, I currently don't remember. > A server which advertises UTF8=APPEND has to comply with the > requirements of the IMAP base specification and [RFC5322] for message > fetching. Mechanisms for 7-bit downgrading to help comply with the > standards are discussed in Downgrading mechanism for > Internationalized eMail Address (IMA) [I-D.ietf-eai-downgrade]. > > IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY > capability SHOULD reject an APPEND command which includes any 8-bit > in the message headers with a "NO" response. Does this need a new response code? I am not entirely sure. > 8. Up-Conversion Server Requirements > > When an IMAP4 server uses a traditional mailbox format that includes > 7-bit headers and it chooses to permit access to that mailbox with > the UTF8 parameter, it MUST support minimal up-conversion as > described in this section. > > The server MUST support up-conversion of the following address > header-fields in the message header: From, Sender, To, CC, Bcc, > Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and > Reply-To. This up-conversion MUST include address local-parts > encoded according to [TBD], Did you mean utf8-local-part defined in section 4.4 of RFC 5335? > address domains encoded according to IDNA > [RFC3490], and MIME header encoding [RFC2047] of display-names and > any [RFC5322] comments. _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 14 10:31:49 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1797B3A6813; Fri, 14 Nov 2008 10:31:49 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6883A67FB for ; Fri, 14 Nov 2008 10:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2nFk1BDwPAe for ; Fri, 14 Nov 2008 10:31:47 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8AE3B3A6813 for ; Fri, 14 Nov 2008 10:31:46 -0800 (PST) Received: from [172.16.2.132] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Nov 2008 18:31:45 +0000 Message-ID: <491DC3F9.50607@isode.com> Date: Fri, 14 Nov 2008 18:31:21 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Newman References: <49152F79.6070609@alvestrand.no> <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> In-Reply-To: <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> MIME-Version: 1.0 Cc: EAI WG Subject: [EAI] AD review of eai-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Chris Newman wrote: > Topic: New address header format introduced by downgrade: > ---- > Section 3.1: > >> downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] >> "<" Mailbox ">" [FWS] CRLF > If uPath is expanded, this becomes: downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" "<" [ A-d-l ":" ] uMailbox ">" ">" 1*[FWS] "<" Mailbox ">" [FWS] CRLF >> downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] >> "<" Mailbox ">" [FWS] CRLF > > This ABNF introduces yet-another new address format. I think that's a > bad idea and a topic the WG should discuss further prior to > progressing this. The alternative I would suggest is to use a subset > of the same syntax used in other UTF-8 address headers so that the > same parser can be reused: > > downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox > FWS "<" Mailbox ">" ">" [CFWS] Right, so this is basically the first part of from RFC 5335: angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / obs-angle-addr I like that a lot. _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 14 11:21:01 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D04B3A67F0; Fri, 14 Nov 2008 11:21:01 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3ABA3A67F0 for ; Fri, 14 Nov 2008 11:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG3sdzQdzqfy for ; Fri, 14 Nov 2008 11:20:59 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id ABC173A635F for ; Fri, 14 Nov 2008 11:20:59 -0800 (PST) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L14Dw-0006Oj-S9; Fri, 14 Nov 2008 14:20:57 -0500 Date: Fri, 14 Nov 2008 14:20:55 -0500 From: John C Klensin To: Alexey Melnikov , Pete Resnick Message-ID: <955BC9896605E660003FD7BF@p3.int.jck.com> In-Reply-To: <491DBA66.5010903@isode.com> References: <491DBA66.5010903@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Friday, 14 November, 2008 17:50 +0000 Alexey Melnikov wrote: > Pete, > I've done a detailed review of the latest IMAP draft. You can > consider it my WGLC-style review. > The document is in a good shape, but I think it would need 1 > more revision before going to IETF LC. > >> 3.1. IMAP UTF-8 Quoted Strings >... > Note that I was faced with a similar issue in the ManageSieve > protocol, where script names are in UTF-8. After some > discussion in the Sieve WG we've decided to go with something > like this: > > A Sieve script name is a sequence of Unicode characters > encoded in > UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode > Definition > (Section 2 of [NET-UNICODE]), with the following additional > restrictions: It would be better if "restrictions" were supplemented with some words that make it painfully clear that these characters are not permitted. I know that is what you mean, but it is possible to misread this and get confused about it. > o 0000-001F; [CONTROL CHARACTERS] > > o 007F; DELETE > > o 0080-009F; [CONTROL CHARACTERS] > > o 2028; LINE SEPARATOR > > o 2029; PARAGRAPH SEPARATOR > > Where: > > [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format > for Network Interchange", RFC 5198, March 2008. >... >> IMAP servers MUST NOT accept UTF-8 characters when storing >> a new message keyword, unless the mailbox is UTF-8 only, >> in which case IMAP servers SHOULD accept UTF-8 in message >> keywords. [TBD stringprep for message keywords? Can we >> reuse SASLprep?] > > Haven't we decided to leave keywords as ASCII some time ago? We have indeed, at least for header field names. I believe that the logic extended to these cases. I do have a strong opinion that, if non-ASCII keywords are accepted, you are going to need to address comparison models for the keywords, including normalization and case-folding issues. We sort of know how to do that, but I can't recommend a tour of that rat hole. john _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Nov 17 05:13:09 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FFC3A6403; Mon, 17 Nov 2008 05:13:09 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8855F3A6403 for ; Mon, 17 Nov 2008 05:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dG9x49stOOB for ; Mon, 17 Nov 2008 05:13:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 557043A63D3 for ; Mon, 17 Nov 2008 05:13:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9394139E349 for ; Mon, 17 Nov 2008 14:11:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9PUVHFPfDF4 for ; Mon, 17 Nov 2008 14:11:40 +0100 (CET) Received: from [130.129.79.154] (unknown [130.129.79.154]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 34A8439E2F1 for ; Mon, 17 Nov 2008 14:11:39 +0100 (CET) Message-ID: <49216DDB.3030707@alvestrand.no> Date: Mon, 17 Nov 2008 14:12:59 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: EAI WG Content-Type: multipart/mixed; boundary="------------050204070808000301040700" Subject: [EAI] [Fwd: AD review of draft-ietf-eai-downgrade-09.txt] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------050204070808000301040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarded with permission. This is obviously a major item to discuss on Thursday; we should aim to go through at least all the points marked with "**" in the meeting. Harald --------------050204070808000301040700 Content-Type: message/rfc822; name="AD review of draft-ietf-eai-downgrade-09.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="AD review of draft-ietf-eai-downgrade-09.txt.eml" Return-Path: Received: from murder ([unix socket]) by eikenes (Cyrus v2.2.13-Debian-2.2.13-13ubuntu3) with LMTPA; Sat, 15 Nov 2008 05:35:20 +0100 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 176B539E257; Sat, 15 Nov 2008 05:35:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtvQtB5oFt1F; Sat, 15 Nov 2008 05:35:17 +0100 (CET) Received: from eikenes.alvestrand.no (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9435539E539; Sat, 15 Nov 2008 05:35:17 +0100 (CET) X-Original-To: eai-dt@alvestrand.no Delivered-To: eai-dt@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56C4C39E539 for ; Sat, 15 Nov 2008 05:35:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX0wZyjyFCOO for ; Sat, 15 Nov 2008 05:35:14 +0100 (CET) X-Greylist: from auto-whitelisted by SQLgrey-1.6.8 Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 748B239E538 for ; Sat, 15 Nov 2008 05:35:14 +0100 (CET) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAF4aX4i005938 for ; Fri, 14 Nov 2008 20:36:33 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAC00501XYV7900@fe-sfbay-09.sun.com> (original mail from Chris.Newman@Sun.COM) for eai-dt@alvestrand.no; Fri, 14 Nov 2008 20:36:33 -0800 (PST) Received: from [172.28.172.84] ([12.104.246.2]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAC003OPY4I5X90@fe-sfbay-09.sun.com> for eai-dt@alvestrand.no; Fri, 14 Nov 2008 20:36:33 -0800 (PST) Date: Fri, 14 Nov 2008 15:10:21 -0800 From: Chris Newman Subject: AD review of draft-ietf-eai-downgrade-09.txt To: eai-dt@alvestrand.no Message-id: <40EDFF6161046D554131601E@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline X-BeenThere: eai-dt@alvestrand.no X-Mailman-Version: 2.1.9 Precedence: list List-Id: EAI WG Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: eai-dt-bounces@alvestrand.no Errors-To: eai-dt-bounces@alvestrand.no Here's my AD review of draft-ietf-eai-downgrade-09.txt. My recommendation is to do a revision prior to last call resolving at least the "**" issues and any "$" issues you choose to resolve. However, I will follow the wishes of the document shepherd on the matter of when to start IETF last call. Permission is granted to share all or part of this review with others as needed. ----- ** - I recommend resolving this before IETF last call * - I recommend resolving this before IESG review $ - If you choose to do this, I recommend doing it before IETF last call others - Treat as equivalent to any other last call comment; it's acceptable to not address these if they're felt to be controversial or disruptive. Section 3.1: >downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] > "<" Mailbox ">" [FWS] CRLF >downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] > "<" Mailbox ">" [FWS] CRLF ** This ABNF introduces yet-another new address format. I think that's a bad idea and a topic the WG should discuss further prior to progressing this. The alternative I would suggest is to use a subset of the same syntax used in other UTF-8 address headers so that the same parser can be reused: downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox FWS "<" Mailbox ">" ">" [CFWS] (note also that 1*[FWS] is incorrect usage) ** Another problem here is that the ABNF confuses the syntax prior to 2047 and subsequent to 2047 encoding. So the ABNF for the two headers is: downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF The unstructured content is downgraded-envelope-addr treated as if it were unstructured with 2047 encoding (and charset UTF-8) as needed. Section 3.2: > fields =/ known-downgraded-headers ":" unstructued CRLF unstructued => unstructured > [RFC2047] with charset='UTF-8'. The header field syntax is specified This looks sorta like a MIME parameter, but isn't because it's using single quotes instead of double quotes so I'm not quite sure what this means. How about just saying "with charset UTF-8." so it's less confusing. > 2. Encode the generated header according to [RFC2047] with > charset='UTF-8'. ** This is problematic because 2047 can't be applied to all structured fields. How about the following: 2. Treat the generated header field content as if it were unstructured, and then apply [RFC2047] encoding with charset UTF-8 as necessary so the result is ASCII. Section 3.3: I suggest this section specifically prohibit application to a "Received" header. It's implied but not stated anywhere. > 2. Encode the generated header field value according to [RFC2047] > with charset='UTF-8'. To preserve space characters, the whole > header field value which include space characters SHOULD be > encoded. For the first sentence, see comment above. ** The second sentence is also problematic. RFC 2822 says lines SHOULD be 78 characters. The new SHOULD is contradictory to that statement, and thus problematic. The simple solution would be to simply delete that sentence. An alternative would be to say something like: While RFC 2047 has a specific algorithm to deal with whitespace in adjacent encoded-words, there are a number of deployed implementations that fail to implement the algorithm correctly. As a result, whitespace behavior is somewhat unpredictable in practice when multiple encoded words are used. While RFC 2822 states that implementations SHOULD limit lines to not more than 78 characters, implementations MAY choose to allow overlong encoded words in order to work around faulty RFC 2047 implementations. Implementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters. Section 4.2: > The "RCPT TO" command can have an ORCPT parameter if the DSN > extension [RFC3461] is supported. If the ORCPT parameter contains an > "utf-8" address and the address contains non-ASCII characters, the > ORCPT parameter MUST be converted to utf-8-addr-xtext form or utf-8- > addr-unitext form which are described in [RFC5337]. ** The transformation that needs to occur on the content of ORCPT is to 1. remove xtext encoding, 2. convert the result of step one to utf-8-addr-unitext form where all non-ASCII characters are represented as EmbeddedUnicodeChar, 3. re-apply xtext encoding to the result of step 2. Section 5: > RECEIVED downgrading: If the header field name is "Received:" and > the FOR clause contains a non-ASCII addresses, remove the FOR > clause from the header field. The other part does not contain > non-ASCII values. Actually, comments may contain non-ASCII characters (section 5.1 is correct, but this section is not correct on that issue). > UNSTRUCTURED downgrading: If the header field has an > field which contains non-ASCII characters, encode the field > according to [RFC2047] with charset='UTF-8'. To preserve space > characters, the whole header field value which include space > characters SHOULD be encoded. See comment for section 3.3 above. > DISPLAY-NAME downgrading: If the header field has any > elements and they have elements which contain non- > ASCII characters, encode the elements according to > [RFC2047] with charset='UTF-8'. This shouldn't be restricted to as can appear in the structure as well. Also it would be helpful to note that this is the same algorithm as WORD downgrading. Section 5.1: > o Address header fields which contain s $ Consider adding: Disposition-Notification-To [RFC 3798] because it's standards track. > o Downgrading Non-ASCII in comments $ As this is a simple transformation, I believe it makes sense to make this list as complete as possible at least with standards track headers. Two that come to mind are: Content-Transfer-Encoding [MIME] Content-Language [RFC 3282] both here and in the MIME headers section. Also for just here: Accept-Language [RFC 3282] > o Trace header fields The term "trace header" adds confusion here, as you've already discussed trace header fields (Resent-*, Return-Path) in previous groups. I suggest just calling this "Received header field". > o MIME Content header fields >... > Perform MIME-VALUE downgrading. Also need to perform COMMENT downgrading. $ Please add "Auto-Submitted" [RFC 3834] to this list. Since we have BCP recommending its use, I think we should treat it as first-class. > o Other header fields > > All other header fields which contains non-ASCII characters are > user-defined, missing from this draft or future defined header > fields. Perform ENCAPSULATION downgrading as a last resort. A suggestion to make this a bit clearer and firmer: If the software understands the header's structure and a downgrading algorithm other than ENCAPSULATION is applicable, that software SHOULD use that algorithm; ENCAPSULATION downgrading is used as a last resort. $ One other header of note: The Original-Recipient header [RFC 3798] is downgraded as described in section 4.2 (the same way the ORCPT parameter is downgraded). Section 6: > Content-Type: > Content-Disposition: > Perform MIME-VALUE downgrading. also COMMENT downgrading. Section 7: The standard pattern for security considerations is to state a threat that is related to or a consequence of the protocol and state a mitigation for that threat (or state why not mitigating the threat is acceptable for this case). > o A Downgraded message's header fields contain ASCII characters > only. But they still contain MIME encapsulated header fields > which contains non-ASCII UTF-8 characters. * This doesn't state a threat. The simple way to fix that is to say "thus it inherits the security considerations of MIME encoded headers [RFC 2047] and UTF-8 [STD63]. > o Rewriting headers increases the opportunities for undetected > spoofing. * This needs a statement about why it's acceptable or how to mitigate it. > o Addresses that do not appear in the message headers may appear in * This is missing the mitigation, which is to not generate a Downgrade-Rcpt-To header. > o The techniques described here invalidates methods that depend on * The two obvious mitigations are to stick to 7-bit when using these techniques (as most/all of them presently require), or make sure you have UTF8SMTP end-to-end when needed. > o Many gateways and servers on the Internet will discard headers ... Such gateways violate RFC 2979 and can be upgraded to correct the problem. >8.1. Trivial downgrading It's not clear to me if this is a normative part of the specification or not. >8.2. 7bit transport consideration > ... If the > body contains multiple MIME parts, this conversion must be performed > for each MIME part according to [RFC2045]. Actually, 8->7 MIME downgrading was never specified and the reference to 2045 here is simply misleading. The constraints on such downgrading are stated in RFC 1652. > Furthermore, IANA is requested to reserve all the field names that > start with "Downgraded-" for unknown header fields downgrading > described in Section 3.3, in accordance with the procedures set out > in [RFC3864]. ** RFC 3864 includes no such procedure. To do this, you need to "Update" RFC 3864 so that it supports reserved prefixes. Reserving a prefix requires a new IANA registration procedure added to the existing registry (likely IESG review). The SASL registry (RFC 5222) followed a similar pattern where the initial registry rules were modified to support reserved prefixes. For this case, when someone attempts to register a "Downgraded-*" header in the future, you need to specify the rules necessary to accept or reject such registration attempts as otherwise the rules in RFC 3864 apply. - Chris _______________________________________________ EAI-DT mailing list EAI-DT@alvestrand.no http://www.alvestrand.no/mailman/listinfo/eai-dt --------------050204070808000301040700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima --------------050204070808000301040700-- From ima-bounces@ietf.org Mon Nov 17 11:50:08 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315B93A6A4E; Mon, 17 Nov 2008 11:50:08 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EFCD3A6A49 for ; Mon, 17 Nov 2008 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K563AKPqMq3J for ; Mon, 17 Nov 2008 11:50:06 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 654383A6A4E for ; Mon, 17 Nov 2008 11:49:54 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAHJni13009188 for ; Mon, 17 Nov 2008 11:49:54 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAH00L01TDDWO00@fe-sfbay-10.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 17 Nov 2008 11:49:44 -0800 (PST) Received: from [172.28.172.84] ([130.129.31.220]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAH00DMYTQUW590@fe-sfbay-10.sun.com>; Mon, 17 Nov 2008 11:49:44 -0800 (PST) Date: Mon, 17 Nov 2008 13:49:42 -0600 From: Chris Newman In-reply-to: <20081113.210646.71105717.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp, ima@ietf.org Message-id: <47A03DF03C405B3AECD5760D@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline References: <49152F79.6070609@alvestrand.no> <1D3C1300AF64B5C448D8D375@446E7922C82D299DB29D899F> <20081113.210646.71105717.fujiwara@jprs.co.jp> Subject: Re: [EAI] downgrade topics X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On November 13, 2008 21:06:46 +0900 fujiwara@jprs.co.jp wrote: >> From: Chris Newman >> While I haven't finished my AD review of eai-downgrade, there are a >> couple issues I'd like the WG to discuss so we have a rough consensus: >> >> Topic: New address header format introduced by downgrade: >> ---- >> Section 3.1: >> >> > downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" >> > 1*[FWS] "<" Mailbox ">" [FWS] CRLF >> > downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] >> > "<" Mailbox ">" [FWS] CRLF >> >> This ABNF introduces yet-another new address format. I think that's a >> bad idea and a topic the WG should discuss further prior to progressing >> this. The alternative I would suggest is to use a subset of the same >> syntax used in other UTF-8 address headers so that the same parser can >> be reused: >> >> downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox >> FWS "<" Mailbox ">" ">" [CFWS] > > This syntax is easy to understand. But it is different from SMTP command. > (The original format is also different from SMTP command.) > I have one another idea. > downgraded-envelope-addr = [FWS] uPath 1*[FWS] "ALT-ADDRESS=" > ALT-ADDRESS-value [FWS] > > Which is better, " ", ">" or > " ALT-ADDRESS=ASCII ? I have a slight preference to keep the SMTP parser and the Message Format parsers separate. Thus I prefer a syntax that reuses the Message Format syntax for EAI downgrade headers rather than the SMTP syntax. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 09:55:08 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CFB3A68CD; Thu, 20 Nov 2008 09:55:08 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986FF3A68CD for ; Thu, 20 Nov 2008 09:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Haf7cx0ql5yB for ; Thu, 20 Nov 2008 09:55:05 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2D9423A67D2 for ; Thu, 20 Nov 2008 09:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1227203704; x=1258739704; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<491DBA66.50109 03@isode.com>|References:=20<491DBA66.5010903@isode.com> |User-Agent:=20Eudora=206.2.5b1(Macintosh)|Date:=20Thu, =2020=20Nov=202008=2011:54:59=20-0600|To:=20Alexey=20Meln ikov=20|From:=20Pete=20Resnick =20|Subject:=20Re:=20[EAI]=20Comme nts=20on=20draft-ietf-eai-imap-utf8-04.txt|CC:=20|Content-Type:=20text/plain=3B=20charset=3D"us-asci i"=3B=20format=3Dflowed|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5100,188,5439"=3B=20a=3D"13310693"; bh=DFfoDn9lYMASGDp2Qi6Z+APYoJD00SHDh/+VxzE0448=; b=gLWE/4c6/DQ5qwp/NAh/YFTS20GPu1LeJdRg//+6AweBnD4d4HBn6kk6 UGcXVM54wt/pDKeYjD7UQ6xnIrHMqvQ4YEyBQEKIuyxC5NAMAN4pkiGiE d6+7olPkFYOTpW/94wTJ9mDk6Uo/UCu8fXawPhPP+KJNto1NF4sfJSStZ c=; X-IronPort-AV: E=McAfee;i="5100,188,5439"; a="13310693" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 09:55:04 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKHt3Nj008110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 09:55:03 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKHt3PN012897 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Nov 2008 09:55:03 -0800 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 09:55:03 -0800 Received: from [75.145.176.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 09:55:02 -0800 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <491DBA66.5010903@isode.com> References: <491DBA66.5010903@isode.com> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Thu, 20 Nov 2008 11:54:59 -0600 To: Alexey Melnikov From: Pete Resnick Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On 11/14/08 at 5:50 PM +0000, Alexey Melnikov wrote: >>[TBD stringprep for mailbox names? Can we reuse SASLprep?]. > >Note that I was faced with a similar issue in the ManageSieve >protocol, where script names are in UTF-8. After some discussion in >the Sieve WG we've decided to go with something like this: > > A Sieve script name is a sequence of Unicode characters encoded in > UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition > (Section 2 of [NET-UNICODE]), with the following additional > restrictions: > > o 0000-001F; [CONTROL CHARACTERS] > > o 007F; DELETE > > o 0080-009F; [CONTROL CHARACTERS] > > o 2028; LINE SEPARATOR > > o 2029; PARAGRAPH SEPARATOR > >Where: > >[NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for Network >Interchange", RFC 5198, March 2008. Works for me. >> ...unless the mailbox is UTF-8 only, in which case IMAP >> servers SHOULD accept UTF-8 in message keywords. [TBD stringprep for >> message keywords? Can we reuse SASLprep?] > >Haven't we decided to leave keywords as ASCII some time ago? I don't >have a strong opinion either way. Same here. I'll check with Chris as to why he put this in the original version. >> TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. > >I think I can help with that ;-): > > utf8-select-param = "UTF8" > ;; Conforms to from RFC 4466. OK. >>3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions >> >> When an IMAP server advertises both the "UTF8" capability and the >> "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the >> LIST extensions described in this section. When an IMAP server >> advertises the UTF8=ONLY capability and the LIST-EXTENDED capability, >> the server MUST reject these LIST extensions with a BAD response. > >Ok, I might be confused here, but I think this contradicts >description of the UTF8=ONLY capability in section 7: > > This 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. I think the point here is that if you have UTF8=ONLY, then it is pointless to use the UTF8 or UTF8ONLY param to LIST, since all of the mailboxes only support UTF-8 headers. But I guess the param will do no harm either. Again, I'll ask Chris. >>3.4.1. UTF8 and UTF8ONLY LIST Selection Options >> >> The UTF8 LIST selection option tells the server to include mailboxes >> that only support UTF-8 headers in the output of the list command. >> The UTF8ONLY LIST selection option tells the server to include all >> mailboxes that support UTF-8 headers and to exclude mailboxes that >> don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it >> is not necessary for the client to request both. Use of either >> selection option will also result in UTF-8 mailbox names in the >> result as described in Section 3.3. > >This need to clarify that either selection option implies the UTF8 >return option described in section 3.4.2, which in its term means >that "\NoUTF8" and "\UTF8Only" mailbox attributes need to be >returned when necessary. The only place where this information can >be found is in the IANA registration itself. I think most readers >would miss that. I'll repeat it here. >>3.4.2. UTF8 LIST Return Option >> >> If the client supplies the UTF8 LIST return option, then the server >> MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as >> appropriate. The \NoUTF8 mailbox attribute indicates an attempt to >> SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with >> a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute >> indicates an attempt to SELECT or EXAMINE that mailbox without the >> UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note >> that computing this information may be expensive on some server >> implementations so this return option should not be used unless >> necessary. >> >> The ABNF [RFC5234] for these LIST extensions follows: >> >> list-select-independent-opt =/ "UTF8" / "UTF8ONLY" > >So, if you agree, I suggest changing this to: > > list-select-independent-opt =/ "UTF8" > list-select-base-opt =/ "UTF8ONLY" No problem. >> mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" > >I think you've copied typo from an old LIST-EXTENDED draft: please >change "mbox-list-oflag" to "mbx-list-oflag". >[...] Done. >>4. UTF8=APPEND Capability >> >> If the UTF8=APPEND capability is advertised, then the server accepts >> UTF-8 headers in the APPEND command message argument. A client which >> sends a message with UTF-8 headers to the server MUST include the >> UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: >> >> append-ext =/ "UTF8" > >This is probably Ok, but note that RFC 4466 required each label to >have a parameter. Whether this is a bug, or there was a reason for >that, I currently don't remember. Crap. That's going to give parsers serious problems. Let's discuss offline. >> IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY >> capability SHOULD reject an APPEND command which includes any 8-bit >> in the message headers with a "NO" response. > >Does this need a new response code? I am not entirely sure. (*Shrug*) I don't think so. >> header-fields in the message header: From, Sender, To, CC, Bcc, >> Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and >> Reply-To. This up-conversion MUST include address local-parts >> encoded according to [TBD], > >Did you mean utf8-local-part defined in section 4.4 of RFC 5335? Thank you. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 10:04:11 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954463A677D; Thu, 20 Nov 2008 10:04:11 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A933A677D for ; Thu, 20 Nov 2008 10:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZJfecDWn1r0 for ; Thu, 20 Nov 2008 10:04:10 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 1C3C03A6767 for ; Thu, 20 Nov 2008 10:04:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F342F39E431 for ; Thu, 20 Nov 2008 19:03:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOcN3wzG1WkX for ; Thu, 20 Nov 2008 19:03:43 +0100 (CET) Received: from [130.129.95.27] (unknown [130.129.95.27]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4E38B39E40A for ; Thu, 20 Nov 2008 19:03:43 +0100 (CET) Message-ID: <4925A694.2020109@alvestrand.no> Date: Thu, 20 Nov 2008 19:04:04 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: EAI WG Subject: [EAI] Agenda slides uploaded X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org I have uploaded agenda slides, which includes notes on the recent AD review of -downgrade, to the preliminary minutes page. I'll be calling for a scribe in the meeting, if we don't have a volunteer ahead of time. http://www.ietf.org/proceedings/08nov/slides/eai-0.ppt Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 11:09:18 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA763A686D; Thu, 20 Nov 2008 11:09:18 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0F93A686D for ; Thu, 20 Nov 2008 11:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsLtxQJiuGXu for ; Thu, 20 Nov 2008 11:09:16 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 389C33A6835 for ; Thu, 20 Nov 2008 11:09:16 -0800 (PST) Received: from [130.129.31.232] ((unknown) [130.129.31.232]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 20 Nov 2008 19:09:13 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4925B5C4.2020104@isode.com> Date: Thu, 20 Nov 2008 13:08:52 -0600 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Pete Resnick References: <491DBA66.5010903@isode.com> In-Reply-To: MIME-Version: 1.0 Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Pete Resnick wrote: > On 11/14/08 at 5:50 PM +0000, Alexey Melnikov wrote: > >>> 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions >>> >>> When an IMAP server advertises both the "UTF8" capability and the >>> "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the >>> LIST extensions described in this section. When an IMAP server >>> advertises the UTF8=ONLY capability and the LIST-EXTENDED >>> capability, >>> the server MUST reject these LIST extensions with a BAD response. >> >> Ok, I might be confused here, but I think this contradicts >> description of the UTF8=ONLY capability in section 7: >> >> This 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. > > I think the point here is that if you have UTF8=ONLY, then it is > pointless to use the UTF8 or UTF8ONLY param to LIST, Pointless for a client that only supports UTF8=ONLY - probably. However, I think the intent is to encourage client deployments now. In short term there would be no UTF8=ONLY servers, so clients would need to work when UTF8 and UTF8ONLY are required. I don't think you want to require two code paths in such clients. > since all of the mailboxes only support UTF-8 headers. But I guess the > param will do no harm either. Again, I'll ask Chris. [...] >>> 4. UTF8=APPEND Capability >>> >>> If the UTF8=APPEND capability is advertised, then the server accepts >>> UTF-8 headers in the APPEND command message argument. A client >>> which >>> sends a message with UTF-8 headers to the server MUST include the >>> UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: >>> >>> append-ext =/ "UTF8" >> >> This is probably Ok, but note that RFC 4466 required each label to >> have a parameter. Whether this is a bug, or there was a reason for >> that, I currently don't remember. > > Crap. That's going to give parsers serious problems. Let's discuss > offline. Sure. _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 11:43:27 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6748128C23B; Thu, 20 Nov 2008 11:43:27 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A417A3A686D for ; Thu, 20 Nov 2008 11:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fib3GILWPSr3 for ; Thu, 20 Nov 2008 11:43:24 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 5D6643A6AF5 for ; Thu, 20 Nov 2008 11:43:24 -0800 (PST) Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1L3FQo-0008Tu-5U; Thu, 20 Nov 2008 19:43:14 +0000 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=[10.1.3.133]) by smtp.afilias.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L3FRA-000843-4m; Thu, 20 Nov 2008 19:43:36 +0000 Message-ID: <4925BDD3.8080007@ca.afilias.info> Date: Thu, 20 Nov 2008 14:43:15 -0500 From: Joseph Yee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Pete Resnick References: <491DBA66.5010903@isode.com> In-Reply-To: Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Pete Resnick wrote: > On 11/14/08 at 5:50 PM +0000, Alexey Melnikov wrote: > >>> [TBD stringprep for mailbox names? Can we reuse SASLprep?]. >> >> Note that I was faced with a similar issue in the ManageSieve >> protocol, where script names are in UTF-8. After some discussion in >> the Sieve WG we've decided to go with something like this: >> >> A Sieve script name is a sequence of Unicode characters encoded in >> UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition >> (Section 2 of [NET-UNICODE]), with the following additional >> restrictions: >> >> o 0000-001F; [CONTROL CHARACTERS] >> >> o 007F; DELETE >> >> o 0080-009F; [CONTROL CHARACTERS] >> >> o 2028; LINE SEPARATOR >> >> o 2029; PARAGRAPH SEPARATOR >> >> Where: >> >> [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for Network >> Interchange", RFC 5198, March 2008. > > Works for me. > Not related to Sieve, but current IMAP mailbox names are expected to store in modified UTF-7 format. Any chance to relax it since we are i18n-ize (lazy to spell) other parts already. Don't remember seeing the discussion of this online before... >>> ...unless the mailbox is UTF-8 only, in which case IMAP >>> servers SHOULD accept UTF-8 in message keywords. [TBD stringprep for >>> message keywords? Can we reuse SASLprep?] >> >> Haven't we decided to leave keywords as ASCII some time ago? I don't >> have a strong opinion either way. > > Same here. I'll check with Chris as to why he put this in the original > version. > Slightly strong opinion here :) Pre predefined keywords like "Answered", "Seen" should stay the same, but user generated keywords? Would love to see it available. But if it meant new mechanism, different way to handle depends on CAPA, or diverse charset support...I am happy to stay in ASCII for now. >>> TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. >> >> I think I can help with that ;-): >> >> utf8-select-param = "UTF8" >> ;; Conforms to from RFC 4466. > > OK. > >>> 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions >>> >>> When an IMAP server advertises both the "UTF8" capability and the >>> "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the >>> LIST extensions described in this section. When an IMAP server >>> advertises the UTF8=ONLY capability and the LIST-EXTENDED capability, >>> the server MUST reject these LIST extensions with a BAD response. >> >> Ok, I might be confused here, but I think this contradicts description >> of the UTF8=ONLY capability in section 7: >> >> This 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. > > I think the point here is that if you have UTF8=ONLY, then it is > pointless to use the UTF8 or UTF8ONLY param to LIST, since all of the > mailboxes only support UTF-8 headers. But I guess the param will do no > harm either. Again, I'll ask Chris. > >>> 3.4.1. UTF8 and UTF8ONLY LIST Selection Options >>> >>> The UTF8 LIST selection option tells the server to include mailboxes >>> that only support UTF-8 headers in the output of the list command. >>> The UTF8ONLY LIST selection option tells the server to include all >>> mailboxes that support UTF-8 headers and to exclude mailboxes that >>> don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it >>> is not necessary for the client to request both. Use of either >>> selection option will also result in UTF-8 mailbox names in the >>> result as described in Section 3.3. >> >> This need to clarify that either selection option implies the UTF8 >> return option described in section 3.4.2, which in its term means that >> "\NoUTF8" and "\UTF8Only" mailbox attributes need to be returned when >> necessary. The only place where this information can be found is in >> the IANA registration itself. I think most readers would miss that. > > I'll repeat it here. > >>> 3.4.2. UTF8 LIST Return Option >>> >>> If the client supplies the UTF8 LIST return option, then the server >>> MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as >>> appropriate. The \NoUTF8 mailbox attribute indicates an attempt to >>> SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with >>> a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute >>> indicates an attempt to SELECT or EXAMINE that mailbox without the >>> UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note >>> that computing this information may be expensive on some server >>> implementations so this return option should not be used unless >>> necessary. >>> >>> The ABNF [RFC5234] for these LIST extensions follows: >>> >>> list-select-independent-opt =/ "UTF8" / "UTF8ONLY" >> >> So, if you agree, I suggest changing this to: >> >> list-select-independent-opt =/ "UTF8" >> list-select-base-opt =/ "UTF8ONLY" > > No problem. > >>> mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" >> >> I think you've copied typo from an old LIST-EXTENDED draft: please >> change "mbox-list-oflag" to "mbx-list-oflag". >> [...] > > Done. > >>> 4. UTF8=APPEND Capability >>> >>> If the UTF8=APPEND capability is advertised, then the server accepts >>> UTF-8 headers in the APPEND command message argument. A client which >>> sends a message with UTF-8 headers to the server MUST include the >>> UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: >>> >>> append-ext =/ "UTF8" >> >> This is probably Ok, but note that RFC 4466 required each label to >> have a parameter. Whether this is a bug, or there was a reason for >> that, I currently don't remember. > > Crap. That's going to give parsers serious problems. Let's discuss offline. > >>> IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY >>> capability SHOULD reject an APPEND command which includes any 8-bit >>> in the message headers with a "NO" response. >> >> Does this need a new response code? I am not entirely sure. > > (*Shrug*) I don't think so. > >>> header-fields in the message header: From, Sender, To, CC, Bcc, >>> Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and >>> Reply-To. This up-conversion MUST include address local-parts >>> encoded according to [TBD], >> >> Did you mean utf8-local-part defined in section 4.4 of RFC 5335? > > Thank you. > > pr Thanks Joseph _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 11:56:31 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351D73A6946; Thu, 20 Nov 2008 11:56:31 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346C73A6946 for ; Thu, 20 Nov 2008 11:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL-UHoBeL9cO for ; Thu, 20 Nov 2008 11:56:29 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0763D3A677D for ; Thu, 20 Nov 2008 11:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1227210988; x=1258746988; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<4925BDD3.80800 07@ca.afilias.info>|References:=20<491DBA66.5010903@isode .com>=0D=0A=20=0D =0A=20<4925BDD3.8080007@ca.afilias.info>|User-Agent:=20Eu dora=206.2.5b1(Macintosh)|Date:=20Thu,=2020=20Nov=202008 =2013:56:09=20-0600|To:=20Joseph=20Yee=20|From:=20Pete=20Resnick=20 |Subject:=20Re:=20[EAI]=20Comments=20on=20draft-ietf-eai- imap-utf8-04.txt|CC:=20|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5440"=3B=20a =3D"13315688"; bh=Dg88teI8+YafBNZLCYc1pcTVur7s0rF3lfdd4uGtYiU=; b=QorhQGYyx8qlrD+PKvzbK490YA5zNdJTuqwxHdhGcSRJO1tteDn4n1NQ m0M6vDhlrQNYFNgQzzOsB60yzI+pnHLxffF2zLPXDbFgzAHpd4IYp+QZ/ 99/9w5blhwLZAFEdp5fzTAxSmeNMTRHrNbKKtNTIN0P+GdlD1laWfo11l o=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13315688" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 11:56:13 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKJuDuq029475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 11:56:13 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKJuCfg006645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Nov 2008 11:56:13 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 11:56:12 -0800 Received: from [75.145.176.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 11:56:11 -0800 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <4925BDD3.8080007@ca.afilias.info> References: <491DBA66.5010903@isode.com> <4925BDD3.8080007@ca.afilias.info> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Thu, 20 Nov 2008 13:56:09 -0600 To: Joseph Yee From: Pete Resnick Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On 11/20/08 at 2:43 PM -0500, Joseph Yee wrote: >Not related to Sieve, but current IMAP mailbox names are expected to >store in modified UTF-7 format. Any chance to relax it since we are >i18n-ize (lazy to spell) other parts already. Don't remember seeing >the discussion of this online before... Is section 3.3 not sufficient? It says: "After an IMAP client successfully issues an "ENABLE UTF8" command, the server MUST NOT return in LIST results any mailbox names to the client following the IMAP4 Mailbox International Naming Convention. Instead, the server MUST return any mailbox names with characters outside the US-ASCII repertorie using utf8-quoted syntax. (The IMAP4 Mailbox International Naming Convention has proved problematic in the past, so the desire is to make this syntax obsolete as quickly as possible.)" >>>Haven't we decided to leave keywords as ASCII some time ago? I >>>don't have a strong opinion either way. >> >>Same here. I'll check with Chris as to why he put this in the >>original version. > >Slightly strong opinion here :) >Pre predefined keywords like "Answered", "Seen" should stay the >same, but user generated keywords? Would love to see it available. >But if it meant new mechanism, different way to handle depends on >CAPA, or diverse charset support...I am happy to stay in ASCII for >now. You might want to address John Klensin's comments on this. On 11/14/08 at 2:20 PM -0500, John C Klensin wrote: >I do have a strong opinion that, if non-ASCII keywords are accepted, >you are going to need to address comparison models for the keywords, >including normalization and case-folding issues. We sort of know how >to do that, but I can't recommend a tour of that rat hole. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 12:15:02 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0B13A69D8; Thu, 20 Nov 2008 12:15:02 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C11CB3A69D8; Thu, 20 Nov 2008 12:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081120201501.C11CB3A69D8@core3.amsl.com> Date: Thu, 20 Nov 2008 12:15:01 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-mailinglist-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart 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 Internationalized Email Addresses Author(s) : R. Gellens Filename : draft-ietf-eai-mailinglist-04.txt Pages : 11 Date : 2008-11-20 This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eai-mailinglist-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-20120635.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Nov 20 12:32:13 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD013A6986; Thu, 20 Nov 2008 12:32:13 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807CD3A6939 for ; Thu, 20 Nov 2008 12:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uErINtY0-a9 for ; Thu, 20 Nov 2008 12:32:11 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 98D423A699A for ; Thu, 20 Nov 2008 12:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1227213131; x=1258749131; h=message-id:x-mailer:x-message-flag:date:to:from:subject: mime-version:content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-flag: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Thu,=2020=20Nov=20 2008=2012:29:03=20-0800|To:=20|From:=20Rand all=20Gellens=20|Subject:=20Re:=20[EA I]=20I-D=20Action:draft-ietf-eai-mailinglist-04.txt |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,54 40"=3B=20a=3D"13342313"; bh=7nzeCEiuODIErcFJBmDfq4627KmEoKruk+J6PyvJHSA=; b=SME6ASwHvDSVBdOW4XSVwZtR3c8q9yOZLGHg2cHiGZOLD2LqytOM0WWM ChJ5OzpNMVSddu5d99ZeQ+W7+r0uXhwNv8F6ypqfVDd2EB3SNAOKUjPUk HnJGxmXgiHm1r09i2dnRTvVS7Hdtb/UP04eWrGZgNvQPjmH5ahP0LKNWa g=; X-IronPort-AV: E=McAfee;i="5300,2777,5440"; a="13342313" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 12:32:10 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKKWAAx006300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Nov 2008 12:32:10 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKKW9rV028688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Nov 2008 12:32:10 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 12:32:09 -0800 Received: from [130.129.79.186] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 12:32:08 -0800 Message-ID: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 20 Nov 2008 12:29:03 -0800 To: From: Randall Gellens MIME-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Subject: Re: [EAI] I-D Action:draft-ietf-eai-mailinglist-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Changes from -03: Rewrote text in Section 5 on List-* headers. Added new text specifically on List-ID. Noted that currently, IRIs in List-* headers must be encoded as ASCII. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The Good Humor man can only be pushed so far --Written on the chalkboard by Bart in the opening of _The_Simpsons_ (TV show) _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 13:11:07 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B3F3A6A01; Thu, 20 Nov 2008 13:11:07 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF013A6A01 for ; Thu, 20 Nov 2008 13:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnF0MhfZ+m-A for ; Thu, 20 Nov 2008 13:11:05 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 020513A6986 for ; Thu, 20 Nov 2008 13:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1227215464; x=1258751464; h=mime-version:x-sender:message-id:in-reply-to:references: user-agent:date:to:from:subject:cc:content-type: x-ironport-av; z=MIME-Version:=201.0|X-Sender:=20presnick@resnick1.qualco mm.com@resnick1.qualcomm.com|Message-ID:=20|In-Reply-To:=20<4925B5C4.20201 04@isode.com>|References:=20<491DBA66.5010903@isode.com> =0D=0A=20=20<4925 B5C4.2020104@isode.com>|User-Agent:=20Eudora=206.2.5b1(Ma cintosh)|Date:=20Thu,=2020=20Nov=202008=2015:10:55=20-060 0|To:=20Alexey=20Melnikov=20 |From:=20Pete=20Resnick=20 |Subject:=20Re:=20[EAI]=20Comments=20on=20draft-ietf-eai- imap-utf8-04.txt|CC:=20|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5440"=3B=20 a=3D"13343541"; bh=nQlGQ6I/8wuys56TJQSGUG2Owwwq5cee6FMEDIt//7A=; b=aXMVYFSTno08b31YPVenLi0pRSOlnpasYQNIXrT2O57QlnzTk4UPX5F/ 3aKk0BlprJxlLAJvi1+fUFzwSY/hczTwMKJ5n/OYfHT4TsnntxxZZJy/p DoNAN0WQGGZVM6naEfWOOUpYbO6VvBvHXlM6h20uBMg/qFnF9SdwpfCy3 I=; X-IronPort-AV: E=McAfee;i="5300,2777,5440"; a="13343541" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 13:11:04 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKLB3tm012191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 13:11:03 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKLAwaw021297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Nov 2008 13:11:03 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 13:10:58 -0800 Received: from [75.145.176.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 13:10:57 -0800 MIME-Version: 1.0 X-Sender: presnick@resnick1.qualcomm.com@resnick1.qualcomm.com Message-ID: In-Reply-To: <4925B5C4.2020104@isode.com> References: <491DBA66.5010903@isode.com> <4925B5C4.2020104@isode.com> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Thu, 20 Nov 2008 15:10:55 -0600 To: Alexey Melnikov From: Pete Resnick Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On 11/20/08 at 1:08 PM -0600, Alexey Melnikov wrote: >>>>4. UTF8=APPEND Capability >>>> >>>> If the UTF8=APPEND capability is advertised, then the server accepts >>>> UTF-8 headers in the APPEND command message argument. A client which >>>> sends a message with UTF-8 headers to the server MUST include the >>>> UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: >>>> >>>> append-ext =/ "UTF8" >>> >>>This is probably Ok, but note that RFC 4466 required each label to >>>have a parameter. Whether this is a bug, or there was a reason for >>>that, I currently don't remember. >> >>Crap. That's going to give parsers serious problems. Let's discuss offline. > >Sure. OK, we discussed offline, and the above is wrong. Instead, we think we need to replace with: utf8-literal = "UTF8" SP "(" literal8 ")" append-data =/ utf8-literal We will also need to update CATENATE (RFC 4469) by adding: cat-part =/ utf8-literal Does that look OK to everyone? (And if you don't have the stomach to read 4466, your silence will be taken as acceptance.) pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 13:30:02 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DC73A6906; Thu, 20 Nov 2008 13:30:02 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 715463A68D4; Thu, 20 Nov 2008 13:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081120213001.715463A68D4@core3.amsl.com> Date: Thu, 20 Nov 2008 13:30:01 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-pop-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart 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 : POP3 Support for UTF-8 Author(s) : C. Newman, R. Gellens Filename : draft-ietf-eai-pop-05.txt Pages : 14 Date : 2008-11-20 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 error strings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eai-pop-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-20132306.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Nov 20 14:15:16 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3391628C277; Thu, 20 Nov 2008 14:15:16 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDA728C128 for ; Thu, 20 Nov 2008 14:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06RCBzZPfz63 for ; Thu, 20 Nov 2008 14:15:13 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 42E3628C269 for ; Thu, 20 Nov 2008 14:15:13 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAKMFAjA008658 for ; Thu, 20 Nov 2008 14:15:10 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAN00G01JSN8T00@fe-sfbay-09.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 20 Nov 2008 14:15:09 -0800 (PST) Received: from [130.129.31.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAN00N1DKH25980@fe-sfbay-09.sun.com>; Thu, 20 Nov 2008 14:15:04 -0800 (PST) Date: Thu, 20 Nov 2008 16:14:56 -0600 From: Chris Newman In-reply-to: To: Pete Resnick , Alexey Melnikov Message-id: <186B92DB7206D49AAA2E40A7@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline References: <491DBA66.5010903@isode.com> Cc: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On November 20, 2008 11:54:59 -0600 Pete Resnick wrote: >> Haven't we decided to leave keywords as ASCII some time ago? I don't >> have a strong opinion either way. > > Same here. I'll check with Chris as to why he put this in the original > version. I wrote it before that decision. Fine to go with ASCII particularly since annotations have gotten further. >>> TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. >> >> I think I can help with that ;-): >> >> utf8-select-param = "UTF8" >> ;; Conforms to from RFC 4466. > > OK. > >>> 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions >>> >>> When an IMAP server advertises both the "UTF8" capability and the >>> "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the >>> LIST extensions described in this section. When an IMAP server >>> advertises the UTF8=ONLY capability and the LIST-EXTENDED capability, >>> the server MUST reject these LIST extensions with a BAD response. >> >> Ok, I might be confused here, but I think this contradicts >> description of the UTF8=ONLY capability in section 7: >> >> This 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. > > I think the point here is that if you have UTF8=ONLY, then it is > pointless to use the UTF8 or UTF8ONLY param to LIST, since all of the > mailboxes only support UTF-8 headers. But I guess the param will do no > harm either. Again, I'll ask Chris. Yes, that's my intent and yes the text should be fixed so it's not contradictory. >>> IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY >>> capability SHOULD reject an APPEND command which includes any 8-bit >>> in the message headers with a "NO" response. >> >> Does this need a new response code? I am not entirely sure. > > (*Shrug*) I don't think so. The litmus test for response codes is "can the client do something reasonable and different with the additional error than it would with a generic error". I think the answer is "no" in this case as the client is busted already if it's sending EAI to a server that won't accept it. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 14:23:04 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8CB3A6898; Thu, 20 Nov 2008 14:23:04 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5F13A6898 for ; Thu, 20 Nov 2008 14:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka3mDMBFGAUE for ; Thu, 20 Nov 2008 14:23:02 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2AF823A677D for ; Thu, 20 Nov 2008 14:23:02 -0800 (PST) Received: from [130.129.31.232] ((unknown) [130.129.31.232]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 20 Nov 2008 22:22:58 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4925E31E.7020000@isode.com> Date: Thu, 20 Nov 2008 16:22:22 -0600 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Newman References: <491DBA66.5010903@isode.com> <186B92DB7206D49AAA2E40A7@446E7922C82D299DB29D899F> In-Reply-To: <186B92DB7206D49AAA2E40A7@446E7922C82D299DB29D899F> MIME-Version: 1.0 Cc: Pete Resnick , ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Chris Newman wrote: > --On November 20, 2008 11:54:59 -0600 Pete Resnick > wrote: > >>>> 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions >>>> >>>> When an IMAP server advertises both the "UTF8" capability and the >>>> "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the >>>> LIST extensions described in this section. When an IMAP server >>>> advertises the UTF8=ONLY capability and the LIST-EXTENDED >>>> capability, >>>> the server MUST reject these LIST extensions with a BAD response. >>> >>> Ok, I might be confused here, but I think this contradicts >>> description of the UTF8=ONLY capability in section 7: >>> >>> This 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. >> >> I think the point here is that if you have UTF8=ONLY, then it is >> pointless to use the UTF8 or UTF8ONLY param to LIST, since all of the >> mailboxes only support UTF-8 headers. But I guess the param will do no >> harm either. Again, I'll ask Chris. > > Yes, that's my intent and yes the text should be fixed so it's not > contradictory. Just to make sure that everyone is on the page, I would like to discuss this quickly during the Minneapolis meeting. _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 14:43:40 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2407B3A6A49; Thu, 20 Nov 2008 14:43:40 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7C13A6A48 for ; Thu, 20 Nov 2008 14:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd3vdVpWhYr2 for ; Thu, 20 Nov 2008 14:43:38 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id CBF293A6A01 for ; Thu, 20 Nov 2008 14:43:37 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAKMhY0N009681 for ; Thu, 20 Nov 2008 14:43:34 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAN00E01LNKWU00@fe-sfbay-10.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 20 Nov 2008 14:43:34 -0800 (PST) Received: from [130.129.31.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAN004UNLSHBQ60@fe-sfbay-10.sun.com> for ima@ietf.org; Thu, 20 Nov 2008 14:43:31 -0800 (PST) Date: Thu, 20 Nov 2008 16:43:29 -0600 From: Chris Newman In-reply-to: <49216DDB.3030707@alvestrand.no> To: EAI WG Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline References: <49216DDB.3030707@alvestrand.no> Subject: Re: [EAI] [Fwd: AD review of draft-ietf-eai-downgrade-09.txt] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Harald correctly pointed out this is inadequate to update the document: > $ One other header of note: > The Original-Recipient header [RFC 3798] is downgraded as described in > section 4.2 (the same way the ORCPT parameter is downgraded). Turning this into a suggested change: ----- Section 5, add (at end): TYPED-ADDRESS downgrading: Address headers of this form with an address type of "utf-8", "utf-8-addr-xtext", or "utf-8-addr-unitext" are downgraded as described in section 4.2. COMMENT downgrading is also performed in this case. If the address type is unrecognized and the header contains non-ASCII, then fall back to using ENCAPSULATION downgrading on the entire header. Section 5.1, add after sub-section "o Address header fields which contain s": o Address header fields with typed addresses: Original-Recipient [RFC3798] If the header contains non-ASCII, perform TYPED-ADDRESS downgrading. ----- As a technical contributor, I'm inclined to include this change for completeness since this header is draft-standard and there's code reuse from ORCPT=. But I could understand arguments to the contrary given this is a bit more complex than I initially thought. The other five headers I recommended simply need to be added to the relevant existing lists in section 5.1. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 20 15:39:21 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9FE3A6A49; Thu, 20 Nov 2008 15:39:21 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12203A68F1 for ; Thu, 20 Nov 2008 15:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5NP67UoTfqg for ; Thu, 20 Nov 2008 15:39:19 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 0465A3A6A49 for ; Thu, 20 Nov 2008 15:39:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82A2839E431 for ; Fri, 21 Nov 2008 00:38:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNTUsfn4wFvG for ; Fri, 21 Nov 2008 00:38:52 +0100 (CET) Received: from [130.129.79.154] (unknown [130.129.79.154]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D926B39E40A for ; Fri, 21 Nov 2008 00:38:51 +0100 (CET) Message-ID: <4925F523.4010301@alvestrand.no> Date: Fri, 21 Nov 2008 00:39:15 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: EAI WG Subject: [EAI] Agenda slides with resolutions uploaded X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org I have uploaded a new version of the agenda slides, this time with resolutions, to the meeting materials server. http://www.ietf.org/proceedings/08nov/slides/eai-0.ppt _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Nov 23 23:08:21 2008 Return-Path: X-Original-To: ima-archive@megatron.ietf.org Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2813A6A04; Sun, 23 Nov 2008 23:08:21 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DFD3A6A04 for ; Sun, 23 Nov 2008 23:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi319lFDxg4w for ; Sun, 23 Nov 2008 23:08:19 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id BE6F73A6405 for ; Sun, 23 Nov 2008 23:08:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78F3F39E47B for ; Mon, 24 Nov 2008 08:07:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pok0wGMIpabp for ; Mon, 24 Nov 2008 08:07:46 +0100 (CET) Received: from [192.168.1.198] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E046539E402 for ; Mon, 24 Nov 2008 08:07:45 +0100 (CET) Message-ID: <492A52DE.5020406@alvestrand.no> Date: Mon, 24 Nov 2008 08:08:14 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: EAI WG Content-Type: multipart/mixed; boundary="------------090205060709010509090406" Subject: [EAI] Minutes from Minneapolis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------090205060709010509090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is the first draft of the Minneapolis minutes (thanks to Ted Hardie!) Please send corrections or comments to the chairs. NOTE: I do not believe there were any issues of great controversy in this meeting. If I do not hear otherwise on the list, I will assume that all resolutions reached by the meeting are accepted by the WG on the mailing list. For those who were not present - please call out any decision you wish to have explicitly re-evaluated on-list! Harald Alvestrand --------------090205060709010509090406 Content-Type: text/plain; name="minneapolis-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minneapolis-minutes.txt" EAI November 20, 2008 Harald Alvestrand, chair The group first reviewed the status of the documents; the core group has been published as rfcs. A few others have expired or were refreshed very late. Only one in queue with the ADs. Downgraded is the one in the AD queue, with issues raised. The group reviewed the AD issues: ABNF for envelope addresses, 2047 encoding instructions, ORCPT handling, reservation of Downgraded-*, Less critical issues The ABNF for envelope addresses is inconsistent; the AD recommended that a single form be selected. This avoids the need for a different parsers. The AD recommended using the From form (nested angle brackets versus adjacent angle brackets) consistently throughout. Consensus to use the > throughout. 2047 encoding instructions: some text implies encoding of structured fields; not explicit about breaking fields into multiple encoded words. The resolution agreed was to add advice to use multiple encoded words when needed. ORCPT encoding was the third issue. It has text that says it MUST be converted to one of two forms; this seems unworkable. The group concluded that it would accept the ADs suggested change: "The transformation that needs to occur on the content of ORCPT is to 1. remove xtext encoding 2. convert the result of step one to utf-8-addr-unitext form where all non-ASCII characters are represented as EmbeddedUnicodeChar, 3. re-apply xtext encoding to the result of step 2." The group then discussed the reservation of downgraded-*. The document references procedures which are not present. Discussion of the problem noted that there might be a way to bend the rules rather than changing them (making it more a suggestion with a note, rather than changing the rules: asking them not to include new downgrade- headers during the EAI experiment). AD suggests that this document contain instructions to the expert reviewer, rather than IANA. Re-wording to fall under the "conflict with existing IETF activity" provision of expert review instead. The working group chair will ask the editor to produce a new document incorporating these changes as soon as possible; the other issues raised will be taken to the list. The group then discussed how comprehensive to make the list of headers to be downgraded; Auto-submitted was one example. Chris was concerned that converting auto-submitted to downgraded-auto-submitted might allow for the creation of mail loops. A total of six will be added to the list: Original-recipient, Auto-submitted, Disposition-to, Content-transfer-encoding, Content-language, Accept-language (the comments on these may be where the UTF-8 occurs). Further discussion will be on the linst. The group then discussed the downgrade-display draft. Only two present had read the draft recently. The group discussion focused on the security considerations. John Klensin felt that it out to be re-couched as a set of experiments to be performed. No consensus on disposition, but the chair stressed that further review is needed here to make progress. The group then discussed the EAI deployment practices draft. John's comments here mirrored the previous draft; it is a useful place to record experience, but it needs to be updated with real deployment experience. The chair took on the task of pinging the editors of Pete Resnick then discussed the IMAP draft,first asking for implementation and deployment experience, then reviewing the changes. During the discusion of the APPEND syntax problem, the chair noted that the room's participants were glazed over. Recommendation that there be a working group last call of the draft revision, knowing that experimental results might cause it to be changed. John Klensin volunteered to push the working group toward producing an update of the charter. He believes we basically know what has to be done. There are documents evaluating the experiments, then ship documents to the IESG for standards track. As a strawman, a ship date of late 2009 for the proposed standards was discussed, but with an intent of reviewing the question in March 2009. There being no other business, the chair closed the meeting. --------------090205060709010509090406 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima --------------090205060709010509090406--