From alexey.melnikov@isode.com Tue Oct 2 02:34:11 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CAC21F8988 for ; Tue, 2 Oct 2012 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW7pOKVCpl8q for ; Tue, 2 Oct 2012 02:34:11 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5121F8815 for ; Tue, 2 Oct 2012 02:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349170448; d=isode.com; s=selector; i=@isode.com; bh=UmcPhZYRGAMy0soYyVxcC0vex1xxO7/E0v2PRL88yVU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=t66d/jSvobNjtcL2ccAJfJbGrMZAupBAIOFUMFdt6Wq+nf/D/VlvHxoMJh7f7zSJowIRMr za38wv6JIdQXE/WkMK0+rKLufRmdnUd+FFgQth+umGtbD6ZLT2iUZASH3zK4q7MQJK9bDz slH2Pby1BRH9CMLyXoR0HhphsCesgl4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 2 Oct 2012 10:34:08 +0100 Message-ID: <506A0266.80005@isode.com> Date: Mon, 01 Oct 2012 21:51:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <505390CE.8070502@isode.com> <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> In-Reply-To: <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 09:34:12 -0000 On 30/09/2012 14:26, Timo Sirainen wrote: > OK, finally feeling energetic enough today to answer this mail :) > > On 15.9.2012, at 23.55, Alexey Melnikov wrote: > >>>>>> The "UTF8=ONLY" capability permits an IMAP server to advertise that >>>>>> it does not permit the international mailbox name convention >>>>>> (modified UTF-7), >>>>> This doesn't really sound like what "design rationale" section talks about UTF8=ONLY. Isn't the idea simply to behave as if client has done ENABLE UTF8=ACCEPT (which may or may not happen to work with current clients)? >>>> No, I think the idea is to advertise that modified UTF-7 is not supported. >>> If that's the only reason for UTF8=ONLY it seems a rather wasteful capability. A server that doesn't bother to implement mUTF7, but does bother to implement other kinds backwards compatibility seems rather unlikely to me. >> I think the idea was that everybody would implement UTF8=ONLY and UTF8=ACCEPT goes away and can be obsoleted. >>> The text in design rationale section talks that in future everyone would be using UTF8 capable clients and servers and all the old compatibility code could be removed. Wouldn't it make much more sense for UTF8=ONLY to mean that the server has no more such compatibility code? (Basically my idea about assuming client has done ENABLE UTF8=ACCEPT.) >> Can you suggest some text, I am not yet sure what exactly you are suggesting. > I'm hoping to avoid having to implement the message downgrading. Has anyone tried various IMAP clients what they do if they are already being fed UTF8 headers and LIST reply? My guess is that they will handle it pretty well. So I'm thinking that the differences between UTF8=ACCEPT vs. UTF8=ONLY are: > > * APPEND: UTF8=ACCEPT requires UTF8 parameter for UTF8 headers, UTF8=ONLY doesn't. I don't think there was a plan to not use UTF8 parameters for UTF8=ONLY. So I think they are still required to be supported. I think it would be Ok for a UTF8=ONLU server to treat UTF8 parameters the same way as regular literals. > Downgrading not needed, since APPEND can simply fail with NO. > > * FETCH BODY[], BODY[HEADER], etc: Non-UTF8 enabled client is tricky, but with UTF8=ONLY the headers can be sent as-is always. Right. > * FETCH BODY/BODYSTRUCTURE/ENVELOPE: Semi-easy to convert everything(?) for non-UTF8 enabled client. With UTF8=ONLY just send as-is. Agreed. > * LIST: Trivial to convert mailbox names to mUTF7 for non-UTF8 enabled clients. With UTF8=ONLY always send as UTF8. > > So only mentioning that UTF8=ONLY affects LIST reply isn't enough. And if my UTF8=ONLY understanding is correct, all of those commands behave identically with UTF8=ACCEPT enabled client and non-UTF8 enabled UTF8=ONLY server. So that's why I'm suggesting simply to change this: > >> The "UTF8=ONLY" capability permits an IMAP server to advertise that >> it does not permit the international mailbox name convention >> (modified UTF-7), > to: > > The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support legacy clients anymore, but behaves as if the client had issued ENABLE UTF8=ONLY command immediately after connect. This also means that when a client detects the UTF8=ONLY capability, there is no need for it to even send the ENABLE UTF8=ONLY command. I don't think your suggestion is correct: it will break clients that don't recognize UTF8=ONLY: IMAP servers can't send non IMAP4rev1 compliant data to clients unless such clients signal that they support new capabilities. So ENABLE UTF8=ONLY would always be required. From tss@iki.fi Tue Oct 2 07:56:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589A521F84A2 for ; Tue, 2 Oct 2012 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQXTh0h6e10Q for ; Tue, 2 Oct 2012 07:56:19 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01C21F84A1 for ; Tue, 2 Oct 2012 07:56:19 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id A09B61AE8819; Tue, 2 Oct 2012 17:56:17 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <506A0266.80005@isode.com> Date: Tue, 2 Oct 2012 17:56:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <29663FDD-D888-4EF8-BCC0-62A9C7A7516C@iki.fi> References: <505390CE.8070502@isode.com> <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> <506A0266.80005@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:56:20 -0000 On 1.10.2012, at 23.51, Alexey Melnikov wrote: >> * APPEND: UTF8=3DACCEPT requires UTF8 parameter for UTF8 headers, = UTF8=3DONLY doesn't. > I don't think there was a plan to not use UTF8 parameters for = UTF8=3DONLY. So I think they are still required to be supported. > I think it would be Ok for a UTF8=3DONLU server to treat UTF8 = parameters the same way as regular literals. OK, I also started wondering about this after sending the mail. >> So only mentioning that UTF8=3DONLY affects LIST reply isn't enough. = And if my UTF8=3DONLY understanding is correct, all of those commands = behave identically with UTF8=3DACCEPT enabled client and non-UTF8 = enabled UTF8=3DONLY server. So that's why I'm suggesting simply to = change this: >>=20 >>> The "UTF8=3DONLY" capability permits an IMAP server to advertise = that >>> it does not permit the international mailbox name convention >>> (modified UTF-7), >> to: >>=20 >> The "UTF8=3DONLY" capability permits an IMAP server to advertise that = it does not support legacy clients anymore, but behaves as if the client = had issued ENABLE UTF8=3DONLY command immediately after connect. This = also means that when a client detects the UTF8=3DONLY capability, there = is no need for it to even send the ENABLE UTF8=3DONLY command. >=20 > I don't think your suggestion is correct: it will break clients that = don't recognize UTF8=3DONLY: IMAP servers can't send non IMAP4rev1 = compliant data to clients unless such clients signal that they support = new capabilities. So ENABLE UTF8=3DONLY would always be required. I think what confused me was the "design rationale" text: The "UTF8=3DONLY" mechanism simplifies diagnosis of interoperability problems when legacy support goes away. In the situation where backwards compatibility is broken anyway, just-send-UTF-8 IMAP has the advantage that it might work with some legacy clients. However, the difficulty of diagnosing interoperability problems caused by a just-send-UTF-8 IMAP mechanism is the reason the "UTF8=3DONLY" capability mechanism was chosen. I understood this as UTF8=3DONLY means the same as "just-send-UTF-8", = but with the benefit of telling clients that it's going to do that. So is it more correct then to say that with UTF8=3DONLY server may = simply not send any LIST replies and not allow any CREATE commands, = unless ENABLE UTF8=3DONLY is done? So basically the server will be = unusable without it.= From alexey.melnikov@isode.com Wed Oct 3 05:30:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA1F21F86AA for ; Wed, 3 Oct 2012 05:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubHsccNVKYQP for ; Wed, 3 Oct 2012 05:30:22 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1021F85B6 for ; Wed, 3 Oct 2012 05:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349267421; d=isode.com; s=selector; i=@isode.com; bh=eZX0ayIdwN+2ebgudzzlB/3nfT77BgtToBGRyc/VUL0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=sIIXiS7mygp2CwDg+hJTz+3Q2kdAza+w2gEhst49LFhjVn+cuGyqOoB6lDh/MLMQAQ6RUw hTh6doVkzlhJKVbxlOW7AUse42q9JrjvHwPGhzoA80azPLO4hcVUeZoUr6QgSY0HXZQyf9 nXxFEsDrW76mQHKKmXEdGowsnFS3ORk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 3 Oct 2012 13:30:21 +0100 Message-ID: <506C2FE0.7040009@isode.com> Date: Wed, 03 Oct 2012 13:30:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <505390CE.8070502@isode.com> <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> <506A0266.80005@isode.com> <29663FDD-D888-4EF8-BCC0-62A9C7A7516C@iki.fi> In-Reply-To: <29663FDD-D888-4EF8-BCC0-62A9C7A7516C@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:30:23 -0000 On 02/10/2012 15:56, Timo Sirainen wrote: > On 1.10.2012, at 23.51, Alexey Melnikov wrote: > >>> * APPEND: UTF8=ACCEPT requires UTF8 parameter for UTF8 headers, UTF8=ONLY doesn't. >> I don't think there was a plan to not use UTF8 parameters for UTF8=ONLY. So I think they are still required to be supported. >> I think it would be Ok for a UTF8=ONLU server to treat UTF8 parameters the same way as regular literals. > OK, I also started wondering about this after sending the mail. Personally I don't care about this particular part (I can live with either no change from UTF8=ACCEPT or no support for UTF8 parameters in UTF8=ONLY). >>> So only mentioning that UTF8=ONLY affects LIST reply isn't enough. And if my UTF8=ONLY understanding is correct, all of those commands behave identically with UTF8=ACCEPT enabled client and non-UTF8 enabled UTF8=ONLY server. So that's why I'm suggesting simply to change this: >>> >>>> The "UTF8=ONLY" capability permits an IMAP server to advertise that >>>> it does not permit the international mailbox name convention >>>> (modified UTF-7), >>> to: >>> >>> The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support legacy clients anymore, but behaves as if the client had issued ENABLE UTF8=ONLY command immediately after connect. This also means that when a client detects the UTF8=ONLY capability, there is no need for it to even send the ENABLE UTF8=ONLY command. >> I don't think your suggestion is correct: it will break clients that don't recognize UTF8=ONLY: IMAP servers can't send non IMAP4rev1 compliant data to clients unless such clients signal that they support new capabilities. So ENABLE UTF8=ONLY would always be required. > I think what confused me was the "design rationale" text: > > The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability > problems when legacy support goes away. In the situation where > backwards compatibility is broken anyway, just-send-UTF-8 IMAP has > the advantage that it might work with some legacy clients. However, > the difficulty of diagnosing interoperability problems caused by a > just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY" > capability mechanism was chosen. Right, this text is not quite right (see more below). > I understood this as UTF8=ONLY means the same as "just-send-UTF-8", but with the benefit of telling clients that it's going to do that. That would have been fine, but you can't do this in IMAP with an extension without violating IMAP architecture. The right way to do this while still complying with IMAP architecture is either: 1). the client signals that it understands the extension (ENABLE is one mechanism) and/or 2). we change the base IMAP capability from IMAP4rev1 to something else. > So is it more correct then to say that with UTF8=ONLY server may simply not send any LIST replies and not allow any CREATE commands, unless ENABLE UTF8=ONLY is done? I think so. > So basically the server will be unusable without it. Nearly unusable, yes. From tss@iki.fi Wed Oct 3 09:30:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE01A21F850C for ; Wed, 3 Oct 2012 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.392 X-Spam-Level: X-Spam-Status: No, score=-110.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJDpn3HggMuy for ; Wed, 3 Oct 2012 09:30:10 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1721F849C for ; Wed, 3 Oct 2012 09:30:09 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 6851D1AE87DA; Wed, 3 Oct 2012 19:30:08 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <506C2FE0.7040009@isode.com> Date: Wed, 3 Oct 2012 19:30:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505390CE.8070502@isode.com> <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> <506A0266.80005@isode.com> <29663FDD-D888-4EF8-BCC0-62A9C7A7516C@iki.fi> <506C2FE0.7040009@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:30:11 -0000 On 3.10.2012, at 15.30, Alexey Melnikov wrote: > On 02/10/2012 15:56, Timo Sirainen wrote: >> On 1.10.2012, at 23.51, Alexey Melnikov wrote: >>=20 >>>> * APPEND: UTF8=3DACCEPT requires UTF8 parameter for UTF8 headers, = UTF8=3DONLY doesn't. >>> I don't think there was a plan to not use UTF8 parameters for = UTF8=3DONLY. So I think they are still required to be supported. >>> I think it would be Ok for a UTF8=3DONLU server to treat UTF8 = parameters the same way as regular literals. >> OK, I also started wondering about this after sending the mail. >=20 > Personally I don't care about this particular part (I can live with = either no change from UTF8=3DACCEPT or no support for UTF8 parameters in = UTF8=3DONLY). I don't care that much either :) >>>> So only mentioning that UTF8=3DONLY affects LIST reply isn't = enough. And if my UTF8=3DONLY understanding is correct, all of those = commands behave identically with UTF8=3DACCEPT enabled client and = non-UTF8 enabled UTF8=3DONLY server. So that's why I'm suggesting simply = to change this: >>>>=20 >>>>> The "UTF8=3DONLY" capability permits an IMAP server to advertise = that >>>>> it does not permit the international mailbox name convention >>>>> (modified UTF-7), >>>> to: >>>>=20 >>>> The "UTF8=3DONLY" capability permits an IMAP server to advertise = that it does not support legacy clients anymore, but behaves as if the = client had issued ENABLE UTF8=3DONLY command immediately after connect. = This also means that when a client detects the UTF8=3DONLY capability, = there is no need for it to even send the ENABLE UTF8=3DONLY command. >>> I don't think your suggestion is correct: it will break clients that = don't recognize UTF8=3DONLY: IMAP servers can't send non IMAP4rev1 = compliant data to clients unless such clients signal that they support = new capabilities. So ENABLE UTF8=3DONLY would always be required. >> I think what confused me was the "design rationale" text: >>=20 >> The "UTF8=3DONLY" mechanism simplifies diagnosis of = interoperability >> problems when legacy support goes away. In the situation where >> backwards compatibility is broken anyway, just-send-UTF-8 IMAP has >> the advantage that it might work with some legacy clients. = However, >> the difficulty of diagnosing interoperability problems caused by a >> just-send-UTF-8 IMAP mechanism is the reason the "UTF8=3DONLY" >> capability mechanism was chosen. >=20 > Right, this text is not quite right (see more below). >=20 >> I understood this as UTF8=3DONLY means the same as "just-send-UTF-8", = but with the benefit of telling clients that it's going to do that. > That would have been fine, but you can't do this in IMAP with an = extension without violating IMAP architecture. The right way to do this = while still complying with IMAP architecture is either: > 1). the client signals that it understands the extension (ENABLE is = one mechanism) > and/or > 2). we change the base IMAP capability from IMAP4rev1 to something = else. IMAP clients don't give very informative error messages if IMAP4rev1 is = missing, so I guess ENABLE is better. >> So is it more correct then to say that with UTF8=3DONLY server may = simply not send any LIST replies and not allow any CREATE commands, = unless ENABLE UTF8=3DONLY is done? >=20 > I think so. OK, so maybe something like: The "UTF8=3DONLY" capability permits an IMAP server to advertise that it = does not support IMAP clients that do not issue ENABLE UTF8=3DONLY. A = client that supports this extension MUST send ENABLE UTF8=3DONLY command = either before login or as the first command in the authenticated state. = The server may otherwise reject all commands or otherwise restrict the = mailboxes visible to the client.= From alexey.melnikov@isode.com Thu Oct 4 08:18:03 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5875811E80D3 for ; Thu, 4 Oct 2012 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJVo3TqGAeVG for ; Thu, 4 Oct 2012 08:18:02 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A221F86F8 for ; Thu, 4 Oct 2012 08:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349363880; d=isode.com; s=selector; i=@isode.com; bh=koUfr7a0cebPDzii1+6FRCZtViwX99dU7HG+weSJYUc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dnzXiMX1Hf3IdZIM4F03noAXsJzCciUD/8qvMn3RB/JOalGFEW7xsFzxORc2QGt3802jbT CkbuXLSGeirVsnnHu9FktDNGFQqDGxXSZg03B8k5qXfT8GkmmIycROaiaDLx3gOjDnQKq2 1oQkPgsNTuhILMlzSpgRL6DPtJQfP7c=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 4 Oct 2012 16:18:00 +0100 Message-ID: <506DA8AD.3060005@isode.com> Date: Thu, 04 Oct 2012 16:18:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <505390CE.8070502@isode.com> <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> <506A0266.80005@isode.com> <29663FDD-D888-4EF8-BCC0-62A9C7A7516C@iki.fi> <506C2FE0.7040009@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:18:03 -0000 On 03/10/2012 17:30, Timo Sirainen wrote: > On 3.10.2012, at 15.30, Alexey Melnikov wrote: >> On 02/10/2012 15:56, Timo Sirainen wrote: >>> On 1.10.2012, at 23.51, Alexey Melnikov wrote: >>>>> * APPEND: UTF8=ACCEPT requires UTF8 parameter for UTF8 headers, UTF8=ONLY doesn't. >>>> I don't think there was a plan to not use UTF8 parameters for UTF8=ONLY. So I think they are still required to be supported. >>>> I think it would be Ok for a UTF8=ONLU server to treat UTF8 parameters the same way as regular literals. >>> OK, I also started wondering about this after sending the mail. >> Personally I don't care about this particular part (I can live with either no change from UTF8=ACCEPT or no support for UTF8 parameters in UTF8=ONLY). > I don't care that much either :) > >>>>> So only mentioning that UTF8=ONLY affects LIST reply isn't enough. And if my UTF8=ONLY understanding is correct, all of those commands behave identically with UTF8=ACCEPT enabled client and non-UTF8 enabled UTF8=ONLY server. So that's why I'm suggesting simply to change this: >>>>> >>>>>> The "UTF8=ONLY" capability permits an IMAP server to advertise that >>>>>> it does not permit the international mailbox name convention >>>>>> (modified UTF-7), >>>>> to: >>>>> >>>>> The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support legacy clients anymore, but behaves as if the client had issued ENABLE UTF8=ONLY command immediately after connect. This also means that when a client detects the UTF8=ONLY capability, there is no need for it to even send the ENABLE UTF8=ONLY command. >>>> I don't think your suggestion is correct: it will break clients that don't recognize UTF8=ONLY: IMAP servers can't send non IMAP4rev1 compliant data to clients unless such clients signal that they support new capabilities. So ENABLE UTF8=ONLY would always be required. >>> I think what confused me was the "design rationale" text: >>> >>> The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability >>> problems when legacy support goes away. In the situation where >>> backwards compatibility is broken anyway, just-send-UTF-8 IMAP has >>> the advantage that it might work with some legacy clients. However, >>> the difficulty of diagnosing interoperability problems caused by a >>> just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY" >>> capability mechanism was chosen. >> Right, this text is not quite right (see more below). >> >>> I understood this as UTF8=ONLY means the same as "just-send-UTF-8", but with the benefit of telling clients that it's going to do that. >> That would have been fine, but you can't do this in IMAP with an extension without violating IMAP architecture. The right way to do this while still complying with IMAP architecture is either: >> 1). the client signals that it understands the extension (ENABLE is one mechanism) >> and/or >> 2). we change the base IMAP capability from IMAP4rev1 to something else. > IMAP clients don't give very informative error messages if IMAP4rev1 is missing, so I guess ENABLE is better. > >>> So is it more correct then to say that with UTF8=ONLY server may simply not send any LIST replies and not allow any CREATE commands, unless ENABLE UTF8=ONLY is done? >> I think so. > OK, so maybe something like: > > The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support IMAP clients that do not issue ENABLE UTF8=ONLY. A client that supports this extension MUST send ENABLE UTF8=ONLY command either before login or as the first command in the authenticated state. The server may otherwise reject all commands or otherwise restrict the mailboxes visible to the client. RFC 5161 says: The ENABLE command is only valid in the authenticated state (see [RFC3501]) I also think that some useful information was lost during this rewrite. So how about this: OLD: The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not permit the international mailbox name convention (modified UTF-7), and also allows all of the capabilities that are allowed by "UTF8=ACCEPT" (see Section 4). As this is an incompatible change to IMAP, a clear warning is necessary. IMAP clients that find implementation of the "UTF8=ONLY" capability problematic are encouraged to at least detect the "UTF8=ONLY" capability and provide an informative error message to the end-user. NEW: The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not permit the international mailbox name convention (modified UTF-7), and also supports all of the functionality that is allowed by "UTF8=ACCEPT" (see Section 3 and Section 4). As this is an incompatible change to IMAP, the server is required to wait for ENABLE UTF8=ONLY command before it can start sending pure UTF-8 mailbox names and non-ASCII messages. In order of being able to talk to a server advertising "UTF8=ONLY" the client needs to send ENABLE UTF8=ONLY command in the authenticated state (as per requirements in [RFC5161]). The server may otherwise, in order to stay compliant with RFC 3501, reject all commands or otherwise restrict the mailboxes visible to the client. IMAP clients that find implementation of the "UTF8=ONLY" capability problematic are encouraged to at least detect the "UTF8=ONLY" capability and provide an informative error message to the end-user. From presnick@qti.qualcomm.com Thu Oct 4 14:33:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754521F84DE for ; Thu, 4 Oct 2012 14:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywHIERFkrRJY for ; Thu, 4 Oct 2012 14:33:38 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB3321F84B6 for ; Thu, 4 Oct 2012 14:33:34 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6855"; a="245893218" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 04 Oct 2012 14:33:33 -0700 X-IronPort-AV: E=Sophos;i="4.80,537,1344236400"; d="scan'208";a="313773352" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Oct 2012 14:33:20 -0700 Received: from kyles-iphone-010073086190.wlan.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 4 Oct 2012 14:33:19 -0700 Message-ID: <506E009A.5040102@qti.qualcomm.com> Date: Thu, 4 Oct 2012 14:33:14 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [EAI] POP/IMAP documents: IESG Evaluation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:33:40 -0000 Folks, There are a couple of outstanding DISCUSS positions from Russ and Benoit during the IESG Evaluation on the IMAP/POP documents. I think I understand the issue, and after discussion today I think we have an easy solution, but I want to confirm with the WG that this still represents our consensus. The issue is with the status of the downgrade documents and how we refer to them. I believe the consensus of the WG was that we want to standardize the downgrade documents because they are the result of extensive technical review, with the outcome being safe and appropriate ways to do downgrading. In particular, if you are going to downgrade, the potential for doing something that does damage (by making a replyable From address that leaks onto the net, or leaking information that becomes a vector of attack) is high enough that you had better know what you're doing when you downgrade. So we decided standards track was appropriate, and I agree. However, it is also perfectly clear that there are other ways you could conceivably downgrade in a safe manner, these were just two ways to do it that got proper vetting. So we didn't want to make either of these REQUIRED for the POP or IMAP documents. However, this left Russ an Benoit a bit confused: If there was the potential for damage if you chose the wrong one, shouldn't these somehow be required? And if not, aren't they just examples that could just be informational documents? After quite a bit of discussion, I think I (and Barry) now understand the issues, and it mostly comes down to how we refer to the two documents. An analogy that helped during our discussion in the IESG was TCP congestion control: Congestion control is much the same in the sense that the receiver can't really tell which congestion control algorithm the sender used, and there are likely many ways to set timers and other parameters and still get it right, but if the sender does it wrong, bad things happen. However, it is also clear that the defined ways of doing congestion control are well understood and tested, and it behooves you to use the currently defined ones unless you really know what you are doing. They aren't just examples; getting this stuff right is hard, and you should trust us that we've got the right algorithm. So, the suggested change to the EAI documents is (a) to add language to both 5721bis and 5738bis that says that *if* you're going to do downgrading, you SHOULD implement one of the algorithms in popimap-downgrade or simpledowngrade (perhaps with a specific line that says, "This stuff is hard to get right, and these two standards track documents are two ways that we worked out that are well understood); and (b) to change the references from informative to normative (because if you don't want to hide the message or refuse to serve it up, you do need to go look at these documents to see how to do downgrading safely). Russ and Benoit have me pretty convinced that this is the appropriate way to go; it makes it clear that these are the well-vetted options, but leaves the out clause (via the SHOULD) that there are other potential algorithms that you could come up with if you knew what you were doing. Does anyone object to going forward this way? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From duerst@it.aoyama.ac.jp Fri Oct 5 03:11:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C390421F861B for ; Fri, 5 Oct 2012 03:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.054 X-Spam-Level: X-Spam-Status: No, score=-101.054 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHBGO0N0sXqF for ; Fri, 5 Oct 2012 03:11:22 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6921F8604 for ; Fri, 5 Oct 2012 03:11:17 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q95AB6b2008438 for ; Fri, 5 Oct 2012 19:11:06 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2ff0_424f_f9c487ca_0ed4_11e2_8ce6_001d096c5782; Fri, 05 Oct 2012 19:11:05 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38230) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 5 Oct 2012 19:11:04 +0900 Message-ID: <506EB22A.6020906@it.aoyama.ac.jp> Date: Fri, 05 Oct 2012 19:10:50 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Pete Resnick References: <506E009A.5040102@qti.qualcomm.com> In-Reply-To: <506E009A.5040102@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] POP/IMAP documents: IESG Evaluation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:11:22 -0000 Just to make sure we have finally move ahead: I don't object to your proposal at all. If Russ and Benoit are going to be happy that way, that's great, and I think it says all we want to say. Regards, Martin. P.S.: I really like the congestion control example. Who came up with that? On 2012/10/05 6:33, Pete Resnick wrote: > Folks, > > There are a couple of outstanding DISCUSS positions from Russ and Benoit > during the IESG Evaluation on the IMAP/POP documents. I think I > understand the issue, and after discussion today I think we have an easy > solution, but I want to confirm with the WG that this still represents > our consensus. > > The issue is with the status of the downgrade documents and how we refer > to them. I believe the consensus of the WG was that we want to > standardize the downgrade documents because they are the result of > extensive technical review, with the outcome being safe and appropriate > ways to do downgrading. In particular, if you are going to downgrade, > the potential for doing something that does damage (by making a > replyable From address that leaks onto the net, or leaking information > that becomes a vector of attack) is high enough that you had better know > what you're doing when you downgrade. So we decided standards track was > appropriate, and I agree. However, it is also perfectly clear that there > are other ways you could conceivably downgrade in a safe manner, these > were just two ways to do it that got proper vetting. So we didn't want > to make either of these REQUIRED for the POP or IMAP documents. > > However, this left Russ an Benoit a bit confused: If there was the > potential for damage if you chose the wrong one, shouldn't these somehow > be required? And if not, aren't they just examples that could just be > informational documents? After quite a bit of discussion, I think I (and > Barry) now understand the issues, and it mostly comes down to how we > refer to the two documents. > > An analogy that helped during our discussion in the IESG was TCP > congestion control: Congestion control is much the same in the sense > that the receiver can't really tell which congestion control algorithm > the sender used, and there are likely many ways to set timers and other > parameters and still get it right, but if the sender does it wrong, bad > things happen. However, it is also clear that the defined ways of doing > congestion control are well understood and tested, and it behooves you > to use the currently defined ones unless you really know what you are > doing. They aren't just examples; getting this stuff right is hard, and > you should trust us that we've got the right algorithm. > > So, the suggested change to the EAI documents is (a) to add language to > both 5721bis and 5738bis that says that *if* you're going to do > downgrading, you SHOULD implement one of the algorithms in > popimap-downgrade or simpledowngrade (perhaps with a specific line that > says, "This stuff is hard to get right, and these two standards track > documents are two ways that we worked out that are well understood); and > (b) to change the references from informative to normative (because if > you don't want to hide the message or refuse to serve it up, you do need > to go look at these documents to see how to do downgrading safely). Russ > and Benoit have me pretty convinced that this is the appropriate way to > go; it makes it clear that these are the well-vetted options, but leaves > the out clause (via the SHOULD) that there are other potential > algorithms that you could come up with if you knew what you were doing. > > Does anyone object to going forward this way? > > pr > From alexey.melnikov@isode.com Fri Oct 5 03:58:06 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4321F861E for ; Fri, 5 Oct 2012 03:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsoHeNCneFuz for ; Fri, 5 Oct 2012 03:58:06 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9B21F8648 for ; Fri, 5 Oct 2012 03:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349434684; d=isode.com; s=selector; i=@isode.com; bh=XmfgYcIR/ktTcKtj3o2r8aamjcWx3XBtxSqc0pYwdXQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ODqwt5ucBhOoRyT+gJa8V9nyq5fgUjy7laMk+GjXTaBLr+1TgnCyp3TX92K1kR+Lak1iPS ajKlWiODJJd9BO8LQYFeoq4kFHVaWdyemUSmc2gX3eLfTuT0eGoyo3DPCriGe/4T7F6Uoj pmV7dLCOETh9tbJTMhE1XTkcLxgbYGw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Oct 2012 11:58:04 +0100 Message-ID: <506EBD44.7040502@isode.com> Date: Fri, 05 Oct 2012 11:58:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Pete Resnick References: <506E009A.5040102@qti.qualcomm.com> In-Reply-To: <506E009A.5040102@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] POP/IMAP documents: IESG Evaluation X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:58:07 -0000 On 04/10/2012 22:33, Pete Resnick wrote: > Folks, > > There are a couple of outstanding DISCUSS positions from Russ and > Benoit during the IESG Evaluation on the IMAP/POP documents. I think I > understand the issue, and after discussion today I think we have an > easy solution, but I want to confirm with the WG that this still > represents our consensus. > > The issue is with the status of the downgrade documents and how we > refer to them. I believe the consensus of the WG was that we want to > standardize the downgrade documents because they are the result of > extensive technical review, with the outcome being safe and > appropriate ways to do downgrading. In particular, if you are going to > downgrade, the potential for doing something that does damage (by > making a replyable From address that leaks onto the net, or leaking > information that becomes a vector of attack) is high enough that you > had better know what you're doing when you downgrade. So we decided > standards track was appropriate, and I agree. However, it is also > perfectly clear that there are other ways you could conceivably > downgrade in a safe manner, these were just two ways to do it that got > proper vetting. So we didn't want to make either of these REQUIRED for > the POP or IMAP documents. > > However, this left Russ an Benoit a bit confused: If there was the > potential for damage if you chose the wrong one, shouldn't these > somehow be required? And if not, aren't they just examples that could > just be informational documents? After quite a bit of discussion, I > think I (and Barry) now understand the issues, and it mostly comes > down to how we refer to the two documents. > > An analogy that helped during our discussion in the IESG was TCP > congestion control: Congestion control is much the same in the sense > that the receiver can't really tell which congestion control algorithm > the sender used, and there are likely many ways to set timers and > other parameters and still get it right, but if the sender does it > wrong, bad things happen. However, it is also clear that the defined > ways of doing congestion control are well understood and tested, and > it behooves you to use the currently defined ones unless you really > know what you are doing. They aren't just examples; getting this stuff > right is hard, and you should trust us that we've got the right > algorithm. > > So, the suggested change to the EAI documents is (a) to add language > to both 5721bis and 5738bis that says that *if* you're going to do > downgrading, you SHOULD implement one of the algorithms in > popimap-downgrade or simpledowngrade (perhaps with a specific line > that says, "This stuff is hard to get right, and these two standards > track documents are two ways that we worked out that are well > understood); and (b) to change the references from informative to > normative (because if you don't want to hide the message or refuse to > serve it up, you do need to go look at these documents to see how to > do downgrading safely). Russ and Benoit have me pretty convinced that > this is the appropriate way to go; it makes it clear that these are > the well-vetted options, but leaves the out clause (via the SHOULD) > that there are other potential algorithms that you could come up with > if you knew what you were doing. > > Does anyone object to going forward this way? No, this looks sensible to me. From tss@iki.fi Fri Oct 5 09:57:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7B321F87BD for ; Fri, 5 Oct 2012 09:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.41 X-Spam-Level: X-Spam-Status: No, score=-110.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUYnmLuVYXZl for ; Fri, 5 Oct 2012 09:57:02 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id BF42B21F87B0 for ; Fri, 5 Oct 2012 09:57:01 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id BC9B61AE8824; Fri, 5 Oct 2012 19:56:59 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <506DA8AD.3060005@isode.com> Date: Fri, 5 Oct 2012 19:56:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505390CE.8070502@isode.com> <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> <506A0266.80005@isode.com> <29663FDD-D888-4EF8-BCC0-62A9C7A7516C@iki.fi> <506C2FE0.7040009@isode.com> <506DA8AD.3060005@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:57:02 -0000 On 4.10.2012, at 18.18, Alexey Melnikov wrote: >> OK, so maybe something like: >>=20 >> The "UTF8=3DONLY" capability permits an IMAP server to advertise that = it does not support IMAP clients that do not issue ENABLE UTF8=3DONLY. A = client that supports this extension MUST send ENABLE UTF8=3DONLY command = either before login or as the first command in the authenticated state. = The server may otherwise reject all commands or otherwise restrict the = mailboxes visible to the client. >=20 > RFC 5161 says: >=20 > The ENABLE command is only valid in the authenticated state (see > [RFC3501]) Oh, somehow I remembered that it was. Wonder why I've even bothered to = add a dummy ENABLE handler for non-authenticated state (just replies = "ENABLE ignored in non-authenticated state.") > I also think that some useful information was lost during this = rewrite. So how about this: >=20 > OLD: > The "UTF8=3DONLY" capability permits an IMAP server to advertise = that > it does not permit the international mailbox name convention > (modified UTF-7), and also allows all of the capabilities that are > allowed by "UTF8=3DACCEPT" (see Section 4). As this is an = incompatible > change to IMAP, a clear warning is necessary. IMAP clients that = find > implementation of the "UTF8=3DONLY" capability problematic are > encouraged to at least detect the "UTF8=3DONLY" capability and = provide > an informative error message to the end-user. >=20 > NEW: > The "UTF8=3DONLY" capability permits an IMAP server to advertise = that > it does not permit the international mailbox name convention > (modified UTF-7), and also supports all of the functionality that is > allowed by "UTF8=3DACCEPT" (see Section 3 and Section 4). > As this is an incompatible change to IMAP, the server is required > to wait for ENABLE UTF8=3DONLY command before it can start sending > pure UTF-8 mailbox names and non-ASCII messages. In order of > being able to talk to a server advertising "UTF8=3DONLY" the client > needs to send ENABLE UTF8=3DONLY command in the authenticated state > (as per requirements in [RFC5161]). The server may otherwise, > in order to stay compliant with RFC 3501, reject all commands or > otherwise restrict the mailboxes visible to the client. >=20 > IMAP clients that find implementation of the "UTF8=3DONLY" = capability > problematic are encouraged to at least detect the "UTF8=3DONLY" = capability > and provide an informative error message to the end-user. I'm ok with that. (Although I think it could be done with less text, but = I don't really want to suggest such changes :)= From alexey.melnikov@isode.com Sat Oct 20 05:51:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9A21F84DF for ; Sat, 20 Oct 2012 05:51:56 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKSAPRXj0NKW for ; Sat, 20 Oct 2012 05:51:56 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C7BB421F84BB for ; Sat, 20 Oct 2012 05:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1350737514; d=isode.com; s=selector; i=@isode.com; bh=qtdpaOMn0/7Pvalo7hnBWBqkdF10zZI43geVMwSKpzY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ujwlN2wGvM1LdfdXJb7i4ZxE+EuYKK3gTS2zC/EPf56JCW+NfGgwnC+IBRTFcwzXP4a9MZ FwKcDBmrbjj8rtIuIXKI1IeLNK4+I/sl+6cy1R+99BQNVd10kg4lEwisPOr2kXG9KeO1BK KhrIedjRYSNzQg8+zH02woMoavK2G10=; Received: from [172.20.10.2] ((unknown) [212.183.140.23]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 20 Oct 2012 13:51:53 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <5082990C.2090902@isode.com> Date: Sat, 20 Oct 2012 13:29:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <505390CE.8070502@isode.com> <5916632E-D140-44AF-8679-71474DEC49EC@iki.fi> In-Reply-To: <5916632E-D140-44AF-8679-71474DEC49EC@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 12:51:56 -0000 On 15/09/2012 17:35, Timo Sirainen wrote: > Maybe it should also have a sentence about using UTF8 in NAMESPACE reply. It could contain UTF8 prefixes, and also when LANGUAGE extension is enabled the TRANSLATION could contain UTF8. Ok, here is a proposal to address this: In Section 3, add to the end of the 1st paragraph: The "UTF8=ACCEPT" capability indicates that the server supports the ability to open mailboxes containing internationalized messages with SELECT and EXAMINE, and can provide UTF-8 responses to the LIST and LSUB commands. ADD: This capability also affects other IMAP extensions that can return mailbox names or their prefixes, such as NAMESPACE [RFC2342] and ACL [RFC4314] And add [RFC2342] and [RFC4314] to informative references. From internet-drafts@ietf.org Sun Oct 21 18:56:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6E621F8A84; Sun, 21 Oct 2012 18:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0HxGxUULGI6; Sun, 21 Oct 2012 18:56:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEB321F8A59; Sun, 21 Oct 2012 18:56:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022015633.18562.83947.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 18:56:33 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-rfc5721bis-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 01:56:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g Group of the IETF. Title : POP3 Support for UTF-8 Author(s) : Randall Gellens Chris Newman Jiankang Yao Kazunori Fujiwara Filename : draft-ietf-eai-rfc5721bis-08.txt Pages : 14 Date : 2012-10-21 Abstract: This specification extends the Post Office Protocol version 3 (POP3) to support UTF-8 encoded international string in user names, passwords, mail addresses, message headers, and protocol-level textual strings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-rfc5721bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-rfc5721bis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaojk@cnnic.cn Sun Oct 21 20:30:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0021F8A71 for ; Sun, 21 Oct 2012 20:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.405 X-Spam-Level: X-Spam-Status: No, score=-99.405 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecdqwqxFA441 for ; Sun, 21 Oct 2012 20:30:45 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3DAE521F8883 for ; Sun, 21 Oct 2012 20:30:43 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 22 Oct 2012 11:30:36 +0800 Message-ID: <3D0578C5B37849A88BCD4708B75C1938@LENOVO47E041CF> From: "Jiankang YAO" To: "Alexey Melnikov" , "Timo Sirainen" References: <505390CE.8070502@isode.com><5916632E-D140-44AF-8679-71474DEC49EC@iki.fi> <5082990C.2090902@isode.com> Date: Mon, 22 Oct 2012 11:30:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 03:30:45 -0000 DQoNCml0IGlzIGZpbmUgdG8gbWUuDQoNCkppYW5rYW5nIFlhbw0KDQoNCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWxleGV5IE1lbG5pa292IiA8YWxleGV5Lm1lbG5pa292 QGlzb2RlLmNvbT4NClRvOiAiVGltbyBTaXJhaW5lbiIgPHRzc0Bpa2kuZmk+DQpDYzogIklFVEYg RUFJIiA8aW1hQGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMjAsIDIwMTIgODoy OSBQTQ0KU3ViamVjdDogUmU6IFtFQUldIDU3MzhiaXMNCg0KDQo+IE9uIDE1LzA5LzIwMTIgMTc6 MzUsIFRpbW8gU2lyYWluZW4gd3JvdGU6DQo+PiBNYXliZSBpdCBzaG91bGQgYWxzbyBoYXZlIGEg c2VudGVuY2UgYWJvdXQgdXNpbmcgVVRGOCBpbiBOQU1FU1BBQ0UgcmVwbHkuIEl0IGNvdWxkIGNv bnRhaW4gVVRGOCBwcmVmaXhlcywgYW5kIGFsc28gd2hlbiBMQU5HVUFHRSBleHRlbnNpb24gaXMg ZW5hYmxlZCB0aGUgVFJBTlNMQVRJT04gY291bGQgY29udGFpbiBVVEY4Lg0KPiBPaywgaGVyZSBp cyBhIHByb3Bvc2FsIHRvIGFkZHJlc3MgdGhpczoNCj4gDQo+IEluIFNlY3Rpb24gMywgYWRkIHRv IHRoZSBlbmQgb2YgdGhlIDFzdCBwYXJhZ3JhcGg6DQo+IA0KPiAgICBUaGUgIlVURjg9QUNDRVBU IiBjYXBhYmlsaXR5IGluZGljYXRlcyB0aGF0IHRoZSBzZXJ2ZXIgc3VwcG9ydHMgdGhlDQo+ICAg IGFiaWxpdHkgdG8gb3BlbiBtYWlsYm94ZXMgY29udGFpbmluZyBpbnRlcm5hdGlvbmFsaXplZCBt ZXNzYWdlcyB3aXRoDQo+ICAgIFNFTEVDVCBhbmQgRVhBTUlORSwgYW5kIGNhbiBwcm92aWRlIFVU Ri04IHJlc3BvbnNlcyB0byB0aGUgTElTVCBhbmQNCj4gICAgTFNVQiBjb21tYW5kcy4NCj4gDQo+ IEFERDoNCj4gDQo+IFRoaXMgY2FwYWJpbGl0eSBhbHNvIGFmZmVjdHMgb3RoZXIgSU1BUCBleHRl bnNpb25zIHRoYXQgY2FuIHJldHVybiANCj4gbWFpbGJveCBuYW1lcw0KPiBvciB0aGVpciBwcmVm aXhlcywgc3VjaCBhcyBOQU1FU1BBQ0UgW1JGQzIzNDJdIGFuZCBBQ0wgW1JGQzQzMTRdDQo+IA0K PiANCj4gQW5kIGFkZCBbUkZDMjM0Ml0gYW5kIFtSRkM0MzE0XSB0byBpbmZvcm1hdGl2ZSByZWZl cmVuY2VzLg0KPiANCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From internet-drafts@ietf.org Mon Oct 22 02:27:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14421F8922; Mon, 22 Oct 2012 02:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H8lidqRxgrF; Mon, 22 Oct 2012 02:27:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4926E21F89EC; Mon, 22 Oct 2012 02:27:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022092723.9286.47389.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 02:27:23 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-popimap-downgrade-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:27:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g Group of the IETF. Title : Post-delivery Message Downgrading for Internationalized = Email Messages Author(s) : Kazunori Fujiwara Filename : draft-ietf-eai-popimap-downgrade-08.txt Pages : 22 Date : 2012-10-22 Abstract: The Email Address Internationalization (SMTPUTF8) extension to SMTP allows UTF-8 characters in mail header fields. Upgraded POP and IMAP servers support internationalized Email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot deliver Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be in traditional message format. In the process, message elements requiring internationalized treatment are recoded or removed and receivers are able to know that they received messages containing such elements even if they cannot process the internationalized elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-popimap-downgrade-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-popimap-downgrade-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 06:42:30 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E421D21F8BD6; Mon, 22 Oct 2012 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7dHl6U-Dmv1; Mon, 22 Oct 2012 06:42:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719B121F8BD7; Mon, 22 Oct 2012 06:42:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022134229.11656.37467.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 06:42:29 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-5738bis-10.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:42:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g Group of the IETF. Title : IMAP Support for UTF-8 Author(s) : Pete Resnick Chris Newman Sean Shen Filename : draft-ietf-eai-5738bis-10.txt Pages : 12 Date : 2012-10-22 Abstract: This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. This specification replaces RFC 5738. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-5738bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-5738bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-5738bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From klensin@jck.com Mon Oct 22 10:10:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE411E80A5 for ; Mon, 22 Oct 2012 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOjeWxzCaC-R for ; Mon, 22 Oct 2012 10:10:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 56E4511E80C5 for ; Mon, 22 Oct 2012 10:10:47 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TQLWY-0008lP-Lo for ima@ietf.org; Mon, 22 Oct 2012 13:10:46 -0400 Date: Mon, 22 Oct 2012 13:10:41 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:10:51 -0000 Hi. We are still going around in circles with the IMAP document (5738bis) relative to: (1) Exactly what a server announcement of UTF8=ONLY means and whether it adds sufficient value to justify the distinction between it and UTF8=ACCEPT. (2) What the distinction is between client-side "ENABLE UTF8=ACCEPT" and "ENABLE UTF8=ONLY" and whether they are actually different in practice. If they are not, would we like to eliminate them in favor of a single "ENABLE UTF8" (even if the server announcements remain separate)? If we retain both, we need to provide a clear explanation as to when each should be used (e.g., whether they can be used only in conjunction with server capability announcements of "...ACCEPT" or "...ONLY" respectively? Because these are significant issues that require WG consensus, not just matters of editorial tuning, and it is now clear that we are not going to be finished in under two weeks (as I/we had hoped), we have scheduled an IETF 85 meeting slot at 9AM on Friday 9 November. The slot is two hours long, but I don't expect/ intend that we will meet for more than one. The people who have been most engaged in the discussion so far will be meeting earlier in the week and will have a clear summary and, we hope, a proposal ready for Friday morning and circulated to this mailing list earlier. Sorry about this although it may be worth noting that more checking and discussion of the document in the WG might have prevented the problem. best, john ---------- Forwarded Message ---------- Date: Monday, October 22, 2012 09:31 -0700 From: "\"IETF Secretariat\"" To: wlo@amsl.com Cc: eai-ads@tools.ietf.org, john-ietf@jck.com, jyee@afilias.info, wlo@amsl.com Subject: eai - Requested session has been scheduled for IETF 85 Dear Wanda Lo, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. eai Session 1 (2:00:00) Friday, Morning Session I 0900-1100 Room Name: Room 209 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 [...] ---------- End Forwarded Message ---------- From yaojk@cnnic.cn Mon Oct 22 19:41:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80C11F0429 for ; Mon, 22 Oct 2012 19:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.251 X-Spam-Level: X-Spam-Status: No, score=-100.251 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+TnbVdU1NKL for ; Mon, 22 Oct 2012 19:41:48 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 78B0A21F8566 for ; Mon, 22 Oct 2012 19:41:44 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 23 Oct 2012 10:41:36 +0800 Message-ID: <91B99FB44A5C41348C9B7C5C901E62A6@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> Date: Tue, 23 Oct 2012 10:41:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:41:48 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDIzLCAyMDEyIDE6MTAgQU0NClN1YmplY3Q6IFtFQUldIEZXRDogZWFpIC0gUmVxdWVzdGVk IHNlc3Npb24gaGFzIGJlZW4gc2NoZWR1bGVkIGZvciBJRVRGIDg1DQoNCg0KPiBIaS4NCj4gDQo+ IFdlIGFyZSBzdGlsbCBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyB3aXRoIHRoZSBJTUFQIGRvY3Vt ZW50DQo+ICg1NzM4YmlzKSByZWxhdGl2ZSB0bzoNCj4gDQo+ICgxKSBFeGFjdGx5IHdoYXQgYSBz ZXJ2ZXIgYW5ub3VuY2VtZW50IG9mIFVURjg9T05MWSBtZWFucyBhbmQNCj4gd2hldGhlciBpdCBh ZGRzIHN1ZmZpY2llbnQgdmFsdWUgdG8ganVzdGlmeSB0aGUgZGlzdGluY3Rpb24NCj4gYmV0d2Vl biBpdCBhbmQgVVRGOD1BQ0NFUFQuDQo+IA0KPiAoMikgV2hhdCB0aGUgZGlzdGluY3Rpb24gaXMg YmV0d2VlbiBjbGllbnQtc2lkZSAiRU5BQkxFDQo+IFVURjg9QUNDRVBUIiBhbmQgIkVOQUJMRSBV VEY4PU9OTFkiIGFuZCB3aGV0aGVyIHRoZXkgYXJlDQo+IGFjdHVhbGx5IGRpZmZlcmVudCBpbiBw cmFjdGljZS4gIElmIHRoZXkgYXJlIG5vdCwgd291bGQgd2UgbGlrZQ0KPiB0byBlbGltaW5hdGUg dGhlbSBpbiBmYXZvciBvZiBhIHNpbmdsZSAiRU5BQkxFIFVURjgiIChldmVuIGlmDQo+IHRoZSBz ZXJ2ZXIgYW5ub3VuY2VtZW50cyByZW1haW4gc2VwYXJhdGUpPyAgIElmIHdlIHJldGFpbiBib3Ro LA0KPiB3ZSBuZWVkIHRvIHByb3ZpZGUgYSBjbGVhciBleHBsYW5hdGlvbiBhcyB0byB3aGVuIGVh Y2ggc2hvdWxkIGJlDQo+IHVzZWQgKGUuZy4sIHdoZXRoZXIgdGhleSBjYW4gYmUgdXNlZCBvbmx5 IGluIGNvbmp1bmN0aW9uIHdpdGgNCj4gc2VydmVyIGNhcGFiaWxpdHkgYW5ub3VuY2VtZW50cyBv ZiAiLi4uQUNDRVBUIiBvciAiLi4uT05MWSINCj4gcmVzcGVjdGl2ZWx5Pw0KPiANCg0KVVRGOD1B Q0NFUFQ6IGFjY2VwdHMgVVRGLTggYW5kIG90aGVyIGVuY29kaW5nczsgSXQgbWVhbnMgdGhhdCB0 aGUgc2VydmVyIGFjY2VwdCBVVEYtOCwgYnV0IG5vdCByZWZ1c2VzIG90aGVyIGVuY29kaW5nLg0K VVRGOD1PTkxZOiBvbmx5IGFjY2VwdHMgVVRGLTguIEl0IG1lYW5zIHRoYXQgdGhlIHNlcnZlciBv bmx5IGFjY2VwdHMgVVRGLTgsIGFuZCByZWZ1c2VzIG90aGVyIGVuY29kaW5nLg0KDQpUaGUgZXhw bGFpbmF0aW9uIGFib3ZlIGlzIHJlYXNvbmFibGU/DQoNCklmIHllcywgSSB0aGluayB0aGF0IHRo ZSBtZWFuaW5nIGhhcyBiZWVuIGV4cHJlc3NlZCBpbiB0aGUgY3VycmVudCBkcmFmdC4NCg0KDQpK aWFua2FuZyBZYW8NCg0KPiBCZWNhdXNlIHRoZXNlIGFyZSBzaWduaWZpY2FudCBpc3N1ZXMgdGhh dCByZXF1aXJlIFdHIGNvbnNlbnN1cywNCj4gbm90IGp1c3QgbWF0dGVycyBvZiBlZGl0b3JpYWwg dHVuaW5nLCBhbmQgaXQgaXMgbm93IGNsZWFyIHRoYXQNCj4gd2UgYXJlIG5vdCBnb2luZyB0byBi ZSBmaW5pc2hlZCBpbiB1bmRlciB0d28gd2Vla3MgKGFzIEkvd2UgaGFkDQo+IGhvcGVkKSwgd2Ug aGF2ZSBzY2hlZHVsZWQgYW4gSUVURiA4NSBtZWV0aW5nIHNsb3QgYXQgOUFNIG9uDQo+IEZyaWRh eSA5IE5vdmVtYmVyLiAgVGhlIHNsb3QgaXMgdHdvIGhvdXJzIGxvbmcsIGJ1dCBJIGRvbid0DQo+ IGV4cGVjdC8gaW50ZW5kIHRoYXQgd2Ugd2lsbCBtZWV0IGZvciBtb3JlIHRoYW4gb25lLg0KPiAN Cj4gVGhlIHBlb3BsZSB3aG8gaGF2ZSBiZWVuIG1vc3QgZW5nYWdlZCBpbiB0aGUgZGlzY3Vzc2lv biBzbyBmYXINCj4gd2lsbCBiZSBtZWV0aW5nIGVhcmxpZXIgaW4gdGhlIHdlZWsgYW5kIHdpbGwg aGF2ZSBhIGNsZWFyDQo+IHN1bW1hcnkgYW5kLCB3ZSBob3BlLCBhIHByb3Bvc2FsIHJlYWR5IGZv ciBGcmlkYXkgbW9ybmluZyBhbmQNCj4gY2lyY3VsYXRlZCB0byB0aGlzIG1haWxpbmcgbGlzdCBl YXJsaWVyLg0KPiANCj4gU29ycnkgYWJvdXQgdGhpcyBhbHRob3VnaCBpdCBtYXkgYmUgd29ydGgg bm90aW5nIHRoYXQgbW9yZQ0KPiBjaGVja2luZyBhbmQgZGlzY3Vzc2lvbiBvZiB0aGUgZG9jdW1l bnQgaW4gdGhlIFdHIG1pZ2h0IGhhdmUNCj4gcHJldmVudGVkIHRoZSBwcm9ibGVtLg0KPiANCj4g YmVzdCwNCj4gICBqb2huDQo+IA0KPiANCj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAt LS0tLS0tLS0tDQo+IERhdGU6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiAwOTozMSAtMDcwMA0K PiBGcm9tOiAiXCJJRVRGIFNlY3JldGFyaWF0XCIiIDxhZ2VuZGFAaWV0Zi5vcmc+DQo+IFRvOiB3 bG9AYW1zbC5jb20NCj4gQ2M6IGVhaS1hZHNAdG9vbHMuaWV0Zi5vcmcsIGpvaG4taWV0ZkBqY2su Y29tLA0KPiBqeWVlQGFmaWxpYXMuaW5mbywgd2xvQGFtc2wuY29tDQo+IFN1YmplY3Q6IGVhaSAt IFJlcXVlc3RlZCBzZXNzaW9uIGhhcyBiZWVuIHNjaGVkdWxlZCBmb3IgSUVURiA4NQ0KPiANCj4g RGVhciBXYW5kYSBMbywNCj4gDQo+IFRoZSBzZXNzaW9uKHMpIHRoYXQgeW91IGhhdmUgcmVxdWVz dGVkIGhhdmUgYmVlbiBzY2hlZHVsZWQuDQo+IEJlbG93IGlzIHRoZSBzY2hlZHVsZWQgc2Vzc2lv biBpbmZvcm1hdGlvbiBmb2xsb3dlZCBieQ0KPiB0aGUgb3JpZ2luYWwgcmVxdWVzdC4gDQo+IA0K PiBlYWkgU2Vzc2lvbiAxICgyOjAwOjAwKQ0KPiAgICBGcmlkYXksIE1vcm5pbmcgU2Vzc2lvbiBJ IDA5MDAtMTEwMA0KPiAgICBSb29tIE5hbWU6IFJvb20gMjA5DQo+ICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICANCj4gDQo+IA0KPiBSZXF1ZXN0 IEluZm9ybWF0aW9uOg0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBXb3JraW5nIEdyb3VwIE5hbWU6IA0KPiBBcmVh IE5hbWU6IA0KPiBTZXNzaW9uIFJlcXVlc3RlcjogDQo+IA0KPiBOdW1iZXIgb2YgU2Vzc2lvbnM6 IDENCj4gTGVuZ3RoIG9mIFNlc3Npb24ocyk6ICAyIEhvdXJzDQo+IE51bWJlciBvZiBBdHRlbmRl ZXM6IDUwDQo+IA0KPiBbLi4uXQ0KPiANCj4gLS0tLS0tLS0tLSBFbmQgRm9yd2FyZGVkIE1lc3Nh Z2UgLS0tLS0tLS0tLQ0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= From tss@iki.fi Tue Oct 23 08:03:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0060711E80A6 for ; Tue, 23 Oct 2012 08:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdgcJQojj4Ag for ; Tue, 23 Oct 2012 08:03:14 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 27CF311E80A5 for ; Tue, 23 Oct 2012 08:03:12 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 25E171AE8769 for ; Tue, 23 Oct 2012 18:03:11 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> Date: Tue, 23 Oct 2012 18:03:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> To: IETF EAI X-Mailer: Apple Mail (2.1085) Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:03:15 -0000 On 22.10.2012, at 20.10, John C Klensin wrote: > We are still going around in circles with the IMAP document > (5738bis) relative to: >=20 > (1) Exactly what a server announcement of UTF8=3DONLY means and > whether it adds sufficient value to justify the distinction > between it and UTF8=3DACCEPT. I'm hoping to avoid implementing message downgrading on the IMAP server = side. So I'm thinking about allowing users to permanently switch to = UTF8=3DONLY mode (I guess there should also be some way to switch back). = So I think it's a good idea to tell clients explicitly that there are = UTF8 messages and no downgrading is possible. To me it seems that = UTF8=3DACCEPT allows at least potentially downgrading while UTF8=3DONLY = doesn't. So keeping them distinct would be nice. This also reminds me that I think it would be a good idea to mention = explicitly in the RFC that the UTF8=3D* capabilities (like all other = capabilities) may be different for different users: * OK [CAPABILITY IMAP4rev1] a LOGIN user pass a OK [CAPABILITY IMAP4rev1 UTF8=3DONLY] Logged in. > (2) What the distinction is between client-side "ENABLE > UTF8=3DACCEPT" and "ENABLE UTF8=3DONLY" and whether they are > actually different in practice. =20 I don't think there is any difference. > If they are not, would we like > to eliminate them in favor of a single "ENABLE UTF8" (even if > the server announcements remain separate)? If we retain both, > we need to provide a clear explanation as to when each should be > used (e.g., whether they can be used only in conjunction with > server capability announcements of "...ACCEPT" or "...ONLY" > respectively? I think ENABLE UTF8 would be clearer, but I don't really care much. > Because these are significant issues that require WG consensus, > not just matters of editorial tuning, and it is now clear that > we are not going to be finished in under two weeks (as I/we had > hoped), we have scheduled an IETF 85 meeting slot at 9AM on > Friday 9 November. The slot is two hours long, but I don't > expect/ intend that we will meet for more than one. I'll try to be in Jabber. From tss@iki.fi Tue Oct 23 08:18:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A592721F869E for ; Tue, 23 Oct 2012 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQlD6ss0utTJ for ; Tue, 23 Oct 2012 08:18:42 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28A21F8694 for ; Tue, 23 Oct 2012 08:18:42 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 23B751AE8769 for ; Tue, 23 Oct 2012 18:18:41 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <20121022015633.18562.83947.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2012 18:18:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6CBA6F4D-F234-4476-AF35-7F7632F50AE4@iki.fi> References: <20121022015633.18562.83947.idtracker@ietfa.amsl.com> To: IETF EAI X-Mailer: Apple Mail (2.1085) Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5721bis-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:18:42 -0000 There's quite a lot of text in section 2.1 paragraphs 2 and 5 saying the = same thing twice (about handling UTF8 mails for non-UTF8 client). = Otherwise looks ok to me. From yaojk@cnnic.cn Tue Oct 23 18:41:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25EF11E815C for ; Tue, 23 Oct 2012 18:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.35 X-Spam-Level: X-Spam-Status: No, score=-100.35 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsvqVFG5IINa for ; Tue, 23 Oct 2012 18:41:01 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 89DF011E8149 for ; Tue, 23 Oct 2012 18:40:58 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 24 Oct 2012 09:40:47 +0800 Message-ID: From: "Jiankang YAO" To: "Timo Sirainen" , "IETF EAI" References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> Date: Wed, 24 Oct 2012 09:40:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 01:41:01 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRpbW8gU2lyYWluZW4iIDx0 c3NAaWtpLmZpPg0KVG86ICJJRVRGIEVBSSIgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMjMsIDIwMTIgMTE6MDMgUE0NClN1YmplY3Q6IFJlOiBbRUFJXSBGV0Q6IGVhaSAt IFJlcXVlc3RlZCBzZXNzaW9uIGhhcyBiZWVuIHNjaGVkdWxlZCBmb3IgSUVURjg1DQoNCg0KPiBP biAyMi4xMC4yMDEyLCBhdCAyMC4xMCwgSm9obiBDIEtsZW5zaW4gd3JvdGU6DQo+IA0KPj4gV2Ug YXJlIHN0aWxsIGdvaW5nIGFyb3VuZCBpbiBjaXJjbGVzIHdpdGggdGhlIElNQVAgZG9jdW1lbnQN Cj4+ICg1NzM4YmlzKSByZWxhdGl2ZSB0bzoNCj4+IA0KPj4gKDEpIEV4YWN0bHkgd2hhdCBhIHNl cnZlciBhbm5vdW5jZW1lbnQgb2YgVVRGOD1PTkxZIG1lYW5zIGFuZA0KPj4gd2hldGhlciBpdCBh ZGRzIHN1ZmZpY2llbnQgdmFsdWUgdG8ganVzdGlmeSB0aGUgZGlzdGluY3Rpb24NCj4+IGJldHdl ZW4gaXQgYW5kIFVURjg9QUNDRVBULg0KPiANCj4gSSdtIGhvcGluZyB0byBhdm9pZCBpbXBsZW1l bnRpbmcgbWVzc2FnZSBkb3duZ3JhZGluZyBvbiB0aGUgSU1BUCBzZXJ2ZXIgc2lkZS4NCj4NCg0K VGhlcmUgaGFkIGEgamFiYmVyIG1lZXRpbmcgaW4gTWF5LiBUaGUgY29uc2Vuc3VzIG9yIHN1bW1h cnkgZm9yIHRoaXMgbWVldGluZyBpcyBoZXJlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9pbWEvY3VycmVudC9tc2cwNDgyMC5odG1sIC4gSXQgZGVjaWRlZCB0aGF0IGRvd25n cmFkaW5nIGlzIHN0bGwga2VwdCBpbiB0aGUgZHJhZnQgYWZ0ZXIgcmV2aXNpbmcuDQoNCklmIGRv d25ncmFkaW5nIGlzIHN0aWxsIHRoZXJlLCBVVEYtOD1PTkxZIG1ha2VzIHRyYW5zaXRpb24gc21v b3RoIGFzIGl0IGlzIHNhaWQgaW4gdGhlIGRyYWZ0J3MgYXBwZW5kaXggIlRoZSAiVVRGOD1PTkxZ IiBtZWNoYW5pc20gc2ltcGxpZmllcyBkaWFnbm9zaXMgb2YgaW50ZXJvcGVyYWJpbGl0eSAgcHJv YmxlbXMgd2hlbiBsZWdhY3kgc3VwcG9ydCBnb2VzIGF3YXkuICINCg0KSmlhbmthbmcgWWFvDQoN Cj4NCj4gU28gSSdtIHRoaW5raW5nIGFib3V0IGFsbG93aW5nIHVzZXJzIHRvIHBlcm1hbmVudGx5 IHN3aXRjaCB0byBVVEY4PU9OTFkgbW9kZSAoSSBndWVzcyB0aGVyZSBzaG91bGQgYWxzbyBiZSBz b21lIHdheSB0byA+c3dpdGNoIGJhY2spLiBTbyBJIHRoaW5rIGl0J3MgYSBnb29kIGlkZWEgdG8g dGVsbCBjbGllbnRzIGV4cGxpY2l0bHkgdGhhdCB0aGVyZSBhcmUgVVRGOCBtZXNzYWdlcyBhbmQg bm8gZG93bmdyYWRpbmcgaXMgcG9zc2libGUuID5UbyBtZSBpdCBzZWVtcyB0aGF0IFVURjg9QUND RVBUIGFsbG93cyBhdCBsZWFzdCBwb3RlbnRpYWxseSBkb3duZ3JhZGluZyB3aGlsZSBVVEY4PU9O TFkgZG9lc24ndC4gU28ga2VlcGluZyB0aGVtID5kaXN0aW5jdCB3b3VsZCBiZSBuaWNlLg0KPiAN Cj4gVGhpcyBhbHNvIHJlbWluZHMgbWUgdGhhdCBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgZ29vZCBp ZGVhIHRvIG1lbnRpb24gZXhwbGljaXRseSBpbiB0aGUgUkZDIHRoYXQgdGhlIFVURjg9KiBjYXBh YmlsaXRpZXMgKGxpa2UgYWxsIG90aGVyIGNhcGFiaWxpdGllcykgbWF5IGJlIGRpZmZlcmVudCBm b3IgZGlmZmVyZW50IHVzZXJzOg0KPiANCj4gKiBPSyBbQ0FQQUJJTElUWSBJTUFQNHJldjFdDQo+ IGEgTE9HSU4gdXNlciBwYXNzDQo+IGEgT0sgW0NBUEFCSUxJVFkgSU1BUDRyZXYxIFVURjg9T05M WV0gTG9nZ2VkIGluLg0KPiANCj4+ICgyKSBXaGF0IHRoZSBkaXN0aW5jdGlvbiBpcyBiZXR3ZWVu IGNsaWVudC1zaWRlICJFTkFCTEUNCj4+IFVURjg9QUNDRVBUIiBhbmQgIkVOQUJMRSBVVEY4PU9O TFkiIGFuZCB3aGV0aGVyIHRoZXkgYXJlDQo+PiBhY3R1YWxseSBkaWZmZXJlbnQgaW4gcHJhY3Rp Y2UuICANCj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IGRpZmZlcmVuY2UuDQo+IA0K Pj4gSWYgdGhleSBhcmUgbm90LCB3b3VsZCB3ZSBsaWtlDQo+PiB0byBlbGltaW5hdGUgdGhlbSBp biBmYXZvciBvZiBhIHNpbmdsZSAiRU5BQkxFIFVURjgiIChldmVuIGlmDQo+PiB0aGUgc2VydmVy IGFubm91bmNlbWVudHMgcmVtYWluIHNlcGFyYXRlKT8gICBJZiB3ZSByZXRhaW4gYm90aCwNCj4+ IHdlIG5lZWQgdG8gcHJvdmlkZSBhIGNsZWFyIGV4cGxhbmF0aW9uIGFzIHRvIHdoZW4gZWFjaCBz aG91bGQgYmUNCj4+IHVzZWQgKGUuZy4sIHdoZXRoZXIgdGhleSBjYW4gYmUgdXNlZCBvbmx5IGlu IGNvbmp1bmN0aW9uIHdpdGgNCj4+IHNlcnZlciBjYXBhYmlsaXR5IGFubm91bmNlbWVudHMgb2Yg Ii4uLkFDQ0VQVCIgb3IgIi4uLk9OTFkiDQo+PiByZXNwZWN0aXZlbHk/DQo+IA0KPiBJIHRoaW5r IEVOQUJMRSBVVEY4IHdvdWxkIGJlIGNsZWFyZXIsIGJ1dCBJIGRvbid0IHJlYWxseSBjYXJlIG11 Y2guDQo+IA0KPj4gQmVjYXVzZSB0aGVzZSBhcmUgc2lnbmlmaWNhbnQgaXNzdWVzIHRoYXQgcmVx dWlyZSBXRyBjb25zZW5zdXMsDQo+PiBub3QganVzdCBtYXR0ZXJzIG9mIGVkaXRvcmlhbCB0dW5p bmcsIGFuZCBpdCBpcyBub3cgY2xlYXIgdGhhdA0KPj4gd2UgYXJlIG5vdCBnb2luZyB0byBiZSBm aW5pc2hlZCBpbiB1bmRlciB0d28gd2Vla3MgKGFzIEkvd2UgaGFkDQo+PiBob3BlZCksIHdlIGhh dmUgc2NoZWR1bGVkIGFuIElFVEYgODUgbWVldGluZyBzbG90IGF0IDlBTSBvbg0KPj4gRnJpZGF5 IDkgTm92ZW1iZXIuICBUaGUgc2xvdCBpcyB0d28gaG91cnMgbG9uZywgYnV0IEkgZG9uJ3QNCj4+ IGV4cGVjdC8gaW50ZW5kIHRoYXQgd2Ugd2lsbCBtZWV0IGZvciBtb3JlIHRoYW4gb25lLg0KPiAN Cj4gSSdsbCB0cnkgdG8gYmUgaW4gSmFiYmVyLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= From tss@iki.fi Tue Oct 23 22:56:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BBD21F8D30 for ; Tue, 23 Oct 2012 22:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.447 X-Spam-Level: X-Spam-Status: No, score=-110.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3e1mLV2cOYE for ; Tue, 23 Oct 2012 22:56:52 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3A21F8D2F for ; Tue, 23 Oct 2012 22:56:51 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 7A1CF1AE876B for ; Wed, 24 Oct 2012 08:56:49 +0300 (EEST) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 08:56:49 +0300 Message-Id: To: IETF EAI Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [EAI] 5738bis / keywords X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 05:56:52 -0000 I'm guessing this could be too late to add now, but I'll mention it = anyway: People have been wanting to use human-readable strings for IMAP keywords = for a while now. But since they're restricted to being atoms, it would = require some kind of encoding to do it. There has been a little bit talk = about what such encoding could be, but nothing really came out of it. = Now would anyway be a nice time to define this easily: UTF8=3D* capability advertised by IMAP server means that the client can = send UTF8 keywords. ENABLE UTF8=3D* by client means that the server can = send UTF8 keywords to client. For ABNF this simply means: flag-keyword =3D atom / quoted Conversion between UTF8 and non-UTF8 keywords could be left unspecified = (they could simply be hidden). From yaojk@cnnic.cn Wed Oct 24 03:52:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AF021F8BCF for ; Wed, 24 Oct 2012 03:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.492 X-Spam-Level: X-Spam-Status: No, score=-99.492 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGARvE+kKNZw for ; Wed, 24 Oct 2012 03:52:52 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 63B1C21F8BB4 for ; Wed, 24 Oct 2012 03:52:50 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 24 Oct 2012 18:52:42 +0800 Message-ID: <590C8F154A974681BA1AF4D0A692ADFF@LENOVO47E041CF> From: "Jiankang YAO" To: "Timo Sirainen" , "IETF EAI" References: Date: Wed, 24 Oct 2012 18:52:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] 5738bis / keywords X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:52:52 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRpbW8gU2lyYWluZW4iIDx0 c3NAaWtpLmZpPg0KVG86ICJJRVRGIEVBSSIgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAyNCwgMjAxMiAxOjU2IFBNDQpTdWJqZWN0OiBbRUFJXSA1NzM4YmlzIC8ga2V5 d29yZHMNCg0KDQo+IEknbSBndWVzc2luZyB0aGlzIGNvdWxkIGJlIHRvbyBsYXRlIHRvIGFkZCBu b3csIGJ1dCBJJ2xsIG1lbnRpb24gaXQgYW55d2F5Og0KPiANCj4gUGVvcGxlIGhhdmUgYmVlbiB3 YW50aW5nIHRvIHVzZSBodW1hbi1yZWFkYWJsZSBzdHJpbmdzIGZvciBJTUFQIGtleXdvcmRzIGZv ciBhIHdoaWxlIG5vdy4gQnV0IHNpbmNlIHRoZXkncmUgcmVzdHJpY3RlZCB0byBiZWluZyBhdG9t cywgaXQgd291bGQgcmVxdWlyZSBzb21lIGtpbmQgb2YgZW5jb2RpbmcgdG8gZG8gaXQuIFRoZXJl IGhhcyBiZWVuIGEgbGl0dGxlIGJpdCB0YWxrIGFib3V0IHdoYXQgc3VjaCBlbmNvZGluZyBjb3Vs ZCBiZSwgYnV0IG5vdGhpbmcgcmVhbGx5IGNhbWUgb3V0IG9mIGl0LiBOb3cgd291bGQgYW55d2F5 IGJlIGEgbmljZSB0aW1lIHRvIGRlZmluZSB0aGlzIGVhc2lseToNCj4gDQo+IFVURjg9KiBjYXBh YmlsaXR5IGFkdmVydGlzZWQgYnkgSU1BUCBzZXJ2ZXIgbWVhbnMgdGhhdCB0aGUgY2xpZW50IGNh biBzZW5kIFVURjgga2V5d29yZHMuIEVOQUJMRSBVVEY4PSogYnkgY2xpZW50IG1lYW5zIHRoYXQg dGhlIHNlcnZlciBjYW4gc2VuZCBVVEY4IGtleXdvcmRzIHRvIGNsaWVudC4gDQo+DQoNCkkgZG8g bm90IHRoaW5rIHRoYXQgVVRGOCBrZXl3b3JkcyBhcmUgZ29vZCBpZGVhcy4NCg0KSSAgY2FuIHJl YWQgVVRGLTggQ2hpbmVzZSBjaGFyYWN0ZXJzLiBCdXQgaWYgdGhlIHNlcnZlciBzZW5kIG1lIHRo ZSBVVEYtOCBSdXNzaWFuIGtleXdvcmRzLCBJIGNhbiBub3QgcmVhZCBpdC4NCg0KSmlhbmthbmcg WWFvDQo+DQo+Rm9yIEFCTkYgdGhpcyBzaW1wbHkgbWVhbnM6DQo+IA0KPiBmbGFnLWtleXdvcmQg ICAgPSBhdG9tIC8gcXVvdGVkDQo+IA0KPiBDb252ZXJzaW9uIGJldHdlZW4gVVRGOCBhbmQgbm9u LVVURjgga2V5d29yZHMgY291bGQgYmUgbGVmdCB1bnNwZWNpZmllZCAodGhleSBjb3VsZCBzaW1w bHkgYmUgaGlkZGVuKS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From tss@iki.fi Wed Oct 24 04:00:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3182B21F8816 for ; Wed, 24 Oct 2012 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.457 X-Spam-Level: X-Spam-Status: No, score=-110.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwR1+L9KYRVW for ; Wed, 24 Oct 2012 04:00:33 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7778621F8727 for ; Wed, 24 Oct 2012 04:00:33 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id DD79B1AE876B; Wed, 24 Oct 2012 14:00:31 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen X-Priority: 3 In-Reply-To: <590C8F154A974681BA1AF4D0A692ADFF@LENOVO47E041CF> Date: Wed, 24 Oct 2012 14:00:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <98F02D8B-EF90-436B-BFC0-A75CF78E1D32@iki.fi> References: <590C8F154A974681BA1AF4D0A692ADFF@LENOVO47E041CF> To: Jiankang YAO X-Mailer: Apple Mail (2.1085) Cc: IETF EAI Subject: Re: [EAI] 5738bis / keywords X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:00:34 -0000 On 24.10.2012, at 13.52, Jiankang YAO wrote: >> I'm guessing this could be too late to add now, but I'll mention it = anyway: >>=20 >> People have been wanting to use human-readable strings for IMAP = keywords for a while now. But since they're restricted to being atoms, = it would require some kind of encoding to do it. There has been a little = bit talk about what such encoding could be, but nothing really came out = of it. Now would anyway be a nice time to define this easily: >>=20 >> UTF8=3D* capability advertised by IMAP server means that the client = can send UTF8 keywords. ENABLE UTF8=3D* by client means that the server = can send UTF8 keywords to client.=20 >>=20 >=20 > I do not think that UTF8 keywords are good ideas. >=20 > I can read UTF-8 Chinese characters. But if the server send me the = UTF-8 Russian keywords, I can not read it. The idea is that keywords could be used as some kind of an alternative = to mailboxes. Their problems would then be exactly the same. The server = wouldn't send you russian keywords if you didn't add such keywords.. From klensin@jck.com Wed Oct 24 04:13:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBF321F8B14 for ; Wed, 24 Oct 2012 04:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooc8akv8FqS6 for ; Wed, 24 Oct 2012 04:13:32 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 411E121F8918 for ; Wed, 24 Oct 2012 04:13:32 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TQyto-000CN2-HY; Wed, 24 Oct 2012 07:13:24 -0400 Date: Wed, 24 Oct 2012 07:13:19 -0400 From: John C Klensin To: Jiankang YAO , Timo Sirainen Message-ID: <887BAB200E7CB530A01DC010@JcK-HP8200.jck.com> In-Reply-To: <590C8F154A974681BA1AF4D0A692ADFF@LENOVO47E041CF> References: <590C8F154A974681BA1AF4D0A692ADFF@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF EAI Subject: Re: [EAI] 5738bis / keywords X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:13:32 -0000 --On Wednesday, October 24, 2012 18:52 +0800 Jiankang YAO wrote: > From: "Timo Sirainen" > To: "IETF EAI" > Sent: Wednesday, October 24, 2012 1:56 PM > Subject: [EAI] 5738bis / keywords > > >> I'm guessing this could be too late to add now, but I'll >> mention it anyway: See separate note. >> People have been wanting to use human-readable strings for >> IMAP keywords for a while now. But since they're restricted >> to being atoms, it would require some kind of encoding to do >> it. There has been a little bit talk about what such encoding >> could be, but nothing really came out of it. Now would anyway >> be a nice time to define this easily: >> >> UTF8=* capability advertised by IMAP server means that the >> client can send UTF8 keywords. ENABLE UTF8=* by client means >> that the server can send UTF8 keywords to client. > I do not think that UTF8 keywords are good ideas. > > I can read UTF-8 Chinese characters. But if the server send > me the UTF-8 Russian keywords, I can not read it. And that is exactly why the base SMTPUTF8/EAI specs carefully avoid allowing non-ASCII header field names and, more generally, why IETF i18n efforts generally have tried to distinguish between "protocol parameters" -- fundamental elements of a protocol and not appropriate for internationalization -- and text fields of various sorts. john From klensin@jck.com Wed Oct 24 04:25:53 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EDF21F8A39 for ; Wed, 24 Oct 2012 04:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m93cyTvdOy8Z for ; Wed, 24 Oct 2012 04:25:53 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CF21F89F4 for ; Wed, 24 Oct 2012 04:25:52 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TQz5s-000CNq-3k; Wed, 24 Oct 2012 07:25:52 -0400 Date: Wed, 24 Oct 2012 07:25:47 -0400 From: John C Klensin To: Timo Sirainen , IETF EAI Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] WG Topics, procedures, and consensus (was: Re: 5738bis / keywords) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:25:53 -0000 --On Wednesday, October 24, 2012 08:56 +0300 Timo Sirainen wrote: > I'm guessing this could be too late to add now, but I'll > mention it anyway: > > People have been wanting to use human-readable strings for > IMAP keywords for a while now. But since they're restricted to > being atoms, it would require some kind of encoding to do it. > There has been a little bit talk about what such encoding > could be, but nothing really came out of it. Now would anyway > be a nice time to define this easily: Timo, at least in my opinion, the one thing the WG has had strong and consistent consensus about (at least since we started on the standards-track work) is that it is important to get this work finished. There are people desperately waiting for the features and groups waiting to deploy code. So far, everyone has been very good about delaying deployment before all details of the standards are settled, but, from various things I've heard and observed, I don't believe we can count on indefinite forbearance. I don't want to be too alarmist about this, but there is a real chance that each week we delay in getting things finished and signed off brings us closer to having to deal with implementations that are incompatible because people didn't (or couldn't) keep waiting. So, unless you can make a case that an issue is really an important showstopper or a problem that was overlooked by the WG, not just design tuning, I'd appreciate it you would just drop it (or accept it as the price of coming in late in the discussion). Let me say that more strongly, with my co-chair hat firmly in place: raising "this could have been done a different way, can we discuss that" or "this would be a nice time to..." questions/issues at this point is off-topic and disruptive and I would encourage people to not post them or respond to them. The UTF8=ONLY question is a good example of something that it still on-topic. It _is_ a showstopper, not because Barry (as AD) and others are questioning the decision but because the text in the document was unclear and subject to multiple interpretations. That problem, which was brought up during Last Call and has to be fixed, opens the question of what the WG really intended (and intends) and, in particular, if "ONLY" is something we still want and need or whether it is now mostly an artifact of a time when drafts of the spec had far more options including the ability to specify whether or not UTF8 was acceptable on a per-command, rather than per-session, basis. Had the document been clear, I would have pushed back against attempts to reopen the design question even if multiple people were having second thoughts about it, especially if the issue had not been brought up during Last Call. So let's please stop this. If you want non-ASCII IMAP keywords, header fields, or anything else, I'd suggest you wait until the IESG signs off on the current documents and then write an "updating" specification and see if you can get consensus for it. It is not a topic on the EAI agenda. For the reason mentioned in my earlier note, I think you will have a lot of trouble getting traction, but that is just a personal opinion. regards, john From ned+ima@mrochek.com Wed Oct 24 08:25:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A07221F88F7 for ; Wed, 24 Oct 2012 08:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRvRXJIU7Q+M for ; Wed, 24 Oct 2012 08:25:25 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9D421F88DF for ; Wed, 24 Oct 2012 08:25:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLSI7Q4V68000MH4@mauve.mrochek.com> for ima@ietf.org; Wed, 24 Oct 2012 08:20:20 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLDMMCPN8G00008S@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 24 Oct 2012 08:20:18 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OLSI7OZK0Q00008S@mauve.mrochek.com> Date: Wed, 24 Oct 2012 08:15:15 -0700 (PDT) In-reply-to: "Your message dated Wed, 24 Oct 2012 08:56:49 +0300" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Timo Sirainen Cc: IETF EAI Subject: Re: [EAI] 5738bis / keywords X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:25:32 -0000 > I'm guessing this could be too late to add now, but I'll mention it anyway: > People have been wanting to use human-readable strings for IMAP keywords for > a while now. But since they're restricted to being atoms, it would require some > kind of encoding to do it. There has been a little bit talk about what such > encoding could be, but nothing really came out of it. I think this is a localization problem, as opposed to an internationalization problem, and solving it by simply allowing the keywords to represent Unicode characters (never mind how) would in fact be the wrong approach. More specifically, keywords represent some sort of state for the message. You want that state expressed in the user's language, whatever that happens to be. This is very different from an address, which should appear appear in the language chosen by it's owner, irrespective of who the reader happens to be. (And yes, this last does create problems, none of which are worth rehashing in this context.) > Now would anyway be a nice time to define this easily: > UTF8=* capability advertised by IMAP server means that the client can send > UTF8 keywords. ENABLE UTF8=* by client means that the server can send UTF8 > keywords to client. For ABNF this simply means: > flag-keyword = atom / quoted > Conversion between UTF8 and non-UTF8 keywords could be left unspecified (they could simply be hidden). I disagree that this is a useful or desirable change. I don't really believe the mapping of keywords to user-visible strings belongs in IMAP at all. But what may be needed is a lightweight way to register the meanings of certain flag names, so that clients can translate them properly. Ned From klensin@jck.com Thu Oct 25 15:20:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FAB21F868C for ; Thu, 25 Oct 2012 15:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coC-Vs+g2x-Q for ; Thu, 25 Oct 2012 15:20:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5005721F85F0 for ; Thu, 25 Oct 2012 15:20:37 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TRVn2-000FWf-Hy for ima@ietf.org; Thu, 25 Oct 2012 18:20:36 -0400 Date: Thu, 25 Oct 2012 18:20:31 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <1E66B3A3311E1986B0EB40EC@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [EAI] Agenda for IETF 85 (Atlanta) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 22:20:38 -0000 Hi. Just to make sure there are no surprises, I've posted an agenda for Atlanta, available at http://tools.ietf.org/wg/eai/agenda?item=agenda-85-eai.html A quick summary, unless people object and propose alternatives, is (1) We have one and only one agenda item, which is straightening out the IMAP UTF8=ONLY and UTF8=ACCEPT situations. People with proposals about what to do are strongly encouraged to get proposed text to this mailing list before IETF starts if you can possibly do so. (2) The agenda contains notes about conditions for adding items to the agenda. Basically, either they need to be on this mailing list before 1600, Atlanta time, on Wednesday 7 Nov with an explanation of why they represent a "showstopper" issue or whoever wants to add them needs to be prepared to make a presentation of under two minutes (no slides) on Friday to convince the people in the room to take it up. We really, really, should not be taking up old issues at this stage unless there is a convincing argument that there is new information and that not revisiting them is would cause major problems. New topics are not on the agenda at all. (3) Schedule 0900-1000: Try to reach resolution on specific proposals and text, than adjorn. 1000-1030: Reserved for a drafting committee if it turns out that we can reach agreement on the proposals but not the text. 1030-1100: Reserved for WG review and discussion of drafting committee output. I can see no alternative to reaching some agreement that gets the POP/IMAP document set approved for publication this calendar year. Whatever conclusion the WG reaches will be posted to the mailing list over the weekend (or sooner), followed by an immediate call for objections. Unless the ADs stop us, the latter will be open only until Monday night. Remember that we have concluded WG Last Call and IETF Last Call on this document and we would not be having this meeting at all if people agreed on what the text means. Those who are not going to be in Atlanta are strongly encouraged to make their positions and desires known on the mailing list well before the meeting, especially of 0900 US EST is a ridiculous time in your time zone. I'd also welcome good summaries of what people think the various options are. They might even be used to shape the final agenda, especially if people agree to them. john From yaojk@cnnic.cn Fri Oct 26 01:43:24 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2DB21F8501 for ; Fri, 26 Oct 2012 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.358 X-Spam-Level: X-Spam-Status: No, score=-100.358 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM6w8ixkDTgl for ; Fri, 26 Oct 2012 01:43:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6EFEF21F8502 for ; Fri, 26 Oct 2012 01:43:23 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 26 Oct 2012 16:43:16 +0800 Message-ID: <29CD3C7D5E3144BCBA78C1F2D84403E4@LENOVO47E041CF> From: "Jiankang YAO" To: "John C Klensin" , References: <1E66B3A3311E1986B0EB40EC@JcK-HP8200.jck.com> Date: Fri, 26 Oct 2012 16:43:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Agenda for IETF 85 (Atlanta) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:43:24 -0000 QmVjYXVzZSBvZiB0aGUgdmlzYSBwcm9ibGVtLCBJIHdpbGwgbm90IGJlIGluIEF0bGFudGEgdGhp cyB0aW1lLg0KSSBzdXBwb3J0IGFueSBkZWNpc2lvbiBtYWRlIGR1cmluZyB0aGUgbWVldGluZy4g SSB3aWxsIGJlIGluIHRoZSBqYWJiZXIuDQoNCkppYW5rYW5nIFlhbw0KDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8a2xlbnNpbkBqY2suY29t Pg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjYsIDIwMTIgNjoy MCBBTQ0KU3ViamVjdDogW0VBSV0gQWdlbmRhIGZvciBJRVRGIDg1IChBdGxhbnRhKQ0KDQoNCj4g SGkuDQo+IA0KPiBKdXN0IHRvIG1ha2Ugc3VyZSB0aGVyZSBhcmUgbm8gc3VycHJpc2VzLCBJJ3Zl IHBvc3RlZCBhbiBhZ2VuZGENCj4gZm9yIEF0bGFudGEsIGF2YWlsYWJsZSBhdA0KPiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvd2cvZWFpL2FnZW5kYT9pdGVtPWFnZW5kYS04NS1lYWkuaHRtbA0KPiAN Cj4gQSBxdWljayBzdW1tYXJ5LCB1bmxlc3MgcGVvcGxlIG9iamVjdCBhbmQgcHJvcG9zZSBhbHRl cm5hdGl2ZXMsDQo+IGlzIA0KPiANCj4gKDEpIFdlIGhhdmUgb25lIGFuZCBvbmx5IG9uZSBhZ2Vu ZGEgaXRlbSwgd2hpY2ggaXMgc3RyYWlnaHRlbmluZw0KPiBvdXQgdGhlIElNQVAgVVRGOD1PTkxZ IGFuZCBVVEY4PUFDQ0VQVCBzaXR1YXRpb25zLiAgUGVvcGxlIHdpdGgNCj4gcHJvcG9zYWxzIGFi b3V0IHdoYXQgdG8gZG8gYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gZ2V0DQo+IHByb3Bvc2Vk IHRleHQgdG8gdGhpcyBtYWlsaW5nIGxpc3QgYmVmb3JlIElFVEYgc3RhcnRzIGlmIHlvdSBjYW4N Cj4gcG9zc2libHkgZG8gc28uDQo+IA0KPiAoMikgVGhlIGFnZW5kYSBjb250YWlucyBub3RlcyBh Ym91dCBjb25kaXRpb25zIGZvciBhZGRpbmcgaXRlbXMNCj4gdG8gdGhlIGFnZW5kYS4gIEJhc2lj YWxseSwgZWl0aGVyIHRoZXkgbmVlZCB0byBiZSBvbiB0aGlzDQo+IG1haWxpbmcgbGlzdCBiZWZv cmUgMTYwMCwgQXRsYW50YSB0aW1lLCBvbiBXZWRuZXNkYXkgNyBOb3Ygd2l0aA0KPiBhbiBleHBs YW5hdGlvbiBvZiB3aHkgdGhleSByZXByZXNlbnQgYSAic2hvd3N0b3BwZXIiIGlzc3VlIG9yDQo+ IHdob2V2ZXIgd2FudHMgdG8gYWRkIHRoZW0gbmVlZHMgdG8gYmUgcHJlcGFyZWQgdG8gbWFrZSBh DQo+IHByZXNlbnRhdGlvbiBvZiB1bmRlciB0d28gbWludXRlcyAobm8gc2xpZGVzKSBvbiBGcmlk YXkgdG8NCj4gY29udmluY2UgdGhlIHBlb3BsZSBpbiB0aGUgcm9vbSB0byB0YWtlIGl0IHVwLg0K PiANCj4gV2UgcmVhbGx5LCByZWFsbHksIHNob3VsZCBub3QgYmUgdGFraW5nIHVwIG9sZCBpc3N1 ZXMgYXQgdGhpcw0KPiBzdGFnZSB1bmxlc3MgdGhlcmUgaXMgYSBjb252aW5jaW5nIGFyZ3VtZW50 IHRoYXQgdGhlcmUgaXMgbmV3DQo+IGluZm9ybWF0aW9uIGFuZCB0aGF0IG5vdCByZXZpc2l0aW5n IHRoZW0gaXMgd291bGQgY2F1c2UgbWFqb3INCj4gcHJvYmxlbXMuICBOZXcgdG9waWNzIGFyZSBu b3Qgb24gdGhlIGFnZW5kYSBhdCBhbGwuDQo+IA0KPiAoMykgU2NoZWR1bGUNCj4gDQo+IDA5MDAt MTAwMDogVHJ5IHRvIHJlYWNoIHJlc29sdXRpb24gb24gc3BlY2lmaWMgcHJvcG9zYWxzIGFuZA0K PiB0ZXh0LCB0aGFuIGFkam9ybi4NCj4gDQo+IDEwMDAtMTAzMDogUmVzZXJ2ZWQgZm9yIGEgZHJh ZnRpbmcgY29tbWl0dGVlIGlmIGl0IHR1cm5zIG91dA0KPiB0aGF0IHdlIGNhbiByZWFjaCBhZ3Jl ZW1lbnQgb24gdGhlIHByb3Bvc2FscyBidXQgbm90IHRoZSB0ZXh0Lg0KPiANCj4gMTAzMC0xMTAw OiBSZXNlcnZlZCBmb3IgV0cgcmV2aWV3IGFuZCBkaXNjdXNzaW9uIG9mIGRyYWZ0aW5nDQo+IGNv bW1pdHRlZSBvdXRwdXQuDQo+IA0KPiBJIGNhbiBzZWUgbm8gYWx0ZXJuYXRpdmUgdG8gcmVhY2hp bmcgc29tZSBhZ3JlZW1lbnQgdGhhdCBnZXRzDQo+IHRoZSBQT1AvSU1BUCBkb2N1bWVudCBzZXQg YXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uIHRoaXMgY2FsZW5kYXINCj4geWVhci4NCj4gDQo+IFdo YXRldmVyIGNvbmNsdXNpb24gdGhlIFdHIHJlYWNoZXMgd2lsbCBiZSBwb3N0ZWQgdG8gdGhlIG1h aWxpbmcNCj4gbGlzdCBvdmVyIHRoZSB3ZWVrZW5kIChvciBzb29uZXIpLCBmb2xsb3dlZCBieSBh biBpbW1lZGlhdGUgY2FsbA0KPiBmb3Igb2JqZWN0aW9ucy4gIFVubGVzcyB0aGUgQURzIHN0b3Ag dXMsIHRoZSBsYXR0ZXIgd2lsbCBiZSBvcGVuDQo+IG9ubHkgdW50aWwgTW9uZGF5IG5pZ2h0LiAg UmVtZW1iZXIgdGhhdCB3ZSBoYXZlIGNvbmNsdWRlZCBXRw0KPiBMYXN0IENhbGwgYW5kIElFVEYg TGFzdCBDYWxsIG9uIHRoaXMgZG9jdW1lbnQgYW5kIHdlIHdvdWxkIG5vdA0KPiBiZSBoYXZpbmcg dGhpcyBtZWV0aW5nIGF0IGFsbCBpZiBwZW9wbGUgYWdyZWVkIG9uIHdoYXQgdGhlIHRleHQNCj4g bWVhbnMuDQo+IA0KPiBUaG9zZSB3aG8gYXJlIG5vdCBnb2luZyB0byBiZSBpbiBBdGxhbnRhIGFy ZSBzdHJvbmdseSBlbmNvdXJhZ2VkDQo+IHRvIG1ha2UgdGhlaXIgcG9zaXRpb25zIGFuZCBkZXNp cmVzIGtub3duIG9uIHRoZSBtYWlsaW5nIGxpc3QNCj4gd2VsbCBiZWZvcmUgdGhlIG1lZXRpbmcs IGVzcGVjaWFsbHkgb2YgMDkwMCBVUyBFU1QgaXMgYQ0KPiByaWRpY3Vsb3VzIHRpbWUgaW4geW91 ciB0aW1lIHpvbmUuDQo+IA0KPiBJJ2QgYWxzbyB3ZWxjb21lIGdvb2Qgc3VtbWFyaWVzIG9mIHdo YXQgcGVvcGxlIHRoaW5rIHRoZSB2YXJpb3VzDQo+IG9wdGlvbnMgYXJlLiAgVGhleSBtaWdodCBl dmVuIGJlIHVzZWQgdG8gc2hhcGUgdGhlIGZpbmFsIGFnZW5kYSwNCj4gZXNwZWNpYWxseSBpZiBw ZW9wbGUgYWdyZWUgdG8gdGhlbS4gDQo+IA0KPiAgIGpvaG4NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4g SU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h From klensin@jck.com Fri Oct 26 07:35:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427B421F85F5 for ; Fri, 26 Oct 2012 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVDj9d-Wd1uB for ; Fri, 26 Oct 2012 07:34:59 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0B921F85C7 for ; Fri, 26 Oct 2012 07:34:59 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TRkzx-000Gk8-7a; Fri, 26 Oct 2012 10:34:57 -0400 Date: Fri, 26 Oct 2012 10:34:52 -0400 From: John C Klensin To: Jiankang YAO , ima@ietf.org Message-ID: <44336ABEA45BC0248948EFBE@JcK-HP8200.jck.com> In-Reply-To: <29CD3C7D5E3144BCBA78C1F2D84403E4@LENOVO47E041CF> References: <1E66B3A3311E1986B0EB40EC@JcK-HP8200.jck.com> <29CD3C7D5E3144BCBA78C1F2D84403E4@LENOVO47E041CF> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Agenda for IETF 85 (Atlanta) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:35:00 -0000 --On Friday, October 26, 2012 16:43 +0800 Jiankang YAO wrote: > Because of the visa problem, I will not be in Atlanta this > time. I support any decision made during the meeting. I will > be in the jabber. Sorry to hear about visa issues. I thought those were getting more under control. See you on the net. best, john From alexey.melnikov@isode.com Tue Oct 30 06:14:28 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8901B21F8507 for ; Tue, 30 Oct 2012 06:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 196FupNxTW0k for ; Tue, 30 Oct 2012 06:14:27 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F05821F84FD for ; Tue, 30 Oct 2012 06:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1351602853; d=isode.com; s=selector; i=@isode.com; bh=KqIcHEtAUp+gJ1Tj2XybSEU6j5y2KtAvCrLlSpulCqQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=p6FcMm4fPZ2h/JU3qFV9Bevo1IL2Z8Opvlik7SiQ8TJhSpJN43vJjSBtyiRtfvddxDbLAC 42fZke/H7hyRwoFu05FXIdqXV+YW6yjFWH3IKSw8Q58XjMzh35hCx0CkI2jLD7JwF1UoEB 8RtgcdjXGzW9I+8+dWKYtHzSIDtVpN4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Oct 2012 13:14:13 +0000 Message-ID: <508FD2C5.2000304@isode.com> Date: Tue, 30 Oct 2012 13:14:45 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> In-Reply-To: <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:14:28 -0000 On 23/10/2012 16:03, Timo Sirainen wrote: > On 22.10.2012, at 20.10, John C Klensin wrote: > >> We are still going around in circles with the IMAP document >> (5738bis) relative to: >> >> (1) Exactly what a server announcement of UTF8=ONLY means and >> whether it adds sufficient value to justify the distinction >> between it and UTF8=ACCEPT. > I'm hoping to avoid implementing message downgrading on the IMAP server side. So I'm thinking about allowing users to permanently switch to UTF8=ONLY mode (I guess there should also be some way to switch back). So I think it's a good idea to tell clients explicitly that there are UTF8 messages and no downgrading is possible. To me it seems that UTF8=ACCEPT allows at least potentially downgrading while UTF8=ONLY doesn't. So keeping them distinct would be nice. I tend to agree. > This also reminds me that I think it would be a good idea to mention explicitly in the RFC that the UTF8=* capabilities (like all other capabilities) may be different for different users: > > * OK [CAPABILITY IMAP4rev1] > a LOGIN user pass > a OK [CAPABILITY IMAP4rev1 UTF8=ONLY] Logged in. Might be a good idea to add a clarifying example. On a somewhat related note, it might be worth actually documenting (in a separate draft) that CAPABILITY answer can change after TLS/authentication. Implementors "know", but as far as I remember RFC 3501 doesn't say that. >> (2) What the distinction is between client-side "ENABLE >> UTF8=ACCEPT" and "ENABLE UTF8=ONLY" and whether they are >> actually different in practice. > I don't think there is any difference. +1. >> If they are not, would we like >> to eliminate them in favor of a single "ENABLE UTF8" (even if >> the server announcements remain separate)? If we retain both, >> we need to provide a clear explanation as to when each should be >> used (e.g., whether they can be used only in conjunction with >> server capability announcements of "...ACCEPT" or "...ONLY" >> respectively? > I think ENABLE UTF8 would be clearer, but I don't really care much. I don't care much either, but "UTF8" is not a registered IMAP capability and ENABLE accept a list of capabilities and not arbitrary tokens. From barryleiba.mailing.lists@gmail.com Tue Oct 30 10:47:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5221F872A for ; Tue, 30 Oct 2012 10:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.977 X-Spam-Level: X-Spam-Status: No, score=-104.977 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIUcVzOsm8z3 for ; Tue, 30 Oct 2012 10:47:15 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C75421F8758 for ; Tue, 30 Oct 2012 10:47:15 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so453731lam.31 for ; Tue, 30 Oct 2012 10:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QztaMwQnOaypO4DGRYLsLUSW9JWioKoyByl6/fvV/j4=; b=JRyyaswr5RAf5qssHZ5YmnHr+LYyvNPo9kVRpTZy8dWjVGJWJ3FqlVUM2hKFSPY7B3 IAqsi4kWqRCIpL0EMdXDo4pSIqjmaiQrYKvZu+IoNwKbEPLor4cx+jndsO05Jlz9LO7h Cz78IqLQvFqEvulb+0HB3Zt8Mj0mcM08kC4IWBT8fYBYmm72/8w7cReAJt329W0f9fVL sD/ezMLestcgQL1b03UYmSLtodZt+tUw3Tx8ObuFZyEwZpu/81oxCWo0wZMgLSjWcSY/ FUA52so82ZpKH1XzjODup3aR02I8qcYdMCPxGnMTvomLdcAfeMMY5tSO28ajr+rWuJa+ 2u5Q== MIME-Version: 1.0 Received: by 10.112.103.234 with SMTP id fz10mr13858055lbb.38.1351619234186; Tue, 30 Oct 2012 10:47:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.99.131 with HTTP; Tue, 30 Oct 2012 10:47:14 -0700 (PDT) In-Reply-To: <508FD2C5.2000304@isode.com> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> Date: Tue, 30 Oct 2012 13:47:14 -0400 X-Google-Sender-Auth: JSuZS8aGAy7hMlvuNNeMWUrd3O4 Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: Timo Sirainen , IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:47:16 -0000 >> I'm hoping to avoid implementing message downgrading on the IMAP server >> side. So I'm thinking about allowing users to permanently switch to >> UTF8=ONLY mode (I guess there should also be some way to switch back). So I >> think it's a good idea to tell clients explicitly that there are UTF8 >> messages and no downgrading is possible. To me it seems that UTF8=ACCEPT >> allows at least potentially downgrading while UTF8=ONLY doesn't. So keeping >> them distinct would be nice. > > I tend to agree. And here's exactly the sort of "UTF8=ONLY is underspecified" thing that I mean: I don't see where the current spec says that UTF8=ONLY doesn't allow downgrading. I don't see where the current spec says anywhere near enough with respect to what UTF8=ONLY changes about how the server works. So, Timo (and Alexey), what makes you think that a server that advertises UTF8=ONLY will never do downgrading? And what makes you think that knowing that would help any clients, given that downgrading is meant for clients that don't understand any of this in the first place? Barry From tss@iki.fi Tue Oct 30 10:57:08 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53D821F8702 for ; Tue, 30 Oct 2012 10:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.855 X-Spam-Level: X-Spam-Status: No, score=-109.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqn9bwguutoY for ; Tue, 30 Oct 2012 10:57:08 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2D21F85A9 for ; Tue, 30 Oct 2012 10:57:07 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id DFED11AE88B2; Tue, 30 Oct 2012 19:57:05 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Tue, 30 Oct 2012 19:57:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> To: Barry Leiba X-Mailer: Apple Mail (2.1085) Cc: IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:57:08 -0000 On 30.10.2012, at 19.47, Barry Leiba wrote: > So, Timo (and Alexey), what makes you think that a server that > advertises UTF8=3DONLY will never do downgrading? =20 I think that's the only reasonable conclusion based on what its = intention was. Although the current draft still explicitly only talks = about the mailbox names being in UTF8. If that truly is the only reason = for the capability, I don't see any point in having it, since the extra = effort to implement mUTF7 is almost nothing. The only complexity I see = is related to downgrading messages. > And what makes you > think that knowing that would help any clients, given that downgrading > is meant for clients that don't understand any of this in the first > place? I'm actually interested in knowing what the current most widely used = clients would do if they saw UTF8 mailbox names and UTF8 headers. I = would actually guess that they would handle them pretty well (except = maybe the UTF8 email addresses). If they did, I think it would be okay = for UTF8=3DONLY server to simply assume that the client is UTF8-capable = and just send it UTF8 data instead of simply giving errors for anything = it tries to do. From tss@iki.fi Tue Oct 30 11:16:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BB321F86ED for ; Tue, 30 Oct 2012 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.227 X-Spam-Level: X-Spam-Status: No, score=-110.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-dGlC9MxLOo for ; Tue, 30 Oct 2012 11:16:38 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id C238121F86E9 for ; Tue, 30 Oct 2012 11:16:37 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id A31121AE8867 for ; Tue, 30 Oct 2012 20:16:36 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: Date: Tue, 30 Oct 2012 20:16:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1993A292-FAAA-4CF3-993B-6BA2C234FADB@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> To: IETF EAI X-Mailer: Apple Mail (2.1085) Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 18:16:39 -0000 On 30.10.2012, at 19.57, Timo Sirainen wrote: >> And what makes you >> think that knowing that would help any clients, given that = downgrading >> is meant for clients that don't understand any of this in the first >> place? >=20 > I'm actually interested in knowing what the current most widely used = clients would do if they saw UTF8 mailbox names and UTF8 headers. I = would actually guess that they would handle them pretty well (except = maybe the UTF8 email addresses). If they did, I think it would be okay = for UTF8=3DONLY server to simply assume that the client is UTF8-capable = and just send it UTF8 data instead of simply giving errors for anything = it tries to do. A quick test shows that Thunderbird and Apple Mail can handle UTF8 = subject/from headers without any problems. Thunderbird was able to list = and subscribe to UTF8 mailbox name correctly. When showing the mailbox = in the actual list, both of them showed the UTF8 characters wrong and = neither could select the mailbox (or in any case showed the mailbox as = empty). If anyone wants to try, I can send IP+user+password for the test server = privately. From klensin@jck.com Tue Oct 30 12:39:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013EC21F8621 for ; Tue, 30 Oct 2012 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRLVNLqCAyn5 for ; Tue, 30 Oct 2012 12:39:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EDB5721F85B8 for ; Tue, 30 Oct 2012 12:39:25 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TTHei-0003Qf-26; Tue, 30 Oct 2012 15:39:20 -0400 Date: Tue, 30 Oct 2012 15:39:15 -0400 From: John C Klensin To: Timo Sirainen , Barry Leiba Message-ID: <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> In-Reply-To: References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:39:27 -0000 --On Tuesday, October 30, 2012 19:57 +0200 Timo Sirainen wrote: >> And what makes you >> think that knowing that would help any clients, given that >> downgrading is meant for clients that don't understand any of >> this in the first place? > > I'm actually interested in knowing what the current most > widely used clients would do if they saw UTF8 mailbox names > and UTF8 headers. I would actually guess that they would > handle them pretty well (except maybe the UTF8 email > addresses). If they did, I think it would be okay for > UTF8=ONLY server to simply assume that the client is > UTF8-capable and just send it UTF8 data instead of simply > giving errors for anything it tries to do. (personal opinion - chair hat off) So you think that it is ok for a server to violate a protocol if only if it announces it first -- in an announcement an un-upgrade client will essentially not see? If so, I want to propose an SMTP extension that is announced in the EHLO response: Extension name: HEADERS-IN-INNER-SLOBBOVIAN-ENGLISH Client command or parameter response: none, client just has to accept it. Inner-Slobbovian-English is just like normal English, except that a few words have their definitions transposed. For example, "From" and "Reply-To" in Inner-Slobbovian-English have the same meanings as "Reply-to" and "From", respectively, in English. As with your tests of just sending UTF-8 header fields to selected clients, this would work most of the time. It would cause havoc that the user would have a lot of trouble diagnosing the rest of the time. Really, I don't want to go there. And I would hope that the IETF community generally, and the IESG in particular, would not approve an extension to a standard whose purpose is to allow the server to unilaterally decide to violate the base protocol. sorry, john From tss@iki.fi Tue Oct 30 14:20:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1121F85FE for ; Tue, 30 Oct 2012 14:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.351 X-Spam-Level: X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+g6UCFMgL9m for ; Tue, 30 Oct 2012 14:20:44 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 56A6721F85FD for ; Tue, 30 Oct 2012 14:20:34 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id E8D231AE8867; Tue, 30 Oct 2012 23:20:32 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> Date: Tue, 30 Oct 2012 23:20:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1085) Cc: Barry Leiba , IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 21:20:45 -0000 On 30.10.2012, at 21.39, John C Klensin wrote: >>> And what makes you >>> think that knowing that would help any clients, given that >>> downgrading is meant for clients that don't understand any of >>> this in the first place? >>=20 >> I'm actually interested in knowing what the current most >> widely used clients would do if they saw UTF8 mailbox names >> and UTF8 headers. I would actually guess that they would >> handle them pretty well (except maybe the UTF8 email >> addresses). If they did, I think it would be okay for >> UTF8=3DONLY server to simply assume that the client is >> UTF8-capable and just send it UTF8 data instead of simply >> giving errors for anything it tries to do. >=20 > (personal opinion - chair hat off) >=20 > So you think that it is ok for a server to violate a protocol if > only if it announces it first Not exactly, not by default. I'm interested in having an option on the = IMAP/POP3 server where the user can decide if he wants to use the "old = email" or the "new UTF8 email". The default would be the "old email". An = UTF8 capable client could enable the "new UTF8 email" for the session. = But also the user (or admin..) could force enabling the "new UTF8 email" = even if the client itself didn't explicitly support it. Pretty much all IMAP clients can already deal with 8bit email headers in = one way or another, because 8bit headers have already existed for a long = time now (hotmail did it for a long time, spam mails still contain it, = and most IMAP servers simply send them to clients). So assuming a user = normally uses UTF8 capable IMAP client, but sometimes (e.g. on a phone) = uses non-UTF8 capable client where the choices are to either a) not be = able to read emails at all or b) violate some RFCs but still read = something that is more or less readable on that client, I think b) isn't = such a bad option. (This is assuming there would be no c) downgrading = option.) So those a) and b) options are the only possibilities of what I think = UTF8=3DONLY could mean. I don't know if it's necessarily a good idea for = it to mean b), but then again it's not very useful for it to mean a) = either. At least with b) the clients can possibly still access some/all = emails, while with a) the user is only getting one error message after = another, maybe never seeing any emails at all. BTW. I heard of test results also for Outlook 2007: Doesn't show UTF8 = headers properly, probably assumes they're in the system's default = charset (CP-1252 in this case). Still the email headers were = understandable enough. Of course if the subject was in some heavily = non-ASCII language like Chinese it probably wouldn't be readable. But = the email body would still be readable even if the headers weren't. So I'm finding it difficult to think of a reason why I would spend a lot = of time implementing the downgrading functionality when it's anyway = going to be unnecessary some day in future, and even today it wouldn't = really be necessary for most users since they could read the emails = anyway (although maybe less perfectly than with the downgrading code). = And note that I'm only talking about IMAP/POP3 side, on SMTP side I can = see how downgrading is much more useful, but luckily I'm not = implementing an SMTP server. :) From tss@iki.fi Tue Oct 30 14:40:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A653221F85C7 for ; Tue, 30 Oct 2012 14:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlnyTf5PhxVt for ; Tue, 30 Oct 2012 14:40:21 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 254BC21F85B3 for ; Tue, 30 Oct 2012 14:40:21 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id DEDDE1AE8867 for ; Tue, 30 Oct 2012 23:40:19 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> Date: Tue, 30 Oct 2012 23:40:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC8DE16-4952-416D-98D2-55E15530CBEB@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> To: IETF EAI X-Mailer: Apple Mail (2.1085) Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 21:40:21 -0000 On 30.10.2012, at 23.20, Timo Sirainen wrote: > And note that I'm only talking about IMAP/POP3 side, on SMTP side I = can see how downgrading is much more useful, but luckily I'm not = implementing an SMTP server. :) On a related note, there are also some new potentially fun combinations = for email clients, like: * IMAP server advertises URLAUTH and UTF8=3DACCEPT * SMTP server advertises BURL but not SMTPUTF8 Few clients support URLAUTH/BURL currently, but if they did .. and if = UTF8 support was added to the client, at least the current behavior of = "first save the email to IMAP server's Sent mailbox and then send it via = SMTP" would suddenly fail in the middle if it was first saved to IMAP = server using UTF8 headers and then SMTP layer noticed it wouldn't work = because SMTPUTF8 wasn't advertised. From klensin@jck.com Tue Oct 30 15:11:11 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6DA21F85B3 for ; Tue, 30 Oct 2012 15:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM81g-KfmS4H for ; Tue, 30 Oct 2012 15:11:11 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4C10A21F85AC for ; Tue, 30 Oct 2012 15:11:11 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TTK1Z-0003bF-W0; Tue, 30 Oct 2012 18:11:05 -0400 Date: Tue, 30 Oct 2012 18:11:00 -0400 From: John C Klensin To: Timo Sirainen Message-ID: <46899EBD133F16ED0C2343EC@JcK-HP8200.jck.com> In-Reply-To: <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 22:11:12 -0000 --On Tuesday, October 30, 2012 23:20 +0200 Timo Sirainen wrote: >> So you think that it is ok for a server to violate a protocol >> if only if it announces it first > > Not exactly, not by default. I'm interested in having an > option on the IMAP/POP3 server where the user can decide if he > wants to use the "old email" or the "new UTF8 email". The > default would be the "old email". An UTF8 capable client could > enable the "new UTF8 email" for the session. But also the user > (or admin..) could force enabling the "new UTF8 email" even if > the client itself didn't explicitly support it. This is just out of band negotiation of a violation (or, if you prefer, non-standard extension) to the protocol. Given the assumed close relationship between IMAP servers and clients (we don't use the term "split-UA" for nothing), I don't see anything preventing you from doing this. There might be a philosophical discussion as to whether the result should be called "IMAP" or "TimoIMAP", but who cares. On other hand, servers who don't know what clients are being used with them or clients that, in practice and notwithstanding some of the "split-UA" assumptions, have no control over what server is being used, need an in-band mechanism. EAI's choices were to use capability announcements or to invent a new mechanism. And the WG selected the former, probably for good reason. In particular, if the server is set to assume and send "new UTF8 email" no matter what, and the user comes along with a legacy client that does Bad Things when sent UTF-8, I wouldn't recommend being the person who gets to debug it or tell the user why that option was arranged for his convenience... unless I was in an enterprise situation in which I got to say "you ran a non-(corporate-)standard client and I'm not interested in your problems". All of this might be different if having the server advertise the capability or having the client enable it was really a big deal. But, as others have pointed out, it really isn't. The only advantage your strategy would gain is a short window in which some legacy clients would be able to accept these messages without being upgraded. That seems to me to be a rotten tradeoff against throwing something at the user that might cause bad behavior with other clients, but YMMD. And, again, it is _really_ late in the process to be having this discussion. best, john From johnl@iecc.com Tue Oct 30 15:47:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D0B21F8471 for ; Tue, 30 Oct 2012 15:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.342 X-Spam-Level: X-Spam-Status: No, score=-110.342 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjsfhbo4J49r for ; Tue, 30 Oct 2012 15:47:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4659B21F846B for ; Tue, 30 Oct 2012 15:47:55 -0700 (PDT) Received: (qmail 66929 invoked from network); 30 Oct 2012 22:47:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Oct 2012 22:47:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50905918.xn--9vv.k1210; i=johnl@user.iecc.com; bh=A91+/iicHP11+yJKsY1ufUImWIFXuEhT8KTDHwKIrrE=; b=ejaYU92GhyyUGFRWryGCU9B4xBTk8G+0t7KsHN/b07ktMA88lwje+tpPBnlpdkKTxLlt+V5ZPNfKAlSRuaOSsH1nhnMrfxvjfQD359BqRJ+w1Blmiz/Tb4y/lDtYmKLz/9K3/qoDZ7tpSuIClmmlJrQ2lExljBiq8LxfPurA8CA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50905918.xn--9vv.k1210; olt=johnl@user.iecc.com; bh=A91+/iicHP11+yJKsY1ufUImWIFXuEhT8KTDHwKIrrE=; b=ozjefM0Pw3r6ubRtccJEzD4LyEllraWHBLx2UR/+Di/RQF7xWW1q9wP3tf4yoGnOfvy0/25fmowUpD1cCXJu7dXy2GMnfWs5jDjcsuTbm2vzfwzpd4MnZUewpFpHXjklBQitZS+LAAphaqA/uvxt2wI0AdoRBUFEOOsyEmePAXg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Oct 2012 22:47:30 -0000 Message-ID: <20121030224730.45612.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tss@iki.fi Subject: Re: [EAI] downgrade or not, was FWD: eai - Requested session X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 22:47:56 -0000 >Pretty much all IMAP clients can already deal with 8bit email headers in one way or another, >because 8bit headers have already existed for a long time now ... Back before my time, the EAI group went through extreme backflips to try and provide a downgrade path so that EAI mail could more or less work with non-EAI mail systems. It became clear that the pain from places where the sort-of-downgrade didn't work far outweighed the benefits. If your MUA is 95% of the way to handling EAI, that's great. It should be easy to persuade its authors to make the tiny tweaks needed to do the other 5% and tell the IMAP server that it does UTF8. As far as I am concerned, I am only interested in two scenarios: A) fully EAI aware software, does all of the EAI stuff B) full downgrade, IMAP server continues to work with all existing clients, yea back unto Outlook 1995 or whatever. It is specifically not a goal to add kludges intended to allow people to use non-EAI software to do mostly EAI stuff. Please don't ask us to go there. Use that effort to upgrade your MUA instead. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From tss@iki.fi Tue Oct 30 15:59:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4522321F85C8 for ; Tue, 30 Oct 2012 15:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.45 X-Spam-Level: X-Spam-Status: No, score=-110.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e+sxZaD0YGl for ; Tue, 30 Oct 2012 15:59:46 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0C47C21F85C5 for ; Tue, 30 Oct 2012 15:59:46 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9AC991AE888E; Wed, 31 Oct 2012 00:59:44 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <46899EBD133F16ED0C2343EC@JcK-HP8200.jck.com> Date: Wed, 31 Oct 2012 00:59:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <636AC7D4-3E27-4C31-AA67-4FC352203FD5@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> <46899EBD133F16ED0C2343EC@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1085) Cc: Barry Leiba , IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 22:59:47 -0000 On 31.10.2012, at 0.11, John C Klensin wrote: >>> So you think that it is ok for a server to violate a protocol >>> if only if it announces it first >>=20 >> Not exactly, not by default. I'm interested in having an >> option on the IMAP/POP3 server where the user can decide if he >> wants to use the "old email" or the "new UTF8 email". The >> default would be the "old email". An UTF8 capable client could >> enable the "new UTF8 email" for the session. But also the user >> (or admin..) could force enabling the "new UTF8 email" even if >> the client itself didn't explicitly support it. >=20 > This is just out of band negotiation of a violation (or, if you > prefer, non-standard extension) to the protocol. Given the > assumed close relationship between IMAP servers and clients (we > don't use the term "split-UA" for nothing), I don't see anything > preventing you from doing this. There might be a philosophical > discussion as to whether the result should be called "IMAP" or > "TimoIMAP", but who cares. =20 Yes, agreed. > On other hand, servers who don't know what clients are being > used with them or clients that, in practice and notwithstanding > some of the "split-UA" assumptions, have no control over what > server is being used, need an in-band mechanism. EAI's choices > were to use capability announcements or to invent a new > mechanism. And the WG selected the former, probably for good > reason. The discussion here I think is mainly about the choice of: a) Don't have UTF8=3DONLY capability at all b) Have UTF8=3DONLY capability only mean that mUTF-7 is not supported in = mailbox list names. c) Same as b) + also not support any kind of message downgrading. Some = way of server not allowing access to UTF8 emails, most likely by not = allowing client to select any mailboxes at all. d) My thought of maybe it meaning that same as assuming client had = issued ENABLE UTF8=3DACCEPT. The current draft seems to point towards b), but I don't think that = makes sense at all (mUTF-7 code is very simple to implement, especially = compared to downgrading related code). Technically I think UTF8=3DONLY = should mean c), but from user's point of view that is just about as = useless as replacing IMAP4rev1 capability with IMAP5, meaning that the = client couldn't access the mails at all anyway then. Of course, that = might eventually be a good thing that users don't attempt to use old = clients against new servers. I don't really know. > In particular, if the server is set to assume and send "new UTF8 > email" no matter what, and the user comes along with a legacy > client that does Bad Things when sent UTF-8, I wouldn't > recommend being the person who gets to debug it or tell the user > why that option was arranged for his convenience... unless I was > in an enterprise situation in which I got to say "you ran a > non-(corporate-)standard client and I'm not interested in your > problems". I wouldn't expect servers to be set for the forced-UTF8 mode outside = small/corporate setups, at least for many more years. Also I don't think = there are any clients that do Very Bad Things when they see UTF8, since = spam has already forced them to deal with it for 10+ years. > All of this might be different if having the server advertise > the capability or having the client enable it was really a big > deal. But, as others have pointed out, it really isn't. The > only advantage your strategy would gain is a short window in > which some legacy clients would be able to accept these messages > without being upgraded. That seems to me to be a rotten > tradeoff against throwing something at the user that might cause > bad behavior with other clients, but YMMD. Depends on how short or long the window is going to be. In the mean time = I think the servers are going to need the force-feature in any case. But = I guess eventually that feature could be disabled and = non-downgrade-capable servers could simply not allow non-UTF8 capable = clients to do anything. Of course, a long time later after "all" clients = support it the servers might be too lazy to actually bother enforcing = that.. So I think all of the solutions are all in all about temporary = (dis)advantages that finally become non-issues. > And, again, it is _really_ late in the process to be having this > discussion. I'm trying to keep this mainly about "What does UTF8=3DONLY mean?" From tss@iki.fi Tue Oct 30 16:21:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E809021F8595 for ; Tue, 30 Oct 2012 16:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcxlCQ68HkvZ for ; Tue, 30 Oct 2012 16:21:36 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 20E4121F8592 for ; Tue, 30 Oct 2012 16:21:36 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 1BBE41AE8863; Wed, 31 Oct 2012 01:21:35 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <20121030224730.45612.qmail@joyce.lan> Date: Wed, 31 Oct 2012 01:21:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC03B06-B809-467F-9EBB-A92E9DADB129@iki.fi> References: <20121030224730.45612.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1085) Cc: ima@ietf.org Subject: Re: [EAI] downgrade or not, was FWD: eai - Requested session X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 23:21:37 -0000 On 31.10.2012, at 0.47, John Levine wrote: > As far as I am concerned, I am only interested in two scenarios: >=20 > A) fully EAI aware software, does all of the EAI stuff >=20 > B) full downgrade, IMAP server continues to work with all existing > clients, yea back unto Outlook 1995 or whatever. Yes, I think those two are the important cases. And A) is (hopefully) = the only one relevant in the far future. > It is specifically not a goal to add kludges intended to allow people > to use non-EAI software to do mostly EAI stuff. Please don't ask us > to go there. Use that effort to upgrade your MUA instead. I don't think it's about kludges. It's mainly a question of which one is = better: a) IMAP client shows all emails in some way. Yes, violating some RFCs, = just like may spams already do, so maybe they won't show up correctly, = but pretty much always they do show up in some way. Theoretically there = are some issues with this that make it worse than not showing the emails = at all, but overall I'd think they are almost nonexistent (or, = guesstimating affecting <0,01% of users). In the far future this won't = be an issue at all. Temporarily this may help some users to use non-UTF8 = clients that otherwise would be completely unusable. b) IMAP client doesn't show any emails in any way. The server simply = says that you're using too old software and you need to upgrade. A clean = solution from the protocol point of view, but not so awesome during the = temporary transition. In the far future this won't be an issue at all = either. For next few years I'm planning on making this an option on the = server side, allowing it to be enabled per-user and/or globally. Also does the RFC really even need to explicitly specify either = behavior? It could simply be a hint to the client/user/debugger that = "you really need to support this UTF8 stuff" and the server could decide = whether to implement a) or b) behavior. Couldn't it be even recommended = that "for the first few years it's a good idea to implement b) by = default, but eventually a) is fine too"? I'm thinking that this is going = to be the reality whether the RFC says it or not. From tss@iki.fi Tue Oct 30 16:35:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67C021F84F5 for ; Tue, 30 Oct 2012 16:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4W-JzsE8ISO for ; Tue, 30 Oct 2012 16:35:52 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3C921F84EB for ; Tue, 30 Oct 2012 16:35:52 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id EEE151AE8866 for ; Wed, 31 Oct 2012 01:35:50 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <20121030224730.45612.qmail@joyce.lan> Date: Wed, 31 Oct 2012 01:35:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121030224730.45612.qmail@joyce.lan> To: IETF EAI X-Mailer: Apple Mail (2.1085) Subject: Re: [EAI] downgrade or not, was FWD: eai - Requested session X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 23:35:52 -0000 On 31.10.2012, at 0.47, John Levine wrote: > It is specifically not a goal to add kludges intended to allow people > to use non-EAI software to do mostly EAI stuff. Please don't ask us > to go there. Use that effort to upgrade your MUA instead. Also another thought from practicality point of view: 1. Admin upgrades SMTP server to be UTF8 capable. 2. New emails arrive with UTF8 headers and get stored using regular = mbox/maildir format. 3. Admin still uses an old generic non-UTF8 capable IMAP/POP3 server. Regardless of what EAI RFCs say, what is going to happen is that the old = non-UTF8 IMAP/POP3 server is going to send the mails to IMAP/POP3 = clients using UTF8 headers. Of course this is mainly the admin's fault = of not using compatible software, but I don't think the above is a very = far fetched scenario. From tss@iki.fi Tue Oct 30 17:04:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D8D21F8615 for ; Tue, 30 Oct 2012 17:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQBDc30vGaxP for ; Tue, 30 Oct 2012 17:04:12 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id A85E921F8453 for ; Tue, 30 Oct 2012 17:04:12 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id A81501AE8863 for ; Wed, 31 Oct 2012 02:04:11 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: <636AC7D4-3E27-4C31-AA67-4FC352203FD5@iki.fi> Date: Wed, 31 Oct 2012 02:04:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8658B435-B2F2-4592-A643-AE1EC8F7B33E@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> <46899EBD133F16ED0C2343EC@JcK-HP8200.jck.com> <636AC7D4-3E27-4C31-AA67-4FC352203FD5@iki.fi> To: IETF EAI X-Mailer: Apple Mail (2.1085) Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 00:04:13 -0000 I know I'm sending too many mails now about this already, but I think = after writing the previous ones I've finally formed an opinion about the = UTF8=3DACCEPT vs. UTF8=3DONLY issue: No IMAP client is ever going to implement UTF8=3DONLY in a different way = than UTF8=3DACCEPT. If the server supports only UTF8=3DONLY, the = clients' possibilities are then to: a) Not support UTF8=3D*: The server will then fail the commands with = "Sorry dude, you need to upgrade your IMAP client to use this awesome = new server." b) Recognize UTF8=3DONLY but not actually support it: The client will = fail the login with "Sorry dude, but I was too lazy to implement proper = support for this server, but not too lazy to add this very helpful error = message saying you can't use this server." The end result is the same. The client can't use the server. In the far = future neither of these things happen. In the mean time I seriously = doubt any client developer will add anything like b), even with a = different error message. So my opinion: Merge UTF8=3DACCEPT and UTF8=3DONLY into a single UTF8 = capability. Leave it to the server implementation to figure out what to = do if the client doesn't issue ENABLE UTF8. It's fine to reject such = clients or to downgrade (more, less or none at all) such clients. From johnl@taugh.com Tue Oct 30 17:33:12 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D7021F8480 for ; Tue, 30 Oct 2012 17:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdKGnSYH+Kb7 for ; Tue, 30 Oct 2012 17:33:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8727421F846D for ; Tue, 30 Oct 2012 17:33:11 -0700 (PDT) Received: (qmail 85534 invoked from network); 31 Oct 2012 00:33:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=14e1b.509071c5.k1210; bh=HUXAXyS/5L1X45ADfpE1PFrwyhaqZfeMRlU8irSyiQ0=; b=Wnz7SHfVVXJ9HVUjqjZkiJIuATfrgS7EGHyQTaC5xtSsIf81Bxx3TjrivA6PB4Nzg0cezsW2O2YGk+CuEBbgJjTJjjt6p4z+E6dKutz/aomKd3BShXb2X2zIrt7EZfxbsTOH+n1wWJsGu6Rsk0od8AA7OqnFQGm4TVNU0VO5t3M= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=14e1b.509071c5.k1210; bh=HUXAXyS/5L1X45ADfpE1PFrwyhaqZfeMRlU8irSyiQ0=; b=I+qt7rfayTtfJvcqPl+jftAE+2s/5/KJaPwVLzYOmgNjF//dh05qLbduT8F3xgh2QUeIbTdbzdLf2zyUImI/VWpirBrfkpGK1kJbyFnmCUILN41l77A1/DYSqGILwrxas2L4sdKG7HEbpnqh6zfQU2NuB7Jpu1vrUTJj9baQTuc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 31 Oct 2012 00:32:47 -0000 Date: 30 Oct 2012 20:33:08 -0400 Message-ID: From: "John R Levine" To: "Timo Sirainen" In-Reply-To: <3AC03B06-B809-467F-9EBB-A92E9DADB129@iki.fi> References: <20121030224730.45612.qmail@joyce.lan> <3AC03B06-B809-467F-9EBB-A92E9DADB129@iki.fi> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] downgrade or not, was FWD: eai - Requested session X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 00:33:12 -0000 These are all questions that we addressed months ago. It's much, much too late to reopen them now. > I don't think it's about kludges. ... > > a) IMAP client shows all emails in some way. Yes, violating some RFCs, That's a kludge, by definition. Don't do that. The whole point of the downgrade docs (have you read them?) is to describe ways to show EAI messages to to non-EAI clients. > b) IMAP client doesn't show any emails in any way. The server simply > says that you're using too old software and you need to upgrade. That's an option, but not a great one since the server will fill up with mail that the user can neither see nor delete. We also discussed this months ago. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From barryleiba.mailing.lists@gmail.com Wed Oct 31 08:36:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8267C21F87BB for ; Wed, 31 Oct 2012 08:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.263 X-Spam-Level: X-Spam-Status: No, score=-103.263 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfRAUe2+JwM0 for ; Wed, 31 Oct 2012 08:36:57 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF02021F87A4 for ; Wed, 31 Oct 2012 08:36:56 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so702460eaa.31 for ; Wed, 31 Oct 2012 08:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HtZF+Uv4xT+X4uzu9Xx0SAkK6YaAjTDx8fhAlt+L1IU=; b=Kje8MdsAmyokTzRaAFdv8LSOWM7YE8HrfLQPazoH8HEVeE1u7vM4Vqh2jFLMvJl0Zk gE9CT7k71MpsYck4Q2w2oo8ib44LInmMnJOgzWymANK7uo8Br3vM50TKB94mvfOUQZmH fo5jMO+RU2L8yWNMC9L5BSjzROkkwSc2qUJbG8tV0HUqcJSYphbYRYKk4gRpixKjFqWG QN8Qt/mSLUfRM3r0ZS+gGSKDQyzVyZ42hYjZmUCFySFj+9EIcUt5I27W1WK2Q6wn4BBw 4OFH5xM2fyH8eh5uVkvLHVEtg3YEcbSELhpJ1SIR0/ENo490ggc9zwn7vgnUTKJh6l4E g0Ww== MIME-Version: 1.0 Received: by 10.14.174.194 with SMTP id x42mr71813728eel.22.1351697815843; Wed, 31 Oct 2012 08:36:55 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.98.71 with HTTP; Wed, 31 Oct 2012 08:36:55 -0700 (PDT) In-Reply-To: <8658B435-B2F2-4592-A643-AE1EC8F7B33E@iki.fi> References: <54CDCF4A5DDF5DDBB319014D@JcK-HP8200.jck.com> <2B98238A-2097-469B-B39B-867C85E8138C@iki.fi> <508FD2C5.2000304@isode.com> <67A2BC9B28E2883D19AB4F91@JcK-HP8200.jck.com> <45455334-DB2A-4F1E-B88A-14797EEC0249@iki.fi> <46899EBD133F16ED0C2343EC@JcK-HP8200.jck.com> <636AC7D4-3E27-4C31-AA67-4FC352203FD5@iki.fi> <8658B435-B2F2-4592-A643-AE1EC8F7B33E@iki.fi> Date: Wed, 31 Oct 2012 11:36:55 -0400 X-Google-Sender-Auth: iTgVRMfWxajDUc1oKNQHhHECkJ0 Message-ID: From: Barry Leiba To: Timo Sirainen Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF EAI Subject: Re: [EAI] FWD: eai - Requested session has been scheduled for IETF 85 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:36:57 -0000 Timo says... > So my opinion: Merge UTF8=ACCEPT and UTF8=ONLY into a single UTF8 > capability. Leave it to the server implementation to figure out what to do if the > client doesn't issue ENABLE UTF8. It's fine to reject such clients or to > downgrade (more, less or none at all) such clients. That's my thought as well. As I've said, I think ONLY was useful when we had a larger set of options, and its existence now is a vestige from that time. But when we decided to drop the other options (ALL, APPEND, and USER), we *did* decide specifically to keep ONLY, which is why we need to have the discussion now about why we decided that at the time. It may well be that I've just forgotten the details, and the distinction is still important. b