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 i6LJiKZB020494; Wed, 21 Jul 2004 12:44:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJiKvJ020493; Wed, 21 Jul 2004 12:44:20 -0700 (PDT) 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 i6LJiJeY020484 for ; Wed, 21 Jul 2004 12:44:20 -0700 (PDT) (envelope-from dinaras@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 PAA17423; Wed, 21 Jul 2004 15:44:21 -0400 (EDT) Message-Id: <200407211944.PAA17423@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-list-extensions-07.txt Date: Wed, 21 Jul 2004 15:44:21 -0400 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 LIST Command Extensions Author(s) : B. Leiba, A. Melnikov Filename : draft-ietf-imapext-list-extensions-07.txt Pages : 0 Date : 2004-7-21 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-07.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-list-extensions-07.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-list-extensions-07.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-7-21153148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153148.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 i6L3nAiQ024365; Tue, 20 Jul 2004 20:49:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L3nAe0024364; Tue, 20 Jul 2004 20:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L3n5h0024343 for ; Tue, 20 Jul 2004 20:49:10 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from lustre.dyn.wiw.org (unknown [192.168.139.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 70C281BDE7B; Wed, 21 Jul 2004 05:49:10 +0200 (CEST) Received: from prosecco.lustre.dyn.wiw.org ([10.0.0.42]) by lustre.dyn.wiw.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1Bn86G-0003Lq-Ma; Wed, 21 Jul 2004 09:19:00 +0530 Message-Id: Date: Wed, 21 Jul 2004 09:19:14 +0530 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: annotate-10 Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In annotate-10, a client can write private annotations even if it doesn't have write access to the mailbox, and it cannot read shared annotations unless it has write access. That seems strange. The document needs to say why, I think. (Unless the reason is obvious and I got up too early again. The latter certainly is true.) Arnt 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 i6KNuP7n004844; Tue, 20 Jul 2004 16:56:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KNuPub004843; Tue, 20 Jul 2004 16:56:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from PC_hipolito.org (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KNuNNd004836 for ; Tue, 20 Jul 2004 16:56:24 -0700 (PDT) (envelope-from presnick@qualcomm.com) Date: Tue, 20 Jul 2004 18:56:35 -0500 To: "Ietf-imapext" From: "Presnick" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cqsoiaawccfmvfyotomi" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------cqsoiaawccfmvfyotomi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music


----------cqsoiaawccfmvfyotomi Content-Type: application/octet-stream; name="Fish.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Fish.scr" ----------cqsoiaawccfmvfyotomi-- 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 i6KK9JM8087359; Tue, 20 Jul 2004 13:09:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KK9JT4087358; Tue, 20 Jul 2004 13:09:19 -0700 (PDT) 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 i6KK9J0D087351 for ; Tue, 20 Jul 2004 13:09:19 -0700 (PDT) (envelope-from dinaras@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 QAA23882; Tue, 20 Jul 2004 16:09:20 -0400 (EDT) Message-Id: <200407202009.QAA23882@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-annotate-10.txt Date: Tue, 20 Jul 2004 16:09:20 -0400 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 : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-10.txt Pages : 36 Date : 2004-7-20 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-10.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-annotate-10.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-annotate-10.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-7-20155935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155935.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 i6KAKtG1083592; Tue, 20 Jul 2004 03:20:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KAKslM083586; Tue, 20 Jul 2004 03:20:54 -0700 (PDT) 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 i6KAKk2P083479 for ; Tue, 20 Jul 2004 03:20:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 20 Jul 2004 11:23:19 +0100 Message-ID: <40FC3F6A.6060908@isode.com> Date: Mon, 19 Jul 2004 22:38:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Simon Josefsson CC: ietf-imapext@imc.org, imap@u.washington.edu Subject: Re: [lemonade] Implementing drafts References: <54DC93DD84CC5028D7C617EE@PLATO.cyrusoft.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: Simon Josefsson wrote: >Cyrus Daboo writes: > > >>>The draft suggests a new convention for transient IMAP capabilities, >>>which should be used until the document describing an IMAP extension >>>becomes RFC. For example, the transient capability for SASL-IR extension >>>as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be >>>X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for >>>individual submission. >>> >>> >>While I think this is a good idea, I think we could get by with a less >>formal approach. >> I would like to remind people that my draft is not intended as a standard track document, it only tries to establish a convention. >> Specifically it should be left up to individual >>drafts to define the capability string for implementations of that >>specific draft, whilst also indicating what the final (RFC) capability >>string is expected to be. >> >>So for example, the following text (which would be used in the final >>RFC version): >> >>'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] >>implementation which returns "ANNOTATEMORE" as one of the supported >>capabilities in the CAPABILITY command response.' >> >>Would become in the preceeding drafts: >> >>'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] >>implementation which returns "ANNOTATEMORE" as one of the supported >>capabilities in the CAPABILITY command response. This capability >>string will be used when this draft is published as an >>RFC. Experimental implementations of this draft MUST use the >>capability response "X-ANNOTATEMORE-05", and MUST NOT use the >>capability response "ANNOTATEMORE".' >> In this particular case, no matter how many MUSTs you put, I don't think people would listen. This also made me think that it might be better not to declare the final capability name until a particular extension is published as an RFC... >For what it's worth, I tend to agree with Cyrus. One practical >problem with draft-melnikov-imap-transitional-capa-00 is that many >drafts undergo mostly editorial changes, sometimes all the way from >version 00 up to, say, 15, without affecting the actual protocol. > This is valid point. But see also my comment below. >Experimental implementations of that same protocol thus might not >interoperate well, hurting preliminary testing of the protocol, which >works against the motivation for the X-DRAFT-* idea. > An advantage of using the formal procedure established in draft-melnikov-imap-transitional-capa-00 is that it is sufficient for an implementor to know 2 things to construct a required capability name: 1). Base capability name. 2). Name of the draft. The second part is also important for another reason. Let's say I see a capability name "X-ANNOTATEMORE-05". How do I know which draft revision has defined it? Without searching for the string in all revisions of the draft (and one might not have them at hand), this might be a bit problematic. So to some extent the draft is trying to address lack of a registry for transient capabilities. Another advantage is that an implementation (server or client) aware of the convention is now able to support a range of revisions of the same extension: capability strings for all revisions of the same extension start with "X-DRAFT-" prefix and end with "base capability name". To some extent this addresses the issue that Simon has raised. (And you know what, I was actually thinking about adding code to my IMAP server that can list additional capabilities by specifying them in a configuration file. Maybe it is a hack ;-), but it is really not that difficult to do.) >However, I agree with the motivation for the draft. Preliminary >testing is important, and often lead to improvements of the drafts. >But I feel recommending IMAP capability document authors to use the >text Cyrus suggested, would be more flexible, and would even simplify >interoperability testing over Alexey's proposal. > >Writing down the above recommendations in at least a draft is probably >required, if any IMAP capability authors are ever going to be aware of >them, though. > At least we have an agreement on this part. >Regards, >Simon > >(With apologies if I misunderstood >draft-melnikov-imap-transitional-capa-00, I haven't read it in >detail.) > > Alexey 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 i6JJqE16027831; Mon, 19 Jul 2004 12:52:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JJqEeB027830; Mon, 19 Jul 2004 12:52:14 -0700 (PDT) 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 i6JJqDmn027824 for ; Mon, 19 Jul 2004 12:52:13 -0700 (PDT) (envelope-from dinaras@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 PAA19275; Mon, 19 Jul 2004 15:52:15 -0400 (EDT) Message-Id: <200407191952.PAA19275@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-acl-10.txt Date: Mon, 19 Jul 2004 15:52:15 -0400 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-acl-10.txt Pages : 10 Date : 2004-7-19 The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.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-acl-10.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-acl-10.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-7-19152605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152605.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 i6J9vB8a010111; Mon, 19 Jul 2004 02:57:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6J9vBIJ010109; Mon, 19 Jul 2004 02:57:11 -0700 (PDT) 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 i6J9vAsk010074 for ; Mon, 19 Jul 2004 02:57:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 19 Jul 2004 10:59:54 +0100 Message-ID: <40FB9AF1.4070900@isode.com> Date: Mon, 19 Jul 2004 10:57:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: ACL draft expired... References: 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: Mark Crispin wrote: > ...it needs to be resubmitted... I've resubmitted it. No major changes: 1). Removed POSTADDRESS (now a separate draft) 2). Fixed few examples 3). Updated Copyright/IPR as per new IETF requirements. Alexey 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 i6H09Ie5070271; Fri, 16 Jul 2004 17:09:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6H09I2k070270; Fri, 16 Jul 2004 17:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H09HsM070264 for ; Fri, 16 Jul 2004 17:09:17 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i6H09N4w030088 for ; Fri, 16 Jul 2004 17:09:23 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i6H09MsE015969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 16 Jul 2004 17:09:22 -0700 Date: Fri, 16 Jul 2004 17:09:23 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: ACL draft expired... Message-ID: Organization: Networks & Distributed Computing 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: ...it needs to be resubmitted... -- 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 i6GIp855018133; Fri, 16 Jul 2004 11:51:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GIp8QK018132; Fri, 16 Jul 2004 11:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIp1uj018103 for ; Fri, 16 Jul 2004 11:51:02 -0700 (PDT) (envelope-from ietf-ietf-imapext@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BlXnV-000136-00 for ; Fri, 16 Jul 2004 20:51:05 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2004 20:51:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2004 20:51:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-imapext@imc.org From: Simon Josefsson Subject: Re: [lemonade] Implementing drafts Date: Fri, 16 Jul 2004 19:39:56 +0200 Lines: 56 Message-ID: References: <54DC93DD84CC5028D7C617EE@PLATO.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:uvMWIh5e3ercDXV2Ajk4pJsulT4= Cc: imap@u.washington.edu Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: >> The draft suggests a new convention for transient IMAP capabilities, >> which should be used until the document discribing an IMAP extension >> becomes RFC. For example, the transient capability for SASL-IR extension >> as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be >> X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for >> individual submission. > > While I think this is a good idea, I think we could get by with a less > formal approach. Specifically it should be left up to individual > drafts to define the capability string for implementations of that > specific draft, whilst also indicating what the final (RFC) capability > string is expected to be. > > So for example, the following text (which would be used in the final > RFC version): > > 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] > implementation which returns "ANNOTATEMORE" as one of the supported > capabilities in the CAPABILITY command response.' > > Would become in the preceeding drafts: > > 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] > implementation which returns "ANNOTATEMORE" as one of the supported > capabilities in the CAPABILITY command response. This capability > string will be used when this draft is published as an > RFC. Experimental implementations of this draft MUST use the > capability response "X-ANNOTATEMORE-05", and MUST NOT use the > capability response "ANNOTATEMORE".' For what it's worth, I tend to agree with Cyrus. One practical problem with draft-melnikov-imap-transitional-capa-00 is that many drafts undergo mostly editorial changes, sometimes all the way from version 00 up to, say, 15, without affecting the actual protocol. Experimental implementations of that same protocol thus might not interoperate well, hurting preliminary testing of the protocol, which works against the motivation for the X-DRAFT-* idea. However, I agree with the motivation for the draft. Preliminary testing is important, and often lead to improvements of the drafts. But I feel recommending IMAP capability document authors to use the text Cyrus suggested, would be more flexible, and would even simplify interoperability testing over Alexey's proposal. Writing down the above recommendations in at least a draft is probably required, if any IMAP capability authors are ever going to be aware of them, though. Regards, Simon (With apologies if I misunderstood draft-melnikov-imap-transitional-capa-00, I haven't read it in detail.) 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 i6GH7aSo000402; Fri, 16 Jul 2004 10:07:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GH7aPV000401; Fri, 16 Jul 2004 10:07:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GH7Zic000395 for ; Fri, 16 Jul 2004 10:07:35 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i6GGubo3009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2004 12:56:38 -0400 Date: Fri, 16 Jul 2004 13:09:49 -0400 From: Cyrus Daboo To: lemonade@ietf.org, IMAP Extensions WG , imap@u.washington.edu Subject: Re: [lemonade] Implementing drafts Message-ID: <54DC93DD84CC5028D7C617EE@PLATO.cyrusoft.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, July 16, 2004 2:58 PM +0100 Alexey Melnikov wrote: >> I don't think deployment of code by itself should freeze a draft -- if >> there are substantial problems with it that appear after deployment, >> these need to be addressed. That doesn't appear to be the case here. > > I wrote a draft that tries to address this problem to some extend: > http://www.melnikov.ca/mel/Drafts/draft-melnikov-imap-transitional-capa-0 > 0.txt > > (I've submitted it before July 12, but I am not sure if it gets > published, as I forgot to add IPR disclosure text) > > The draft suggests a new convention for transient IMAP capabilities, > which should be used until the document discribing an IMAP extension > becomes RFC. For example, the transient capability for SASL-IR extension > as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be > X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for > individual submission. While I think this is a good idea, I think we could get by with a less formal approach. Specifically it should be left up to individual drafts to define the capability string for implementations of that specific draft, whilst also indicating what the final (RFC) capability string is expected to be. So for example, the following text (which would be used in the final RFC version): 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] implementation which returns "ANNOTATEMORE" as one of the supported capabilities in the CAPABILITY command response.' Would become in the preceeding drafts: 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] implementation which returns "ANNOTATEMORE" as one of the supported capabilities in the CAPABILITY command response. This capability string will be used when this draft is published as an RFC. Experimental implementations of this draft MUST use the capability response "X-ANNOTATEMORE-05", and MUST NOT use the capability response "ANNOTATEMORE".' Even if we decide to stick with the formal approach, I think your draft should explicitly state that the final (RFC) capability MUST NOT be used, and should explicitly spell out what the capability string for the draft actually is, similar to the above text. -- Cyrus Daboo 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 i6GDwgbB070022; Fri, 16 Jul 2004 06:58:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GDwgWT070021; Fri, 16 Jul 2004 06:58:42 -0700 (PDT) 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 i6GDwfRm070007 for ; Fri, 16 Jul 2004 06:58:41 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 16 Jul 2004 15:01:00 +0100 Message-ID: <40F7DF00.8000004@isode.com> Date: Fri, 16 Jul 2004 14:58:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Rob Siemborski CC: imap@u.washington.edu, lemonade@ietf.org, IMAP Extensions WG Subject: Implementing drafts References: <40F6B9D2.6020709@isode.com> <40F6C2ED.6010406@oceana.com> <40F6FF12.5040703@isode.com> <5IPRfSFgXVPI3bG2y0VOvA.md5@prosecco.lustre.dyn.wiw.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: [Sorry for cross-post, please limit your replies to IMAPEXT] Rob Siemborski wrote: > On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote: > >> (I'll be happy with either, though. And I wish people would mention >> it on the list when they freeze a draft by releasing code widely.) > > (oh -- Squirrelmail [and I presume pine] have also deployed this on > the client side). > > The problem is often times the only way to fully vet a draft is to > implement and actually use code with it. There are a few significant > problems in a number of IMAP extensions that weren't fully implemented > by anyone before they became RFCs. > > On the other hand, great progress was made on ANNOTATEMORE only after > Cyrus implemeted and deployed early drafts of it (and then had to go > back and fix it when the syntax was substantially improved after > problems were found). > > I don't think deployment of code by itself should freeze a draft -- if > there are substantial problems with it that appear after deployment, > these need to be addressed. That doesn't appear to be the case here. I wrote a draft that tries to address this problem to some extend: http://www.melnikov.ca/mel/Drafts/draft-melnikov-imap-transitional-capa-00.txt (I've submitted it before July 12, but I am not sure if it gets published, as I forgot to add IPR disclosure text) The draft suggests a new convention for transient IMAP capabilities, which should be used until the document discribing an IMAP extension becomes RFC. For example, the transient capability for SASL-IR extension as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for individual submission. Alexey 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 i6EJFSnD055220; Wed, 14 Jul 2004 12:15:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJFSRM055219; Wed, 14 Jul 2004 12:15:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJFRQq055213 for ; Wed, 14 Jul 2004 12:15:27 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6EJFSbR003280; Wed, 14 Jul 2004 15:15:28 -0400 Date: Wed, 14 Jul 2004 15:15:27 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: Ken Murchison , Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME In-Reply-To: Message-ID: References: <40F54519.5040301@oceana.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, 14 Jul 2004, Arnt Gulbrandsen wrote: > > Uh. There's even more tricky & devious behaviour here. > > What happens if INBOX is an alias for, say, /user/, and > /user/ is renamed? The same as if INBOX is renamed, or something > different? RFC 3501 only has this peculiar behavior for the case of RENAME INBOX. I'd say that RENAME /user/foo /user/bar should result in /user/foo not existing afterwards (provided the server allows the rename at all). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----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 i6EIPZbS047164; Wed, 14 Jul 2004 11:25:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIPZTl047163; Wed, 14 Jul 2004 11:25:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6EIPRMS047123 for ; Wed, 14 Jul 2004 11:25:32 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from lustre.dyn.wiw.org (unknown [192.168.139.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 2BEBA1BDE81; Wed, 14 Jul 2004 20:25:27 +0200 (CEST) Received: from prosecco.lustre.dyn.wiw.org ([10.0.0.5]) by lustre.dyn.wiw.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1BkoRR-0005QY-Pi; Wed, 14 Jul 2004 23:55:17 +0530 Message-Id: Date: Wed, 14 Jul 2004 23:55:18 +0530 From: Arnt Gulbrandsen To: Ken Murchison Subject: Re: ANNOTATEMORE and RENAME Cc: Cyrus Daboo , IMAP Extensions WG References: <40F54519.5040301@oceana.com> In-Reply-To: <40F54519.5040301@oceana.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Uh. There's even more tricky & devious behaviour here. What happens if INBOX is an alias for, say, /user/, and /user/ is renamed? The same as if INBOX is renamed, or something different? Ken Murchison writes: > 1. The annotations get renamed (e.g. move) to the new mailbox. > > 2. The annotations stay with the INBOX, since we're not really "renaming" it. > > 3. The annotations stay with the INBOX, and the new mailbox gets a > copy of the annotations from the INBOX. > > IMO, options 2 and 3 seem the most reasonable. I agree. To me the most important facet is that renaming /user/arnt and INBOX should affect the annotations in the same way; it tentatively seems that 3 is the best when viewed from both points of view. Arnt 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 i6EFjSS6015738; Wed, 14 Jul 2004 08:45:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFjSOU015737; Wed, 14 Jul 2004 08:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFjRkR015660 for ; Wed, 14 Jul 2004 08:45:28 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i6EFs5c9001006; Wed, 14 Jul 2004 11:54:05 -0400 (EDT) Message-ID: <40F55590.7080306@oceana.com> Date: Wed, 14 Jul 2004 11:47:28 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ken Murchison CC: Alexey Melnikov , Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME References: <40F54519.5040301@oceana.com> <40F549DA.1090605@isode.com> <40F550C9.6040901@oceana.com> In-Reply-To: <40F550C9.6040901@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > I think this is in the implementation and user expectation. I look at > renaming INBOX as an archiving procedure, where my INBOX doesn't move, > but the messages are moved into a new mailbox. In this case, I'd be > somewhat upset if I had to recreate the annotations on my INBOX. > > Perhaps 3 is the best choice as it doesn't both. ^^^^^^^ oops! Obviously, I meant DOES both. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp 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 i6EFh6H9014775; Wed, 14 Jul 2004 08:43:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFh64d014773; Wed, 14 Jul 2004 08:43:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFh4gC014743 for ; Wed, 14 Jul 2004 08:43:04 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6EFh2kp025550; Wed, 14 Jul 2004 11:43:02 -0400 Date: Wed, 14 Jul 2004 11:43:00 -0400 (EDT) From: Rob Siemborski To: Ken Murchison cc: Alexey Melnikov , Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME In-Reply-To: <40F550C9.6040901@oceana.com> Message-ID: References: <40F54519.5040301@oceana.com> <40F549DA.1090605@isode.com> <40F550C9.6040901@oceana.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, 14 Jul 2004, Ken Murchison wrote: >>> 3. The annotations stay with the INBOX, and the new mailbox gets a copy >>> of the annotations from the INBOX. [snip] >> Actually, I think options 1 and 3 seem the most reasonable. When INBOX is >> renamed a new INBOX is created. Surely a user will want to see there >> annotations move to the new mailbox (for consistency with other cases). > > I think this is in the implementation and user expectation. I look at > renaming INBOX as an archiving procedure, where my INBOX doesn't move, but > the messages are moved into a new mailbox. In this case, I'd be somewhat > upset if I had to recreate the annotations on my INBOX. > > Perhaps 3 is the best choice as it doesn't both. 3 strikes me as the best choice with the least potential for user surprise (note that a user may not even know that their client is "renaming" the INBOX, just 'archiving' it). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----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 i6EFP3XB006977; Wed, 14 Jul 2004 08:25:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFP30J006976; Wed, 14 Jul 2004 08:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFP2i3006927 for ; Wed, 14 Jul 2004 08:25:02 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i6EFXgdq032495; Wed, 14 Jul 2004 11:33:42 -0400 (EDT) Message-ID: <40F550C9.6040901@oceana.com> Date: Wed, 14 Jul 2004 11:27:05 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME References: <40F54519.5040301@oceana.com> <40F549DA.1090605@isode.com> In-Reply-To: <40F549DA.1090605@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ken Murchison wrote: > >> Cyrus, >> >> In the process of fixing a subtle bug (#2441) in the Cyrus IMAP RENAME >> code, it occurred to me that the ANNOTATEMORE draft doesn't discuss >> the interaction with RENAME, specifically the special case of renaming >> an INBOX. >> >> I believe its obvious that when renaming non-INBOX mailboxes that the >> annotations should move with the mailboxes, but what should happen >> when an INBOX is renamed? I see three approaches: >> >> 1. The annotations get renamed (e.g. move) to the new mailbox. >> >> 2. The annotations stay with the INBOX, since we're not really >> "renaming" it. >> >> 3. The annotations stay with the INBOX, and the new mailbox gets a >> copy of the annotations from the INBOX. >> >> >> IMO, options 2 and 3 seem the most reasonable. > > >> Thoughts? > > > Actually, I think options 1 and 3 seem the most reasonable. When INBOX > is renamed a new INBOX is created. Surely a user will want to see there > annotations move to the new mailbox (for consistency with other cases). I think this is in the implementation and user expectation. I look at renaming INBOX as an archiving procedure, where my INBOX doesn't move, but the messages are moved into a new mailbox. In this case, I'd be somewhat upset if I had to recreate the annotations on my INBOX. Perhaps 3 is the best choice as it doesn't both. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp 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 i6EEvheG094672; Wed, 14 Jul 2004 07:57:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEvhfA094671; Wed, 14 Jul 2004 07:57:43 -0700 (PDT) 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 i6EEvgH7094656 for ; Wed, 14 Jul 2004 07:57:43 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 14 Jul 2004 15:59:54 +0100 Message-ID: <40F549DA.1090605@isode.com> Date: Wed, 14 Jul 2004 15:57:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Ken Murchison CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME References: <40F54519.5040301@oceana.com> In-Reply-To: <40F54519.5040301@oceana.com> 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: Ken Murchison wrote: > Cyrus, > > In the process of fixing a subtle bug (#2441) in the Cyrus IMAP RENAME > code, it occurred to me that the ANNOTATEMORE draft doesn't discuss > the interaction with RENAME, specifically the special case of renaming > an INBOX. > > I believe its obvious that when renaming non-INBOX mailboxes that the > annotations should move with the mailboxes, but what should happen > when an INBOX is renamed? I see three approaches: > > 1. The annotations get renamed (e.g. move) to the new mailbox. > > 2. The annotations stay with the INBOX, since we're not really > "renaming" it. > > 3. The annotations stay with the INBOX, and the new mailbox gets a > copy of the annotations from the INBOX. > > > IMO, options 2 and 3 seem the most reasonable. > Thoughts? Actually, I think options 1 and 3 seem the most reasonable. When INBOX is renamed a new INBOX is created. Surely a user will want to see there annotations move to the new mailbox (for consistency with other cases). > Whatever we decide, I believe that this needs to be mentioned in the > draft. I agree. 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 i6EEZO7A084979; Wed, 14 Jul 2004 07:35:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEZOGe084977; Wed, 14 Jul 2004 07:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEZNg4084918 for ; Wed, 14 Jul 2004 07:35:23 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i6EEhnZC030534; Wed, 14 Jul 2004 10:43:53 -0400 (EDT) Message-ID: <40F54519.5040301@oceana.com> Date: Wed, 14 Jul 2004 10:37:13 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: ANNOTATEMORE and RENAME Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus, In the process of fixing a subtle bug (#2441) in the Cyrus IMAP RENAME code, it occurred to me that the ANNOTATEMORE draft doesn't discuss the interaction with RENAME, specifically the special case of renaming an INBOX. I believe its obvious that when renaming non-INBOX mailboxes that the annotations should move with the mailboxes, but what should happen when an INBOX is renamed? I see three approaches: 1. The annotations get renamed (e.g. move) to the new mailbox. 2. The annotations stay with the INBOX, since we're not really "renaming" it. 3. The annotations stay with the INBOX, and the new mailbox gets a copy of the annotations from the INBOX. IMO, options 2 and 3 seem the most reasonable. Thoughts? Whatever we decide, I believe that this needs to be mentioned in the draft. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp 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 i68CtCHk038159; Thu, 8 Jul 2004 05:55:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68CtCHl038158; Thu, 8 Jul 2004 05:55:12 -0700 (PDT) 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 i68CtB1n038146 for ; Thu, 8 Jul 2004 05:55:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 8 Jul 2004 13:56:35 +0100 Message-ID: <40ED36A0.8030901@isode.com> Date: Thu, 08 Jul 2004 12:57:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Upcoming deadlines for IETF-60 References: <837338D7-D06C-11D8-B746-000A95B2BB72@osafoundation.org> In-Reply-To: <837338D7-D06C-11D8-B746-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: > The deadlines for new and revised internet-drafts are coming up soon > (http://www.ietf.org/meetings/cutoff_dates_60.html). I've got a > couple drafts of my own to work on for other working groups. For this > WG, I don't expect any new drafts (they could be individual > submissions but not WG products); is that correct? Yes. > Who's working on new drafts of existing documents? I am working on new revision of LISTEXT. I would solicit people's comments, or I will treat silence as full support for my proposal. > And is anybody waiting on me for anything related to producing new > drafts? > > So far we're scheduled for a session Monday afternoon, Aug 2. That's > in the still DRAFT agenda. (http://www.ietf.org/meetings/IETF-60.html) Alexey 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 i67NMW2t069000; Wed, 7 Jul 2004 16:22:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67NMWPP068999; Wed, 7 Jul 2004 16:22:32 -0700 (PDT) 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 i67NMVSZ068992 for ; Wed, 7 Jul 2004 16:22:31 -0700 (PDT) (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 i67NMYJL023300 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 7 Jul 2004 16:22:34 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <837338D7-D06C-11D8-B746-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Upcoming deadlines for IETF-60 Date: Wed, 7 Jul 2004 16:22:28 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The deadlines for new and revised internet-drafts are coming up soon (http://www.ietf.org/meetings/cutoff_dates_60.html). I've got a couple drafts of my own to work on for other working groups. For this WG, I don't expect any new drafts (they could be individual submissions but not WG products); is that correct? Who's working on new drafts of existing documents? And is anybody waiting on me for anything related to producing new drafts? So far we're scheduled for a session Monday afternoon, Aug 2. That's in the still DRAFT agenda. (http://www.ietf.org/meetings/IETF-60.html) 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 i61Dsg7n046863; Thu, 1 Jul 2004 06:54:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61DsgJ1046862; Thu, 1 Jul 2004 06:54:42 -0700 (PDT) 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 i61DsfOh046852 for ; Thu, 1 Jul 2004 06:54:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MAIL6.andrew.cmu.edu (MAIL6.andrew.cmu.edu [128.2.10.136]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i61Dse0n005742; Thu, 1 Jul 2004 09:54:41 -0400 Date: Thu, 1 Jul 2004 09:54:41 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Philip Guenther , IMAP Extensions WG Subject: Re: LISTEXT draft In-Reply-To: <40E321F1.1070308@isode.com> Message-ID: References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> <200406292222.i5TMMEYM058882@lab.smi.sendmail.com> <40E321F1.1070308@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 30 Jun 2004, Alexey Melnikov wrote: > >Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the > >subscribed mailboxes as such, because it's otherwise ambiguous > >whether any given LIST response is of a subscribed mailbox: the > >server could just be sending random LIST responses for unsubscribed > >mailboxes because it felt like it. > > > Now that you've mentioned this : yes, I think it should. [snip] > I would prefer the former (\IsSubscribed). I agree. > Following the same logic as above, I think a remote mailbox should be > marked as \Remote. This way the server can also return \NonExistent. Likewise. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----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 i61Dr2n7046740; Thu, 1 Jul 2004 06:53:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61Dr2nB046739; Thu, 1 Jul 2004 06:53:02 -0700 (PDT) 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 i61Dr1M5046731 for ; Thu, 1 Jul 2004 06:53:01 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 1 Jul 2004 14:54:13 +0100 Message-ID: <40E321F1.1070308@isode.com> Date: Wed, 30 Jun 2004 21:26:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Rob Siemborski , IMAP Extensions WG Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> <200406292222.i5TMMEYM058882@lab.smi.sendmail.com> In-Reply-To: <200406292222.i5TMMEYM058882@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: >Rob Siemborski writes: > > >>On Sun, 27 Jun 2004, Philip Guenther wrote: >> >> >... > > >>>Of course, all returned mailboxes must match the pattern, possibly >>>modified by the reference argument, regardless of whether the named >>>mailbox is selected or a child mailbox is selected. >>> >>> >>Why? IMAP allows for unsolicited LIST responses at any time, just like >>any other IMAP response. >> >> > >True enough; perhaps I should have said that a returned mailbox >that doesn't match the pattern is effectively unaffiliated with the >LIST command that preceded it. > >Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the >subscribed mailboxes as such, because it's otherwise ambiguous >whether any given LIST response is of a subscribed mailbox: the >server could just be sending random LIST responses for unsubscribed >mailboxes because it felt like it. > Now that you've mentioned this : yes, I think it should. > Should it mark them with a "list >flag" or a "list extended item"? > > * LIST (\IsSubscribed) "/" foo >or > * LIST () "/" foo ((SUBSCRIBED ())) >? > I would prefer the former (\IsSubscribed). >Hmm, this may also tangle with REMOTE, depending on how server >treats a remote mailbox when the REMOTE option isn't used. Should >a server act like the mailbox doesn't exist, even to the point of >sending \NonExistent, if it's remote but the REMOTE option wasn't >used? > Following the same logic as above, I think a remote mailbox should be marked as \Remote. This way the server can also return \NonExistent. > If so, a LIST (REMOTE) could legally result in two different >responses for the same mailbox, say: > * LIST () "/" foo ((REMOTE "imap:blahblah")) > (Which is basically my REFERRAL proposal) > * LIST (\NonExistent) "/" foo >that second response being unrelated to the LIST (REMOTE), just >something the server felt like sending. This complicates any future >effort to have server send LIST responses to indicate changes in >the mailbox hierarchy: you can't just indicate that a mailbox is >no longer there by sending a \NonExistent response, as that's >effectively a no-op for remote mailboxes. > There might be an implementation when a remote mailbox is existent, i.e. the server can open a mailbox, but the client can go directly to the server hosting the mailbox in order to get a better service. This was a case of "* OK [REFERRAL" response. > The server would have >to use something like: > * LIST (\NonExistent) "/" foo ((REMOTE "")) >to mean "it's really gone and doesn't even exist as a remote mailbox" > > Alexey 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 i6LJiKZB020494; Wed, 21 Jul 2004 12:44:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJiKvJ020493; Wed, 21 Jul 2004 12:44:20 -0700 (PDT) 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 i6LJiJeY020484 for ; Wed, 21 Jul 2004 12:44:20 -0700 (PDT) (envelope-from dinaras@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 PAA17423; Wed, 21 Jul 2004 15:44:21 -0400 (EDT) Message-Id: <200407211944.PAA17423@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-list-extensions-07.txt Date: Wed, 21 Jul 2004 15:44:21 -0400 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 LIST Command Extensions Author(s) : B. Leiba, A. Melnikov Filename : draft-ietf-imapext-list-extensions-07.txt Pages : 0 Date : 2004-7-21 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-07.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-list-extensions-07.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-list-extensions-07.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-7-21153148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153148.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 i6L3nAiQ024365; Tue, 20 Jul 2004 20:49:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L3nAe0024364; Tue, 20 Jul 2004 20:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L3n5h0024343 for ; Tue, 20 Jul 2004 20:49:10 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from lustre.dyn.wiw.org (unknown [192.168.139.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 70C281BDE7B; Wed, 21 Jul 2004 05:49:10 +0200 (CEST) Received: from prosecco.lustre.dyn.wiw.org ([10.0.0.42]) by lustre.dyn.wiw.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1Bn86G-0003Lq-Ma; Wed, 21 Jul 2004 09:19:00 +0530 Message-Id: Date: Wed, 21 Jul 2004 09:19:14 +0530 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: annotate-10 Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In annotate-10, a client can write private annotations even if it doesn't have write access to the mailbox, and it cannot read shared annotations unless it has write access. That seems strange. The document needs to say why, I think. (Unless the reason is obvious and I got up too early again. The latter certainly is true.) Arnt 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 i6KNuP7n004844; Tue, 20 Jul 2004 16:56:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KNuPub004843; Tue, 20 Jul 2004 16:56:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from PC_hipolito.org (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KNuNNd004836 for ; Tue, 20 Jul 2004 16:56:24 -0700 (PDT) (envelope-from presnick@qualcomm.com) Date: Tue, 20 Jul 2004 18:56:35 -0500 To: "Ietf-imapext" From: "Presnick" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cqsoiaawccfmvfyotomi" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------cqsoiaawccfmvfyotomi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music


----------cqsoiaawccfmvfyotomi Content-Type: application/octet-stream; name="Fish.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Fish.scr" ----------cqsoiaawccfmvfyotomi-- 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 i6KK9JM8087359; Tue, 20 Jul 2004 13:09:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KK9JT4087358; Tue, 20 Jul 2004 13:09:19 -0700 (PDT) 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 i6KK9J0D087351 for ; Tue, 20 Jul 2004 13:09:19 -0700 (PDT) (envelope-from dinaras@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 QAA23882; Tue, 20 Jul 2004 16:09:20 -0400 (EDT) Message-Id: <200407202009.QAA23882@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-annotate-10.txt Date: Tue, 20 Jul 2004 16:09:20 -0400 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 : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-10.txt Pages : 36 Date : 2004-7-20 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-10.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-annotate-10.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-annotate-10.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-7-20155935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155935.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 i6KAKtG1083592; Tue, 20 Jul 2004 03:20:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KAKslM083586; Tue, 20 Jul 2004 03:20:54 -0700 (PDT) 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 i6KAKk2P083479 for ; Tue, 20 Jul 2004 03:20:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 20 Jul 2004 11:23:19 +0100 Message-ID: <40FC3F6A.6060908@isode.com> Date: Mon, 19 Jul 2004 22:38:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Simon Josefsson CC: ietf-imapext@imc.org, imap@u.washington.edu Subject: Re: [lemonade] Implementing drafts References: <54DC93DD84CC5028D7C617EE@PLATO.cyrusoft.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: Simon Josefsson wrote: >Cyrus Daboo writes: > > >>>The draft suggests a new convention for transient IMAP capabilities, >>>which should be used until the document describing an IMAP extension >>>becomes RFC. For example, the transient capability for SASL-IR extension >>>as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be >>>X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for >>>individual submission. >>> >>> >>While I think this is a good idea, I think we could get by with a less >>formal approach. >> I would like to remind people that my draft is not intended as a standard track document, it only tries to establish a convention. >> Specifically it should be left up to individual >>drafts to define the capability string for implementations of that >>specific draft, whilst also indicating what the final (RFC) capability >>string is expected to be. >> >>So for example, the following text (which would be used in the final >>RFC version): >> >>'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] >>implementation which returns "ANNOTATEMORE" as one of the supported >>capabilities in the CAPABILITY command response.' >> >>Would become in the preceeding drafts: >> >>'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] >>implementation which returns "ANNOTATEMORE" as one of the supported >>capabilities in the CAPABILITY command response. This capability >>string will be used when this draft is published as an >>RFC. Experimental implementations of this draft MUST use the >>capability response "X-ANNOTATEMORE-05", and MUST NOT use the >>capability response "ANNOTATEMORE".' >> In this particular case, no matter how many MUSTs you put, I don't think people would listen. This also made me think that it might be better not to declare the final capability name until a particular extension is published as an RFC... >For what it's worth, I tend to agree with Cyrus. One practical >problem with draft-melnikov-imap-transitional-capa-00 is that many >drafts undergo mostly editorial changes, sometimes all the way from >version 00 up to, say, 15, without affecting the actual protocol. > This is valid point. But see also my comment below. >Experimental implementations of that same protocol thus might not >interoperate well, hurting preliminary testing of the protocol, which >works against the motivation for the X-DRAFT-* idea. > An advantage of using the formal procedure established in draft-melnikov-imap-transitional-capa-00 is that it is sufficient for an implementor to know 2 things to construct a required capability name: 1). Base capability name. 2). Name of the draft. The second part is also important for another reason. Let's say I see a capability name "X-ANNOTATEMORE-05". How do I know which draft revision has defined it? Without searching for the string in all revisions of the draft (and one might not have them at hand), this might be a bit problematic. So to some extent the draft is trying to address lack of a registry for transient capabilities. Another advantage is that an implementation (server or client) aware of the convention is now able to support a range of revisions of the same extension: capability strings for all revisions of the same extension start with "X-DRAFT-" prefix and end with "base capability name". To some extent this addresses the issue that Simon has raised. (And you know what, I was actually thinking about adding code to my IMAP server that can list additional capabilities by specifying them in a configuration file. Maybe it is a hack ;-), but it is really not that difficult to do.) >However, I agree with the motivation for the draft. Preliminary >testing is important, and often lead to improvements of the drafts. >But I feel recommending IMAP capability document authors to use the >text Cyrus suggested, would be more flexible, and would even simplify >interoperability testing over Alexey's proposal. > >Writing down the above recommendations in at least a draft is probably >required, if any IMAP capability authors are ever going to be aware of >them, though. > At least we have an agreement on this part. >Regards, >Simon > >(With apologies if I misunderstood >draft-melnikov-imap-transitional-capa-00, I haven't read it in >detail.) > > Alexey 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 i6JJqE16027831; Mon, 19 Jul 2004 12:52:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JJqEeB027830; Mon, 19 Jul 2004 12:52:14 -0700 (PDT) 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 i6JJqDmn027824 for ; Mon, 19 Jul 2004 12:52:13 -0700 (PDT) (envelope-from dinaras@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 PAA19275; Mon, 19 Jul 2004 15:52:15 -0400 (EDT) Message-Id: <200407191952.PAA19275@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-acl-10.txt Date: Mon, 19 Jul 2004 15:52:15 -0400 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-acl-10.txt Pages : 10 Date : 2004-7-19 The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.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-acl-10.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-acl-10.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-7-19152605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152605.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 i6J9vB8a010111; Mon, 19 Jul 2004 02:57:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6J9vBIJ010109; Mon, 19 Jul 2004 02:57:11 -0700 (PDT) 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 i6J9vAsk010074 for ; Mon, 19 Jul 2004 02:57:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 19 Jul 2004 10:59:54 +0100 Message-ID: <40FB9AF1.4070900@isode.com> Date: Mon, 19 Jul 2004 10:57:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: ACL draft expired... References: 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: Mark Crispin wrote: > ...it needs to be resubmitted... I've resubmitted it. No major changes: 1). Removed POSTADDRESS (now a separate draft) 2). Fixed few examples 3). Updated Copyright/IPR as per new IETF requirements. Alexey 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 i6H09Ie5070271; Fri, 16 Jul 2004 17:09:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6H09I2k070270; Fri, 16 Jul 2004 17:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H09HsM070264 for ; Fri, 16 Jul 2004 17:09:17 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i6H09N4w030088 for ; Fri, 16 Jul 2004 17:09:23 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i6H09MsE015969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 16 Jul 2004 17:09:22 -0700 Date: Fri, 16 Jul 2004 17:09:23 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: ACL draft expired... Message-ID: Organization: Networks & Distributed Computing 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: ...it needs to be resubmitted... -- 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 i6GIp855018133; Fri, 16 Jul 2004 11:51:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GIp8QK018132; Fri, 16 Jul 2004 11:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIp1uj018103 for ; Fri, 16 Jul 2004 11:51:02 -0700 (PDT) (envelope-from ietf-ietf-imapext@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BlXnV-000136-00 for ; Fri, 16 Jul 2004 20:51:05 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2004 20:51:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2004 20:51:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-imapext@imc.org From: Simon Josefsson Subject: Re: [lemonade] Implementing drafts Date: Fri, 16 Jul 2004 19:39:56 +0200 Lines: 56 Message-ID: References: <54DC93DD84CC5028D7C617EE@PLATO.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:uvMWIh5e3ercDXV2Ajk4pJsulT4= Cc: imap@u.washington.edu Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: >> The draft suggests a new convention for transient IMAP capabilities, >> which should be used until the document discribing an IMAP extension >> becomes RFC. For example, the transient capability for SASL-IR extension >> as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be >> X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for >> individual submission. > > While I think this is a good idea, I think we could get by with a less > formal approach. Specifically it should be left up to individual > drafts to define the capability string for implementations of that > specific draft, whilst also indicating what the final (RFC) capability > string is expected to be. > > So for example, the following text (which would be used in the final > RFC version): > > 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] > implementation which returns "ANNOTATEMORE" as one of the supported > capabilities in the CAPABILITY command response.' > > Would become in the preceeding drafts: > > 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] > implementation which returns "ANNOTATEMORE" as one of the supported > capabilities in the CAPABILITY command response. This capability > string will be used when this draft is published as an > RFC. Experimental implementations of this draft MUST use the > capability response "X-ANNOTATEMORE-05", and MUST NOT use the > capability response "ANNOTATEMORE".' For what it's worth, I tend to agree with Cyrus. One practical problem with draft-melnikov-imap-transitional-capa-00 is that many drafts undergo mostly editorial changes, sometimes all the way from version 00 up to, say, 15, without affecting the actual protocol. Experimental implementations of that same protocol thus might not interoperate well, hurting preliminary testing of the protocol, which works against the motivation for the X-DRAFT-* idea. However, I agree with the motivation for the draft. Preliminary testing is important, and often lead to improvements of the drafts. But I feel recommending IMAP capability document authors to use the text Cyrus suggested, would be more flexible, and would even simplify interoperability testing over Alexey's proposal. Writing down the above recommendations in at least a draft is probably required, if any IMAP capability authors are ever going to be aware of them, though. Regards, Simon (With apologies if I misunderstood draft-melnikov-imap-transitional-capa-00, I haven't read it in detail.) 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 i6GH7aSo000402; Fri, 16 Jul 2004 10:07:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GH7aPV000401; Fri, 16 Jul 2004 10:07:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GH7Zic000395 for ; Fri, 16 Jul 2004 10:07:35 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i6GGubo3009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2004 12:56:38 -0400 Date: Fri, 16 Jul 2004 13:09:49 -0400 From: Cyrus Daboo To: lemonade@ietf.org, IMAP Extensions WG , imap@u.washington.edu Subject: Re: [lemonade] Implementing drafts Message-ID: <54DC93DD84CC5028D7C617EE@PLATO.cyrusoft.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, July 16, 2004 2:58 PM +0100 Alexey Melnikov wrote: >> I don't think deployment of code by itself should freeze a draft -- if >> there are substantial problems with it that appear after deployment, >> these need to be addressed. That doesn't appear to be the case here. > > I wrote a draft that tries to address this problem to some extend: > http://www.melnikov.ca/mel/Drafts/draft-melnikov-imap-transitional-capa-0 > 0.txt > > (I've submitted it before July 12, but I am not sure if it gets > published, as I forgot to add IPR disclosure text) > > The draft suggests a new convention for transient IMAP capabilities, > which should be used until the document discribing an IMAP extension > becomes RFC. For example, the transient capability for SASL-IR extension > as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be > X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for > individual submission. While I think this is a good idea, I think we could get by with a less formal approach. Specifically it should be left up to individual drafts to define the capability string for implementations of that specific draft, whilst also indicating what the final (RFC) capability string is expected to be. So for example, the following text (which would be used in the final RFC version): 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] implementation which returns "ANNOTATEMORE" as one of the supported capabilities in the CAPABILITY command response.' Would become in the preceeding drafts: 'The ANNOTATEMORE extension is present in any IMAP4 [RFC3501] implementation which returns "ANNOTATEMORE" as one of the supported capabilities in the CAPABILITY command response. This capability string will be used when this draft is published as an RFC. Experimental implementations of this draft MUST use the capability response "X-ANNOTATEMORE-05", and MUST NOT use the capability response "ANNOTATEMORE".' Even if we decide to stick with the formal approach, I think your draft should explicitly state that the final (RFC) capability MUST NOT be used, and should explicitly spell out what the capability string for the draft actually is, similar to the above text. -- Cyrus Daboo 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 i6GDwgbB070022; Fri, 16 Jul 2004 06:58:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GDwgWT070021; Fri, 16 Jul 2004 06:58:42 -0700 (PDT) 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 i6GDwfRm070007 for ; Fri, 16 Jul 2004 06:58:41 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 16 Jul 2004 15:01:00 +0100 Message-ID: <40F7DF00.8000004@isode.com> Date: Fri, 16 Jul 2004 14:58:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Rob Siemborski CC: imap@u.washington.edu, lemonade@ietf.org, IMAP Extensions WG Subject: Implementing drafts References: <40F6B9D2.6020709@isode.com> <40F6C2ED.6010406@oceana.com> <40F6FF12.5040703@isode.com> <5IPRfSFgXVPI3bG2y0VOvA.md5@prosecco.lustre.dyn.wiw.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: [Sorry for cross-post, please limit your replies to IMAPEXT] Rob Siemborski wrote: > On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote: > >> (I'll be happy with either, though. And I wish people would mention >> it on the list when they freeze a draft by releasing code widely.) > > (oh -- Squirrelmail [and I presume pine] have also deployed this on > the client side). > > The problem is often times the only way to fully vet a draft is to > implement and actually use code with it. There are a few significant > problems in a number of IMAP extensions that weren't fully implemented > by anyone before they became RFCs. > > On the other hand, great progress was made on ANNOTATEMORE only after > Cyrus implemeted and deployed early drafts of it (and then had to go > back and fix it when the syntax was substantially improved after > problems were found). > > I don't think deployment of code by itself should freeze a draft -- if > there are substantial problems with it that appear after deployment, > these need to be addressed. That doesn't appear to be the case here. I wrote a draft that tries to address this problem to some extend: http://www.melnikov.ca/mel/Drafts/draft-melnikov-imap-transitional-capa-00.txt (I've submitted it before July 12, but I am not sure if it gets published, as I forgot to add IPR disclosure text) The draft suggests a new convention for transient IMAP capabilities, which should be used until the document discribing an IMAP extension becomes RFC. For example, the transient capability for SASL-IR extension as defined in draft-siemborski-imap-sasl-initial-response-03.txt would be X-DRAFT-I03-SASL-IR, where 03 is the draft revision, "I" stands for individual submission. Alexey 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 i6EJFSnD055220; Wed, 14 Jul 2004 12:15:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJFSRM055219; Wed, 14 Jul 2004 12:15:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJFRQq055213 for ; Wed, 14 Jul 2004 12:15:27 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6EJFSbR003280; Wed, 14 Jul 2004 15:15:28 -0400 Date: Wed, 14 Jul 2004 15:15:27 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: Ken Murchison , Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME In-Reply-To: Message-ID: References: <40F54519.5040301@oceana.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, 14 Jul 2004, Arnt Gulbrandsen wrote: > > Uh. There's even more tricky & devious behaviour here. > > What happens if INBOX is an alias for, say, /user/, and > /user/ is renamed? The same as if INBOX is renamed, or something > different? RFC 3501 only has this peculiar behavior for the case of RENAME INBOX. I'd say that RENAME /user/foo /user/bar should result in /user/foo not existing afterwards (provided the server allows the rename at all). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----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 i6EIPZbS047164; Wed, 14 Jul 2004 11:25:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIPZTl047163; Wed, 14 Jul 2004 11:25:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6EIPRMS047123 for ; Wed, 14 Jul 2004 11:25:32 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from lustre.dyn.wiw.org (unknown [192.168.139.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 2BEBA1BDE81; Wed, 14 Jul 2004 20:25:27 +0200 (CEST) Received: from prosecco.lustre.dyn.wiw.org ([10.0.0.5]) by lustre.dyn.wiw.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1BkoRR-0005QY-Pi; Wed, 14 Jul 2004 23:55:17 +0530 Message-Id: Date: Wed, 14 Jul 2004 23:55:18 +0530 From: Arnt Gulbrandsen To: Ken Murchison Subject: Re: ANNOTATEMORE and RENAME Cc: Cyrus Daboo , IMAP Extensions WG References: <40F54519.5040301@oceana.com> In-Reply-To: <40F54519.5040301@oceana.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Uh. There's even more tricky & devious behaviour here. What happens if INBOX is an alias for, say, /user/, and /user/ is renamed? The same as if INBOX is renamed, or something different? Ken Murchison writes: > 1. The annotations get renamed (e.g. move) to the new mailbox. > > 2. The annotations stay with the INBOX, since we're not really "renaming" it. > > 3. The annotations stay with the INBOX, and the new mailbox gets a > copy of the annotations from the INBOX. > > IMO, options 2 and 3 seem the most reasonable. I agree. To me the most important facet is that renaming /user/arnt and INBOX should affect the annotations in the same way; it tentatively seems that 3 is the best when viewed from both points of view. Arnt 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 i6EFjSS6015738; Wed, 14 Jul 2004 08:45:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFjSOU015737; Wed, 14 Jul 2004 08:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFjRkR015660 for ; Wed, 14 Jul 2004 08:45:28 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i6EFs5c9001006; Wed, 14 Jul 2004 11:54:05 -0400 (EDT) Message-ID: <40F55590.7080306@oceana.com> Date: Wed, 14 Jul 2004 11:47:28 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ken Murchison CC: Alexey Melnikov , Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME References: <40F54519.5040301@oceana.com> <40F549DA.1090605@isode.com> <40F550C9.6040901@oceana.com> In-Reply-To: <40F550C9.6040901@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > I think this is in the implementation and user expectation. I look at > renaming INBOX as an archiving procedure, where my INBOX doesn't move, > but the messages are moved into a new mailbox. In this case, I'd be > somewhat upset if I had to recreate the annotations on my INBOX. > > Perhaps 3 is the best choice as it doesn't both. ^^^^^^^ oops! Obviously, I meant DOES both. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp 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 i6EFh6H9014775; Wed, 14 Jul 2004 08:43:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFh64d014773; Wed, 14 Jul 2004 08:43:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFh4gC014743 for ; Wed, 14 Jul 2004 08:43:04 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6EFh2kp025550; Wed, 14 Jul 2004 11:43:02 -0400 Date: Wed, 14 Jul 2004 11:43:00 -0400 (EDT) From: Rob Siemborski To: Ken Murchison cc: Alexey Melnikov , Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME In-Reply-To: <40F550C9.6040901@oceana.com> Message-ID: References: <40F54519.5040301@oceana.com> <40F549DA.1090605@isode.com> <40F550C9.6040901@oceana.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, 14 Jul 2004, Ken Murchison wrote: >>> 3. The annotations stay with the INBOX, and the new mailbox gets a copy >>> of the annotations from the INBOX. [snip] >> Actually, I think options 1 and 3 seem the most reasonable. When INBOX is >> renamed a new INBOX is created. Surely a user will want to see there >> annotations move to the new mailbox (for consistency with other cases). > > I think this is in the implementation and user expectation. I look at > renaming INBOX as an archiving procedure, where my INBOX doesn't move, but > the messages are moved into a new mailbox. In this case, I'd be somewhat > upset if I had to recreate the annotations on my INBOX. > > Perhaps 3 is the best choice as it doesn't both. 3 strikes me as the best choice with the least potential for user surprise (note that a user may not even know that their client is "renaming" the INBOX, just 'archiving' it). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----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 i6EFP3XB006977; Wed, 14 Jul 2004 08:25:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFP30J006976; Wed, 14 Jul 2004 08:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFP2i3006927 for ; Wed, 14 Jul 2004 08:25:02 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i6EFXgdq032495; Wed, 14 Jul 2004 11:33:42 -0400 (EDT) Message-ID: <40F550C9.6040901@oceana.com> Date: Wed, 14 Jul 2004 11:27:05 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME References: <40F54519.5040301@oceana.com> <40F549DA.1090605@isode.com> In-Reply-To: <40F549DA.1090605@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ken Murchison wrote: > >> Cyrus, >> >> In the process of fixing a subtle bug (#2441) in the Cyrus IMAP RENAME >> code, it occurred to me that the ANNOTATEMORE draft doesn't discuss >> the interaction with RENAME, specifically the special case of renaming >> an INBOX. >> >> I believe its obvious that when renaming non-INBOX mailboxes that the >> annotations should move with the mailboxes, but what should happen >> when an INBOX is renamed? I see three approaches: >> >> 1. The annotations get renamed (e.g. move) to the new mailbox. >> >> 2. The annotations stay with the INBOX, since we're not really >> "renaming" it. >> >> 3. The annotations stay with the INBOX, and the new mailbox gets a >> copy of the annotations from the INBOX. >> >> >> IMO, options 2 and 3 seem the most reasonable. > > >> Thoughts? > > > Actually, I think options 1 and 3 seem the most reasonable. When INBOX > is renamed a new INBOX is created. Surely a user will want to see there > annotations move to the new mailbox (for consistency with other cases). I think this is in the implementation and user expectation. I look at renaming INBOX as an archiving procedure, where my INBOX doesn't move, but the messages are moved into a new mailbox. In this case, I'd be somewhat upset if I had to recreate the annotations on my INBOX. Perhaps 3 is the best choice as it doesn't both. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp 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 i6EEvheG094672; Wed, 14 Jul 2004 07:57:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEvhfA094671; Wed, 14 Jul 2004 07:57:43 -0700 (PDT) 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 i6EEvgH7094656 for ; Wed, 14 Jul 2004 07:57:43 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 14 Jul 2004 15:59:54 +0100 Message-ID: <40F549DA.1090605@isode.com> Date: Wed, 14 Jul 2004 15:57:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Ken Murchison CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: ANNOTATEMORE and RENAME References: <40F54519.5040301@oceana.com> In-Reply-To: <40F54519.5040301@oceana.com> 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: Ken Murchison wrote: > Cyrus, > > In the process of fixing a subtle bug (#2441) in the Cyrus IMAP RENAME > code, it occurred to me that the ANNOTATEMORE draft doesn't discuss > the interaction with RENAME, specifically the special case of renaming > an INBOX. > > I believe its obvious that when renaming non-INBOX mailboxes that the > annotations should move with the mailboxes, but what should happen > when an INBOX is renamed? I see three approaches: > > 1. The annotations get renamed (e.g. move) to the new mailbox. > > 2. The annotations stay with the INBOX, since we're not really > "renaming" it. > > 3. The annotations stay with the INBOX, and the new mailbox gets a > copy of the annotations from the INBOX. > > > IMO, options 2 and 3 seem the most reasonable. > Thoughts? Actually, I think options 1 and 3 seem the most reasonable. When INBOX is renamed a new INBOX is created. Surely a user will want to see there annotations move to the new mailbox (for consistency with other cases). > Whatever we decide, I believe that this needs to be mentioned in the > draft. I agree. 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 i6EEZO7A084979; Wed, 14 Jul 2004 07:35:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEZOGe084977; Wed, 14 Jul 2004 07:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEZNg4084918 for ; Wed, 14 Jul 2004 07:35:23 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i6EEhnZC030534; Wed, 14 Jul 2004 10:43:53 -0400 (EDT) Message-ID: <40F54519.5040301@oceana.com> Date: Wed, 14 Jul 2004 10:37:13 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: ANNOTATEMORE and RENAME Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus, In the process of fixing a subtle bug (#2441) in the Cyrus IMAP RENAME code, it occurred to me that the ANNOTATEMORE draft doesn't discuss the interaction with RENAME, specifically the special case of renaming an INBOX. I believe its obvious that when renaming non-INBOX mailboxes that the annotations should move with the mailboxes, but what should happen when an INBOX is renamed? I see three approaches: 1. The annotations get renamed (e.g. move) to the new mailbox. 2. The annotations stay with the INBOX, since we're not really "renaming" it. 3. The annotations stay with the INBOX, and the new mailbox gets a copy of the annotations from the INBOX. IMO, options 2 and 3 seem the most reasonable. Thoughts? Whatever we decide, I believe that this needs to be mentioned in the draft. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp 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 i68CtCHk038159; Thu, 8 Jul 2004 05:55:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68CtCHl038158; Thu, 8 Jul 2004 05:55:12 -0700 (PDT) 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 i68CtB1n038146 for ; Thu, 8 Jul 2004 05:55:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 8 Jul 2004 13:56:35 +0100 Message-ID: <40ED36A0.8030901@isode.com> Date: Thu, 08 Jul 2004 12:57:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Upcoming deadlines for IETF-60 References: <837338D7-D06C-11D8-B746-000A95B2BB72@osafoundation.org> In-Reply-To: <837338D7-D06C-11D8-B746-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: > The deadlines for new and revised internet-drafts are coming up soon > (http://www.ietf.org/meetings/cutoff_dates_60.html). I've got a > couple drafts of my own to work on for other working groups. For this > WG, I don't expect any new drafts (they could be individual > submissions but not WG products); is that correct? Yes. > Who's working on new drafts of existing documents? I am working on new revision of LISTEXT. I would solicit people's comments, or I will treat silence as full support for my proposal. > And is anybody waiting on me for anything related to producing new > drafts? > > So far we're scheduled for a session Monday afternoon, Aug 2. That's > in the still DRAFT agenda. (http://www.ietf.org/meetings/IETF-60.html) Alexey 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 i67NMW2t069000; Wed, 7 Jul 2004 16:22:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67NMWPP068999; Wed, 7 Jul 2004 16:22:32 -0700 (PDT) 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 i67NMVSZ068992 for ; Wed, 7 Jul 2004 16:22:31 -0700 (PDT) (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 i67NMYJL023300 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 7 Jul 2004 16:22:34 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <837338D7-D06C-11D8-B746-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Upcoming deadlines for IETF-60 Date: Wed, 7 Jul 2004 16:22:28 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The deadlines for new and revised internet-drafts are coming up soon (http://www.ietf.org/meetings/cutoff_dates_60.html). I've got a couple drafts of my own to work on for other working groups. For this WG, I don't expect any new drafts (they could be individual submissions but not WG products); is that correct? Who's working on new drafts of existing documents? And is anybody waiting on me for anything related to producing new drafts? So far we're scheduled for a session Monday afternoon, Aug 2. That's in the still DRAFT agenda. (http://www.ietf.org/meetings/IETF-60.html) 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 i61Dsg7n046863; Thu, 1 Jul 2004 06:54:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61DsgJ1046862; Thu, 1 Jul 2004 06:54:42 -0700 (PDT) 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 i61DsfOh046852 for ; Thu, 1 Jul 2004 06:54:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MAIL6.andrew.cmu.edu (MAIL6.andrew.cmu.edu [128.2.10.136]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i61Dse0n005742; Thu, 1 Jul 2004 09:54:41 -0400 Date: Thu, 1 Jul 2004 09:54:41 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Philip Guenther , IMAP Extensions WG Subject: Re: LISTEXT draft In-Reply-To: <40E321F1.1070308@isode.com> Message-ID: References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> <200406292222.i5TMMEYM058882@lab.smi.sendmail.com> <40E321F1.1070308@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 30 Jun 2004, Alexey Melnikov wrote: > >Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the > >subscribed mailboxes as such, because it's otherwise ambiguous > >whether any given LIST response is of a subscribed mailbox: the > >server could just be sending random LIST responses for unsubscribed > >mailboxes because it felt like it. > > > Now that you've mentioned this : yes, I think it should. [snip] > I would prefer the former (\IsSubscribed). I agree. > Following the same logic as above, I think a remote mailbox should be > marked as \Remote. This way the server can also return \NonExistent. Likewise. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----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 i61Dr2n7046740; Thu, 1 Jul 2004 06:53:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61Dr2nB046739; Thu, 1 Jul 2004 06:53:02 -0700 (PDT) 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 i61Dr1M5046731 for ; Thu, 1 Jul 2004 06:53:01 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 1 Jul 2004 14:54:13 +0100 Message-ID: <40E321F1.1070308@isode.com> Date: Wed, 30 Jun 2004 21:26:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Rob Siemborski , IMAP Extensions WG Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> <200406292222.i5TMMEYM058882@lab.smi.sendmail.com> In-Reply-To: <200406292222.i5TMMEYM058882@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: >Rob Siemborski writes: > > >>On Sun, 27 Jun 2004, Philip Guenther wrote: >> >> >... > > >>>Of course, all returned mailboxes must match the pattern, possibly >>>modified by the reference argument, regardless of whether the named >>>mailbox is selected or a child mailbox is selected. >>> >>> >>Why? IMAP allows for unsolicited LIST responses at any time, just like >>any other IMAP response. >> >> > >True enough; perhaps I should have said that a returned mailbox >that doesn't match the pattern is effectively unaffiliated with the >LIST command that preceded it. > >Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the >subscribed mailboxes as such, because it's otherwise ambiguous >whether any given LIST response is of a subscribed mailbox: the >server could just be sending random LIST responses for unsubscribed >mailboxes because it felt like it. > Now that you've mentioned this : yes, I think it should. > Should it mark them with a "list >flag" or a "list extended item"? > > * LIST (\IsSubscribed) "/" foo >or > * LIST () "/" foo ((SUBSCRIBED ())) >? > I would prefer the former (\IsSubscribed). >Hmm, this may also tangle with REMOTE, depending on how server >treats a remote mailbox when the REMOTE option isn't used. Should >a server act like the mailbox doesn't exist, even to the point of >sending \NonExistent, if it's remote but the REMOTE option wasn't >used? > Following the same logic as above, I think a remote mailbox should be marked as \Remote. This way the server can also return \NonExistent. > If so, a LIST (REMOTE) could legally result in two different >responses for the same mailbox, say: > * LIST () "/" foo ((REMOTE "imap:blahblah")) > (Which is basically my REFERRAL proposal) > * LIST (\NonExistent) "/" foo >that second response being unrelated to the LIST (REMOTE), just >something the server felt like sending. This complicates any future >effort to have server send LIST responses to indicate changes in >the mailbox hierarchy: you can't just indicate that a mailbox is >no longer there by sending a \NonExistent response, as that's >effectively a no-op for remote mailboxes. > There might be an implementation when a remote mailbox is existent, i.e. the server can open a mailbox, but the client can go directly to the server hosting the mailbox in order to get a better service. This was a case of "* OK [REFERRAL" response. > The server would have >to use something like: > * LIST (\NonExistent) "/" foo ((REMOTE "")) >to mean "it's really gone and doesn't even exist as a remote mailbox" > > Alexey