Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJRHuU015471; Thu, 30 Dec 2004 11:27:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUJRHtw015470; Thu, 30 Dec 2004 11:27:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJRG0E015385 for ; Thu, 30 Dec 2004 11:27:16 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBUJQraa023155 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Dec 2004 11:26:53 -0800 In-Reply-To: <41D453AE.2040806@alussinan.org> References: <41D272B6.5070706@alussinan.org> <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> <41D453AE.2040806@alussinan.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org From: Lisa Dusseault Subject: Re: Storing annotations colours on IMAP servers Date: Thu, 30 Dec 2004 11:26:47 -0800 To: kael X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I imagine users wouldn't define annotations in any case; client developers would, and as you suggest, it's possible to standardize a name for the colour annotation as well as a syntax. That work isn't within the charter of this WG but this is probably a decent place to try to drum up participation. I can't think of any way to synchronize colours with current MUAs. They're already deployed with support only for adding their own colouring and storing it locally, as you illustrate with Thunderbird and Mulberry. Lisa On Dec 30, 2004, at 11:14 AM, kael wrote: > On 30.12.2004 19:17, Lisa Dusseault wrote: >> The annotate draft >> > -11.txt> allows client-specific annotations to be added to the mail >> store, if the server supports it. You could either define a >> proprietary annotation (and not share colour information with other >> clients, but make it available to be synchronized via the server) or >> work out some agreed scheme which other clients could use as well. > > How could colors be synchronized with (current) MUAs ? > > Actually, I was thinking that IMAP servers could have the ability to > store that kind of information _by default_ which could help to make > "gains productivity". > > Users would have neither to define annotations name nor their color > each time they configure a MUA. > > This page http://researchweb.watson.ibm.com/history/index.htm gave me > the idea - visualization tools are very useful when they use colors. > > Currently, it's great to use IMAP: nomad users configure the MUA and > get all their emails. But each time, users have to re-configure > keywords name and colors - personal experience with Mulberry and > Thunderbird's labels, unfortunately not interoperable (or compatible > ?). > > So waiting for the /ACAP Renaissance/, maybe IMAP could help and > annotations colors could be standardized - maybe as "attributes" ? > > -- > kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us > > "We're in the process of creating a planetary nervous system" > _The network is the blog_ by Jon Udell - > http://weblog.infoworld.com/udell/2004/12/17.html#a1136 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJFVSv097972; Thu, 30 Dec 2004 11:15:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUJFVCb097971; Thu, 30 Dec 2004 11:15:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJFUfd097939 for ; Thu, 30 Dec 2004 11:15:31 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix3-1.free.fr (Postfix) with ESMTP id E3D931734B3; Thu, 30 Dec 2004 20:15:24 +0100 (CET) Message-ID: <41D453AE.2040806@alussinan.org> Date: Thu, 30 Dec 2004 20:14:54 +0100 From: kael User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: ietf-imapext@imc.org Subject: Re: Storing annotations colours on IMAP servers References: <41D272B6.5070706@alussinan.org> <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> In-Reply-To: <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 30.12.2004 19:17, Lisa Dusseault wrote: > The annotate draft > -11.txt> allows client-specific annotations to be added to the mail > store, if the server supports it. You could either define a > proprietary annotation (and not share colour information with other > clients, but make it available to be synchronized via the server) or > work out some agreed scheme which other clients could use as well. How could colors be synchronized with (current) MUAs ? Actually, I was thinking that IMAP servers could have the ability to store that kind of information _by default_ which could help to make "gains productivity". Users would have neither to define annotations name nor their color each time they configure a MUA. This page http://researchweb.watson.ibm.com/history/index.htm gave me the idea - visualization tools are very useful when they use colors. Currently, it's great to use IMAP: nomad users configure the MUA and get all their emails. But each time, users have to re-configure keywords name and colors - personal experience with Mulberry and Thunderbird's labels, unfortunately not interoperable (or compatible ?). So waiting for the /ACAP Renaissance/, maybe IMAP could help and annotations colors could be standardized - maybe as "attributes" ? -- kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us "We're in the process of creating a planetary nervous system" _The network is the blog_ by Jon Udell - http://weblog.infoworld.com/udell/2004/12/17.html#a1136 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUIINQM080945; Thu, 30 Dec 2004 10:18:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUIIN3W080944; Thu, 30 Dec 2004 10:18:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUIIMxa080932 for ; Thu, 30 Dec 2004 10:18:22 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBUII1aa018455 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Dec 2004 10:18:01 -0800 In-Reply-To: <41D272B6.5070706@alussinan.org> References: <41D272B6.5070706@alussinan.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org From: Lisa Dusseault Subject: Re: Storing annotations colours on IMAP servers Date: Thu, 30 Dec 2004 10:17:54 -0800 To: kael X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The annotate draft allows client-specific annotations to be added to the mail store, if the server supports it. You could either define a proprietary annotation (and not share colour information with other clients, but make it available to be synchronized via the server) or work out some agreed scheme which other clients could use as well. Lisa On Dec 29, 2004, at 1:02 AM, kael wrote: > > Hello, > > Could annotations (and keywords) colours be stored on IMAP servers ? > > Thank you very much. > > -- > kael > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBT93P2T062337; Wed, 29 Dec 2004 01:03:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBT93PW0062336; Wed, 29 Dec 2004 01:03:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBT93OvO061877 for ; Wed, 29 Dec 2004 01:03:25 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix3-2.free.fr (Postfix) with ESMTP id 814D9C110; Wed, 29 Dec 2004 10:03:11 +0100 (CET) Message-ID: <41D272B6.5070706@alussinan.org> Date: Wed, 29 Dec 2004 10:02:46 +0100 From: kael User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Storing annotations colours on IMAP servers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Could annotations (and keywords) colours be stored on IMAP servers ? Thank you very much. -- kael Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBSJMh2K010177; Tue, 28 Dec 2004 11:22:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBSJMhIW010176; Tue, 28 Dec 2004 11:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBSJMhcd010005 for ; Tue, 28 Dec 2004 11:22:43 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBSJMbaa023183 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 28 Dec 2004 11:22:38 -0800 Mime-Version: 1.0 (Apple Message framework v619) To: IMAP Extensions WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-4--746987174 From: Lisa Dusseault Subject: Fwd: Interim Meeting for IMAPEXT Date: Tue, 28 Dec 2004 11:22:27 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4--746987174 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I got the interim meeting announcement in just under the wire... *whew* Please continue to let me know if you plan to attend or what you'd like to discuss. So far, Barry Leiba, Randy Gellens, Alexey Melnikov and I are on the side of probably attending, and Mark and Cyrus on the side of probably not attending. That means we'll have all the authors of LISTEXT and half the authors of ANNOTATE, available to heckle them about their draft lateness :) We may also discuss 2086upd but only if something surprising turns up. So far it looks like the last call is generating some changes but nothing requiring a reset. Stephane Maes is kindly looking into letting us use the same Oracle space that the Lemonade WG is using. Lisa Begin forwarded message: > From: Lisa Dusseault > Date: December 21, 2004 11:31:05 AM PST > To: IETF-Announce@ietf.org > Cc: Subject: Interim Meeting for IMAPEXT > > We are organizing an interim meeting for IMAPEXT in the San Francisco > Bay Area for the afternoon of Jan 20. (The meeting location and time > will be alongside the LEMONADE WG interim meeting which has an > overlapping membership). > > I've already announced this intent on the IMAPEXT mailing list and > would like to announce it more widely even though we don't as yet know > the exact location. > > Scott Hollenbeck has indicated his approval. > > Location: TBD, near San Francisco/Redwood Shores, CA > Date: Jan 20, 2:00 pm to 5:00 pm > Hotel: See LEMONADE WG interim meeting information > > Agenda (Draft) > =========== > > - resolve ANNOTATE open issues with authors > - Discuss LISTEXT extensions > - Resume work on ACL draft > > > --Thanks, > Lisa Dusseault > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-4--746987174 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I got the interim meeting announcement in just under the wire... *whew* Please continue to let me know if you plan to attend or what you'd like to discuss. So far, Barry Leiba, Randy Gellens, Alexey Melnikov and I are on the side of probably attending, and Mark and Cyrus on the side of probably not attending. That means we'll have all the authors of LISTEXT and half the authors of ANNOTATE, available to heckle them about their draft lateness :) We may also discuss 2086upd but only if something surprising turns up. So far it looks like the last call is generating some changes but nothing requiring a reset. Stephane Maes is kindly looking into letting us use the same Oracle space that the Lemonade WG is using. Lisa Begin forwarded message: 0000,0000,0000From: Lisa Dusseault < 0000,0000,0000Date: December 21, 2004 11:31:05 AM PST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: Subject: Interim Meeting for IMAPEXT We are organizing an interim meeting for IMAPEXT in the San Francisco Bay Area for the afternoon of Jan 20. (The meeting location and time will be alongside the LEMONADE WG interim meeting which has an overlapping membership). I've already announced this intent on the IMAPEXT mailing list and would like to announce it more widely even though we don't as yet know the exact location. Scott Hollenbeck has indicated his approval. Location: TBD, near San Francisco/Redwood Shores, CA Date: Jan 20, 2:00 pm to 5:00 pm Hotel: See LEMONADE WG interim meeting information Agenda (Draft) =========== - resolve ANNOTATE open issues with authors - Discuss LISTEXT extensions - Resume work on ACL draft --Thanks, Lisa Dusseault _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-4--746987174-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBPCQjoe063997; Sat, 25 Dec 2004 04:26:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBPCQjWZ063995; Sat, 25 Dec 2004 04:26:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBPCQikq063706 for ; Sat, 25 Dec 2004 04:26:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 25 Dec 2004 12:26:37 +0000 Message-ID: <41CD4429.5000803@isode.com> Date: Sat, 25 Dec 2004 10:42:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Wed, 8 Dec 2004, Lisa Dusseault wrote: > >> I call your attention to this draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt > > Sorry I've been absent from the list -- I've been rearranging my life > for the last few months. Its likely I'd be able to make the interim > meeting if it happens. > > I'm really glad to see this work being done :) > > 1 note: > > 3) > A server implementation conformant to this document MUST also return > rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability > response. > > The ABNF for this indicates that digits are also allowed, yet digits > are technically "defined" as "optional" in RFC2086. Can this be > clarified to indicate that it includes only optional rights that are > implemented by the server, or that this applies to only standard > rights (and thus the ABNF is fixed). > > I'm not convinced that the client is able to do anything with > knowledge of optional rights that are implemented by the server > without more context, and since they are already defined in 2086, I > think I lean towards the later, but I'm willing to hear other opinions. Ok, here is my change to address this issue: In section 3: A server implementation conformant to this document MUST also return rights (see below) not defined in section 3.2 in the "RIGHTS=" capability. Added new section 3.2: 3.2. Rights defined in RFC 2086. For convenience, this section lists the rights which were defined in the RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights ("0" .. "9"). The listed rights MUST NOT be returned in the "RIGHTS=" capability string. Updated ABNF: new_rights = 1*LOWER_ALPHA ;; MUST include "t", "e", "x" and "k". ;; MUST NOT include standard rights listed ;; in section 3.2 ... rights_capa = "RIGHTS=" new_rights ;; RIGHTS=... capability Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBOBIqYZ000957; Fri, 24 Dec 2004 03:18:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBOBIqm7000941; Fri, 24 Dec 2004 03:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBOBIkRO000715 for ; Fri, 24 Dec 2004 03:18:51 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 24 Dec 2004 11:18:43 +0000 Message-ID: <41CBFB0D.7030501@isode.com> Date: Fri, 24 Dec 2004 11:18:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> <41C9E8E1.2040206@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Wed, 22 Dec 2004, Alexey Melnikov wrote: > >>> 3) >>> A server implementation conformant to this document MUST also return >>> rights (see below) not defined in RFC 2086 in the "RIGHTS=" >>> capability >>> response. >>> >>> The ABNF for this indicates that digits are also allowed, yet digits >>> are technically "defined" as "optional" in RFC2086. Can this be >>> clarified to indicate that it includes only optional rights that are >>> implemented by the server, or that this applies to only standard >>> rights (and thus the ABNF is fixed). >>> >>> I'm not convinced that the client is able to do anything with >>> knowledge of optional rights that are implemented by the server >>> without more context, and since they are already defined in 2086, I >>> think I lean towards the later, but I'm willing to hear other opinions. >> >> The latter sounds better to me. Do you want me to clarify the text or >> do you want tighter ABNF as well? > > I don't see a reason for the ABNF to allow digits when the text does not. Ok, but I will not explicitly prohibit in ABNF rights defined in 2086. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJHfPM031881; Thu, 23 Dec 2004 11:17:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNJHfmB031880; Thu, 23 Dec 2004 11:17:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJHeii031836 for ; Thu, 23 Dec 2004 11:17:40 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX46.andrew.cmu.edu (UNIX46.andrew.cmu.edu [128.2.13.176]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id iBNJHegv026926; Thu, 23 Dec 2004 14:17:40 -0500 Date: Thu, 23 Dec 2004 14:17:40 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) In-Reply-To: <41C9E8E1.2040206@isode.com> Message-ID: References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> <41C9E8E1.2040206@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Dec 2004, Alexey Melnikov wrote: >> 3) >> A server implementation conformant to this document MUST also return >> rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability >> response. >> >> The ABNF for this indicates that digits are also allowed, yet digits are >> technically "defined" as "optional" in RFC2086. Can this be clarified to >> indicate that it includes only optional rights that are implemented by the >> server, or that this applies to only standard rights (and thus the ABNF is >> fixed). >> >> I'm not convinced that the client is able to do anything with knowledge of >> optional rights that are implemented by the server without more context, >> and since they are already defined in 2086, I think I lean towards the >> later, but I'm willing to hear other opinions. > > The latter sounds better to me. Do you want me to clarify the text or do you > want tighter ABNF as well? I don't see a reason for the ABNF to allow digits when the text does not. -Rob ------------------------------------------------------------------------- Rob Siemborski | PGP:0x5CE32FCC | rjs3@andrew.cmu.edu -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJ4urY017690; Thu, 23 Dec 2004 11:04:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNJ4uIG017688; Thu, 23 Dec 2004 11:04:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJ4phl017451 for ; Thu, 23 Dec 2004 11:04:53 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 23 Dec 2004 19:04:29 +0000 Message-ID: <41C9E8E1.2040206@isode.com> Date: Wed, 22 Dec 2004 21:36:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > 1 note: > > 3) > A server implementation conformant to this document MUST also return > rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability > response. > > The ABNF for this indicates that digits are also allowed, yet digits > are technically "defined" as "optional" in RFC2086. Can this be > clarified to indicate that it includes only optional rights that are > implemented by the server, or that this applies to only standard > rights (and thus the ABNF is fixed). > > I'm not convinced that the client is able to do anything with > knowledge of optional rights that are implemented by the server > without more context, and since they are already defined in 2086, I > think I lean towards the later, but I'm willing to hear other opinions. The latter sounds better to me. Do you want me to clarify the text or do you want tighter ABNF as well? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMGhpkF010323; Wed, 22 Dec 2004 08:43:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBMGhoQD010305; Wed, 22 Dec 2004 08:43:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMGhlUj010201 for ; Wed, 22 Dec 2004 08:43:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX47.andrew.cmu.edu (UNIX47.andrew.cmu.edu [128.2.13.177]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id iBMGhlgv023807 for ; Wed, 22 Dec 2004 11:43:47 -0500 Date: Wed, 22 Dec 2004 11:43:47 -0500 (EST) From: Rob Siemborski To: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) In-Reply-To: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> Message-ID: References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 8 Dec 2004, Lisa Dusseault wrote: > I call your attention to this draft: > > http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt Sorry I've been absent from the list -- I've been rearranging my life for the last few months. Its likely I'd be able to make the interim meeting if it happens. I'm really glad to see this work being done :) 1 note: 3) A server implementation conformant to this document MUST also return rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability response. The ABNF for this indicates that digits are also allowed, yet digits are technically "defined" as "optional" in RFC2086. Can this be clarified to indicate that it includes only optional rights that are implemented by the server, or that this applies to only standard rights (and thus the ABNF is fixed). I'm not convinced that the client is able to do anything with knowledge of optional rights that are implemented by the server without more context, and since they are already defined in 2086, I think I lean towards the later, but I'm willing to hear other opinions. -Rob ------------------------------------------------------------------------- Rob Siemborski | PGP:0x5CE32FCC | rjs3@andrew.cmu.edu -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBM92lNH099389; Wed, 22 Dec 2004 01:02:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBM92ljY099388; Wed, 22 Dec 2004 01:02:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBM92jNe099363 for ; Wed, 22 Dec 2004 01:02:46 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 22 Dec 2004 09:02:41 +0000 Message-ID: <41C89A05.2050302@isode.com> Date: Tue, 21 Dec 2004 21:47:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I call your attention to this draft: > > http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt > > It was extracted from a more ambitious update to IMAP ACLs so it's not > as fresh as it looks from its 02 age. Alexey has some minor edits to > make (which he'll list in reply to this email), but we believe it's > ready for WG last call. > > Because of the current and imminent winter observances and vacations, > last call will go until Jan 4. Happy holidays I-D reading! Ok, here is a list of changes I've done to my copy: 1). Clarified that DELETEACL "fred" doesn't affect the identifier "-fred". New text reads (section 3, second paragraph from the bottom): A DELETEACL of "fred" simply deletes the identifier "fred" from the ACL; it does not affect any rights that the user "fred" may get from another entry in the ACL, in particular it doesn't affect rights granted to the identifier "-fred". The following example was added to the section describing DELETEACL (section 4.2): Example: C: B001 GETACL INBOX S: * ACL INBOX Fred rwipslxeta -Fred wet $team w S: B001 OK Getacl complete C: B002 DELETEACL INBOX Fred S: B002 OK Deleteacl complete C: B003 GETACL INBOX S: * ACL INBOX -Fred wet $team w S: B003 OK Getacl complete 2). Removed several commas when no needed (as per Philip). Also corrected few cases where singular was used instead of plural (as per Ken). 3). Corrected examples in sections 4.3, 4.4 and 4.5: new rights defined in the document were not listed. Fixed examples: In section 4.3: Example: C: A002 GETACL INBOX S: * ACL INBOX Fred rwipsldexta S: A002 OK Getacl complete In section 4.4: Example: C: a001 LISTRIGHTS ~/Mail/saved smith S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte S: a001 OK Listrights completed C: a005 LISTRIGHTS archive.imap anyone S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t e a 0 1 2 3 4 5 6 7 8 9 S: a005 Listrights successful In section 4.5: Example: C: A003 MYRIGHTS INBOX S: * MYRIGHTS INBOX rwiptsldaex S: A003 OK Myrights complete 4). Updated description of rights needed for DELETE command as per question asked by Philip. New description: DELETE - "x" right on the mailbox. Note that some servers don't allow to delete a non-empty mailbox. If this is the case, the user would also need "r", "e" and "t" rights, in order to open the mailbox and empty it. Is this clear enough? 5). Dave has requested that section 6.1.1 shows an example when MYRIGHTS and SELECT commands are pipelined. I've added: Note that in order to get better performance the client may pipeline SELECT and MYRIGHTS commands: C: A142 SELECT INBOX C: A143 MYRIGHTS INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited S: A142 OK [READ-WRITE] SELECT completed S: * MYRIGHTS INBOX lrwis S: A143 OK completed Alexey P.S. Dave also found an issue with LISTRIGHTS command and virtual rights. I will post a separate message on this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB90SF0O005031; Wed, 8 Dec 2004 16:28:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB90SFIQ005030; Wed, 8 Dec 2004 16:28:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB90SFet004987 for ; Wed, 8 Dec 2004 16:28:15 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB90S8aa015092 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Dec 2004 16:28:12 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: WG last call for IMAP ACL small-scope changes (RFC2086bis) Date: Wed, 8 Dec 2004 16:28:02 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I call your attention to this draft: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt It was extracted from a more ambitious update to IMAP ACLs so it's not as fresh as it looks from its 02 age. Alexey has some minor edits to make (which he'll list in reply to this email), but we believe it's ready for WG last call. Because of the current and imminent winter observances and vacations, last call will go until Jan 4. Happy holidays I-D reading! Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8I28d9033134; Wed, 8 Dec 2004 10:02:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8I28tv033129; Wed, 8 Dec 2004 10:02:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8I28K6032943 for ; Wed, 8 Dec 2004 10:02:08 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB8I22aa000366 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Dec 2004 10:02:04 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <3F2736B6-4943-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: IMAPEXT Interim WG meeting Date: Wed, 8 Dec 2004 10:01:55 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Lemonade WG is getting together in the Bay Area for an interim WG meeting Jan 19 and Jan 20. The Lemonade chairs left the afternoon of Jan 20 unbooked, so we could get together and work on IMAPEXT stuff that afternoon if there's enough interest. I've already checked to see if some of the authors of our drafts can make it and some can. I'll need to get official IESG approval I think, but I thought it would be good to suggest a time and get feedback. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6Cx6oG056166; Mon, 6 Dec 2004 04:59:06 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6Cx6Y4056164; Mon, 6 Dec 2004 04:59:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6Cx4xb055956 for ; Mon, 6 Dec 2004 04:59:05 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 6 Dec 2004 12:58:59 +0000 Message-ID: <41B45792.70000@isode.com> Date: Mon, 06 Dec 2004 12:58:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: What is wrong with UIDPLUS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am forwarding Mark's message so it can be found in IMAPEXT archive. -------- Original Message -------- Subject: Re: [lemonade] URLFETCH Partial Fetches Date: Sun, 5 Dec 2004 11:41:07 -0800 (PST) From: Mark Crispin To: Alexey Melnikov CC: lemonade@ietf.org References: <41B3541D.2000904@isode.com> On Sun, 5 Dec 2004, Alexey Melnikov wrote: > I am curious to know what are the problems with UIDPLUS? Good question, Alexey! I've been taking a long hard look at UIDPLUS lately, as I may have to implement it. UIDPLUS bundles two orthogonal functionalities: the UID EXPUNGE command, and the APPENDUID and COPYUID responses. There is no implementation dependendency between the two; they should not be in the same capability. But the worst part is that APPENDUID and COPYUID are poorly thought out, especially in light of the interaction with MULTIAPPEND. There should have been a single response for all cases, not the current situation where very similar, but not quite the same, responses are used. In some mail stores, certain cases of COPY end up having to be implemented as APPEND internally; this creates an added implementation burden to generate the correct COPYUID. When multiple messages are involved, APPENDUID/COPYUID suffer from the flaw that a set<->set mapping needs to be calculated; the excuse being that if monotonically increasing UIDs are assigned then the response is less chatty than alternatives. It's also an invitation to bugs. There should be an explicit source->destination mapping for each message, not "match this set with that set". In some mail stores, it can be very expensive to return APPENDUID/COPYUID data, *especially* in those cases where the IMAP server vendor does not control the delivery mechanism. In fact, UIDPLUS could be called the FCTGTMSFASS (Force Customers To Get Their Mail Software From A Single Source) extension to IMAP. Since IMAP requires strictly ascending UIDs, it is impossible to assign a UID to a newly APPENDed or COPYed message without assurance than any new mail delivered to the mailbox has also had a UID assigned. Hence FCTGTMSFASS; if the mail delivery agent is from another vendor that assurance may be absent and the IMAP server has to fix things. This, in turn, requires a sort of read/write open that assigns UIDs but doesn't affect \Recent flags or the RECENT count in the next open. That also means that you can't use "no UID was assigned when mailbox opened" to mean \Recent -- the \Recent flag has to be maintained independently. All this is not cheap, although with a lot of extra programming much of the extra cost can be ameliorated. Among other things, this means additional mailbox metadata in order to avoid taking the worst-case fixup path each time. Better would have been to have two new commands that would return new responses (instead of response codes). This would save servers the work if the client does not care (the majority of clients!), and also would have allowed much more flexibility in the response syntax. In conclusion, I believe that UIDPLUS: 1) bundles together things that did not need to be bundled; 2) creates server burdens that often are unnecessary; 3) has a incredibly kludgy design in order to avoid adding new commands and responses. In some ways, the third sin is the worst of all, and caused the other two sins. I've often criticized ACL, but it is well-designed. The problem with is that ACL is a *very* hard problem. The difficulty is *far* worse when you attempt to export external legacy facilities. Similar comments can be made about certain other troublesome extensions (e.g. QUOTA). UIDPLUS, on the other hand, stands out as expediency over good design. I fear that it's much too late to fix it now. We're stuck with the wart. But we can learn from the mistake, and avoid similar mistakes in the future. That I think is the important point to move forward. What seems to be simple and expedient today can have long-term deleterious consequences in the future. It's often difficult, and frustrating!!, to be delayed in discussions on how to do things right when an attractive shortcut seems to exist. It's even more frustrating when deadlines are faced and/or needs are unmet. But the results of doing it right are worth it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3CEcuW017318; Fri, 3 Dec 2004 04:14:38 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3CEcll017316; Fri, 3 Dec 2004 04:14:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3CEaJq017194 for ; Fri, 3 Dec 2004 04:14:37 -0800 (PST) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27818; Fri, 3 Dec 2004 07:14:34 -0500 (EST) Message-Id: <200412031214.HAA27818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-2086upd-02.txt Date: Fri, 03 Dec 2004 07:14:34 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-2086upd-02.txt Pages : 0 Date : 2004-12-2 The ACL (Access Control List) extension (RFC 2086) of the Internet Message Access Protocol (IMAP4rev1) permits mailbox access control lists to be manipulated through the IMAP protocol. This document is a revision of the RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-2086upd-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-2086upd-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-2115345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-2086upd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-2086upd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-2115345.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2HHj3Y060485; Thu, 2 Dec 2004 09:17:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2HHjX0060484; Thu, 2 Dec 2004 09:17:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2HHiAR060469 for ; Thu, 2 Dec 2004 09:17:44 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 2 Dec 2004 17:17:38 +0000 Message-ID: <41AF4E31.2070905@isode.com> Date: Thu, 02 Dec 2004 17:17:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: IMAP Extensions WG Subject: Re: Changes to the 2086upd draft References: <41AF3579.70004@isode.com> <200412021705.iB2H5nfp043854@lab.smi.sendmail.com> In-Reply-To: <200412021705.iB2H5nfp043854@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Alexey Melnikov writes: >... > > >>8). Declared uppercase rights illegal, due to backward compatibility. >> >>9). Removed MYRIGHTS response code, because David Cridland has pointed >>out that there would be a compatibility issue for servers that implement >>both 2086upd and ACL, caused by issue # 8. >> >> > >I don't understand the logic on this. If an existing server gives a >meaning to uppercase rights other than "same as the lowercase" then it >is not compliant with the ACL RFC, which reserves all letters for >standards-track extensions. > >On top of that, how could the appearance of such illegal rights in a new >MYRIGHTS response code be more of a problem than their appearance in >other ACL responses? The ban applies to the ACL commands too... > > A server that supports both ACL and ACL2 would have to lowercase rights in the MYRIGHTS response code. As there is no way for the server to know if the client supports ACL or ACL2, this means that *every* ACL2 server MUST always lowercase rights in MYRIGHTS, which creates a special case for ACL2-only servers. And server implementors can easily miss it. David also pointed out that the client can pipeline SELECT with MYRIGHTS anyway, so we have a workaround for ACL. >(Did I miss this on the list?) > > No, this was off the list discussion between David, Cyrus and myself. >>10). Updated the description of rights required for the DELETE command >>to read: >> >> DELETE - "x" right on the mailbox. Note, that some servers don't allow >> to delete a non-empty mailbox. If this is the case, the user >> also need both "e" and "t" rights, in order to make the mailbox >> empty first. >> >> > >Is this saying that some servers, when told to DELETE a non-empty >mailbox, must internally perform STORE and EXPUNGE commands, such that >the DELETE will fail if the user has the "x" right but not both the "e" >and "t" rights? Or is this saying that some servers will fail a DELETE >of a non-empty mailbox and that clients MAY work around this brokeness >by doing the STORE and EXPUNGE themselves? > > I meant the latter, although there are some existing servers that do the former. >At least in the latter case, the "r" right would also be required. > > Right. >("Note that..." doesn't take a comma. That should be fixed in a couple >other places in the draft.) > > Fixed, thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2H5xvZ052085; Thu, 2 Dec 2004 09:05:59 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2H5xpJ052084; Thu, 2 Dec 2004 09:05:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2H5uIW051956 for ; Thu, 2 Dec 2004 09:05:59 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iB2H5oi5008080 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 2 Dec 2004 09:05:51 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iB2H5oi5008080 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Dp+H8VIQ2DBig13cc679KHRgrlEwzHBM2YoS6+EPV6bMzFFGgVMddAkKBYGSHk+oc GZUmIQ6tqs5DZJAP24lazRMuB4Yx4OzdOR+81pYet+arCBvfc5JiLSX4Hb7LAaIOwGh uczyQxOxaApcWOUF6GbM8AQgnZ8PacI3b4g+xAU= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iB2H5nfp043854; Thu, 2 Dec 2004 09:05:50 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200412021705.iB2H5nfp043854@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: Changes to the 2086upd draft In-reply-to: <41AF3579.70004@isode.com> References: <41AF3579.70004@isode.com> Date: Thu, 02 Dec 2004 09:05:49 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >8). Declared uppercase rights illegal, due to backward compatibility. > >9). Removed MYRIGHTS response code, because David Cridland has pointed >out that there would be a compatibility issue for servers that implement >both 2086upd and ACL, caused by issue # 8. I don't understand the logic on this. If an existing server gives a meaning to uppercase rights other than "same as the lowercase" then it is not compliant with the ACL RFC, which reserves all letters for standards-track extensions. On top of that, how could the appearance of such illegal rights in a new MYRIGHTS response code be more of a problem than their appearance in other ACL responses? The ban applies to the ACL commands too... (Did I miss this on the list?) >10). Updated the description of rights required for the DELETE command >to read: > > DELETE - "x" right on the mailbox. Note, that some servers don't allow > to delete a non-empty mailbox. If this is the case, the user > also need both "e" and "t" rights, in order to make the mailbox > empty first. Is this saying that some servers, when told to DELETE a non-empty mailbox, must internally perform STORE and EXPUNGE commands, such that the DELETE will fail if the user has the "x" right but not both the "e" and "t" rights? Or is this saying that some servers will fail a DELETE of a non-empty mailbox and that clients MAY work around this brokeness by doing the STORE and EXPUNGE themselves? At least in the latter case, the "r" right would also be required. ("Note that..." doesn't take a comma. That should be fixed in a couple other places in the draft.) Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2FWJua053734; Thu, 2 Dec 2004 07:32:19 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2FWJ7w053733; Thu, 2 Dec 2004 07:32:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2FWHGh053455 for ; Thu, 2 Dec 2004 07:32:18 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 2 Dec 2004 15:32:11 +0000 Message-ID: <41AF3579.70004@isode.com> Date: Thu, 02 Dec 2004 15:32:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: IMAP Extensions WG Subject: Changes to the 2086upd draft MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've just submitted a new revision of 2086upd. I've done the following changes to the document: 1). Redefined "c" as a virtual right, added "k" right that controls CREATE. "c" can be "kx" or just "k", depending on a server implementation. (Issue raised by Ken Murchison). A new section was created to talk about this, text was rewritten. Please check the section 3.1.1. in the latest draft. 2). Add the rest of 2086 (commands/responses) to the 2086upd (new section 4) as suggested by Chris Newman. BNF was changed to ABNF in the process. 3). Moved description of standard rights into a separate subsection of section 3. This will make it easier to reference in ACL2. 4). Changed "mailbox" to "mailbox name" in a few places. An ACL can apply to a non-selectable mailbox, so I thought that the term "mailbox name" would be more appropriate. 5). Added "UTF-8 + SASLPrep" as per Chris' comment (section 4): Servers, when processing a command that have an authentication identifier as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), SHOULD first prepare the received identifier using "SASLprep" profile [SASLprep] of the "stringprep" algorithm [StringPrep]. If the preparation of the identifier fails or results in an empty string, the server MUST refuse to perform the command with a BAD response. 6). Added text about handling of unrecognized rights, as suggested by Philip Guenther: In section talking about SETACL: Note, that an unrecognized right MUST cause the command to return the BAD response. In particular, server MUST NOT silently ignore unrecognized rights. And added the following examples: Example: C: A001 SETACL INBOX.Drafts Chris lrswicda S: A001 OK Setacl complete C: A035 SETACL INBOX.Drafts John lrQswicda S: A035 BAD Uppercase rights are not allowed C: A036 SETACL INBOX.Drafts John lrqswicda S: A036 BAD The q right is not supported 7). Added few clarifications about identifier canonicalization as suggested by Chris Newman: In section 4.3. GETACL command: Some implementations may permit multiple forms of an authentication identifier to reference the same IMAP account. Usually, such implementations will have a canonical form that is stored internally. An ACL response caused by an GETACL command may include a canonicalized form of the authentication identifier which might be different from the one used in the corresponding SETACL command. In section 4.4. LISTRIGHTS command: Some implementations may permit multiple forms of an authentication identifier to reference the same IMAP account. Usually, such implementations will have a canonical form that is stored internally. A LISTRIGHTS response caused by a LISTRIGHTS command MUST always return the same form of an authentication identifier as specified by the client. This is to allow the client to correlate the response with the command. 8). Declared uppercase rights illegal, due to backward compatibility. 9). Removed MYRIGHTS response code, because David Cridland has pointed out that there would be a compatibility issue for servers that implement both 2086upd and ACL, caused by issue # 8. 10). Updated the description of rights required for the DELETE command to read: DELETE - "x" right on the mailbox. Note, that some servers don't allow to delete a non-empty mailbox. If this is the case, the user also need both "e" and "t" rights, in order to make the mailbox empty first. The DELETE command MUST delete the ACL associated with the deleted mailbox. Is it Ok with everyone? 11). Added IANA considerations section. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJRHuU015471; Thu, 30 Dec 2004 11:27:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUJRHtw015470; Thu, 30 Dec 2004 11:27:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJRG0E015385 for ; Thu, 30 Dec 2004 11:27:16 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBUJQraa023155 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Dec 2004 11:26:53 -0800 In-Reply-To: <41D453AE.2040806@alussinan.org> References: <41D272B6.5070706@alussinan.org> <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> <41D453AE.2040806@alussinan.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org From: Lisa Dusseault Subject: Re: Storing annotations colours on IMAP servers Date: Thu, 30 Dec 2004 11:26:47 -0800 To: kael X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I imagine users wouldn't define annotations in any case; client developers would, and as you suggest, it's possible to standardize a name for the colour annotation as well as a syntax. That work isn't within the charter of this WG but this is probably a decent place to try to drum up participation. I can't think of any way to synchronize colours with current MUAs. They're already deployed with support only for adding their own colouring and storing it locally, as you illustrate with Thunderbird and Mulberry. Lisa On Dec 30, 2004, at 11:14 AM, kael wrote: > On 30.12.2004 19:17, Lisa Dusseault wrote: >> The annotate draft >> > -11.txt> allows client-specific annotations to be added to the mail >> store, if the server supports it. You could either define a >> proprietary annotation (and not share colour information with other >> clients, but make it available to be synchronized via the server) or >> work out some agreed scheme which other clients could use as well. > > How could colors be synchronized with (current) MUAs ? > > Actually, I was thinking that IMAP servers could have the ability to > store that kind of information _by default_ which could help to make > "gains productivity". > > Users would have neither to define annotations name nor their color > each time they configure a MUA. > > This page http://researchweb.watson.ibm.com/history/index.htm gave me > the idea - visualization tools are very useful when they use colors. > > Currently, it's great to use IMAP: nomad users configure the MUA and > get all their emails. But each time, users have to re-configure > keywords name and colors - personal experience with Mulberry and > Thunderbird's labels, unfortunately not interoperable (or compatible > ?). > > So waiting for the /ACAP Renaissance/, maybe IMAP could help and > annotations colors could be standardized - maybe as "attributes" ? > > -- > kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us > > "We're in the process of creating a planetary nervous system" > _The network is the blog_ by Jon Udell - > http://weblog.infoworld.com/udell/2004/12/17.html#a1136 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJFVSv097972; Thu, 30 Dec 2004 11:15:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUJFVCb097971; Thu, 30 Dec 2004 11:15:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUJFUfd097939 for ; Thu, 30 Dec 2004 11:15:31 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix3-1.free.fr (Postfix) with ESMTP id E3D931734B3; Thu, 30 Dec 2004 20:15:24 +0100 (CET) Message-ID: <41D453AE.2040806@alussinan.org> Date: Thu, 30 Dec 2004 20:14:54 +0100 From: kael User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: ietf-imapext@imc.org Subject: Re: Storing annotations colours on IMAP servers References: <41D272B6.5070706@alussinan.org> <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> In-Reply-To: <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 30.12.2004 19:17, Lisa Dusseault wrote: > The annotate draft > -11.txt> allows client-specific annotations to be added to the mail > store, if the server supports it. You could either define a > proprietary annotation (and not share colour information with other > clients, but make it available to be synchronized via the server) or > work out some agreed scheme which other clients could use as well. How could colors be synchronized with (current) MUAs ? Actually, I was thinking that IMAP servers could have the ability to store that kind of information _by default_ which could help to make "gains productivity". Users would have neither to define annotations name nor their color each time they configure a MUA. This page http://researchweb.watson.ibm.com/history/index.htm gave me the idea - visualization tools are very useful when they use colors. Currently, it's great to use IMAP: nomad users configure the MUA and get all their emails. But each time, users have to re-configure keywords name and colors - personal experience with Mulberry and Thunderbird's labels, unfortunately not interoperable (or compatible ?). So waiting for the /ACAP Renaissance/, maybe IMAP could help and annotations colors could be standardized - maybe as "attributes" ? -- kael -- http://kevan.org/extispicious.cgi?name=ubi.quito.us "We're in the process of creating a planetary nervous system" _The network is the blog_ by Jon Udell - http://weblog.infoworld.com/udell/2004/12/17.html#a1136 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUIINQM080945; Thu, 30 Dec 2004 10:18:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUIIN3W080944; Thu, 30 Dec 2004 10:18:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUIIMxa080932 for ; Thu, 30 Dec 2004 10:18:22 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBUII1aa018455 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Dec 2004 10:18:01 -0800 In-Reply-To: <41D272B6.5070706@alussinan.org> References: <41D272B6.5070706@alussinan.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FE555B4-5A8F-11D9-819C-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org From: Lisa Dusseault Subject: Re: Storing annotations colours on IMAP servers Date: Thu, 30 Dec 2004 10:17:54 -0800 To: kael X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The annotate draft allows client-specific annotations to be added to the mail store, if the server supports it. You could either define a proprietary annotation (and not share colour information with other clients, but make it available to be synchronized via the server) or work out some agreed scheme which other clients could use as well. Lisa On Dec 29, 2004, at 1:02 AM, kael wrote: > > Hello, > > Could annotations (and keywords) colours be stored on IMAP servers ? > > Thank you very much. > > -- > kael > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBT93P2T062337; Wed, 29 Dec 2004 01:03:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBT93PW0062336; Wed, 29 Dec 2004 01:03:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBT93OvO061877 for ; Wed, 29 Dec 2004 01:03:25 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix3-2.free.fr (Postfix) with ESMTP id 814D9C110; Wed, 29 Dec 2004 10:03:11 +0100 (CET) Message-ID: <41D272B6.5070706@alussinan.org> Date: Wed, 29 Dec 2004 10:02:46 +0100 From: kael User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Storing annotations colours on IMAP servers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Could annotations (and keywords) colours be stored on IMAP servers ? Thank you very much. -- kael Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBSJMh2K010177; Tue, 28 Dec 2004 11:22:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBSJMhIW010176; Tue, 28 Dec 2004 11:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBSJMhcd010005 for ; Tue, 28 Dec 2004 11:22:43 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBSJMbaa023183 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 28 Dec 2004 11:22:38 -0800 Mime-Version: 1.0 (Apple Message framework v619) To: IMAP Extensions WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-4--746987174 From: Lisa Dusseault Subject: Fwd: Interim Meeting for IMAPEXT Date: Tue, 28 Dec 2004 11:22:27 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4--746987174 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I got the interim meeting announcement in just under the wire... *whew* Please continue to let me know if you plan to attend or what you'd like to discuss. So far, Barry Leiba, Randy Gellens, Alexey Melnikov and I are on the side of probably attending, and Mark and Cyrus on the side of probably not attending. That means we'll have all the authors of LISTEXT and half the authors of ANNOTATE, available to heckle them about their draft lateness :) We may also discuss 2086upd but only if something surprising turns up. So far it looks like the last call is generating some changes but nothing requiring a reset. Stephane Maes is kindly looking into letting us use the same Oracle space that the Lemonade WG is using. Lisa Begin forwarded message: > From: Lisa Dusseault > Date: December 21, 2004 11:31:05 AM PST > To: IETF-Announce@ietf.org > Cc: Subject: Interim Meeting for IMAPEXT > > We are organizing an interim meeting for IMAPEXT in the San Francisco > Bay Area for the afternoon of Jan 20. (The meeting location and time > will be alongside the LEMONADE WG interim meeting which has an > overlapping membership). > > I've already announced this intent on the IMAPEXT mailing list and > would like to announce it more widely even though we don't as yet know > the exact location. > > Scott Hollenbeck has indicated his approval. > > Location: TBD, near San Francisco/Redwood Shores, CA > Date: Jan 20, 2:00 pm to 5:00 pm > Hotel: See LEMONADE WG interim meeting information > > Agenda (Draft) > =========== > > - resolve ANNOTATE open issues with authors > - Discuss LISTEXT extensions > - Resume work on ACL draft > > > --Thanks, > Lisa Dusseault > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-4--746987174 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I got the interim meeting announcement in just under the wire... *whew* Please continue to let me know if you plan to attend or what you'd like to discuss. So far, Barry Leiba, Randy Gellens, Alexey Melnikov and I are on the side of probably attending, and Mark and Cyrus on the side of probably not attending. That means we'll have all the authors of LISTEXT and half the authors of ANNOTATE, available to heckle them about their draft lateness :) We may also discuss 2086upd but only if something surprising turns up. So far it looks like the last call is generating some changes but nothing requiring a reset. Stephane Maes is kindly looking into letting us use the same Oracle space that the Lemonade WG is using. Lisa Begin forwarded message: 0000,0000,0000From: Lisa Dusseault < 0000,0000,0000Date: December 21, 2004 11:31:05 AM PST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: Subject: Interim Meeting for IMAPEXT We are organizing an interim meeting for IMAPEXT in the San Francisco Bay Area for the afternoon of Jan 20. (The meeting location and time will be alongside the LEMONADE WG interim meeting which has an overlapping membership). I've already announced this intent on the IMAPEXT mailing list and would like to announce it more widely even though we don't as yet know the exact location. Scott Hollenbeck has indicated his approval. Location: TBD, near San Francisco/Redwood Shores, CA Date: Jan 20, 2:00 pm to 5:00 pm Hotel: See LEMONADE WG interim meeting information Agenda (Draft) =========== - resolve ANNOTATE open issues with authors - Discuss LISTEXT extensions - Resume work on ACL draft --Thanks, Lisa Dusseault _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-4--746987174-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBPCQjoe063997; Sat, 25 Dec 2004 04:26:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBPCQjWZ063995; Sat, 25 Dec 2004 04:26:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBPCQikq063706 for ; Sat, 25 Dec 2004 04:26:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 25 Dec 2004 12:26:37 +0000 Message-ID: <41CD4429.5000803@isode.com> Date: Sat, 25 Dec 2004 10:42:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Wed, 8 Dec 2004, Lisa Dusseault wrote: > >> I call your attention to this draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt > > Sorry I've been absent from the list -- I've been rearranging my life > for the last few months. Its likely I'd be able to make the interim > meeting if it happens. > > I'm really glad to see this work being done :) > > 1 note: > > 3) > A server implementation conformant to this document MUST also return > rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability > response. > > The ABNF for this indicates that digits are also allowed, yet digits > are technically "defined" as "optional" in RFC2086. Can this be > clarified to indicate that it includes only optional rights that are > implemented by the server, or that this applies to only standard > rights (and thus the ABNF is fixed). > > I'm not convinced that the client is able to do anything with > knowledge of optional rights that are implemented by the server > without more context, and since they are already defined in 2086, I > think I lean towards the later, but I'm willing to hear other opinions. Ok, here is my change to address this issue: In section 3: A server implementation conformant to this document MUST also return rights (see below) not defined in section 3.2 in the "RIGHTS=" capability. Added new section 3.2: 3.2. Rights defined in RFC 2086. For convenience, this section lists the rights which were defined in the RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights ("0" .. "9"). The listed rights MUST NOT be returned in the "RIGHTS=" capability string. Updated ABNF: new_rights = 1*LOWER_ALPHA ;; MUST include "t", "e", "x" and "k". ;; MUST NOT include standard rights listed ;; in section 3.2 ... rights_capa = "RIGHTS=" new_rights ;; RIGHTS=... capability Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBOBIqYZ000957; Fri, 24 Dec 2004 03:18:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBOBIqm7000941; Fri, 24 Dec 2004 03:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBOBIkRO000715 for ; Fri, 24 Dec 2004 03:18:51 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 24 Dec 2004 11:18:43 +0000 Message-ID: <41CBFB0D.7030501@isode.com> Date: Fri, 24 Dec 2004 11:18:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> <41C9E8E1.2040206@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Wed, 22 Dec 2004, Alexey Melnikov wrote: > >>> 3) >>> A server implementation conformant to this document MUST also return >>> rights (see below) not defined in RFC 2086 in the "RIGHTS=" >>> capability >>> response. >>> >>> The ABNF for this indicates that digits are also allowed, yet digits >>> are technically "defined" as "optional" in RFC2086. Can this be >>> clarified to indicate that it includes only optional rights that are >>> implemented by the server, or that this applies to only standard >>> rights (and thus the ABNF is fixed). >>> >>> I'm not convinced that the client is able to do anything with >>> knowledge of optional rights that are implemented by the server >>> without more context, and since they are already defined in 2086, I >>> think I lean towards the later, but I'm willing to hear other opinions. >> >> The latter sounds better to me. Do you want me to clarify the text or >> do you want tighter ABNF as well? > > I don't see a reason for the ABNF to allow digits when the text does not. Ok, but I will not explicitly prohibit in ABNF rights defined in 2086. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJHfPM031881; Thu, 23 Dec 2004 11:17:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNJHfmB031880; Thu, 23 Dec 2004 11:17:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJHeii031836 for ; Thu, 23 Dec 2004 11:17:40 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX46.andrew.cmu.edu (UNIX46.andrew.cmu.edu [128.2.13.176]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id iBNJHegv026926; Thu, 23 Dec 2004 14:17:40 -0500 Date: Thu, 23 Dec 2004 14:17:40 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) In-Reply-To: <41C9E8E1.2040206@isode.com> Message-ID: References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> <41C9E8E1.2040206@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 22 Dec 2004, Alexey Melnikov wrote: >> 3) >> A server implementation conformant to this document MUST also return >> rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability >> response. >> >> The ABNF for this indicates that digits are also allowed, yet digits are >> technically "defined" as "optional" in RFC2086. Can this be clarified to >> indicate that it includes only optional rights that are implemented by the >> server, or that this applies to only standard rights (and thus the ABNF is >> fixed). >> >> I'm not convinced that the client is able to do anything with knowledge of >> optional rights that are implemented by the server without more context, >> and since they are already defined in 2086, I think I lean towards the >> later, but I'm willing to hear other opinions. > > The latter sounds better to me. Do you want me to clarify the text or do you > want tighter ABNF as well? I don't see a reason for the ABNF to allow digits when the text does not. -Rob ------------------------------------------------------------------------- Rob Siemborski | PGP:0x5CE32FCC | rjs3@andrew.cmu.edu -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJ4urY017690; Thu, 23 Dec 2004 11:04:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNJ4uIG017688; Thu, 23 Dec 2004 11:04:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJ4phl017451 for ; Thu, 23 Dec 2004 11:04:53 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 23 Dec 2004 19:04:29 +0000 Message-ID: <41C9E8E1.2040206@isode.com> Date: Wed, 22 Dec 2004 21:36:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > 1 note: > > 3) > A server implementation conformant to this document MUST also return > rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability > response. > > The ABNF for this indicates that digits are also allowed, yet digits > are technically "defined" as "optional" in RFC2086. Can this be > clarified to indicate that it includes only optional rights that are > implemented by the server, or that this applies to only standard > rights (and thus the ABNF is fixed). > > I'm not convinced that the client is able to do anything with > knowledge of optional rights that are implemented by the server > without more context, and since they are already defined in 2086, I > think I lean towards the later, but I'm willing to hear other opinions. The latter sounds better to me. Do you want me to clarify the text or do you want tighter ABNF as well? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMGhpkF010323; Wed, 22 Dec 2004 08:43:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBMGhoQD010305; Wed, 22 Dec 2004 08:43:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMGhlUj010201 for ; Wed, 22 Dec 2004 08:43:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX47.andrew.cmu.edu (UNIX47.andrew.cmu.edu [128.2.13.177]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id iBMGhlgv023807 for ; Wed, 22 Dec 2004 11:43:47 -0500 Date: Wed, 22 Dec 2004 11:43:47 -0500 (EST) From: Rob Siemborski To: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) In-Reply-To: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> Message-ID: References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 8 Dec 2004, Lisa Dusseault wrote: > I call your attention to this draft: > > http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt Sorry I've been absent from the list -- I've been rearranging my life for the last few months. Its likely I'd be able to make the interim meeting if it happens. I'm really glad to see this work being done :) 1 note: 3) A server implementation conformant to this document MUST also return rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability response. The ABNF for this indicates that digits are also allowed, yet digits are technically "defined" as "optional" in RFC2086. Can this be clarified to indicate that it includes only optional rights that are implemented by the server, or that this applies to only standard rights (and thus the ABNF is fixed). I'm not convinced that the client is able to do anything with knowledge of optional rights that are implemented by the server without more context, and since they are already defined in 2086, I think I lean towards the later, but I'm willing to hear other opinions. -Rob ------------------------------------------------------------------------- Rob Siemborski | PGP:0x5CE32FCC | rjs3@andrew.cmu.edu -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBM92lNH099389; Wed, 22 Dec 2004 01:02:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBM92ljY099388; Wed, 22 Dec 2004 01:02:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBM92jNe099363 for ; Wed, 22 Dec 2004 01:02:46 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.6] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 22 Dec 2004 09:02:41 +0000 Message-ID: <41C89A05.2050302@isode.com> Date: Tue, 21 Dec 2004 21:47:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: IMAP Extensions WG Subject: Re: WG last call for IMAP ACL small-scope changes (RFC2086bis) References: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I call your attention to this draft: > > http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt > > It was extracted from a more ambitious update to IMAP ACLs so it's not > as fresh as it looks from its 02 age. Alexey has some minor edits to > make (which he'll list in reply to this email), but we believe it's > ready for WG last call. > > Because of the current and imminent winter observances and vacations, > last call will go until Jan 4. Happy holidays I-D reading! Ok, here is a list of changes I've done to my copy: 1). Clarified that DELETEACL "fred" doesn't affect the identifier "-fred". New text reads (section 3, second paragraph from the bottom): A DELETEACL of "fred" simply deletes the identifier "fred" from the ACL; it does not affect any rights that the user "fred" may get from another entry in the ACL, in particular it doesn't affect rights granted to the identifier "-fred". The following example was added to the section describing DELETEACL (section 4.2): Example: C: B001 GETACL INBOX S: * ACL INBOX Fred rwipslxeta -Fred wet $team w S: B001 OK Getacl complete C: B002 DELETEACL INBOX Fred S: B002 OK Deleteacl complete C: B003 GETACL INBOX S: * ACL INBOX -Fred wet $team w S: B003 OK Getacl complete 2). Removed several commas when no needed (as per Philip). Also corrected few cases where singular was used instead of plural (as per Ken). 3). Corrected examples in sections 4.3, 4.4 and 4.5: new rights defined in the document were not listed. Fixed examples: In section 4.3: Example: C: A002 GETACL INBOX S: * ACL INBOX Fred rwipsldexta S: A002 OK Getacl complete In section 4.4: Example: C: a001 LISTRIGHTS ~/Mail/saved smith S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte S: a001 OK Listrights completed C: a005 LISTRIGHTS archive.imap anyone S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t e a 0 1 2 3 4 5 6 7 8 9 S: a005 Listrights successful In section 4.5: Example: C: A003 MYRIGHTS INBOX S: * MYRIGHTS INBOX rwiptsldaex S: A003 OK Myrights complete 4). Updated description of rights needed for DELETE command as per question asked by Philip. New description: DELETE - "x" right on the mailbox. Note that some servers don't allow to delete a non-empty mailbox. If this is the case, the user would also need "r", "e" and "t" rights, in order to open the mailbox and empty it. Is this clear enough? 5). Dave has requested that section 6.1.1 shows an example when MYRIGHTS and SELECT commands are pipelined. I've added: Note that in order to get better performance the client may pipeline SELECT and MYRIGHTS commands: C: A142 SELECT INBOX C: A143 MYRIGHTS INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited S: A142 OK [READ-WRITE] SELECT completed S: * MYRIGHTS INBOX lrwis S: A143 OK completed Alexey P.S. Dave also found an issue with LISTRIGHTS command and virtual rights. I will post a separate message on this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB90SF0O005031; Wed, 8 Dec 2004 16:28:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB90SFIQ005030; Wed, 8 Dec 2004 16:28:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB90SFet004987 for ; Wed, 8 Dec 2004 16:28:15 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB90S8aa015092 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Dec 2004 16:28:12 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2F7B8EBF-4979-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: WG last call for IMAP ACL small-scope changes (RFC2086bis) Date: Wed, 8 Dec 2004 16:28:02 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I call your attention to this draft: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt It was extracted from a more ambitious update to IMAP ACLs so it's not as fresh as it looks from its 02 age. Alexey has some minor edits to make (which he'll list in reply to this email), but we believe it's ready for WG last call. Because of the current and imminent winter observances and vacations, last call will go until Jan 4. Happy holidays I-D reading! Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8I28d9033134; Wed, 8 Dec 2004 10:02:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8I28tv033129; Wed, 8 Dec 2004 10:02:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8I28K6032943 for ; Wed, 8 Dec 2004 10:02:08 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB8I22aa000366 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Dec 2004 10:02:04 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <3F2736B6-4943-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: IMAPEXT Interim WG meeting Date: Wed, 8 Dec 2004 10:01:55 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Lemonade WG is getting together in the Bay Area for an interim WG meeting Jan 19 and Jan 20. The Lemonade chairs left the afternoon of Jan 20 unbooked, so we could get together and work on IMAPEXT stuff that afternoon if there's enough interest. I've already checked to see if some of the authors of our drafts can make it and some can. I'll need to get official IESG approval I think, but I thought it would be good to suggest a time and get feedback. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6Cx6oG056166; Mon, 6 Dec 2004 04:59:06 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6Cx6Y4056164; Mon, 6 Dec 2004 04:59:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6Cx4xb055956 for ; Mon, 6 Dec 2004 04:59:05 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 6 Dec 2004 12:58:59 +0000 Message-ID: <41B45792.70000@isode.com> Date: Mon, 06 Dec 2004 12:58:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: What is wrong with UIDPLUS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am forwarding Mark's message so it can be found in IMAPEXT archive. -------- Original Message -------- Subject: Re: [lemonade] URLFETCH Partial Fetches Date: Sun, 5 Dec 2004 11:41:07 -0800 (PST) From: Mark Crispin To: Alexey Melnikov CC: lemonade@ietf.org References: <41B3541D.2000904@isode.com> On Sun, 5 Dec 2004, Alexey Melnikov wrote: > I am curious to know what are the problems with UIDPLUS? Good question, Alexey! I've been taking a long hard look at UIDPLUS lately, as I may have to implement it. UIDPLUS bundles two orthogonal functionalities: the UID EXPUNGE command, and the APPENDUID and COPYUID responses. There is no implementation dependendency between the two; they should not be in the same capability. But the worst part is that APPENDUID and COPYUID are poorly thought out, especially in light of the interaction with MULTIAPPEND. There should have been a single response for all cases, not the current situation where very similar, but not quite the same, responses are used. In some mail stores, certain cases of COPY end up having to be implemented as APPEND internally; this creates an added implementation burden to generate the correct COPYUID. When multiple messages are involved, APPENDUID/COPYUID suffer from the flaw that a set<->set mapping needs to be calculated; the excuse being that if monotonically increasing UIDs are assigned then the response is less chatty than alternatives. It's also an invitation to bugs. There should be an explicit source->destination mapping for each message, not "match this set with that set". In some mail stores, it can be very expensive to return APPENDUID/COPYUID data, *especially* in those cases where the IMAP server vendor does not control the delivery mechanism. In fact, UIDPLUS could be called the FCTGTMSFASS (Force Customers To Get Their Mail Software From A Single Source) extension to IMAP. Since IMAP requires strictly ascending UIDs, it is impossible to assign a UID to a newly APPENDed or COPYed message without assurance than any new mail delivered to the mailbox has also had a UID assigned. Hence FCTGTMSFASS; if the mail delivery agent is from another vendor that assurance may be absent and the IMAP server has to fix things. This, in turn, requires a sort of read/write open that assigns UIDs but doesn't affect \Recent flags or the RECENT count in the next open. That also means that you can't use "no UID was assigned when mailbox opened" to mean \Recent -- the \Recent flag has to be maintained independently. All this is not cheap, although with a lot of extra programming much of the extra cost can be ameliorated. Among other things, this means additional mailbox metadata in order to avoid taking the worst-case fixup path each time. Better would have been to have two new commands that would return new responses (instead of response codes). This would save servers the work if the client does not care (the majority of clients!), and also would have allowed much more flexibility in the response syntax. In conclusion, I believe that UIDPLUS: 1) bundles together things that did not need to be bundled; 2) creates server burdens that often are unnecessary; 3) has a incredibly kludgy design in order to avoid adding new commands and responses. In some ways, the third sin is the worst of all, and caused the other two sins. I've often criticized ACL, but it is well-designed. The problem with is that ACL is a *very* hard problem. The difficulty is *far* worse when you attempt to export external legacy facilities. Similar comments can be made about certain other troublesome extensions (e.g. QUOTA). UIDPLUS, on the other hand, stands out as expediency over good design. I fear that it's much too late to fix it now. We're stuck with the wart. But we can learn from the mistake, and avoid similar mistakes in the future. That I think is the important point to move forward. What seems to be simple and expedient today can have long-term deleterious consequences in the future. It's often difficult, and frustrating!!, to be delayed in discussions on how to do things right when an attractive shortcut seems to exist. It's even more frustrating when deadlines are faced and/or needs are unmet. But the results of doing it right are worth it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3CEcuW017318; Fri, 3 Dec 2004 04:14:38 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3CEcll017316; Fri, 3 Dec 2004 04:14:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3CEaJq017194 for ; Fri, 3 Dec 2004 04:14:37 -0800 (PST) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27818; Fri, 3 Dec 2004 07:14:34 -0500 (EST) Message-Id: <200412031214.HAA27818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-2086upd-02.txt Date: Fri, 03 Dec 2004 07:14:34 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-2086upd-02.txt Pages : 0 Date : 2004-12-2 The ACL (Access Control List) extension (RFC 2086) of the Internet Message Access Protocol (IMAP4rev1) permits mailbox access control lists to be manipulated through the IMAP protocol. This document is a revision of the RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-2086upd-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-2086upd-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-2115345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-2086upd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-2086upd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-2115345.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2HHj3Y060485; Thu, 2 Dec 2004 09:17:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2HHjX0060484; Thu, 2 Dec 2004 09:17:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2HHiAR060469 for ; Thu, 2 Dec 2004 09:17:44 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 2 Dec 2004 17:17:38 +0000 Message-ID: <41AF4E31.2070905@isode.com> Date: Thu, 02 Dec 2004 17:17:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: IMAP Extensions WG Subject: Re: Changes to the 2086upd draft References: <41AF3579.70004@isode.com> <200412021705.iB2H5nfp043854@lab.smi.sendmail.com> In-Reply-To: <200412021705.iB2H5nfp043854@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Alexey Melnikov writes: >... > > >>8). Declared uppercase rights illegal, due to backward compatibility. >> >>9). Removed MYRIGHTS response code, because David Cridland has pointed >>out that there would be a compatibility issue for servers that implement >>both 2086upd and ACL, caused by issue # 8. >> >> > >I don't understand the logic on this. If an existing server gives a >meaning to uppercase rights other than "same as the lowercase" then it >is not compliant with the ACL RFC, which reserves all letters for >standards-track extensions. > >On top of that, how could the appearance of such illegal rights in a new >MYRIGHTS response code be more of a problem than their appearance in >other ACL responses? The ban applies to the ACL commands too... > > A server that supports both ACL and ACL2 would have to lowercase rights in the MYRIGHTS response code. As there is no way for the server to know if the client supports ACL or ACL2, this means that *every* ACL2 server MUST always lowercase rights in MYRIGHTS, which creates a special case for ACL2-only servers. And server implementors can easily miss it. David also pointed out that the client can pipeline SELECT with MYRIGHTS anyway, so we have a workaround for ACL. >(Did I miss this on the list?) > > No, this was off the list discussion between David, Cyrus and myself. >>10). Updated the description of rights required for the DELETE command >>to read: >> >> DELETE - "x" right on the mailbox. Note, that some servers don't allow >> to delete a non-empty mailbox. If this is the case, the user >> also need both "e" and "t" rights, in order to make the mailbox >> empty first. >> >> > >Is this saying that some servers, when told to DELETE a non-empty >mailbox, must internally perform STORE and EXPUNGE commands, such that >the DELETE will fail if the user has the "x" right but not both the "e" >and "t" rights? Or is this saying that some servers will fail a DELETE >of a non-empty mailbox and that clients MAY work around this brokeness >by doing the STORE and EXPUNGE themselves? > > I meant the latter, although there are some existing servers that do the former. >At least in the latter case, the "r" right would also be required. > > Right. >("Note that..." doesn't take a comma. That should be fixed in a couple >other places in the draft.) > > Fixed, thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2H5xvZ052085; Thu, 2 Dec 2004 09:05:59 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2H5xpJ052084; Thu, 2 Dec 2004 09:05:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2H5uIW051956 for ; Thu, 2 Dec 2004 09:05:59 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iB2H5oi5008080 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 2 Dec 2004 09:05:51 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iB2H5oi5008080 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Dp+H8VIQ2DBig13cc679KHRgrlEwzHBM2YoS6+EPV6bMzFFGgVMddAkKBYGSHk+oc GZUmIQ6tqs5DZJAP24lazRMuB4Yx4OzdOR+81pYet+arCBvfc5JiLSX4Hb7LAaIOwGh uczyQxOxaApcWOUF6GbM8AQgnZ8PacI3b4g+xAU= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iB2H5nfp043854; Thu, 2 Dec 2004 09:05:50 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200412021705.iB2H5nfp043854@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: Changes to the 2086upd draft In-reply-to: <41AF3579.70004@isode.com> References: <41AF3579.70004@isode.com> Date: Thu, 02 Dec 2004 09:05:49 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >8). Declared uppercase rights illegal, due to backward compatibility. > >9). Removed MYRIGHTS response code, because David Cridland has pointed >out that there would be a compatibility issue for servers that implement >both 2086upd and ACL, caused by issue # 8. I don't understand the logic on this. If an existing server gives a meaning to uppercase rights other than "same as the lowercase" then it is not compliant with the ACL RFC, which reserves all letters for standards-track extensions. On top of that, how could the appearance of such illegal rights in a new MYRIGHTS response code be more of a problem than their appearance in other ACL responses? The ban applies to the ACL commands too... (Did I miss this on the list?) >10). Updated the description of rights required for the DELETE command >to read: > > DELETE - "x" right on the mailbox. Note, that some servers don't allow > to delete a non-empty mailbox. If this is the case, the user > also need both "e" and "t" rights, in order to make the mailbox > empty first. Is this saying that some servers, when told to DELETE a non-empty mailbox, must internally perform STORE and EXPUNGE commands, such that the DELETE will fail if the user has the "x" right but not both the "e" and "t" rights? Or is this saying that some servers will fail a DELETE of a non-empty mailbox and that clients MAY work around this brokeness by doing the STORE and EXPUNGE themselves? At least in the latter case, the "r" right would also be required. ("Note that..." doesn't take a comma. That should be fixed in a couple other places in the draft.) Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2FWJua053734; Thu, 2 Dec 2004 07:32:19 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2FWJ7w053733; Thu, 2 Dec 2004 07:32:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2FWHGh053455 for ; Thu, 2 Dec 2004 07:32:18 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 2 Dec 2004 15:32:11 +0000 Message-ID: <41AF3579.70004@isode.com> Date: Thu, 02 Dec 2004 15:32:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: IMAP Extensions WG Subject: Changes to the 2086upd draft MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've just submitted a new revision of 2086upd. I've done the following changes to the document: 1). Redefined "c" as a virtual right, added "k" right that controls CREATE. "c" can be "kx" or just "k", depending on a server implementation. (Issue raised by Ken Murchison). A new section was created to talk about this, text was rewritten. Please check the section 3.1.1. in the latest draft. 2). Add the rest of 2086 (commands/responses) to the 2086upd (new section 4) as suggested by Chris Newman. BNF was changed to ABNF in the process. 3). Moved description of standard rights into a separate subsection of section 3. This will make it easier to reference in ACL2. 4). Changed "mailbox" to "mailbox name" in a few places. An ACL can apply to a non-selectable mailbox, so I thought that the term "mailbox name" would be more appropriate. 5). Added "UTF-8 + SASLPrep" as per Chris' comment (section 4): Servers, when processing a command that have an authentication identifier as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), SHOULD first prepare the received identifier using "SASLprep" profile [SASLprep] of the "stringprep" algorithm [StringPrep]. If the preparation of the identifier fails or results in an empty string, the server MUST refuse to perform the command with a BAD response. 6). Added text about handling of unrecognized rights, as suggested by Philip Guenther: In section talking about SETACL: Note, that an unrecognized right MUST cause the command to return the BAD response. In particular, server MUST NOT silently ignore unrecognized rights. And added the following examples: Example: C: A001 SETACL INBOX.Drafts Chris lrswicda S: A001 OK Setacl complete C: A035 SETACL INBOX.Drafts John lrQswicda S: A035 BAD Uppercase rights are not allowed C: A036 SETACL INBOX.Drafts John lrqswicda S: A036 BAD The q right is not supported 7). Added few clarifications about identifier canonicalization as suggested by Chris Newman: In section 4.3. GETACL command: Some implementations may permit multiple forms of an authentication identifier to reference the same IMAP account. Usually, such implementations will have a canonical form that is stored internally. An ACL response caused by an GETACL command may include a canonicalized form of the authentication identifier which might be different from the one used in the corresponding SETACL command. In section 4.4. LISTRIGHTS command: Some implementations may permit multiple forms of an authentication identifier to reference the same IMAP account. Usually, such implementations will have a canonical form that is stored internally. A LISTRIGHTS response caused by a LISTRIGHTS command MUST always return the same form of an authentication identifier as specified by the client. This is to allow the client to correlate the response with the command. 8). Declared uppercase rights illegal, due to backward compatibility. 9). Removed MYRIGHTS response code, because David Cridland has pointed out that there would be a compatibility issue for servers that implement both 2086upd and ACL, caused by issue # 8. 10). Updated the description of rights required for the DELETE command to read: DELETE - "x" right on the mailbox. Note, that some servers don't allow to delete a non-empty mailbox. If this is the case, the user also need both "e" and "t" rights, in order to make the mailbox empty first. The DELETE command MUST delete the ACL associated with the deleted mailbox. Is it Ok with everyone? 11). Added IANA considerations section.