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 i7VMCHKk000274; Tue, 31 Aug 2004 15:12:17 -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 i7VMCH1b000273; Tue, 31 Aug 2004 15:12:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMCGSw000264 for ; Tue, 31 Aug 2004 15:12:16 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id EAD12154009; Tue, 31 Aug 2004 22:12:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: Subject: Annotate questions. Message-ID: <20040831221121.22471.33383.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 23:11:21 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus, I'm probably being particularly stupid here, but I'm not quite clear from reading the draft of a couple of points concerning shared/private flags. The thread I inadvertantly spawned on the nature of shared vs private flags nagged me into thinking about manipulating flags via annotations, and wondering which of .priv or .shared to use. As far as I can tell, given a message 1234: a1 FETCH 1234 (FLAGS) * 1234 FETCH (FLAGS ()) a1 OK Message has no flags. a2 FETCH 1234 (ANNOTATION ("/flags/\\deleted" ("value"))) * 1234 FETCH (ANNOTATION ("/flags/\\deleted" ("value.priv" NIL) ("value.shared" NIL)) a2 OK No clues given here. The only way I could tell which I'm meant to be using would be to STORE FLAGS, then look at the annotations. Then at least I'd presumably know if the flag was shared or not. This further suggests that ANNOTATE isn't completely replacing STORE/FETCH FLAGS, but is supplementing them - but I can only tell whether a flag is shared or private by first storing it. Can I set a shared and private \Deleted flag independently with ANNOTATE? Which one is counted when I do an EXPUNGE? Similar confusion applies to any flag, of course. Incidentally, I'd greatly appreciate anyone who could give me a test account on a server supporting ANNOTATE - I'd like to experiment a little with it in implementation. Aside from this one bewilderness, it all looks good to me. Dave. 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 i7VKpI3R083403; Tue, 31 Aug 2004 13:51: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 i7VKpIdZ083402; Tue, 31 Aug 2004 13:51:18 -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 i7VKpHxq083393 for ; Tue, 31 Aug 2004 13:51:17 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VKXEo3014936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 16:33:15 -0400 Date: Tue, 31 Aug 2004 16:51:18 -0400 From: Cyrus Daboo To: Dave Cridland cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <7434ABF472F8E51E83CC0DBF@ninevah.cyrusoft.com> In-Reply-To: <20040831203825.22471.85302.polymer@peirce.gestalt.entity.net> References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> <20040831203825.22471.85302.polymer@peirce.gestalt.entity.net> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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.3 tests=UPPERCASE_25_50 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dave, --On Tuesday, August 31, 2004 9:38 PM +0100 Dave Cridland wrote: >> +---------------+-----------------------------------+ >> | | | >> | >> | | write private | Any mailbox that can be SELECTED >> | >> | Server | | or EXAMINED (even if [READ-ONLY]. >> | >> | without | | >> | > > But not sure about this - if the mailbox is being EXAMINed, I think > RFC3501 suggests that private annotations MUST NOT be writable [6.3.2]. > SELECT [READ-ONLY] appears to suggest that per-user annotations MAY be > writable - not that they MUST or even SHOULD be. [6.3.1] OK, I could change that to: | +---------------+-----------------------------------+ | | | | | Server | write private | Any SELECTED [READ-WRITE] mailbox.| | without | | SELECTED [READ-ONLY] mailboxes MAY| | ACL Extension | | also permit writes. | | | | | | +---------------+-----------------------------------+ -- 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 i7VKdM9l080957; Tue, 31 Aug 2004 13:39:22 -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 i7VKdMFX080956; Tue, 31 Aug 2004 13:39:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VKdLw1080948 for ; Tue, 31 Aug 2004 13:39:21 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 25683154009; Tue, 31 Aug 2004 20:39:25 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> In-Reply-To: <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> Message-ID: <20040831203825.22471.85302.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 21:38:25 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Aug 31 20:31:43 2004, Cyrus Daboo wrote: > Below is a table I propose putting into the ANNOTATE draft to > clarify access control issues. Note that I have used the 'm' and > 'n' rights for ANNOTATE. > > +---------------+---------------+-----------------------------------+ > | Server Type | Action on | Type of mailbox > | > | | annotation | > | > +===============+===============+===================================+ > | | | > | > | | read private | Any mailbox that can be SELECTED > | > | | | or EXAMINED. > | > | | | > | I agree with this, as long as the inference is SHOULD, not MUST. (To put it another way, clients can issue a FETCH on private annotations with a reasonable expectation that it will succeed, but MUST be prepared for it to fail.) > | > +---------------+-----------------------------------+ > | | | > | > | | write private | Any mailbox that can be SELECTED > | > | Server | | or EXAMINED (even if [READ-ONLY]. > | > | without | | > | But not sure about this - if the mailbox is being EXAMINed, I think RFC3501 suggests that private annotations MUST NOT be writable [6.3.2]. SELECT [READ-ONLY] appears to suggest that per-user annotations MAY be writable - not that they MUST or even SHOULD be. [6.3.1] Of course, I might be misreading you here, rather than disagreeing. Aside from this, adding rights does, of course, work. It seems to me that in the absence of these extended rights, the client can assume the same semantics as above, which are - I think - calculable from the existing 2086 rights. (Not that it matters enormously.) As long as the server implementors [of which I'm not one] think it's fair to add in extra rights for this purpose, I'm perfectly happy with it as a client implementor. Dave. 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 i7VJVfQC066824; Tue, 31 Aug 2004 12:31:41 -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 i7VJVfB3066823; Tue, 31 Aug 2004 12:31:41 -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 i7VJVeXE066807 for ; Tue, 31 Aug 2004 12:31:41 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VJDeo3013251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2004 15:13:41 -0400 Date: Tue, 31 Aug 2004 15:31:43 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> In-Reply-To: <412B7F3B.60206@isode.com> References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 24, 2004 6:47 PM +0100 Alexey Melnikov wrote: >> I noticed the thread in the archives about ANNOTATE/ACL interaction, >> and Arnt Gulbrandsen's comment on it. >> >> A quick suggestion: >> >> Could we use the 's' right to indicate permission to store private >> annotations, and the 'w' write to store shared ones? >> >> This seems more logical to me, since: >> >> 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only >> per-user data I'm aware of in an IMAP4 shared mailbox. > > I don't think ACL2 says that 's' only controls private (per-user) \Seen > even though Cyrus Imap implements the \Seen flag as private. I've > implemented \Seen as a shared flag once. Having said that, I don't like > overloading the meaning of different ACL rights. > > On a second through, if existing ACL implementations are Ok with > declaring the 's' right as controlling per-user flags (except for > \Deleted of course) and annotations, that would be fine with me. At this point what I would propose is that we have two new ACL rights for writeability of shared annotations and read/write of private annotations. Reading of shared annotations will always be possible with the 'r' right. These new rights would be advertised in the new RIGHTS capability extension that Alexey is working on. I don't think its too much to ask servers that support ACL and are adding ANNOTATE to also add the new rights. Below is a table I propose putting into the ANNOTATE draft to clarify access control issues. Note that I have used the 'm' and 'n' rights for ANNOTATE. +---------------+---------------+-----------------------------------+ | Server Type | Action on | Type of mailbox | | | annotation | | +===============+===============+===================================+ | | | | | | read private | Any mailbox that can be SELECTED | | | | or EXAMINED. | | | | | | +---------------+-----------------------------------+ | | | | | | write private | Any mailbox that can be SELECTED | | Server | | or EXAMINED (even if [READ-ONLY]. | | without | | | | ACL Extension +---------------+-----------------------------------+ | | | | | | read shared | Any mailbox that can be SELECTED | | | | or EXAMINED. | | | | | | +---------------+-----------------------------------+ | | | | | | write shared | Any mailbox that can be SELECTED | | | | or EXAMINED and is [READ-WRITE]. | | | | | +---------------+---------------+-----------------------------------+ | | | | | | read private | Any mailbox with the 'm' right. | | | | | | +---------------+-----------------------------------+ | | | | | Server | write private | Any mailbox with the 'm' right. | | with | | | | ACL/RIGHTS +---------------+-----------------------------------+ | Extensions | | | | | read shared | Any mailbox with the 'r' right. | | | | | | +---------------+-----------------------------------+ | | | | | | write shared | Any mailbox with the 'n' right. | | | | | +---------------+---------------+-----------------------------------+ -- 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 i7VFt6PW029084; Tue, 31 Aug 2004 08:55: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 i7VFt6cJ029083; Tue, 31 Aug 2004 08:55:06 -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 i7VFt451029077 for ; Tue, 31 Aug 2004 08:55:05 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VFb5o3008454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 11:37:05 -0400 Date: Tue, 31 Aug 2004 11:55:06 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: LISTEXT to finish... Message-ID: <45A18C1561E515CAA6B8A59A@ninevah.cyrusoft.com> In-Reply-To: <413467DA.1090704@isode.com> References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> <413467DA.1090704@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 31, 2004 12:58 PM +0100 Alexey Melnikov wrote: > I would also like to change "match option" to "selection option", as half > of the document is still talking about "selection criteria". And I think > it would be better to keep using "match" when talking about mailbox > pattern matching. Any objections? No. > Also, if people have suggestions about better name for \HasSubmailboxes, > speak up now. How about replacing 'Submailboxes' with 'Children' since the later is terminology already well described. In which case we could have '\AlsoChildren' - with the implication that some children of the current mailbox also match the selection criteria. -- 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 i7VFZtwg025659; Tue, 31 Aug 2004 08:35: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 i7VFZslH025658; Tue, 31 Aug 2004 08:35:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFZsPH025623 for ; Tue, 31 Aug 2004 08:35:54 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 54FAE154009; Tue, 31 Aug 2004 15:35:45 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> <413467DA.1090704@isode.com> In-Reply-To: <413467DA.1090704@isode.com> Message-ID: <20040831153446.22087.17467.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 16:34:46 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Aug 31 12:58:18 2004, Alexey Melnikov wrote: > I would also like to change "match option" to "selection option", > as half of the document is still talking about "selection > criteria". And I think it would be better to keep using "match" > when talking about mailbox pattern matching. Any objections? > > This makes the sense of REMOTE, for instance, clearer. (Since it doesn't match, but extends the selection). The return option REMOTE still needs to vanish, though - it serves no purpose. > Also, if people have suggestions about better name for > \HasSubmailboxes, speak up now. > > The only possible alternative I can think of that makes any sense is \HasInferiors but I'm not all that fussed, and I'm not sure if that would raise a conceptual problem with \NoInferiors or whether it makes more sense because of it. Dave. 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 i7VBwONa069060; Tue, 31 Aug 2004 04:58: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 i7VBwOoH069059; Tue, 31 Aug 2004 04:58:24 -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 i7VBwNTZ069045 for ; Tue, 31 Aug 2004 04:58:24 -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, 31 Aug 2004 13:03:56 +0100 Message-ID: <413467DA.1090704@isode.com> Date: Tue, 31 Aug 2004 12:58:18 +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 CC: IMAP Extensions WG Subject: Re: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> In-Reply-To: <8813AB5145EF95839A9507BB@ninevah.cyrusoft.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: Cyrus Daboo wrote: >>> One option would be to change it to a match option instead of a return >>> option and rename it appropriately. e.g. add the search option >>> 'MATCHPARENT' which causes non-matching parent items to be matched and >>> implicitly results in \PlaceHolder and \HasSubmailboxes being computed >>> and returned. That would make the behaviour consistent. >> >> Hmm, this sounds sufficient. We wouldn't need another return option for >> this? > > I can't think of a case where it would need a return option as well. > Note that MATCHPARENT only makes sense when other match options are > also used, so maybe it MUST NOT occur as the only match option. Ok, I've made this change in my copy. I would also like to change "match option" to "selection option", as half of the document is still talking about "selection criteria". And I think it would be better to keep using "match" when talking about mailbox pattern matching. Any objections? Also, if people have suggestions about better name for \HasSubmailboxes, speak up now. 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 i7RGHYWF040436; Fri, 27 Aug 2004 09:17:34 -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 i7RGHY33040435; Fri, 27 Aug 2004 09:17:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from RMF.net (200-122-65-108.cab.prima.net.ar [200.122.65.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RGHW1Y040421 for ; Fri, 27 Aug 2004 09:17:34 -0700 (PDT) (envelope-from chris.newman@sun.com) Date: Fri, 27 Aug 2004 13:17:16 -0300 To: "Ietf-imapext" From: "Chris.newman" Subject: 1 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lbykhuuiitcjpcuizcbo" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------lbykhuuiitcjpcuizcbo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit


----------lbykhuuiitcjpcuizcbo Content-Type: application/octet-stream; name="2.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2.gif" NDU0NTEyMTI= ----------lbykhuuiitcjpcuizcbo-- 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 i7QLZNGg042102; Thu, 26 Aug 2004 14:35:23 -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 i7QLZNPr042101; Thu, 26 Aug 2004 14:35:23 -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 i7QLZNIR042091 for ; Thu, 26 Aug 2004 14:35:23 -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 i7QLZMpp031944 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 26 Aug 2004 14:35:23 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: New charter posted Date: Thu, 26 Aug 2004 14:35:11 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Our new charter milestones are posted at http://www.ietf.org/html.charters/imapext-charter.html. Now let's try to meet those milestones! There's very little argument so I expect we can do it -- let me know if there are any real blockers I can help with. 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 i7PJMmgW093707; Wed, 25 Aug 2004 12:22:48 -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 i7PJMmeW093706; Wed, 25 Aug 2004 12:22:48 -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 i7PJMm5Q093691 for ; Wed, 25 Aug 2004 12:22:48 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7PJMkpp017609 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 25 Aug 2004 12:22:50 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2192496C-F6CC-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: WebDAV server for WG collaboration Date: Wed, 25 Aug 2004 12:22:40 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: With the help of Jim Whitehead, Sung Kim, Marshall Rose and Xythos Software, Inc, I've set up a server for IETF usage -- particularly for working groups to collaborate on IETF-related documents. We're just getting this off the ground, so I'm starting with this WG and the WebDAV WG. If you're an author/editor of any of the IMAPEXT drafts, let me know if you can make use of this and I'll make you an account & get you started. Since the server is a WebDAV server it supports clients like Windows Network Places, Office, Adobe clients, MacOS/X WebDAV/FS, sitecopy, and many many more. There's also a Web/HTML GUI for functions unique to Xythos WebFile Server or functions not supported by your client software. 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 i7OM5JT5064795; Tue, 24 Aug 2004 15:05: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 i7OM5JKU064794; Tue, 24 Aug 2004 15:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OM5Irk064787 for ; Tue, 24 Aug 2004 15:05:18 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OM5NuP024208; Tue, 24 Aug 2004 15:05: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.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OM5M9E007512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2004 15:05:22 -0700 Date: Tue, 24 Aug 2004 15:05:22 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) In-Reply-To: <28C2B31E3CC26D671C269758@d64-180-170-72.bchsia.telus.net> Message-ID: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> <28C2B31E3CC26D671C269758@d64-180-170-72.bchsia.telus.net> 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: On Tue, 24 Aug 2004, Lyndon Nerenberg wrote: > But in an NNTP client's view, the message isn't deleted, it has been "read" > which, in my mind, maps to \Seen, not \Deleted. The delete model in NNTP is > completely different from that in IMAP. The UW/Pine/c-client world respectfully disagrees. \Deleted is the permanent flag reflecting .newsrc status, \Seen is a session flag that marks whether you have read a particular message in the session. The other useful session flag is \Answered. We have been doing it this way (and mass-distributing the software!) for 12 years. If you think about it, it makes sense; especially when you consider that it is useful for a client to maintain both "seen in this session" and ".newsrc state" as separate states. The contrary argument is based upon rn and other ancient programs calling .newsrc state as "read" state. But it really was no such thing. You could "catch-up", marking all messages in .newsrc, and you could revert messages to not have "read" state. \Deleted maps better to this than \Seen, in spite of the misleading name used by rn. > So while I'm not saying that per-user \deleted is a bad thing, I don't think > NNTP message stores are a valid argument for it. We disagree. If I can't convince you of the technical/user interface argument, please consider the long history and widespread distribution. -- 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 i7OLr693062115; Tue, 24 Aug 2004 14:53: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 i7OLr6OE062114; Tue, 24 Aug 2004 14:53:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLr5U3062104 for ; Tue, 24 Aug 2004 14:53:05 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d64-180-170-72.bchsia.telus.net (d64-180-170-72.bchsia.telus.net [64.180.170.72]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i7OLqkqx005411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 15:53:00 -0600 (MDT) Date: Tue, 24 Aug 2004 14:52:45 -0700 From: Lyndon Nerenberg To: Cyrus Daboo , Mark Crispin cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <28C2B31E3CC26D671C269758@d64-180-170-72.bchsia.telus.net> In-Reply-To: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) 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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-8-24 4:32 PM -0400 Cyrus Daboo wrote: > Whilst you can't expunge you can at least do view-filtering on the > client to hide the deleted messages, which is useful. But in an NNTP client's view, the message isn't deleted, it has been "read" which, in my mind, maps to \Seen, not \Deleted. The delete model in NNTP is completely different from that in IMAP. So while I'm not saying that per-user \deleted is a bad thing, I don't think NNTP message stores are a valid argument for it. --lyndon 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 i7OLHXnc057795; Tue, 24 Aug 2004 14:17:33 -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 i7OLHXHo057794; Tue, 24 Aug 2004 14:17:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLHWjf057788 for ; Tue, 24 Aug 2004 14:17:32 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OLHail011055; Tue, 24 Aug 2004 14:17:36 -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.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OLHaMd012949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2004 14:17:36 -0700 Date: Tue, 24 Aug 2004 14:17:36 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: Lyndon Nerenberg , ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) In-Reply-To: Message-ID: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> 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: On Tue, 24 Aug 2004, Cyrus Daboo wrote: > Whilst you can't expunge you can at least do view-filtering on the client to > hide the deleted messages, which is useful. Exactly. UW imapd has always used \Deleted to reflect .newsrc state. I didn't like the idea at first, but I came to realize that it makes a good deal of sense. -- 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 i7OKWZ08054167; Tue, 24 Aug 2004 13:32: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 i7OKWZ9o054166; Tue, 24 Aug 2004 13:32:35 -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 i7OKWY21054159 for ; Tue, 24 Aug 2004 13:32:35 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7OKFXo3023307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 16:15:33 -0400 Date: Tue, 24 Aug 2004 16:32:30 -0400 From: Cyrus Daboo To: Lyndon Nerenberg , Mark Crispin cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: In-Reply-To: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Lyndon, --On Tuesday, August 24, 2004 1:15 PM -0700 Lyndon Nerenberg wrote: >> Per-user \Deleted is useful for newsgroups... > > How so? You can't Expunge newsgroups (well, not in any IMAP server that > I've come across). News client semantics key off \Seen. > > This is one of the major reasons why I don't like expressing newsgroups > through IMAP. Whilst you can't expunge you can at least do view-filtering on the client to hide the deleted messages, which is useful. -- 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 i7OKG3PK053256; Tue, 24 Aug 2004 13:16: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 i7OKG3cZ053255; Tue, 24 Aug 2004 13:16:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKG238053241 for ; Tue, 24 Aug 2004 13:16:02 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d64-180-170-72.bchsia.telus.net (d64-180-170-72.bchsia.telus.net [64.180.170.72]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i7OKFpg8004970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 14:15:54 -0600 (MDT) Date: Tue, 24 Aug 2004 13:15:51 -0700 From: Lyndon Nerenberg To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: In-Reply-To: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) 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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-8-24 12:35 PM -0700 Mark Crispin wrote: > Per-user \Deleted is useful for newsgroups... How so? You can't Expunge newsgroups (well, not in any IMAP server that I've come across). News client semantics key off \Seen. This is one of the major reasons why I don't like expressing newsgroups through IMAP. --lyndon 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 i7OJfApt051305; Tue, 24 Aug 2004 12:41: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 i7OJfAkk051304; Tue, 24 Aug 2004 12:41:10 -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 i7OJf9GL051298 for ; Tue, 24 Aug 2004 12:41:09 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7OJODo3022341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 15:24:14 -0400 Date: Tue, 24 Aug 2004 15:41:10 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: Lisa Dusseault , IMAP Extensions WG Subject: Re: LISTEXT to finish... Message-ID: <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> In-Reply-To: <412B9840.9070601@isode.com> References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 24, 2004 8:34 PM +0100 Alexey Melnikov wrote: >> One option would be to change it to a match option instead of a return >> option and rename it appropriately. e.g. add the search option >> 'MATCHPARENT' which causes non-matching parent items to be matched and >> implicitly results in \PlaceHolder and \HasSubmailboxes being computed >> and returned. That would make the behaviour consistent. > > Hmm, this sounds sufficient. We wouldn't need another return option for > this? I can't think of a case where it would need a return option as well. Note that MATCHPARENT only makes sense when other match options are also used, so maybe it MUST NOT occur as the only match option. -- 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 i7OJZ6WN050686; Tue, 24 Aug 2004 12:35: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 i7OJZ6Ni050685; Tue, 24 Aug 2004 12:35:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJZ5t5050679 for ; Tue, 24 Aug 2004 12:35:05 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OJZ7oO025754; Tue, 24 Aug 2004 12:35:07 -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.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OJZ6fw030864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2004 12:35:06 -0700 Date: Tue, 24 Aug 2004 12:35:06 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Dave Cridland , ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) In-Reply-To: <412B95CC.5050906@isode.com> Message-ID: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> 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: On Tue, 24 Aug 2004, Alexey Melnikov wrote: >> Equally, I've not seen \Deleted implemented as anything but shared... > Chris Newman thinks otherwise, although I've been surprised by this as well. Per-user \Deleted is useful for newsgroups... -- 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 i7OJYSYe050626; Tue, 24 Aug 2004 12:34: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 i7OJYSws050625; Tue, 24 Aug 2004 12:34:28 -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 i7OJYRT1050618 for ; Tue, 24 Aug 2004 12:34:28 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 24 Aug 2004 20:39:29 +0100 Message-ID: <412B9840.9070601@isode.com> Date: Tue, 24 Aug 2004 20:34: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 MIME-Version: 1.0 To: Cyrus Daboo CC: Lisa Dusseault , IMAP Extensions WG Subject: Re: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> In-Reply-To: <95574C2548DA27BD2E017D01@ninevah.cyrusoft.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: Cyrus Daboo wrote: > Hi Alexey, > > --On Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov > wrote: > >> One more issue: I was debating with myself whether SUBMAILBOXES is a >> match option or a return option. It seems that return options should not >> generally affect information about which mailboxes is returned (this is >> what match options do). However SUBMAILBOXES forces the server to >> [possibly] return information about parent mailboxes. I think this is a >> single exception which should be allowed and clearly documented. > > > One option would be to change it to a match option instead of a return > option and rename it appropriately. e.g. add the search option > 'MATCHPARENT' which causes non-matching parent items to be matched and > implicitly results in \PlaceHolder and \HasSubmailboxes being computed > and returned. That would make the behaviour consistent. Hmm, this sounds sufficient. We wouldn't need another return option for this? 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 i7OJNufp049716; Tue, 24 Aug 2004 12:23:56 -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 i7OJNuUU049715; Tue, 24 Aug 2004 12:23:56 -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 i7OJNti4049700 for ; Tue, 24 Aug 2004 12:23:56 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 24 Aug 2004 20:29:01 +0100 Message-ID: <412B95CC.5050906@isode.com> Date: Tue, 24 Aug 2004 20:23:56 +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: Dave Cridland CC: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> In-Reply-To: <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> 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: Dave Cridland wrote: >> On a second through, if existing ACL implementations are Ok with >> declaring the 's' right as controlling per-user flags (except for >> \Deleted of course) and annotations, that would be fine with me. > > Equally, I've not seen \Deleted implemented as anything but shared... Chris Newman thinks otherwise, although I've been surprised by this as well. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJHtAe049272; Tue, 24 Aug 2004 12:17: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 i7OJHtN0049271; Tue, 24 Aug 2004 12:17:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJHsQ2049264 for ; Tue, 24 Aug 2004 12:17:54 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D1CD1154009; Tue, 24 Aug 2004 19:17:57 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> In-Reply-To: <412B7F3B.60206@isode.com> Message-ID: <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 24 Aug 2004 20:17:14 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Aug 24 18:47:39 2004, Alexey Melnikov wrote: > Dave Cridland wrote: >> 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the >> only per-user data I'm aware of in an IMAP4 shared mailbox. > > I don't think ACL2 says that 's' only controls private (per-user) > \Seen even though Cyrus Imap implements the \Seen flag as private. > I've implemented \Seen as a shared flag once. Having said that, I > don't like overloading the meaning of different ACL rights. > > Ah, yes, sorry, you're right - I just hadn't thought of \Seen as being anything but a private flag. > On a second through, if existing ACL implementations are Ok with > declaring the 's' right as controlling per-user flags (except for > \Deleted of course) and annotations, that would be fine with me. Equally, I've not seen \Deleted implemented as anything but shared... I'd guess that the sole purpose of having 's' seperate was to support the notion of the private versus shared flags in Cyrus. I don't know other implementations' semantics well enough to know if it's worth formally redefining it in ACL2 to simply mean "private". Dave. 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 i7OIueRK045777; Tue, 24 Aug 2004 11:56:40 -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 i7OIuepE045776; Tue, 24 Aug 2004 11:56:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIudqp045761 for ; Tue, 24 Aug 2004 11:56:40 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id E3EE7154009 for ; Tue, 24 Aug 2004 18:56:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Subject: LISTEXT-08, REMOTE Message-ID: <20040824185559.11765.62533.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 24 Aug 2004 19:55:59 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've a few problems with the REMOTE match and return modifier as specified in listext-08. I've tossed a couple of ideas at Alexey, and I'll reprise them here, as well as (my interpretation of) his responses. Specifically: 1) The REMOTE return option (hereafter referred to as REMOTE-return) is redundant, and serves no purpose at all in the current specification. It should therefore be modified or removed. Consider: a) a LIST (REMOTE) "" "*" b) b LIST (REMOTE) "" "*" RETURN (REMOTE) c) c LIST "" "*" d) d LIST "" "*" RETURN (REMOTE) d is identical to c, b is identical to a. If it's redundant, then it's just going to confuse people. In my opinion, it needs to be stripped out of the specification. (It serves no purpose whatsoever as it stands). 2) REMOTE does not match the similarly syntaxed SUBSCRIBED: e) e LIST (SUBSCRIBED) "" "*" f) f LIST (SUBSCRIBED) "" "*" RETURN (SUBSCRIBED) g) g LIST "" "*" h) h LIST "" "*" RETURN (SUBSCRIBED) Here, while f is identical to e, h is not identical to g. e and f both list *only* subscribed mailboxes, whereas g and h lists all mailboxes. h also provides \Subscribed flags as approriate. To put it another way, REMOTE-match increases the matching mailboxes, whereas SUBSCRIBED-match reduces them. SUBSCRIBED-return simply adds subscription information, whereas REMOTE-return does nothing. 3) We could change REMOTE-match to match remote mailboxes only, and change REMOTE-return from a noop to imply that remote mailboxes should be included in the search. Alexey suggested: > So you want a return option to change which mailboxes *match* the > selection criteria, which seems slightly wrong to me. However, I don't think it is changing what's matched, but what mailboxes are searched through, which is slightly different, and has precedent - SUBMAILBOXES changes what's searched through as well. The result would be: a) Now lists only REMOTE mailboxes, with flags. [Presumably it would list local mailboxes that had children who are remote with \Placeholder where approriate.] b) Does the same. [I'm assuming that, like SUBSCRIBED, the return option remains implied] c) Remains unchanged, as it has to. d) Lists all mailboxes, flagging those that are remote. [The same as a in the current specification.] 4) Alexey floated this idea: > What about having REMOTEONLY match option in addition to REMOTE > match option? A match, to me, means "ONLY" anyway. :-) A subtle variation on this would be to create a LOCAL match, on by default, but turned off by the REMOTE match - this still leaves REMOTE-return redundant, though, so it'd still have to be stripped out of the specification, in my opinion. 5) Alexey also floated this: > An alternative is to change the definition of REMOTE to only match > remote mailboxes and force the client to issue 2 extended LIST > commands to get information about both local and remote mailboxes. Which I don't like anymore than I suspect he does. I have to admit, I can't think of a real-world circumstance where a client would want to limit the mailboxes returned by a LIST to only remote ones. (There's specialized management clients, of course, but those are on fast connections I assume, and could presumably cope with the extra information.) So it's quite possible that the best solution is to get rid of either REMOTE-match or REMOTE-return entirely and have done with it. Dave. 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 i7OHlcx4029409; Tue, 24 Aug 2004 10:47:38 -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 i7OHlcEA029407; Tue, 24 Aug 2004 10:47:38 -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 i7OHlbRt029395 for ; Tue, 24 Aug 2004 10:47:38 -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, 24 Aug 2004 18:52:43 +0100 Message-ID: <412B7F3B.60206@isode.com> Date: Tue, 24 Aug 2004 18:47:39 +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: Dave Cridland CC: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> In-Reply-To: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> 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: Dave Cridland wrote: > Hiya, folks. > > I noticed the thread in the archives about ANNOTATE/ACL interaction, > and Arnt Gulbrandsen's comment on it. > > A quick suggestion: > > Could we use the 's' right to indicate permission to store private > annotations, and the 'w' write to store shared ones? > > This seems more logical to me, since: > > 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only > per-user data I'm aware of in an IMAP4 shared mailbox. I don't think ACL2 says that 's' only controls private (per-user) \Seen even though Cyrus Imap implements the \Seen flag as private. I've implemented \Seen as a shared flag once. Having said that, I don't like overloading the meaning of different ACL rights. On a second through, if existing ACL implementations are Ok with declaring the 's' right as controlling per-user flags (except for \Deleted of course) and annotations, that would be fine with me. > 'w' is used for 'flags other than \SEEN and \DELETED' - in other > words, those flags which are informational only to the server, but > affect other clients. 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 i7OFxJhP004929; Tue, 24 Aug 2004 08:59: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 i7OFxJYc004928; Tue, 24 Aug 2004 08:59:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFxIO8004921 for ; Tue, 24 Aug 2004 08:59:18 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id B58FD154009 for ; Tue, 24 Aug 2004 15:59:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Subject: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 24 Aug 2004 16:58:37 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hiya, folks. I noticed the thread in the archives about ANNOTATE/ACL interaction, and Arnt Gulbrandsen's comment on it. A quick suggestion: Could we use the 's' right to indicate permission to store private annotations, and the 'w' write to store shared ones? This seems more logical to me, since: 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only per-user data I'm aware of in an IMAP4 shared mailbox. 'w' is used for 'flags other than \SEEN and \DELETED' - in other words, those flags which are informational only to the server, but affect other clients. In the absence of ACL2, or ACL: If SELECT returns [READ-ONLY], then private annotation stores MAY succeed (in line with 3501/6.3.1), but shared annotation stores MUST fail (likewise). If EXAMINE is used, then all annotation stores MUST fail (3501/6.3.2 appears to support this.) However, since there seems much debate about this, perhaps I'm missing something obvious? Feel free to shoot me down in flames if I'm being an idiot. :-) Dave. 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 i7OEW8u1084259; Tue, 24 Aug 2004 07:32:09 -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 i7OEW83Y084258; Tue, 24 Aug 2004 07:32:08 -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 i7OEW73s084220 for ; Tue, 24 Aug 2004 07:32:08 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7OEF8o3015985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 10:15:10 -0400 Date: Tue, 24 Aug 2004 10:32:03 -0400 From: Cyrus Daboo To: Alexey Melnikov , Lisa Dusseault cc: IMAP Extensions WG Subject: Re: LISTEXT to finish... Message-ID: <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> In-Reply-To: <412B3528.7080808@isode.com> References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov wrote: > One more issue: I was debating with myself whether SUBMAILBOXES is a > match option or a return option. It seems that return options should not > generally affect information about which mailboxes is returned (this is > what match options do). However SUBMAILBOXES forces the server to > [possibly] return information about parent mailboxes. I think this is a > single exception which should be allowed and clearly documented. One option would be to change it to a match option instead of a return option and rename it appropriately. e.g. add the search option 'MATCHPARENT' which causes non-matching parent items to be matched and implicitly results in \PlaceHolder and \HasSubmailboxes being computed and returned. That would make the behaviour consistent. -- 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 i7OCVl6m057323; Tue, 24 Aug 2004 05:31:47 -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 i7OCVl2T057322; Tue, 24 Aug 2004 05:31:47 -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 i7OCVkYr057300 for ; Tue, 24 Aug 2004 05:31:46 -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, 24 Aug 2004 13:36:39 +0100 Message-ID: <412B3528.7080808@isode.com> Date: Tue, 24 Aug 2004 13:31:36 +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: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> In-Reply-To: <2B5435B6-F55D-11D8-93B2-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: > We need to resolve all the editor comments/questions left in the > draft, so I've gone through each one to give an opinion. Most > importantly, I propose to leave \PlaceHolder in place, but to provide > an example that illustrates its use. At some point we'll need a draft > without those comments & go to last call. > > 1. "< name begins with a parenthesis, the new syntax is being used; if it > does not, it's in the original syntax>>." > > For this one, the << and >> need to be taken out -- the sentence > fragment (or one like it) is needed. I will update this sentence to match the reality: there are now 3 ways (instead of 1 as described) to detect new syntax. No action is required from the WG. > 2. "< upon publication as an RFC>>" > > Please change this to a RFC EDITOR note. Ok. > 3. "< removed..." > > Let's leave \PlaceHolder in place. If anybody has specific > suggestions for improving the explanations, please provide them. If > anybody really objects to \Placeholder, please provide either an > alternative name or an alternative mechanism to solve the problem. > > To make the spec clearer, an example will be provided as per another > comment. Make sense. > 4. "<>" > > I think this can be left as is for the RFC editor to deal with. > > 5. "< support for it is a prerequisite for any future extensions that > require specialized forms of the LIST command>>" > > For this one, remove << and >> and leave the sentence fragment in place. The issues here is that I would like to allow for IMAP extensions that *generate* LISTEXT responses, but don't necessarily support extended LIST syntax (i.e. they don't *parse* extended LIST command) or don't have to support the core set of match options: SUBSCRIBED/REMOTE/CHILDREN/SUBMAILBOXES. One example of such extension is ACL2. One can read the current draft that any ACL2 server MUST advertise both LISTEXT and ACL2 in its capability response. In order to clarify that this is not the case, I will need to do some text reorganization. > 6. "<>" > > Agreed. please put one in or refer to a later example that > illustrates this. Ok. > 7. "< return option (see below).>>" > 8. "< return option (see below).>>" > > I think for both of these, the comment markers << and >> can be > removed and the sentences remain to help readers. I agree. I will also update IANA registration template to allow a match option to require a particular return option (see issue #13 below). > 9. "<>" > 10. "<>" > > Shouldn't this be "folders/folder"? Take a stab at it, at any rate, > remove the question mark and << >>. Maybe. We need some term for something which is not necessary a mailbox, e.g. a "non existent mailbox". I vaguely remember that Mark has made some suggestion on this, I will have to double check. > 11. "< of the output in the previous example? What about nonexistent > "Fruit/Peach"?>>" > > Obviously it's not a superset. Why not remove this comment, text > included. Ok. I am tempted to update the Note to say that is is not a superset, so that other people don't get confused ;-). > 12. "<>" > > This is a problem -- commented text that appears in the middle of an > example. Should this line appear or not? This probably also requires > clarifying text up front once the authors make a decision, to explain > why that's the only decision that will be possible to implementors of > the spec. This relates to #11. > 13. " <>" > > I don't know about this one -- authors, please make a recommendation. I think #7 and #8 answer this. > I get the feeling that implied return options don't need to appear > in the registration template Thinking more about this: I don't think this is the case. I still can see a situation when a return option doesn't have a corresponding match option. So we should keep two registration templates. > but that extra information may need to appear elsewhere. One more issue: I was debating with myself whether SUBMAILBOXES is a match option or a return option. It seems that return options should not generally affect information about which mailboxes is returned (this is what match options do). However SUBMAILBOXES forces the server to [possibly] return information about parent mailboxes. I think this is a single exception which should be allowed and clearly documented. 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 i7NNZtqR048470; Mon, 23 Aug 2004 16:35: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 i7NNZtaf048469; Mon, 23 Aug 2004 16:35:55 -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 i7NNZtB4048462 for ; Mon, 23 Aug 2004 16:35:55 -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 i7NNZvpp026272 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 23 Aug 2004 16:35:58 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: LISTEXT to finish... Date: Mon, 23 Aug 2004 16:35:51 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We need to resolve all the editor comments/questions left in the draft, so I've gone through each one to give an opinion. Most importantly, I propose to leave \PlaceHolder in place, but to provide an example that illustrates its use. At some point we'll need a draft without those comments & go to last call. 1. "<>." For this one, the << and >> need to be taken out -- the sentence fragment (or one like it) is needed. 2. "<>" Please change this to a RFC EDITOR note. 3. "<>" I think this can be left as is for the RFC editor to deal with. 5. "<>" For this one, remove << and >> and leave the sentence fragment in place. 6. "<>" Agreed. please put one in or refer to a later example that illustrates this. 7. "<>" 8. "<>" I think for both of these, the comment markers << and >> can be removed and the sentences remain to help readers. 9. "<>" 10. "<>" Shouldn't this be "folders/folder"? Take a stab at it, at any rate, remove the question mark and << >>. 11. "<>" Obviously it's not a superset. Why not remove this comment, text included. 12. "<>" This is a problem -- commented text that appears in the middle of an example. Should this line appear or not? This probably also requires clarifying text up front once the authors make a decision, to explain why that's the only decision that will be possible to implementors of the spec. 13. " <>" I don't know about this one -- authors, please make a recommendation. I get the feeling that implied return options don't need to appear in the registration template but that extra information may need to appear elsewhere. 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 i7IMHZ2u050895; Wed, 18 Aug 2004 15:17: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 i7IMHZPG050894; Wed, 18 Aug 2004 15:17:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMHW8m050874 for ; Wed, 18 Aug 2004 15:17:34 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7IMHUl5001667 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 18 Aug 2004 15:17:30 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7IMHU5V018501; Wed, 18 Aug 2004 15:17:30 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408182217.i7IMHU5V018501@lab.smi.sendmail.com> To: Timo Sirainen Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: New revision of draft-ietf-imapext-list-extensions In-reply-to: <7291DBD4-F15D-11D8-A412-000393CC2E90@iki.fi> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> <200408182040.i7IKegGd011514@lab.smi.sendmail.com> <7291DBD4-F15D-11D8-A412-000393CC2E90@iki.fi> Date: Wed, 18 Aug 2004 15:17:30 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: >On 18.8.2004, at 23:40, Philip Guenther wrote: ... >> When there are no selection options like SUBSCRIBED, then you can >> derive the CHILDREN flags from the SUBMAILBOXES flags: >> - \HasSubmailboxes implies \HasChildren >> - \PlaceHolder implies \HasChildren and \Nonexistent > >I thought \PlaceHolder would never appear then? Consider a system where the mailbox "foo/bar" can exist without "foo" existing (this can happen under Cyrus, for example). tag LIST (SUBMAILBOXES) "" % should include * LIST (\PlaceHolder \NonExistent) "/" "foo" among its responses. >> - having neither \HasSubmailboxes nor \PlaceHolder implies >> \HasNoChildren > >If a subscribed mailbox has non-subscribed children, I don't think >\HasSubmailboxes is supposed to be sent then? In that case it doesn't >imply \HasNoChildren. Correct. My statement was in the context of the "When there are no selection options like SUBSCRIBED" constraint. >Maybe the \HasSubmailboxes should rather be named \HasSubMatches or >something similiar? I'm not particularly attached to the names, though \HasSubMatches may make it seem the submailbox in question matches the _pattern_ instead of the selection criteria. >How well in general does LISTEXT allow server to send LIST replies to >client unilaterally? It doesn't affect it all: the server can always send whatever responses it wants, though they better be "true" in some sense. Rob raised this before, which led to the addition of the \Subscribed and \Remote flags to eliminate the ambiguity that can be created. (See the list archives for an example.) >For example to update \Marked, \UnMarked or >\Subscribed flags, or simply to announce existance of new mailbox? At >least any assumptions about the meaning of lack of flags seem to break >then. Yes and no. Suppose you receive one or more LIST responses for a mailbox between the time you send a LIST command and you get the tagged OK. Responses for mailboxes that don't match the reference+pattern arguments were unsolicited, so you can't draw a conclusion from the absence of flags for them. Similarly, if the LIST had the SUBSCRIBED option, then responses that don't have the \Subscribed flag were unsolicited. For the rest of responses, at least one of them for each mailbox has the right flags, so the union of the flags returned for a given mailbox should be correct for drawing conclusions about it not having any children, etc. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILS0Ns042428; Wed, 18 Aug 2004 14:28:00 -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 i7ILS0GZ042427; Wed, 18 Aug 2004 14:28:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILRw8u042388 for ; Wed, 18 Aug 2004 14:27:59 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 7DF461C3510E; Thu, 19 Aug 2004 00:27:55 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 37B011C1D0E0; Thu, 19 Aug 2004 00:27:49 +0300 (EEST) In-Reply-To: <200408182040.i7IKegGd011514@lab.smi.sendmail.com> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> <200408182040.i7IKegGd011514@lab.smi.sendmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12-740633111" Message-Id: <7291DBD4-F15D-11D8-A412-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Thu, 19 Aug 2004 00:27:46 +0300 To: Philip Guenther X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-12-740633111 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 18.8.2004, at 23:40, Philip Guenther wrote: > This is the key difference between SUBMAILBOXES and CHILDREN options: > the former tells you whether there are children mailboxes that match > the selection criteria, the latter tells you whether there are > children mailboxes that simply _exist_. OK, this makes sense now. I think the draft text needs to be clarified a bit, at least added something about the children and submailboxes difference. Also the term "selection criteria" doesn't seem to be explained anywhere in the draft. > When there are no selection options like SUBSCRIBED, then you can > derive the CHILDREN flags from the SUBMAILBOXES flags: > - \HasSubmailboxes implies \HasChildren > - \PlaceHolder implies \HasChildren and \Nonexistent I thought \PlaceHolder would never appear then? > - having neither \HasSubmailboxes nor \PlaceHolder implies > \HasNoChildren If a subscribed mailbox has non-subscribed children, I don't think \HasSubmailboxes is supposed to be sent then? In that case it doesn't imply \HasNoChildren. Maybe the \HasSubmailboxes should rather be named \HasSubMatches or something similiar? How well in general does LISTEXT allow server to send LIST replies to client unilaterally? For example to update \Marked, \UnMarked or \Subscribed flags, or simply to announce existance of new mailbox? At least any assumptions about the meaning of lack of flags seem to break then. --Apple-Mail-12-740633111 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBI8nSyUhSUUBViskRAkvGAJ9Gqc7vLM8ZbrQxWjoXsUqWa6SK1ACgh+bK 08WQKzoq8JbjK1trrz7XhXA= =aEIR -----END PGP SIGNATURE----- --Apple-Mail-12-740633111-- 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 i7IKerGc034859; Wed, 18 Aug 2004 13:40:53 -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 i7IKervT034858; Wed, 18 Aug 2004 13:40:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKep9k034824 for ; Wed, 18 Aug 2004 13:40:52 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7IKegXA008615 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 18 Aug 2004 13:40:42 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7IKegGd011514; Wed, 18 Aug 2004 13:40:42 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408182040.i7IKegGd011514@lab.smi.sendmail.com> To: Timo Sirainen Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: New revision of draft-ietf-imapext-list-extensions In-reply-to: <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> Date: Wed, 18 Aug 2004 13:40:42 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: >On 17.8.2004, at 15:12, Alexey Melnikov wrote: >>> However what's the point of \HasSubmailboxes? Looks like the only >>> time it's returned is when doing LIST *, >> >> No, it will also be returned for LIST %. >> \PlaceHolder says that the mailbox doesn't match the selection >> option(s), but one of the children might. > >This I understand because it's required for LIST (subscribed) % to work >in a useful way. > >> \HasSubmailboxes says that the mailbox does match the selection >> option(s) and one of the children might. > >But this I still don't. You mean that LIST % will return >\HasSubmailboxes for all mailboxes that have children? No. The mailbox has to a) match the selection criteria (e.g., be subscribed), and b) have a child that matches the selection criteria. That it simply has a child mailbox is not sufficient. This is the key difference between SUBMAILBOXES and CHILDREN options: the former tells you whether there are children mailboxes that match the selection criteria, the latter tells you whether there are children mailboxes that simply _exist_. When there are no selection options like SUBSCRIBED, then you can derive the CHILDREN flags from the SUBMAILBOXES flags: - \HasSubmailboxes implies \HasChildren - \PlaceHolder implies \HasChildren and \Nonexistent - having neither \HasSubmailboxes nor \PlaceHolder implies \HasNoChildren When SUBSCRIBED or a similar option is involved, they may behave completely differently; for example, one mailbox may have a child that isn't subscribed (\HasChildren but not \HasSubMailboxes or \PlaceHolder), while another may 'have' a subscribed child that doens't exist any more (\HasSubMailboxes or \PlaceHolder, but not \HasChildren). To back track, \HasSubMailboxes came about after I asked what a server should do when it has at least one child mailbox that matches the selection criteria (say, SUBSCRIBED) but that doesn't match the pattern, for the case when the mailbox also matches the selection criteria. Before \HasSubMailboxes, only two answers made sense, though they both were ugly: 1) don't tell the client that there's a selected child at all * LIST () "/" foo 2) send *two* reponses for the mailboxes * LIST () "/" foo * LIST (\PlaceHolder) "/" foo If (1) is acceptable, then a client that wants to display the subscribed mailbox hierarchy level by level has to manually check for subscribed children below each subscribed mailbox. It has been argued that (2) is the correct answer for this situation with LSUB. In off-list mail with Alexey, I questioned the wisdom of designing a requirement that a server send two replies for a single mailbox. After some slogging back and forth, \HasSubMailboxes emerged. That part of the discussion should probably have migrated back to the list after the initial flailing around... >Why? I don't see >why % would match child mailboxes, isn't the whole point of it not to? It sounds like you're mixing the pattern matching of the names into the selection criteria. The definitions of \HasSubmailboxes and \PlaceHolder depend on keeping them separate. >Or do you mean that % would also match for child mailboxes? So for >example: > >LIST * >* LIST (\HasSubmailboxes) foo >* LIST () foo/bar Yes. (Well, you're leaving out the hierarchy delimiter...) >LIST % >* LIST (\HasSubmailboxes) foo Yes. >LIST %o >* LIST () foo No, that should return * LIST (\HasSubmailboxes) "/" foo too: "foo" has a child mailbox that matches the selection criteria (by existing). The change in pattern didn't affect which mailboxes were matched, why would you think anything had changed? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIEqiW009436; Wed, 18 Aug 2004 11:14:52 -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 i7IIEqPv009433; Wed, 18 Aug 2004 11:14:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIEoEk009406 for ; Wed, 18 Aug 2004 11:14:51 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 8F5371C3510E; Wed, 18 Aug 2004 21:14:46 +0300 (EEST) Received: from [192.168.10.2] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id E7A9A1C1D0E0; Wed, 18 Aug 2004 21:14:41 +0300 (EEST) Subject: Re: New revision of draft-ietf-imapext-list-extensions From: Timo Sirainen To: Alexey Melnikov Cc: IMAP Extensions WG In-Reply-To: <412332A6.8010706@isode.com> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> <412332A6.8010706@isode.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Vr62D9nes8XgKzM59a7y" Date: Wed, 18 Aug 2004 21:14:41 +0300 Message-Id: <1092852881.455.94.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 1.5.91 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-Vr62D9nes8XgKzM59a7y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-08-18 at 11:42 +0100, Alexey Melnikov wrote: > >> \HasSubmailboxes says that the mailbox does match the selection=20 > >> option(s) and one of the children might. > > > > But this I still don't. You mean that LIST % will return=20 > > \HasSubmailboxes for all mailboxes that have children? >=20 > It must if the CHILDREN option was also specified, but it may even=20 > without it (if this information is readily available on the server). \HasSubmailboxes isn't \HasChildren. > > Why? I don't see why % would match child mailboxes, isn't the whole=20 > > point of it not to?=20 >=20 > It will not match a child mailbox, but it will return information about=20 > them. > The assumption here is that the client is not doing LIST "" *, as it=20 > might return too many responses. Instead the client is doing LIST "" %,=20 > then for each mailbox marked with \HasChildren the client will=20 > try LIST "" /%. Yes, \HasChildren is useful for that. So why also have \HasSubmailboxes? Could you give some example when \HasSubmailboxes is useful for client, but \HasChildren isn't enough? To me they seem very much the same thing except \HasSubmailboxes has some very strange explanation when it's supposed to be sent. --=-Vr62D9nes8XgKzM59a7y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBI5yRyUhSUUBViskRArk2AJ9Rd7qWep58+VXqSMZqJGujVWAJywCgizoE WK794FhafRV4T6OxI7PocEQ= =kCs+ -----END PGP SIGNATURE----- --=-Vr62D9nes8XgKzM59a7y-- 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 i7IAhJO3091447; Wed, 18 Aug 2004 03:43: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 i7IAhJdR091446; Wed, 18 Aug 2004 03:43:19 -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 i7IAhI57091410 for ; Wed, 18 Aug 2004 03:43:18 -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, 18 Aug 2004 11:47:23 +0100 Message-ID: <412332A6.8010706@isode.com> Date: Wed, 18 Aug 2004 11:42:46 +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: Timo Sirainen CC: IMAP Extensions WG Subject: Re: New revision of draft-ietf-imapext-list-extensions References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> In-Reply-To: <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> 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: Timo Sirainen wrote: > On 17.8.2004, at 15:12, Alexey Melnikov wrote: > >>> However what's the point of \HasSubmailboxes? Looks like the only >>> time it's returned is when doing LIST *, >> >> No, it will also be returned for LIST %. >> \PlaceHolder says that the mailbox doesn't match the selection >> option(s), but one of the children might. > > This I understand because it's required for LIST (subscribed) % to > work in a useful way. > >> \HasSubmailboxes says that the mailbox does match the selection >> option(s) and one of the children might. > > But this I still don't. You mean that LIST % will return > \HasSubmailboxes for all mailboxes that have children? It must if the CHILDREN option was also specified, but it may even without it (if this information is readily available on the server). > Why? I don't see why % would match child mailboxes, isn't the whole > point of it not to? It will not match a child mailbox, but it will return information about them. The assumption here is that the client is not doing LIST "" *, as it might return too many responses. Instead the client is doing LIST "" %, then for each mailbox marked with \HasChildren the client will try LIST "" /%. > Or do you mean that % would also match for child mailboxes? So for > example: > > LIST * > * LIST (\HasSubmailboxes) foo > * LIST () foo/bar > > LIST % > * LIST (\HasSubmailboxes) foo > > LIST %o > * LIST () foo Yes. > I don't really understand that either. 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 i7HKxofL098082; Tue, 17 Aug 2004 13:59:50 -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 i7HKxoZb098081; Tue, 17 Aug 2004 13:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HKxmvf098061 for ; Tue, 17 Aug 2004 13:59:49 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id B837A1C3510E; Tue, 17 Aug 2004 23:59:45 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 318FC1C3510B; Tue, 17 Aug 2004 23:59:41 +0300 (EEST) In-Reply-To: <4121F616.1000506@isode.com> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-652547114" Message-Id: <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Tue, 17 Aug 2004 23:59:40 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-8-652547114 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 17.8.2004, at 15:12, Alexey Melnikov wrote: >> However what's the point of \HasSubmailboxes? Looks like the only >> time it's returned is when doing LIST *, > > No, it will also be returned for LIST %. > \PlaceHolder says that the mailbox doesn't match the selection > option(s), but one of the children might. This I understand because it's required for LIST (subscribed) % to work in a useful way. > \HasSubmailboxes says that the mailbox does match the selection > option(s) and one of the children might. But this I still don't. You mean that LIST % will return \HasSubmailboxes for all mailboxes that have children? Why? I don't see why % would match child mailboxes, isn't the whole point of it not to? Or do you mean that % would also match for child mailboxes? So for example: LIST * * LIST (\HasSubmailboxes) foo * LIST () foo/bar LIST % * LIST (\HasSubmailboxes) foo LIST %o * LIST () foo I don't really understand that either. --Apple-Mail-8-652547114 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBInG8yUhSUUBViskRAjnzAJ9f10vOZ3cbNk2EYePtfpXWTqb+ugCfcptO 0fDCHSqRHqDskxXcxgfMQ44= =8yfZ -----END PGP SIGNATURE----- --Apple-Mail-8-652547114-- 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 i7HHv2QD085173; Tue, 17 Aug 2004 10:57: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 i7HHv2v7085172; Tue, 17 Aug 2004 10:57: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 i7HHv1XO085166 for ; Tue, 17 Aug 2004 10:57:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust11.tnt24.lnd4.gbr.da.uu.net [62.188.151.11]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 17 Aug 2004 19:01:21 +0100 Message-ID: <4121F616.1000506@isode.com> Date: Tue, 17 Aug 2004 13:12:06 +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: Timo Sirainen CC: IMAP Extensions WG Subject: Re: New revision of draft-ietf-imapext-list-extensions References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> In-Reply-To: <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> 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: Timo Sirainen wrote: > On 16.8.2004, at 23:06, Lisa Dusseault wrote: > >> Did somebody have a proposal for what to do about \PlaceHolder? >> Without a preferred counter-proposal, we'll probably go to Last Call >> with the placeHolder stuff as-is. > > I don't remember seeing discussion here about \PlaceHolder. Seems > useful to me. > > However what's the point of \HasSubmailboxes? Looks like the only time > it's returned is when doing LIST *, No, it will also be returned for LIST %. \PlaceHolder says that the mailbox doesn't match the selection option(s), but one of the children might. \HasSubmailboxes says that the mailbox does match the selection option(s) and one of the children might. > and in that case the LIST reply for the submailbox itself is also > returned. Not for LIST "" "%". 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 i7HB3juH008920; Tue, 17 Aug 2004 04:03:45 -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 i7HB3j5U008919; Tue, 17 Aug 2004 04:03:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HB3geI008872 for ; Tue, 17 Aug 2004 04:03:44 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id D9A031C3510C; Tue, 17 Aug 2004 14:03:35 +0300 (EEST) Received: from [192.168.200.103] (kone5.procontrol.vip.fi [212.149.71.166]) by danu.procontrol.fi (Postfix) with ESMTP id 90CF71C3510B for ; Tue, 17 Aug 2004 14:03:31 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <411FE659.1050908@isode.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-616777331" Message-Id: <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Tue, 17 Aug 2004 14:03:30 +0300 To: IMAP Extensions WG X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-5-616777331 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 16.8.2004, at 23:06, Lisa Dusseault wrote: > Did somebody have a proposal for what to do about \PlaceHolder? > Without a preferred counter-proposal, we'll probably go to Last Call > with the placeHolder stuff as-is. I don't remember seeing discussion here about \PlaceHolder. Seems useful to me. However what's the point of \HasSubmailboxes? Looks like the only time it's returned is when doing LIST *, and in that case the LIST reply for the submailbox itself is also returned. --Apple-Mail-5-616777331 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBIeYCyUhSUUBViskRAqz/AJwIfvZG3CQhbVgydjl49oL2BHLSwgCglObs NLh6D91F0DBC+eUS2BhEaX0= =Jcjx -----END PGP SIGNATURE----- --Apple-Mail-5-616777331-- 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 i7H1lNXM015558; Mon, 16 Aug 2004 18:47:23 -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 i7H1lN0Q015557; Mon, 16 Aug 2004 18:47:23 -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 i7H1lKhS015520 for ; Mon, 16 Aug 2004 18:47:22 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust224.tnt2.lnd4.gbr.da.uu.net [62.188.131.224]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 17 Aug 2004 02:51:23 +0100 Message-ID: <41215188.3090008@isode.com> Date: Tue, 17 Aug 2004 01:30:00 +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: Timo Sirainen CC: IMAP Extensions WG Subject: Re: ANNOTATE and ACL interaction References: <411B9CF8.3000109@isode.com> <1092403627.455.38.camel@hurina> In-Reply-To: <1092403627.455.38.camel@hurina> 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: Timo Sirainen wrote: >On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote: > > >>a). 'w' right controls writability of shared annotations only. If this >>is combined with the assumption A), this means that adding a separate >>right just for controlling private annotations doesn't make much sense: >>who really cares that you've set your private version of /altsubject? >>The most damage the user can do it to run out of disk quota. >> >>So, in this case the 'w' right controls shared annotations (and will >>result in READ-WRITE response code as described in section 9.2 of the >>draft-ietf-imapext-acl-10.txt). No right is required to store private >>annotations (the ability to open a mailbox, i.e. the 'r' right, is >>sufficient). Larry has suggested this behavior before. >> >> > >What about some public anonymous accounts where you don't want it? > Good point. >Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess? > Just returning NO would be fine, unless we want to be specific which response code should be used. >Other than in that case, I think user should always be free to set >private annotations where he wants. > Ok. We can add a note saying that an ANNOTATE server may choose to disallow storage of private annotations for some users, e.g. "anonymous". 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 i7GK6ICN090288; Mon, 16 Aug 2004 13:06: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 i7GK6Ino090287; Mon, 16 Aug 2004 13:06:18 -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 i7GK6IBm090275 for ; Mon, 16 Aug 2004 13:06:18 -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 i7GK6Kpp015082 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 16 Aug 2004 13:06:20 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <411FE659.1050908@isode.com> References: <411FE659.1050908@isode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Mon, 16 Aug 2004 13:06:13 -0700 To: IMAP Extensions WG 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: Did somebody have a proposal for what to do about \PlaceHolder? Without a preferred counter-proposal, we'll probably go to Last Call with the placeHolder stuff as-is. Lisa On Aug 15, 2004, at 3:40 PM, Alexey Melnikov wrote: > < removed: > 2) There are only two reasons for including a matching mailbox name > in the responses to the LIST command: > > a) the mailbox name also satisfies the selection criteria; > > b) the mailbox name has at least one child mailbox that satisfies > the selection criteria, but doesn't match the canonical LIST > pattern. For more information on this case see the > \PlaceHolder > flag description in Section 3. 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 i7GJIuli087174; Mon, 16 Aug 2004 12:18:56 -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 i7GJIuBo087173; Mon, 16 Aug 2004 12:18:56 -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 i7GJIuVS087165 for ; Mon, 16 Aug 2004 12:18:56 -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 PAA24610; Mon, 16 Aug 2004 15:18:58 -0400 (EDT) Message-Id: <200408161918.PAA24610@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-08.txt Date: Mon, 16 Aug 2004 15:18:57 -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-08.txt Pages : 0 Date : 2004-8-16 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-08.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-08.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-08.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-8-16153629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-16153629.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 i7G2lj0d003399; Sun, 15 Aug 2004 19:47:45 -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 i7G2ljjx003398; Sun, 15 Aug 2004 19:47:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G2liMv003389 for ; Sun, 15 Aug 2004 19:47:45 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 42CEF4F101 for ; Sun, 15 Aug 2004 22:47:43 -0400 (EDT) Message-Id: <4.2.0.58.J.20040816112029.05e49bc8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 16 Aug 2004 11:29:05 +0900 To: ietf-imapext@imc.org From: Martin Duerst Subject: new mailing list: public-ietf-collation@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear IMAP experts, After discussion with Chris Newman, author of the Internet Draft http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt, we have created a new mailing list, public-ietf-collation@w3.org, for discussion (and hopefully completion) of this work on identifiers for collations. This mailing list replaces an earlier one hosted at a different place. If you want to contribute or are interested in this work, please subscribe by sending mail to public-ietf-collation-REQUEST@w3.org (capitalization irrelevant) with "subscribe" (without the quotes) in the subject. The archives of this mailing list can be found at http://lists.w3.org/Archives/Public/public-ietf-collation/, and are publicly accessible. I expect discussion to begin no earlier than Monday, August 23, to allow everybody interested to subscribe. Regards, Martin. 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 i7DDRMiH084492; Fri, 13 Aug 2004 06:27:22 -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 i7DDRMWX084491; Fri, 13 Aug 2004 06:27:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DDRKrK084413 for ; Fri, 13 Aug 2004 06:27:21 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id BF9AF1C35106; Fri, 13 Aug 2004 16:27:14 +0300 (EEST) Received: from [192.168.10.2] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id C617C1C350EE; Fri, 13 Aug 2004 16:27:09 +0300 (EEST) Subject: Re: ANNOTATE and ACL interaction From: Timo Sirainen To: Alexey Melnikov Cc: IMAP Extensions WG In-Reply-To: <411B9CF8.3000109@isode.com> References: <411B9CF8.3000109@isode.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t+1YSF9UoMZWXD4W00Hk" Date: Fri, 13 Aug 2004 16:27:07 +0300 Message-Id: <1092403627.455.38.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 1.5.91 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-t+1YSF9UoMZWXD4W00Hk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote: > a). 'w' right controls writability of shared annotations only. If this > is combined with the assumption A), this means that adding a separate > right just for controlling private annotations doesn't make much sense: > who really cares that you've set your private version of /altsubject? > The most damage the user can do it to run out of disk quota. >=20 > So, in this case the 'w' right controls shared annotations (and will > result in READ-WRITE response code as described in section 9.2 of the > draft-ietf-imapext-acl-10.txt). No right is required to store private > annotations (the ability to open a mailbox, i.e. the 'r' right, is > sufficient). Larry has suggested this behavior before. What about some public anonymous accounts where you don't want it? Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess? Other than in that case, I think user should always be free to set private annotations where he wants. --=-t+1YSF9UoMZWXD4W00Hk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBHMGryUhSUUBViskRAr6iAJ4thdvFXoZnybr6U6GxkutBnCRWVwCfXM2k 3pQtCNbcEbaZ5NtYKzaZWQQ= =rbE5 -----END PGP SIGNATURE----- --=-t+1YSF9UoMZWXD4W00Hk-- 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 i7CGcNLl099722; Thu, 12 Aug 2004 09:38:23 -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 i7CGcNPB099721; Thu, 12 Aug 2004 09:38:23 -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 i7CGcLlI099709 for ; Thu, 12 Aug 2004 09:38:22 -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, 12 Aug 2004 17:42:23 +0100 Message-ID: <411B9CF8.3000109@isode.com> Date: Thu, 12 Aug 2004 17:38:16 +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: ANNOTATE and ACL interaction 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: [Resending, as I've used a wrong email address] Let me try to iterate through this again and give my suggestions: 1). A client should be able to fetch private and shared annotations if it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or READ-WRITE). 2). Writability of different annotations is a more difficult question. Let me try to propose several solutions and give my comments. Assumptions: A). Ability to change shared annotations is an extra privilege to the ability to change private annotations, as there might be a security risk if a user is allowed to change shared annotations. B). A right required to change shared annotations is different from the right required to change private annotations. C). ACL 'w' right currently controls writability of all flags (with exception of \Seen and \Deleted, which will be ignored in the following discussion). It makes sense that the 'w' right also controls one of the following: I). writability of shared annotations only II). writability of private annotations only III). both. The assumptions result in the following cases: a). 'w' right controls writability of shared annotations only. If this is combined with the assumption A), this means that adding a separate right just for controlling private annotations doesn't make much sense: who really cares that you've set your private version of /altsubject? The most damage the user can do it to run out of disk quota. So, in this case the 'w' right controls shared annotations (and will result in READ-WRITE response code as described in section 9.2 of the draft-ietf-imapext-acl-10.txt). No right is required to store private annotations (the ability to open a mailbox, i.e. the 'r' right, is sufficient). Larry has suggested this behavior before. b). 'w' right controls writability of private annotations only. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'w' right doesn't control READ-WRITE state, but the new 'H' right does. However the 'w' right controls writability of all IMAP flags (ignoring \Seen and \Deleted), whether they are shared or private. c). 'w' right controls writability of both private and shared annotations. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. This also means that writability of private annotations requires a separate right, let's call it the 'V' right for now. The 'w' right is 'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x'). The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'H' right (and thus the 'w' right) controls READ-WRITE state. ============ From the 3 cases mentioned above I don't like b), as it suggest that the effect of the 'w' right is different for flags and annotations, which is bad. It might also mean that on existing ACL servers users have to update all ACLs to allow for storing of shared annotations. The case c). requires more modifications to the ACL document. So unless somebody can give an argument that it is important to be able to disallow a user to be able to store private annotations I would slightly favor a) over c). Comments? 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 i7CGagcl099594; Thu, 12 Aug 2004 09:36: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 i7CGagA6099593; Thu, 12 Aug 2004 09:36: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 i7CGaa75099581 for ; Thu, 12 Aug 2004 09:36:39 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 12 Aug 2004 17:40:24 +0100 Message-ID: <411B9C80.60905@isode.com> Date: Thu, 12 Aug 2004 17:36:16 +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: IMAP Extensions WG Subject: ANNOTATE and ACL interaction 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: Let me try to iterate through this again and give my suggestions: 1). A client should be able to fetch private and shared annotations if it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or READ-WRITE). 2). Writability of different annotations is a more difficult question. Let me try to propose several solutions and give my comments. Assumptions: A). Ability to change shared annotations is an extra privilege to the ability to change private annotations, as there might be a security risk if a user is allowed to change shared annotations. B). A right required to change shared annotations is different from the right required to change private annotations. C). ACL 'w' right currently controls writability of all flags (with exception of \Seen and \Deleted, which will be ignored in the following discussion). It makes sense that the 'w' right also controls one of the following: I). writability of shared annotations only II). writability of private annotations only III). both. The assumptions result in the following cases: a). 'w' right controls writability of shared annotations only. If this is combined with the assumption A), this means that adding a separate right just for controlling private annotations doesn't make much sense: who really cares that you've set your private version of /altsubject? The most damage the user can do it to run out of disk quota. So, in this case the 'w' right controls shared annotations (and will result in READ-WRITE response code as described in section 9.2 of the draft-ietf-imapext-acl-10.txt). No right is required to store private annotations (the ability to open a mailbox, i.e. the 'r' right, is sufficient). Larry has suggested this behavior before. b). 'w' right controls writability of private annotations only. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'w' right doesn't control READ-WRITE state, but the new 'H' right does. However the 'w' right controls writability of all IMAP flags (ignoring \Seen and \Deleted), whether they are shared or private. c). 'w' right controls writability of both private and shared annotations. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. This also means that writability of private annotations requires a separate right, let's call it the 'V' right for now. The 'w' right is 'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x'). The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'H' right (and thus the 'w' right) controls READ-WRITE state. ============ From the 3 cases mentioned above I don't like b), as it suggest that the effect of the 'w' right is different for flags and annotations, which is bad. It might also mean that on existing ACL servers users have to update all ACLs to allow for storing of shared annotations. The case c). requires more modifications to the ACL document. So unless somebody can give an argument that it is important to be able to disallow a user to be able to store private annotations I would slightly favor a) over c). Comments? 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 i7CGKRYb097162; Thu, 12 Aug 2004 09:20:27 -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 i7CGKRkE097161; Thu, 12 Aug 2004 09:20:27 -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 i7CGKQwN097147 for ; Thu, 12 Aug 2004 09:20:26 -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, 12 Aug 2004 17:24:22 +0100 Message-ID: <411B98B6.3020103@isode.com> Date: Thu, 12 Aug 2004 17:20:06 +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: Cyrus Daboo CC: Lisa Dusseault , IMAP Extensions WG Subject: ANNOTATE (was Re: New IMAPEXT WG Charter proposal) References: <00EE5AC6F5CA9C13786A7C4B@ninevah.cyrusoft.com> In-Reply-To: <00EE5AC6F5CA9C13786A7C4B@ninevah.cyrusoft.com> MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Lisa, > > --On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault > wrote: > >> Philip suggested allowing ourselves slightly longer to actually get >> annotate and listext done, but since this is what we came up with in the >> room I said he should propose that on the list once I posted this to the >> list... > > > The only outstanding issue with ANNOTATE is what to do about flags. > The problem is the ambiguity of per-user vs shared flag/keyword > mapping based on the fact that different servers treat those in > different ways. Possible courses of action are: > > 1) Remove read and write access for IMAP flags and keywords in > ANNOTATE. This eliminates the problem altogether. One issue with this > is that the current CONDSTORE extension in RFC Editor queue does > depend on at least read access to flags in annotate. If we changed > ANNOTATE in this way we would have to 'recall' CONDSTORE - I am not > sure what mechanisms exist to do that... I really-really-really don't like this. If we end up going this route my preference would be to remove CONDSTORE dependencies on SORT and ANNOTATE. > 2) Only allow read access to IMAP flags and keywords. There are two > possibilities for this: > > - The .priv and .shared values are always the same representing the > base IMAP state. Although this is ugly, this might work. I think the WG agrees that the client usually don't care whether a flag is implemented as shared or private. > - One of .priv or .shared is set to 'NIL', whilst the other > represents the base IMAP state. The server will use the appropriate > .priv or .shared based on the actual per-user or shared behaviour of > the base flag/keyword. Although this reflect the true server state, this seems overly complex. > 3) Allow both read and write access as currently defined, but clearly > outline how these map to per-user and shared flags. > > One possibility for (3) that we did not consider before is to add a > new attribute to the /flags hierarchy that would allow the server to > indicate which of the .priv or .shared values map to the base IMAP > flag/keyword. e.g. we require a 'default' attribute on each /flag > entry with values 'priv' or 'shared' to indicate which annotation is > tied to the base value. A server that supports ACL and has the 's' bit > off would use 'shared' for the 'default' attribute on /flags/\seen, or > if the 's' bit is on it would use 'priv' for the new attribute. I had a similar idea in mind: the server returns SHAREDFLAGS response on SELECT/EXAMINE. I had some text about SHAREDFLAGS in one of my drafts, but it got dropped because I wasn't sure if it was that useful. Now we seem to agree that it is. Anyway, this solution bring back the problem that we've discussed in San Diego: inconsistency between rights that control changes to different IMAP flags and rights which control changes to annotations. > Another approach would be to do the same thing but using ANNOTATEMORE > to enumerate the flags/keywords for a specific mailbox and indicate > how the base state maps to .priv and .shared. This makes sense in that > this state is a per-mailbox attribute rather than a per-message attribute. Yes. > However this adds a probably unwanted dependency on ANNOTATEMORE. Yes, this is an issue and we probably don't want ANNOTATEMORE dependency. I think there is another possible solution: 4). Reserve /flags hierarchy for CONDSTORE and don't allow fetches or changes to IMAP flags through ANNOTATION interface. The reserved hierarchy will only be used in the SEARCH command as described in the CONDSTORE document. To summarize, I would prefer either 2a) or 4). 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 i7AIls6x055866; Tue, 10 Aug 2004 11:47:54 -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 i7AIlswr055865; Tue, 10 Aug 2004 11:47:54 -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 i7AIlrXj055857 for ; Tue, 10 Aug 2004 11:47:53 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7AIlspp023588 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 10 Aug 2004 11:47:54 -0700 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7BD@vsvapostal8.vcorp.ad.vrsn.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7BD@vsvapostal8.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'IMAP Extensions WG'" , "'Alexey Melnikov'" From: Lisa Dusseault Subject: Re: New IMAPEXT WG Charter proposal Date: Tue, 10 Aug 2004 11:47:44 -0700 To: "Scott Hollenbeck" 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: I wanted to propose clarifying text because I felt the charter text was so minimal as to be quite ambiguous to a newcomer (though meaningful to a participant). Perhaps at this point it doesn't matter -- the milestones may make the specific goals sufficiently clear. But, unless other people speak out in favour of clearer charter text, I'll remove the new text and submit only the milestones, with Alexey's clarifications. Lisa On Aug 10, 2004, at 5:42 AM, Scott Hollenbeck wrote: > >> Note, that any Charter text change requires IESG approval, while >> milestones change will only require approval by the >> responsible AD (i.e. >> Scott). > > Right -- I was going to mention that myself. IESG approval isn't > usually a > big deal, but it can take a few weeks. > > -Scott- > 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 i7ACfnxr092558; Tue, 10 Aug 2004 05:41:49 -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 i7ACfnpv092557; Tue, 10 Aug 2004 05:41:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ACfmtV092531 for ; Tue, 10 Aug 2004 05:41:48 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 10 Aug 2004 08:41:44 -0400 id 002F4006.4118C288.00002C77 From: "Scott Hollenbeck" To: "'Alexey Melnikov'" , "'Lisa Dusseault'" Cc: "'IMAP Extensions WG'" Subject: RE: New IMAPEXT WG Charter proposal Date: Tue, 10 Aug 2004 08:42:05 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7BD@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4118AF7B.8020206@isode.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Note, that any Charter text change requires IESG approval, while > milestones change will only require approval by the > responsible AD (i.e. > Scott). Right -- I was going to mention that myself. IESG approval isn't usually a big deal, but it can take a few weeks. -Scott- 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 i7ABxh0Z081502; Tue, 10 Aug 2004 04:59: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 i7ABxhJ4081501; Tue, 10 Aug 2004 04:59: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 i7ABxgFi081490 for ; Tue, 10 Aug 2004 04:59:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust162.tnt28.lnd4.gbr.da.uu.net [62.188.156.162]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 10 Aug 2004 13:03:25 +0100 Message-ID: <4118AF7B.8020206@isode.com> Date: Tue, 10 Aug 2004 12:20:27 +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: New IMAPEXT WG Charter proposal References: 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: Lisa Dusseault wrote: > Here is a proposed new charter for the IMAPEXT WG. I mostly edited > the milestones to say what we discussed in the WG meeting; however I > also added a small amount of detail to the list of new functions in > order to clarify (and limit) the list to what we're actually doing. > > Philip suggested allowing ourselves slightly longer to actually get > annotate and listext done, but since this is what we came up with in > the room I said he should propose that on the list once I posted this > to the list... > > Lisa > >> Description of Working Group: >> >> The IETF IMAP extensions Working Group shall revise and publish >> standards-track extensions to IMAP4 for performing the following >> functions: >> >> 1. Sorting and threading of messages in a single mailbox (to be dealt >> with by one or more mechanisms) >> >> 2. Access Control Lists -- either an update to, or a replacement for >> the existing Access Control document, particularly to provide a >> canonical list of rights and define how they affect various operations. >> >> 3. Message-level annotations -- a feature set to allow arbitrary >> user-level and shared annotations to be added to any message in >> compatible mailboxes. Must support multiple users/clients. >> >> Revising the base IMAP4rev1 specification is out of the scope of this >> WG. However, this WG will ensure that whatever extensions it does >> propose do not worsen any existing problems in the base specification >> of IMAP, nor do they make any such problems harder to address in the >> future. > Note, that any Charter text change requires IESG approval, while milestones change will only require approval by the responsible AD (i.e. Scott). >> Goals and Milestones: >> >> REMOVE THIS MILESTONE: Submit an Internet-Draft enumerating >> known problems to avoid in the base specification >> MARK AS DONE on Dec 03 Submit to IESG, draft on conditional >> storage to help multiple clients use a single mailbox > IMHO, "conditional STORE operation" seems better. >> MARK AS DONE on Feb 04 Submit to IESG, revised >> Sorting/Threading spec(s) >> Aug 04 WG last call for i18n draft >> Aug 04 WG Last call for annotate draft >> Aug 04 WG last call for LIST extensions draft, defining syntax >> allowing much better extensibility in the frequently-extended LIST >> command, and supporting other drafts in this WG > Do we have an exact date in mind? I've mostly finished updating LISTEXT, but I am afraid I will need one more revision to polish it. >> Sep 04 Submit to IESG, Internationalization draft >> Sep 04 Submit to IESG, revised annotate draft >> Oct 04 Submit to IESG, revised List Extensions draft >> Oct 04 Submit I-D to *update* existing ACL RFC, explaining >> rights & listing rights in CAPABILITY response >> Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL >> RFC >> Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met >> we agreed to close the WG and defer ACL2 to another WG. > 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 i79IsmA0003058; Mon, 9 Aug 2004 11:54:48 -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 i79Ismsi003057; Mon, 9 Aug 2004 11:54:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from WC-DEV02.com ([206.135.195.254]) by above.proper.com (8.12.11/8.12.9) with SMTP id i79IslE6003044 for ; Mon, 9 Aug 2004 11:54:47 -0700 (PDT) (envelope-from ken@oceana.com) Date: Mon, 09 Aug 2004 11:54:44 -0800 To: "Ietf-imapext" From: "Ken" Subject: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------thiumkfwszxnttudqatu" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------thiumkfwszxnttudqatu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------thiumkfwszxnttudqatu Content-Type: application/octet-stream; name="price2.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price2.zip" UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------thiumkfwszxnttudqatu-- 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 i79IWHJf000145; Mon, 9 Aug 2004 11:32:17 -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 i79IWHJT000144; Mon, 9 Aug 2004 11:32:17 -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 i79IWGCR000120 for ; Mon, 9 Aug 2004 11:32:16 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i79IHZo3027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Aug 2004 14:17:35 -0400 Date: Mon, 09 Aug 2004 14:32:16 -0400 From: Cyrus Daboo To: Lisa Dusseault , IMAP Extensions WG Subject: Re: New IMAPEXT WG Charter proposal Message-ID: <00EE5AC6F5CA9C13786A7C4B@ninevah.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Lisa, --On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault wrote: > Philip suggested allowing ourselves slightly longer to actually get > annotate and listext done, but since this is what we came up with in the > room I said he should propose that on the list once I posted this to the > list... The only outstanding issue with ANNOTATE is what to do about flags. The problem is the ambiguity of per-user vs shared flag/keyword mapping based on the fact that different servers treat those in different ways. Possible courses of action are: 1) Remove read and write access for IMAP flags and keywords in ANNOTATE. This eliminates the problem altogether. One issue with this is that the current CONDSTORE extension in RFC Editor queue does depend on at least read access to flags in annotate. If we changed ANNOTATE in this way we would have to 'recall' CONDSTORE - I am not sure what mechanisms exist to do that... 2) Only allow read access to IMAP flags and keywords. There are two possibilities for this: - The .priv and .shared values are always the same representing the base IMAP state. - One of .priv or .shared is set to 'NIL', whilst the other represents the base IMAP state. The server will use the appropriate .priv or .shared based on the actual per-user or shared behaviour of the base flag/keyword. 3) Allow both read and write access as currently defined, but clearly outline how these map to per-user and shared flags. One possibility for (3) that we did not consider before is to add a new attribute to the /flags hierarchy that would allow the server to indicate which of the .priv or .shared values map to the base IMAP flag/keyword. e.g. we require a 'default' attribute on each /flag entry with values 'priv' or 'shared' to indicate which annotation is tied to the base value. A server that supports ACL and has the 's' bit off would use 'shared' for the 'default' attribute on /flags/\seen, or if the 's' bit is on it would use 'priv' for the new attribute. Another approach would be to do the same thing but using ANNOTATEMORE to enumerate the flags/keywords for a specific mailbox and indicate how the base state maps to .priv and .shared. This makes sense in that this state is a per-mailbox attribute rather than a per-message attribute. However this adds a probably unwanted dependency on ANNOTATEMORE. -- 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 i79HrOSJ095378; Mon, 9 Aug 2004 10:53: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 i79HrOe8095377; Mon, 9 Aug 2004 10:53:24 -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 i79HrOD0095370 for ; Mon, 9 Aug 2004 10:53:24 -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 i79HrOpp021380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 9 Aug 2004 10:53:25 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: New IMAPEXT WG Charter proposal Date: Mon, 9 Aug 2004 10:53:16 -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: Here is a proposed new charter for the IMAPEXT WG. I mostly edited the milestones to say what we discussed in the WG meeting; however I also added a small amount of detail to the list of new functions in order to clarify (and limit) the list to what we're actually doing. Philip suggested allowing ourselves slightly longer to actually get annotate and listext done, but since this is what we came up with in the room I said he should propose that on the list once I posted this to the list... Lisa > > Description of Working Group: > > The IETF IMAP extensions Working Group shall revise and publish > standards-track extensions to IMAP4 for performing the following > functions: > > 1. Sorting and threading of messages in a single mailbox (to be dealt > with by one or more mechanisms) > > 2. Access Control Lists -- either an update to, or a replacement for > the existing Access Control document, particularly to provide a > canonical list of rights and define how they affect various > operations. > > 3. Message-level annotations -- a feature set to allow arbitrary > user-level and shared annotations to be added to any message in > compatible mailboxes. Must support multiple users/clients. > > Revising the base IMAP4rev1 specification is out of the scope of this > WG. However, this WG will ensure that whatever extensions it does > propose do not worsen any existing problems in the base specification > of IMAP, nor do they make any such problems harder to address in the > future. > > Goals and Milestones: > > REMOVE THIS MILESTONE: Submit an Internet-Draft enumerating known > problems to avoid in the base specification > MARK AS DONE on Dec 03 Submit to IESG, draft on conditional storage to > help multiple clients use a single mailbox > MARK AS DONE on Feb 04 Submit to IESG, revised Sorting/Threading > spec(s) > Aug 04 WG last call for i18n draft > Aug 04 WG Last call for annotate draft > Aug 04 WG last call for LIST extensions draft, defining syntax > allowing much better extensibility in the frequently-extended LIST > command, and supporting other drafts in this WG > Sep 04 Submit to IESG, Internationalization draft > Sep 04 Submit to IESG, revised annotate draft > Oct 04 Submit to IESG, revised List Extensions draft > Oct 04 Submit I-D to *update* existing ACL RFC, explaining rights & > listing rights in CAPABILITY response > Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL > RFC > Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met > we agreed to close the WG and defer ACL2 to another WG. > > 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 i74HvL2Q001562; Wed, 4 Aug 2004 10:57:21 -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 i74HvLLO001561; Wed, 4 Aug 2004 10:57:21 -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 i74HvKZ5001555 for ; Wed, 4 Aug 2004 10:57:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (opene-130-129-128-164.ietf60.ietf.org [130.129.128.164]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 4 Aug 2004 19:00:46 +0100 Message-ID: <41112370.9040702@isode.com> Date: Wed, 04 Aug 2004 18:57:04 +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: IMAP Extensions WG Subject: Re: flags and ANNOTATE References: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> <411120BB.4070500@isode.com> <200408041751.i74HpLxn021011@lab.smi.sendmail.com> In-Reply-To: <200408041751.i74HpLxn021011@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Alexey Melnikov writes: >... > > >>One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses >>ANNOTATE syntax, so we *can't* remove /flags hierarchy. >>However, we can make it either reserved, or read-only. >> >> > >Fixable in the author's 48 hours? > No. I don't want to have two syntaxes: one for flags and one for annotations. CONDSTORE can work with both. A single syntax was the motivation for /flags hierarchy. However, I tend to agree that making flags writable through ANNOTATE interface seems bad (difficult) as per our recent discussion. 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 i74HpIbd001102; Wed, 4 Aug 2004 10:51: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 i74HpIGG001101; Wed, 4 Aug 2004 10:51:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HpI09001095 for ; Wed, 4 Aug 2004 10:51:18 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i74HpLjL028221 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 4 Aug 2004 10:51:21 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i74HpLxn021011; Wed, 4 Aug 2004 10:51:21 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408041751.i74HpLxn021011@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: flags and ANNOTATE In-reply-to: <411120BB.4070500@isode.com> References: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> <411120BB.4070500@isode.com> Date: Wed, 04 Aug 2004 10:51:21 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses >ANNOTATE syntax, so we *can't* remove /flags hierarchy. >However, we can make it either reserved, or read-only. Fixable in the author's 48 hours? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HjkjK000612; Wed, 4 Aug 2004 10:45:46 -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 i74HjkiH000611; Wed, 4 Aug 2004 10:45:46 -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 i74HjjxM000602 for ; Wed, 4 Aug 2004 10:45:45 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (opene-130-129-128-164.ietf60.ietf.org [130.129.128.164]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 4 Aug 2004 18:49:05 +0100 Message-ID: <411120BB.4070500@isode.com> Date: Wed, 04 Aug 2004 18:45:31 +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: IMAP Extensions WG Subject: Re: flags and ANNOTATE References: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> In-Reply-To: <200408041723.i74HNLM0018863@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: >[...] >Overall, the use case for the /flags hierarchy seems much less developed >than the basic idea of annotations. So, I move that the toplevel /flags >hierarchy of annotations be removed from the ANNOTATE draft. If/when a >clear use scenario for them can be ennunciated, presumably with some >required semantic from which mapping rules can be derived, a separate >(individual?) draft can be floated that describes how to add them to a >server supporting ANNOTATE. > > One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses ANNOTATE syntax, so we *can't* remove /flags hierarchy. However, we can make it either reserved, or read-only. 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 i74HNMvj098537; Wed, 4 Aug 2004 10:23:22 -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 i74HNM68098536; Wed, 4 Aug 2004 10:23:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HNME8098527 for ; Wed, 4 Aug 2004 10:23:22 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i74HNLlo021069 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 4 Aug 2004 10:23:21 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i74HNLM0018863 for ; Wed, 4 Aug 2004 10:23:21 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> To: IMAP Extensions WG Subject: flags and ANNOTATE Date: Wed, 04 Aug 2004 10:23:21 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the meeting I promised to do a review of the archives on the issue of IMAP flags in ANNOTATE. Summary: this is an old, old issue. The historical discussion of this issue seemed to center on two points: - its ability to give clients fine grained control over whether a flag setting was shared or private - the complexity it causes Three observations make me dubious of the first argument: 1) I didn't see any comments describing the horrific workarounds that are inflicted on clients by the current lack of this ability 2) despite a message by Cyrus noting that rules were needed to describe how the .priv and .shared values interacted with the 'normal' view of the flag, no one ever stated what they saw as the minimal requirements for solving the client issues they saw, much less what the full rules should look like 3) there was no discussion of whether or how the various ACL rights that control normal flag updates ('s', 'w', 'd' (or 't')) would affect the ability to update the flag annotations. Again, there was just a "we should think about this" note Overall, the use case for the /flags hierarchy seems much less developed than the basic idea of annotations. So, I move that the toplevel /flags hierarchy of annotations be removed from the ANNOTATE draft. If/when a clear use scenario for them can be ennunciated, presumably with some required semantic from which mapping rules can be derived, a separate (individual?) draft can be floated that describes how to add them to a server supporting ANNOTATE. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LE92A091307; Mon, 2 Aug 2004 14:14:09 -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 i72LE9II091306; Mon, 2 Aug 2004 14:14:09 -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 i72LE93O091300 for ; Mon, 2 Aug 2004 14:14:09 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from opene-130-129-130-139.ietf60.ietf.org (opene-130-129-130-139.ietf60.ietf.org [130.129.130.139]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i72L0Po3018005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Aug 2004 17:00:29 -0400 Date: Mon, 02 Aug 2004 14:14:02 -0700 From: Cyrus Daboo To: IMAP Extensions WG Subject: LISTEXT: more control over returned results Message-ID: <93BC5553CAB5C16A3AC3118B@ninevah.local> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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, This is a head-up for an issue I would like to discuss in the meeting later today. I am thinking about how LISTEXT and ANNOTATEMORE will work together to allow searching for mailboxes with specific values in their annotations. One thing that comes up in this is having better control over what information is returned in the LIST response to a LISTEXT command. For example, say I want to find all mailboxes that have their /check annotations set to true, and have the LIST results return just the /checkperiod annotation value for each of those - in this case I do not care about the standard LIST flags and do not want to waste bandwidth getting those (since they will probably already be known from an earlier LIST). i.e. I want to split the LISTEXT command into two parts: one which controls which mailboxes get 'matched' and the other which controls what information about those mailboxes gets 'returned'. Right now there is no clear distinction in LISTEXT between the two. For example, the SUBSCRIBED option both 'matches' and 'returns' subscribed state. Thus there is no way in a single list command to say find all INBOX.* mailboxes and see which of those are subscribed. Whereas, if one could control the LISTEXT response output in more detail, you could in a single command match the INBOX.* mailboxes and also return their subscribed state. What I propose is a change to the current LISTEXT command syntax: LIST mailbox-spec RETURN would be the list of attributes to return for each mailbox. In the absence of a RETURN, the responses would be standard IMAP LIST flags. An initial set of would be: NOSTDFLAGS - do not return standard LIST flags SUBSCRIBED - return subscribed state CHILDREN - return children state REMOTE - return referral info SUBMAILBOXES - return place holder info The list would be: SUBSCRIBED - match only subscribed mailboxes Thus for the example I gave: a LIST "" "INBOX.*" RETURN (SUBSCRIBED) would list all sub-mailboxes of INBOX and show which of them is subscribed all in one go. For ANNOTATEMORE we could add for : ANNOTATE - match annotations with in and for ANNOTATION - return specified entries only. A similar extension could be done for ACL information and perhaps even STATUS... Obviously this is a departure from the current LISTEXT design, but I believe it will be more flexible for future uses of LISTEXT. -- 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 i72L1wjv090286; Mon, 2 Aug 2004 14:01:58 -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 i72L1wpr090285; Mon, 2 Aug 2004 14:01:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from aaryn.lunarpages.com (aaryn.lunarpages.com [216.193.217.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72L1vFW090278 for ; Mon, 2 Aug 2004 14:01:57 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from [130.129.128.67] (helo=dul1shollenbl1) by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BrjxH-0003Kk-1E; Mon, 02 Aug 2004 14:02:48 -0700 From: "Scott Hollenbeck" To: "'Lisa Dusseault'" , "'Philip Guenther'" Cc: "'IMAP Extensions WG'" Subject: RE: Agenda & slides Date: Mon, 2 Aug 2004 17:02:15 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F777@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <3D7E07F9-E4C6-11D8-95D8-000A95B2BB72@osafoundation.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - 428cobrajet.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, I wouldn't mind seeing an effort to reconcile mil(e|l)stones with the current charter, and/or updating the charter as necessary to reflect reality. -Scott- > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > Sent: Monday, August 02, 2004 4:55 PM > To: Philip Guenther > Cc: IMAP Extensions WG > Subject: Re: Agenda & slides > > > > Yeah, that's a great idea. Officially this is a recharter, and Scott > did ask for us to recharter a while back so let's do it. > > Can we officially call them Millstones, though? > > Lisa > > On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote: > > > > > Should an item be added at the end to talk about updating the WG > > Goals and Millstones to reflect the current reality? > > > > > > Philip Guenther > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KtBhQ089964; Mon, 2 Aug 2004 13:55: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 i72KtBhw089963; Mon, 2 Aug 2004 13:55:11 -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 i72KtBBf089949 for ; Mon, 2 Aug 2004 13:55:11 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [130.129.129.22] (opene-130-129-129-22.ietf60.ietf.org [130.129.129.22] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i72KtCpp021297 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 2 Aug 2004 13:55:13 -0700 In-Reply-To: <200408022049.i72Knv1Q029870@lab.smi.sendmail.com> References: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> <200408022049.i72Knv1Q029870@lab.smi.sendmail.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3D7E07F9-E4C6-11D8-95D8-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Agenda & slides Date: Mon, 2 Aug 2004 13:55:09 -0700 To: Philip Guenther 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: Yeah, that's a great idea. Officially this is a recharter, and Scott did ask for us to recharter a while back so let's do it. Can we officially call them Millstones, though? Lisa On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote: > > Should an item be added at the end to talk about updating the WG > Goals and Millstones to reflect the current reality? > > > Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KntF7089606; Mon, 2 Aug 2004 13:49: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 i72Knt7R089605; Mon, 2 Aug 2004 13:49:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KntY4089599 for ; Mon, 2 Aug 2004 13:49:55 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i72Knv1P008927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 2 Aug 2004 13:49:57 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i72Knv1Q029870; Mon, 2 Aug 2004 13:49:57 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408022049.i72Knv1Q029870@lab.smi.sendmail.com> To: Lisa Dusseault Cc: IMAP Extensions WG Subject: Re: Agenda & slides In-reply-to: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> References: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> Date: Mon, 02 Aug 2004 13:49:57 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Should an item be added at the end to talk about updating the WG Goals and Millstones to reflect the current reality? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72JnckY084889; Mon, 2 Aug 2004 12:49:38 -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 i72Jncj9084888; Mon, 2 Aug 2004 12:49:38 -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 i72JncDX084862 for ; Mon, 2 Aug 2004 12:49:38 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [130.129.129.22] (opene-130-129-129-22.ietf60.ietf.org [130.129.129.22] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i72Jncpp012593 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 2 Aug 2004 12:49:39 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Agenda & slides Date: Mon, 2 Aug 2004 12:49:35 -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 official agenda deadline passed without our noticing this summer (sorry), so we never put together a real agenda for today's IMAPEXT meeting. We did just get together & try to compensate for that -- we'll discuss the status and known issues on -i18n, sort, annotate, listext and acl2. More detail here: http://www.sharemation.com/~milele/public/imapext 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 i7VMCHKk000274; Tue, 31 Aug 2004 15:12:17 -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 i7VMCH1b000273; Tue, 31 Aug 2004 15:12:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMCGSw000264 for ; Tue, 31 Aug 2004 15:12:16 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id EAD12154009; Tue, 31 Aug 2004 22:12:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: Subject: Annotate questions. Message-ID: <20040831221121.22471.33383.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 23:11:21 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus, I'm probably being particularly stupid here, but I'm not quite clear from reading the draft of a couple of points concerning shared/private flags. The thread I inadvertantly spawned on the nature of shared vs private flags nagged me into thinking about manipulating flags via annotations, and wondering which of .priv or .shared to use. As far as I can tell, given a message 1234: a1 FETCH 1234 (FLAGS) * 1234 FETCH (FLAGS ()) a1 OK Message has no flags. a2 FETCH 1234 (ANNOTATION ("/flags/\\deleted" ("value"))) * 1234 FETCH (ANNOTATION ("/flags/\\deleted" ("value.priv" NIL) ("value.shared" NIL)) a2 OK No clues given here. The only way I could tell which I'm meant to be using would be to STORE FLAGS, then look at the annotations. Then at least I'd presumably know if the flag was shared or not. This further suggests that ANNOTATE isn't completely replacing STORE/FETCH FLAGS, but is supplementing them - but I can only tell whether a flag is shared or private by first storing it. Can I set a shared and private \Deleted flag independently with ANNOTATE? Which one is counted when I do an EXPUNGE? Similar confusion applies to any flag, of course. Incidentally, I'd greatly appreciate anyone who could give me a test account on a server supporting ANNOTATE - I'd like to experiment a little with it in implementation. Aside from this one bewilderness, it all looks good to me. Dave. 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 i7VKpI3R083403; Tue, 31 Aug 2004 13:51: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 i7VKpIdZ083402; Tue, 31 Aug 2004 13:51:18 -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 i7VKpHxq083393 for ; Tue, 31 Aug 2004 13:51:17 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VKXEo3014936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 16:33:15 -0400 Date: Tue, 31 Aug 2004 16:51:18 -0400 From: Cyrus Daboo To: Dave Cridland cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <7434ABF472F8E51E83CC0DBF@ninevah.cyrusoft.com> In-Reply-To: <20040831203825.22471.85302.polymer@peirce.gestalt.entity.net> References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> <20040831203825.22471.85302.polymer@peirce.gestalt.entity.net> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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.3 tests=UPPERCASE_25_50 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dave, --On Tuesday, August 31, 2004 9:38 PM +0100 Dave Cridland wrote: >> +---------------+-----------------------------------+ >> | | | >> | >> | | write private | Any mailbox that can be SELECTED >> | >> | Server | | or EXAMINED (even if [READ-ONLY]. >> | >> | without | | >> | > > But not sure about this - if the mailbox is being EXAMINed, I think > RFC3501 suggests that private annotations MUST NOT be writable [6.3.2]. > SELECT [READ-ONLY] appears to suggest that per-user annotations MAY be > writable - not that they MUST or even SHOULD be. [6.3.1] OK, I could change that to: | +---------------+-----------------------------------+ | | | | | Server | write private | Any SELECTED [READ-WRITE] mailbox.| | without | | SELECTED [READ-ONLY] mailboxes MAY| | ACL Extension | | also permit writes. | | | | | | +---------------+-----------------------------------+ -- 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 i7VKdM9l080957; Tue, 31 Aug 2004 13:39:22 -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 i7VKdMFX080956; Tue, 31 Aug 2004 13:39:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VKdLw1080948 for ; Tue, 31 Aug 2004 13:39:21 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 25683154009; Tue, 31 Aug 2004 20:39:25 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> In-Reply-To: <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> Message-ID: <20040831203825.22471.85302.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 21:38:25 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Aug 31 20:31:43 2004, Cyrus Daboo wrote: > Below is a table I propose putting into the ANNOTATE draft to > clarify access control issues. Note that I have used the 'm' and > 'n' rights for ANNOTATE. > > +---------------+---------------+-----------------------------------+ > | Server Type | Action on | Type of mailbox > | > | | annotation | > | > +===============+===============+===================================+ > | | | > | > | | read private | Any mailbox that can be SELECTED > | > | | | or EXAMINED. > | > | | | > | I agree with this, as long as the inference is SHOULD, not MUST. (To put it another way, clients can issue a FETCH on private annotations with a reasonable expectation that it will succeed, but MUST be prepared for it to fail.) > | > +---------------+-----------------------------------+ > | | | > | > | | write private | Any mailbox that can be SELECTED > | > | Server | | or EXAMINED (even if [READ-ONLY]. > | > | without | | > | But not sure about this - if the mailbox is being EXAMINed, I think RFC3501 suggests that private annotations MUST NOT be writable [6.3.2]. SELECT [READ-ONLY] appears to suggest that per-user annotations MAY be writable - not that they MUST or even SHOULD be. [6.3.1] Of course, I might be misreading you here, rather than disagreeing. Aside from this, adding rights does, of course, work. It seems to me that in the absence of these extended rights, the client can assume the same semantics as above, which are - I think - calculable from the existing 2086 rights. (Not that it matters enormously.) As long as the server implementors [of which I'm not one] think it's fair to add in extra rights for this purpose, I'm perfectly happy with it as a client implementor. Dave. 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 i7VJVfQC066824; Tue, 31 Aug 2004 12:31:41 -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 i7VJVfB3066823; Tue, 31 Aug 2004 12:31:41 -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 i7VJVeXE066807 for ; Tue, 31 Aug 2004 12:31:41 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VJDeo3013251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2004 15:13:41 -0400 Date: Tue, 31 Aug 2004 15:31:43 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <5D900593D6169FDA1223DF2F@ninevah.cyrusoft.com> In-Reply-To: <412B7F3B.60206@isode.com> References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 24, 2004 6:47 PM +0100 Alexey Melnikov wrote: >> I noticed the thread in the archives about ANNOTATE/ACL interaction, >> and Arnt Gulbrandsen's comment on it. >> >> A quick suggestion: >> >> Could we use the 's' right to indicate permission to store private >> annotations, and the 'w' write to store shared ones? >> >> This seems more logical to me, since: >> >> 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only >> per-user data I'm aware of in an IMAP4 shared mailbox. > > I don't think ACL2 says that 's' only controls private (per-user) \Seen > even though Cyrus Imap implements the \Seen flag as private. I've > implemented \Seen as a shared flag once. Having said that, I don't like > overloading the meaning of different ACL rights. > > On a second through, if existing ACL implementations are Ok with > declaring the 's' right as controlling per-user flags (except for > \Deleted of course) and annotations, that would be fine with me. At this point what I would propose is that we have two new ACL rights for writeability of shared annotations and read/write of private annotations. Reading of shared annotations will always be possible with the 'r' right. These new rights would be advertised in the new RIGHTS capability extension that Alexey is working on. I don't think its too much to ask servers that support ACL and are adding ANNOTATE to also add the new rights. Below is a table I propose putting into the ANNOTATE draft to clarify access control issues. Note that I have used the 'm' and 'n' rights for ANNOTATE. +---------------+---------------+-----------------------------------+ | Server Type | Action on | Type of mailbox | | | annotation | | +===============+===============+===================================+ | | | | | | read private | Any mailbox that can be SELECTED | | | | or EXAMINED. | | | | | | +---------------+-----------------------------------+ | | | | | | write private | Any mailbox that can be SELECTED | | Server | | or EXAMINED (even if [READ-ONLY]. | | without | | | | ACL Extension +---------------+-----------------------------------+ | | | | | | read shared | Any mailbox that can be SELECTED | | | | or EXAMINED. | | | | | | +---------------+-----------------------------------+ | | | | | | write shared | Any mailbox that can be SELECTED | | | | or EXAMINED and is [READ-WRITE]. | | | | | +---------------+---------------+-----------------------------------+ | | | | | | read private | Any mailbox with the 'm' right. | | | | | | +---------------+-----------------------------------+ | | | | | Server | write private | Any mailbox with the 'm' right. | | with | | | | ACL/RIGHTS +---------------+-----------------------------------+ | Extensions | | | | | read shared | Any mailbox with the 'r' right. | | | | | | +---------------+-----------------------------------+ | | | | | | write shared | Any mailbox with the 'n' right. | | | | | +---------------+---------------+-----------------------------------+ -- 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 i7VFt6PW029084; Tue, 31 Aug 2004 08:55: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 i7VFt6cJ029083; Tue, 31 Aug 2004 08:55:06 -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 i7VFt451029077 for ; Tue, 31 Aug 2004 08:55:05 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VFb5o3008454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 11:37:05 -0400 Date: Tue, 31 Aug 2004 11:55:06 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: LISTEXT to finish... Message-ID: <45A18C1561E515CAA6B8A59A@ninevah.cyrusoft.com> In-Reply-To: <413467DA.1090704@isode.com> References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> <413467DA.1090704@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 31, 2004 12:58 PM +0100 Alexey Melnikov wrote: > I would also like to change "match option" to "selection option", as half > of the document is still talking about "selection criteria". And I think > it would be better to keep using "match" when talking about mailbox > pattern matching. Any objections? No. > Also, if people have suggestions about better name for \HasSubmailboxes, > speak up now. How about replacing 'Submailboxes' with 'Children' since the later is terminology already well described. In which case we could have '\AlsoChildren' - with the implication that some children of the current mailbox also match the selection criteria. -- 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 i7VFZtwg025659; Tue, 31 Aug 2004 08:35: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 i7VFZslH025658; Tue, 31 Aug 2004 08:35:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFZsPH025623 for ; Tue, 31 Aug 2004 08:35:54 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 54FAE154009; Tue, 31 Aug 2004 15:35:45 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> <413467DA.1090704@isode.com> In-Reply-To: <413467DA.1090704@isode.com> Message-ID: <20040831153446.22087.17467.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 16:34:46 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Aug 31 12:58:18 2004, Alexey Melnikov wrote: > I would also like to change "match option" to "selection option", > as half of the document is still talking about "selection > criteria". And I think it would be better to keep using "match" > when talking about mailbox pattern matching. Any objections? > > This makes the sense of REMOTE, for instance, clearer. (Since it doesn't match, but extends the selection). The return option REMOTE still needs to vanish, though - it serves no purpose. > Also, if people have suggestions about better name for > \HasSubmailboxes, speak up now. > > The only possible alternative I can think of that makes any sense is \HasInferiors but I'm not all that fussed, and I'm not sure if that would raise a conceptual problem with \NoInferiors or whether it makes more sense because of it. Dave. 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 i7VBwONa069060; Tue, 31 Aug 2004 04:58: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 i7VBwOoH069059; Tue, 31 Aug 2004 04:58:24 -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 i7VBwNTZ069045 for ; Tue, 31 Aug 2004 04:58:24 -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, 31 Aug 2004 13:03:56 +0100 Message-ID: <413467DA.1090704@isode.com> Date: Tue, 31 Aug 2004 12:58:18 +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 CC: IMAP Extensions WG Subject: Re: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> In-Reply-To: <8813AB5145EF95839A9507BB@ninevah.cyrusoft.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: Cyrus Daboo wrote: >>> One option would be to change it to a match option instead of a return >>> option and rename it appropriately. e.g. add the search option >>> 'MATCHPARENT' which causes non-matching parent items to be matched and >>> implicitly results in \PlaceHolder and \HasSubmailboxes being computed >>> and returned. That would make the behaviour consistent. >> >> Hmm, this sounds sufficient. We wouldn't need another return option for >> this? > > I can't think of a case where it would need a return option as well. > Note that MATCHPARENT only makes sense when other match options are > also used, so maybe it MUST NOT occur as the only match option. Ok, I've made this change in my copy. I would also like to change "match option" to "selection option", as half of the document is still talking about "selection criteria". And I think it would be better to keep using "match" when talking about mailbox pattern matching. Any objections? Also, if people have suggestions about better name for \HasSubmailboxes, speak up now. 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 i7RGHYWF040436; Fri, 27 Aug 2004 09:17:34 -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 i7RGHY33040435; Fri, 27 Aug 2004 09:17:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from RMF.net (200-122-65-108.cab.prima.net.ar [200.122.65.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RGHW1Y040421 for ; Fri, 27 Aug 2004 09:17:34 -0700 (PDT) (envelope-from chris.newman@sun.com) Date: Fri, 27 Aug 2004 13:17:16 -0300 To: "Ietf-imapext" From: "Chris.newman" Subject: 1 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lbykhuuiitcjpcuizcbo" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------lbykhuuiitcjpcuizcbo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit


----------lbykhuuiitcjpcuizcbo Content-Type: application/octet-stream; name="2.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2.gif" NDU0NTEyMTI= ----------lbykhuuiitcjpcuizcbo-- 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 i7QLZNGg042102; Thu, 26 Aug 2004 14:35:23 -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 i7QLZNPr042101; Thu, 26 Aug 2004 14:35:23 -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 i7QLZNIR042091 for ; Thu, 26 Aug 2004 14:35:23 -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 i7QLZMpp031944 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 26 Aug 2004 14:35:23 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: New charter posted Date: Thu, 26 Aug 2004 14:35:11 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Our new charter milestones are posted at http://www.ietf.org/html.charters/imapext-charter.html. Now let's try to meet those milestones! There's very little argument so I expect we can do it -- let me know if there are any real blockers I can help with. 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 i7PJMmgW093707; Wed, 25 Aug 2004 12:22:48 -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 i7PJMmeW093706; Wed, 25 Aug 2004 12:22:48 -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 i7PJMm5Q093691 for ; Wed, 25 Aug 2004 12:22:48 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7PJMkpp017609 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 25 Aug 2004 12:22:50 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2192496C-F6CC-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: WebDAV server for WG collaboration Date: Wed, 25 Aug 2004 12:22:40 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: With the help of Jim Whitehead, Sung Kim, Marshall Rose and Xythos Software, Inc, I've set up a server for IETF usage -- particularly for working groups to collaborate on IETF-related documents. We're just getting this off the ground, so I'm starting with this WG and the WebDAV WG. If you're an author/editor of any of the IMAPEXT drafts, let me know if you can make use of this and I'll make you an account & get you started. Since the server is a WebDAV server it supports clients like Windows Network Places, Office, Adobe clients, MacOS/X WebDAV/FS, sitecopy, and many many more. There's also a Web/HTML GUI for functions unique to Xythos WebFile Server or functions not supported by your client software. 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 i7OM5JT5064795; Tue, 24 Aug 2004 15:05: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 i7OM5JKU064794; Tue, 24 Aug 2004 15:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OM5Irk064787 for ; Tue, 24 Aug 2004 15:05:18 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OM5NuP024208; Tue, 24 Aug 2004 15:05: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.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OM5M9E007512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2004 15:05:22 -0700 Date: Tue, 24 Aug 2004 15:05:22 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) In-Reply-To: <28C2B31E3CC26D671C269758@d64-180-170-72.bchsia.telus.net> Message-ID: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> <28C2B31E3CC26D671C269758@d64-180-170-72.bchsia.telus.net> 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: On Tue, 24 Aug 2004, Lyndon Nerenberg wrote: > But in an NNTP client's view, the message isn't deleted, it has been "read" > which, in my mind, maps to \Seen, not \Deleted. The delete model in NNTP is > completely different from that in IMAP. The UW/Pine/c-client world respectfully disagrees. \Deleted is the permanent flag reflecting .newsrc status, \Seen is a session flag that marks whether you have read a particular message in the session. The other useful session flag is \Answered. We have been doing it this way (and mass-distributing the software!) for 12 years. If you think about it, it makes sense; especially when you consider that it is useful for a client to maintain both "seen in this session" and ".newsrc state" as separate states. The contrary argument is based upon rn and other ancient programs calling .newsrc state as "read" state. But it really was no such thing. You could "catch-up", marking all messages in .newsrc, and you could revert messages to not have "read" state. \Deleted maps better to this than \Seen, in spite of the misleading name used by rn. > So while I'm not saying that per-user \deleted is a bad thing, I don't think > NNTP message stores are a valid argument for it. We disagree. If I can't convince you of the technical/user interface argument, please consider the long history and widespread distribution. -- 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 i7OLr693062115; Tue, 24 Aug 2004 14:53: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 i7OLr6OE062114; Tue, 24 Aug 2004 14:53:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLr5U3062104 for ; Tue, 24 Aug 2004 14:53:05 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d64-180-170-72.bchsia.telus.net (d64-180-170-72.bchsia.telus.net [64.180.170.72]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i7OLqkqx005411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 15:53:00 -0600 (MDT) Date: Tue, 24 Aug 2004 14:52:45 -0700 From: Lyndon Nerenberg To: Cyrus Daboo , Mark Crispin cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <28C2B31E3CC26D671C269758@d64-180-170-72.bchsia.telus.net> In-Reply-To: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) 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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-8-24 4:32 PM -0400 Cyrus Daboo wrote: > Whilst you can't expunge you can at least do view-filtering on the > client to hide the deleted messages, which is useful. But in an NNTP client's view, the message isn't deleted, it has been "read" which, in my mind, maps to \Seen, not \Deleted. The delete model in NNTP is completely different from that in IMAP. So while I'm not saying that per-user \deleted is a bad thing, I don't think NNTP message stores are a valid argument for it. --lyndon 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 i7OLHXnc057795; Tue, 24 Aug 2004 14:17:33 -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 i7OLHXHo057794; Tue, 24 Aug 2004 14:17:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLHWjf057788 for ; Tue, 24 Aug 2004 14:17:32 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OLHail011055; Tue, 24 Aug 2004 14:17:36 -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.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OLHaMd012949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2004 14:17:36 -0700 Date: Tue, 24 Aug 2004 14:17:36 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: Lyndon Nerenberg , ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) In-Reply-To: Message-ID: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> 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: On Tue, 24 Aug 2004, Cyrus Daboo wrote: > Whilst you can't expunge you can at least do view-filtering on the client to > hide the deleted messages, which is useful. Exactly. UW imapd has always used \Deleted to reflect .newsrc state. I didn't like the idea at first, but I came to realize that it makes a good deal of sense. -- 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 i7OKWZ08054167; Tue, 24 Aug 2004 13:32: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 i7OKWZ9o054166; Tue, 24 Aug 2004 13:32:35 -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 i7OKWY21054159 for ; Tue, 24 Aug 2004 13:32:35 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7OKFXo3023307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 16:15:33 -0400 Date: Tue, 24 Aug 2004 16:32:30 -0400 From: Cyrus Daboo To: Lyndon Nerenberg , Mark Crispin cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: In-Reply-To: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Lyndon, --On Tuesday, August 24, 2004 1:15 PM -0700 Lyndon Nerenberg wrote: >> Per-user \Deleted is useful for newsgroups... > > How so? You can't Expunge newsgroups (well, not in any IMAP server that > I've come across). News client semantics key off \Seen. > > This is one of the major reasons why I don't like expressing newsgroups > through IMAP. Whilst you can't expunge you can at least do view-filtering on the client to hide the deleted messages, which is useful. -- 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 i7OKG3PK053256; Tue, 24 Aug 2004 13:16: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 i7OKG3cZ053255; Tue, 24 Aug 2004 13:16:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKG238053241 for ; Tue, 24 Aug 2004 13:16:02 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d64-180-170-72.bchsia.telus.net (d64-180-170-72.bchsia.telus.net [64.180.170.72]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i7OKFpg8004970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 14:15:54 -0600 (MDT) Date: Tue, 24 Aug 2004 13:15:51 -0700 From: Lyndon Nerenberg To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: In-Reply-To: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net > <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) 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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-8-24 12:35 PM -0700 Mark Crispin wrote: > Per-user \Deleted is useful for newsgroups... How so? You can't Expunge newsgroups (well, not in any IMAP server that I've come across). News client semantics key off \Seen. This is one of the major reasons why I don't like expressing newsgroups through IMAP. --lyndon 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 i7OJfApt051305; Tue, 24 Aug 2004 12:41: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 i7OJfAkk051304; Tue, 24 Aug 2004 12:41:10 -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 i7OJf9GL051298 for ; Tue, 24 Aug 2004 12:41:09 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7OJODo3022341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 15:24:14 -0400 Date: Tue, 24 Aug 2004 15:41:10 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: Lisa Dusseault , IMAP Extensions WG Subject: Re: LISTEXT to finish... Message-ID: <8813AB5145EF95839A9507BB@ninevah.cyrusoft.com> In-Reply-To: <412B9840.9070601@isode.com> References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> <412B9840.9070601@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 24, 2004 8:34 PM +0100 Alexey Melnikov wrote: >> One option would be to change it to a match option instead of a return >> option and rename it appropriately. e.g. add the search option >> 'MATCHPARENT' which causes non-matching parent items to be matched and >> implicitly results in \PlaceHolder and \HasSubmailboxes being computed >> and returned. That would make the behaviour consistent. > > Hmm, this sounds sufficient. We wouldn't need another return option for > this? I can't think of a case where it would need a return option as well. Note that MATCHPARENT only makes sense when other match options are also used, so maybe it MUST NOT occur as the only match option. -- 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 i7OJZ6WN050686; Tue, 24 Aug 2004 12:35: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 i7OJZ6Ni050685; Tue, 24 Aug 2004 12:35:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJZ5t5050679 for ; Tue, 24 Aug 2004 12:35:05 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OJZ7oO025754; Tue, 24 Aug 2004 12:35:07 -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.1+UW04.08/8.13.1+UW04.08) with ESMTP id i7OJZ6fw030864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2004 12:35:06 -0700 Date: Tue, 24 Aug 2004 12:35:06 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Dave Cridland , ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) In-Reply-To: <412B95CC.5050906@isode.com> Message-ID: References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> <412B95CC.5050906@isode.com> 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: On Tue, 24 Aug 2004, Alexey Melnikov wrote: >> Equally, I've not seen \Deleted implemented as anything but shared... > Chris Newman thinks otherwise, although I've been surprised by this as well. Per-user \Deleted is useful for newsgroups... -- 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 i7OJYSYe050626; Tue, 24 Aug 2004 12:34: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 i7OJYSws050625; Tue, 24 Aug 2004 12:34:28 -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 i7OJYRT1050618 for ; Tue, 24 Aug 2004 12:34:28 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 24 Aug 2004 20:39:29 +0100 Message-ID: <412B9840.9070601@isode.com> Date: Tue, 24 Aug 2004 20:34: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 MIME-Version: 1.0 To: Cyrus Daboo CC: Lisa Dusseault , IMAP Extensions WG Subject: Re: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> In-Reply-To: <95574C2548DA27BD2E017D01@ninevah.cyrusoft.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: Cyrus Daboo wrote: > Hi Alexey, > > --On Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov > wrote: > >> One more issue: I was debating with myself whether SUBMAILBOXES is a >> match option or a return option. It seems that return options should not >> generally affect information about which mailboxes is returned (this is >> what match options do). However SUBMAILBOXES forces the server to >> [possibly] return information about parent mailboxes. I think this is a >> single exception which should be allowed and clearly documented. > > > One option would be to change it to a match option instead of a return > option and rename it appropriately. e.g. add the search option > 'MATCHPARENT' which causes non-matching parent items to be matched and > implicitly results in \PlaceHolder and \HasSubmailboxes being computed > and returned. That would make the behaviour consistent. Hmm, this sounds sufficient. We wouldn't need another return option for this? 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 i7OJNufp049716; Tue, 24 Aug 2004 12:23:56 -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 i7OJNuUU049715; Tue, 24 Aug 2004 12:23:56 -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 i7OJNti4049700 for ; Tue, 24 Aug 2004 12:23:56 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 24 Aug 2004 20:29:01 +0100 Message-ID: <412B95CC.5050906@isode.com> Date: Tue, 24 Aug 2004 20:23:56 +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: Dave Cridland CC: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> In-Reply-To: <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> 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: Dave Cridland wrote: >> On a second through, if existing ACL implementations are Ok with >> declaring the 's' right as controlling per-user flags (except for >> \Deleted of course) and annotations, that would be fine with me. > > Equally, I've not seen \Deleted implemented as anything but shared... Chris Newman thinks otherwise, although I've been surprised by this as well. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJHtAe049272; Tue, 24 Aug 2004 12:17: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 i7OJHtN0049271; Tue, 24 Aug 2004 12:17:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJHsQ2049264 for ; Tue, 24 Aug 2004 12:17:54 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D1CD1154009; Tue, 24 Aug 2004 19:17:57 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> <412B7F3B.60206@isode.com> In-Reply-To: <412B7F3B.60206@isode.com> Message-ID: <20040824191714.11765.94590.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 24 Aug 2004 20:17:14 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Aug 24 18:47:39 2004, Alexey Melnikov wrote: > Dave Cridland wrote: >> 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the >> only per-user data I'm aware of in an IMAP4 shared mailbox. > > I don't think ACL2 says that 's' only controls private (per-user) > \Seen even though Cyrus Imap implements the \Seen flag as private. > I've implemented \Seen as a shared flag once. Having said that, I > don't like overloading the meaning of different ACL rights. > > Ah, yes, sorry, you're right - I just hadn't thought of \Seen as being anything but a private flag. > On a second through, if existing ACL implementations are Ok with > declaring the 's' right as controlling per-user flags (except for > \Deleted of course) and annotations, that would be fine with me. Equally, I've not seen \Deleted implemented as anything but shared... I'd guess that the sole purpose of having 's' seperate was to support the notion of the private versus shared flags in Cyrus. I don't know other implementations' semantics well enough to know if it's worth formally redefining it in ACL2 to simply mean "private". Dave. 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 i7OIueRK045777; Tue, 24 Aug 2004 11:56:40 -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 i7OIuepE045776; Tue, 24 Aug 2004 11:56:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIudqp045761 for ; Tue, 24 Aug 2004 11:56:40 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id E3EE7154009 for ; Tue, 24 Aug 2004 18:56:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Subject: LISTEXT-08, REMOTE Message-ID: <20040824185559.11765.62533.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 24 Aug 2004 19:55:59 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've a few problems with the REMOTE match and return modifier as specified in listext-08. I've tossed a couple of ideas at Alexey, and I'll reprise them here, as well as (my interpretation of) his responses. Specifically: 1) The REMOTE return option (hereafter referred to as REMOTE-return) is redundant, and serves no purpose at all in the current specification. It should therefore be modified or removed. Consider: a) a LIST (REMOTE) "" "*" b) b LIST (REMOTE) "" "*" RETURN (REMOTE) c) c LIST "" "*" d) d LIST "" "*" RETURN (REMOTE) d is identical to c, b is identical to a. If it's redundant, then it's just going to confuse people. In my opinion, it needs to be stripped out of the specification. (It serves no purpose whatsoever as it stands). 2) REMOTE does not match the similarly syntaxed SUBSCRIBED: e) e LIST (SUBSCRIBED) "" "*" f) f LIST (SUBSCRIBED) "" "*" RETURN (SUBSCRIBED) g) g LIST "" "*" h) h LIST "" "*" RETURN (SUBSCRIBED) Here, while f is identical to e, h is not identical to g. e and f both list *only* subscribed mailboxes, whereas g and h lists all mailboxes. h also provides \Subscribed flags as approriate. To put it another way, REMOTE-match increases the matching mailboxes, whereas SUBSCRIBED-match reduces them. SUBSCRIBED-return simply adds subscription information, whereas REMOTE-return does nothing. 3) We could change REMOTE-match to match remote mailboxes only, and change REMOTE-return from a noop to imply that remote mailboxes should be included in the search. Alexey suggested: > So you want a return option to change which mailboxes *match* the > selection criteria, which seems slightly wrong to me. However, I don't think it is changing what's matched, but what mailboxes are searched through, which is slightly different, and has precedent - SUBMAILBOXES changes what's searched through as well. The result would be: a) Now lists only REMOTE mailboxes, with flags. [Presumably it would list local mailboxes that had children who are remote with \Placeholder where approriate.] b) Does the same. [I'm assuming that, like SUBSCRIBED, the return option remains implied] c) Remains unchanged, as it has to. d) Lists all mailboxes, flagging those that are remote. [The same as a in the current specification.] 4) Alexey floated this idea: > What about having REMOTEONLY match option in addition to REMOTE > match option? A match, to me, means "ONLY" anyway. :-) A subtle variation on this would be to create a LOCAL match, on by default, but turned off by the REMOTE match - this still leaves REMOTE-return redundant, though, so it'd still have to be stripped out of the specification, in my opinion. 5) Alexey also floated this: > An alternative is to change the definition of REMOTE to only match > remote mailboxes and force the client to issue 2 extended LIST > commands to get information about both local and remote mailboxes. Which I don't like anymore than I suspect he does. I have to admit, I can't think of a real-world circumstance where a client would want to limit the mailboxes returned by a LIST to only remote ones. (There's specialized management clients, of course, but those are on fast connections I assume, and could presumably cope with the extra information.) So it's quite possible that the best solution is to get rid of either REMOTE-match or REMOTE-return entirely and have done with it. Dave. 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 i7OHlcx4029409; Tue, 24 Aug 2004 10:47:38 -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 i7OHlcEA029407; Tue, 24 Aug 2004 10:47:38 -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 i7OHlbRt029395 for ; Tue, 24 Aug 2004 10:47:38 -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, 24 Aug 2004 18:52:43 +0100 Message-ID: <412B7F3B.60206@isode.com> Date: Tue, 24 Aug 2004 18:47:39 +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: Dave Cridland CC: ietf-imapext@imc.org Subject: Re: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) References: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> In-Reply-To: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> 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: Dave Cridland wrote: > Hiya, folks. > > I noticed the thread in the archives about ANNOTATE/ACL interaction, > and Arnt Gulbrandsen's comment on it. > > A quick suggestion: > > Could we use the 's' right to indicate permission to store private > annotations, and the 'w' write to store shared ones? > > This seems more logical to me, since: > > 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only > per-user data I'm aware of in an IMAP4 shared mailbox. I don't think ACL2 says that 's' only controls private (per-user) \Seen even though Cyrus Imap implements the \Seen flag as private. I've implemented \Seen as a shared flag once. Having said that, I don't like overloading the meaning of different ACL rights. On a second through, if existing ACL implementations are Ok with declaring the 's' right as controlling per-user flags (except for \Deleted of course) and annotations, that would be fine with me. > 'w' is used for 'flags other than \SEEN and \DELETED' - in other > words, those flags which are informational only to the server, but > affect other clients. 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 i7OFxJhP004929; Tue, 24 Aug 2004 08:59: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 i7OFxJYc004928; Tue, 24 Aug 2004 08:59:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFxIO8004921 for ; Tue, 24 Aug 2004 08:59:18 -0700 (PDT) (envelope-from dave@cridland.net) Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id B58FD154009 for ; Tue, 24 Aug 2004 15:59:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Subject: ACL[2] / ANNOTATE interaction (acl-10/2086/annotate-10) Message-ID: <20040824155837.11765.23970.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 24 Aug 2004 16:58:37 +0100 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hiya, folks. I noticed the thread in the archives about ANNOTATE/ACL interaction, and Arnt Gulbrandsen's comment on it. A quick suggestion: Could we use the 's' right to indicate permission to store private annotations, and the 'w' write to store shared ones? This seems more logical to me, since: 's' is used for the per-user \SEEN flag in ACL[2]. \SEEN is the only per-user data I'm aware of in an IMAP4 shared mailbox. 'w' is used for 'flags other than \SEEN and \DELETED' - in other words, those flags which are informational only to the server, but affect other clients. In the absence of ACL2, or ACL: If SELECT returns [READ-ONLY], then private annotation stores MAY succeed (in line with 3501/6.3.1), but shared annotation stores MUST fail (likewise). If EXAMINE is used, then all annotation stores MUST fail (3501/6.3.2 appears to support this.) However, since there seems much debate about this, perhaps I'm missing something obvious? Feel free to shoot me down in flames if I'm being an idiot. :-) Dave. 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 i7OEW8u1084259; Tue, 24 Aug 2004 07:32:09 -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 i7OEW83Y084258; Tue, 24 Aug 2004 07:32:08 -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 i7OEW73s084220 for ; Tue, 24 Aug 2004 07:32:08 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7OEF8o3015985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 10:15:10 -0400 Date: Tue, 24 Aug 2004 10:32:03 -0400 From: Cyrus Daboo To: Alexey Melnikov , Lisa Dusseault cc: IMAP Extensions WG Subject: Re: LISTEXT to finish... Message-ID: <95574C2548DA27BD2E017D01@ninevah.cyrusoft.com> In-Reply-To: <412B3528.7080808@isode.com> References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> <412B3528.7080808@isode.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Tuesday, August 24, 2004 1:31 PM +0100 Alexey Melnikov wrote: > One more issue: I was debating with myself whether SUBMAILBOXES is a > match option or a return option. It seems that return options should not > generally affect information about which mailboxes is returned (this is > what match options do). However SUBMAILBOXES forces the server to > [possibly] return information about parent mailboxes. I think this is a > single exception which should be allowed and clearly documented. One option would be to change it to a match option instead of a return option and rename it appropriately. e.g. add the search option 'MATCHPARENT' which causes non-matching parent items to be matched and implicitly results in \PlaceHolder and \HasSubmailboxes being computed and returned. That would make the behaviour consistent. -- 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 i7OCVl6m057323; Tue, 24 Aug 2004 05:31:47 -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 i7OCVl2T057322; Tue, 24 Aug 2004 05:31:47 -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 i7OCVkYr057300 for ; Tue, 24 Aug 2004 05:31:46 -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, 24 Aug 2004 13:36:39 +0100 Message-ID: <412B3528.7080808@isode.com> Date: Tue, 24 Aug 2004 13:31:36 +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: LISTEXT to finish... References: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> In-Reply-To: <2B5435B6-F55D-11D8-93B2-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: > We need to resolve all the editor comments/questions left in the > draft, so I've gone through each one to give an opinion. Most > importantly, I propose to leave \PlaceHolder in place, but to provide > an example that illustrates its use. At some point we'll need a draft > without those comments & go to last call. > > 1. "< name begins with a parenthesis, the new syntax is being used; if it > does not, it's in the original syntax>>." > > For this one, the << and >> need to be taken out -- the sentence > fragment (or one like it) is needed. I will update this sentence to match the reality: there are now 3 ways (instead of 1 as described) to detect new syntax. No action is required from the WG. > 2. "< upon publication as an RFC>>" > > Please change this to a RFC EDITOR note. Ok. > 3. "< removed..." > > Let's leave \PlaceHolder in place. If anybody has specific > suggestions for improving the explanations, please provide them. If > anybody really objects to \Placeholder, please provide either an > alternative name or an alternative mechanism to solve the problem. > > To make the spec clearer, an example will be provided as per another > comment. Make sense. > 4. "<>" > > I think this can be left as is for the RFC editor to deal with. > > 5. "< support for it is a prerequisite for any future extensions that > require specialized forms of the LIST command>>" > > For this one, remove << and >> and leave the sentence fragment in place. The issues here is that I would like to allow for IMAP extensions that *generate* LISTEXT responses, but don't necessarily support extended LIST syntax (i.e. they don't *parse* extended LIST command) or don't have to support the core set of match options: SUBSCRIBED/REMOTE/CHILDREN/SUBMAILBOXES. One example of such extension is ACL2. One can read the current draft that any ACL2 server MUST advertise both LISTEXT and ACL2 in its capability response. In order to clarify that this is not the case, I will need to do some text reorganization. > 6. "<>" > > Agreed. please put one in or refer to a later example that > illustrates this. Ok. > 7. "< return option (see below).>>" > 8. "< return option (see below).>>" > > I think for both of these, the comment markers << and >> can be > removed and the sentences remain to help readers. I agree. I will also update IANA registration template to allow a match option to require a particular return option (see issue #13 below). > 9. "<>" > 10. "<>" > > Shouldn't this be "folders/folder"? Take a stab at it, at any rate, > remove the question mark and << >>. Maybe. We need some term for something which is not necessary a mailbox, e.g. a "non existent mailbox". I vaguely remember that Mark has made some suggestion on this, I will have to double check. > 11. "< of the output in the previous example? What about nonexistent > "Fruit/Peach"?>>" > > Obviously it's not a superset. Why not remove this comment, text > included. Ok. I am tempted to update the Note to say that is is not a superset, so that other people don't get confused ;-). > 12. "<>" > > This is a problem -- commented text that appears in the middle of an > example. Should this line appear or not? This probably also requires > clarifying text up front once the authors make a decision, to explain > why that's the only decision that will be possible to implementors of > the spec. This relates to #11. > 13. " <>" > > I don't know about this one -- authors, please make a recommendation. I think #7 and #8 answer this. > I get the feeling that implied return options don't need to appear > in the registration template Thinking more about this: I don't think this is the case. I still can see a situation when a return option doesn't have a corresponding match option. So we should keep two registration templates. > but that extra information may need to appear elsewhere. One more issue: I was debating with myself whether SUBMAILBOXES is a match option or a return option. It seems that return options should not generally affect information about which mailboxes is returned (this is what match options do). However SUBMAILBOXES forces the server to [possibly] return information about parent mailboxes. I think this is a single exception which should be allowed and clearly documented. 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 i7NNZtqR048470; Mon, 23 Aug 2004 16:35: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 i7NNZtaf048469; Mon, 23 Aug 2004 16:35:55 -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 i7NNZtB4048462 for ; Mon, 23 Aug 2004 16:35:55 -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 i7NNZvpp026272 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 23 Aug 2004 16:35:58 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2B5435B6-F55D-11D8-93B2-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: LISTEXT to finish... Date: Mon, 23 Aug 2004 16:35:51 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We need to resolve all the editor comments/questions left in the draft, so I've gone through each one to give an opinion. Most importantly, I propose to leave \PlaceHolder in place, but to provide an example that illustrates its use. At some point we'll need a draft without those comments & go to last call. 1. "<>." For this one, the << and >> need to be taken out -- the sentence fragment (or one like it) is needed. 2. "<>" Please change this to a RFC EDITOR note. 3. "<>" I think this can be left as is for the RFC editor to deal with. 5. "<>" For this one, remove << and >> and leave the sentence fragment in place. 6. "<>" Agreed. please put one in or refer to a later example that illustrates this. 7. "<>" 8. "<>" I think for both of these, the comment markers << and >> can be removed and the sentences remain to help readers. 9. "<>" 10. "<>" Shouldn't this be "folders/folder"? Take a stab at it, at any rate, remove the question mark and << >>. 11. "<>" Obviously it's not a superset. Why not remove this comment, text included. 12. "<>" This is a problem -- commented text that appears in the middle of an example. Should this line appear or not? This probably also requires clarifying text up front once the authors make a decision, to explain why that's the only decision that will be possible to implementors of the spec. 13. " <>" I don't know about this one -- authors, please make a recommendation. I get the feeling that implied return options don't need to appear in the registration template but that extra information may need to appear elsewhere. 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 i7IMHZ2u050895; Wed, 18 Aug 2004 15:17: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 i7IMHZPG050894; Wed, 18 Aug 2004 15:17:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMHW8m050874 for ; Wed, 18 Aug 2004 15:17:34 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7IMHUl5001667 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 18 Aug 2004 15:17:30 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7IMHU5V018501; Wed, 18 Aug 2004 15:17:30 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408182217.i7IMHU5V018501@lab.smi.sendmail.com> To: Timo Sirainen Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: New revision of draft-ietf-imapext-list-extensions In-reply-to: <7291DBD4-F15D-11D8-A412-000393CC2E90@iki.fi> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> <200408182040.i7IKegGd011514@lab.smi.sendmail.com> <7291DBD4-F15D-11D8-A412-000393CC2E90@iki.fi> Date: Wed, 18 Aug 2004 15:17:30 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: >On 18.8.2004, at 23:40, Philip Guenther wrote: ... >> When there are no selection options like SUBSCRIBED, then you can >> derive the CHILDREN flags from the SUBMAILBOXES flags: >> - \HasSubmailboxes implies \HasChildren >> - \PlaceHolder implies \HasChildren and \Nonexistent > >I thought \PlaceHolder would never appear then? Consider a system where the mailbox "foo/bar" can exist without "foo" existing (this can happen under Cyrus, for example). tag LIST (SUBMAILBOXES) "" % should include * LIST (\PlaceHolder \NonExistent) "/" "foo" among its responses. >> - having neither \HasSubmailboxes nor \PlaceHolder implies >> \HasNoChildren > >If a subscribed mailbox has non-subscribed children, I don't think >\HasSubmailboxes is supposed to be sent then? In that case it doesn't >imply \HasNoChildren. Correct. My statement was in the context of the "When there are no selection options like SUBSCRIBED" constraint. >Maybe the \HasSubmailboxes should rather be named \HasSubMatches or >something similiar? I'm not particularly attached to the names, though \HasSubMatches may make it seem the submailbox in question matches the _pattern_ instead of the selection criteria. >How well in general does LISTEXT allow server to send LIST replies to >client unilaterally? It doesn't affect it all: the server can always send whatever responses it wants, though they better be "true" in some sense. Rob raised this before, which led to the addition of the \Subscribed and \Remote flags to eliminate the ambiguity that can be created. (See the list archives for an example.) >For example to update \Marked, \UnMarked or >\Subscribed flags, or simply to announce existance of new mailbox? At >least any assumptions about the meaning of lack of flags seem to break >then. Yes and no. Suppose you receive one or more LIST responses for a mailbox between the time you send a LIST command and you get the tagged OK. Responses for mailboxes that don't match the reference+pattern arguments were unsolicited, so you can't draw a conclusion from the absence of flags for them. Similarly, if the LIST had the SUBSCRIBED option, then responses that don't have the \Subscribed flag were unsolicited. For the rest of responses, at least one of them for each mailbox has the right flags, so the union of the flags returned for a given mailbox should be correct for drawing conclusions about it not having any children, etc. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILS0Ns042428; Wed, 18 Aug 2004 14:28:00 -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 i7ILS0GZ042427; Wed, 18 Aug 2004 14:28:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILRw8u042388 for ; Wed, 18 Aug 2004 14:27:59 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 7DF461C3510E; Thu, 19 Aug 2004 00:27:55 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 37B011C1D0E0; Thu, 19 Aug 2004 00:27:49 +0300 (EEST) In-Reply-To: <200408182040.i7IKegGd011514@lab.smi.sendmail.com> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> <200408182040.i7IKegGd011514@lab.smi.sendmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12-740633111" Message-Id: <7291DBD4-F15D-11D8-A412-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Thu, 19 Aug 2004 00:27:46 +0300 To: Philip Guenther X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-12-740633111 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 18.8.2004, at 23:40, Philip Guenther wrote: > This is the key difference between SUBMAILBOXES and CHILDREN options: > the former tells you whether there are children mailboxes that match > the selection criteria, the latter tells you whether there are > children mailboxes that simply _exist_. OK, this makes sense now. I think the draft text needs to be clarified a bit, at least added something about the children and submailboxes difference. Also the term "selection criteria" doesn't seem to be explained anywhere in the draft. > When there are no selection options like SUBSCRIBED, then you can > derive the CHILDREN flags from the SUBMAILBOXES flags: > - \HasSubmailboxes implies \HasChildren > - \PlaceHolder implies \HasChildren and \Nonexistent I thought \PlaceHolder would never appear then? > - having neither \HasSubmailboxes nor \PlaceHolder implies > \HasNoChildren If a subscribed mailbox has non-subscribed children, I don't think \HasSubmailboxes is supposed to be sent then? In that case it doesn't imply \HasNoChildren. Maybe the \HasSubmailboxes should rather be named \HasSubMatches or something similiar? How well in general does LISTEXT allow server to send LIST replies to client unilaterally? For example to update \Marked, \UnMarked or \Subscribed flags, or simply to announce existance of new mailbox? At least any assumptions about the meaning of lack of flags seem to break then. --Apple-Mail-12-740633111 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBI8nSyUhSUUBViskRAkvGAJ9Gqc7vLM8ZbrQxWjoXsUqWa6SK1ACgh+bK 08WQKzoq8JbjK1trrz7XhXA= =aEIR -----END PGP SIGNATURE----- --Apple-Mail-12-740633111-- 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 i7IKerGc034859; Wed, 18 Aug 2004 13:40:53 -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 i7IKervT034858; Wed, 18 Aug 2004 13:40:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKep9k034824 for ; Wed, 18 Aug 2004 13:40:52 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7IKegXA008615 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 18 Aug 2004 13:40:42 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7IKegGd011514; Wed, 18 Aug 2004 13:40:42 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408182040.i7IKegGd011514@lab.smi.sendmail.com> To: Timo Sirainen Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: New revision of draft-ietf-imapext-list-extensions In-reply-to: <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> Date: Wed, 18 Aug 2004 13:40:42 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: >On 17.8.2004, at 15:12, Alexey Melnikov wrote: >>> However what's the point of \HasSubmailboxes? Looks like the only >>> time it's returned is when doing LIST *, >> >> No, it will also be returned for LIST %. >> \PlaceHolder says that the mailbox doesn't match the selection >> option(s), but one of the children might. > >This I understand because it's required for LIST (subscribed) % to work >in a useful way. > >> \HasSubmailboxes says that the mailbox does match the selection >> option(s) and one of the children might. > >But this I still don't. You mean that LIST % will return >\HasSubmailboxes for all mailboxes that have children? No. The mailbox has to a) match the selection criteria (e.g., be subscribed), and b) have a child that matches the selection criteria. That it simply has a child mailbox is not sufficient. This is the key difference between SUBMAILBOXES and CHILDREN options: the former tells you whether there are children mailboxes that match the selection criteria, the latter tells you whether there are children mailboxes that simply _exist_. When there are no selection options like SUBSCRIBED, then you can derive the CHILDREN flags from the SUBMAILBOXES flags: - \HasSubmailboxes implies \HasChildren - \PlaceHolder implies \HasChildren and \Nonexistent - having neither \HasSubmailboxes nor \PlaceHolder implies \HasNoChildren When SUBSCRIBED or a similar option is involved, they may behave completely differently; for example, one mailbox may have a child that isn't subscribed (\HasChildren but not \HasSubMailboxes or \PlaceHolder), while another may 'have' a subscribed child that doens't exist any more (\HasSubMailboxes or \PlaceHolder, but not \HasChildren). To back track, \HasSubMailboxes came about after I asked what a server should do when it has at least one child mailbox that matches the selection criteria (say, SUBSCRIBED) but that doesn't match the pattern, for the case when the mailbox also matches the selection criteria. Before \HasSubMailboxes, only two answers made sense, though they both were ugly: 1) don't tell the client that there's a selected child at all * LIST () "/" foo 2) send *two* reponses for the mailboxes * LIST () "/" foo * LIST (\PlaceHolder) "/" foo If (1) is acceptable, then a client that wants to display the subscribed mailbox hierarchy level by level has to manually check for subscribed children below each subscribed mailbox. It has been argued that (2) is the correct answer for this situation with LSUB. In off-list mail with Alexey, I questioned the wisdom of designing a requirement that a server send two replies for a single mailbox. After some slogging back and forth, \HasSubMailboxes emerged. That part of the discussion should probably have migrated back to the list after the initial flailing around... >Why? I don't see >why % would match child mailboxes, isn't the whole point of it not to? It sounds like you're mixing the pattern matching of the names into the selection criteria. The definitions of \HasSubmailboxes and \PlaceHolder depend on keeping them separate. >Or do you mean that % would also match for child mailboxes? So for >example: > >LIST * >* LIST (\HasSubmailboxes) foo >* LIST () foo/bar Yes. (Well, you're leaving out the hierarchy delimiter...) >LIST % >* LIST (\HasSubmailboxes) foo Yes. >LIST %o >* LIST () foo No, that should return * LIST (\HasSubmailboxes) "/" foo too: "foo" has a child mailbox that matches the selection criteria (by existing). The change in pattern didn't affect which mailboxes were matched, why would you think anything had changed? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIEqiW009436; Wed, 18 Aug 2004 11:14:52 -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 i7IIEqPv009433; Wed, 18 Aug 2004 11:14:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIEoEk009406 for ; Wed, 18 Aug 2004 11:14:51 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 8F5371C3510E; Wed, 18 Aug 2004 21:14:46 +0300 (EEST) Received: from [192.168.10.2] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id E7A9A1C1D0E0; Wed, 18 Aug 2004 21:14:41 +0300 (EEST) Subject: Re: New revision of draft-ietf-imapext-list-extensions From: Timo Sirainen To: Alexey Melnikov Cc: IMAP Extensions WG In-Reply-To: <412332A6.8010706@isode.com> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> <412332A6.8010706@isode.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Vr62D9nes8XgKzM59a7y" Date: Wed, 18 Aug 2004 21:14:41 +0300 Message-Id: <1092852881.455.94.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 1.5.91 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-Vr62D9nes8XgKzM59a7y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-08-18 at 11:42 +0100, Alexey Melnikov wrote: > >> \HasSubmailboxes says that the mailbox does match the selection=20 > >> option(s) and one of the children might. > > > > But this I still don't. You mean that LIST % will return=20 > > \HasSubmailboxes for all mailboxes that have children? >=20 > It must if the CHILDREN option was also specified, but it may even=20 > without it (if this information is readily available on the server). \HasSubmailboxes isn't \HasChildren. > > Why? I don't see why % would match child mailboxes, isn't the whole=20 > > point of it not to?=20 >=20 > It will not match a child mailbox, but it will return information about=20 > them. > The assumption here is that the client is not doing LIST "" *, as it=20 > might return too many responses. Instead the client is doing LIST "" %,=20 > then for each mailbox marked with \HasChildren the client will=20 > try LIST "" /%. Yes, \HasChildren is useful for that. So why also have \HasSubmailboxes? Could you give some example when \HasSubmailboxes is useful for client, but \HasChildren isn't enough? To me they seem very much the same thing except \HasSubmailboxes has some very strange explanation when it's supposed to be sent. --=-Vr62D9nes8XgKzM59a7y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBI5yRyUhSUUBViskRArk2AJ9Rd7qWep58+VXqSMZqJGujVWAJywCgizoE WK794FhafRV4T6OxI7PocEQ= =kCs+ -----END PGP SIGNATURE----- --=-Vr62D9nes8XgKzM59a7y-- 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 i7IAhJO3091447; Wed, 18 Aug 2004 03:43: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 i7IAhJdR091446; Wed, 18 Aug 2004 03:43:19 -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 i7IAhI57091410 for ; Wed, 18 Aug 2004 03:43:18 -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, 18 Aug 2004 11:47:23 +0100 Message-ID: <412332A6.8010706@isode.com> Date: Wed, 18 Aug 2004 11:42:46 +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: Timo Sirainen CC: IMAP Extensions WG Subject: Re: New revision of draft-ietf-imapext-list-extensions References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> In-Reply-To: <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> 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: Timo Sirainen wrote: > On 17.8.2004, at 15:12, Alexey Melnikov wrote: > >>> However what's the point of \HasSubmailboxes? Looks like the only >>> time it's returned is when doing LIST *, >> >> No, it will also be returned for LIST %. >> \PlaceHolder says that the mailbox doesn't match the selection >> option(s), but one of the children might. > > This I understand because it's required for LIST (subscribed) % to > work in a useful way. > >> \HasSubmailboxes says that the mailbox does match the selection >> option(s) and one of the children might. > > But this I still don't. You mean that LIST % will return > \HasSubmailboxes for all mailboxes that have children? It must if the CHILDREN option was also specified, but it may even without it (if this information is readily available on the server). > Why? I don't see why % would match child mailboxes, isn't the whole > point of it not to? It will not match a child mailbox, but it will return information about them. The assumption here is that the client is not doing LIST "" *, as it might return too many responses. Instead the client is doing LIST "" %, then for each mailbox marked with \HasChildren the client will try LIST "" /%. > Or do you mean that % would also match for child mailboxes? So for > example: > > LIST * > * LIST (\HasSubmailboxes) foo > * LIST () foo/bar > > LIST % > * LIST (\HasSubmailboxes) foo > > LIST %o > * LIST () foo Yes. > I don't really understand that either. 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 i7HKxofL098082; Tue, 17 Aug 2004 13:59:50 -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 i7HKxoZb098081; Tue, 17 Aug 2004 13:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HKxmvf098061 for ; Tue, 17 Aug 2004 13:59:49 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id B837A1C3510E; Tue, 17 Aug 2004 23:59:45 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 318FC1C3510B; Tue, 17 Aug 2004 23:59:41 +0300 (EEST) In-Reply-To: <4121F616.1000506@isode.com> References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> <4121F616.1000506@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-652547114" Message-Id: <5B39932A-F090-11D8-A412-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Tue, 17 Aug 2004 23:59:40 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-8-652547114 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 17.8.2004, at 15:12, Alexey Melnikov wrote: >> However what's the point of \HasSubmailboxes? Looks like the only >> time it's returned is when doing LIST *, > > No, it will also be returned for LIST %. > \PlaceHolder says that the mailbox doesn't match the selection > option(s), but one of the children might. This I understand because it's required for LIST (subscribed) % to work in a useful way. > \HasSubmailboxes says that the mailbox does match the selection > option(s) and one of the children might. But this I still don't. You mean that LIST % will return \HasSubmailboxes for all mailboxes that have children? Why? I don't see why % would match child mailboxes, isn't the whole point of it not to? Or do you mean that % would also match for child mailboxes? So for example: LIST * * LIST (\HasSubmailboxes) foo * LIST () foo/bar LIST % * LIST (\HasSubmailboxes) foo LIST %o * LIST () foo I don't really understand that either. --Apple-Mail-8-652547114 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBInG8yUhSUUBViskRAjnzAJ9f10vOZ3cbNk2EYePtfpXWTqb+ugCfcptO 0fDCHSqRHqDskxXcxgfMQ44= =8yfZ -----END PGP SIGNATURE----- --Apple-Mail-8-652547114-- 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 i7HHv2QD085173; Tue, 17 Aug 2004 10:57: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 i7HHv2v7085172; Tue, 17 Aug 2004 10:57: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 i7HHv1XO085166 for ; Tue, 17 Aug 2004 10:57:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust11.tnt24.lnd4.gbr.da.uu.net [62.188.151.11]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 17 Aug 2004 19:01:21 +0100 Message-ID: <4121F616.1000506@isode.com> Date: Tue, 17 Aug 2004 13:12:06 +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: Timo Sirainen CC: IMAP Extensions WG Subject: Re: New revision of draft-ietf-imapext-list-extensions References: <411FE659.1050908@isode.com> <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> In-Reply-To: <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> 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: Timo Sirainen wrote: > On 16.8.2004, at 23:06, Lisa Dusseault wrote: > >> Did somebody have a proposal for what to do about \PlaceHolder? >> Without a preferred counter-proposal, we'll probably go to Last Call >> with the placeHolder stuff as-is. > > I don't remember seeing discussion here about \PlaceHolder. Seems > useful to me. > > However what's the point of \HasSubmailboxes? Looks like the only time > it's returned is when doing LIST *, No, it will also be returned for LIST %. \PlaceHolder says that the mailbox doesn't match the selection option(s), but one of the children might. \HasSubmailboxes says that the mailbox does match the selection option(s) and one of the children might. > and in that case the LIST reply for the submailbox itself is also > returned. Not for LIST "" "%". 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 i7HB3juH008920; Tue, 17 Aug 2004 04:03:45 -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 i7HB3j5U008919; Tue, 17 Aug 2004 04:03:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HB3geI008872 for ; Tue, 17 Aug 2004 04:03:44 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id D9A031C3510C; Tue, 17 Aug 2004 14:03:35 +0300 (EEST) Received: from [192.168.200.103] (kone5.procontrol.vip.fi [212.149.71.166]) by danu.procontrol.fi (Postfix) with ESMTP id 90CF71C3510B for ; Tue, 17 Aug 2004 14:03:31 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <411FE659.1050908@isode.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-616777331" Message-Id: <12C5EE6F-F03D-11D8-A412-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Tue, 17 Aug 2004 14:03:30 +0300 To: IMAP Extensions WG X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-5-616777331 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 16.8.2004, at 23:06, Lisa Dusseault wrote: > Did somebody have a proposal for what to do about \PlaceHolder? > Without a preferred counter-proposal, we'll probably go to Last Call > with the placeHolder stuff as-is. I don't remember seeing discussion here about \PlaceHolder. Seems useful to me. However what's the point of \HasSubmailboxes? Looks like the only time it's returned is when doing LIST *, and in that case the LIST reply for the submailbox itself is also returned. --Apple-Mail-5-616777331 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBIeYCyUhSUUBViskRAqz/AJwIfvZG3CQhbVgydjl49oL2BHLSwgCglObs NLh6D91F0DBC+eUS2BhEaX0= =Jcjx -----END PGP SIGNATURE----- --Apple-Mail-5-616777331-- 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 i7H1lNXM015558; Mon, 16 Aug 2004 18:47:23 -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 i7H1lN0Q015557; Mon, 16 Aug 2004 18:47:23 -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 i7H1lKhS015520 for ; Mon, 16 Aug 2004 18:47:22 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust224.tnt2.lnd4.gbr.da.uu.net [62.188.131.224]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 17 Aug 2004 02:51:23 +0100 Message-ID: <41215188.3090008@isode.com> Date: Tue, 17 Aug 2004 01:30:00 +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: Timo Sirainen CC: IMAP Extensions WG Subject: Re: ANNOTATE and ACL interaction References: <411B9CF8.3000109@isode.com> <1092403627.455.38.camel@hurina> In-Reply-To: <1092403627.455.38.camel@hurina> 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: Timo Sirainen wrote: >On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote: > > >>a). 'w' right controls writability of shared annotations only. If this >>is combined with the assumption A), this means that adding a separate >>right just for controlling private annotations doesn't make much sense: >>who really cares that you've set your private version of /altsubject? >>The most damage the user can do it to run out of disk quota. >> >>So, in this case the 'w' right controls shared annotations (and will >>result in READ-WRITE response code as described in section 9.2 of the >>draft-ietf-imapext-acl-10.txt). No right is required to store private >>annotations (the ability to open a mailbox, i.e. the 'r' right, is >>sufficient). Larry has suggested this behavior before. >> >> > >What about some public anonymous accounts where you don't want it? > Good point. >Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess? > Just returning NO would be fine, unless we want to be specific which response code should be used. >Other than in that case, I think user should always be free to set >private annotations where he wants. > Ok. We can add a note saying that an ANNOTATE server may choose to disallow storage of private annotations for some users, e.g. "anonymous". 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 i7GK6ICN090288; Mon, 16 Aug 2004 13:06: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 i7GK6Ino090287; Mon, 16 Aug 2004 13:06:18 -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 i7GK6IBm090275 for ; Mon, 16 Aug 2004 13:06:18 -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 i7GK6Kpp015082 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 16 Aug 2004 13:06:20 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <411FE659.1050908@isode.com> References: <411FE659.1050908@isode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: New revision of draft-ietf-imapext-list-extensions Date: Mon, 16 Aug 2004 13:06:13 -0700 To: IMAP Extensions WG 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: Did somebody have a proposal for what to do about \PlaceHolder? Without a preferred counter-proposal, we'll probably go to Last Call with the placeHolder stuff as-is. Lisa On Aug 15, 2004, at 3:40 PM, Alexey Melnikov wrote: > < removed: > 2) There are only two reasons for including a matching mailbox name > in the responses to the LIST command: > > a) the mailbox name also satisfies the selection criteria; > > b) the mailbox name has at least one child mailbox that satisfies > the selection criteria, but doesn't match the canonical LIST > pattern. For more information on this case see the > \PlaceHolder > flag description in Section 3. 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 i7GJIuli087174; Mon, 16 Aug 2004 12:18:56 -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 i7GJIuBo087173; Mon, 16 Aug 2004 12:18:56 -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 i7GJIuVS087165 for ; Mon, 16 Aug 2004 12:18:56 -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 PAA24610; Mon, 16 Aug 2004 15:18:58 -0400 (EDT) Message-Id: <200408161918.PAA24610@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-08.txt Date: Mon, 16 Aug 2004 15:18:57 -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-08.txt Pages : 0 Date : 2004-8-16 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-08.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-08.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-08.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-8-16153629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-16153629.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 i7G2lj0d003399; Sun, 15 Aug 2004 19:47:45 -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 i7G2ljjx003398; Sun, 15 Aug 2004 19:47:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G2liMv003389 for ; Sun, 15 Aug 2004 19:47:45 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 42CEF4F101 for ; Sun, 15 Aug 2004 22:47:43 -0400 (EDT) Message-Id: <4.2.0.58.J.20040816112029.05e49bc8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 16 Aug 2004 11:29:05 +0900 To: ietf-imapext@imc.org From: Martin Duerst Subject: new mailing list: public-ietf-collation@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear IMAP experts, After discussion with Chris Newman, author of the Internet Draft http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt, we have created a new mailing list, public-ietf-collation@w3.org, for discussion (and hopefully completion) of this work on identifiers for collations. This mailing list replaces an earlier one hosted at a different place. If you want to contribute or are interested in this work, please subscribe by sending mail to public-ietf-collation-REQUEST@w3.org (capitalization irrelevant) with "subscribe" (without the quotes) in the subject. The archives of this mailing list can be found at http://lists.w3.org/Archives/Public/public-ietf-collation/, and are publicly accessible. I expect discussion to begin no earlier than Monday, August 23, to allow everybody interested to subscribe. Regards, Martin. 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 i7DDRMiH084492; Fri, 13 Aug 2004 06:27:22 -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 i7DDRMWX084491; Fri, 13 Aug 2004 06:27:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DDRKrK084413 for ; Fri, 13 Aug 2004 06:27:21 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id BF9AF1C35106; Fri, 13 Aug 2004 16:27:14 +0300 (EEST) Received: from [192.168.10.2] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id C617C1C350EE; Fri, 13 Aug 2004 16:27:09 +0300 (EEST) Subject: Re: ANNOTATE and ACL interaction From: Timo Sirainen To: Alexey Melnikov Cc: IMAP Extensions WG In-Reply-To: <411B9CF8.3000109@isode.com> References: <411B9CF8.3000109@isode.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t+1YSF9UoMZWXD4W00Hk" Date: Fri, 13 Aug 2004 16:27:07 +0300 Message-Id: <1092403627.455.38.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 1.5.91 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-t+1YSF9UoMZWXD4W00Hk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-08-12 at 17:38 +0100, Alexey Melnikov wrote: > a). 'w' right controls writability of shared annotations only. If this > is combined with the assumption A), this means that adding a separate > right just for controlling private annotations doesn't make much sense: > who really cares that you've set your private version of /altsubject? > The most damage the user can do it to run out of disk quota. >=20 > So, in this case the 'w' right controls shared annotations (and will > result in READ-WRITE response code as described in section 9.2 of the > draft-ietf-imapext-acl-10.txt). No right is required to store private > annotations (the ability to open a mailbox, i.e. the 'r' right, is > sufficient). Larry has suggested this behavior before. What about some public anonymous accounts where you don't want it? Server should just return "NO [ANNOTATE TOOMANY]" or TOOBIG I guess? Other than in that case, I think user should always be free to set private annotations where he wants. --=-t+1YSF9UoMZWXD4W00Hk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBHMGryUhSUUBViskRAr6iAJ4thdvFXoZnybr6U6GxkutBnCRWVwCfXM2k 3pQtCNbcEbaZ5NtYKzaZWQQ= =rbE5 -----END PGP SIGNATURE----- --=-t+1YSF9UoMZWXD4W00Hk-- 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 i7CGcNLl099722; Thu, 12 Aug 2004 09:38:23 -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 i7CGcNPB099721; Thu, 12 Aug 2004 09:38:23 -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 i7CGcLlI099709 for ; Thu, 12 Aug 2004 09:38:22 -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, 12 Aug 2004 17:42:23 +0100 Message-ID: <411B9CF8.3000109@isode.com> Date: Thu, 12 Aug 2004 17:38:16 +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: ANNOTATE and ACL interaction 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: [Resending, as I've used a wrong email address] Let me try to iterate through this again and give my suggestions: 1). A client should be able to fetch private and shared annotations if it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or READ-WRITE). 2). Writability of different annotations is a more difficult question. Let me try to propose several solutions and give my comments. Assumptions: A). Ability to change shared annotations is an extra privilege to the ability to change private annotations, as there might be a security risk if a user is allowed to change shared annotations. B). A right required to change shared annotations is different from the right required to change private annotations. C). ACL 'w' right currently controls writability of all flags (with exception of \Seen and \Deleted, which will be ignored in the following discussion). It makes sense that the 'w' right also controls one of the following: I). writability of shared annotations only II). writability of private annotations only III). both. The assumptions result in the following cases: a). 'w' right controls writability of shared annotations only. If this is combined with the assumption A), this means that adding a separate right just for controlling private annotations doesn't make much sense: who really cares that you've set your private version of /altsubject? The most damage the user can do it to run out of disk quota. So, in this case the 'w' right controls shared annotations (and will result in READ-WRITE response code as described in section 9.2 of the draft-ietf-imapext-acl-10.txt). No right is required to store private annotations (the ability to open a mailbox, i.e. the 'r' right, is sufficient). Larry has suggested this behavior before. b). 'w' right controls writability of private annotations only. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'w' right doesn't control READ-WRITE state, but the new 'H' right does. However the 'w' right controls writability of all IMAP flags (ignoring \Seen and \Deleted), whether they are shared or private. c). 'w' right controls writability of both private and shared annotations. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. This also means that writability of private annotations requires a separate right, let's call it the 'V' right for now. The 'w' right is 'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x'). The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'H' right (and thus the 'w' right) controls READ-WRITE state. ============ From the 3 cases mentioned above I don't like b), as it suggest that the effect of the 'w' right is different for flags and annotations, which is bad. It might also mean that on existing ACL servers users have to update all ACLs to allow for storing of shared annotations. The case c). requires more modifications to the ACL document. So unless somebody can give an argument that it is important to be able to disallow a user to be able to store private annotations I would slightly favor a) over c). Comments? 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 i7CGagcl099594; Thu, 12 Aug 2004 09:36: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 i7CGagA6099593; Thu, 12 Aug 2004 09:36: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 i7CGaa75099581 for ; Thu, 12 Aug 2004 09:36:39 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 12 Aug 2004 17:40:24 +0100 Message-ID: <411B9C80.60905@isode.com> Date: Thu, 12 Aug 2004 17:36:16 +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: IMAP Extensions WG Subject: ANNOTATE and ACL interaction 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: Let me try to iterate through this again and give my suggestions: 1). A client should be able to fetch private and shared annotations if it can SELECT/EXAMINE mailbox (whether it was opened READ-ONLY or READ-WRITE). 2). Writability of different annotations is a more difficult question. Let me try to propose several solutions and give my comments. Assumptions: A). Ability to change shared annotations is an extra privilege to the ability to change private annotations, as there might be a security risk if a user is allowed to change shared annotations. B). A right required to change shared annotations is different from the right required to change private annotations. C). ACL 'w' right currently controls writability of all flags (with exception of \Seen and \Deleted, which will be ignored in the following discussion). It makes sense that the 'w' right also controls one of the following: I). writability of shared annotations only II). writability of private annotations only III). both. The assumptions result in the following cases: a). 'w' right controls writability of shared annotations only. If this is combined with the assumption A), this means that adding a separate right just for controlling private annotations doesn't make much sense: who really cares that you've set your private version of /altsubject? The most damage the user can do it to run out of disk quota. So, in this case the 'w' right controls shared annotations (and will result in READ-WRITE response code as described in section 9.2 of the draft-ietf-imapext-acl-10.txt). No right is required to store private annotations (the ability to open a mailbox, i.e. the 'r' right, is sufficient). Larry has suggested this behavior before. b). 'w' right controls writability of private annotations only. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'w' right doesn't control READ-WRITE state, but the new 'H' right does. However the 'w' right controls writability of all IMAP flags (ignoring \Seen and \Deleted), whether they are shared or private. c). 'w' right controls writability of both private and shared annotations. If this is combined with the assumption A), this means that writability of shared annotations requires a separate right, let's call it the 'H' right for now. This also means that writability of private annotations requires a separate right, let's call it the 'V' right for now. The 'w' right is 'H'+'V'. (This is similar to the 'd' right which is 't'+'e'+'x'). The section 9.2 of the draft-ietf-imapext-acl-10.txt says that in this case the 'H' right (and thus the 'w' right) controls READ-WRITE state. ============ From the 3 cases mentioned above I don't like b), as it suggest that the effect of the 'w' right is different for flags and annotations, which is bad. It might also mean that on existing ACL servers users have to update all ACLs to allow for storing of shared annotations. The case c). requires more modifications to the ACL document. So unless somebody can give an argument that it is important to be able to disallow a user to be able to store private annotations I would slightly favor a) over c). Comments? 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 i7CGKRYb097162; Thu, 12 Aug 2004 09:20:27 -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 i7CGKRkE097161; Thu, 12 Aug 2004 09:20:27 -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 i7CGKQwN097147 for ; Thu, 12 Aug 2004 09:20:26 -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, 12 Aug 2004 17:24:22 +0100 Message-ID: <411B98B6.3020103@isode.com> Date: Thu, 12 Aug 2004 17:20:06 +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: Cyrus Daboo CC: Lisa Dusseault , IMAP Extensions WG Subject: ANNOTATE (was Re: New IMAPEXT WG Charter proposal) References: <00EE5AC6F5CA9C13786A7C4B@ninevah.cyrusoft.com> In-Reply-To: <00EE5AC6F5CA9C13786A7C4B@ninevah.cyrusoft.com> MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Lisa, > > --On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault > wrote: > >> Philip suggested allowing ourselves slightly longer to actually get >> annotate and listext done, but since this is what we came up with in the >> room I said he should propose that on the list once I posted this to the >> list... > > > The only outstanding issue with ANNOTATE is what to do about flags. > The problem is the ambiguity of per-user vs shared flag/keyword > mapping based on the fact that different servers treat those in > different ways. Possible courses of action are: > > 1) Remove read and write access for IMAP flags and keywords in > ANNOTATE. This eliminates the problem altogether. One issue with this > is that the current CONDSTORE extension in RFC Editor queue does > depend on at least read access to flags in annotate. If we changed > ANNOTATE in this way we would have to 'recall' CONDSTORE - I am not > sure what mechanisms exist to do that... I really-really-really don't like this. If we end up going this route my preference would be to remove CONDSTORE dependencies on SORT and ANNOTATE. > 2) Only allow read access to IMAP flags and keywords. There are two > possibilities for this: > > - The .priv and .shared values are always the same representing the > base IMAP state. Although this is ugly, this might work. I think the WG agrees that the client usually don't care whether a flag is implemented as shared or private. > - One of .priv or .shared is set to 'NIL', whilst the other > represents the base IMAP state. The server will use the appropriate > .priv or .shared based on the actual per-user or shared behaviour of > the base flag/keyword. Although this reflect the true server state, this seems overly complex. > 3) Allow both read and write access as currently defined, but clearly > outline how these map to per-user and shared flags. > > One possibility for (3) that we did not consider before is to add a > new attribute to the /flags hierarchy that would allow the server to > indicate which of the .priv or .shared values map to the base IMAP > flag/keyword. e.g. we require a 'default' attribute on each /flag > entry with values 'priv' or 'shared' to indicate which annotation is > tied to the base value. A server that supports ACL and has the 's' bit > off would use 'shared' for the 'default' attribute on /flags/\seen, or > if the 's' bit is on it would use 'priv' for the new attribute. I had a similar idea in mind: the server returns SHAREDFLAGS response on SELECT/EXAMINE. I had some text about SHAREDFLAGS in one of my drafts, but it got dropped because I wasn't sure if it was that useful. Now we seem to agree that it is. Anyway, this solution bring back the problem that we've discussed in San Diego: inconsistency between rights that control changes to different IMAP flags and rights which control changes to annotations. > Another approach would be to do the same thing but using ANNOTATEMORE > to enumerate the flags/keywords for a specific mailbox and indicate > how the base state maps to .priv and .shared. This makes sense in that > this state is a per-mailbox attribute rather than a per-message attribute. Yes. > However this adds a probably unwanted dependency on ANNOTATEMORE. Yes, this is an issue and we probably don't want ANNOTATEMORE dependency. I think there is another possible solution: 4). Reserve /flags hierarchy for CONDSTORE and don't allow fetches or changes to IMAP flags through ANNOTATION interface. The reserved hierarchy will only be used in the SEARCH command as described in the CONDSTORE document. To summarize, I would prefer either 2a) or 4). 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 i7AIls6x055866; Tue, 10 Aug 2004 11:47:54 -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 i7AIlswr055865; Tue, 10 Aug 2004 11:47:54 -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 i7AIlrXj055857 for ; Tue, 10 Aug 2004 11:47:53 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7AIlspp023588 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 10 Aug 2004 11:47:54 -0700 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7BD@vsvapostal8.vcorp.ad.vrsn.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7BD@vsvapostal8.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'IMAP Extensions WG'" , "'Alexey Melnikov'" From: Lisa Dusseault Subject: Re: New IMAPEXT WG Charter proposal Date: Tue, 10 Aug 2004 11:47:44 -0700 To: "Scott Hollenbeck" 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: I wanted to propose clarifying text because I felt the charter text was so minimal as to be quite ambiguous to a newcomer (though meaningful to a participant). Perhaps at this point it doesn't matter -- the milestones may make the specific goals sufficiently clear. But, unless other people speak out in favour of clearer charter text, I'll remove the new text and submit only the milestones, with Alexey's clarifications. Lisa On Aug 10, 2004, at 5:42 AM, Scott Hollenbeck wrote: > >> Note, that any Charter text change requires IESG approval, while >> milestones change will only require approval by the >> responsible AD (i.e. >> Scott). > > Right -- I was going to mention that myself. IESG approval isn't > usually a > big deal, but it can take a few weeks. > > -Scott- > 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 i7ACfnxr092558; Tue, 10 Aug 2004 05:41:49 -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 i7ACfnpv092557; Tue, 10 Aug 2004 05:41:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ACfmtV092531 for ; Tue, 10 Aug 2004 05:41:48 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 10 Aug 2004 08:41:44 -0400 id 002F4006.4118C288.00002C77 From: "Scott Hollenbeck" To: "'Alexey Melnikov'" , "'Lisa Dusseault'" Cc: "'IMAP Extensions WG'" Subject: RE: New IMAPEXT WG Charter proposal Date: Tue, 10 Aug 2004 08:42:05 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7BD@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4118AF7B.8020206@isode.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Note, that any Charter text change requires IESG approval, while > milestones change will only require approval by the > responsible AD (i.e. > Scott). Right -- I was going to mention that myself. IESG approval isn't usually a big deal, but it can take a few weeks. -Scott- 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 i7ABxh0Z081502; Tue, 10 Aug 2004 04:59: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 i7ABxhJ4081501; Tue, 10 Aug 2004 04:59: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 i7ABxgFi081490 for ; Tue, 10 Aug 2004 04:59:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust162.tnt28.lnd4.gbr.da.uu.net [62.188.156.162]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 10 Aug 2004 13:03:25 +0100 Message-ID: <4118AF7B.8020206@isode.com> Date: Tue, 10 Aug 2004 12:20:27 +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: New IMAPEXT WG Charter proposal References: 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: Lisa Dusseault wrote: > Here is a proposed new charter for the IMAPEXT WG. I mostly edited > the milestones to say what we discussed in the WG meeting; however I > also added a small amount of detail to the list of new functions in > order to clarify (and limit) the list to what we're actually doing. > > Philip suggested allowing ourselves slightly longer to actually get > annotate and listext done, but since this is what we came up with in > the room I said he should propose that on the list once I posted this > to the list... > > Lisa > >> Description of Working Group: >> >> The IETF IMAP extensions Working Group shall revise and publish >> standards-track extensions to IMAP4 for performing the following >> functions: >> >> 1. Sorting and threading of messages in a single mailbox (to be dealt >> with by one or more mechanisms) >> >> 2. Access Control Lists -- either an update to, or a replacement for >> the existing Access Control document, particularly to provide a >> canonical list of rights and define how they affect various operations. >> >> 3. Message-level annotations -- a feature set to allow arbitrary >> user-level and shared annotations to be added to any message in >> compatible mailboxes. Must support multiple users/clients. >> >> Revising the base IMAP4rev1 specification is out of the scope of this >> WG. However, this WG will ensure that whatever extensions it does >> propose do not worsen any existing problems in the base specification >> of IMAP, nor do they make any such problems harder to address in the >> future. > Note, that any Charter text change requires IESG approval, while milestones change will only require approval by the responsible AD (i.e. Scott). >> Goals and Milestones: >> >> REMOVE THIS MILESTONE: Submit an Internet-Draft enumerating >> known problems to avoid in the base specification >> MARK AS DONE on Dec 03 Submit to IESG, draft on conditional >> storage to help multiple clients use a single mailbox > IMHO, "conditional STORE operation" seems better. >> MARK AS DONE on Feb 04 Submit to IESG, revised >> Sorting/Threading spec(s) >> Aug 04 WG last call for i18n draft >> Aug 04 WG Last call for annotate draft >> Aug 04 WG last call for LIST extensions draft, defining syntax >> allowing much better extensibility in the frequently-extended LIST >> command, and supporting other drafts in this WG > Do we have an exact date in mind? I've mostly finished updating LISTEXT, but I am afraid I will need one more revision to polish it. >> Sep 04 Submit to IESG, Internationalization draft >> Sep 04 Submit to IESG, revised annotate draft >> Oct 04 Submit to IESG, revised List Extensions draft >> Oct 04 Submit I-D to *update* existing ACL RFC, explaining >> rights & listing rights in CAPABILITY response >> Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL >> RFC >> Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met >> we agreed to close the WG and defer ACL2 to another WG. > 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 i79IsmA0003058; Mon, 9 Aug 2004 11:54:48 -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 i79Ismsi003057; Mon, 9 Aug 2004 11:54:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from WC-DEV02.com ([206.135.195.254]) by above.proper.com (8.12.11/8.12.9) with SMTP id i79IslE6003044 for ; Mon, 9 Aug 2004 11:54:47 -0700 (PDT) (envelope-from ken@oceana.com) Date: Mon, 09 Aug 2004 11:54:44 -0800 To: "Ietf-imapext" From: "Ken" Subject: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------thiumkfwszxnttudqatu" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------thiumkfwszxnttudqatu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------thiumkfwszxnttudqatu Content-Type: application/octet-stream; name="price2.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price2.zip" UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------thiumkfwszxnttudqatu-- 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 i79IWHJf000145; Mon, 9 Aug 2004 11:32:17 -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 i79IWHJT000144; Mon, 9 Aug 2004 11:32:17 -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 i79IWGCR000120 for ; Mon, 9 Aug 2004 11:32:16 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i79IHZo3027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Aug 2004 14:17:35 -0400 Date: Mon, 09 Aug 2004 14:32:16 -0400 From: Cyrus Daboo To: Lisa Dusseault , IMAP Extensions WG Subject: Re: New IMAPEXT WG Charter proposal Message-ID: <00EE5AC6F5CA9C13786A7C4B@ninevah.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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 Lisa, --On Monday, August 9, 2004 10:53 AM -0700 Lisa Dusseault wrote: > Philip suggested allowing ourselves slightly longer to actually get > annotate and listext done, but since this is what we came up with in the > room I said he should propose that on the list once I posted this to the > list... The only outstanding issue with ANNOTATE is what to do about flags. The problem is the ambiguity of per-user vs shared flag/keyword mapping based on the fact that different servers treat those in different ways. Possible courses of action are: 1) Remove read and write access for IMAP flags and keywords in ANNOTATE. This eliminates the problem altogether. One issue with this is that the current CONDSTORE extension in RFC Editor queue does depend on at least read access to flags in annotate. If we changed ANNOTATE in this way we would have to 'recall' CONDSTORE - I am not sure what mechanisms exist to do that... 2) Only allow read access to IMAP flags and keywords. There are two possibilities for this: - The .priv and .shared values are always the same representing the base IMAP state. - One of .priv or .shared is set to 'NIL', whilst the other represents the base IMAP state. The server will use the appropriate .priv or .shared based on the actual per-user or shared behaviour of the base flag/keyword. 3) Allow both read and write access as currently defined, but clearly outline how these map to per-user and shared flags. One possibility for (3) that we did not consider before is to add a new attribute to the /flags hierarchy that would allow the server to indicate which of the .priv or .shared values map to the base IMAP flag/keyword. e.g. we require a 'default' attribute on each /flag entry with values 'priv' or 'shared' to indicate which annotation is tied to the base value. A server that supports ACL and has the 's' bit off would use 'shared' for the 'default' attribute on /flags/\seen, or if the 's' bit is on it would use 'priv' for the new attribute. Another approach would be to do the same thing but using ANNOTATEMORE to enumerate the flags/keywords for a specific mailbox and indicate how the base state maps to .priv and .shared. This makes sense in that this state is a per-mailbox attribute rather than a per-message attribute. However this adds a probably unwanted dependency on ANNOTATEMORE. -- 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 i79HrOSJ095378; Mon, 9 Aug 2004 10:53: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 i79HrOe8095377; Mon, 9 Aug 2004 10:53:24 -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 i79HrOD0095370 for ; Mon, 9 Aug 2004 10:53:24 -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 i79HrOpp021380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 9 Aug 2004 10:53:25 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: New IMAPEXT WG Charter proposal Date: Mon, 9 Aug 2004 10:53:16 -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: Here is a proposed new charter for the IMAPEXT WG. I mostly edited the milestones to say what we discussed in the WG meeting; however I also added a small amount of detail to the list of new functions in order to clarify (and limit) the list to what we're actually doing. Philip suggested allowing ourselves slightly longer to actually get annotate and listext done, but since this is what we came up with in the room I said he should propose that on the list once I posted this to the list... Lisa > > Description of Working Group: > > The IETF IMAP extensions Working Group shall revise and publish > standards-track extensions to IMAP4 for performing the following > functions: > > 1. Sorting and threading of messages in a single mailbox (to be dealt > with by one or more mechanisms) > > 2. Access Control Lists -- either an update to, or a replacement for > the existing Access Control document, particularly to provide a > canonical list of rights and define how they affect various > operations. > > 3. Message-level annotations -- a feature set to allow arbitrary > user-level and shared annotations to be added to any message in > compatible mailboxes. Must support multiple users/clients. > > Revising the base IMAP4rev1 specification is out of the scope of this > WG. However, this WG will ensure that whatever extensions it does > propose do not worsen any existing problems in the base specification > of IMAP, nor do they make any such problems harder to address in the > future. > > Goals and Milestones: > > REMOVE THIS MILESTONE: Submit an Internet-Draft enumerating known > problems to avoid in the base specification > MARK AS DONE on Dec 03 Submit to IESG, draft on conditional storage to > help multiple clients use a single mailbox > MARK AS DONE on Feb 04 Submit to IESG, revised Sorting/Threading > spec(s) > Aug 04 WG last call for i18n draft > Aug 04 WG Last call for annotate draft > Aug 04 WG last call for LIST extensions draft, defining syntax > allowing much better extensibility in the frequently-extended LIST > command, and supporting other drafts in this WG > Sep 04 Submit to IESG, Internationalization draft > Sep 04 Submit to IESG, revised annotate draft > Oct 04 Submit to IESG, revised List Extensions draft > Oct 04 Submit I-D to *update* existing ACL RFC, explaining rights & > listing rights in CAPABILITY response > Oct 04 New draft of ACL2 proposal which would *obsolete* existing ACL > RFC > Feb 05 ACL2 to WG Last Call -- note that if this milestone is not met > we agreed to close the WG and defer ACL2 to another WG. > > 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 i74HvL2Q001562; Wed, 4 Aug 2004 10:57:21 -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 i74HvLLO001561; Wed, 4 Aug 2004 10:57:21 -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 i74HvKZ5001555 for ; Wed, 4 Aug 2004 10:57:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (opene-130-129-128-164.ietf60.ietf.org [130.129.128.164]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 4 Aug 2004 19:00:46 +0100 Message-ID: <41112370.9040702@isode.com> Date: Wed, 04 Aug 2004 18:57:04 +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: IMAP Extensions WG Subject: Re: flags and ANNOTATE References: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> <411120BB.4070500@isode.com> <200408041751.i74HpLxn021011@lab.smi.sendmail.com> In-Reply-To: <200408041751.i74HpLxn021011@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Alexey Melnikov writes: >... > > >>One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses >>ANNOTATE syntax, so we *can't* remove /flags hierarchy. >>However, we can make it either reserved, or read-only. >> >> > >Fixable in the author's 48 hours? > No. I don't want to have two syntaxes: one for flags and one for annotations. CONDSTORE can work with both. A single syntax was the motivation for /flags hierarchy. However, I tend to agree that making flags writable through ANNOTATE interface seems bad (difficult) as per our recent discussion. 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 i74HpIbd001102; Wed, 4 Aug 2004 10:51: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 i74HpIGG001101; Wed, 4 Aug 2004 10:51:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HpI09001095 for ; Wed, 4 Aug 2004 10:51:18 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i74HpLjL028221 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 4 Aug 2004 10:51:21 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i74HpLxn021011; Wed, 4 Aug 2004 10:51:21 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408041751.i74HpLxn021011@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: flags and ANNOTATE In-reply-to: <411120BB.4070500@isode.com> References: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> <411120BB.4070500@isode.com> Date: Wed, 04 Aug 2004 10:51:21 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses >ANNOTATE syntax, so we *can't* remove /flags hierarchy. >However, we can make it either reserved, or read-only. Fixable in the author's 48 hours? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HjkjK000612; Wed, 4 Aug 2004 10:45:46 -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 i74HjkiH000611; Wed, 4 Aug 2004 10:45:46 -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 i74HjjxM000602 for ; Wed, 4 Aug 2004 10:45:45 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (opene-130-129-128-164.ietf60.ietf.org [130.129.128.164]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 4 Aug 2004 18:49:05 +0100 Message-ID: <411120BB.4070500@isode.com> Date: Wed, 04 Aug 2004 18:45:31 +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: IMAP Extensions WG Subject: Re: flags and ANNOTATE References: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> In-Reply-To: <200408041723.i74HNLM0018863@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: >[...] >Overall, the use case for the /flags hierarchy seems much less developed >than the basic idea of annotations. So, I move that the toplevel /flags >hierarchy of annotations be removed from the ANNOTATE draft. If/when a >clear use scenario for them can be ennunciated, presumably with some >required semantic from which mapping rules can be derived, a separate >(individual?) draft can be floated that describes how to add them to a >server supporting ANNOTATE. > > One thing I forgot to mention during the IMAPEXT meeting. CONDSTORE uses ANNOTATE syntax, so we *can't* remove /flags hierarchy. However, we can make it either reserved, or read-only. 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 i74HNMvj098537; Wed, 4 Aug 2004 10:23:22 -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 i74HNM68098536; Wed, 4 Aug 2004 10:23:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HNME8098527 for ; Wed, 4 Aug 2004 10:23:22 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i74HNLlo021069 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 4 Aug 2004 10:23:21 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i74HNLM0018863 for ; Wed, 4 Aug 2004 10:23:21 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408041723.i74HNLM0018863@lab.smi.sendmail.com> To: IMAP Extensions WG Subject: flags and ANNOTATE Date: Wed, 04 Aug 2004 10:23:21 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the meeting I promised to do a review of the archives on the issue of IMAP flags in ANNOTATE. Summary: this is an old, old issue. The historical discussion of this issue seemed to center on two points: - its ability to give clients fine grained control over whether a flag setting was shared or private - the complexity it causes Three observations make me dubious of the first argument: 1) I didn't see any comments describing the horrific workarounds that are inflicted on clients by the current lack of this ability 2) despite a message by Cyrus noting that rules were needed to describe how the .priv and .shared values interacted with the 'normal' view of the flag, no one ever stated what they saw as the minimal requirements for solving the client issues they saw, much less what the full rules should look like 3) there was no discussion of whether or how the various ACL rights that control normal flag updates ('s', 'w', 'd' (or 't')) would affect the ability to update the flag annotations. Again, there was just a "we should think about this" note Overall, the use case for the /flags hierarchy seems much less developed than the basic idea of annotations. So, I move that the toplevel /flags hierarchy of annotations be removed from the ANNOTATE draft. If/when a clear use scenario for them can be ennunciated, presumably with some required semantic from which mapping rules can be derived, a separate (individual?) draft can be floated that describes how to add them to a server supporting ANNOTATE. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LE92A091307; Mon, 2 Aug 2004 14:14:09 -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 i72LE9II091306; Mon, 2 Aug 2004 14:14:09 -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 i72LE93O091300 for ; Mon, 2 Aug 2004 14:14:09 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from opene-130-129-130-139.ietf60.ietf.org (opene-130-129-130-139.ietf60.ietf.org [130.129.130.139]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i72L0Po3018005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Aug 2004 17:00:29 -0400 Date: Mon, 02 Aug 2004 14:14:02 -0700 From: Cyrus Daboo To: IMAP Extensions WG Subject: LISTEXT: more control over returned results Message-ID: <93BC5553CAB5C16A3AC3118B@ninevah.local> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) 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, This is a head-up for an issue I would like to discuss in the meeting later today. I am thinking about how LISTEXT and ANNOTATEMORE will work together to allow searching for mailboxes with specific values in their annotations. One thing that comes up in this is having better control over what information is returned in the LIST response to a LISTEXT command. For example, say I want to find all mailboxes that have their /check annotations set to true, and have the LIST results return just the /checkperiod annotation value for each of those - in this case I do not care about the standard LIST flags and do not want to waste bandwidth getting those (since they will probably already be known from an earlier LIST). i.e. I want to split the LISTEXT command into two parts: one which controls which mailboxes get 'matched' and the other which controls what information about those mailboxes gets 'returned'. Right now there is no clear distinction in LISTEXT between the two. For example, the SUBSCRIBED option both 'matches' and 'returns' subscribed state. Thus there is no way in a single list command to say find all INBOX.* mailboxes and see which of those are subscribed. Whereas, if one could control the LISTEXT response output in more detail, you could in a single command match the INBOX.* mailboxes and also return their subscribed state. What I propose is a change to the current LISTEXT command syntax: LIST mailbox-spec RETURN would be the list of attributes to return for each mailbox. In the absence of a RETURN, the responses would be standard IMAP LIST flags. An initial set of would be: NOSTDFLAGS - do not return standard LIST flags SUBSCRIBED - return subscribed state CHILDREN - return children state REMOTE - return referral info SUBMAILBOXES - return place holder info The list would be: SUBSCRIBED - match only subscribed mailboxes Thus for the example I gave: a LIST "" "INBOX.*" RETURN (SUBSCRIBED) would list all sub-mailboxes of INBOX and show which of them is subscribed all in one go. For ANNOTATEMORE we could add for : ANNOTATE - match annotations with in and for ANNOTATION - return specified entries only. A similar extension could be done for ACL information and perhaps even STATUS... Obviously this is a departure from the current LISTEXT design, but I believe it will be more flexible for future uses of LISTEXT. -- 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 i72L1wjv090286; Mon, 2 Aug 2004 14:01:58 -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 i72L1wpr090285; Mon, 2 Aug 2004 14:01:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from aaryn.lunarpages.com (aaryn.lunarpages.com [216.193.217.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72L1vFW090278 for ; Mon, 2 Aug 2004 14:01:57 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from [130.129.128.67] (helo=dul1shollenbl1) by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BrjxH-0003Kk-1E; Mon, 02 Aug 2004 14:02:48 -0700 From: "Scott Hollenbeck" To: "'Lisa Dusseault'" , "'Philip Guenther'" Cc: "'IMAP Extensions WG'" Subject: RE: Agenda & slides Date: Mon, 2 Aug 2004 17:02:15 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F777@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <3D7E07F9-E4C6-11D8-95D8-000A95B2BB72@osafoundation.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - 428cobrajet.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, I wouldn't mind seeing an effort to reconcile mil(e|l)stones with the current charter, and/or updating the charter as necessary to reflect reality. -Scott- > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > Sent: Monday, August 02, 2004 4:55 PM > To: Philip Guenther > Cc: IMAP Extensions WG > Subject: Re: Agenda & slides > > > > Yeah, that's a great idea. Officially this is a recharter, and Scott > did ask for us to recharter a while back so let's do it. > > Can we officially call them Millstones, though? > > Lisa > > On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote: > > > > > Should an item be added at the end to talk about updating the WG > > Goals and Millstones to reflect the current reality? > > > > > > Philip Guenther > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KtBhQ089964; Mon, 2 Aug 2004 13:55: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 i72KtBhw089963; Mon, 2 Aug 2004 13:55:11 -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 i72KtBBf089949 for ; Mon, 2 Aug 2004 13:55:11 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [130.129.129.22] (opene-130-129-129-22.ietf60.ietf.org [130.129.129.22] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i72KtCpp021297 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 2 Aug 2004 13:55:13 -0700 In-Reply-To: <200408022049.i72Knv1Q029870@lab.smi.sendmail.com> References: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> <200408022049.i72Knv1Q029870@lab.smi.sendmail.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3D7E07F9-E4C6-11D8-95D8-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Agenda & slides Date: Mon, 2 Aug 2004 13:55:09 -0700 To: Philip Guenther 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: Yeah, that's a great idea. Officially this is a recharter, and Scott did ask for us to recharter a while back so let's do it. Can we officially call them Millstones, though? Lisa On Aug 2, 2004, at 1:49 PM, Philip Guenther wrote: > > Should an item be added at the end to talk about updating the WG > Goals and Millstones to reflect the current reality? > > > Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KntF7089606; Mon, 2 Aug 2004 13:49: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 i72Knt7R089605; Mon, 2 Aug 2004 13:49:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KntY4089599 for ; Mon, 2 Aug 2004 13:49:55 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i72Knv1P008927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 2 Aug 2004 13:49:57 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i72Knv1Q029870; Mon, 2 Aug 2004 13:49:57 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200408022049.i72Knv1Q029870@lab.smi.sendmail.com> To: Lisa Dusseault Cc: IMAP Extensions WG Subject: Re: Agenda & slides In-reply-to: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> References: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> Date: Mon, 02 Aug 2004 13:49:57 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Should an item be added at the end to talk about updating the WG Goals and Millstones to reflect the current reality? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72JnckY084889; Mon, 2 Aug 2004 12:49:38 -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 i72Jncj9084888; Mon, 2 Aug 2004 12:49:38 -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 i72JncDX084862 for ; Mon, 2 Aug 2004 12:49:38 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [130.129.129.22] (opene-130-129-129-22.ietf60.ietf.org [130.129.129.22] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i72Jncpp012593 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 2 Aug 2004 12:49:39 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <14B412CE-E4BD-11D8-95D8-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Agenda & slides Date: Mon, 2 Aug 2004 12:49:35 -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 official agenda deadline passed without our noticing this summer (sorry), so we never put together a real agenda for today's IMAPEXT meeting. We did just get together & try to compensate for that -- we'll discuss the status and known issues on -i18n, sort, annotate, listext and acl2. More detail here: http://www.sharemation.com/~milele/public/imapext Lisa