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 i5TMMHlk030103; Tue, 29 Jun 2004 15:22: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 i5TMMHf7030102; Tue, 29 Jun 2004 15:22:17 -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 i5TMMGqM030091 for ; Tue, 29 Jun 2004 15:22:17 -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 i5TMMFrR003482 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Jun 2004 15:22:15 -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 i5TMMEYM058882; Tue, 29 Jun 2004 15:22:14 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406292222.i5TMMEYM058882@lab.smi.sendmail.com> To: Rob Siemborski Cc: Alexey Melnikov , IMAP Extensions WG From: Philip Guenther Subject: Re: LISTEXT draft In-reply-to: References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> Date: Tue, 29 Jun 2004 15:22:14 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Sun, 27 Jun 2004, Philip Guenther wrote: ... >> Of course, all returned mailboxes must match the pattern, possibly >> modified by the reference argument, regardless of whether the named >> mailbox is selected or a child mailbox is selected. > >Why? IMAP allows for unsolicited LIST responses at any time, just like >any other IMAP response. True enough; perhaps I should have said that a returned mailbox that doesn't match the pattern is effectively unaffiliated with the LIST command that preceded it. Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the subscribed mailboxes as such, because it's otherwise ambiguous whether any given LIST response is of a subscribed mailbox: the server could just be sending random LIST responses for unsubscribed mailboxes because it felt like it. Should it mark them with a "list flag" or a "list extended item"? * LIST (\IsSubscribed) "/" foo or * LIST () "/" foo ((SUBSCRIBED ())) ? Hmm, this may also tangle with REMOTE, depending on how server treats a remote mailbox when the REMOTE option isn't used. Should a server act like the mailbox doesn't exist, even to the point of sending \NonExistent, if it's remote but the REMOTE option wasn't used? If so, a LIST (REMOTE) could legally result in two different responses for the same mailbox, say: * LIST () "/" foo ((REMOTE "imap:blahblah")) * LIST (\NonExistent) "/" foo that second response being unrelated to the LIST (REMOTE), just something the server felt like sending. This complicates any future effort to have server send LIST responses to indicate changes in the mailbox hierarchy: you can't just indicate that a mailbox is no longer there by sending a \NonExistent response, as that's effectively a no-op for remote mailboxes. The server would have to use something like: * LIST (\NonExistent) "/" foo ((REMOTE "")) to mean "it's really gone and doesn't even exist as a remote mailbox" 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 i5TKhtLg024355; Tue, 29 Jun 2004 13:43: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 i5TKhtVK024354; Tue, 29 Jun 2004 13:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TKhtSp024347 for ; Tue, 29 Jun 2004 13:43:55 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKhp0w028697 for ; Tue, 29 Jun 2004 13:43:56 -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.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKhokm001770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 Jun 2004 13:43:51 -0700 X-Return-Path: X-Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Tue, 29 Jun 2004 13:23:48 -0700 (PDT) X-Return-Path: X-Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.140]) by ndcms.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKNmT0001301; Tue, 29 Jun 2004 13:23:48 -0700 X-Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKNitF012169; Tue, 29 Jun 2004 13:23:46 -0700 X-Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfOLP-0005T8-W0; Tue, 29 Jun 2004 15:32:39 -0400 X-Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfOH0-0004aK-A3 for i-d-announce@megatron.ietf.org; Tue, 29 Jun 2004 15:28:06 -0400 X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11344 for ; Tue, 29 Jun 2004 15:28:04 -0400 (EDT) Message-Id: <200406291928.PAA11344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 29 Jun 2004 15:28:04 -0400 Subject: I-D ACTION:draft-crispin-imap-urlauth-09.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-Uwash-Spam: Gauge=XII, Probability=12%, Report='MIME_BOUND_NEXTPART 1.085, __SANE_MSGID 0, __MIME_VERSION 0, __NEXTPART_ALL 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __TO_MALFORMED_2 0, NO_REAL_NAME 0.000, __X_BEENTHERE 0, __DCC_BODY 0, __DCC_FUZ1 0, __DCC_FUZ2 0, DCC_BULK_LOW 0, __HAS_MSGID 0' 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. Title : Internet Message Access Protocol (IMAP) - URLAUTH Extension Author(s) : M. Crispin, C. Newman Filename : draft-crispin-imap-urlauth-09.txt Pages : 8 Date : 2004-6-29 This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can create 'signed' URLs which can be used to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of 'URLAUTH'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-09.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-crispin-imap-urlauth-09.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-crispin-imap-urlauth-09.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-6-29150052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imap-urlauth-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imap-urlauth-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150052.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 i5TJAhVs016246; Tue, 29 Jun 2004 12:10: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 i5TJAhT8016245; Tue, 29 Jun 2004 12:10:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJAgLX016235 for ; Tue, 29 Jun 2004 12:10:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i5TJAe0n001385; Tue, 29 Jun 2004 15:10:40 -0400 Date: Tue, 29 Jun 2004 15:10:40 -0400 (EDT) From: Rob Siemborski To: Philip Guenther cc: Alexey Melnikov , IMAP Extensions WG , Mark Crispin , Ken Murchison Subject: Re: LISTEXT draft In-Reply-To: <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> Message-ID: References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 27 Jun 2004, Philip Guenther wrote: > Alexey Melnikov writes: > ... >> 2). Clarify that there are only two reasons for including a mailbox in >> the responses to the LIST command: the mailbox itself may be selected >> and matched and/or it may have at least one child mailbox that is >> selected but not matched. If neither of those is true then there's no >> reason to include a response for the mailbox. > > Of course, all returned mailboxes must match the pattern, possibly > modified by the reference argument, regardless of whether the named > mailbox is selected or a child mailbox is selected. Why? IMAP allows for unsolicited LIST responses at any time, just like any other IMAP response. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5S1a8Zi001160; Sun, 27 Jun 2004 18:36:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5S1a8VT001159; Sun, 27 Jun 2004 18:36:08 -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 i5S1a360001144 for ; Sun, 27 Jun 2004 18:36:05 -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 i5S1a2Kx020656 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 27 Jun 2004 18:36:02 -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 i5S1a1Tw093890; Sun, 27 Jun 2004 18:36:01 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG , Mark Crispin , Ken Murchison From: Philip Guenther Subject: Re: LISTEXT draft In-reply-to: <40DDF46F.30309@isode.com> References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> Date: Sun, 27 Jun 2004 18:36:01 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >2). Clarify that there are only two reasons for including a mailbox in >the responses to the LIST command: the mailbox itself may be selected >and matched and/or it may have at least one child mailbox that is >selected but not matched. If neither of those is true then there's no >reason to include a response for the mailbox. Of course, all returned mailboxes must match the pattern, possibly modified by the reference argument, regardless of whether the named mailbox is selected or a child mailbox is selected. ... >Philip originally suggested to use the CHILDREN selection criterion >should be used instead of SUBMAILBOXES. I am not so sure about this. >Suggestions are welcome. I have no strong feelings about what name should be used for this; it merely started from my pondering the differences between \PlaceHolder and \HasChildren and the observation that, unlike \HasChildren, \PlaceHolder had a clear definition in the presence of other selection criteria (in particular, SUBSCRIBED). ... >(unspecified whether it has any selected and matched children). This is to leave it up to the implementation what happens if the client specifies a pattern that can match a mailbox and some, but not all of its child mailboxes: an implementation could ignore the matched children when deciding whether the \PlaceHolder or \HasSubmailboxes flag is needed or it could decide which flag to return based just on whether any children were matched. I wouldn't expect this leeway to be a problem for clients for two reasons: 1) it seems unlikely that a client would use such a pattern normally, and 2) there's only an ambiguity if at last one child mailbox was also returned, which probably resolves the real question that the client wanted answered. For example, consider a hierarchy using slash as the delimiter with the following mailboxes: foo2 foo2/bar1 foo2/bar2 quux2/bar2 If the client sends the command A01 LIST (SUBMAILBOXES) "" "*2" then the server MUST include * LIST () "/" "foo2/bar2" * LIST () "/" "quux2/bar2" and exactly one of * LIST () "/" "foo2" * LIST (\HasSubmailboxes) "/" "foo2" in its response. It MAY also include * LIST (\NonExistent \PlaceHolder) "/" "quux2" >After all those changes/clarifications, the table shown by Philip becomes: > > has selected child returned >exists selected that doesn't match pattern LISTEXT flags >--------------------------------------------------------------------------- > no no no no response >yes no no no response > no yes no (\NonExistent) >yes yes no () > no no yes (\NonExistent \PlaceHolder) >yes no yes (\PlaceHolder) > no yes yes (\NonExistent >\HasSubmailboxes) >yes yes yes (\HasSubmailboxes) That third column should just be titled "has selected child". (I'm obviously in favor of this change) 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 i5RMcBjn087016; Sun, 27 Jun 2004 15:38: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 i5RMcBeh087015; Sun, 27 Jun 2004 15:38:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RMc9Fm087008 for ; Sun, 27 Jun 2004 15:38:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust235.tnt27.lnd4.gbr.da.uu.net [62.188.154.235]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 27 Jun 2004 23:39:05 +0100 Message-ID: <40DDF46F.30309@isode.com> Date: Sat, 26 Jun 2004 23:10:55 +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 CC: Philip Guenther , Mark Crispin , Ken Murchison Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> In-Reply-To: <40D75322.8050409@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Philip Guenther wrote: > >> [...] >> For any possible mailbox name that matches a LIST pattern, there >> are eight possible situations to reflect the three conditions: >> - does the name exist as a mailbox >> - does the name match the selection criteria (LISTEXT options) >> - does the name have at least one child mailbox which exists and >> matches the selection criteria, but *doesn't* match the pattern >> >> has selected child returned >> exists selected that doesn't match pat. LISTEXT flags >> --------------------------------------------------------------------------- >> >> no no no no response >> yes no no no response >> no yes no (\NonExistent) >> yes yes no () >> no no yes (???) <- 1 >> yes no yes (\PlaceHolder) >> no yes yes (\NonExistent) >> yes yes yes () <- 2 >> >> >> Question #1: >> What should be returned in case #1 (line 5) above? For a concrete >> example, consider a Cyrus-like server on which the mailbox >> "Vegis/Squash" was created and subscribed to, and then the "Vegis" >> mailbox was deleted, removing it completely and _not_ leaving it >> as a \NoSelect mailbox; should the command >> tag LIST (SUBSCRIBED) "" % >> >> return a LIST response for "Vegis", >> >> and if so, with what flags? >> > Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be > returned, as there are submailboxes that conform to the selection > criteria, but doesn't match the pattern. It also seems that > \NonExistent should be returned as well, as the mailbox doesn't exist. > (From the point of view of a client writer: the client need to know > which mailboxes should not be selected). > However, the current definition for \NonExistent is: > "\NonExistent", that indicates that a mailbox is subscribed to, but > does not actually exist. > > I am wondering if this definition should be changed to be more > generic, for example: > > "\NonExistent", that indicates that a mailbox satisfy the selection > criterion, but does not actually exist. > > But this might be too open ended. Alternatively, the draft can spell > out this case specifically and show an example. > What other people think? Philip has found few underspecified cases. After discussing this off list with Philip I would propose the following changes to the LISTEXT document: 1). Clarify that for any mailbox name only a single LIST response must be returned. 2). Clarify that there are only two reasons for including a mailbox in the responses to the LIST command: the mailbox itself may be selected and matched and/or it may have at least one child mailbox that is selected but not matched. If neither of those is true then there's no reason to include a response for the mailbox. 3). Add a new selection criterion (e.g. SUBMAILBOXES) that requests that \PlaceHolder MUST be returned and MUST be precise. In the absence of the criterion \PlaceHolder MAY be returned and it is not necessary precise. (Clients need to handle the case when \PlaceHolder is returned and there are no submailboxes, as they were deleted/renamed after the LIST response was sent, but before the client had a chance to list/access them). Philip originally suggested to use the CHILDREN selection criterion should be used instead of SUBMAILBOXES. I am not so sure about this. Suggestions are welcome. 4). Clarify the meaning of \PlaceHolder flag: \PlaceHolder mailbox is *not* selected but it has selected children (unspecified whether any, all, or none are matched) Add a new mutually exclusive flag \HasSubmailboxes: \HasSubmailboxes mailbox is selected *and* has selected children (unspecified whether any, all or none are matched) Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox matches the selection criterion, but doesn't have any selected but unmatched children (unspecified whether it has any selected and matched children). 5). Define \NonExistent as follows: "\NonExistent", that indicates that a mailbox satisfy the selection criterion, but does not actually exist. 6). Add more examples, clarify edge cases. ========= After all those changes/clarifications, the table shown by Philip becomes: has selected child returned exists selected that doesn't match pattern LISTEXT flags --------------------------------------------------------------------------- no no no no response yes no no no response no yes no (\NonExistent) yes yes no () no no yes (\NonExistent \PlaceHolder) yes no yes (\PlaceHolder) no yes yes (\NonExistent \HasSubmailboxes) yes yes yes (\HasSubmailboxes) 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 i5O7RIQR051762; Thu, 24 Jun 2004 00:27: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 i5O7RIgD051761; Thu, 24 Jun 2004 00:27: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 i5O7RGD5051740 for ; Thu, 24 Jun 2004 00:27: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 i5O7RGV3032659 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 24 Jun 2004 00:27:16 -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 i5O7RFxl081070; Thu, 24 Jun 2004 00:27:16 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406240727.i5O7RFxl081070@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: LISTEXT draft In-reply-to: <40D84CBF.3060709@isode.com> References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40D84CBF.3060709@isode.com> Date: Thu, 24 Jun 2004 00:27:15 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >Alexey Melnikov wrote: > >> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be >> returned, as there are submailboxes that conform to the selection >> criteria, but doesn't match the pattern. [...] > >On a related note: I was wondering if it is worth adding a selection >criterion saying that \PlaceHolder MUST be returned and MUST be precise? I support this idea. Indeed, an accurate version of the \PlaceHolder described in the current draft could be construed as an improved version of \HasChildren, as it actually has a well defined meaning when other selection criteria (such as SUBSCRIBED) are used. Looking at this another way: is there any objection to the idea that a server MUST support a 100% accurate version** of \HasChildren to claim LISTEXT compliancy? Philip Guenther ** Not necessarily under the name \HasChildren or exactly as described in RFC 3348, but the same basic idea of "some mailbox under this one has a specified property" 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 i5MFE6Nn047073; Tue, 22 Jun 2004 08:14: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 i5MFE6x6047072; Tue, 22 Jun 2004 08:14:06 -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 i5MFE5p1047062 for ; Tue, 22 Jun 2004 08:14:05 -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, 22 Jun 2004 16:14:42 +0100 Message-ID: <40D84CBF.3060709@isode.com> Date: Tue, 22 Jun 2004 16:14:07 +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 CC: Philip Guenther Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> In-Reply-To: <40D75322.8050409@isode.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: Alexey Melnikov wrote: > Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be > returned, as there are submailboxes that conform to the selection > criteria, but doesn't match the pattern. [...] On a related note: I was wondering if it is worth adding a selection criterion saying that \PlaceHolder MUST be returned and MUST be precise? 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 i5MCwPc7018798; Tue, 22 Jun 2004 05:58:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MCwPYd018796; Tue, 22 Jun 2004 05:58:25 -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 i5MCwKqt018774 for ; Tue, 22 Jun 2004 05:58:20 -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, 22 Jun 2004 13:58:54 +0100 Message-ID: <40D82CEB.6020803@isode.com> Date: Tue, 22 Jun 2004 13:58:19 +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: Arnt Gulbrandsen CC: IMAP Extensions WG Subject: Re: Changes to LISTEXT draft References: <40D75F2C.6040905@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> I've updated the LISTEXT draft to use ACAP vendor registry. I will be >> sending a new revision shortly. There is also the following text in >> the draft now: >> >> Standard LISTEXT option/extended data item names are case >> insensitive. Vendor specific LISTEXT option/extended data item >> names are case insensitive, if the vendor prefix is omitted. The >> vendor prefix itself is not case-sensitive, as it might contain >> non-ASCII characters. >> >> Does this text make any sense? > > A little bit too complex, perhaps? If the client's required to to do > case folding for the word föö, surely it can manage to fold the vendor > name möö as well. > >> What should be done for vendor prefixes that are completely comprised >> of ASCII characters? Should IANA be directed to prevent registrations >> that are completely in ASCII and only differ in case? > > The latter seems to offer a good way out. The only procedural problem with this is that ACAP vendor registry is defined by the ACAP RFC, we don't want to revise it ;-). 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 i5MC5aic008419; Tue, 22 Jun 2004 05:05:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MC5aAs008418; Tue, 22 Jun 2004 05:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MC5TwI008387 for ; Tue, 22 Jun 2004 05:05:33 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id B5E221BDE7F; Tue, 22 Jun 2004 14:05:29 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 2F0D51BDE7B; Tue, 22 Jun 2004 14:05:27 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: Alexey Melnikov Subject: Re: Changes to LISTEXT draft Cc: IMAP Extensions WG References: <40D75F2C.6040905@isode.com> In-Reply-To: <40D75F2C.6040905@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 Date: Tue, 22 Jun 2004 14:09:24 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5MC5ZwI008412 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > I've updated the LISTEXT draft to use ACAP vendor registry. I will be > sending a new revision shortly. There is also the following text in > the draft now: > > Standard LISTEXT option/extended data item names are case > insensitive. Vendor specific LISTEXT option/extended data item > names are case insensitive, if the vendor prefix is omitted. The > vendor prefix itself is not case-sensitive, as it might contain > non-ASCII characters. > > Does this text make any sense? A little bit too complex, perhaps? If the client's required to to do case folding for the word föö, surely it can manage to fold the vendor name möö as well. > What should be done for vendor prefixes that are completely comprised > of ASCII characters? Should IANA be directed to prevent registrations > that are completely in ASCII and only differ in case? The latter seems to offer a good way out. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNQbow094239; Mon, 21 Jun 2004 16:26:37 -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 i5LNQbZv094238; Mon, 21 Jun 2004 16:26:37 -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 i5LNQZ8v094224 for ; Mon, 21 Jun 2004 16:26:36 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:27:08 +0100 Message-ID: <40D75F2C.6040905@isode.com> Date: Mon, 21 Jun 2004 23:20:28 +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: Changes to LISTEXT draft 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: I've updated the LISTEXT draft to use ACAP vendor registry. I will be sending a new revision shortly. There is also the following text in the draft now: Standard LISTEXT option/extended data item names are case insensitive. Vendor specific LISTEXT option/extended data item names are case insensitive, if the vendor prefix is omitted. The vendor prefix itself is not case-sensitive, as it might contain non-ASCII characters. Does this text make any sense? What should be done for vendor prefixes that are completely comprised of ASCII characters? Should IANA be directed to prevent registrations that are completely in ASCII and only differ in case? 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 i5LNN1s9093202; Mon, 21 Jun 2004 16:23:01 -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 i5LNN1On093201; Mon, 21 Jun 2004 16:23:01 -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 i5LNMvfK093176 for ; Mon, 21 Jun 2004 16:22:59 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:23:04 +0100 Message-ID: <40D75322.8050409@isode.com> Date: Mon, 21 Jun 2004 22:29: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 MIME-Version: 1.0 To: Philip Guenther CC: IMAP Extensions WG Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> In-Reply-To: <200406081235.i58CZTT0068505@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: >Please forgive me the disorganization of this note, I've having a >hard time finding a good presentation for the thoughts and questions >in it. I came up with these questions while trying to figure out >what it would take to implement LISTEXT in the IMAP server I work >on. Having pondered these questions, I understand less than when >I started. > > >For any possible mailbox name that matches a LIST pattern, there >are eight possible situations to reflect the three conditions: >- does the name exist as a mailbox >- does the name match the selection criteria (LISTEXT options) >- does the name have at least one child mailbox which exists and > matches the selection criteria, but *doesn't* match the pattern > > has selected child returned >exists selected that doesn't match pat. LISTEXT flags >--------------------------------------------------------------------------- > no no no no response > yes no no no response > no yes no (\NonExistent) > yes yes no () > no no yes (???) <- 1 > yes no yes (\PlaceHolder) > no yes yes (\NonExistent) > yes yes yes () <- 2 > > >Question #1: > What should be returned in case #1 (line 5) above? For a concrete >example, consider a Cyrus-like server on which the mailbox >"Vegis/Squash" was created and subscribed to, and then the "Vegis" >mailbox was deleted, removing it completely and _not_ leaving it >as a \NoSelect mailbox; should the command > tag LIST (SUBSCRIBED) "" % > >return a LIST response for "Vegis", > >and if so, with what flags? > Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be returned, as there are submailboxes that conform to the selection criteria, but doesn't match the pattern. It also seems that \NonExistent should be returned as well, as the mailbox doesn't exist. (From the point of view of a client writer: the client need to know which mailboxes should not be selected). However, the current definition for \NonExistent is: "\NonExistent", that indicates that a mailbox is subscribed to, but does not actually exist. I am wondering if this definition should be changed to be more generic, for example: "\NonExistent", that indicates that a mailbox satisfy the selection criterion, but does not actually exist. But this might be too open ended. Alternatively, the draft can spell out this case specifically and show an example. What other people think? 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 i5LNMAPj093065; Mon, 21 Jun 2004 16:22: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 i5LNMAqE093064; Mon, 21 Jun 2004 16:22:10 -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 i5LNM4SI093035 for ; Mon, 21 Jun 2004 16:22:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:22:00 +0100 Message-ID: <40D74F3F.5010604@isode.com> Date: Mon, 21 Jun 2004 22:12: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 To: Lisa Dusseault CC: Ken Murchison , IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> <40A12004.3060401@isode.com> <8D59182D-C2EB-11D8-A549-000A95B2BB72@osafoundation.org> In-Reply-To: <8D59182D-C2EB-11D8-A549-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: > Going through older mail now that I've reviewed LISTEXT myself, it > seems there a couple issues around what status LISTEXT has with > respect to two RFCs. Please give your input if you've got any > background with these RFCs ... and let the group know to what extent > these RFCs are implemented, and whether the implementors intend to go > ahead with LISTEXT. > >>> or does LISTEXT automatically give you support for the functionality >>> in RFC 2193 and RFC 3348? >> >> LISTEXT gives the complete functionality of RFC 3348. However LIST >> (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC >> 2193 is not affected. > > We probably need to be pretty clear about that role, in LISTEXT, > before going forward. Is there general agreement about how LISTEXT > relates to RFC2193? I proposed earlier to publish a revision of RFC 2193 shortly after publishing LISTEXT. I also wanted to add REFERRAL list data item to LIST response, but I don't feel there is any consensus on this. I intend to either publish a separate draft for REFERRAL, or fold it into revision of RFC 2193. If anybody has any comments on this plan, please speak up now. >>> I don't know, it seemed like common sense to me. Is LISTEXT going >>> to deprecate RFC 3348? >> >> I think it effectively does. But does WG wants to officially state >> that in LISTEXT? > > To me it looks like LISTEXT should deprecate RFC3348, but we > definitely need to hear from people with a deeper background. As far as I know everybody agrees with this decision. If anybody want to speak against it, please give your arguments 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 i5KIulT3051522; Sun, 20 Jun 2004 11:56: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 i5KIul7E051521; Sun, 20 Jun 2004 11:56:47 -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 i5KIujeP051500 for ; Sun, 20 Jun 2004 11:56:45 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org 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 i5KItcJL009347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 20 Jun 2004 11:55:41 -0700 In-Reply-To: <40A12004.3060401@isode.com> References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> <40A12004.3060401@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D59182D-C2EB-11D8-A549-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Ken Murchison , IMAP Extensions WG From: Lisa Dusseault Subject: Re: Collected issues with LISTEXT Date: Sun, 20 Jun 2004 11:56:35 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Going through older mail now that I've reviewed LISTEXT myself, it seems there a couple issues around what status LISTEXT has with respect to two RFCs. Please give your input if you've got any background with these RFCs ... and let the group know to what extent these RFCs are implemented, and whether the implementors intend to go ahead with LISTEXT. >> or does LISTEXT automatically give you support for the functionality >> in RFC 2193 and RFC 3348? > > LISTEXT gives the complete functionality of RFC 3348. However LIST > (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 > is not affected. We probably need to be pretty clear about that role, in LISTEXT, before going forward. Is there general agreement about how LISTEXT relates to RFC2193? >> >> I don't know, it seemed like common sense to me. Is LISTEXT going to >> deprecate RFC 3348? > > I think it effectively does. But does WG wants to officially state > that in LISTEXT? To me it looks like LISTEXT should deprecate RFC3348, but we definitely need to hear from people with a deeper background. 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 i5IN3nFm094652; Fri, 18 Jun 2004 16:03: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 i5IN3ncH094651; Fri, 18 Jun 2004 16:03:49 -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 i5IN3mKp094633 for ; Fri, 18 Jun 2004 16:03:49 -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 i5IN2kJL023703 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 18 Jun 2004 16:02:49 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: LISTEXT spec Date: Fri, 18 Jun 2004 16:03:37 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've reviewed the LISTEXT spec & I have only one issue that the authors are probably already aware of -- that the definition of PlaceHolder needs to be finished. Otherwise, if the authors are ready for last call, I'll make that happen. 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 i5IBuC0O070265; Fri, 18 Jun 2004 04:56:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IBuC0q070264; Fri, 18 Jun 2004 04:56:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IBuB5a070255 for ; Fri, 18 Jun 2004 04:56:11 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 979851A71C; Fri, 18 Jun 2004 13:56:12 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 7EB611A6FF; Fri, 18 Jun 2004 13:56:09 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: Re: draft-ietf-imapext-i18n-03.txt Cc: Ned Freed References: In-Reply-To: Date: Fri, 18 Jun 2004 13:57:26 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen writes: > Chris Freeman's I got that name wrong, didn't I? The sun must have baked my brain. Sorry. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IBsZ01069892; Fri, 18 Jun 2004 04:54: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 i5IBsZfS069891; Fri, 18 Jun 2004 04:54:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IBsY7w069881 for ; Fri, 18 Jun 2004 04:54:34 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 4D1721A71C; Fri, 18 Jun 2004 13:54:35 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 2CAB31A6FF; Fri, 18 Jun 2004 13:54:32 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: draft-ietf-imapext-i18n-03.txt Cc: Ned Freed Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 18 Jun 2004 13:55:49 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think I worked through everyone's comments. If there's something I missed or you have new comments, please let me know. Otherwise I'll just lounge in the sun, waiting for Ned Freed (cc:) to update Chris Freeman's comparator draft. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HH0har079555; Thu, 17 Jun 2004 10:00: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 i5HH0hNd079554; Thu, 17 Jun 2004 10:00:43 -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 i5HH0hpH079540 for ; Thu, 17 Jun 2004 10:00:43 -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 i5HGxgJL000347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 17 Jun 2004 09:59:42 -0700 Mime-Version: 1.0 (Apple Message framework v613) To: IMAP Extensions WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-12--337229252 From: Lisa Dusseault Subject: Fwd: 60th IETF Meeting - DRAFT Agenda Date: Thu, 17 Jun 2004 10:00:36 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-12--337229252 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Note that IMAPEXT is meeting the afternoon of Monday, Aug 2. We should have a new annotate draft by then, discuss private/shared issues if they're still open, and hopefully start some discussion of LISTEXT by then ( I still owe a review but others ought to review as well). Lisa Begin forwarded message: > From: agenda@ietf.org > Date: June 16, 2004 2:49:27 PM PDT > To: wgchairs@ietf.org, iesg@ietf.org > Cc: mbeaulie@foretec.com > Subject: 60th IETF Meeting - DRAFT Agenda > > > Draft Agenda of the Sixtieth IETF > August 1 - 6, 2004 > As of 6/16/2004 > > SUNDAY, August 1, 2004 > 1000-1700 IEPG Meeting - Marina 6 > 1200-1900 Registration - Harbor Island Foyer > 1300-1400 Newcomer's Training - Grande Ballroom A > 1300-1500 Editor's Training - Marina 5 > 1300-1500 Intro WG Chairs Training - > 1500-1700 Security Tutorial - Grande Ballroom A > 1700-1900 Welcome Reception - Grande Ballroom B/C > > MONDAY, August 2, 2004 > 0800-2000 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP apparea Applications Open Area Meeting > GEN newtrk New IETF Standards Track Discussion WG > INT dnsext DNS Extensions WG > OPS multi6 Site Multihoming for IPv6 WG > OPS hubmib Ethernet Interfaces and Hub MIB WG > RTG manet Mobile Ad-hoc Networks WG > TSV xcon Centralized Conference WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > APP imapext Internet Message Access Protocol Extension WG > INT rbridge IP Subnets in Topologies Which are Flexible, Universal > and Nice BOF > IRTF mobopts IP Mobility Optimizations > RTG forces Forwarding and Control Element Separation WG > SEC perm Protected Entertainment Rights Management BOF > TSV nsis Next Steps in Signaling WG > > 1500-1530 Break (Refreshments provided) - Harbor Island Foyer > 1530-1730 Afternoon Sessions II > APP simple SIP for Instant Messaging and Presence Leveraging > Extensions WG > GEN genarea General Area Open Meeting > OPS rmonmib Remote Network Monitoring WG > RTG ospf Open Shortest Path First WG > TSV dccp Datagram Congestion Control Protocol WG > TSV pwe3 Pseudo Wire Emulation Edge to Edge WG > > 1730-1930 Break > 1930-2200 Evening Sessions > APP lemonade Enhancements to Internet email to Support Diverse > Service Environments WG > INT nemo Network Mobility WG > RTG rtgarea Routing Area Meeting > SEC mobike IKEv2 Mobility and Multihoming WG > OPS/ imss/ Internet and Management Support for Storage WG and > TSV ips IP Storage WG > > TUESDAY, August 3, 2004 > 0800-1800 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP simple SIP for Instant Messaging and Presence Leveraging > Extensions WG > INT dhc Dynamic Host Configuration WG > IRTF dtnrg Delay-tolerant Networking Research Group > OPS psamp Packet Sampling WG > RTG ccamp Common Control and Measurement Plane WG > TSV avt Audio/Video Transport WG > > 1130-1300 Break > 1300-1400 Afternoon Sessions I > APP geopriv Geographic Location/Privacy WG > OPS atommib Atom MIB WG > RTG pim Protocol Independent Multicast WG > SEC smime S/MIME Mail Security WG > TSV nsis Next Steps in Signaling WG > TSV speechsc Speech Services Control WG > > 1415-1515 Afternoon Sessions II > APP geopriv Geographic Location/Privacy WG > INT magma Multicast & Anycast Group Membership WG > OPS aaa Authentication, Authorization and Accounting WG > RTG vrrp Virtual Router Redundancy Protocol WG > SEC enroll Credential and Provisioning WG > TSV ieprep Internet Emergency Preparedness WG > > 1515-1545 Break (Refreshments provided) - Harbor Island Foyer > 1545-1645 Afternoon Sessions III > SEC sasl Simple Authentication and Security Layer WG > TSV rohc Robust Header Compression WG > > 1700-1800 Afternoon Sessions IV > APP ldapbis LDAP (v3) Revision WG > TSV rohc Robust Header Compression WG > > > WEDNESDAY, August 4, 2004 > 0800-1700 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP marid MTA Authorization Records in DNS WG > INT eap Extensible Authentication Protocol WG > OPS mboned MBONE Deployment WG > SEC pkix Public Key Infrastructure WG > TSV rddp Remote Direct Data Placement WG > TSV sip Session Initiation Protocol WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > IRTF asrg Anti Spam Working Group > OPS capwap Control and Provisioning of Wireless Access Points WG > OPS dnsop Domain Name System Operations WG > SEC krbwg Kerberos WG > TSV enum Telephone and Number Mapping WG > TSV mmusic Multiparty Multimedia Session Control WG > > 1500-1530 Break (Refreshments provided) - Harbor Island Foyer > 1530-1730 Afternoon Sessions II > APP marid MTA Authorization Records in DNS WG > GEN icar Improved Cross-Area Review WG > INT ipv6 IP Version 6 WG > OPS ipfix IP Flow Export WG > RTG isis IS-IS for IP Internets WG > SEC pki4ipsec Profiling Use of PKI in IPSEC WG > TSV avt Audio/Video Transport WG > > 1730-1930 Break > 1930-2200 Plenary - IETF Business Meeting - Grande Ballroom > > > 2230 Late Night Session > PGP Key Signing > > > THURSDAY, August 5, 2004 > 0800-1700 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > INT hip Host Identity Protocol WG > RTG mpls Multi Protocol Label Switching WG > SEC msec Multicast Security WG > TSV tsvwg Transport Area Working Group > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > INT ipdvb IP over Digital Video Broadcast WG > INT l3vpn Layer 3 Virtual Private Network WG > SEC ltans Long-Term Archive and Notary WG > TSV rserpool Reliable Server Pooling WG > TSV sip Session Initiation Protocol WG > > 1500-1530 Break (Refreshments provided) - Harbor Island Foyer > 1530-1730 Afternoon Sessions II > APP webdav WWW Distributed Authoring and Versioning WG > INT dnsext DNS Extensions WG > OPS grow Global Routing Operations WG * > SEC saag Open Security Area Directorate > TSV sipping Session Initiation Protocol WG > > 1730-1930 Break > 1930-2200 Plenary - IETF Planning Meeting - Grande Ballroom > > > Friday, August 6, 2004 > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP atompub Atom Publishing Format and Protocol PWG > OPS netconf Network Configuration WG > RTG rpsec Routing Protocol Security Requirements WG > TSV sipping Session Initiation Protocol WG > --Apple-Mail-12--337229252 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Note that IMAPEXT is meeting the afternoon of Monday, Aug 2. We should have a new annotate draft by then, discuss private/shared issues if they're still open, and hopefully start some discussion of LISTEXT by then ( I still owe a review but others ought to review as well). Lisa Begin forwarded message: 0000,0000,0000From: agenda@ietf.org 0000,0000,0000Date: June 16, 2004 2:49:27 PM PDT 0000,0000,0000To: wgchairs@ietf.org, iesg@ietf.org 0000,0000,0000Cc: mbeaulie@foretec.com 0000,0000,0000Subject: 60th IETF Meeting - DRAFT Agenda Draft Agenda of the Sixtieth IETF August 1 - 6, 2004 As of 6/16/2004 SUNDAY, August 1, 2004 1000-1700 IEPG Meeting - Marina 6 1200-1900 Registration - Harbor Island Foyer 1300-1400 Newcomer's Training - Grande Ballroom A 1300-1500 Editor's Training - Marina 5 1300-1500 Intro WG Chairs Training - 1500-1700 Security Tutorial - Grande Ballroom A 1700-1900 Welcome Reception - Grande Ballroom B/C MONDAY, August 2, 2004 0800-2000 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting GEN newtrk New IETF Standards Track Discussion WG INT dnsext DNS Extensions WG OPS multi6 Site Multihoming for IPv6 WG OPS hubmib Ethernet Interfaces and Hub MIB WG RTG manet Mobile Ad-hoc Networks WG TSV xcon Centralized Conference WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP imapext Internet Message Access Protocol Extension WG INT rbridge IP Subnets in Topologies Which are Flexible, Universal and Nice BOF IRTF mobopts IP Mobility Optimizations RTG forces Forwarding and Control Element Separation WG SEC perm Protected Entertainment Rights Management BOF TSV nsis Next Steps in Signaling WG 1500-1530 Break (Refreshments provided) - Harbor Island Foyer 1530-1730 Afternoon Sessions II APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG GEN genarea General Area Open Meeting OPS rmonmib Remote Network Monitoring WG RTG ospf Open Shortest Path First WG TSV dccp Datagram Congestion Control Protocol WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG 1730-1930 Break 1930-2200 Evening Sessions APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG INT nemo Network Mobility WG RTG rtgarea Routing Area Meeting SEC mobike IKEv2 Mobility and Multihoming WG OPS/ imss/ Internet and Management Support for Storage WG and TSV ips IP Storage WG TUESDAY, August 3, 2004 0800-1800 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT dhc Dynamic Host Configuration WG IRTF dtnrg Delay-tolerant Networking Research Group OPS psamp Packet Sampling WG RTG ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG 1130-1300 Break 1300-1400 Afternoon Sessions I APP geopriv Geographic Location/Privacy WG OPS atommib Atom MIB WG RTG pim Protocol Independent Multicast WG SEC smime S/MIME Mail Security WG TSV nsis Next Steps in Signaling WG TSV speechsc Speech Services Control WG 1415-1515 Afternoon Sessions II APP geopriv Geographic Location/Privacy WG INT magma Multicast & Anycast Group Membership WG OPS aaa Authentication, Authorization and Accounting WG RTG vrrp Virtual Router Redundancy Protocol WG SEC enroll Credential and Provisioning WG TSV ieprep Internet Emergency Preparedness WG 1515-1545 Break (Refreshments provided) - Harbor Island Foyer 1545-1645 Afternoon Sessions III SEC sasl Simple Authentication and Security Layer WG TSV rohc Robust Header Compression WG 1700-1800 Afternoon Sessions IV APP ldapbis LDAP (v3) Revision WG TSV rohc Robust Header Compression WG WEDNESDAY, August 4, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP marid MTA Authorization Records in DNS WG INT eap Extensible Authentication Protocol WG OPS mboned MBONE Deployment WG SEC pkix Public Key Infrastructure WG TSV rddp Remote Direct Data Placement WG TSV sip Session Initiation Protocol WG 1130-1300 Break 1300-1500 Afternoon Sessions I IRTF asrg Anti Spam Working Group OPS capwap Control and Provisioning of Wireless Access Points WG OPS dnsop Domain Name System Operations WG SEC krbwg Kerberos WG TSV enum Telephone and Number Mapping WG TSV mmusic Multiparty Multimedia Session Control WG 1500-1530 Break (Refreshments provided) - Harbor Island Foyer 1530-1730 Afternoon Sessions II APP marid MTA Authorization Records in DNS WG GEN icar Improved Cross-Area Review WG INT ipv6 IP Version 6 WG OPS ipfix IP Flow Export WG RTG isis IS-IS for IP Internets WG SEC pki4ipsec Profiling Use of PKI in IPSEC WG TSV avt Audio/Video Transport WG 1730-1930 Break 1930-2200 Plenary - IETF Business Meeting - Grande Ballroom 2230 Late Night Session PGP Key Signing THURSDAY, August 5, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions INT hip Host Identity Protocol WG RTG mpls Multi Protocol Label Switching WG SEC msec Multicast Security WG TSV tsvwg Transport Area Working Group 1130-1300 Break 1300-1500 Afternoon Sessions I INT ipdvb IP over Digital Video Broadcast WG INT l3vpn Layer 3 Virtual Private Network WG SEC ltans Long-Term Archive and Notary WG TSV rserpool Reliable Server Pooling WG TSV sip Session Initiation Protocol WG 1500-1530 Break (Refreshments provided) - Harbor Island Foyer 1530-1730 Afternoon Sessions II APP webdav WWW Distributed Authoring and Versioning WG INT dnsext DNS Extensions WG OPS grow Global Routing Operations WG * SEC saag Open Security Area Directorate TSV sipping Session Initiation Protocol WG 1730-1930 Break 1930-2200 Plenary - IETF Planning Meeting - Grande Ballroom Friday, August 6, 2004 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP atompub Atom Publishing Format and Protocol PWG OPS netconf Network Configuration WG RTG rpsec Routing Protocol Security Requirements WG TSV sipping Session Initiation Protocol WG --Apple-Mail-12--337229252-- 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 i5FHVtRn073034; Tue, 15 Jun 2004 10:31: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 i5FHVtPj073033; Tue, 15 Jun 2004 10:31: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 i5FHVtkK073021 for ; Tue, 15 Jun 2004 10:31:55 -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 i5FHUpJL008113 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Jun 2004 10:30:54 -0700 In-Reply-To: <623CFC7CC97B09F1A272A227@ninevah.cyrusoft.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> <623CFC7CC97B09F1A272A227@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Tue, 15 Jun 2004 10:31:41 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You are correct in pointing out all of these issues with the WebDAV property model or its equivalents. We could argue how bad these problems are but that depends on the use cases. Does anybody have any other property privacy schemes to propose? Anybody want to try to summarize the pros/cons of the ideas so far, or how the schemes relate to the most likely email use cases? We need some more discussion in order to close on this issue. Lisa On Jun 15, 2004, at 10:24 AM, Cyrus Daboo wrote: > Hi Lisa, > > --On Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault > wrote: > >>> Registering properties as private or shared is a non-starter in my >>> opinion. Consider what a server would have to do in a case like that: >>> the server would have to have some internal table tracking the >>> private/shared status of each property (as defined in the registry) >>> so >>> that it can determine whether the current user can access that >>> property. It would be impossible to keep the server up to date with >>> the registry. >> >> You know, this is exactly the way webDAV properties work, so I guess >> there is a proof by existence. Servers don't in fact have to keep >> up-to-date with the standards defining protected properties. Let's >> say >> the "quota" property is registered in a standard, as a property that >> may >> be read by the owner of the file and is protected from being written >> by >> most users. Then, if a server does advertise support for the 'quota' >> draft, then clients can count on the property being protected as >> defined. >> If the server does not advertise support for the 'quota' draft, then >> clients can set a property with the name 'quota' but it's a dead >> property >> and has no protection and no side-effects. By definition in WebDAV, >> dead >> properties are subject to regular access control as a group, rather >> than >> special server-mediated protection rules depending on the specific >> property. >> >> To generalize, the property registration scheme works if there's some >> way >> for clients to tell which properties the server knows about and >> protects >> in some way. If the client knows that the server explicitly protects >> 'foo' as defined in the registry, then the client can go ahead and use >> 'foo'. The client could either ask the server "what are your rules >> for >> protecting 'foo'" or "what properties do you support and protect in >> some >> manner". > > What you are suggesting is that every new property defined has to have > an associated CAPABILITY response so that the client knows that the > server supports it - or (to avoid CAPABILITY bloat but adding another > round-trip) a new 'ANNOTATEPROPS' command that returns the list of > known properties. > > However, how would you deal with the case of a client vendor that > wants to implement their own client-specific properties which need > varying access control restrictions (some shared, some private)? > > Also note that deployment of new versions of IMAP servers (and to a > lesser extent clients) tends to take a long time. I don't know how > that compares with http/webdav servers, but I would guess admins are > more willing to do frequent updates of those. That means that clients > that want to use a newly defined property will be stuck waiting on > server deployment, rather than being able to use it immediately in an > interoperable way. > > -- > 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 i5FHOFhZ071382; Tue, 15 Jun 2004 10:24:15 -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 i5FHOFcq071381; Tue, 15 Jun 2004 10:24:15 -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 i5FHOFh0071373 for ; Tue, 15 Jun 2004 10:24:15 -0700 (PDT) (envelope-from daboo@cyrusoft.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 i5FHI11F014475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2004 13:18:01 -0400 Date: Tue, 15 Jun 2004 13:24:17 -0400 From: Cyrus Daboo To: Lisa Dusseault cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Issues on annotate-09 Message-ID: <623CFC7CC97B09F1A272A227@ninevah.cyrusoft.com> In-Reply-To: References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> 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 Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault wrote: >> Registering properties as private or shared is a non-starter in my >> opinion. Consider what a server would have to do in a case like that: >> the server would have to have some internal table tracking the >> private/shared status of each property (as defined in the registry) so >> that it can determine whether the current user can access that >> property. It would be impossible to keep the server up to date with >> the registry. > > You know, this is exactly the way webDAV properties work, so I guess > there is a proof by existence. Servers don't in fact have to keep > up-to-date with the standards defining protected properties. Let's say > the "quota" property is registered in a standard, as a property that may > be read by the owner of the file and is protected from being written by > most users. Then, if a server does advertise support for the 'quota' > draft, then clients can count on the property being protected as defined. > If the server does not advertise support for the 'quota' draft, then > clients can set a property with the name 'quota' but it's a dead property > and has no protection and no side-effects. By definition in WebDAV, dead > properties are subject to regular access control as a group, rather than > special server-mediated protection rules depending on the specific > property. > > To generalize, the property registration scheme works if there's some way > for clients to tell which properties the server knows about and protects > in some way. If the client knows that the server explicitly protects > 'foo' as defined in the registry, then the client can go ahead and use > 'foo'. The client could either ask the server "what are your rules for > protecting 'foo'" or "what properties do you support and protect in some > manner". What you are suggesting is that every new property defined has to have an associated CAPABILITY response so that the client knows that the server supports it - or (to avoid CAPABILITY bloat but adding another round-trip) a new 'ANNOTATEPROPS' command that returns the list of known properties. However, how would you deal with the case of a client vendor that wants to implement their own client-specific properties which need varying access control restrictions (some shared, some private)? Also note that deployment of new versions of IMAP servers (and to a lesser extent clients) tends to take a long time. I don't know how that compares with http/webdav servers, but I would guess admins are more willing to do frequent updates of those. That means that clients that want to use a newly defined property will be stuck waiting on server deployment, rather than being able to use it immediately in an interoperable way. -- 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 i5FGRhNE056038; Tue, 15 Jun 2004 09:27: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 i5FGRhTb056037; Tue, 15 Jun 2004 09:27:43 -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 i5FGRfXP056017 for ; Tue, 15 Jun 2004 09:27:41 -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 i5FGQaJL004077 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Jun 2004 09:26:38 -0700 In-Reply-To: References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Tue, 15 Jun 2004 09:27:29 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Registering properties as private or shared is a non-starter in my > opinion. Consider what a server would have to do in a case like that: > the server would have to have some internal table tracking the > private/shared status of each property (as defined in the registry) so > that it can determine whether the current user can access that > property. It would be impossible to keep the server up to date with > the registry. You know, this is exactly the way webDAV properties work, so I guess there is a proof by existence. Servers don't in fact have to keep up-to-date with the standards defining protected properties. Let's say the "quota" property is registered in a standard, as a property that may be read by the owner of the file and is protected from being written by most users. Then, if a server does advertise support for the 'quota' draft, then clients can count on the property being protected as defined. If the server does not advertise support for the 'quota' draft, then clients can set a property with the name 'quota' but it's a dead property and has no protection and no side-effects. By definition in WebDAV, dead properties are subject to regular access control as a group, rather than special server-mediated protection rules depending on the specific property. To generalize, the property registration scheme works if there's some way for clients to tell which properties the server knows about and protects in some way. If the client knows that the server explicitly protects 'foo' as defined in the registry, then the client can go ahead and use 'foo'. The client could either ask the server "what are your rules for protecting 'foo'" or "what properties do you support and protect in some manner". 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 i58CZWk4087510; Tue, 8 Jun 2004 05:35:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i58CZWr5087509; Tue, 8 Jun 2004 05:35:32 -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 i58CZUhT087500 for ; Tue, 8 Jun 2004 05:35:32 -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.0) with ESMTP id i58CZTS8010704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 8 Jun 2004 05:35:29 -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 i58CZTT0068505 for ; Tue, 8 Jun 2004 05:35:29 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> To: IMAP Extensions WG From: Philip Guenther Subject: LISTEXT draft Date: Tue, 08 Jun 2004 05:35:29 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please forgive me the disorganization of this note, I've having a hard time finding a good presentation for the thoughts and questions in it. I came up with these questions while trying to figure out what it would take to implement LISTEXT in the IMAP server I work on. Having pondered these questions, I understand less than when I started. For any possible mailbox name that matches a LIST pattern, there are eight possible situations to reflect the three conditions: - does the name exist as a mailbox - does the name match the selection criteria (LISTEXT options) - does the name have at least one child mailbox which exists and matches the selection criteria, but *doesn't* match the pattern has selected child returned exists selected that doesn't match LISTEXT flags --------------------------------------------------------------------------- no no no no response yes no no no response no yes no (\NonExistent) yes yes no () no no yes (???) <- 1 yes no yes (\PlaceHolder) no yes yes (\NonExistent) yes yes yes () <- 2 Question #1: What should be returned in case #1 (line 5) above? For a concrete example, consider a Cyrus-like server on which the mailbox "Vegis/Squash" was created and subscribed to, and then the "Vegis" mailbox was deleted, removing it completely and _not_ leaving it as a \NoSelect mailbox; should the command tag LIST (SUBSCRIBED) "" % return a LIST response for "Vegis", and if so, with what flags? Question #2: In the past, it has been argued that LSUB should return two responses for a given name, one with \NoSelect and one without, if the name was both subscribed and had subscribed children that did not match the pattern, i.e., line 8 in the table above. Others have disagreed with this reading of RFC 3501. Can LISTEXT please state how a server should respond in that situation? That is, should the server send a response with the \PlaceHolder flag and one without, or just one response? (Maintainers of IMAP clients should speak up here...) Question #3: The LISTEXT syntax permits an empty options list, e.g., tag LIST () "" % Does that mean the "selection criteria" is "does the mailbox exist"? Should the cited command return a LIST response for "Vegis", and if so, with what flags? Question #4: Consider the last four lines of the table at top. Should any of the responses change if the mailbox *also* has a selected child that *does* match the pattern? Question #5: Do any of your answers change if the pattern is "Veg%" instead of "%"? What if the pattern is "Vegis"? Philip Guenther guenther@sendmail.com 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 i57KeGEm000254; Mon, 7 Jun 2004 13:40:16 -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 i57KeGc4000253; Mon, 7 Jun 2004 13:40:16 -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 i57KeFPx000247 for ; Mon, 7 Jun 2004 13:40:15 -0700 (PDT) (envelope-from daboo@cyrusoft.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 i57KZC1F030819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 16:35:15 -0400 Date: Mon, 07 Jun 2004 16:40:16 -0400 From: Cyrus Daboo To: Lisa Dusseault , IMAP Extensions WG Subject: Re: Annotate draft comments Message-ID: 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 Wednesday, June 2, 2004 1:58 PM -0700 Lisa Dusseault wrote: > > > Discussion kind of died down on my comments on the annotate draft. Does > anybody see a consensus on the private/public stuff, which generated the > most discussion? (this is also an invitation for other people to chime > in who haven't already). Do the authors plan another draft? > > Lisa > Here is the list of issues I have since the last draft came out: 1) Private/shared debate: this issue is still open. I think it would be useful if those proposing a change could clarify their positions given the recent debate. 2) Language attribute: I agree this should be present for any value that represents text that can be displayed to the user. There is no need for it for numeric or enumerated (boolean) values such as flags. I will add text for that. 3) Missing IANA registrations: I will add those. 4) Clarification of /comment and /altsubject. I will add those. However, I am somewhat unsure of exactly what requirements /altsubject places on clients - so if anyone else can suggest those that would be handy. 5) Security considerations inadequate: perhaps someone could suggest better text for that or point out other areas in ANNOTATE that the current text does not mention. I would like to wait for the private/shared issue to be resolved before putting out another draft, but if we think that will take a while, I will go ahead and do a new draft with the other changes soon. -- 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 i57JgolB094027; Mon, 7 Jun 2004 12:42: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 i57Jgot2094026; Mon, 7 Jun 2004 12:42:50 -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 i57JgnJX094018 for ; Mon, 7 Jun 2004 12:42:49 -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 PAA11167; Mon, 7 Jun 2004 15:42:51 -0400 (EDT) Message-Id: <200406071942.PAA11167@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-i18n-03.txt Date: Mon, 07 Jun 2004 15:42:51 -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 : Internet Message Access Protocol Internationalization Author(s) : C. Newman, A. Gulbrandsen Filename : draft-ietf-imapext-i18n-03.txt Pages : 17 Date : 2004-6-7 Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-03.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-i18n-03.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-i18n-03.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-6-7154428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154428.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 i55909A1045154; Sat, 5 Jun 2004 02:00: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 i559091w045152; Sat, 5 Jun 2004 02:00:09 -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 i5590890045127 for ; Sat, 5 Jun 2004 02:00:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust107.tnt105.lnd4.gbr.da.uu.net [213.116.58.107]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 5 Jun 2004 09:59:56 +0100 Message-ID: <40C18AED.2060905@isode.com> Date: Sat, 05 Jun 2004 09:57:17 +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: Annotate draft comments 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: > Discussion kind of died down on my comments on the annotate draft. We need to collect all issues in one place. > Does anybody see a consensus on the private/public stuff, which > generated the most discussion? (this is also an invitation for other > people to chime in who haven't already). I think we've agreed to add more description about annotations like altsubject. I think there is no consensus to change existing private/public annotation model, as described by Cyrus recently. > Do the authors plan another draft? > > Lisa 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 i53G9ubt087788; Thu, 3 Jun 2004 09:09: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 i53G9uC0087786; Thu, 3 Jun 2004 09:09:56 -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 i53G9tiB087775 for ; Thu, 3 Jun 2004 09:09: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 i53G94JM010668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 3 Jun 2004 09:09:05 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Annotate draft comments Date: Wed, 2 Jun 2004 13:58:43 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Discussion kind of died down on my comments on the annotate draft. Does anybody see a consensus on the private/public stuff, which generated the most discussion? (this is also an invitation for other people to chime in who haven't already). Do the authors plan another draft? 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 i51FOjmU070976; Tue, 1 Jun 2004 08:24: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 i51FOjiC070975; Tue, 1 Jun 2004 08:24:45 -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 i51FOjS1070963 for ; Tue, 1 Jun 2004 08:24:45 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout5.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i51FOVMY007116; Tue, 1 Jun 2004 08:24:36 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i51FOV63021378; Tue, 1 Jun 2004 08:24:31 -0700 Date: Tue, 1 Jun 2004 08:24:31 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: ietf-imapext@imc.org Subject: Re: imapext-i18n draft In-Reply-To: Message-ID: References: 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, 1 Jun 2004, Arnt Gulbrandsen wrote: > If noone screams and stamps their feet, section 4.5 will die. Last warning > now. Yes! Death to 4.5. -- 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 i51EjiPD060496; Tue, 1 Jun 2004 07:45:44 -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 i51EjiLV060495; Tue, 1 Jun 2004 07:45:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i51Ejh30060454 for ; Tue, 1 Jun 2004 07:45:44 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: imapext-i18n draft Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 1 Jun 2004 16:48:03 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, there's been a new draft there for a few days, incorporating suggestions and addressing concerns from various people. If noone screams and stamps their feet, section 4.5 will die. Last warning now. I'd like to know whether you all think the example in section 4.3 is sensible. I like it and it seems in tune with the (currently expired) comparator draft. I can add some more examples if anyone thinks it's called for. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TMMHlk030103; Tue, 29 Jun 2004 15:22: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 i5TMMHf7030102; Tue, 29 Jun 2004 15:22:17 -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 i5TMMGqM030091 for ; Tue, 29 Jun 2004 15:22:17 -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 i5TMMFrR003482 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Jun 2004 15:22:15 -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 i5TMMEYM058882; Tue, 29 Jun 2004 15:22:14 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406292222.i5TMMEYM058882@lab.smi.sendmail.com> To: Rob Siemborski Cc: Alexey Melnikov , IMAP Extensions WG From: Philip Guenther Subject: Re: LISTEXT draft In-reply-to: References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> Date: Tue, 29 Jun 2004 15:22:14 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Sun, 27 Jun 2004, Philip Guenther wrote: ... >> Of course, all returned mailboxes must match the pattern, possibly >> modified by the reference argument, regardless of whether the named >> mailbox is selected or a child mailbox is selected. > >Why? IMAP allows for unsolicited LIST responses at any time, just like >any other IMAP response. True enough; perhaps I should have said that a returned mailbox that doesn't match the pattern is effectively unaffiliated with the LIST command that preceded it. Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the subscribed mailboxes as such, because it's otherwise ambiguous whether any given LIST response is of a subscribed mailbox: the server could just be sending random LIST responses for unsubscribed mailboxes because it felt like it. Should it mark them with a "list flag" or a "list extended item"? * LIST (\IsSubscribed) "/" foo or * LIST () "/" foo ((SUBSCRIBED ())) ? Hmm, this may also tangle with REMOTE, depending on how server treats a remote mailbox when the REMOTE option isn't used. Should a server act like the mailbox doesn't exist, even to the point of sending \NonExistent, if it's remote but the REMOTE option wasn't used? If so, a LIST (REMOTE) could legally result in two different responses for the same mailbox, say: * LIST () "/" foo ((REMOTE "imap:blahblah")) * LIST (\NonExistent) "/" foo that second response being unrelated to the LIST (REMOTE), just something the server felt like sending. This complicates any future effort to have server send LIST responses to indicate changes in the mailbox hierarchy: you can't just indicate that a mailbox is no longer there by sending a \NonExistent response, as that's effectively a no-op for remote mailboxes. The server would have to use something like: * LIST (\NonExistent) "/" foo ((REMOTE "")) to mean "it's really gone and doesn't even exist as a remote mailbox" 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 i5TKhtLg024355; Tue, 29 Jun 2004 13:43: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 i5TKhtVK024354; Tue, 29 Jun 2004 13:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TKhtSp024347 for ; Tue, 29 Jun 2004 13:43:55 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKhp0w028697 for ; Tue, 29 Jun 2004 13:43:56 -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.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKhokm001770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 Jun 2004 13:43:51 -0700 X-Return-Path: X-Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Tue, 29 Jun 2004 13:23:48 -0700 (PDT) X-Return-Path: X-Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.140]) by ndcms.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKNmT0001301; Tue, 29 Jun 2004 13:23:48 -0700 X-Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5TKNitF012169; Tue, 29 Jun 2004 13:23:46 -0700 X-Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfOLP-0005T8-W0; Tue, 29 Jun 2004 15:32:39 -0400 X-Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfOH0-0004aK-A3 for i-d-announce@megatron.ietf.org; Tue, 29 Jun 2004 15:28:06 -0400 X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11344 for ; Tue, 29 Jun 2004 15:28:04 -0400 (EDT) Message-Id: <200406291928.PAA11344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 29 Jun 2004 15:28:04 -0400 Subject: I-D ACTION:draft-crispin-imap-urlauth-09.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-Uwash-Spam: Gauge=XII, Probability=12%, Report='MIME_BOUND_NEXTPART 1.085, __SANE_MSGID 0, __MIME_VERSION 0, __NEXTPART_ALL 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __TO_MALFORMED_2 0, NO_REAL_NAME 0.000, __X_BEENTHERE 0, __DCC_BODY 0, __DCC_FUZ1 0, __DCC_FUZ2 0, DCC_BULK_LOW 0, __HAS_MSGID 0' 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. Title : Internet Message Access Protocol (IMAP) - URLAUTH Extension Author(s) : M. Crispin, C. Newman Filename : draft-crispin-imap-urlauth-09.txt Pages : 8 Date : 2004-6-29 This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can create 'signed' URLs which can be used to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of 'URLAUTH'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-09.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-crispin-imap-urlauth-09.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-crispin-imap-urlauth-09.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-6-29150052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imap-urlauth-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imap-urlauth-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150052.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 i5TJAhVs016246; Tue, 29 Jun 2004 12:10: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 i5TJAhT8016245; Tue, 29 Jun 2004 12:10:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJAgLX016235 for ; Tue, 29 Jun 2004 12:10:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i5TJAe0n001385; Tue, 29 Jun 2004 15:10:40 -0400 Date: Tue, 29 Jun 2004 15:10:40 -0400 (EDT) From: Rob Siemborski To: Philip Guenther cc: Alexey Melnikov , IMAP Extensions WG , Mark Crispin , Ken Murchison Subject: Re: LISTEXT draft In-Reply-To: <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> Message-ID: References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 27 Jun 2004, Philip Guenther wrote: > Alexey Melnikov writes: > ... >> 2). Clarify that there are only two reasons for including a mailbox in >> the responses to the LIST command: the mailbox itself may be selected >> and matched and/or it may have at least one child mailbox that is >> selected but not matched. If neither of those is true then there's no >> reason to include a response for the mailbox. > > Of course, all returned mailboxes must match the pattern, possibly > modified by the reference argument, regardless of whether the named > mailbox is selected or a child mailbox is selected. Why? IMAP allows for unsolicited LIST responses at any time, just like any other IMAP response. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5S1a8Zi001160; Sun, 27 Jun 2004 18:36:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5S1a8VT001159; Sun, 27 Jun 2004 18:36:08 -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 i5S1a360001144 for ; Sun, 27 Jun 2004 18:36:05 -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 i5S1a2Kx020656 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 27 Jun 2004 18:36:02 -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 i5S1a1Tw093890; Sun, 27 Jun 2004 18:36:01 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406280136.i5S1a1Tw093890@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG , Mark Crispin , Ken Murchison From: Philip Guenther Subject: Re: LISTEXT draft In-reply-to: <40DDF46F.30309@isode.com> References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40DDF46F.30309@isode.com> Date: Sun, 27 Jun 2004 18:36:01 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >2). Clarify that there are only two reasons for including a mailbox in >the responses to the LIST command: the mailbox itself may be selected >and matched and/or it may have at least one child mailbox that is >selected but not matched. If neither of those is true then there's no >reason to include a response for the mailbox. Of course, all returned mailboxes must match the pattern, possibly modified by the reference argument, regardless of whether the named mailbox is selected or a child mailbox is selected. ... >Philip originally suggested to use the CHILDREN selection criterion >should be used instead of SUBMAILBOXES. I am not so sure about this. >Suggestions are welcome. I have no strong feelings about what name should be used for this; it merely started from my pondering the differences between \PlaceHolder and \HasChildren and the observation that, unlike \HasChildren, \PlaceHolder had a clear definition in the presence of other selection criteria (in particular, SUBSCRIBED). ... >(unspecified whether it has any selected and matched children). This is to leave it up to the implementation what happens if the client specifies a pattern that can match a mailbox and some, but not all of its child mailboxes: an implementation could ignore the matched children when deciding whether the \PlaceHolder or \HasSubmailboxes flag is needed or it could decide which flag to return based just on whether any children were matched. I wouldn't expect this leeway to be a problem for clients for two reasons: 1) it seems unlikely that a client would use such a pattern normally, and 2) there's only an ambiguity if at last one child mailbox was also returned, which probably resolves the real question that the client wanted answered. For example, consider a hierarchy using slash as the delimiter with the following mailboxes: foo2 foo2/bar1 foo2/bar2 quux2/bar2 If the client sends the command A01 LIST (SUBMAILBOXES) "" "*2" then the server MUST include * LIST () "/" "foo2/bar2" * LIST () "/" "quux2/bar2" and exactly one of * LIST () "/" "foo2" * LIST (\HasSubmailboxes) "/" "foo2" in its response. It MAY also include * LIST (\NonExistent \PlaceHolder) "/" "quux2" >After all those changes/clarifications, the table shown by Philip becomes: > > has selected child returned >exists selected that doesn't match pattern LISTEXT flags >--------------------------------------------------------------------------- > no no no no response >yes no no no response > no yes no (\NonExistent) >yes yes no () > no no yes (\NonExistent \PlaceHolder) >yes no yes (\PlaceHolder) > no yes yes (\NonExistent >\HasSubmailboxes) >yes yes yes (\HasSubmailboxes) That third column should just be titled "has selected child". (I'm obviously in favor of this change) 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 i5RMcBjn087016; Sun, 27 Jun 2004 15:38: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 i5RMcBeh087015; Sun, 27 Jun 2004 15:38:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RMc9Fm087008 for ; Sun, 27 Jun 2004 15:38:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust235.tnt27.lnd4.gbr.da.uu.net [62.188.154.235]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 27 Jun 2004 23:39:05 +0100 Message-ID: <40DDF46F.30309@isode.com> Date: Sat, 26 Jun 2004 23:10:55 +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 CC: Philip Guenther , Mark Crispin , Ken Murchison Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> In-Reply-To: <40D75322.8050409@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Philip Guenther wrote: > >> [...] >> For any possible mailbox name that matches a LIST pattern, there >> are eight possible situations to reflect the three conditions: >> - does the name exist as a mailbox >> - does the name match the selection criteria (LISTEXT options) >> - does the name have at least one child mailbox which exists and >> matches the selection criteria, but *doesn't* match the pattern >> >> has selected child returned >> exists selected that doesn't match pat. LISTEXT flags >> --------------------------------------------------------------------------- >> >> no no no no response >> yes no no no response >> no yes no (\NonExistent) >> yes yes no () >> no no yes (???) <- 1 >> yes no yes (\PlaceHolder) >> no yes yes (\NonExistent) >> yes yes yes () <- 2 >> >> >> Question #1: >> What should be returned in case #1 (line 5) above? For a concrete >> example, consider a Cyrus-like server on which the mailbox >> "Vegis/Squash" was created and subscribed to, and then the "Vegis" >> mailbox was deleted, removing it completely and _not_ leaving it >> as a \NoSelect mailbox; should the command >> tag LIST (SUBSCRIBED) "" % >> >> return a LIST response for "Vegis", >> >> and if so, with what flags? >> > Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be > returned, as there are submailboxes that conform to the selection > criteria, but doesn't match the pattern. It also seems that > \NonExistent should be returned as well, as the mailbox doesn't exist. > (From the point of view of a client writer: the client need to know > which mailboxes should not be selected). > However, the current definition for \NonExistent is: > "\NonExistent", that indicates that a mailbox is subscribed to, but > does not actually exist. > > I am wondering if this definition should be changed to be more > generic, for example: > > "\NonExistent", that indicates that a mailbox satisfy the selection > criterion, but does not actually exist. > > But this might be too open ended. Alternatively, the draft can spell > out this case specifically and show an example. > What other people think? Philip has found few underspecified cases. After discussing this off list with Philip I would propose the following changes to the LISTEXT document: 1). Clarify that for any mailbox name only a single LIST response must be returned. 2). Clarify that there are only two reasons for including a mailbox in the responses to the LIST command: the mailbox itself may be selected and matched and/or it may have at least one child mailbox that is selected but not matched. If neither of those is true then there's no reason to include a response for the mailbox. 3). Add a new selection criterion (e.g. SUBMAILBOXES) that requests that \PlaceHolder MUST be returned and MUST be precise. In the absence of the criterion \PlaceHolder MAY be returned and it is not necessary precise. (Clients need to handle the case when \PlaceHolder is returned and there are no submailboxes, as they were deleted/renamed after the LIST response was sent, but before the client had a chance to list/access them). Philip originally suggested to use the CHILDREN selection criterion should be used instead of SUBMAILBOXES. I am not so sure about this. Suggestions are welcome. 4). Clarify the meaning of \PlaceHolder flag: \PlaceHolder mailbox is *not* selected but it has selected children (unspecified whether any, all, or none are matched) Add a new mutually exclusive flag \HasSubmailboxes: \HasSubmailboxes mailbox is selected *and* has selected children (unspecified whether any, all or none are matched) Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox matches the selection criterion, but doesn't have any selected but unmatched children (unspecified whether it has any selected and matched children). 5). Define \NonExistent as follows: "\NonExistent", that indicates that a mailbox satisfy the selection criterion, but does not actually exist. 6). Add more examples, clarify edge cases. ========= After all those changes/clarifications, the table shown by Philip becomes: has selected child returned exists selected that doesn't match pattern LISTEXT flags --------------------------------------------------------------------------- no no no no response yes no no no response no yes no (\NonExistent) yes yes no () no no yes (\NonExistent \PlaceHolder) yes no yes (\PlaceHolder) no yes yes (\NonExistent \HasSubmailboxes) yes yes yes (\HasSubmailboxes) 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 i5O7RIQR051762; Thu, 24 Jun 2004 00:27: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 i5O7RIgD051761; Thu, 24 Jun 2004 00:27: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 i5O7RGD5051740 for ; Thu, 24 Jun 2004 00:27: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 i5O7RGV3032659 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 24 Jun 2004 00:27:16 -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 i5O7RFxl081070; Thu, 24 Jun 2004 00:27:16 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406240727.i5O7RFxl081070@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: LISTEXT draft In-reply-to: <40D84CBF.3060709@isode.com> References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> <40D84CBF.3060709@isode.com> Date: Thu, 24 Jun 2004 00:27:15 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >Alexey Melnikov wrote: > >> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be >> returned, as there are submailboxes that conform to the selection >> criteria, but doesn't match the pattern. [...] > >On a related note: I was wondering if it is worth adding a selection >criterion saying that \PlaceHolder MUST be returned and MUST be precise? I support this idea. Indeed, an accurate version of the \PlaceHolder described in the current draft could be construed as an improved version of \HasChildren, as it actually has a well defined meaning when other selection criteria (such as SUBSCRIBED) are used. Looking at this another way: is there any objection to the idea that a server MUST support a 100% accurate version** of \HasChildren to claim LISTEXT compliancy? Philip Guenther ** Not necessarily under the name \HasChildren or exactly as described in RFC 3348, but the same basic idea of "some mailbox under this one has a specified property" 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 i5MFE6Nn047073; Tue, 22 Jun 2004 08:14: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 i5MFE6x6047072; Tue, 22 Jun 2004 08:14:06 -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 i5MFE5p1047062 for ; Tue, 22 Jun 2004 08:14:05 -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, 22 Jun 2004 16:14:42 +0100 Message-ID: <40D84CBF.3060709@isode.com> Date: Tue, 22 Jun 2004 16:14:07 +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 CC: Philip Guenther Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> <40D75322.8050409@isode.com> In-Reply-To: <40D75322.8050409@isode.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: Alexey Melnikov wrote: > Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be > returned, as there are submailboxes that conform to the selection > criteria, but doesn't match the pattern. [...] On a related note: I was wondering if it is worth adding a selection criterion saying that \PlaceHolder MUST be returned and MUST be precise? 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 i5MCwPc7018798; Tue, 22 Jun 2004 05:58:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MCwPYd018796; Tue, 22 Jun 2004 05:58:25 -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 i5MCwKqt018774 for ; Tue, 22 Jun 2004 05:58:20 -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, 22 Jun 2004 13:58:54 +0100 Message-ID: <40D82CEB.6020803@isode.com> Date: Tue, 22 Jun 2004 13:58:19 +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: Arnt Gulbrandsen CC: IMAP Extensions WG Subject: Re: Changes to LISTEXT draft References: <40D75F2C.6040905@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> I've updated the LISTEXT draft to use ACAP vendor registry. I will be >> sending a new revision shortly. There is also the following text in >> the draft now: >> >> Standard LISTEXT option/extended data item names are case >> insensitive. Vendor specific LISTEXT option/extended data item >> names are case insensitive, if the vendor prefix is omitted. The >> vendor prefix itself is not case-sensitive, as it might contain >> non-ASCII characters. >> >> Does this text make any sense? > > A little bit too complex, perhaps? If the client's required to to do > case folding for the word föö, surely it can manage to fold the vendor > name möö as well. > >> What should be done for vendor prefixes that are completely comprised >> of ASCII characters? Should IANA be directed to prevent registrations >> that are completely in ASCII and only differ in case? > > The latter seems to offer a good way out. The only procedural problem with this is that ACAP vendor registry is defined by the ACAP RFC, we don't want to revise it ;-). 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 i5MC5aic008419; Tue, 22 Jun 2004 05:05:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MC5aAs008418; Tue, 22 Jun 2004 05:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MC5TwI008387 for ; Tue, 22 Jun 2004 05:05:33 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id B5E221BDE7F; Tue, 22 Jun 2004 14:05:29 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 2F0D51BDE7B; Tue, 22 Jun 2004 14:05:27 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: Alexey Melnikov Subject: Re: Changes to LISTEXT draft Cc: IMAP Extensions WG References: <40D75F2C.6040905@isode.com> In-Reply-To: <40D75F2C.6040905@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 Date: Tue, 22 Jun 2004 14:09:24 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5MC5ZwI008412 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > I've updated the LISTEXT draft to use ACAP vendor registry. I will be > sending a new revision shortly. There is also the following text in > the draft now: > > Standard LISTEXT option/extended data item names are case > insensitive. Vendor specific LISTEXT option/extended data item > names are case insensitive, if the vendor prefix is omitted. The > vendor prefix itself is not case-sensitive, as it might contain > non-ASCII characters. > > Does this text make any sense? A little bit too complex, perhaps? If the client's required to to do case folding for the word föö, surely it can manage to fold the vendor name möö as well. > What should be done for vendor prefixes that are completely comprised > of ASCII characters? Should IANA be directed to prevent registrations > that are completely in ASCII and only differ in case? The latter seems to offer a good way out. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNQbow094239; Mon, 21 Jun 2004 16:26:37 -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 i5LNQbZv094238; Mon, 21 Jun 2004 16:26:37 -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 i5LNQZ8v094224 for ; Mon, 21 Jun 2004 16:26:36 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:27:08 +0100 Message-ID: <40D75F2C.6040905@isode.com> Date: Mon, 21 Jun 2004 23:20:28 +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: Changes to LISTEXT draft 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: I've updated the LISTEXT draft to use ACAP vendor registry. I will be sending a new revision shortly. There is also the following text in the draft now: Standard LISTEXT option/extended data item names are case insensitive. Vendor specific LISTEXT option/extended data item names are case insensitive, if the vendor prefix is omitted. The vendor prefix itself is not case-sensitive, as it might contain non-ASCII characters. Does this text make any sense? What should be done for vendor prefixes that are completely comprised of ASCII characters? Should IANA be directed to prevent registrations that are completely in ASCII and only differ in case? 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 i5LNN1s9093202; Mon, 21 Jun 2004 16:23:01 -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 i5LNN1On093201; Mon, 21 Jun 2004 16:23:01 -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 i5LNMvfK093176 for ; Mon, 21 Jun 2004 16:22:59 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:23:04 +0100 Message-ID: <40D75322.8050409@isode.com> Date: Mon, 21 Jun 2004 22:29: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 MIME-Version: 1.0 To: Philip Guenther CC: IMAP Extensions WG Subject: Re: LISTEXT draft References: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> In-Reply-To: <200406081235.i58CZTT0068505@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: >Please forgive me the disorganization of this note, I've having a >hard time finding a good presentation for the thoughts and questions >in it. I came up with these questions while trying to figure out >what it would take to implement LISTEXT in the IMAP server I work >on. Having pondered these questions, I understand less than when >I started. > > >For any possible mailbox name that matches a LIST pattern, there >are eight possible situations to reflect the three conditions: >- does the name exist as a mailbox >- does the name match the selection criteria (LISTEXT options) >- does the name have at least one child mailbox which exists and > matches the selection criteria, but *doesn't* match the pattern > > has selected child returned >exists selected that doesn't match pat. LISTEXT flags >--------------------------------------------------------------------------- > no no no no response > yes no no no response > no yes no (\NonExistent) > yes yes no () > no no yes (???) <- 1 > yes no yes (\PlaceHolder) > no yes yes (\NonExistent) > yes yes yes () <- 2 > > >Question #1: > What should be returned in case #1 (line 5) above? For a concrete >example, consider a Cyrus-like server on which the mailbox >"Vegis/Squash" was created and subscribed to, and then the "Vegis" >mailbox was deleted, removing it completely and _not_ leaving it >as a \NoSelect mailbox; should the command > tag LIST (SUBSCRIBED) "" % > >return a LIST response for "Vegis", > >and if so, with what flags? > Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be returned, as there are submailboxes that conform to the selection criteria, but doesn't match the pattern. It also seems that \NonExistent should be returned as well, as the mailbox doesn't exist. (From the point of view of a client writer: the client need to know which mailboxes should not be selected). However, the current definition for \NonExistent is: "\NonExistent", that indicates that a mailbox is subscribed to, but does not actually exist. I am wondering if this definition should be changed to be more generic, for example: "\NonExistent", that indicates that a mailbox satisfy the selection criterion, but does not actually exist. But this might be too open ended. Alternatively, the draft can spell out this case specifically and show an example. What other people think? 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 i5LNMAPj093065; Mon, 21 Jun 2004 16:22: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 i5LNMAqE093064; Mon, 21 Jun 2004 16:22:10 -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 i5LNM4SI093035 for ; Mon, 21 Jun 2004 16:22:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:22:00 +0100 Message-ID: <40D74F3F.5010604@isode.com> Date: Mon, 21 Jun 2004 22:12: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 To: Lisa Dusseault CC: Ken Murchison , IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> <40A12004.3060401@isode.com> <8D59182D-C2EB-11D8-A549-000A95B2BB72@osafoundation.org> In-Reply-To: <8D59182D-C2EB-11D8-A549-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: > Going through older mail now that I've reviewed LISTEXT myself, it > seems there a couple issues around what status LISTEXT has with > respect to two RFCs. Please give your input if you've got any > background with these RFCs ... and let the group know to what extent > these RFCs are implemented, and whether the implementors intend to go > ahead with LISTEXT. > >>> or does LISTEXT automatically give you support for the functionality >>> in RFC 2193 and RFC 3348? >> >> LISTEXT gives the complete functionality of RFC 3348. However LIST >> (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC >> 2193 is not affected. > > We probably need to be pretty clear about that role, in LISTEXT, > before going forward. Is there general agreement about how LISTEXT > relates to RFC2193? I proposed earlier to publish a revision of RFC 2193 shortly after publishing LISTEXT. I also wanted to add REFERRAL list data item to LIST response, but I don't feel there is any consensus on this. I intend to either publish a separate draft for REFERRAL, or fold it into revision of RFC 2193. If anybody has any comments on this plan, please speak up now. >>> I don't know, it seemed like common sense to me. Is LISTEXT going >>> to deprecate RFC 3348? >> >> I think it effectively does. But does WG wants to officially state >> that in LISTEXT? > > To me it looks like LISTEXT should deprecate RFC3348, but we > definitely need to hear from people with a deeper background. As far as I know everybody agrees with this decision. If anybody want to speak against it, please give your arguments 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 i5KIulT3051522; Sun, 20 Jun 2004 11:56: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 i5KIul7E051521; Sun, 20 Jun 2004 11:56:47 -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 i5KIujeP051500 for ; Sun, 20 Jun 2004 11:56:45 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org 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 i5KItcJL009347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 20 Jun 2004 11:55:41 -0700 In-Reply-To: <40A12004.3060401@isode.com> References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> <40A12004.3060401@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D59182D-C2EB-11D8-A549-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Ken Murchison , IMAP Extensions WG From: Lisa Dusseault Subject: Re: Collected issues with LISTEXT Date: Sun, 20 Jun 2004 11:56:35 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Going through older mail now that I've reviewed LISTEXT myself, it seems there a couple issues around what status LISTEXT has with respect to two RFCs. Please give your input if you've got any background with these RFCs ... and let the group know to what extent these RFCs are implemented, and whether the implementors intend to go ahead with LISTEXT. >> or does LISTEXT automatically give you support for the functionality >> in RFC 2193 and RFC 3348? > > LISTEXT gives the complete functionality of RFC 3348. However LIST > (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 > is not affected. We probably need to be pretty clear about that role, in LISTEXT, before going forward. Is there general agreement about how LISTEXT relates to RFC2193? >> >> I don't know, it seemed like common sense to me. Is LISTEXT going to >> deprecate RFC 3348? > > I think it effectively does. But does WG wants to officially state > that in LISTEXT? To me it looks like LISTEXT should deprecate RFC3348, but we definitely need to hear from people with a deeper background. 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 i5IN3nFm094652; Fri, 18 Jun 2004 16:03: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 i5IN3ncH094651; Fri, 18 Jun 2004 16:03:49 -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 i5IN3mKp094633 for ; Fri, 18 Jun 2004 16:03:49 -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 i5IN2kJL023703 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 18 Jun 2004 16:02:49 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: LISTEXT spec Date: Fri, 18 Jun 2004 16:03:37 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've reviewed the LISTEXT spec & I have only one issue that the authors are probably already aware of -- that the definition of PlaceHolder needs to be finished. Otherwise, if the authors are ready for last call, I'll make that happen. 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 i5IBuC0O070265; Fri, 18 Jun 2004 04:56:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IBuC0q070264; Fri, 18 Jun 2004 04:56:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IBuB5a070255 for ; Fri, 18 Jun 2004 04:56:11 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 979851A71C; Fri, 18 Jun 2004 13:56:12 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 7EB611A6FF; Fri, 18 Jun 2004 13:56:09 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: Re: draft-ietf-imapext-i18n-03.txt Cc: Ned Freed References: In-Reply-To: Date: Fri, 18 Jun 2004 13:57:26 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen writes: > Chris Freeman's I got that name wrong, didn't I? The sun must have baked my brain. Sorry. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IBsZ01069892; Fri, 18 Jun 2004 04:54: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 i5IBsZfS069891; Fri, 18 Jun 2004 04:54:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IBsY7w069881 for ; Fri, 18 Jun 2004 04:54:34 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 4D1721A71C; Fri, 18 Jun 2004 13:54:35 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 2CAB31A6FF; Fri, 18 Jun 2004 13:54:32 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: draft-ietf-imapext-i18n-03.txt Cc: Ned Freed Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 18 Jun 2004 13:55:49 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think I worked through everyone's comments. If there's something I missed or you have new comments, please let me know. Otherwise I'll just lounge in the sun, waiting for Ned Freed (cc:) to update Chris Freeman's comparator draft. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HH0har079555; Thu, 17 Jun 2004 10:00: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 i5HH0hNd079554; Thu, 17 Jun 2004 10:00:43 -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 i5HH0hpH079540 for ; Thu, 17 Jun 2004 10:00:43 -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 i5HGxgJL000347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 17 Jun 2004 09:59:42 -0700 Mime-Version: 1.0 (Apple Message framework v613) To: IMAP Extensions WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-12--337229252 From: Lisa Dusseault Subject: Fwd: 60th IETF Meeting - DRAFT Agenda Date: Thu, 17 Jun 2004 10:00:36 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-12--337229252 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Note that IMAPEXT is meeting the afternoon of Monday, Aug 2. We should have a new annotate draft by then, discuss private/shared issues if they're still open, and hopefully start some discussion of LISTEXT by then ( I still owe a review but others ought to review as well). Lisa Begin forwarded message: > From: agenda@ietf.org > Date: June 16, 2004 2:49:27 PM PDT > To: wgchairs@ietf.org, iesg@ietf.org > Cc: mbeaulie@foretec.com > Subject: 60th IETF Meeting - DRAFT Agenda > > > Draft Agenda of the Sixtieth IETF > August 1 - 6, 2004 > As of 6/16/2004 > > SUNDAY, August 1, 2004 > 1000-1700 IEPG Meeting - Marina 6 > 1200-1900 Registration - Harbor Island Foyer > 1300-1400 Newcomer's Training - Grande Ballroom A > 1300-1500 Editor's Training - Marina 5 > 1300-1500 Intro WG Chairs Training - > 1500-1700 Security Tutorial - Grande Ballroom A > 1700-1900 Welcome Reception - Grande Ballroom B/C > > MONDAY, August 2, 2004 > 0800-2000 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP apparea Applications Open Area Meeting > GEN newtrk New IETF Standards Track Discussion WG > INT dnsext DNS Extensions WG > OPS multi6 Site Multihoming for IPv6 WG > OPS hubmib Ethernet Interfaces and Hub MIB WG > RTG manet Mobile Ad-hoc Networks WG > TSV xcon Centralized Conference WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > APP imapext Internet Message Access Protocol Extension WG > INT rbridge IP Subnets in Topologies Which are Flexible, Universal > and Nice BOF > IRTF mobopts IP Mobility Optimizations > RTG forces Forwarding and Control Element Separation WG > SEC perm Protected Entertainment Rights Management BOF > TSV nsis Next Steps in Signaling WG > > 1500-1530 Break (Refreshments provided) - Harbor Island Foyer > 1530-1730 Afternoon Sessions II > APP simple SIP for Instant Messaging and Presence Leveraging > Extensions WG > GEN genarea General Area Open Meeting > OPS rmonmib Remote Network Monitoring WG > RTG ospf Open Shortest Path First WG > TSV dccp Datagram Congestion Control Protocol WG > TSV pwe3 Pseudo Wire Emulation Edge to Edge WG > > 1730-1930 Break > 1930-2200 Evening Sessions > APP lemonade Enhancements to Internet email to Support Diverse > Service Environments WG > INT nemo Network Mobility WG > RTG rtgarea Routing Area Meeting > SEC mobike IKEv2 Mobility and Multihoming WG > OPS/ imss/ Internet and Management Support for Storage WG and > TSV ips IP Storage WG > > TUESDAY, August 3, 2004 > 0800-1800 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP simple SIP for Instant Messaging and Presence Leveraging > Extensions WG > INT dhc Dynamic Host Configuration WG > IRTF dtnrg Delay-tolerant Networking Research Group > OPS psamp Packet Sampling WG > RTG ccamp Common Control and Measurement Plane WG > TSV avt Audio/Video Transport WG > > 1130-1300 Break > 1300-1400 Afternoon Sessions I > APP geopriv Geographic Location/Privacy WG > OPS atommib Atom MIB WG > RTG pim Protocol Independent Multicast WG > SEC smime S/MIME Mail Security WG > TSV nsis Next Steps in Signaling WG > TSV speechsc Speech Services Control WG > > 1415-1515 Afternoon Sessions II > APP geopriv Geographic Location/Privacy WG > INT magma Multicast & Anycast Group Membership WG > OPS aaa Authentication, Authorization and Accounting WG > RTG vrrp Virtual Router Redundancy Protocol WG > SEC enroll Credential and Provisioning WG > TSV ieprep Internet Emergency Preparedness WG > > 1515-1545 Break (Refreshments provided) - Harbor Island Foyer > 1545-1645 Afternoon Sessions III > SEC sasl Simple Authentication and Security Layer WG > TSV rohc Robust Header Compression WG > > 1700-1800 Afternoon Sessions IV > APP ldapbis LDAP (v3) Revision WG > TSV rohc Robust Header Compression WG > > > WEDNESDAY, August 4, 2004 > 0800-1700 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP marid MTA Authorization Records in DNS WG > INT eap Extensible Authentication Protocol WG > OPS mboned MBONE Deployment WG > SEC pkix Public Key Infrastructure WG > TSV rddp Remote Direct Data Placement WG > TSV sip Session Initiation Protocol WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > IRTF asrg Anti Spam Working Group > OPS capwap Control and Provisioning of Wireless Access Points WG > OPS dnsop Domain Name System Operations WG > SEC krbwg Kerberos WG > TSV enum Telephone and Number Mapping WG > TSV mmusic Multiparty Multimedia Session Control WG > > 1500-1530 Break (Refreshments provided) - Harbor Island Foyer > 1530-1730 Afternoon Sessions II > APP marid MTA Authorization Records in DNS WG > GEN icar Improved Cross-Area Review WG > INT ipv6 IP Version 6 WG > OPS ipfix IP Flow Export WG > RTG isis IS-IS for IP Internets WG > SEC pki4ipsec Profiling Use of PKI in IPSEC WG > TSV avt Audio/Video Transport WG > > 1730-1930 Break > 1930-2200 Plenary - IETF Business Meeting - Grande Ballroom > > > 2230 Late Night Session > PGP Key Signing > > > THURSDAY, August 5, 2004 > 0800-1700 IETF Registration - Harbor Island Foyer > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > INT hip Host Identity Protocol WG > RTG mpls Multi Protocol Label Switching WG > SEC msec Multicast Security WG > TSV tsvwg Transport Area Working Group > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > INT ipdvb IP over Digital Video Broadcast WG > INT l3vpn Layer 3 Virtual Private Network WG > SEC ltans Long-Term Archive and Notary WG > TSV rserpool Reliable Server Pooling WG > TSV sip Session Initiation Protocol WG > > 1500-1530 Break (Refreshments provided) - Harbor Island Foyer > 1530-1730 Afternoon Sessions II > APP webdav WWW Distributed Authoring and Versioning WG > INT dnsext DNS Extensions WG > OPS grow Global Routing Operations WG * > SEC saag Open Security Area Directorate > TSV sipping Session Initiation Protocol WG > > 1730-1930 Break > 1930-2200 Plenary - IETF Planning Meeting - Grande Ballroom > > > Friday, August 6, 2004 > 0800-0900 Continental Breakfast - Harbor Island Foyer > 0900-1130 Morning Sessions > APP atompub Atom Publishing Format and Protocol PWG > OPS netconf Network Configuration WG > RTG rpsec Routing Protocol Security Requirements WG > TSV sipping Session Initiation Protocol WG > --Apple-Mail-12--337229252 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Note that IMAPEXT is meeting the afternoon of Monday, Aug 2. We should have a new annotate draft by then, discuss private/shared issues if they're still open, and hopefully start some discussion of LISTEXT by then ( I still owe a review but others ought to review as well). Lisa Begin forwarded message: 0000,0000,0000From: agenda@ietf.org 0000,0000,0000Date: June 16, 2004 2:49:27 PM PDT 0000,0000,0000To: wgchairs@ietf.org, iesg@ietf.org 0000,0000,0000Cc: mbeaulie@foretec.com 0000,0000,0000Subject: 60th IETF Meeting - DRAFT Agenda Draft Agenda of the Sixtieth IETF August 1 - 6, 2004 As of 6/16/2004 SUNDAY, August 1, 2004 1000-1700 IEPG Meeting - Marina 6 1200-1900 Registration - Harbor Island Foyer 1300-1400 Newcomer's Training - Grande Ballroom A 1300-1500 Editor's Training - Marina 5 1300-1500 Intro WG Chairs Training - 1500-1700 Security Tutorial - Grande Ballroom A 1700-1900 Welcome Reception - Grande Ballroom B/C MONDAY, August 2, 2004 0800-2000 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting GEN newtrk New IETF Standards Track Discussion WG INT dnsext DNS Extensions WG OPS multi6 Site Multihoming for IPv6 WG OPS hubmib Ethernet Interfaces and Hub MIB WG RTG manet Mobile Ad-hoc Networks WG TSV xcon Centralized Conference WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP imapext Internet Message Access Protocol Extension WG INT rbridge IP Subnets in Topologies Which are Flexible, Universal and Nice BOF IRTF mobopts IP Mobility Optimizations RTG forces Forwarding and Control Element Separation WG SEC perm Protected Entertainment Rights Management BOF TSV nsis Next Steps in Signaling WG 1500-1530 Break (Refreshments provided) - Harbor Island Foyer 1530-1730 Afternoon Sessions II APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG GEN genarea General Area Open Meeting OPS rmonmib Remote Network Monitoring WG RTG ospf Open Shortest Path First WG TSV dccp Datagram Congestion Control Protocol WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG 1730-1930 Break 1930-2200 Evening Sessions APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG INT nemo Network Mobility WG RTG rtgarea Routing Area Meeting SEC mobike IKEv2 Mobility and Multihoming WG OPS/ imss/ Internet and Management Support for Storage WG and TSV ips IP Storage WG TUESDAY, August 3, 2004 0800-1800 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT dhc Dynamic Host Configuration WG IRTF dtnrg Delay-tolerant Networking Research Group OPS psamp Packet Sampling WG RTG ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG 1130-1300 Break 1300-1400 Afternoon Sessions I APP geopriv Geographic Location/Privacy WG OPS atommib Atom MIB WG RTG pim Protocol Independent Multicast WG SEC smime S/MIME Mail Security WG TSV nsis Next Steps in Signaling WG TSV speechsc Speech Services Control WG 1415-1515 Afternoon Sessions II APP geopriv Geographic Location/Privacy WG INT magma Multicast & Anycast Group Membership WG OPS aaa Authentication, Authorization and Accounting WG RTG vrrp Virtual Router Redundancy Protocol WG SEC enroll Credential and Provisioning WG TSV ieprep Internet Emergency Preparedness WG 1515-1545 Break (Refreshments provided) - Harbor Island Foyer 1545-1645 Afternoon Sessions III SEC sasl Simple Authentication and Security Layer WG TSV rohc Robust Header Compression WG 1700-1800 Afternoon Sessions IV APP ldapbis LDAP (v3) Revision WG TSV rohc Robust Header Compression WG WEDNESDAY, August 4, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP marid MTA Authorization Records in DNS WG INT eap Extensible Authentication Protocol WG OPS mboned MBONE Deployment WG SEC pkix Public Key Infrastructure WG TSV rddp Remote Direct Data Placement WG TSV sip Session Initiation Protocol WG 1130-1300 Break 1300-1500 Afternoon Sessions I IRTF asrg Anti Spam Working Group OPS capwap Control and Provisioning of Wireless Access Points WG OPS dnsop Domain Name System Operations WG SEC krbwg Kerberos WG TSV enum Telephone and Number Mapping WG TSV mmusic Multiparty Multimedia Session Control WG 1500-1530 Break (Refreshments provided) - Harbor Island Foyer 1530-1730 Afternoon Sessions II APP marid MTA Authorization Records in DNS WG GEN icar Improved Cross-Area Review WG INT ipv6 IP Version 6 WG OPS ipfix IP Flow Export WG RTG isis IS-IS for IP Internets WG SEC pki4ipsec Profiling Use of PKI in IPSEC WG TSV avt Audio/Video Transport WG 1730-1930 Break 1930-2200 Plenary - IETF Business Meeting - Grande Ballroom 2230 Late Night Session PGP Key Signing THURSDAY, August 5, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions INT hip Host Identity Protocol WG RTG mpls Multi Protocol Label Switching WG SEC msec Multicast Security WG TSV tsvwg Transport Area Working Group 1130-1300 Break 1300-1500 Afternoon Sessions I INT ipdvb IP over Digital Video Broadcast WG INT l3vpn Layer 3 Virtual Private Network WG SEC ltans Long-Term Archive and Notary WG TSV rserpool Reliable Server Pooling WG TSV sip Session Initiation Protocol WG 1500-1530 Break (Refreshments provided) - Harbor Island Foyer 1530-1730 Afternoon Sessions II APP webdav WWW Distributed Authoring and Versioning WG INT dnsext DNS Extensions WG OPS grow Global Routing Operations WG * SEC saag Open Security Area Directorate TSV sipping Session Initiation Protocol WG 1730-1930 Break 1930-2200 Plenary - IETF Planning Meeting - Grande Ballroom Friday, August 6, 2004 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP atompub Atom Publishing Format and Protocol PWG OPS netconf Network Configuration WG RTG rpsec Routing Protocol Security Requirements WG TSV sipping Session Initiation Protocol WG --Apple-Mail-12--337229252-- 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 i5FHVtRn073034; Tue, 15 Jun 2004 10:31: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 i5FHVtPj073033; Tue, 15 Jun 2004 10:31: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 i5FHVtkK073021 for ; Tue, 15 Jun 2004 10:31:55 -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 i5FHUpJL008113 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Jun 2004 10:30:54 -0700 In-Reply-To: <623CFC7CC97B09F1A272A227@ninevah.cyrusoft.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> <623CFC7CC97B09F1A272A227@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Tue, 15 Jun 2004 10:31:41 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You are correct in pointing out all of these issues with the WebDAV property model or its equivalents. We could argue how bad these problems are but that depends on the use cases. Does anybody have any other property privacy schemes to propose? Anybody want to try to summarize the pros/cons of the ideas so far, or how the schemes relate to the most likely email use cases? We need some more discussion in order to close on this issue. Lisa On Jun 15, 2004, at 10:24 AM, Cyrus Daboo wrote: > Hi Lisa, > > --On Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault > wrote: > >>> Registering properties as private or shared is a non-starter in my >>> opinion. Consider what a server would have to do in a case like that: >>> the server would have to have some internal table tracking the >>> private/shared status of each property (as defined in the registry) >>> so >>> that it can determine whether the current user can access that >>> property. It would be impossible to keep the server up to date with >>> the registry. >> >> You know, this is exactly the way webDAV properties work, so I guess >> there is a proof by existence. Servers don't in fact have to keep >> up-to-date with the standards defining protected properties. Let's >> say >> the "quota" property is registered in a standard, as a property that >> may >> be read by the owner of the file and is protected from being written >> by >> most users. Then, if a server does advertise support for the 'quota' >> draft, then clients can count on the property being protected as >> defined. >> If the server does not advertise support for the 'quota' draft, then >> clients can set a property with the name 'quota' but it's a dead >> property >> and has no protection and no side-effects. By definition in WebDAV, >> dead >> properties are subject to regular access control as a group, rather >> than >> special server-mediated protection rules depending on the specific >> property. >> >> To generalize, the property registration scheme works if there's some >> way >> for clients to tell which properties the server knows about and >> protects >> in some way. If the client knows that the server explicitly protects >> 'foo' as defined in the registry, then the client can go ahead and use >> 'foo'. The client could either ask the server "what are your rules >> for >> protecting 'foo'" or "what properties do you support and protect in >> some >> manner". > > What you are suggesting is that every new property defined has to have > an associated CAPABILITY response so that the client knows that the > server supports it - or (to avoid CAPABILITY bloat but adding another > round-trip) a new 'ANNOTATEPROPS' command that returns the list of > known properties. > > However, how would you deal with the case of a client vendor that > wants to implement their own client-specific properties which need > varying access control restrictions (some shared, some private)? > > Also note that deployment of new versions of IMAP servers (and to a > lesser extent clients) tends to take a long time. I don't know how > that compares with http/webdav servers, but I would guess admins are > more willing to do frequent updates of those. That means that clients > that want to use a newly defined property will be stuck waiting on > server deployment, rather than being able to use it immediately in an > interoperable way. > > -- > 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 i5FHOFhZ071382; Tue, 15 Jun 2004 10:24:15 -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 i5FHOFcq071381; Tue, 15 Jun 2004 10:24:15 -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 i5FHOFh0071373 for ; Tue, 15 Jun 2004 10:24:15 -0700 (PDT) (envelope-from daboo@cyrusoft.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 i5FHI11F014475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2004 13:18:01 -0400 Date: Tue, 15 Jun 2004 13:24:17 -0400 From: Cyrus Daboo To: Lisa Dusseault cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Issues on annotate-09 Message-ID: <623CFC7CC97B09F1A272A227@ninevah.cyrusoft.com> In-Reply-To: References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> 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 Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault wrote: >> Registering properties as private or shared is a non-starter in my >> opinion. Consider what a server would have to do in a case like that: >> the server would have to have some internal table tracking the >> private/shared status of each property (as defined in the registry) so >> that it can determine whether the current user can access that >> property. It would be impossible to keep the server up to date with >> the registry. > > You know, this is exactly the way webDAV properties work, so I guess > there is a proof by existence. Servers don't in fact have to keep > up-to-date with the standards defining protected properties. Let's say > the "quota" property is registered in a standard, as a property that may > be read by the owner of the file and is protected from being written by > most users. Then, if a server does advertise support for the 'quota' > draft, then clients can count on the property being protected as defined. > If the server does not advertise support for the 'quota' draft, then > clients can set a property with the name 'quota' but it's a dead property > and has no protection and no side-effects. By definition in WebDAV, dead > properties are subject to regular access control as a group, rather than > special server-mediated protection rules depending on the specific > property. > > To generalize, the property registration scheme works if there's some way > for clients to tell which properties the server knows about and protects > in some way. If the client knows that the server explicitly protects > 'foo' as defined in the registry, then the client can go ahead and use > 'foo'. The client could either ask the server "what are your rules for > protecting 'foo'" or "what properties do you support and protect in some > manner". What you are suggesting is that every new property defined has to have an associated CAPABILITY response so that the client knows that the server supports it - or (to avoid CAPABILITY bloat but adding another round-trip) a new 'ANNOTATEPROPS' command that returns the list of known properties. However, how would you deal with the case of a client vendor that wants to implement their own client-specific properties which need varying access control restrictions (some shared, some private)? Also note that deployment of new versions of IMAP servers (and to a lesser extent clients) tends to take a long time. I don't know how that compares with http/webdav servers, but I would guess admins are more willing to do frequent updates of those. That means that clients that want to use a newly defined property will be stuck waiting on server deployment, rather than being able to use it immediately in an interoperable way. -- 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 i5FGRhNE056038; Tue, 15 Jun 2004 09:27: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 i5FGRhTb056037; Tue, 15 Jun 2004 09:27:43 -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 i5FGRfXP056017 for ; Tue, 15 Jun 2004 09:27:41 -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 i5FGQaJL004077 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Jun 2004 09:26:38 -0700 In-Reply-To: References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Tue, 15 Jun 2004 09:27:29 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Registering properties as private or shared is a non-starter in my > opinion. Consider what a server would have to do in a case like that: > the server would have to have some internal table tracking the > private/shared status of each property (as defined in the registry) so > that it can determine whether the current user can access that > property. It would be impossible to keep the server up to date with > the registry. You know, this is exactly the way webDAV properties work, so I guess there is a proof by existence. Servers don't in fact have to keep up-to-date with the standards defining protected properties. Let's say the "quota" property is registered in a standard, as a property that may be read by the owner of the file and is protected from being written by most users. Then, if a server does advertise support for the 'quota' draft, then clients can count on the property being protected as defined. If the server does not advertise support for the 'quota' draft, then clients can set a property with the name 'quota' but it's a dead property and has no protection and no side-effects. By definition in WebDAV, dead properties are subject to regular access control as a group, rather than special server-mediated protection rules depending on the specific property. To generalize, the property registration scheme works if there's some way for clients to tell which properties the server knows about and protects in some way. If the client knows that the server explicitly protects 'foo' as defined in the registry, then the client can go ahead and use 'foo'. The client could either ask the server "what are your rules for protecting 'foo'" or "what properties do you support and protect in some manner". 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 i58CZWk4087510; Tue, 8 Jun 2004 05:35:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i58CZWr5087509; Tue, 8 Jun 2004 05:35:32 -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 i58CZUhT087500 for ; Tue, 8 Jun 2004 05:35:32 -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.0) with ESMTP id i58CZTS8010704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 8 Jun 2004 05:35:29 -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 i58CZTT0068505 for ; Tue, 8 Jun 2004 05:35:29 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200406081235.i58CZTT0068505@lab.smi.sendmail.com> To: IMAP Extensions WG From: Philip Guenther Subject: LISTEXT draft Date: Tue, 08 Jun 2004 05:35:29 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please forgive me the disorganization of this note, I've having a hard time finding a good presentation for the thoughts and questions in it. I came up with these questions while trying to figure out what it would take to implement LISTEXT in the IMAP server I work on. Having pondered these questions, I understand less than when I started. For any possible mailbox name that matches a LIST pattern, there are eight possible situations to reflect the three conditions: - does the name exist as a mailbox - does the name match the selection criteria (LISTEXT options) - does the name have at least one child mailbox which exists and matches the selection criteria, but *doesn't* match the pattern has selected child returned exists selected that doesn't match LISTEXT flags --------------------------------------------------------------------------- no no no no response yes no no no response no yes no (\NonExistent) yes yes no () no no yes (???) <- 1 yes no yes (\PlaceHolder) no yes yes (\NonExistent) yes yes yes () <- 2 Question #1: What should be returned in case #1 (line 5) above? For a concrete example, consider a Cyrus-like server on which the mailbox "Vegis/Squash" was created and subscribed to, and then the "Vegis" mailbox was deleted, removing it completely and _not_ leaving it as a \NoSelect mailbox; should the command tag LIST (SUBSCRIBED) "" % return a LIST response for "Vegis", and if so, with what flags? Question #2: In the past, it has been argued that LSUB should return two responses for a given name, one with \NoSelect and one without, if the name was both subscribed and had subscribed children that did not match the pattern, i.e., line 8 in the table above. Others have disagreed with this reading of RFC 3501. Can LISTEXT please state how a server should respond in that situation? That is, should the server send a response with the \PlaceHolder flag and one without, or just one response? (Maintainers of IMAP clients should speak up here...) Question #3: The LISTEXT syntax permits an empty options list, e.g., tag LIST () "" % Does that mean the "selection criteria" is "does the mailbox exist"? Should the cited command return a LIST response for "Vegis", and if so, with what flags? Question #4: Consider the last four lines of the table at top. Should any of the responses change if the mailbox *also* has a selected child that *does* match the pattern? Question #5: Do any of your answers change if the pattern is "Veg%" instead of "%"? What if the pattern is "Vegis"? Philip Guenther guenther@sendmail.com 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 i57KeGEm000254; Mon, 7 Jun 2004 13:40:16 -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 i57KeGc4000253; Mon, 7 Jun 2004 13:40:16 -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 i57KeFPx000247 for ; Mon, 7 Jun 2004 13:40:15 -0700 (PDT) (envelope-from daboo@cyrusoft.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 i57KZC1F030819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 16:35:15 -0400 Date: Mon, 07 Jun 2004 16:40:16 -0400 From: Cyrus Daboo To: Lisa Dusseault , IMAP Extensions WG Subject: Re: Annotate draft comments Message-ID: 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 Wednesday, June 2, 2004 1:58 PM -0700 Lisa Dusseault wrote: > > > Discussion kind of died down on my comments on the annotate draft. Does > anybody see a consensus on the private/public stuff, which generated the > most discussion? (this is also an invitation for other people to chime > in who haven't already). Do the authors plan another draft? > > Lisa > Here is the list of issues I have since the last draft came out: 1) Private/shared debate: this issue is still open. I think it would be useful if those proposing a change could clarify their positions given the recent debate. 2) Language attribute: I agree this should be present for any value that represents text that can be displayed to the user. There is no need for it for numeric or enumerated (boolean) values such as flags. I will add text for that. 3) Missing IANA registrations: I will add those. 4) Clarification of /comment and /altsubject. I will add those. However, I am somewhat unsure of exactly what requirements /altsubject places on clients - so if anyone else can suggest those that would be handy. 5) Security considerations inadequate: perhaps someone could suggest better text for that or point out other areas in ANNOTATE that the current text does not mention. I would like to wait for the private/shared issue to be resolved before putting out another draft, but if we think that will take a while, I will go ahead and do a new draft with the other changes soon. -- 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 i57JgolB094027; Mon, 7 Jun 2004 12:42: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 i57Jgot2094026; Mon, 7 Jun 2004 12:42:50 -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 i57JgnJX094018 for ; Mon, 7 Jun 2004 12:42:49 -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 PAA11167; Mon, 7 Jun 2004 15:42:51 -0400 (EDT) Message-Id: <200406071942.PAA11167@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-i18n-03.txt Date: Mon, 07 Jun 2004 15:42:51 -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 : Internet Message Access Protocol Internationalization Author(s) : C. Newman, A. Gulbrandsen Filename : draft-ietf-imapext-i18n-03.txt Pages : 17 Date : 2004-6-7 Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-03.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-i18n-03.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-i18n-03.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-6-7154428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154428.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 i55909A1045154; Sat, 5 Jun 2004 02:00: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 i559091w045152; Sat, 5 Jun 2004 02:00:09 -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 i5590890045127 for ; Sat, 5 Jun 2004 02:00:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust107.tnt105.lnd4.gbr.da.uu.net [213.116.58.107]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 5 Jun 2004 09:59:56 +0100 Message-ID: <40C18AED.2060905@isode.com> Date: Sat, 05 Jun 2004 09:57:17 +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: Annotate draft comments 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: > Discussion kind of died down on my comments on the annotate draft. We need to collect all issues in one place. > Does anybody see a consensus on the private/public stuff, which > generated the most discussion? (this is also an invitation for other > people to chime in who haven't already). I think we've agreed to add more description about annotations like altsubject. I think there is no consensus to change existing private/public annotation model, as described by Cyrus recently. > Do the authors plan another draft? > > Lisa 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 i53G9ubt087788; Thu, 3 Jun 2004 09:09: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 i53G9uC0087786; Thu, 3 Jun 2004 09:09:56 -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 i53G9tiB087775 for ; Thu, 3 Jun 2004 09:09: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 i53G94JM010668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 3 Jun 2004 09:09:05 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Annotate draft comments Date: Wed, 2 Jun 2004 13:58:43 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Discussion kind of died down on my comments on the annotate draft. Does anybody see a consensus on the private/public stuff, which generated the most discussion? (this is also an invitation for other people to chime in who haven't already). Do the authors plan another draft? 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 i51FOjmU070976; Tue, 1 Jun 2004 08:24: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 i51FOjiC070975; Tue, 1 Jun 2004 08:24:45 -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 i51FOjS1070963 for ; Tue, 1 Jun 2004 08:24:45 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout5.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i51FOVMY007116; Tue, 1 Jun 2004 08:24:36 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i51FOV63021378; Tue, 1 Jun 2004 08:24:31 -0700 Date: Tue, 1 Jun 2004 08:24:31 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: ietf-imapext@imc.org Subject: Re: imapext-i18n draft In-Reply-To: Message-ID: References: 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, 1 Jun 2004, Arnt Gulbrandsen wrote: > If noone screams and stamps their feet, section 4.5 will die. Last warning > now. Yes! Death to 4.5. -- 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 i51EjiPD060496; Tue, 1 Jun 2004 07:45:44 -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 i51EjiLV060495; Tue, 1 Jun 2004 07:45:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i51Ejh30060454 for ; Tue, 1 Jun 2004 07:45:44 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: imapext-i18n draft Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 1 Jun 2004 16:48:03 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, there's been a new draft there for a few days, incorporating suggestions and addressing concerns from various people. If noone screams and stamps their feet, section 4.5 will die. Last warning now. I'd like to know whether you all think the example in section 4.3 is sensible. I like it and it seems in tune with the (currently expired) comparator draft. I can add some more examples if anyone thinks it's called for. Arnt